Étude de cas : comment cette formation a été écrite

Tu as posé des contrôles sur ton projet. Depuis, ils ne disent rien. Tu ne sais pas si c’est parce que tout va bien, ou parce qu’ils ont cessé de tourner et que personne ne s’en est aperçu. Et quand tu cherches à quoi ressemble un montage qui, lui, tient, tu trouves des principes — jamais le compte de ce qu’un dispositif réel a attrapé, ni de ce qu’il a laissé filer.

Voilà ce compte. Il est daté, tenu pendant la production, et il n’est pas flatteur. Le morceau le plus utile n’est pas un score : c’est le test qu’on a monté pour se mesurer, et qui ne mesurait rien.

Ce qui se passe vraiment

Ce qui a produit ces pages

Le projet s’est donné un nom à lui-même : la chaîne de production. Des postes, un seul travail chacun, dans un ordre fixe. Ce que le mot ne doit pas laisser croire : dans une vraie chaîne, un maillon qui casse arrête tout. Ici, non — un poste peut tourner à vide sans que rien le signale, et cette leçon raconte les trois fois où c’est arrivé. Quatre fichiers décident, et pas la même chose.

Le fichier	Ce qu’il décide	Ce qui se passe quand il a tort
Le plan	le périmètre : une leçon qui n’y est pas n’existe pas	on écrit une leçon dont personne n’a validé la raison d’être
La charte	à qui on parle, comment on écrit, ce qui reste privé	le ton dérive d’une leçon à l’autre sans qu’on sache où
Le brief de faits	les faits vérifiés, les analogies, le vocabulaire	chaque leçon qui s’y fie hérite de l’erreur
Le fichier de suivi	où on en est, et le motif de chaque décision	on refait trois fois le même arbitrage

Deux règles les relient. En cas de désaccord entre une leçon et le brief, c’est la leçon qui a tort — sinon deux versions divergent sans que personne s’en aperçoive. Et une décision de périmètre prise en rédigeant remonte dans le plan, jamais l’inverse : c’est ce qui permet de compter, des semaines plus tard, combien de fois la même erreur est revenue.

Quatre ouvriers, un seul travail chacun

Quatre postes, tenus par quatre subagents — des ouvriers isolés qui travaillent à part et ne rendent qu’un résumé (leçon 4). Un seul rédige ; les trois autres contrôlent.

• le rédacteur écrit la leçon à partir de son entrée dans le plan et ne vérifie rien : le compter comme relecteur gonflerait l’appareil d’un quart ;
• le vérificateur de faits rend quatre verdicts : faux, non vérifié, périmé, omission. Sa hiérarchie de sources a trois niveaux : un instantané local de la documentation officielle, rafraîchi chaque jour ; puis la documentation d’une bibliothèque, pour ce qui n’est pas l’outil ; puis le web, réservé au paysage et aux dates, jamais pour une affirmation technique ;
• le relecteur qui incarne le lecteur n’a le droit de rien supposer : chaque fois qu’il se dit « ça, il le sait forcément », c’est un défaut. Il ne connaît pas le projet et n’a pas lu les autres leçons — sauf celles auxquelles la leçon renvoie explicitement. Ses outils sont en lecture seule (leçon 12) ;
• l’avocat du diable part du principe que la leçon est faible et cherche ce qui la rendrait indéfendable devant quelqu’un de compétent et de mal disposé. Trois verdicts : fatal, sérieux, encaissable. Sa consigne la plus importante n’est pas d’attaquer, c’est de se réfuter lui-même avant de rendre : le bruit tue l’habitude de se faire relire.

Les deux derniers ne se voient pas, et on ne leur donne que le chemin du fichier : un relecteur à qui on explique ses intentions relit les intentions. Une exception, assumée — l’avocat du diable lit le plan et les leçons voisines, parce que détecter une contradiction entre deux leçons est impossible sans elles. Il paie ça d’un biais, et ça a payé une fois, sur deux leçons qui allaient employer la même image à l’envers.

Trois skills pour enchaîner, parce que la mémoire ne s’accumule pas

