Une entrée du changelog décrit une modification confirmée : version, date effective, utilisateurs concernés, comportement avant et après et action requise. Ce modèle concerne une fonction déjà déployée, pas le premier lancement.
Réunir les faits d'une modification
Confirmez avec le responsable le nom de la fonction, l'identifiant de version, le moment réel du déploiement et les utilisateurs concernés. Une date prévue n'est pas une date effective. Si l'accès est limité, nommez le groupe.
Le ticket interne aide à retrouver une décision mais ne remplace pas une description pour les clients. Le texte doit se comprendre sans notes internes.
Noter version et date
Utilisez l'identifiant adopté par le produit, sans inventer un numéro. Si le produit suit SemVer, interprétez ses composants selon ses règles et son API publique déclarée. D'autres systèmes peuvent avoir un autre sens.
Écrivez une date sans ambiguïté, par exemple YYYY-MM-DD, avec fuseau si l'heure importe. La date de rédaction peut différer. Pour un déploiement progressif, indiquez début et couverture actuelle.
Expliquer avant et après
Décrivez le comportement observable avant et après, le public, les limites et les étapes nécessaires. Si aucune action n'est nécessaire, dites-le.
Une modification de filtre ne prouve pas une hausse des ventes ni un temps économisé. Ne revendiquez que des effets vérifiés. Les prix et la facturation restent dans leur documentation.
Exemple d'une entrée
Cet exemple fictif ne décrit pas une version de Semly.
- Fonction : filtrage d'une liste de documents.
- Version : 2.4.1 selon la numérotation du produit illustratif.
- Date effective : 2026-10-12.
- Avant : sélectionner un second filtre supprimait le premier.
- Après : la liste applique les deux filtres sélectionnés.
- Portée : utilisateurs de la liste dans la version 2.4.1.
- Action : actualiser la liste ouverte après la mise à jour.
- Limite : les modèles de filtres enregistrés ne changent pas.
La limite évite des suppositions sur les modèles. Dans le cas réel, ajoutez un lien vérifié vers la documentation. Si elle manque, décrivez l'étape sans inventer d'URL.
Vérifier avant l'enregistrement
Comparez version, date, portée et comportement à la confirmation de l'équipe. Contrôlez l'action et les liens.
Un lecteur ignorant le ticket doit savoir ce qui a changé et quand. Des fonctions indépendantes ont des entrées distinctes dans la version ; la même modification ne nécessite pas plusieurs articles.
Préserver le sens dans les traductions
Conservez identifiant, moment, public et limites. Une autre langue ne confirme pas un accès dans un autre marché.
Lors d'une correction éditoriale, gardez la date réelle de déploiement et signalez séparément la correction du texte. Ce n'est pas un nouveau déploiement.
Source sur la numérotation
SemVer concerne une API publique déclarée. Il n'est pas obligatoire pour toutes les applications SaaS.
