Que retient un client d’une ligne comme « Correction d’une condition de course dans la mise en cache des requêtes meta » ? Rien d’exploitable pour lui, et pourtant cette phrase est parfaitement légitime dans un changelog technique. Le problème n’est pas la précision de la ligne, mais son destinataire : un client qui ne lit jamais de code a besoin d’un tout autre document, avec un tout autre vocabulaire.
Beaucoup d’agences et de développeurs indépendants envoient le même document aux deux publics, en espérant que le client survolera les termes techniques sans s’y attarder. Dans la pratique, cela produit l’effet inverse : le client se sent exclu d’une information qui le concerne pourtant directement, puisqu’elle décrit une modification apportée à son propre site.
Deux documents, deux objectifs distincts
Le changelog technique sert à l’équipe de développement : il trace précisément ce qui a changé, dans quel fichier, pour quelle raison, avec quel niveau de risque de régression. Le résumé client sert un objectif différent : rassurer, informer d’un bénéfice concret, signaler une action éventuelle à effectuer de son côté. Vouloir fusionner les deux revient à sacrifier l’un des deux objectifs.
Traduire une ligne technique en langage client
| Ligne technique | Formulation client |
|---|---|
| Correction d’une condition de course dans la mise en cache des requêtes meta | Correction d’un bug rare qui pouvait ralentir l’affichage de certaines pages |
| Ajout d’un index sur la colonne date_creation de la table réservations | Amélioration de la rapidité des recherches dans les réservations |
| Mise à jour de la dépendance vers PHP 8.0 pour la compatibilité serveur | Mise à jour technique nécessaire pour rester compatible avec les futurs hébergements |
| Correction d’un échappement incorrect dans le formulaire de contact | Renforcement de la sécurité du formulaire de contact |
Checklist avant l’envoi du résumé client
- Chaque ligne décrit-elle un effet perçu par le client, pas une cause technique ?
- Le vocabulaire évite-t-il tout terme réservé aux développeurs (variable, requête, cache, condition de course) ?
- Une action est-elle demandée au client ? Si oui, est-elle formulée en premier, pas noyée dans la liste ?
- Le résumé tient-il en moins d’une dizaine de lignes, lisible en moins d’une minute ?
- Un correctif de sécurité important est-il signalé sans détailler la faille elle-même, pour ne pas exposer le mécanisme exploité ?
L’erreur à ne pas commettre : trop en dire sur une faille corrigée
Un cas mérite une attention particulière : quand une mise à jour corrige une faille de sécurité, le résumé client doit signaler qu’un correctif de sécurité a été appliqué, sans en détailler le mécanisme technique exact. Un attaquant qui consulterait ce résumé ne doit pas y trouver d’indice exploitable sur des sites qui n’auraient pas encore appliqué la mise à jour.
Un exemple complet de résumé client
Mise à jour du 9 octobre : votre site est plus rapide sur les pages de réservation, un correctif de sécurité a été appliqué sur le formulaire de contact, et la compatibilité avec les futures versions de votre hébergement a été assurée. Aucune action n’est nécessaire de votre part.
Conserver le changelog technique en parallèle
Le résumé client ne remplace jamais le changelog technique : il en est une traduction sélective, orientée vers ce qui concerne réellement le client. Le changelog technique complet reste indispensable pour l’équipe de développement, en cas de régression à investiguer plus tard, ou pour retrouver précisément quelle version a introduit quel changement.
Pour aller plus loin
Séparer clairement ces deux documents demande un peu de discipline supplémentaire à chaque mise à jour, mais évite un malentendu fréquent : un client qui pense que « rien n’a changé » simplement parce qu’il n’a rien compris au changelog qu’on lui a transmis tel quel. Un résumé bien écrit, même bref, entretient une relation de confiance bien plus efficacement qu’un document technique envoyé par habitude.