Trois skills portent l’ordre des étapes. Un skill est une fiche réutilisable : du savoir ou une procédure. La leçon 4 a dit pourquoi ce sont des skills et pas des commandes : les deux créent la même barre oblique, mais la documentation officielle désigne le skill comme le successeur recommandé.

/lecon      écrit une leçon de bout en bout : cadrer, rédiger, vérifier, faire relire, corriger, clore
/verifier   contrôle les faits, d'une leçon ou de toutes
/relire     lance les deux relecteurs en parallèle, dans un seul message

Ce que ça achète, et ce que ça garantit — la nuance est plus fine qu’on ne l’écrit d’habitude. Ça n’achète rien qu’on ne pourrait faire à la main : seulement de ne plus avoir à s’en souvenir. Et les instructions en prose d’un skill sont une demande, pas une garantie (leçon 9) : la documentation range les skills du côté où c’est le modèle qui décide de l’étape suivante. Mais un skill n’est pas que de la prose. Une syntaxe y lance une commande dont la sortie remplace la ligne avant que le modèle lise le texte : notre skill de vérification s’en sert pour afficher d’entrée la date de l’instantané de documentation. Et l’en-tête d’un skill peut déclarer des hooks, actifs ensuite pour la session. Ce qui reste vrai : l’ordre écrit retire à toi la possibilité de sauter une étape à minuit, pas au modèle.

Pour contraindre vraiment l’enchaînement, il faut un workflow, où un script tient la boucle. Réserve à connaître avant de bâtir dessus : les workflows dynamiques demandent une version minimale de l’outil et ne sont pas disponibles partout — plans payants, accès par l’API, trois plateformes d’hébergement.

Le journal : ce que ça a attrapé, et ce que ça a coûté

Ce qui suit sort du fichier de suivi, et il faut le qualifier avant de le lire : ce sont des accidents constatés, trouvés au fil de la production. Ça vaut comme journal, pas comme démonstration.

La thèse elle-même a été corrigée en route. Le critère de départ était « code depuis des années sur un projet en production ». Un contre-exemple l’a fait tomber : on peut ne pas relire le code produit et tirer énormément de ces process. Le critère est devenu « ton projet a dépassé ce que tu peux tenir dans ta tête ».

Un verdict fatal est tombé, et il n’a pas été rafistolé. Sur la page de vocabulaire, c’est la raison d’être qui tombait : ses trois arguments étaient réfutables sur les deux pages que la leçon mettait elle-même en lien. Périmètre refondu dans le plan, leçon réécrite dessus — elle a rétréci, et c’est à ça qu’on a vu qu’elle était juste. Un autre fatal a été refusé : l’avocat du diable n’a pas raison par défaut, et le fichier de suivi annonce que le motif de ce refus est consigné plus bas, où il ne l’est pas.

Et le pire n’est pas venu de la chaîne. Une relecture croisée a été lancée après coup, avec deux relecteurs de familles différentes — c’est le mot du fichier de suivi, et je n’en dirai pas plus. Elle a trouvé deux conseils faux dans une leçon déjà en ligne, dont « supprime la branche jetable et recommence » alors que les modifications non enregistrées suivent le changement de branche. Le cas a été reproduit dans un dépôt jetable avant correction. Le même passage a trouvé trois trous dans la chaîne elle-même : la catégorie « omission » du vérificateur traitée nulle part, un arrêt sur défaut fatal sans trace écrite, rien qui empêche de réécrire par-dessus une leçon déjà relue. Trois étapes pouvaient donc être sautées sans que ça se voie.

Trois revendications d’exclusivité se sont révélées fausses, le motif le plus répété : « personne ne publie ça en français », deux fois, alors que la documentation officielle existe en français ; puis un tri des tâches donné pour inédit, dont l’ossature est chez Martin Fowler et dans Getting Things Done. La quatrième a failli s’écrire dans cette page même — j’y viens.

Le défaut était dans les fichiers de pilotage, et on ne sait pas combien de fois

C’est le résultat qui m’a le plus surpris, et celui qui se transporte le mieux : plusieurs fois, ce qui était faux n’était pas dans une leçon mais dans le fichier qui sert de source de vérité aux leçons. Le fichier de suivi en numérote cinq.

