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, et le parcours passe en entier — la suite de clics que tu avais écrite à la leçon 10 pour vérifier ton produit sans lire son code. 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, et il faut deux mots avant de voir pourquoi. Un subagent est un ouvrier isolé : Claude lui confie une tâche, il travaille dans son coin avec son propre plan de travail, et il ne rend qu’un résumé. Certains sont fournis, et tu peux écrire les tiens — c’est le geste 4, plus bas dans cette leçon. Le CLAUDE.md est le fichier de règles du projet, celui de la leçon 6, relu à chaque session ; il en existe un par niveau, le tien, celui du projet, ceux des sous-dossiers, et c’est cet empilement qu’on appelle la hiérarchie.

Ce qu’un relecteur lancé comme subagent a sous les yeux au départ : ses propres consignes, le message que Claude compose pour lui, tous les fichiers CLAUDE.md de la hiérarchie, et l’état de ton dépôt — la liste des fichiers modifiés, prise en photo au démarrage de la session parente, donc peut-être il y a deux heures. Celui-là, tu ne peux pas le lui couper. N’y arrivent jamais : l’historique de la conversation, les fichiers déjà lus, les skills déjà invoqués. Le détail des modifications non plus : c’est à toi de lui nommer les fichiers à relire.

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. C’est le comportement par défaut, et il vaut pour tous les subagents sauf les deux que la leçon 6 a nommés, Explore et Plan, qui ne sont pas des relecteurs.

Depuis la version 2.1.271, livrée le 14 septembre 2026, un champ permet de le couper. Il s’appelle omitClaudeMd, il se pose dans l’en-tête du subagent, et à true il le lance sans le fichier de règles de ton compte, sans celui du projet et sans le CLAUDE.local.md. Les règles imposées par une organisation, elles, restent chargées. Le champ ne vaut que pour les subagents que tu écris toi-même et pour ceux qui viennent d’un plugin, et il est ignoré si l’agent tient la session principale au lieu d’être délégué.

Et la relecture intégrée, alors ? C’est la question que cette section t’apprend à poser, et la réponse est écrite : /code-review suit ton fichier de règles comme n’importe quelle session. Tu ne peux pas le lui couper, parce que le champ ci-dessus se pose dans un fichier d’agent, et celui-là n’est pas à toi. Ce n’est pas une raison de s’en priver : elle apporte un angle que tu n’as pas, et le geste 3 y revient. Mais tu sais maintenant qu’elle arrive en connaissant ta thèse, et c’est le geste 4 qui te donne le relecteur que tu peux rendre aveugle.

Ce que ça coûte, et il faut le savoir avant de le poser. Ton fichier de règles ne contient pas que tes intentions. Il porte aussi tes conventions de forme, et le relecteur les perd en même temps : il te reprochera de suivre des règles qu’il ne connaît plus. La documentation officielle le dit dans la phrase même qui présente le champ, et elle donne la manœuvre complète : à réserver aux subagents qui prennent tout ce qu’il leur faut dans le message de délégation. Couper le fichier de règles n’est donc que la moitié du geste. L’autre moitié est de remettre dans la consigne les seuls critères dont le relecteur a besoin pour juger.

Et ce que ça ne règle pas. Le champ ne rend pas le relecteur ignorant de ta conversation : il l’était déjà, c’est le sujet de cette leçon. Il ne t’apprend pas non plus quels critères remettre dans la consigne, et c’est là que se joue la qualité de la relecture.

Quand couper, et quand laisser. Le geste 2 va poser qu’on peut faire juger un travail contre les règles écrites du projet, en ne donnant que le chemin du fichier. Ce n’est pas l’inverse de ce qui précède, et la ligne de partage tient à ce que ton fichier de règles contient réellement :

• il ne porte que des normes — conventions, exigences, ce qui est interdit ? Laisse-le arriver. C’est un critère écrit avant le résultat, exactement ce que le geste 2 exploite ;
• il porte aussi tes intentions — la thèse, ce que tu cherches à démontrer, l’audience que tu vises ? Coupe. Le relecteur y lirait la réponse attendue avant d’avoir regardé le travail.

Le champ ne sait pas trier : c’est tout ou rien. Donc si ton fichier mélange les deux, ce qui est le cas le plus courant, tu coupes et tu remets les seules normes dans la consigne. C’est la situation de la chaîne qui produit ces leçons : son fichier de règles porte la charte de rédaction et la thèse dans le même document, et ses deux relecteurs reçoivent les deux. Au 16 septembre 2026, elle n’a pas encore appliqué son propre geste : aucun des deux ne porte la ligne. C’est écrit ici parce que c’est le défaut que cette leçon enseigne à repérer.

