Exemples de changelog

1. Une version SaaS ordinaire

Le cas courant : une poignée de changements visibles pour l'utilisateur, aucune migration, aucun drame. C'est court parce que la version était petite, et résister à l'envie de la remplir est l'essentiel du métier.

## 20 août 2026

### Nouveautés
- Vues enregistrées dans la boîte. Épingle un filtre une fois et
  réutilise-le depuis la barre latérale.

### Améliorations
- Le job d'export indique désormais sa progression au lieu de sembler
  bloqué sur les gros comptes.

### Corrections
- Les membres invités ne voient plus un tableau de bord vide avant
  leur première connexion.

2. Une version API avec une dépréciation

Le lecteur d'un changelog d'API cherche une seule chose : si son intégration est sur le point de casser, et combien de temps il lui reste. Mets ça en haut et donne-lui une date.

## Acme API 4.2 - 20 août 2026

### Changements importants
- `?page=` est supprimé sur tous les endpoints de liste. Utilise la
  valeur `nextCursor` de la réponse précédente.
  `?page=` renverra 400 après le 1er octobre 2026.
  Étapes de migration : acme.example/docs/pagination

### Nouveautés
- Les webhooks peuvent être limités à un seul projet.

### Améliorations
- Les endpoints de liste répondent environ quatre fois plus vite sur
  les comptes de plus de 10 000 enregistrements.

3. Une version mobile

Les app stores affichent un champ de nouveautés tronqué, et la revue peut retenir une build pendant des jours. Ces deux faits façonnent l'entrée.

## iOS 3.4.0 - 20 août 2026

Mode hors ligne. Ouvre, lis et rédige sans connexion ;
tout se synchronise quand tu es de nouveau en ligne.

### Également dans cette version
- Démarrage plus rapide sur les appareils plus anciens.
- Correction d'un plantage à l'ouverture d'un lien partagé depuis Mail.

4. Une correction de sécurité

La seule entrée où en dire moins est juste. Les utilisateurs doivent savoir qu'ils doivent mettre à jour ; personne d'autre n'a besoin d'une description assez précise pour attaquer la version qu'ils n'ont pas encore mise à jour.

## 20 août 2026

### Sécurité
- Renforcement de la validation des jetons de session. Les comptes sur
  des installations auto-hébergées devraient passer à la 4.2.1 ou
  ultérieure. Signalé de façon responsable ; aucune preuve
  d'exploitation. Détails : acme.example/security/2026-08

5. À quoi ressemble une mauvaise entrée

Chaque ligne ici a une forme réelle, et chaque ligne est une erreur :

## v2.3.7

- Fusion de la PR #482 depuis feature/inbox-refactor
- Montée de lodash 4.17.20 -> 4.17.21
- Correction d'une race condition dans MembershipCache.resolve()
- Diverses corrections et améliorations
- Refactoring du modèle SavedView (merci, Dave !)

Ce que les bons ont en commun

• Ils décrivent un résultat, pas une implémentation. Quelqu'un qui n'a jamais vu le code peut quand même dire si l'entrée le concerne.
• Ils omettent des choses. Les montées de dépendances, les refactors, les changements de CI et les renommages internes sont absents, et c'est cette absence qui garde le reste lisible.
• Ils mettent en premier ce qui coûte cher. Si quelque chose casse, c'est le premier titre, avec une date.
• Ils sont datés d'une façon utile au lecteur : un numéro de version là où les utilisateurs voient des versions, une date là où ils ne le peuvent pas.
• Ils sont ennuyeux exprès. Pas de points d'exclamation, pas d'adjectifs marketing, pas de « nous sommes ravis d'annoncer ». Qui lit un changelog cherche de l'information et déteste tout ce qui se met en travers.

Questions fréquentes

Quel format un changelog devrait-il utiliser ?

keepachangelog.com est ce qui se rapproche le plus d'un standard, et les noms de ses sections (Added, Changed, Deprecated, Removed, Fixed, Security) sont largement reconnus. C'est bien moins important que la rédaction à l'intérieur des sections. Un format cohérent avec des entrées vagues est pire qu'un format libre avec des entrées précises.

À quelle fréquence devrions-nous publier ?

Au rythme qui correspond à tes versions, et avec constance. Publier par version est la règle la plus simple. Regrouper un mois de versions en un seul billet rend chaque changement individuel plus difficile à retrouver plus tard, ce qui est précisément le moment où la plupart des gens lisent vraiment un changelog.

Le changelog devrait-il vivre sur notre site ou sur une page tierce ?

Sur ton site si tu peux, car c'est là que le trafic et la valeur de recherche s'accumulent, et parce qu'un changelog sur un domaine tiers est à un lien de ton produit plutôt qu'une partie de celui-ci. C'est l'argument en faveur de le diffuser comme un flux que tu rends toi-même, plutôt qu'une page hébergée à laquelle tu renvoies.

Les gens lisent-ils vraiment les changelogs ?

Une petite partie les lit régulièrement, et une part bien plus grande les cherche au moment où quelque chose change sous leurs pieds. Ce second groupe est la raison d'écrire le symptôme plutôt que la cause : ils cherchent ce qui leur est arrivé, dans leurs propres mots.

Pour aller plus loin : Changelog vs release notes : quelle est la différence ? et Keep a Changelog, vraiment implémenté.