1. Le brief renvoyait à d’anciens numéros de leçon, et le plan annonçait huit déclencheurs pour n’en énumérer que sept.
2. Trois erreurs de fait dans le brief, que nous y avions mises — dont « en dehors du dossier de travail, une autorisation est demandée » : vrai selon le mode d’autorisation, faux en mode automatique, où un classificateur tranche et peut approuver seul.
3. Le plan et le brief se contredisaient sur ce qui est documenté officiellement ; le plan a été corrigé.
4. La découverte la plus coûteuse du projet : la documentation officielle existe en français. Elle a rendu faux d’un coup un argument du plan et une phrase du brief enrichie le matin même.
5. Deux faits faux écrits dans le brief la veille, propagés jusque dans une leçon déjà publiée : une commande donnée pour vérifier qu’une règle est chargée et qui ne fait pas ça, et l’affirmation qu’un seul mécanisme applique vraiment une consigne. Corrigés aux trois endroits le jour même.

Cinq est un plancher, pas un total. En recomptant pour écrire cette page, j’ai trouvé deux autres corrections logées dans le brief et jamais entrées dans le décompte. Pire : le brief numérote un de ces cas « la troisième fois », alors que le fichier de suivi avait déjà donné ce rang à un autre. Le compte lui-même a bégayé. Un fichier de faits vérifiés n’est pas un fichier de faits vrais : il a l’air d’aller bien tant que personne ne le rouvre.

Le premier test qu’on a monté ne mesurait rien

Tout ce qui précède est un journal, et la leçon 13 est sans pitié avec ça : tant qu’un filet n’a pas été exercé exprès, on connaît ce qu’il a attrapé par accident, pas ce qu’il attrape. Alors la chaîne a été éprouvée. Deux fois, parce que la première ne comptait pas.

Le premier essai : une fausse leçon de 63 lignes, onze défauts plantés et consignés d’avance dans un fichier séparé, onze attrapés. L’avocat du diable a démonté le protocole en quatre points, tous justes.

• Le chemin transmis aux relecteurs contenait deux fois le mot « épreuve ». On leur a donc dit que c’en était une, et un relecteur prévenu ne relit pas la même chose.
• Le corrigé était dans le même dossier que le sujet, écrit à la même minute, avec une colonne « doit être attrapé par qui ». Les trois relecteurs savent lister un dossier et ouvrir un fichier.
• Deux des onze défauts avaient leur correction écrite dans le dépôt le matin même : les retrouver mesure la lecture d’un fichier, pas la détection d’un défaut.
• Onze sur onze est le résultat le moins informatif possible. Un score parfait sur des défauts choisis par celui qui connaît le filet ne dit pas que le filet est bon : il dit qu’ils étaient trop faciles.

Piège — celui qui monte le test connaît la réponse, et il contamine le protocole sans s’en apercevoir, par des gestes qui ressemblent à du rangement : nommer le fichier, le poser à côté du corrigé, choisir des défauts qu’il vient de corriger. Le score qui en sort est ininterprétable.

Ses trouvailles non plantées ont été gardées et revérifiées — un score nul ne rend pas fausse une découverte faite en route. Deux ont survécu, et il a fallu recadrer les deux, dont une dans cette page.

• Le double Échap n’annule pas, il ouvre un menu de retour en arrière — à condition que la zone de saisie soit vide ; sinon, il l’efface. La première version de cette page a écrit la moitié de la condition : le motif « condition à moitié énoncée » qu’elle catalogue plus haut.
• Les modifications faites par un subagent ne sont pas restaurées — le plus souvent, pas toujours. Un skill dérivé qui tourne au premier plan modifie l’arbre de travail pendant ton propre tour, et celles-là sont bien restaurées. Pour tout le reste, il faut le gestionnaire de versions.

La deuxième épreuve, montée contre son auteur