Ce que le contexte neuf t’achète sans que tu demandes rien, c’est l’ignorance de ta conversation : les hésitations, les arbitrages, les « fais simple pour l’instant ». L’ignorance de ce que le projet a écrit sur lui-même se demande, et elle se paie. 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, dont un reproduit 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.

Une partie s’automatise : Claude peut lancer /code-review de lui-même si tu le lui demandes en langage ordinaire, et une tâche planifiée dont la consigne est /code-review lance réellement la relecture. Une seule réserve est documentée, et elle porte sur la variante déléguée à distance : une tâche planifiée ne la déclenche jamais, donc on planifie /code-review sans son argument ultra. Reste que le déclencheur qui tient vraiment est celui que tu accroches à un geste que tu fais déjà, parce que celui-là ne dépend pas de ta mémoire.

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.

Deux phrases de l’exemple ne sont pas de la politesse. La troisième est le remède documenté à la fausse alerte : ne signaler que les manques qui touchent la correction ou les exigences écrites, et traiter tout le reste comme facultatif. 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, et c’est un autre dispositif, décrit deux paragraphes plus bas. 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. Ce niveau commande combien Claude réfléchit avant d’agir, et tous les modèles n’offrent pas les mêmes : demander un niveau que le tien ne connaît pas n’échoue pas, il exécute le niveau supporté le plus haut en dessous. Le niveau qui tourne n’est donc pas toujours celui que tu as tapé, et c’est vérifiable : il s’affiche dans l’en-tête de la session, à côté du nom du modèle. Ce niveau-là ne règle que la relecture ; celui de ta session se pose autrement, et sa portée change selon le geste : la leçon 9 donne les deux.

Et ultra n’est pas un cran de cette échelle. L’échelle s’arrête à max ; ultra se tape au même endroit, avec la même syntaxe, et désigne autre chose : un service distant, facturé, celui du paragraphe suivant. Il n’existe aucun niveau d’effort qui porte ce nom.

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
omitClaudeMd: true
---

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.

Ta liste de contrôle — c'est toi qui l'écris, et c'est elle qui fait le dispositif :
- une erreur possible n'est traitée nulle part, et rien ne le signale à l'écran ;
- un ancien chemin a survécu à côté du nouveau, et les deux sont encore appelés ;
- la même valeur est écrite à deux endroits qui peuvent diverger.

Les trois points ci-dessus sont des exemples, pas la liste. La tienne se remplit avec ce que tu t’es déjà fait avoir : un relecteur dont la liste est vide relit ce qu’il veut, et c’est le premier geste de cette leçon qui tombe.

Et voilà où se pose la ligne du début de leçon. omitClaudeMd: true, dans l’en-tête, quatrième ligne : c’est là, et nulle part ailleurs. Ce relecteur-ci démarre donc sans ton fichier de règles, et c’est pour ça que sa liste de contrôle doit être complète — elle est tout ce qu’il a. Si tes règles ne portent que des normes et aucune intention, retire la ligne : autant qu’il les lise.

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.

Un critère mécanique, ça se compte avant d’être vécu. Tu le passes sur l’historique déjà écrit, tu comptes ce qu’il sort, puis combien de ces sorties étaient du bruit. Le détecteur que la leçon 14 branche en refus d’envoi a été réglé comme ça, sur un de mes dépôts, 734 commits sur trois mois. Le critère évident, beaucoup de suppressions par rapport aux ajouts, en sort huit, dont six nettoyages parfaitement légitimes : une fausse alerte toutes les deux semaines, de quoi apprendre à passer outre. Le critère retenu, un fichier qui revient à un état qu’il a déjà eu, en sort exactement trois, tous vrais. Zéro fausse alerte, et le compte se refait chez toi pour le prix d’une commande.

Un relecteur, lui, ne se recompte pas sur ton historique — et c’est la seule chose que cette différence veut dire. Repasser une relecture profonde sur trois mois de travail coûterait ce que coûte chaque exécution, et rien ne garantit que deux exécutions rendent la même liste : ces dispositifs ne sont pas déterministes, et la documentation le dit de leurs voisins.

