Exemples de release notes pour chaque type de changement

Les meilleurs exemples de release notes sont courts, nomment les personnes concernées et disent quoi faire ensuite. Voici un exemple pour chaque type de changement que vous livrerez, avec la raison pour laquelle il fonctionne, pour que vous puissiez copier la forme et y mettre vos propres faits.

Tous les exemples sont inventés, pour une application de facturation fictive appelée Tidepool.

Que partagent les bons exemples de release notes ?

Ils disent aux utilisateurs ce qui a changé et ce qu’ils doivent éventuellement en faire, avec leurs mots à eux. Chaque type de changement a un rôle différent, donc la forme varie de l’un à l’autre.

À quoi ressemble une bonne note de nouvelle fonctionnalité ?

Une bonne note de fonctionnalité s’ouvre sur ce que le lecteur peut faire maintenant et nomme les plans ou les rôles qui y ont accès. Elle laisse de côté l’implémentation.

Envoyez vos factures dans la langue du client. Vous pouvez désormais choisir une langue pour chaque client, et ses factures, ses relances et sa page de paiement la suivent. Le français, l’allemand, l’espagnol et le portugais sont disponibles sur tous les plans. Réglez-la depuis la page du client, sous Préférences de facturation.

Le titre est une phrase que le lecteur dirait à voix haute, et le corps donne la portée et l’emplacement. Un lecteur qui ne parcourt que la ligne en gras sait déjà ce qui est sorti. La méthode générale est dans comment écrire des release notes.

À quoi ressemble une bonne note d’amélioration ?

Une note d’amélioration décrit un changement que le lecteur va ressentir, et y met un chiffre mesuré quand il en existe un. Sans chiffre, dites ce que le lecteur n’a plus à faire.

La liste des factures se charge environ trois fois plus vite. Les comptes de plus de 5 000 factures attendaient environ neuf secondes pour la liste. Elle s’ouvre maintenant en trois secondes environ. Aucune action requise.

“Améliorations de performance” ne dit rien au lecteur, alors que neuf secondes contre trois est une affirmation qu’il peut vérifier lundi matin. Le “Aucune action requise” final répond à la question que chaque lecteur se pose.

À quoi ressemble une bonne note de correctif ?

Une note de correctif décrit le symptôme que l’utilisateur a vu, pas la cause dans le code, et dit s’il doit refaire quelque chose. Les corrections que personne n’a remarquées peuvent aller dans la liste du bas.

Corrigé : e-mails de relance envoyés en double le jour d’échéance. Certains clients recevaient deux relances identiques lorsque leur facture arrivait à échéance le dernier jour d’un mois. C’est corrigé. Les relances déjà envoyées ne sont pas concernées, et personne n’a besoin de rien renvoyer.

Le titre commence par “Corrigé” pour qu’un lecteur qui survole puisse trier d’un coup d’œil, et la vraie condition (le dernier jour du mois) suit aussitôt.

Comment rédiger des release notes pour un changement cassant ?

Une note de changement cassant commence par la date et le groupe concerné, puis donne la migration dans la même entrée. Elle va en premier dans les release notes, parce que c’est l’entrée qu’un lecteur ne doit pas manquer.

Les signatures de webhook deviennent obligatoires le 1er décembre 2026. À partir de cette date, Tidepool cesse d’envoyer des charges utiles de webhook non signées. Cela concerne toute personne qui reçoit des webhooks sans vérifier l’en-tête Tidepool-Signature. Pour migrer, vérifiez l’en-tête avec le secret sous Paramètres, Développeurs. Si vous vérifiez déjà les signatures, aucune action requise.

La date est dans le titre, donc elle survit à une lecture en diagonale. Le groupe concerné est désigné par ce qu’il fait, et la dernière phrase libère ceux qui sont déjà en règle, ce qui réduit la charge du support. Le guide sur les changements cassants explique comment décider si un changement en est un.

À quoi ressemble une note de correctif de sécurité ?

Une note de sécurité dit ce qui était exposé, si quelqu’un l’a exploité, qui est concerné et ce qu’il doit faire. Restez factuel et calme.

Sécurité : des liens de réinitialisation de mot de passe pouvaient être réutilisés. Entre le 3 et le 17 septembre 2026, un lien de réinitialisation de mot de passe restait valide après un premier usage. Nous n’avons trouvé aucun signe d’exploitation. C’est corrigé, et tous les liens de réinitialisation en attente ont été invalidés. Si vous avez demandé une réinitialisation pendant cette période, demandez un nouveau lien.

La période exacte permet au lecteur d’évaluer sa propre exposition, et la phrase sur l’exploitation répond à la première question que tout le monde pose. “Un problème potentiel” ressemble à de la dissimulation, alors dites ce que vous savez.

Comment rédiger un avis de dépréciation ?