Le protocole corrigé, sur les quatre points ci-dessus : nom de fichier neutre, sans un mot qui annonce un test ; placé parmi les vraies leçons, pas dans un dossier à part ; corrigé sorti du dépôt, donc hors de ce qu’un relecteur liste en explorant — improbable à trouver, pas inaccessible : leurs outils de lecture acceptent un chemin absolu, où qu’il pointe. Et sept défauts, dont deux conçus pour survivre. Ces deux-là visaient l’angle mort supposé : un fait faux qui ne relève pas de la documentation de l’outil mais d’un gestionnaire de versions (à la date de l’épreuve, la seule cause avérée d’erreur publiée sur ce projet), puis sa propagation dans un quiz, pour voir si le contrôle recopie l’erreur du texte. La supposition n’a pas tenu une journée : le 19 août, une leçon déjà en ligne a dû être corrigée d’un fait de documentation faux, sur la taille de la fenêtre de contexte. L’angle mort n’était donc pas là où on l’avait situé. Une limite résiduelle a été comptée plutôt que camouflée : l’avocat du diable lit le plan, il pouvait s’apercevoir que la fausse leçon n’y figure pas. On en a fait le septième défaut.

Ce n’est pas une invention — c’est le quatrième faux inédit du projet, évité de justesse. Planter un nombre connu de défauts, soumettre à des relecteurs indépendants, compter la part retrouvée : ça s’appelle l’error seeding, publié par Harlan Mills en 1972. Estimer ce qui reste à partir des recoupements entre relecteurs indépendants, c’est le capture-recapture, introduit dans les inspections logicielles en 1992 et évalué depuis. Une synthèse de 2004 fait le bilan de dix ans de travaux. L’équivalent côté code s’appelle le mutation testing. Ce qui reste propre ici n’est pas la méthode, c’est le journal daté de cette production-ci.

La règle de comptage, avant le tableau, parce qu’un tableau dont les valeurs ne sont pas définies ne compte rien. oui : le relecteur nomme le défaut et donne le bon motif. partiel : il signale l’endroit sans nommer la cause. — : il n’en dit rien. Un défaut est déclaré attrapé dès qu’un seul « oui » tombe : les trois ne cherchent pas la même chose, et c’est tout l’intérêt de les avoir séparés.

Le défaut planté	Conçu pour	Vérificateur	Lecteur	Avocat
La commande d’état listerait les fichiers exclus	survivre	oui	oui	oui
Le quiz reprend la même commande fausse	survivre	oui	oui	oui
« le degré le plus fort de vérification »	attrapé	oui	oui	oui
« il ne voit pas l’historique »	attrapé	oui	—	oui
« une fenêtre vierge, sans rien de ta conversation »	attrapé	oui	partiel	oui
« élimine la plupart des fausses alertes »	attrapé	oui	oui	oui
La leçon ne figure pas dans le plan	attrapé	oui	—	oui (fatal)

Sept plantés, sept attrapés — et les deux conçus pour survivre n’ont pas survécu. Celui sur le gestionnaire de versions a été pris par les trois, et par deux d’entre eux en exécutant réellement la commande, pas en lisant. C’est le seul enseignement solide du tableau : les deux défauts les plus durs n’étaient pas assez durs, et sept sur sept ne dit rien de plus.

Les quatre trouvailles hors programme, qui valent mieux que le score

Aucune n’était plantée. C’est la part qui apprend, et la première vaut à elle seule les deux épreuves.

Le geste rend le même verdict pour le cas sain et pour la catastrophe. J’avais planté « la commande d’état ne liste pas les fichiers exclus ». L’avocat du diable ne s’est pas arrêté à la phrase : il a reproduit le cas qui compte, celui d’un fichier enregistré avant d’avoir été ajouté aux exclusions — le secret déjà dans l’historique. Là, la commande rend un écran propre, le lecteur conclut « c’est réglé » et publie son secret. C’est la définition même du filet mort de la leçon 13. Les trois autres, plus courtes :

• le relecteur qu’on fabrique saute les fichiers exclus : l’outil de recherche de contenu respecte les règles d’exclusion, celui qui liste les fichiers ne les respecte pas. Le subagent recommandé porte les deux, donc sa recherche a un trou, et rien ne le dit ;
• l’état du dépôt qu’un subagent reçoit est un instantané pris au démarrage de la session parente, pas au moment où on le lance : un relecteur délégué en fin de journée juge l’état d’il y a deux heures ;
• « un relecteur qui connaît tes intentions ne trouve rien » est réfuté par notre propre charte, qui écrit que l’avocat du diable lit le plan, et que c’est ce biais-là qui lui a permis de repérer un conflit entre deux leçons dont une n’était pas encore écrite.

