Le changelog : l'outil marketing le plus sous-estimé du SaaS

La plupart des équipes SaaS consacrent des semaines à développer une nouvelle fonctionnalité et 20 minutes à la communiquer. Un changelog bien fait peut doubler l'adoption d'une nouvelle fonctionnalité, réduire le churn des utilisateurs qui attendaient cette évolution, et générer du bouche-à-oreille spontané.

Un changelog mal fait (ou absent) est une opportunité manquée à chaque release. Et vous releasez souvent — c'est autant d'opportunités ratées.

Ce qu'un bon changelog contient

Un titre qui dit "pourquoi", pas "quoi"

Mauvais : "Mise à jour de l'interface des paramètres"
Bon : "Trouvez vos paramètres 3x plus vite avec la nouvelle organisation"

Vos utilisateurs ne lisent pas votre changelog pour savoir ce que vous avez fait. Ils le lisent pour savoir si ça change quelque chose pour eux.

Une description humaine, pas technique

Évitez le jargon technique dans votre changelog public. "Nous avons refactorisé le module d'authentification pour améliorer la scalabilité" signifie rien pour votre utilisateur. "La connexion est maintenant 2x plus rapide et vous restez connecté plus longtemps" signifie tout.

Un visuel

Une capture d'écran ou une courte vidéo de 30 secondes augmente l'engagement sur les entrées de changelog de 60 à 120 % selon les études. Les utilisateurs comprennent instantanément le changement sans devoir l'explorer dans le produit.

Le contexte "pourquoi maintenant"

Si vous pouvez mentionner que cette fonctionnalité était demandée par vos utilisateurs ("Suite à vos nombreux retours..."), faites-le. Ça ferme la boucle du feedback et ça montre que vous écoutez.

La fréquence idéale

Il n'y a pas de règle universelle, mais deux extrêmes à éviter :

  • Trop rare (une fois par trimestre) : vos utilisateurs n'ont pas l'habitude de le lire, et vos releases semblent rares même si ce n'est pas le cas
  • Trop fréquent (plusieurs fois par semaine) : les utilisateurs développent une "fatigue changelog" et commencent à ignorer les notifications

La fréquence idéale pour la plupart des SaaS : 2 à 4 fois par mois, avec des entrées regroupant plusieurs petites améliorations sous des thèmes cohérents.

Distribuer votre changelog

Un changelog publié sur une page web cachée dans vos docs ne sera lu par personne. Distribution recommandée :

  • Une notification in-app (badge ou popup non intrusif) pour les utilisateurs actifs
  • Un email mensuel "Ce qui a changé ce mois-ci" pour votre base entière
  • Un post LinkedIn/Twitter pour les releases majeures
  • Une page publique indexée pour le SEO

Conclusion

Votre changelog est votre journal de bord public. C'est la preuve tangible que votre produit évolue, que vous écoutez, et que vous livrez. Traitez-le avec le soin que vous accordez à votre marketing — parce que c'en est.