Créer une page de changelog produit sans code : le guide

Créer une page de changelog produit sans code

Oui, et la vraie question n'est pas la construction mais la mise à jour. La page se génère en une construction à 6 crédits. Ce qui compte ensuite, c'est de choisir entre publier chaque entrée par une modification, stocker les entrées dans une base Supabase, ou exporter le code vers GitHub.

Ce choix se fait au début, parce qu'il conditionne la structure de la page. Le reste du guide part de là.

À quoi sert vraiment une page de changelog ?

À trois choses distinctes, et il vaut mieux savoir laquelle vous vise, sinon la page finit par ne servir à aucune.

Elle sert d'abord à vos utilisateurs actuels. Un client qui a demandé une fonctionnalité il y a trois mois veut savoir qu'elle est arrivée. Sans page de nouveautés, vous lui envoyez un e-mail ou vous ne lui dites rien, et la deuxième option est malheureusement la plus fréquente.

Elle sert ensuite de preuve de vie. Un prospect qui hésite entre deux outils regarde souvent la date de la dernière mise à jour publiée. Un produit qui bouge chaque mois inspire davantage confiance qu'un produit dont la dernière nouvelle date de l'an dernier.

Elle sert enfin de mémoire interne. Le support y renvoie les clients, l'équipe commerciale y retrouve ce qui a été livré, et vous-même y relisez ce qui a changé avant de préparer une démonstration. Cette troisième fonction est celle qu'on découvre après six mois.

Que contient une entrée de changelog bien écrite ?

Cinq éléments, pas plus. Les changelogs illisibles sont ceux qui mélangent le journal de commits et la communication client.

Écrivez les descriptions du point de vue de l'utilisateur. « Ajout d'un index sur la table des factures » ne dit rien à personne. « L'export des factures s'ouvre désormais sans attente sur les gros comptes » dit exactement la même chose et donne envie de tester.

Une entrée fait deux à quatre phrases. Au-delà, c'est un article de blog, et il vaut mieux le publier comme tel avec un lien depuis le changelog.

Quel rythme de publication tenir ?

Un rythme que vous pourrez tenir dans six mois, pas celui de la semaine de lancement. Un changelog abandonné fait plus de mal qu'une absence de changelog.

Le rythme mensuel convient à la plupart des petites équipes. Il permet de regrouper les correctifs, de raconter une progression et de rédiger sérieusement une fois par mois plutôt que mal quatre fois.

Le rythme hebdomadaire convient aux produits en forte évolution avec une personne dédiée à la communication. Il crée une habitude chez les utilisateurs, à condition de ne pas remplir les semaines creuses avec du remplissage.

Ce qui ne fonctionne jamais, c'est la publication à chaque déploiement. Vos clients ne veulent pas savoir que vous avez livré vingt fois cette semaine. Ils veulent savoir ce qui change pour eux, ce qui est souvent une seule ligne sur les vingt.

Choisissez donc un rythme, annoncez-le sur la page, et respectez-le. « Nouveautés publiées le premier mardi de chaque mois » vaut mieux que n'importe quelle promesse de temps réel.

Quel prompt donne une page de changelog utilisable ?

Un prompt qui décrit la structure d'une entrée et le filtrage, pas seulement l'apparence.

Crée une page de changelog produit pour un logiciel de gestion
de projet en ligne.
Une entrée contient : date, catégorie (Nouveauté, Amélioration,
Correctif), titre court, description de deux à quatre phrases,
et une mention facultative « Attention, changement de comportement ».
Les entrées sont affichées de la plus récente à la plus ancienne,
regroupées par mois, avec un filtre par catégorie en haut.
Chaque entrée a sa propre ancre partageable.
En haut de page : une phrase expliquant le rythme de publication
et un champ e-mail pour recevoir les nouveautés.
En bas : un lien vers la documentation et un lien vers la page
de suggestions.
Design sobre, colonne de lecture étroite, beaucoup d'air,
lisible sur téléphone.

Les ancres par entrée valent le détour : elles permettent au support de renvoyer un client directement sur la bonne nouveauté. C'est le genre de détail impossible à rattraper élégamment plus tard, et gratuit si vous le demandez au départ.

Le champ e-mail suppose une intégration derrière. Zugo se branche sur Resend pour les e-mails partant du projet, ce qui se met en place une fois que la page existe.

Comment mettre à jour la page sans y laisser tous ses crédits ?

Voici la partie que la plupart des guides passent sous silence. Trois méthodes, trois budgets, trois publics.

La première coûte 3 crédits par publication. À raison d'une entrée par mois, c'est négligeable ; à raison d'une par semaine, cela reste tenable ; à raison d'une par jour, cela devient absurde et il faut changer de méthode.

La deuxième est celle qui convient au plus grand nombre. Les entrées deviennent des lignes dans une table, n'importe qui de l'équipe peut en ajouter une sans repasser par une génération, et la page reste identique. C'est aussi ce qui permet de préparer plusieurs entrées à l'avance.

La troisième s'adresse aux équipes qui ont déjà un dépôt et une routine de publication. L'export vous rend le code source et vous continuez chez vous, avec le déploiement sur votre propre compte Vercel si vous le souhaitez.

Combien cela coûte-t-il en crédits ?

Les tarifs sont les mêmes pour tous les projets.

Le plan gratuit donne 5 crédits, soit une unité de moins qu'une construction : de quoi essayer, pas de quoi livrer. Pro coûte $25 par mois pour 200 crédits, ce qui représente environ 33 constructions, 66 modifications ou 16 plateformes multipages. Business coûte $99 par mois pour 800 crédits.

Un changelog publié chaque semaine consomme donc 12 crédits par mois en méthode manuelle, ce qui laisse la très grande majorité d'un plan Pro pour le reste de vos projets. Si vous passez en base, la publication ne consomme plus rien du tout.

Quelles limites faut-il accepter ?

Trois, et aucune n'est bloquante si elle est connue à l'avance.

La page ne se remplit pas toute seule depuis votre dépôt. Personne ne lit vos commits pour rédiger vos nouveautés à votre place, et c'est plutôt une bonne nouvelle : un changelog généré depuis des messages techniques est illisible pour un client.

Zugo ne remplace pas une équipe de développement sur un produit complexe. Un changelog reste une page, très simple par nature. Le jour où vous voulez des notifications ciblées par segment d'utilisateur et un historique par compte, c'est un morceau de produit, pas une page, et l'export du code devient la bonne décision.

Enfin, la vérification en bac à sable confirme que la page s'ouvre avant qu'elle vous soit livrée : une construction qui ne démarre pas n'est pas remise. Elle ne relit pas vos dates, vos numéros de version, ni la justesse de ce que vous annoncez.

Par où commencer ?

Rédigez trois entrées avant de générer quoi que ce soit, en reprenant vos trois dernières livraisons réelles. C'est le seul moyen de savoir si votre modèle d'entrée fonctionne, et cela prend vingt minutes.

Lancez ensuite la construction, publiez sur l'adresse .zugo.run fournie, puis reliez la page à votre produit. Elle fonctionne mieux entourée : créer un site de documentation pour les explications détaillées, créer une page de statut pour les incidents, et créer un tableau de suggestions pour recueillir ce que les gens attendent ensuite. Ouvrez un compte sur zugo.dev et commencez par vos trois entrées.