Le relecteur qui ne sait rien de tes intentions

Tu as demandé une modification, tu t’en es servi, ça fait ce que tu voulais. L’écran affiche la bonne valeur, le parcours que tu avais écrit à la leçon 10 passe en entier. Il est tard, la question suivante attend, et tu passes à la suite.

C’est légitime, et la leçon 10 t’a donné le droit de le faire. Le problème tient dans la phrase elle-même : tu as vérifié ce que tu voulais. Ce qui a été écrit à côté de ce que tu voulais n’a encore été regardé par personne.

Ce qui se passe vraiment

Celui qui a suivi le travail ne peut plus le voir

Ce n’est pas une question de compétence, c’est une question de position. La documentation le dit dans les termes les plus simples : un contexte neuf améliore la relecture parce que Claude ne sera pas biaisé en faveur du code qu’il vient d’écrire.

Le mot « contexte » a été posé à la leçon 3 : le plan de travail, tout ce que la session a sous les yeux à cet instant. Un contexte neuf, c’est un plan de travail vide. Le relecteur qui y démarre ne voit que la modification et les critères qu’on lui donne, pas le raisonnement qui a produit cette modification — donc il évalue le résultat à ses propres conditions. C’est l’ouvrier isolé de la leçon 4, qui travaille à part et ne rend qu’un résumé. Ici, cette isolation n’est pas une économie de place, c’est tout le dispositif : ce qu’il n’a pas reçu est exactement ce qui l’aurait convaincu d’avance.

L’image retenue pour ce rôle est celle de l’avocat du diable : le relecteur payé pour trouver que c’est mauvais. S’il ne trouve rien, alors seulement on y croit. Et elle porte sa limite dans le même mouvement — il n’a pas raison par défaut, et c’est sur cette confusion-là que meurent la plupart des dispositifs de relecture.

Ce qu’il ignore, c’est ta conversation — pas tes règles écrites

Le titre de cette leçon est une promesse à moitié tenue. Le contexte de départ d’un relecteur lancé comme subagent contient son propre prompt système (pas celui, complet, de Claude Code), le message de délégation que Claude compose pour lui, et tous les fichiers CLAUDE.md de la hiérarchie. N’y arrivent jamais : l’historique de la conversation, les fichiers déjà lus, les skills déjà invoqués.

Conséquence directe, et elle est mesurable sur nous. Le fichier de règles de la chaîne qui produit ces leçons porte la thèse, l’audience visée, la charte de rédaction, et jusqu’à la phrase « on n’explique jamais nos intentions à un relecteur ». Le relecteur censé ne rien recevoir la lit quand même. Ce n’est pas contournable par réglage : aucun champ ne permet de choisir quels agents sautent les CLAUDE.md, et la leçon 6 a posé la seule exception qui existe — Explore et Plan, qui ne sont pas des relecteurs.

Ce que le contexte neuf t’achète, c’est l’ignorance de ta conversation : les hésitations, les arbitrages, les « fais simple pour l’instant ». Pas l’ignorance de ce que le projet a écrit sur lui-même. Retiens la ligne, elle sert au geste 2 : ce qui a été écrit avant le résultat est un critère ; ce qui s’explique après coup est une justification.

Piège — depuis la version 2.1.232, en session interactive, Claude peut lancer un fork : un subagent qui hérite de toute la conversation au lieu de partir à neuf. Même prompt système, mêmes outils, même modèle, même historique. La leçon 6 a introduit le mot dans ce sens-là. C’est littéralement le relecteur qui connaît tes intentions, et le mode est actif par défaut. Deux choses limitent le risque : Claude n’obtient un fork que s’il demande ce type ; sans type demandé, il obtient le subagent général, qui part à neuf. Et les forks en cours apparaissent dans un panneau sous ta zone de saisie, une ligne par fork. Pour la certitude, nomme l’agent au lieu de laisser choisir : @ puis le nom de ton subagent, ou /code-review, dont la documentation dit qu’elle tourne dans un subagent à contexte isolé. Tu peux aussi poser "Agent(fork)" dans le tableau deny de .claude/settings.local.json, au sens de la leçon 8. Attention au mot lui-même. Dans la documentation des skills, context: fork désigne l’inverse exact : une exécution isolée, sans accès à l’historique. Deux pages, deux sens.

