Comment créer une page de changelog : entrées, étiquettes, RSS et « Nouveautés »

Une page de changelog est une liste datée des changements de votre produit, du plus récent au plus ancien, rédigée pour les personnes qui l'utilisent. Pour la créer, il faut des entrées avec une date, un titre clair, une courte explication et une étiquette (Nouveau, Amélioré, Corrigé), une page qui les liste, une URL distincte pour chaque entrée et, idéalement, un flux RSS et un moyen de signaler aux utilisateurs qu'il y a du nouveau. C'est l'une des choses les plus simples à construire ; la décision principale concerne l'emplacement des entrées : des fichiers dans votre site, ou une base de données avec une page d'administration.

Pourquoi un changelog vaut la peine

Un changelog montre aux clients et aux prospects que le produit est entretenu. Il donne au support et aux équipes commerciales un lien à envoyer lorsqu'on leur demande si le produit fait déjà X. C'est aussi un moyen de boucler la boucle des retours : lorsqu'une fonctionnalité demandée est livrée, l'entrée de changelog est ce vers quoi vous orientez les personnes. Si vous gérez un portail de retours clients, reliez directement les demandes livrées à leurs entrées.

Un changelog n'est pas votre historique de commits interne. « Refactorisation du service de facturation » ne veut rien dire pour un utilisateur. « Les factures affichent désormais le numéro de TVA de votre entreprise » oui.

Ce qu'il faut sur la page

Contenu de chaque entrée

Champ	Remarques
Titre	Ce qui a changé, du point de vue de l'utilisateur
Date	Date de publication, affichée sur la page
Étiquette	Nouveau, Amélioré, Corrigé (et peut-être Supprimé ou Sécurité)
Corps	Quelques phrases ou puces ; comment l'utiliser, qui en bénéficie
Image ou vidéo	Facultatif ; une capture d'écran en dit plus qu'un paragraphe
Slug	L'URL de l'entrée, comme `/changelog/invoice-vat-numbers`
Statut	Brouillon ou publiée, plus une date de publication programmée si nécessaire

Extras dans l'application

Badge « Nouveautés » : un point sur un élément de menu lorsqu'il existe des entrées que l'utilisateur n'a pas vues. Stockez la date de la dernière entrée ouverte, par utilisateur ou dans le navigateur.
Récapitulatif par e-mail : un résumé envoyé aux utilisateurs qui y ont consenti. Cela nécessite un fournisseur d'envoi ; voir comment envoyer des e-mails depuis votre application.

La décision principale : fichiers ou base de données

Entrées sous forme de fichiers dans le site

Chaque entrée est un fichier Markdown du projet. Publier une entrée signifie ajouter un fichier et redéployer. C'est l'approche la plus simple et la plus robuste : pas de base de données, pas de connexion d'administration, rien à sécuriser, et les pages peuvent être pré-rendues pour charger vite et être faciles à lire pour les moteurs de recherche.

Elle convient aux équipes dont les rédacteurs sont à l'aise pour demander à un générateur IA ou pour modifier un fichier.

Entrées dans une base de données avec page d'administration

Les entrées vivent dans une table, et une page d'administration privée permet à toute personne de l'équipe de rédiger, prévisualiser, programmer et publier. Cela convient aux équipes où le marketing ou le support rédige les mises à jour, ou lorsque vous voulez une publication programmée ou des entrées par audience (par exemple, n'afficher les fonctionnalités entreprise qu'aux clients entreprise).

Le coût est une construction et une maintenance plus lourdes : une connexion d'administration, des envois d'images, et la garantie que les pages publiques restent lisibles par les moteurs de recherche, ce qu'une page qui ne charge les entrées que dans le navigateur peut ne pas permettre.

	Fichiers	Base de données + administration
Qui peut publier	Quiconque modifie le projet	Toute personne avec une connexion d'administration
Mise en place	Minimale	Connexion, stockage, interface d'administration
SEO	Facile (pages pré-rendues)	Demande du soin pour que les pages soient rendues côté serveur ou pré-rendues
Programmation	Publication au déploiement	Possible par date
Coût d'hébergement	Statique	Nécessite une application en cours d'exécution et une base de données

Rédiger des entrées que les gens lisent

Commencez par le bénéfice. « Exporter les rapports vers Excel » vaut mieux que « Nouveau module d'export ».
Dites à qui cela s'adresse. Tous les forfaits, Pro uniquement, déploiement progressif cette semaine.
Montrez-le. Une capture d'écran ou un court extrait.
Regroupez les petites corrections. Une entrée hebdomadaire « Corrections et améliorations » en puces évite d'inonder la page.
Soyez honnête sur les suppressions. Si une fonctionnalité disparaît, dites quand et par quoi la remplacer.

Un premier prompt qui fonctionne

