Un journal des modifications n'est pas un récit

Un journal des modifications et un récit de version ne font pas le même travail, même s'ils parlent de la même livraison. Le journal dit ce qui a changé, dans quelle version, à quelle date. Le récit dit ce que cela change pour la personne qui s'en sert, et ce qu'elle doit faire autrement, s'il y a quelque chose à faire. Quand vous les fondez, vous obtenez un texte trop long pour être consulté, et trop flou pour servir d'archive. À deux dans un studio, la confusion coûte du temps : l'un croit avoir prévenu, l'autre ne retrouve pas le fait. Tenez les deux documents. Ils peuvent se citer. Ils ne se remplacent pas.

Le lecteur du journal n'est pas toujours le lecteur du récit. Le premier peut être vous-même dans six mois, ou la personne qui reprend le support un lundi où vous êtes absent. Le second est souvent quelqu'un qui n'a pas demandé une version, et qui veut savoir si son geste habituel tient encore. Écrire pour les deux en même temps pousse au pire des tons : assez technique pour perdre le client, assez vague pour ne rien garantir. Décidez, avant la livraison, lequel des deux textes sort. Parfois un seul suffit. Quand un comportement change, les deux sont dus, et le récit doit pointer vers le journal, pas le recopier en plus joli.

Cas : une correction de formulaire, dite deux fois

Le formulaire de contact envoyait les messages au mauvais champ. Le journal technique dit : « corrige le mapping du champ reply-to ». Le texte pour les lecteurs dit : « les messages envoyés mardi entre 9 h et 11 h peuvent ne pas avoir la bonne adresse de réponse. Écrivez de nouveau si vous n’avez pas eu de retour. » Vous publiez les deux. Le journal reste court. Le récit dit ce que la personne doit faire. Aucun des deux ne raconte la journée de l’équipe.

Modèle à copier : la même correction, dite deux fois

• Journal : « 2026-10-26 — corrige le champ reply-to du formulaire. »
• Pour le lecteur : « Les messages envoyés mardi entre 9 h et 11 h peuvent avoir la mauvaise adresse de réponse. Écrivez de nouveau si vous n’avez pas eu de retour. »
• Ni l’un ni l’autre ne raconte la journée de l’équipe.

Savoir pour qui vous écrivez

Nommez les deux lecteurs sur un papier, pas dans le texte publié. Le premier cherche une trace : quelle version, quel jour, quel effet visible, quelle rupture. Il accepte des phrases sèches. Le second cherche une consigne : est-ce que j'ouvre encore le même menu, est-ce que mon export tient, est-ce que je dois agir avant jeudi. Il n'a pas à connaître le nom interne d'un module. Si vous ne savez pas qui lira, vous écrirez un mélange. Posez la question à voix haute avec l'autre personne du studio. L'une tient souvent le journal parce qu'elle a fait la modification. L'autre tient souvent le récit parce qu'elle parle aux gens qui s'en servent. Les deux rôles peuvent tourner. Ils ne se confondent pas dans le même paragraphe.

Un enregistrement du dépôt n'est ni l'un ni l'autre. Il parle à la personne qui relira le code, avec des noms de fichiers et des raisons locales. Le copier dans le journal publie une langue que le lecteur extérieur ne peut pas vérifier, et que vous-même oublierez. Traduisez. « Correction d'un pointeur nul dans l'export » devient « l'export PDF ne coupe plus la dernière ligne d'une note ». Le fait reste. Le décor interne disparaît. Si vous n'arrivez pas à traduire, demandez-vous si le changement mérite une ligne publique. Beaucoup de ces enregistrements n'en méritent pas. Les regrouper en silence n'est pas un mensonge, tant que vous ne cachez pas une rupture sous ce silence.

Ce que le journal doit pouvoir prouver

Une entrée de journal tient en peu de champs, toujours les mêmes. La version, écrite comme vous la nommez vraiment auprès des gens. La date du jour où cette version est devenue celle qu'ils peuvent obtenir, pas la date du premier essai interne. Une classe de changement : ajout, correction, ou rupture. Puis une phrase qui dit le fait observable. Pas de slogan au-dessus. Pas de remerciement pour la patience des utilisateurs, qui n'archive rien. Si vous devez expliquer pourquoi vous avez choisi cette voie, ce pourquoi appartient au récit, ou à une note de conception rangée ailleurs. Le journal qui justifie devient un plaidoyer. Dans un an, vous voudrez le fait, pas la plaidoirie, et la plaidoirie aura vieilli plus vite.