Le moment manquant

Le système d’alerte pour écoles audité en juillet 2026, celui dont la leçon 6 raconte les divergences, n’a pas été rattrapé par un outil. Les défauts que le rapport a listés, la personne qui avait écrit le code ne les avait pas vus. Mais d’autres failles, écrites de sa main, elle les avait trouvées et corrigées elle-même, seule, des mois plus tard. La capacité était là. Ce qui manquait, c’était le moment — rien, dans sa façon de travailler, ne venait s’intercaler entre « ça marche » et « je passe à la suite ». Cette leçon ne t’apprend pas à mieux regarder : elle installe ce moment, et c’est par là qu’on commence.

Ce que deux relectures ont donné ici, et ce que ça ne prouve pas

Deux relecteurs ont été lancés sur une même session de travail de cette chaîne, séparément, sans se voir. Le premier a rendu cinq défauts, le second quatre, et un seul point commun entre les deux listes.

Il faut dire tout de suite ce qui affaiblit la mesure : les deux n’ont pas tourné au même moment — le second n’a pu être lancé qu’une fois le dépôt git créé, donc pas exactement sur le même état du matériau. Et on ne sait pas ce que valaient toutes ces trouvailles. Pour le second, oui : deux de ses quatre défauts étaient des conseils faux dans une leçon déjà publiée, reproduits en bac à sable avant correction. Pour les cinq du premier, rien n’a été consigné. Donc rien n’en sera affirmé.

Ce que cette mesure justifie est donc plus modeste que « deux valent mieux qu’un », et plus solide : le second relecteur n’est pas une redondance, il regarde ailleurs. Elle n’autorise pas à conclure du non-recoupement que les deux se complètent : couverture et confiance ne se mesurent pas avec le même geste.

Ce qu’on fait

Cinq gestes. Les deux premiers ne demandent rien à installer et valent pour tous les autres.

1. Poser le moment, et savoir où on ne lance pas

Je n’ai pas de rituel périodique, et je ne vais pas t’en inventer un. Ce qui marche n’est pas un horaire, c’est un état : le moment où tu allais passer à la suite. Le déclencheur est celui de la leçon 10 — le parcours est passé en entier, tu allais fermer. Pas avant : il n’y a rien de stable à relire. Pas trois jours plus tard : tu auras empilé quatre modifications et le relecteur te rendra une liste que tu ne trieras jamais.

Et il y a un endroit où on ne lance pas. Une relecture n’est pas gratuite : elle consomme du contexte au retour, et les dispositifs lourds consomment de l’argent. La ligne de partage tient en une question : est-ce que quelque chose a pu changer là où je n’ai pas regardé ? Une correction d’affichage, non. Une route ajoutée, un champ renommé, une condition touchée dans du code partagé, oui.

Rien n’automatise ça de façon fiable : Claude peut lancer /code-review de lui-même si tu le lui demandes, et une tâche planifiée peut la déclencher, mais dans certaines sessions cette tâche arrive comme du texte ordinaire et rien ne tourne. Le seul déclencheur qui tienne est celui que tu accroches à un geste que tu fais déjà.

2. Écrire l’ordre de mission — et choisir ce que tu lui donnes

Un relecteur sans consigne relit ce qu’il veut. La documentation nomme les trois choses qu’un ordre de mission doit contenir : le travail à contrôler, le plan sur lequel le contrôler, et ce qui compte comme trouvaille — c’est la ligne que tout le monde oublie. L’exemple officiel, transposé :

Relis la modification en cours contre PLAN.md. Vérifie que chaque exigence
y est implémentée, que les cas limites listés ont des tests, et que rien
hors périmètre n'a changé. Ne signale que les manques qui touchent la
correction ou les exigences écrites ; traite tout le reste comme facultatif.
Rapporte les manques, pas les préférences de style. Pour chaque trouvaille,
cite le fichier et la ligne dans la source.