Ce que la deuxième épreuve ne mesure toujours pas. Un seul essai, sur sept défauts conçus par quelqu’un qui connaît le dispositif : ils ressemblent à ce qu’il sait voir. Les deux qui devaient résister n’ont pas résisté — le jeu était trop facile. Rien sur la provenance. Un jeu plus dur reste à écrire, par un autre.

Personne ne regardait d’où venait la matière

Voilà la page la plus utile de cette étude de cas, et celle que j’aurais préféré ne pas écrire. Les trois contrôleurs ont chacun une consigne écrite, et aucune ne parle de provenance : le vérificateur contrôle si c’est vrai, pas si ça avait le droit de sortir ; le lecteur signale où il décroche ; l’avocat cherche ce qui rend la leçon indéfendable. Aucun n’a de raison de se demander d’où vient une phrase exacte, bien écrite et convaincante. L’angle mort n’est pas une négligence, il est structurel.

Et la pression était réelle. Deux fois, de la matière qui n’avait rien à faire dehors a été retirée à la main, tard : un chiffre tiré d’un audit privé écrit dans le plan, et un passage sur le système d’un tiers retiré d’une leçon avant sa mise en ligne. Une seule barrière durable a été posée : le dossier de l’audit est déclaré non versionné. La cause est dans la consigne, pas dans les relecteurs — « débrouille-toi pour trouver de la matière » : un agent obéit, sans moyen de distinguer ce qui est publiable de ce qui ne l’est pas.

Piège — la formulation qui ouvre le plus grand périmètre est celle qui a l’air la plus inoffensive. « Trouve de quoi illustrer », « prends des exemples réels », « débrouille-toi » : ce ne sont pas des demandes vagues, ce sont des ordres de fouille.

Un contrôle a pourtant mordu, et il n’est pas de nous. Trois fois dans la même journée, ce qui a arrêté la fouille n’était ni un relecteur ni une règle du projet — vérifié : le projet ne pose aucun hook ni règle de refus. C’était un garde-fou intégré à l’outil, en amont de la chaîne, et il a arrêté exactement ce que les trois relecteurs n’avaient aucune raison de chercher : d’abord des éléments d’un audit privé au-delà du périmètre autorisé, puis des dépôts clients et des données personnelles. Trois raisons de ne pas s’appuyer dessus : il n’est pas à nous, il peut changer sans prévenir, et il ne couvre que ce cas. Le compter dans son propre dispositif, c’est se croire protégé par ce qu’on ne contrôle pas.

Ces cinq épisodes sont des accidents constatés, pas des tests provoqués. Aucun ne vient de notre chaîne. Sur la provenance, ce dispositif n’a jamais été vu rougir — l’image vient de la leçon 13 : casser exprès ce qu’un filet doit attraper et le regarder protester. Tant qu’on ne l’a pas vu protester, son silence ne se distingue pas de son absence.

Ce qu’on fait

Six gestes, nés d’un projet qui produit du texte. Ceux qui ne se transposent pas tout seuls reçoivent leur version côté code : « écris une fausse leçon » ne veut rien dire pour quelqu’un dont le produit est un programme, et qui par hypothèse ne relit pas ce que l’agent écrit.

1. Séparer ce qui décide de ce qui raconte

Un fichier pour le périmètre, un pour l’état, un pour les faits, avec la règle de préséance : en cas de désaccord, c’est le texte qui a tort. Sur un projet de code, ce fichier de faits n’est pas vide non plus : la version minimale que vous supportez vraiment, le nom du champ que trois services lisent, le comportement d’une bibliothèque tierce vérifié un mardi, avec l’endroit où il l’a été. Et le fichier d’état trace les motifs, pas les cases cochées : une décision datée avec sa raison permet de voir, des semaines plus tard, que la même erreur est revenue cinq fois — et qu’on l’avait mal comptée.

2. Un relecteur, un travail, et rien d’autre que le chemin