Gardez l'ordre le plus utile pour une recherche : les ruptures d'abord, puis les corrections, puis les ajouts. Une personne qui arrive inquiète ne doit pas traverser trois paragraphes d'améliorations avant d'apprendre que son ancienne adresse ne répond plus. Numérotez ou datez de façon monotone. Les noms de version poétiques sont un luxe si la date est absente. À deux, mettez-vous d'accord sur un seul endroit où le journal vit : une page du produit, un fichier dans le dépôt que vous acceptez de montrer, pas les deux en désaccord. Quand ils divergent, aucun n'est une archive. L'autre personne doit pouvoir ajouter une entrée sans réinventer le modèle. Un modèle de quatre lignes, copié, bat un bel exemple que personne n'ose toucher.

• Version, date de mise à disposition, puis les faits.
• Ruptures en tête, corrections ensuite, ajouts en dernier.
• Une phrase observable, sans nom de fichier interne.
• Un seul endroit fait foi quand deux copies existent.

Ce que le récit a le droit de raconter

Le récit commence par la conséquence, pas par votre effort. Si rien ne change pour la personne qui s'en sert, vous pouvez vous taire, ou écrire une ligne : rien à faire de votre côté. Le silence est parfois plus respectueux qu'un billet qui raconte vos nuits. Quand quelque chose change, dites le geste. Où cliquer, ce qui disparaît, ce qui remplace, à partir de quand. Un récit utile tient souvent en un écran. S'il en faut trois, vous êtes peut-être en train d'écrire le journal une seconde fois, avec des adjectifs. Coupez tout ce qui ne modifie pas une action. Gardez une seule métaphore si elle éclaire, puis revenez au concret. Le lecteur est là parce qu'un écran ne fait plus ce qu'il faisait hier.

Dites aussi ce que vous ne savez pas encore, si cela évite une fausse certitude. Un export peut rester lent sur les très longs documents : si vous ne l'avez pas mesuré chez eux, ne promettez pas un temps. Décrivez la limite que vous connaissez. « Nous avons vérifié des notes d'une dizaine de pages. Au-delà, dites-nous ce que vous voyez. » C'est un récit honnête. Il ne chiffrera pas une amélioration que vous n'avez pas constatée. Évitez les pourcentages de satisfaction, les classements, les « la plupart des gens ». Vous n'en avez pas besoin pour expliquer un bouton. Si un choix a un coût, nommez-le. Un menu plus simple qui cache une option ancienne est une nouvelle, pas seulement une bonne nouvelle.

Tenir une entrée que l'on copie

Écrivez l'entrée pendant que le changement est frais, pas la veille de l'annonce, de mémoire. Une forme fixe aide. Première ligne : version et date. Lignes suivantes : la classe, puis le fait. Par exemple, une correction dit que l'export PDF garde la dernière ligne d'une note. Une rupture dit que l'ancienne adresse des notes n'est plus acceptée, que les appels passent par la nouvelle, et qu'aucune conversion silencieuse n'est faite. Vous n'avez pas à inventer un style à chaque fois. La monotonie est une politesse envers le futur lecteur, y compris vous. L'autre personne du studio relit avant publication, non pour embellir, mais pour vérifier qu'un fait observable est bien un fait, et qu'aucune rupture n'a été classée par erreur parmi les corrections, là où personne ne la cherchera.

Rangez les entrées de la plus récente à la plus ancienne, et ne réécrivez pas l'histoire quand vous avez honte d'une ancienne formule. Vous pouvez ajouter une ligne datée : précision du 3 avril, l'ancienne adresse a été coupée pour de bon. Vous ne changez pas la phrase du 2 mars pour faire comme si vous l'aviez toujours su. Un journal modifié sans trace n'est plus un journal. Si une entrée était fausse, dites-le dans une entrée nouvelle, avec la date de la correction. Cette rigueur paraît excessive les semaines calmes. Elle devient le seul fil quand un client affirme que « ça marchait avant » et que vous devez répondre sans reconstruire le passé à deux voix différentes.

1. Copier le modèle : version, date, classe, fait observable.
2. Placer toute rupture avant les corrections de la même version.
3. Faire relire par l'autre personne avant de publier.
4. Corriger une erreur par une nouvelle ligne datée, sans réécrire le passé.

Ne pas ensevelir une rupture sous le ton

Une rupture de compatibilité n'est pas une amélioration qui s'ignore. Si un ancien geste échoue, le mot rupture, ou une formule aussi nette, doit apparaître dans la première ligne que l'œil croise. Un ton enjoué autour, des remerciements, une liste de petites nouveautés au-dessus : tout cela ensevelit. Vous pouvez être courtois sans être flou. « À partir du 12 mars, l'adresse ancienne renvoie une erreur. Voici la nouvelle. Voici ce que nous ne convertissons pas. » La personne concernée peut être agacée. Elle peut agir. L'agacement sans consigne est pire, et c'est ce que produit un récit qui célèbre la simplicité pendant que le journal, trois clics plus loin, avoue la coupure. Mettez la coupure dans les deux, avec le même vocabulaire, le même jour.