Deux régimes, et il faut savoir dans lequel tu es, parce que le geste 5 dira l’inverse de ce paragraphe. Le régime ci-dessus est celui du contrôle contre un critère écrit : un cahier des charges, la demande d’origine, le fichier où tu as écrit ce que tu voulais avant de le demander. Ce n’est pas une intention, c’est une norme opposable — écrite avant le résultat, mesurable sans toi. L’autre régime est celui du contrôle à l’aveugle : quand la norme est déjà dans les règles du projet, on ne donne que le chemin du fichier, et rien d’autre. C’est le nôtre ici.

Tu n’as pas de plan écrit ? Alors tu es dans le second régime, et c’est très bien. Ce qu’il ne faut surtout pas faire, c’est écrire après coup un plan qui décrit ce que la modification fait déjà : tu ne fabriques pas un critère, tu fabriques une justification, et le relecteur la validera. Prends plutôt une relecture qui apporte le sien — /code-review n’a pas besoin de ton plan.

Les deux dernières phrases de l’exemple ne sont pas de la politesse. L’avant-dernière est le remède documenté à la fausse alerte, et il s’écrit dans l’ordre de mission, pas après coup. La dernière est une barre de vérification : exiger une citation fichier:ligne dans la source plutôt qu’une déduction à partir des noms. La documentation la donne comme motif de REVIEW.md, donc pour le service géré dont on parle plus bas ; c’est nous qui la transposons dans un ordre de mission local, où elle sert le même but — couper les faux positifs.

3. Prendre les relectures déjà écrites

Trois commandes existent, et elles couvrent trois angles que tu n’aurais pas demandés toi-même. Aucune ne demande d’écrire un agent.

La commande	Ce qu’elle cherche	Ce qu’elle exige	Ce qu’elle écrit
/code-review	les bugs de correction, plus les nettoyages de réutilisation, simplification et efficacité	rien de particulier ; pas d’application GitHub à installer	rien, sauf si tu passes --fix
/security-review	injections, problèmes d’authentification, exposition de données	un remote origin : elle compare ta branche à la branche par défaut d’origin	rien
/simplify	quatre agents en parallèle : réutilisation de ce qui existe, simplification, efficacité, et si le changement est au bon niveau d’abstraction ; depuis la version 2.1.154 elle ne cherche plus les bugs	rien	elle applique ses corrections, sans drapeau à passer

La dernière colonne n’est pas un détail : /simplify est la seule des trois qui modifie ton arbre de travail par défaut. Elle contredit le critère du geste 4 — un relecteur rapporte, il ne corrige pas. Si tu la lances, lance-la sur un travail déjà enregistré, pour pouvoir revenir en arrière.

/code-review est celle qu’on lance par défaut. Sans argument, elle regarde les commits de ta branche en avance sur leur upstream (la branche distante que la tienne suit), plus tes modifications non enregistrées ; on peut lui passer à la place un chemin, un numéro de PR (de pull request, leçon 6) ou un nom de branche. Trois drapeaux : --fix applique les trouvailles, --comment les poste en commentaires de PR, --post propose de poster le résultat d’une relecture ultra sur une PR GitHub. Elle tourne par défaut en arrière-plan, sans remplir ta conversation — sauf quand elle repasse au premier plan : relance pendant qu’une relecture tourne, mode non interactif avec -p, ou CLAUDE_CODE_DISABLE_BACKGROUND_TASKS à 1.

Son réglage le moins connu est celui qui compte. Le niveau d’effort se tape juste après la commande : /code-review high. Il va de low à max en passant par xhigh. À low et medium, elle ne rapporte que ce dont elle est la plus sûre, donc moins de faux positifs ; de high à max, la couverture s’élargit et peut inclure des trouvailles dont elle est moins sûre. Si tu ne tapes rien, elle réutilise le dernier niveau que tu as tapé, même dans une session antérieure, et te le dit par un avis du genre Reusing high effort — sauf si tu n’en as jamais tapé, auquel cas elle prend l’effort courant de la session.

Restent les deux dispositifs plus lourds, tous deux en research preview — livrés pour essai et susceptibles de changer, leçon 10 :