Découpe la relecture en rôles qui ne se recouvrent pas, donne à chacun le chemin du fichier et rien d’autre, et lance-les sans qu’ils se voient. Puis le geste qui rend le dispositif tenable : exiger de l’attaquant qu’il essaie de se réfuter avant de rendre. Sans ça, la liste gonfle, tu cesses de la lire, et le dispositif meurt de la façon la plus banale — parce que plus personne ne l’ouvre.

3. Écrire l’ordre des étapes, en sachant ce que ça garantit

Pose l’ordre là où tu n’as plus à t’en souvenir, avec la priorité de traitement : ce qui est faux d’abord, puis ce qui fait tomber la thèse, puis ce qui manque, puis ce qui gêne. Mais sois exact sur ce que ça achète : une procédure écrite retire ta décision de sauter une étape, pas celle du modèle, et trois étapes ont sauté ici sans que rien ne le dise. Si l’enchaînement doit être contraint, c’est un workflow qu’il faut (leçon 15) — en vérifiant que ta version et ton plan le proposent. Et un arrêt sur défaut fatal doit laisser une trace écrite, sans quoi un cycle interrompu ne se distingue pas d’un cycle jamais tenté.

4. Nommer la matière, au lieu de dire « débrouille-toi »

Deux phrases à écrire dans le fichier de règles : d’où la matière a le droit de venir, et où elle a le droit d’aller. Une liste de dossiers autorisés vaut mieux qu’une interdiction générale, qui suppose qu’on a pensé à tout. Ces deux phrases sont du contexte, donc une demande. La barrière s’écrit dans les réglages d’autorisation : une règle de refus sur la lecture des chemins concernés, dont la leçon 8 donne les propriétés : évaluée avant tout le reste, aucune portée ne peut la lever. Et sa réserve, qu’il ne faut pas perdre en la citant : elle couvre les outils de fichiers de l’agent et les commandes de lecture qu’il reconnaît, pas un programme tiers qui ouvre les fichiers lui-même — là, seul le bac à sable bloque.

5. Un second avis d’une autre famille, et reproduire avant de corriger

Les deux conseils faux publiés n’ont pas été trouvés par la chaîne, mais par un relecteur d’une autre famille lancé après coup : cinq défauts du premier, quatre du second, un seul point commun. Donc fais relire par autre chose que ce qui a écrit : ce n’est pas une seconde couche du même filet, c’est un filet dont les mailles ne tombent pas aux mêmes endroits. Et ce qui est reproductible se reproduit avant d’être corrigé — sans quoi on remplace une affirmation non vérifiée par une autre. Côté code, ce second geste porte un nom que tu connais déjà : le test qui échoue avant la correction et passe après.

6. Planter des défauts et compter — le geste a un nom depuis 1972

Les trois trous du dispositif ne sont pas apparus en le relisant, mais en regardant ce qu’il avait laissé passer. Deux questions ouvrent le dossier — qu’est-ce que ce dispositif n’a aucune raison de chercher ?, et quelle catégorie de verdict n’est traitée nulle part ? : un rapport qui rend quatre types de défaut et une procédure qui n’en traite que trois font disparaître le quatrième sans un mot.

Puis le geste que la leçon 13 prescrit vraiment. Écris les défauts dans un fichier à part avant de soumettre quoi que ce soit ; garde ce fichier hors de l’arborescence que tu leur soumets — ça le rend improbable à trouver, pas inaccessible : un relecteur qui lit des fichiers accepte n’importe quel chemin, et seule une règle de refus sur la lecture ferme vraiment la porte, avec la réserve du geste 4 ; donne au brouillon un nom qui n’annonce rien ; passe la chaîne sans prévenir personne ; puis compte ce qui n’était pas au programme. La règle qui décide de tout n’est pas le score, c’est où est le corrigé. Et côté code, ce geste s’appelle le mutation testing : un outil injecte des fautes une par une dans ton programme, et voit combien ta suite de tests en tue. Tu n’as rien à relire, et c’est l’intérêt : le rapport dit quelles fautes ta vérification ne voit pas. Sans outil : casse à la main une condition, une valeur limite, un appel.

