Claude ne doit pas réviser le code qu'il vient d'écrire

Le réflexe est presque universel. On finit une session Claude Code qui vient d’écrire deux cents lignes, on lui demande “tu peux relire ton code et me dire s’il y a des bugs ?”, et il répond “j’ai relu, ça me semble correct”. Le code est mergé, le ticket est fermé, et trois jours plus tard la régression remonte en production. Le problème n’est pas que le modèle ait menti, c’est qu’on lui a demandé une revue dans la session où il était en posture de construction. Un LLM qui vient de produire un artefact ne le critique pas comme un relecteur extérieur. Il l’explique, le défend, le justifie. La revue utile par un LLM exige une fresh session, fresh contexte, et cette discipline est codée jusque dans les outils qu’Anthropic livre par défaut dans Claude Code.

C’est un détail de méthode qui change radicalement la fiabilité de ce qu’on commit.

Posture build et posture review ne sont pas le même mode mental

Quand Claude écrit du code, il accumule dans sa fenêtre de contexte le raisonnement qui a produit chaque ligne, les hypothèses retenues, les chemins écartés, les contraintes qu’il s’est posées à lui-même. Tout ça forme un état mental qui justifie le code produit. Demander à ce même état mental de critiquer l’artefact qu’il vient de cristalliser, c’est demander à un avocat de plaider contre son propre dossier.

Le modèle qui vient d’écrire la fonction se souvient d’avoir choisi “je ne valide pas l’input ici parce que je suppose que le caller le fait”. Quand on lui demande de relire, il voit cette absence de validation et l’interprète comme intentionnelle, parce que dans sa mémoire de session, elle l’est. Un modèle frais, à qui on présente la même fonction sans le contexte de production, voit immédiatement la même absence comme un trou potentiel.

C’est exactement ce que le blog post de lancement d’Opus 4.8 met en avant quand il décrit le nouveau comportement de revue : “in Claude Code, it asks the right questions, catches its own mistakes, pushes back when a plan isn’t sound”. Le mot-clé est catches its own mistakes, mais cette amélioration s’exprime sur un code que le modèle évalue à froid, pas sur un code qu’il vient de défendre tour après tour.

Les chiffres méritent d’être posés à plat : Opus 4.8 est “around four times less likely than its predecessor to allow flaws in code it has written to pass unremarked” et obtient un score de “0 % d’uncritically reporting flawed results”, c’est-à-dire qu’il ne rapporte plus de résultats erronés en faisant comme si tout allait bien. C’est une amélioration réelle et mesurée, et elle s’applique principalement à du code soumis sans contexte de génération. Sur du code que le modèle a lui-même produit dans la session courante, la pente est plus douce parce que les justifications restent activement portées dans la fenêtre. La règle pratique qui en découle : un modèle qui flag son incertitude au tour 15 d’une session vous fait gagner deux heures de debugging au tour 40, mais la même incertitude, soumise en fresh session au tour 16, est encore plus susceptible d’être attrapée.

Anthropic a codé la discipline dans un outil livré par défaut

La référence des commandes Claude Code liste /code-review comme un bundled workflow, une commande livrée avec Claude Code, qu’on peut invoquer sur n’importe quel diff. Elle existe précisément parce que la revue dans la session qui vient de coder est inférieure à la revue dans une session séparée. La bundled /code-review n’est pas un raffinement esthétique : c’est l’instrumentation officielle d’un principe que les retours utilisateurs ont rendu évident.

Le pattern est simple. La session A code la modification. La session B, démarrée fraîche, ouvre le diff et en fait la revue. Pas d’historique de conversation, pas de justifications portées par le contexte, pas de souvenir des chemins écartés. Le modèle voit le code comme un relecteur externe le verrait : une boîte noire à juger sur ce qui est écrit, pas sur ce qui aurait pu être écrit.

Le coût marginal est ridicule, une commande de plus. Le bénéfice est asymétrique : une fraction des cas où la session A aurait laissé passer un bug est rattrapée par la session B. Sur du code qui finit en production, ce ratio est dur à refuser.

Trois patterns qui marchent

Au-delà de /code-review, trois disciplines concrètes traduisent le principe.

Fenêtre séparée, repo identique. La session de revue ouvre le repo, lit le diff via git diff main, et fait son passage. C’est le plus simple, claude -p dans une nouvelle terminal session pointée sur le même worktree. Le modèle n’a aucune mémoire de ce qui a produit le diff. C’est l’angle aveugle volontaire qu’on cherche.

Modèle différent pour la revue. Si la session de construction tournait en Opus 4.8, la session de revue peut tourner en Sonnet 4.6 ou même en Haiku, non pas pour économiser, mais pour augmenter la diversité de jugement. Un autre modèle, avec un autre tokenizer, une autre distribution de raisonnement, surfacera des choses que le premier n’aurait pas vues. C’est l’équivalent LLM du second opinion en médecine.

Prompt structuré explicitement adverse. Plutôt que “relis ce code”, on demande “voici un diff. Cherche activement ce qui pourrait casser. Pour chaque ligne modifiée, pose-toi la question : qu’est-ce qui invalide cette modification ?”. C’est la posture qui maximise le retour. La même approche est exactement ce que les dynamic workflows codifient à l’échelle massive, chaque finding est passé à un agent qui essaie de le réfuter avant qu’il ne soit rapporté. À l’échelle artisanale, c’est le même réflexe.

Sur des modifications critiques, sécurité, migrations de schéma, modifications de logique métier, combiner les trois (fenêtre séparée + modèle différent + prompt adverse) produit un filet de revue qui rattrape l’écrasante majorité des erreurs silencieuses qu’une revue mono-session laisserait passer.

Cas particuliers : post-PR et post-merge

La discipline s’étend au-delà de la revue de session courte.

Avant le merge. La session A pousse la PR. Une session B, fraîche, ouvre la PR via gh pr view, lit le diff, et fait sa revue en posture adverse. Le résultat, bugs trouvés, questions soulevées, peut être posté comme commentaire sur la PR via gh pr comment. Le code-reviewer humain bénéficie alors de deux passes LLM avant la sienne, sans les avoir orchestrées.

Après le merge. Une fois par semaine, un claude -p programmé peut prendre les diffs des sept derniers jours sur main et chercher rétroactivement les choses ratées. Ce qu’il trouve devient des tickets, pas des urgences, mais une queue de dette technique qualifiée. Le rapport coût/bénéfice est exceptionnel : une heure de compute par semaine identifie systématiquement ce qu’aucune revue humaine de PR n’aurait pris le temps d’attraper.

Ces deux passes appartiennent à une discipline plus large : le plan, le modèle, la revue. Le modèle qui révise n’est jamais celui qui vient d’écrire. La revue n’est jamais dans la session qui a fait le travail. Et le contexte de revue est explicitement adverse, pas neutre.

Ce qui est élégant dans cette discipline, c’est qu’elle s’aligne avec une vérité plus ancienne : un développeur qui relit son propre code trois minutes après l’avoir écrit ne voit pas ce qu’un autre développeur verrait en trente secondes. Les LLMs reproduisent cette limite cognitive, pas la transcendent. Une fois qu’on intègre ça dans le workflow, la qualité de ce qui sort de Claude Code monte d’un cran, pas parce que le modèle est meilleur, mais parce qu’on a séparé deux modes mentaux qu’il faut maintenir séparés.

Si cela vous a parlé, vous aimerez Claude Opus 4.8 : un modèle qui rattrape ses propres bugs et Claude Code : quatre disciplines plutôt que trente-deux hacks. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.