Une session qui n'a pas lu refait les erreurs déjà payées

Une équipe d'agents produit vite. Elle refait aussi vite les erreurs déjà payées — parce que rien ne l'oblige à lire ce qui a été écrit avant elle. Voici comment une seule règle a rattrapé une catastrophe qui n'avait laissé aucun signe.

Le problème n'est pas la mémoire, c'est la lecture

Sur la tour, tout est écrit. Les articles disent ce qu'on a compris. Les compétences disent comment on travaille. Les cahiers de tests disent quelle preuve on exige. Les règles disent ce qu'on ne contourne jamais.

Et pourtant, une session qui démarre ne lit rien de tout ça. Elle lit la demande, et elle se met au travail. C'est exactement là que naissent les erreurs qui reviennent : pas par manque d'intelligence, par manque de lecture.

J'ai dû le redire quatre fois dans une seule journée : « va lire les articles des tests », « lis encore l'autonomie », « et les garde-fous lis », « va lire les articles sur les circuits ». Quatre demandes pour une seule chose : ne pas travailler à côté de ce qui est déjà écrit.

Ce qu'une session a fait, faute d'avoir lu

Ce matin-là, une session répare une trentaine de pages du site. Le travail est bon : le menu des langues remarche, chaque réparation est prouvée dans un vrai navigateur, aller et retour. Elle annonce le résultat avec ses chiffres.

Elle a réparé directement en production.

Or il existe, sur ce site, un article qui dit exactement pourquoi c'est faux : un correctif qui ne passe pas par l'essai n'est pas terminé. La production n'est pas l'endroit où l'on écrit — c'est une copie de l'endroit où l'on écrit. Une réparation faite du mauvais côté est effacée à la publication suivante, sans message, sans trace, souvent des jours plus tard quand plus personne ne fait le lien.

Cet article était en ligne. Personne ne l'avait relu.

Le chiffre que la lecture a fait apparaître

La compétence a été écrite dans la foulée. Son premier travail a été de lire les articles sur les circuits — quatre minutes. Elle en a sorti une règle : on ne réécrit pas la production à la main, jamais, même pour une ligne.

Il a suffi alors de poser une question que personne n'avait posée : que détruirait la prochaine publication ? La réponse se mesure en une commande, qui simule la copie sans rien toucher.

Ces onze fichiers, c'était un site entier : sa porte, son parcours, sa salle des agents, ses images. Une page de démonstration technique, construite pour être montrée à des recruteurs. Elle n'aurait pas été abîmée : elle aurait disparu. Et son absence ne se serait vue que le jour où quelqu'un aurait cliqué sur le lien.

Après réparation — remettre au bon endroit ce qui n'existait qu'en production — le même contrôle donne 61 fichiers, tous de vieilles copies de sauvegarde. Aucun danger.

Les cinq endroits, toujours les cinq

La compétence ne construit rien. Elle lit, elle range, elle rend la main. Elle cherche dans cinq endroits, et aucun n'est optionnel :

• Les articles publiés — ce qui a été compris et rendu public.
• Les compétences — la méthode déjà écrite.
• Les spécifications — ce qu'une compétence autorise vraiment.
• Les règles qui priment — ce qu'on ne contourne jamais.
• Les cahiers de tests — la preuve déjà exigée sur ce sujet.

Elle cherche par le contenu, pas par le nom du fichier. Un article sur les tests peut s'appeler « Tuer un tunnel ne suffit pas ». Un nom de fichier ne dit pas ce qu'un texte a compris.

Puis elle rend trois choses, et rien d'autre : ce qu'elle a lu, les règles qui s'appliquent à cette tâche précise, et — la partie que tout le monde oublie — ce que ça interdit de faire.

Ce que ça change

Une session qui n'a pas lu improvise une méthode. Une session qui a lu applique une doctrine. La différence ne se voit pas dans le code produit : elle se voit dans le nombre de fois où il faut répéter la même chose.

Il reste une chose que la lecture ne remplace pas. Un texte dit ce qu'on a compris ; il ne dit pas ce que la machine fait en ce moment. Lire avant d'agir, oui — mais mesurer avant de conclure, toujours.