Un produit qui progresse sans le dire est indiscernable, vu de l'extérieur, d'un produit à l'arrêt. Le changelog n'est pas une formalité de communication : c'est la seule preuve datée qu'il se passe quelque chose.
La réponse courte. Un changelog public est un journal des changements livrés, lisible par les clients. Sa valeur tient à trois choses : la régularité, le fait de dire ce que le changement permet plutôt que ce qui a été modifié, et le lien avec les demandes qui l'avaient motivé. Il ne retient personne à lui seul.
À qui il sert réellement
Trois publics distincts le lisent, pour trois raisons différentes.
Ceux qui ont demandé quelque chose. Ils cherchent leur demande. C'est le lecteur le plus important et celui pour qui le lien entre l'entrée et la demande d'origine change tout.
Ceux qui hésitent à renouveler. Ils cherchent une réponse à « ce produit avance-t-il ». Six mois d'entrées régulières répondent mieux que n'importe quel argumentaire.
Ceux qui évaluent le produit avant d'acheter. Pour un produit jeune, c'est un signal de vitalité souvent plus convaincant qu'une page de fonctionnalités.
Ces trois usages expliquent pourquoi un changelog interne, ou une liste de numéros de version, ne remplit pas la fonction.
Ce qui distingue une entrée utile
La différence tient à ce qu'on met en sujet de la phrase.
Une entrée faible décrit le changement : « ajout d'un filtre sur la liste des retours ». Une entrée utile décrit ce qui devient possible : « vous pouvez maintenant afficher uniquement les retours d'un client donné, ce qui évite de parcourir toute la liste avant une réunion de renouvellement ».
Quatre éléments à inclure, aucun long :
- Ce qui change, en une phrase, du point de vue de l'usage.
- Pour qui, si cela ne concerne pas tout le monde.
- Où le trouver, parce que la fonctionnalité la mieux conçue ne sert à rien si personne ne la trouve.
- Le lien vers la demande d'origine, quand il y en a une.
Ce qu'il vaut mieux éviter : les numéros de version comme titre, le vocabulaire interne, et les regroupements trimestriels qui noient dix changements dans un pavé.
Le rythme compte plus que le volume
Un changelog irrégulier est presque pire que pas de changelog : il donne une date visible du dernier signe de vie.
Mieux vaut une entrée courte toutes les deux semaines qu'une longue tous les trimestres. La régularité est ce que le lecteur interprète, bien plus que la taille des livraisons.
Deux conséquences pratiques. Publier aussi les petites choses : une correction de bug qui gênait trois clients mérite une ligne, et ces trois clients la verront. Et ne pas attendre une grosse fonctionnalité pour publier, sinon le journal s'arrête pendant les mois où le travail est le plus lourd, c'est-à-dire exactement quand le silence est le plus mal interprété.
Le lien avec les demandes
C'est ce qui transforme un journal en fermeture de boucle.
Quand une livraison répond à une demande, l'entrée doit pointer vers elle, et la demande doit changer d'état. Les personnes qui l'avaient soutenue apprennent alors la nouvelle sans que personne n'écrive de message individuel.
C'est l'étape de communication de la boucle de feedback, et c'est presque toujours celle qui manque. Une équipe peut construire exactement ce que les utilisateurs demandaient et n'en tirer aucun bénéfice de perception simplement parce que personne ne l'a su.
Le changelog de FlagUp fonctionne sur ce principe, en lien avec le tableau des demandes de fonctionnalités.
Ce qu'un changelog ne fait pas
Il faut être clair là-dessus, car la promesse est souvent surestimée.
Un changelog ne retient pas un client dont le problème n'est pas résolu. Voir passer dix améliorations qui ne concernent pas sa difficulté peut même produire l'effet inverse : la preuve que l'équipe travaille sur autre chose.
Il ne remplace pas non plus une feuille de route. Le changelog regarde en arrière, la roadmap regarde en avant, et les deux questions que se posent les clients sont différentes.
Enfin, aucune donnée publique fiable ne permet d'affirmer qu'un changelog améliore la rétention d'un pourcentage donné. Ce qu'on peut dire sans exagérer : il rend visible un travail déjà fait, et l'invisibilité de ce travail a un coût certain.
Questions fréquentes
Faut-il publier les corrections de bugs ?
Oui, sauf les correctifs internes sans effet perceptible. Une correction visible rassure ceux qui l'avaient signalée et montre que les signalements servent.
Faut-il annoncer les changements à venir dans le changelog ?
Non, cela brouille sa fonction. Le changelog dit ce qui est livré et disponible maintenant. Ce qui est prévu relève de la roadmap.
Que faire des changements qui dégradent l'expérience de certains ?
Les annoncer explicitement, avec la raison et la solution de remplacement. Découvrir seul une suppression de fonctionnalité coûte beaucoup plus cher en confiance que l'annonce elle-même.
À quelle fréquence minimale ?
Deux fois par mois est un rythme tenable pour la plupart des équipes. En deçà d'une fois par mois, le journal commence à se lire comme un signe d'arrêt.
Pour aller plus loin
- Building in public : partager sa roadmap avec prudence
- Réduire le churn avec une boucle de feedback structurée
- Comment utiliser le NPS pour construire une roadmap
Relier une livraison à la demande qui l'a motivée ferme la boucle sans écrire un message par personne. Voyez le changelog et les tarifs.