Les corrections liées à un accès indu se disent avec la même netteté, et avec une retenue sur le procédé. Dites qu'une mise à jour ferme un accès qui permettait, dans un cas précis, d'atteindre une donnée qui n'était pas la sienne. Dites qu'il faut mettre à jour, et à partir de quelle version. Ne décrivez pas les étapes qui reproduiraient le problème. Le journal n'est pas un mode d'emploi pour qui chercherait à recommencer. Le récit, lui, dit seulement le geste demandé : mettre à jour, se reconnecter, ne rien changer d'autre. Si vous ne savez pas encore qui a été touché, ne fabriquez pas un bilan. Dites que vous n'avez pas de liste fiable, et ce que vous faites pour le savoir.

Lier le récit au journal sans les fondre

Le récit peut tenir en un paragraphe sur la page d'accueil du produit, ou dans le message que vous envoyez vraiment. Sa dernière ligne pointe vers l'entrée de journal, avec la version et la date, pas vers un dossier entier où il faudrait chercher. Le journal, en retour, peut porter un lien « ce que cela change pour vous » quand le geste n'est pas évident. Ce lien ne recopie pas le récit. Il y mène. Ainsi, celui qui veut le fait reste dans la liste. Celui qui veut la consigne sort vers le récit, puis revient. Si vous ne liez rien, les deux textes dérivent : le récit parle d'une version que le journal n'a pas encore, ou l'inverse, et la personne absente ne sait plus lequel croire.

Décidez aussi de ce qui ne sera jamais public. Les essais internes, les fausses pistes, les noms de clients, les détails d'une panne qui exposeraient des données : cela vit dans une note privée, pas dans le journal affiché. La note privée peut être plus bavarde, puisqu'elle ne sert que vous deux. Elle ne doit pas contredire le public. Si le privé dit qu'une rupture est grave et le public dit que tout est plus simple, vous avez un problème de texte, pas de communication. Alignez-les. Le privé peut ajouter le contexte que le public tait. Il ne peut pas inverser le fait. Une fois par mois, ouvrez les deux côte à côte. Cinq minutes suffisent à voir une version annoncée sans entrée, ou une entrée sans récit alors qu'un geste a changé.

Une cadence qu'une équipe de deux peut tenir

N'écrivez pas à chaque enregistrement, vous abandonnerez. Écrivez quand une version devient celle que quelqu'un d'autre peut rencontrer : une mise en ligne, une livraison, un correctif que vous demandez d'installer. Entre ces moments, une liste brouillon dans le dépôt suffit, une ligne par fait, sans prose. Le jour de la publication, vous transformez le brouillon en entrées selon le modèle, vous triez les ruptures, vous décidez s'il faut un récit. Cette transformation est un travail, prévoyez-la dans l'heure de livraison, pas « quand on aura le temps ». À deux, celui qui n'a pas écrit le code relit. Il voit mieux les phrases que lui-même ne comprendrait pas. S'il ne comprend pas le fait, le lecteur extérieur non plus. Réécrivez la ligne.

Tenez cette cadence même les semaines pauvres. Une version sans rupture et sans changement visible peut avoir une entrée d'une ligne : mises à jour internes, rien à faire de votre côté. Cette ligne-là a de la valeur. Elle empêche le trou qui fait croire qu'une version a été oubliée, ou qu'un problème ancien date d'aujourd'hui. Elle vous entraîne à ne pas dramatiser. Les semaines riches, résistez à l'envie d'un récit pour chaque ajout. Un seul récit, en haut, peut dire : trois corrections, rien à changer dans vos gestes, et une rupture détaillée ci-dessous. Le journal porte le détail. Vous n'avez pas besoin d'une voix nouvelle à chaque fois. Vous avez besoin que, dans un an, l'un de vous deux retrouve la date sans appeler l'autre. C'est le test. S'il échoue, le texte était un souvenir, pas un journal.

La prochaine livraison peut rester petite. Copiez le modèle, écrivez la version et la date, mettez la rupture en premier s'il y en a une, faites relire la ligne par l'autre personne. S'il faut un récit, qu'il dise le geste et qu'il pointe vers cette entrée, sans la répéter en plus long. Vous n'aurez pas l'impression d'avoir écrit quelque chose de mémorable. C'est bon signe. Dans six mois, cette monotonie sera le seul texte encore vrai, alors que le récit d'humeur aura été oublié, et c'est précisément pour cela que vous l'aurez tenu à part, propre, et facile à continuer quand la semaine sera moins calme.