Un avis de dépréciation nomme ce qui est retiré, donne une date de fin ferme et pointe vers le remplacement.

L’endpoint v1 des factures est déprécié et prend fin le 1er mars 2027. GET /v1/invoices continue de fonctionner jusqu’au 1er mars 2027, puis renvoie 410 Gone. Utilisez GET /v2/invoices, qui renvoie les mêmes champs plus currency. Les réponses de v1 incluent désormais un en-tête Sunset avec la date de fin. Un guide de migration côte à côte est dans la documentation.

Le nom de l’endpoint est dans le titre, parce que les personnes concernées le recherchent, et le remplacement se trouve à côté du retrait. L’en-tête Sunset indique aux développeurs quels appels utilisent encore l’ancienne version. Le traitement plus long est dans déprécier une API.

À quoi ressemble une note de release pour l’app store ?

Une note pour l’app store tient en deux ou trois phrases simples, parce que la plupart des gens ne lisent que la première ligne. Commencez par le changement qu’un utilisateur remarquerait.

Scannez un reçu papier et Tidepool remplit le montant, la date et le fournisseur. Le mode sombre suit désormais le réglage de votre téléphone. Nous avons aussi corrigé un plantage à l’ouverture d’une facture depuis une notification.

Le changement le plus utile vient en premier, et la correction nomme la situation qui plantait. Pas de numéro de version et pas de “corrections de bugs et améliorations”. Les release notes pour applications mobiles couvrent les règles propres aux boutiques.

Que doit contenir une note de release interne ?

Une note interne est la version pour le support et les ventes. Elle ajoute ce que la note publique omet : ce qu’il faut dire, et ce qu’il faut éviter de promettre.

Les factures multilingues sont sorties aujourd’hui (tous les plans). Support : les clients règlent la langue sous Préférences de facturation, et les factures existantes gardent leur langue d’origine. L’italien n’est pas encore disponible. Ventes : c’est ouvert à tous les plans, ne le présentez donc pas comme une montée en gamme.

Chaque public a sa propre ligne étiquetée, et la note pose la limite (“L’italien n’est pas encore disponible”) avant qu’un client ne la demande. L’article sur les notes de release internes couvre le format et les canaux.

À quoi ressemble une mauvaise note de release, réécrite ?

Une mauvaise note de release énumère ce que l’équipe a fait au lieu de ce que le lecteur obtient. Corrigez-la en mettant le résultat en tête et en supprimant le vocabulaire interne.

Avant :

v3.8.1 Refactorisation du planificateur de relances. Correction d’une race condition dans ReminderJob. Mise à jour de bull en 4.12. Améliorations diverses.

Après :

Les e-mails de relance ne partent plus en double. Les clients dont une facture arrivait à échéance le dernier jour d’un mois pouvaient recevoir deux relances. C’est corrigé, et les relances déjà envoyées n’ont pas besoin d’être renvoyées. Aucune action requise.

Aussi dans 3.8.1 : bull mis à jour en 4.12.

La mise à jour de dépendance est descendue en pied de note, et la race condition est devenue un symptôme qu’un client reconnaîtrait.

Comment garder des release notes cohérentes d’une version à l’autre ?

Rédigez chaque entrée quand le changement est fusionné, et faites-la approuver par une personne avant la livraison.

Changeloop fonctionne ainsi : il rédige une entrée à partir de chaque pull request fusionnée avec l’IA et la retient jusqu’à ce qu’un humain l’approuve. C’est à l’étape d’approbation qu’un éditeur applique les règles ci-dessus. Pour fixer d’abord le format, partez du modèle de release notes, et consultez des exemples de changelog pour voir à quoi ressemblent des pages terminées.

FAQ

Que sont de nouvelles release notes ? De nouvelles release notes sont le message publié avec la dernière version d’un produit, qui décrit ce qui a changé et ce que les utilisateurs doivent faire. Elles couvrent les fonctionnalités, les améliorations, les correctifs et les changements cassants.

Quelle est la différence entre une release note et un changelog ? Le changelog garde tout, pour quiconque veut l’historique complet. Une release note y puise : une seule version, écrite pour les lecteurs qui se demandent si elle les concerne. La comparaison complète est dans changelog vs release notes.

Que signifie release notes ? Les release notes disent aux utilisateurs ce qui a changé dans une version. L’expression couvre tout ce qui explique ce qui est sorti, d’un texte “Nouveautés” de l’app store à une page du site d’une entreprise.

Quelle longueur pour chaque entrée de release notes ? Deux à quatre phrases suffisent pour la plupart des entrées : le résultat, les personnes concernées et quoi faire. Un changement cassant ou un correctif de sécurité peut être plus long, car il faut une date ou une migration.

Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.

À voir sur changeloop : Modèle de release notes, Exemples de changelog