J'ai relu un texte, je l'ai marqué bon à partir, et ce n'est pas ce texte qui est parti. Rien n'avait cassé. La chaîne faisait exactement ce pour quoi elle avait été construite : entre mon accord et l'envoi, un dernier module repassait le contenu dans un modèle pour « améliorer » la formulation. Ma relecture n'avait servi à rien, et je ne l'ai découvert qu'en lisant le résultat publié.
Le point de non-retour
Dans toute chaîne qui produit quelque chose vers l'extérieur — un post, un mail, un devis, une réponse client — il existe un instant précis où un humain dit oui. Appelle-le le point de validation. La règle qui en découle est courte :
Après le point de validation, plus rien ne doit pouvoir modifier le contenu. Transporter, formater, horodater, archiver : oui. Reformuler, compléter, corriger : non.
Ce n'est pas une question de goût. C'est ce qui donne un sens à ta signature. Si une étape postérieure peut encore réécrire, tu n'as pas validé un contenu, tu as validé une intention — et c'est la machine qui a le dernier mot sur ce qui sort sous ton nom. La nuance paraît mince tant que rien ne dérape. Elle devient énorme le jour où un client lit une phrase que tu n'as pas écrite.
Trois façons de vider une validation de son sens
La réécriture en aval. C'est mon cas. Un module d'« amélioration » placé juste avant l'envoi, par confort au moment de la construction, et qui transforme chaque relecture en théâtre. Variante fréquente : la chaîne ne stocke pas le texte validé, elle le régénère à l'envoi à partir du même prompt. Le modèle n'est pas déterministe, donc ce n'est jamais tout à fait le même texte.
Le mauvais état déclencheur. La validation existe, quelqu'un la fait, mais la chaîne se déclenche sur un autre signal — une date, une arrivée dans une base, un statut voisin. Elle finit par envoyer des éléments que personne n'a ouverts, ou par renvoyer ce qui était déjà parti. Techniquement elle fonctionne. Elle ne lit simplement pas la décision humaine.
La validation par échantillon. Tu relis trois éléments sur quarante, tu trouves les trois corrects, tu valides le lot. Tu n'as pas validé quarante contenus, tu as estimé une probabilité. Pour un envoi massif à des clients, c'est une approche risquée qu'il vaut mieux assumer explicitement — en pilote sur un sous-ensemble réel — plutôt que de la laisser passer pour une relecture.
Quatre conditions pour qu'une validation tienne
- Le contenu validé est stocké tel quel, et c'est cet enregistrement qui est envoyé. Jamais une régénération, jamais une recomposition à la volée.
- L'état de validation est explicite et c'est lui qui déclenche. Un statut, une case, un champ : une valeur qu'un humain seul peut poser, et que la chaîne lit comme sa condition de départ.
- L'envoi n'est pas rejouable. Une marque d'envoi vide avant, remplie après — identifiant, URL, horodatage — et un déclencheur qui exige qu'elle soit vide. Sans ça, un passage de trop republie tout.
- La trace permet la comparaison. On doit pouvoir mettre côte à côte ce qui a été validé et ce qui est sorti. C'est la seule manière de détecter une dérive comme la mienne autrement qu'au hasard d'une lecture.
Un effet de bord agréable de ces quatre points : la chaîne devient débogable. Quand un contenu part de travers, tu sais immédiatement si le problème est avant ou après le point de validation, et tu relances une étape sans tout rejouer.
Le brouillon vit dans ton outil, pas dans le canal
La question qu'on me pose ensuite est toujours la même : où relire, concrètement ? La réponse qui marche le mieux chez moi, c'est de ne pas chercher à déposer un brouillon dans l'outil de publication. La plupart des API ne savent pas le faire, et quand elles le savent, tu te retrouves avec deux endroits où le même contenu existe dans deux versions.
Le brouillon vit dans la base de contenu, là où la chaîne l'a déposé. Le changement de statut est le bouton d'envoi. Un seul endroit à relire, un seul geste qui engage, et ce geste reste le mien. C'est exactement le même principe que le brouillon de mail préparé par un agent : tout est prêt, l'envoi reste humain.
Où mettre l'IA, alors
En amont du point de validation, elle a toute sa place, et c'est là qu'elle fait gagner du temps : rédiger une première version, en proposer trois, classer, résumer, préparer un dossier, signaler ce qui manque. Plus elle travaille tôt, plus elle est utile, parce que tout ce qu'elle produit passe encore sous un regard.
En aval, elle ne sert à rien que tu veuilles. Ce qui reste à faire après ton accord, c'est de la plomberie : appeler une API, respecter un format, écrire une date, mettre un statut à jour. Des tâches déterministes, qui ont besoin de fiabilité et pas d'intelligence. Mettre un modèle à cet endroit, c'est ajouter de l'imprévisible exactement là où tu venais de fixer les choses.
Le test de demain matin
Prends ta chaîne la plus automatisée et réponds à une seule question : entre le moment où je dis oui et le moment où ça sort, qu'est-ce qui peut encore changer le contenu ?
Liste les étapes, une par une, sans en excuser aucune. Si la réponse n'est pas « rien », tu sais déjà quoi déplacer en amont et quoi supprimer. Et si tu ne sais pas répondre, c'est que ta chaîne a grossi sans que personne ne redessine ce point — c'est le cas le plus courant, et le plus facile à corriger tant que rien n'est encore parti de travers.