• Code Review, le service géré qui relit les pull requests sur GitHub, est réservé aux offres Team et Enterprise. La plupart des lecteurs de cette leçon n’y ont pas accès ; s’il revient plus bas, c’est parce qu’il montre ce que fait une relecture sérieuse, pas parce que tu vas le lancer.
• Ultrareview, en revanche, est à ta portée : c’est /code-review ultra, une relecture profonde dans un bac à sable distant, disponible dès Pro et Max avec trois exécutions gratuites par compte, une fois pour toutes.

4. Fabriquer le regard qui manque

Quand l’angle que tu veux n’est dans aucune des trois, tu écris un subagent. C’est un fichier markdown à déposer dans .claude/agents/ à la racine du projet — ou dans ~/.claude/agents/ pour qu’il te suive partout. Un en-tête, puis le corps qui devient son prompt système :

---
name: relecteur
description: Relit une modification et rapporte les manques. À utiliser après une modification.
tools: Read, Grep, Glob
---

Tu relis les fichiers qu'on te nomme. Pour chaque point de la liste ci-dessous, dis ce
qui manque, en citant fichier et ligne. Classe par gravité. Ne propose pas de style.

L’exemple officiel tient en trois décisions, et c’est la deuxième qui fait le dispositif : des outils de lecture seulement ; ni Edit ni Write, parce qu’il rapporte et ne corrige pas ; et une liste de contrôle explicite avec un rendu ordonné par priorité. Une nuance honnête : l’exemple officiel inclut Bash, et tant que Bash est là, retirer Edit et Write ne garantit rien. La documentation le dit en montrant qu’il faut un hook PreToolUse quand on veut un contrôle plus fin que le champ tools. Pour la certitude, ne lui donne pas Bash — mais sache ce que ça coûte : la première instruction de l’exemple officiel est de lancer git diff pour voir les modifications récentes, et sans Bash aucun moyen documenté ne lui montre cette comparaison. C’est alors à toi de lui nommer les fichiers à relire.

Ensuite, tu l’appelles par son nom : @ puis le nom dans la liste qui s’ouvre, ou « utilise le subagent relecteur sur ces fichiers » suivi des chemins. Et parce qu’il tourne comme subagent, la session qui implémente reçoit les manques directement, sans rien recopier d’une fenêtre à l’autre.

5. Faire attaquer les trouvailles, et ne pas faire se parler les relecteurs

Un relecteur qui rapporte sans avoir été contredit te fait sur-construire. C’est la raison d’être de l’étape adverse. Dans les dispositifs lourds, elle est intégrée : Code Review fait suivre ses agents parallèles d’une étape de vérification qui confronte les candidats au comportement réel du code, et ultrareview reproduit chaque trouvaille indépendamment dans son bac à sable. La forme qui ne coûte rien : l’exiger dans l’ordre de mission — avant d’écrire une trouvaille, essaie de la réfuter ; si tu y arrives, jette-la.

Il faut dire ce que fait réellement la chaîne de ces leçons, parce que c’est la version modeste : nos deux relecteurs sont lancés en parallèle, ils ne se relisent pas l’un l’autre, et seul celui qui joue l’avocat du diable a la consigne de se réfuter lui-même avant de rendre. L’autre a la consigne inverse — ne rien signaler est le signe qu’il a relu trop vite. Le dispositif où un agent démolit les trouvailles des autres est documenté ; il n’est pas monté ici.

Et on ne les fait pas se parler, délibérément. Deux relecteurs qui se sont concertés convergent, et deux relecteurs qui convergent ne trouvent qu’une fois ce qu’ils auraient trouvé deux fois. La règle qui va avec est celle du second régime du geste 2 : on ne leur donne que le chemin du fichier — un relecteur à qui on explique ses intentions relit les intentions. Ce qui la rend payante : quand deux relecteurs indépendants pointent le même endroit par des chemins différents, c’est la trouvaille la plus sûre du lot, et elle se traite en premier quelle que soit la gravité affichée. C’est arrivé une fois ici, sur une absence dans un tableau de la documentation officielle : le vérificateur de faits et l’avocat du diable, deux rôles différents et sans contact, l’ont trouvée le même jour. Chacun l’avait trouvée seul ; c’est la coïncidence qui a fait la traiter en premier.