Ce que ça ne fait pas

Un essai ne fait pas une preuve, et l’angle mort reste entier

Rappel de ce qui précède : un seul essai retenu, sept défauts conçus par quelqu’un qui connaît le dispositif, les deux plus durs tombés quand même, rien sur la provenance. Ce n’est pas une preuve.

On ne sait pas combien de temps ça coûte

Cette section s’appelait « ce n’est pas plus rapide » et ne donnait aucune durée. Le trou est réel : aucun temps n’a été relevé sur cette production, donc rien à annoncer, ni dans un sens ni dans l’autre. Une formation qui interdit les chiffres sans source ne s’exempte pas elle-même. Ce qui a été compté, ce sont les passes : deux jets et trois relectures sur une leçon, une refonte complète après un verdict fatal, une troisième passée de 574 à 408 lignes après publication. Ce que la chaîne rend n’est pas du temps : c’est de savoir laquelle des deux phrases est vraie ce soir — « c’est juste » ou « personne n’a regardé ».

Elle ne garantit pas la justesse, et elle n’a pas trouvé seule ce qu’on lui attribue

Sur les cinq défauts de pilotage, le fichier de suivi n’en attribue que deux à un relecteur : les trois autres ressemblent à des trouvailles faites à la main pendant l’arbitrage, et leur silence ne vaut pas quitus. Elle ne décide pas non plus à la place de quelqu’un : quand un verdict fatal tombe, la procédure dit arrête-toi et remonte le problème au plan, pas « répare ». Réécrire une leçon dont la thèse est fausse produit une leçon fausse mieux écrite.

Elle ne se copie pas depuis cette page

Ce qui est ici, c’est la structure : les rôles, l’ordre, les règles de préséance, les deux protocoles d’épreuve. Le contenu des fichiers de règles, les consignes de chaque relecteur et les fichiers à reprendre restent hors du gratuit. Et seize pages écrites par une personne ne disent rien de ce que ça donnerait à cinq.

Et le porte-à-faux de cette page-ci

Sa première version a reçu un verdict fatal : tous ses chiffres étaient des accidents constatés, elle affirmait ce qu’elle prétendait démontrer. C’est ce verdict qui a fait monter l’épreuve — puis la deuxième, quand la première s’est révélée contaminée. Et il faut dire par quoi cette page est passée, parce qu’un défaut de pilotage vivant le laisse supposer : le rédacteur et la procédure qui l’appelle sont bornés aux quinze premières leçons, et personne ne les a rouverts au passage à seize. Cette page n’est donc pas sortie de la commande d’écriture : rédigée à la main, hors chaîne, puis soumise aux trois relecteurs comme n’importe quelle autre (le chemin du fichier, rien d’autre), puis corrigée. Deux fois.

Où c’est écrit

Le fond de cette leçon ne vient d’aucune page officielle : c’est le journal d’une production. Les mécanismes qu’elle emploie, eux, sont documentés — liens vers les pages anglaises, pour les raisons données en leçon 4.

• Les subagents — ce qu’un ouvrier isolé reçoit au démarrage, dont l’instantané pris au lancement de la session parente ;
• Les skills — la syntaxe qui injecte la sortie d’une commande avant que le modèle lise le texte, et le champ d’en-tête qui déclare des hooks ;
• Les workflows — qui décide de l’étape suivante, la version minimale requise et les plans où ils sont disponibles ;
• Les permissions — ce qu’une règle de refus sur la lecture couvre, et ce qu’elle ne couvre pas.

Et la méthode de l’épreuve, qui n’est pas de nous :

• Harlan Mills, On the Statistical Validation of Computer Programs, IBM Federal Systems Division, 1972 — l’error seeding : planter un nombre connu de fautes pour estimer celles qu’on n’a pas vues ;
• Petersson, Thelin, Runeson et Wohlin, Capture-recapture in software inspections after 10 years research, Journal of Systems and Software, 2004 — dix ans de mesures sur des inspections par plusieurs relecteurs indépendants ;
• DeMillo, Lipton et Sayward, Hints on Test Data Selection, Computer 11(4), 1978 — le mutation testing, l’équivalent côté code.