Ajoute un changelog public à notre site sur /changelog. Chaque entrée est un fichier Markdown avec un titre, une date, une étiquette (Nouveau, Amélioré ou Corrigé), une image de couverture facultative et un corps. La page d'index liste les entrées de la plus récente à la plus ancienne avec la date, l'étiquette et le premier paragraphe, dispose de boutons de filtre par étiquette, et affiche 10 entrées par page. Chaque entrée a sa propre page à /changelog/<slug>, avec un titre de page et une description adaptés aux moteurs de recherche. Ajoute un flux RSS à /changelog/rss.xml. Crée trois entrées d'exemple. Respecte le design existant du site, reste lisible sur téléphone, et pré-rends les pages pour qu'elles se chargent rapidement.

Pour la version avec base de données, remplacez la première phrase par « Stocke les entrées dans une base de données avec un statut brouillon ou publié et une date de publication, et ajoute une page d'administration protégée par mot de passe pour les rédiger, les prévisualiser et les publier. »

Étapes de création

Décider fichiers ou base de données en vous appuyant sur le tableau ci-dessus.
Construire la page d'index et les pages d'entrées avec quelques entrées d'exemple.
Ajouter les étiquettes et les filtres.
Ajouter le flux RSS et le lier depuis la page.
Ajouter les titres de page, les descriptions et une entrée dans le plan du site pour chaque entrée. Notre guide sur le SEO pour les sites créés avec l'IA couvre les bases.
Page d'administration et connexion, si vous avez choisi la voie avec base de données.
Badge « Nouveautés » dans votre application.
Rédiger de vraies entrées pour les derniers mois, pour que la page ne soit pas vide au lancement.

Erreurs courantes

Copier les messages de commit. Rédigez pour les utilisateurs, pas pour les développeurs.
Une seule grande page sans URL par entrée. Personne ne peut lier un changement précis, et les moteurs de recherche voient une page au lieu de nombreuses.
Les mises à jour s'arrêtent après un mois. Un changelog dont la dernière mise à jour remonte à un an suggère un produit abandonné. Fixez un rythme que vous pouvez tenir.
Charger les entrées seulement dans le navigateur. Les moteurs de recherche et les aperçus de liens peuvent voir une page vide. Pré-rendez ou rendez côté serveur.
Mélanger les incidents. Les pannes ont leur place sur une page d'état, pas dans le changelog.

Quand un outil de changelog hébergé est le meilleur choix

Il existe des outils hébergés de changelog et de mises à jour produit, dont certains sont fournis avec des tableaux de retours ou des widgets intégrés à l'application. Ils valent le coup si vous voulez une fenêtre contextuelle dans l'application, un ciblage d'audience et des statistiques sans les construire, ou si votre équipe paie déjà un outil qui en inclut un. Votre logiciel de blog ou de centre d'aide peut aussi proposer un format adapté.

Créer le vôtre a du sens lorsque vous voulez le changelog sur votre propre domaine, dans votre propre design, et entièrement indexable ; pour une simple liste d'entrées datées, le travail reste limité.

Créer avec Mythex

Sur Mythex, vous pouvez demander à l'agent d'ajouter un changelog à un projet existant ou de le construire comme petit site autonome, et de le voir dans l'aperçu en direct au fur et à mesure. La version basée sur des fichiers n'a pas besoin de base de données. Si vous choisissez la version avec administration, l'agent ajoute une base Postgres dédiée lorsque les entrées doivent être enregistrées (ou tapez /database), et les captures d'écran vont dans le stockage de fichiers du projet. La connexion de l'administration est à ajouter avec votre propre approche d'authentification (recette d'ajout de connexion).

Les nouvelles applications Mythex sont souvent des applications monopages rendues côté client, que la recette SEO présente comme moins bien adaptées à la recherche ; demandez donc des pages de changelog statiques ou pré-rendues si vous voulez que les entrées soient trouvées sur les moteurs de recherche. La même recette couvre les titres, les descriptions et les plans du site. Pour un point de départ avec un changelog intégré, voir le modèle hub de connaissances produit.

Questions

Que doit contenir une entrée de changelog ?

Une date, un titre court qui dit ce qui a changé pour l'utilisateur, quelques phrases ou puces qui l'expliquent, une étiquette telle que Nouveau, Amélioré ou Corrigé, et, facultativement, une capture d'écran et un lien vers plus de détails.

Un changelog a-t-il besoin d'une base de données ?

Pas forcément. Si une ou deux personnes publient les mises à jour, les entrées peuvent être des fichiers Markdown du site, publiés à chaque déploiement. Utilisez une base de données lorsque des personnes non techniques doivent rédiger et programmer des entrées depuis une page d'administration.

À quelle fréquence faut-il mettre à jour un changelog ?

Chaque fois qu'un changement remarquable pour les utilisateurs intervient. De nombreux petits produits regroupent les changements chaque semaine ou toutes les deux semaines ; l'important est un rythme régulier pour que la page paraisse vivante.

Un changelog est-il bon pour le SEO ?

Il peut aider un peu : chaque entrée est une page explorable sur une fonctionnalité, et une page régulièrement mise à jour signale un produit actif. Donnez à chaque entrée sa propre URL et un titre descriptif.