Ce que ça ne fait pas

Il trouvera quelque chose, même quand il n’y a rien

À retenir — un relecteur à qui on demande de trouver des manques en rapportera généralement, même quand le travail est sain, parce que c’est ce qu’on lui a demandé. Courir après chaque trouvaille mène droit à la sur-ingénierie : couches d’abstraction en trop, code défensif, tests pour des cas qui ne peuvent pas arriver. Le remède est documenté et tient en une consigne : ne signaler que les manques qui touchent la correction ou les exigences énoncées, et traiter tout le reste comme facultatif.

C’est le revers annoncé en leçon 10 : l’avocat du diable est payé pour trouver que c’est mauvais, il n’a pas raison pour autant. Une objection qu’on ne peut pas étayer n’est pas une attaque, c’est du bruit — et un dispositif de relecture ne meurt presque jamais parce qu’il est mauvais, il meurt parce qu’on cesse de le lire.

Alors qui tranche, si tu ne relis pas le code ? Pas toi, et cette leçon serait malhonnête si elle te renvoyait le paquet. Ton travail n’est pas de juger chaque trouvaille, c’est de vérifier qu’un dispositif l’a jugée : la barre fichier:ligne du geste 2 et la réfutation adverse du geste 5 font le tri avant que la liste t’arrive. Pour ce qui reste, la question n’est pas « est-ce vrai ? » mais celle de la leçon 10 : est-ce que ça se voit dans le parcours ? Une trouvaille qui décrit une panne reproductible se traite ; celle qui décrit un risque que rien ne rend visible attend.

Il ne relit pas ce que tu crois

Le périmètre par défaut est plus étroit que le mot « relecture ». Code Review, le service géré, se concentre par défaut sur la correction : pas le formatage, pas la couverture de tests manquante. Et ça ne s’élargit qu’en ajoutant des fichiers de guidage au dépôt. En local, /code-review y ajoute les nettoyages du tableau plus haut, rien d’autre. Sur Code Review, une partie du tri arrive faite — chaque trouvaille est classée Important (à corriger avant fusion), Nit (mineur) ou Pre-existing (déjà présent, pas introduit par cette modification). Et deux dispositifs portent des noms voisins sans lire les mêmes fichiers : REVIEW.md, qui règle ce qu’Important veut dire pour un dépôt, n’est lu que par Code Review, jamais par la relecture locale.

Une relecture n’est pas un essai. Aucune de ces commandes ne remplace le parcours de la leçon 10 : elles regardent une modification, elles ne sont pas ton utilisateur.

Il peut mourir sans rien dire

C’est la section que cette leçon se doit d’écrire, sous peine de fabriquer le problème que la leçon 13 répare. Le geste qui les attrape toutes tient en une ligne à ajouter à ton ordre de mission : demande au relecteur de commencer par dire ce qu’il a regardé — combien de fichiers, quelle plage comparée. Un rapport vide qui ne sait pas répondre à ça n’a rien regardé.

Quatre morts te concernent même si tu n’as jamais écrit un seul agent.

• /security-review qui compare ta branche à elle-même. Sans origin/HEAD, l’échec est bruyant : une erreur ambiguous argument. Le cas dangereux est celui d’après la réparation : sur un dépôt distant qui était vide, la marche à suivre documentée fait pousser ta branche puis la nommer dans git remote set-head — origin/HEAD pointe alors sur ta propre branche, et la comparaison reste vide tant qu’elle n’en a pas divergé.
• Ultrareview qui n’en est pas un. Quand ultrareview n’est pas disponible (compte non claude.ai, Bedrock, Google Cloud Agent Platform, Microsoft Foundry, Zero Data Retention), /code-review ultra bascule en relecture locale dans ta session sans que tu l’aies demandé.
• Une relecture planifiée qui n’en est pas une. Dans certaines sessions, /code-review ne tourne que si tu la tapes toi-même, et la tâche planifiée arrive à Claude comme du texte ordinaire. Ces sessions-là : fournisseurs cloud, passerelle des applications Claude, variables de confidentialité comme DISABLE_TELEMETRY ou DO_NOT_TRACK.
• Des corrections hors du filet. Une relecture lancée en arrière-plan avec --fix applique ses corrections hors des checkpoints : /rewind ne les défait pas, il faut git. La leçon 7 avait posé la limite, la voici en situation.