Ce que cette leçon ajoute : pas la méthode, qui a cinquante ans. Le journal daté d’une production précise — ce qu’un dispositif a attrapé et laissé passer, deux protocoles d’épreuve dont le premier ne mesurait rien, et l’angle mort qu’aucun de ses trois relecteurs n’était fait pour voir.

Le point de bascule

Tu as basculé le jour où, devant un dispositif qui ne t’a rien signalé, ta question n’est plus « est-ce que c’est bon ? » mais « qu’est-ce que celui-là n’a aucune raison de chercher, et qui le cherche à sa place ? ». La première n’a jamais eu de réponse. La seconde en a une — et le jour où c’est « personne », tu sais où tu en es.

Vérifier que c’est passé

Tu plantes onze défauts dans un faux document, tu passes ta chaîne de relecture, elle les attrape tous les onze. Tu es content. Qu'est-ce qui aurait dû t'alerter d'abord ?

Le score lui-même. Onze sur onze est le résultat le moins informatif possible : il est compatible avec « mon filet est excellent » et avec « mes défauts étaient trop faciles », sans permettre de trancher. Avant de lire un chiffre, on relit le protocole : le nom du fichier annonçait-il un test ? le corrigé était-il posé là où ce que je teste allait regarder ? Ici, les réponses étaient mauvaises, et l’essai a été refait.

Tu plantes une commande fausse dans un brouillon : elle prétend afficher les fichiers exclus alors qu'elle ne le fait pas. Un relecteur répond « faux, la vraie commande est celle-ci ». Il a raison. Est-ce que le sujet est clos ?

Non : c’est là que se joue la différence entre corriger et comprendre. La bonne question n’est pas « quelle est la bonne commande » mais « que donne le geste dans le cas qui compte ? ». Pour un fichier enregistré avant d’avoir été ajouté aux exclusions, la commande rend un écran propre : le même verdict pour le cas sain et pour la catastrophe. Un relecteur qui reproduit le cas trouve ça ; un qui corrige la phrase, non.

Tu délègues la recherche de matière à un agent avec la consigne « trouve des exemples réels, débrouille-toi ». Il revient avec des exemples excellents, exacts, parfaitement écrits. Qu'est-ce que tes relecteurs vont dire ?

Que c’est excellent, exact et bien écrit — et ils auront raison. C’est le problème : une consigne large n’est pas une consigne floue, c’est une autorisation étendue, et un agent va chercher la matière là où elle est. Aucun relecteur de contenu ne se demande d’où sort une phrase convaincante. Le tri n’existe que si tu l’écris : d’où la matière a le droit de venir, où elle a le droit d’aller — puis une règle de refus sur la lecture (leçon 8), qui ne couvre pas un programme ouvrant les fichiers lui-même : là, c’est le bac à sable.

Ce que tu as en main

Seize leçons, et une seule idée qui les traverse : tu n’as pas besoin de relire pour vérifier, mais tu as besoin de quelque chose qui vérifie à ta place — et de savoir si cette chose est encore en vie.

Ce que tu as monté au fil du parcours, si tu as fait les gestes plutôt que de les lire :

• une demande qui exige sa preuve, et le réflexe de regarder ce qui a été touché (leçon 2) ;
• un parcours de vérification écrit avant de demander, pas après avoir vu le résultat (leçon 10) ;
• une liste de travail qui te dit ce qui court et ce qui est armé, pas ce qui te culpabilise (leçon 11) ;
• un second regard qui n’a pas fait le travail et à qui tu n’as pas raconté tes intentions (leçon 12) ;
• et l’habitude d’exercer un filet au lieu de le relire, parce que le silence ne prouve rien (leçon 13).

Cette semaine, une seule chose. Prends le dispositif auquel tu fais le plus confiance, celui dont tu n’as pas eu de nouvelles depuis le plus longtemps, et casse quelque chose exprès pour voir s’il rougit. Si tu ne devais garder qu’un geste de ces seize leçons, c’est celui-là : c’est le seul qui distingue un filet d’un souvenir de filet.

Et si rien ne rougit, tu viens d’apprendre la chose la plus utile du parcours, au meilleur moment possible.