Il se calibre autrement, et il faut le faire. La leçon 13 pose la règle sans exception : tant que tu n’as pas vu ton filet rougir, tu ne sais pas s’il passe ou s’il n’existe pas. Un relecteur n’y échappe pas. Le geste tient en trois temps : tu demandes l’introduction d’un défaut précis dans une copie de travail jetable, celle de la leçon 14 ; tu lances ton relecteur dessus ; et tu regardes s’il proteste. S’il ne dit rien, tu viens d’apprendre que ton dispositif est décoratif, pour le prix d’un fichier. Le procédé porte un nom, error seeding, et il est publié depuis 1972 : on plante un nombre connu de défauts, on compte la part que le dispositif retrouve. La leçon 16 raconte deux épreuves de ce genre menées sur la chaîne qui produit ces leçons.

Et l’épreuve ne se lit que dans un sens. S’il n’a rien dit, tu sais : le dispositif est décoratif. S’il l’a trouvé, tu ne sais qu’une chose, c’est qu’une fois il a vu. Deux exécutions ne rendent pas la même liste, et exercer un chemin ne valide que ce chemin. C’est la différence entre un relecteur et un déclencheur automatique : le second refera ce qu’il a fait, le premier non.

Les deux gestes qui suivent, la barre fichier:ligne et la réfutation adverse, ne remplacent donc rien : ils réduisent le bruit au quotidien, le défaut planté dit si le dispositif est mort.

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 — mais elle le serait tout autant en te promettant un juge qu’elle n’a pas monté. Ce que tu as, c’est du bruit en moins : la barre fichier:ligne du geste 2 écarte ce qui a été déduit d’un nom de variable, la réfutation adverse du geste 5 écarte ce que le relecteur lui-même n’arrive pas à défendre. Ni l’une ni l’autre ne dit le vrai du faux, et la seconde est rendue par celui qui vient d’écrire la trouvaille. Le vrai juge, celui où un second agent démolit les trouvailles du premier, est documenté et n’est pas monté ici. Pour ce qui reste, la question n’est pas « est-ce vrai ? », c’est où ça va, et la réponse tient en deux cas :

• ça se voit dans le parcours de la leçon 10 — une panne que tu peux reproduire en cliquant : ça se traite tout de suite, tu as de quoi vérifier que c’est réparé ;
• rien ne le rend visible — une faille, un filet mort, une sauvegarde jamais restaurée : ça monte dans la liste de la leçon 11, avec sa condition de sortie. Pas au fond d’un tiroir.

La condition de sortie, écris-la de façon à pouvoir la fermer. « Aller regarder » n’en est pas une si tu ne lis pas le code : la ligne resterait ouverte pour toujours, et une liste dont rien ne sort finit par ne plus être lue. Ce qui la ferme, c’est un second dispositif qui confirme ou infirme : une relecture de sécurité lancée sur le seul chemin concerné, ou le défaut planté dont parle la section suivante.

La nuance décide de tout, et c’est la leçon 11 qui l’a établie : invisible ne veut pas dire secondaire, ça veut dire que tu ne sauras pas tout seul quand c’est réglé. D’où la condition de sortie écrite à côté. Et sa règle vaut ici mot pour mot : « je ne sais pas » compte comme un oui.

Le piège serait de lire « invisible, donc ça attend » — ce serait renvoyer au fond de la pile exactement ce pour quoi la leçon 10 t’a envoyé ici : la faille de sécurité, que par définition aucun parcours ne montre.

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 ne part pas au loin. Une tâche planifiée lance bien /code-review, mais jamais sa variante déléguée à distance : planifiée avec l’argument ultra, elle ne déclenche pas ce que tu crois avoir programmé. On la planifie sans lui.
• 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 visent tes propres agents, mais deux d’entre elles valent aussi pour ceux que tu installes ou que Claude lance seul, 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 23 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. Plusieurs des comportements décrits ci-dessus ont changé à une version précise, et la leçon ne porte pas toujours laquelle : ce qu’elle décrit vaut pour l’état contrôlé, pas pour le tien. L’ensemble a été contrôlé le 16 septembre 2026 contre l’instantané de la documentation officielle du même jour, et ce contrôle a trouvé deux comportements qui avaient changé depuis le précédent. 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. Ensuite, deux destinations et pas une : ce qui se voit dans le parcours de la leçon 10 se traite tout de suite ; ce que rien ne rend visible, une faille par exemple, monte dans la liste de la leçon 11 avec sa condition de sortie. Aucune des deux n’est « ça attend ».

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.