Les trois suivantes n’arrivent qu’à partir du moment où tu écris tes propres agents, et le geste d’observation est le même pour toutes : /doctor, qui signale les doublons, puis la ligne d’ouverture du rapport.

• Ce n’est pas ta définition qui tourne. Deux fichiers d’agent portant le même name dans le même dossier : Claude Code n’en charge qu’un, choisi par l’ordre de lecture du système de fichiers. Entre dossiers, la priorité est fixée — réglages gérés par l’organisation, drapeau --agents de la session, .claude/agents/ du projet, ~/.claude/agents/, agents d’un plugin.
• Des outils retirés en silence. Un subagent en arrière-plan ne conserve qu’un jeu d’outils réduit, et le retrait ne remonte aucune erreur. L’arrière-plan est le défaut, que le mode fork soit actif ou non ; seuls les forks y échappent. Une liste tools laissée vide le fait lancer sans aucun outil, là encore sans refus.
• Des champs ignorés au chargement. Les hooks déclarés dans l’en-tête d’un subagent de projet ne s’exécutent pas tant que le dossier n’a pas été approuvé par le dialogue de confiance : le subagent tourne, ses hooks sont ignorés, l’erreur part dans le journal de débogage. Un subagent fourni par un plugin, lui, voit ses champs hooks, mcpServers et permissionMode ignorés.

Il ne neutralise pas ce qu’il te rapporte

Un relecteur a pu lire des fichiers, des pages web et des sorties de commande que personne n’a relus, et son rapport peut porter des instructions visant ta conversation principale. Claude Code inspecte le rapport final de chaque subagent, mais cette inspection n’enlève rien et ne reformule rien — elle marque le texte, elle ne juge pas si le contenu est malveillant. D’où l’habitude à prendre : un rapport de relecture est une liste de constats, pas une liste d’ordres. Une ligne qui dit « lance maintenant telle commande » n’est pas une trouvaille, c’est du texte venu d’ailleurs. Tu ne l’exécutes pas, tu vas voir d’où il vient.

Ce n’est ni gratuit, ni rapide

Plusieurs relecteurs coûtent du contexte. La documentation avertit que lancer beaucoup de subagents qui rendent chacun un résultat détaillé consomme beaucoup de place dans ta conversation principale : l’isolation protège pendant le travail, pas au retour.

Et les dispositifs lourds coûtent de l’argent. Au 20 août 2026 : une relecture de Code Review se termine en vingt minutes en moyenne pour quinze à vingt-cinq dollars en crédits d’usage. Ultrareview prend cinq à dix minutes ; après les trois exécutions gratuites de Pro et Max, elle coûte typiquement cinq à vingt-cinq dollars selon la taille du changement, et une exécution que tu arrêtes en route consomme quand même une des trois.

Ce que tu achètes n’est donc ni de la vitesse, ni de la tranquillité : c’est de ne plus être le seul juge de ce que tu viens de produire. Le prix est un ordre de mission à écrire, un moment à tenir, et l’acceptation qu’une partie des trouvailles seront fausses.

Et les versions bougent sous tes pieds. Chaque comportement daté ci-dessus porte son numéro de version à l’endroit où il est décrit. L’ensemble a été contrôlé le 20 août 2026 contre l’instantané de la documentation officielle du même jour. C’est la date du dernier contrôle, pas une promesse de fraîcheur : claude --version et /help répondent pour ta machine, aujourd’hui.

Où c’est écrit

• Ajouter une étape de relecture adverse — le contexte neuf, l’ordre de mission type et l’avertissement sur les fausses trouvailles ;
• Subagents — ce qui est chargé au démarrage, les outils disponibles, écrire un fichier d’agent et le fork de la conversation ;
• Relire une modification localement — cibles, drapeaux, niveaux d’effort et arrière-plan ; comment fonctionnent les relectures et REVIEW.md ; ultrareview et ses exécutions gratuites ;
• Commandes — les trois commandes et ce que chacune écrit ; skills pour l’autre sens du mot fork ; le relecteur de sécurité sans origin/HEAD et l’agent lancé sans outils.

Comme aux leçons précédentes, ces liens pointent vers les pages anglaises ; la version française existe, /fr/ à la place de /en/, mais elle traduit une partie des mots que tu verras sur ton écran, et elle peut être en retard sur le fond. Un lien qui vise une section précise peut d’ailleurs ne mener nulle part côté français : la section n’y est parfois pas encore traduite, et tu atterris en haut de la page sans que rien te le dise.

Ce que cette leçon ajoute à ces pages : le moment où la relecture s’insère et l’endroit où on s’en dispense ; la correction de ce que « contexte neuf » veut dire réellement, fichiers de règles compris ; et la liste des façons dont un relecteur tourne sans rien regarder, qu’aucune page ne rassemble.

Le point de bascule

Tu as basculé le jour où « ça marche » a cessé d’être une conclusion pour devenir une moitié de réponse — et où ta question suivante n’est plus « est-ce que j’y crois ? » mais « qui d’autre a regardé, et qu’est-ce que je lui ai donné pour regarder ? ». La première question n’a jamais eu de réponse. La seconde en a une, et elle tient dans un ordre de mission.

Vérifier que c’est passé

Tu viens de faire écrire une fonctionnalité et tu tapes « lance un subagent pour relire ce que tu viens de faire ». Le rapport revient : rien à signaler. Qu'est-ce que ce rapport vaut ?

Deux questions, dans cet ordre. Qu’est-ce qui a été lancé ? Sans type demandé, Claude obtient le subagent général, qui part à neuf — mais depuis la version 2.1.232 le mode fork est actif par défaut en session interactive, et Claude peut demander un fork : un subagent qui hérite de toute la conversation, donc du raisonnement qui a produit la modification. Les forks en cours apparaissent dans le panneau sous ta zone de saisie ; pour la certitude, nomme l’agent au lieu de laisser choisir, ou pose "Agent(fork)" en deny. Et qu’est-ce qu’il a regardé ? Un rapport vide ne vaut que si tu peux répondre : combien de fichiers, quelle plage comparée.

Ton relecteur rend sept trouvailles sur une modification de quarante lignes. Tu les corriges toutes, consciencieusement. Deux semaines plus tard, personne ne comprend plus ce fichier. Qu'est-ce qui s'est passé ?

Un relecteur à qui on demande de trouver des manques en rapporte, même quand le travail est sain : c’est ce qu’on lui a demandé. Les corriger toutes produit la sur-ingénierie documentée — couches d’abstraction en trop, code défensif, tests pour des cas qui ne peuvent pas arriver. Le tri ne se fait pas à la lecture du rapport, il s’écrit dans l’ordre de mission : ne signaler que les manques qui touchent la correction ou les exigences énoncées, et citer fichier:ligne pour chaque trouvaille. Ton travail n’est pas de juger les sept, c’est de vérifier qu’un dispositif les a jugées — puis de traiter celles qui se voient dans le parcours de la leçon 10.

Ton dépôt distant était vide. Tu as poussé ton travail, la relecture de sécurité a échoué avec une erreur, tu as suivi la marche à suivre pour créer la référence manquante, tu relances : elle tourne et ne signale rien. Tu es tranquille ?

Non, et c’est le cas d’école du filet mort. La réparation documentée fait pointer origin/HEAD sur la branche que tu viens de pousser — donc la relecture compare ta branche à elle-même, et la comparaison reste vide tant qu’elle n’en a pas divergé. Cette fois, le relecteur ne se plaint pas : la première erreur, ambiguous argument, était bruyante ; celle-ci est silencieuse. Un rapport vide n’est une bonne nouvelle que si tu sais ce qui a été regardé. C’est la leçon 13.