Un Claude qui corrige l'autre

Ce que c'est et pourquoi ça compte

Quand une session de Claude Code termine un travail et vous dit « fait », le réflexe est de lui demander de revérifier. Ça marche mal. Elle vient d'écrire ce code, elle sait pourquoi elle l'a fait comme ça, et quand elle le relit elle voit ce qu'elle voulait faire, pas ce qu'elle a vraiment fait.

C'est le même angle mort que nous avons quand nous relisons un texte à nous. Les erreurs qui passent sont justement celles que vous n'avez pas imaginées en écrivant : le champ laissé vide, le double clic, l'utilisateur qui ouvre les données d'un autre.

C'est pour ça que je fais faire la vérification par une autre session, qui démarre sans la conversation de la première. Elle ne voit que les modifications et une tâche : trouver comment les casser. Le guide officiel de Claude Code le dit aussi : une session au contexte propre relit mieux le code, parce qu'elle n'est pas attachée à ce qu'elle vient d'écrire.

Pourquoi ça compte : si vous construisez une app sans être développeur, vous n'avez pas encore l'œil pour voir ces trous. Un relecteur dont la tâche est d'attaquer le code les cherche à votre place, avant que vos utilisateurs ne les trouvent.

1. Le prompt du relecteur

Voici le prompt que je colle dans la deuxième session, mot pour mot. Tel quel, il fonctionne avant le commit. Si vous avez déjà fait le commit, ajoutez à la fin quels fichiers regarder.

Tu es un relecteur externe. Ce n'est pas toi qui as écrit ce code et tu ne sais pas pourquoi il est fait comme ça : ne le demande pas et ne cherche pas de justifications. Regarde seulement les modifications qui viennent d'être faites : lance git status et git diff, et lis en entier les nouveaux fichiers que git status liste (le diff ne les montre pas). Ta seule tâche est de trouver comment les casser. Cherche :
- saisies : champs vides, textes très longs, caractères bizarres, nombres négatifs, double clic, requêtes en double ;
- permissions : qui peut voir ou modifier des données qui ne sont pas les siennes, ce qui se passe sans connexion ou connecté avec le compte d'un autre ;
- cas limites : listes vides, réseau lent ou absent, deux utilisateurs au même moment ;
- sécurité : clés ou mots de passe dans le code, données de l'utilisateur utilisées sans contrôle, erreurs qui en montrent trop.
Pour chaque problème, écris : où (fichier et ligne), comment je le casse (les étapes exactes), ce qui se passe, gravité (haute, moyenne, basse). Trie du plus grave au moins grave. Ne corrige rien et ne modifie pas les fichiers : je veux seulement le rapport.

Chaque morceau a une raison.

• « Ce n'est pas toi qui as écrit ce code » : je lui retire le rôle d'auteur. Un auteur défend son travail, un relecteur externe cherche les défauts.
• « Lance git status et git diff, et lis en entier les nouveaux fichiers » : git diff ne montre que les modifications des fichiers que git connaît déjà. Les fichiers créés de zéro, elle les trouve avec git status, et sans cette ligne ils resteraient de côté.
• « Ta seule tâche est de trouver comment les casser » : je ne lui demande pas si le code est bon. Je lui demande de l'attaquer, ce qui est une autre question.
• Les quatre zones, c'est-à-dire saisies, permissions, cas limites et sécurité, sont les endroits où les apps construites à la va-vite cassent le plus souvent. Si votre app a une partie sensible, comme les paiements, ajoutez-la en cinquième ligne.
• « Comment je le casse (les étapes exactes) » : un problème avec les étapes, vous le vérifiez vous-même en deux minutes. Un « il pourrait y avoir un problème », non.
• « Ne corrige rien et ne modifie pas les fichiers » : le relecteur signale, il ne touche pas. S'il corrigeait lui-même, vous auriez deux sessions qui changent les mêmes fichiers et vous ne sauriez plus qui a fait quoi.

2. Comment je l'utilise

1. Quand la première session dit « fait », je ne lui demande pas de se revérifier.
2. J'ouvre un nouveau terminal dans le même dossier et je lance claude. Ou, dans la même fenêtre, /clear ouvre une nouvelle conversation avec un contexte vide. L'ancienne reste enregistrée et vous la reprenez avec /resume.
3. Je colle le prompt. Avant le commit, git status et git diff montrent le travail qui vient d'être fait. Après le commit, je lui indique les fichiers.
4. Je rapporte le rapport à la première session et je fais corriger en commençant par la gravité haute.
5. Sur la connexion, les paiements et les données des utilisateurs, je relis aussi la correction, dans encore une nouvelle session.

Un détail sur git diff : il montre les modifications des fichiers que git connaît déjà, donc les nouveaux fichiers n'y sont pas. C'est pour ça que le prompt contient git status, qui les liste, et le relecteur les lit en entier. Si vous préférez les voir aussi dans le diff, lancez git add -N . dans le terminal avant d'ouvrir le relecteur : git les marque comme fichiers à ajouter et ils apparaissent alors dans git diff.

Le relecteur ne doit pas pouvoir écrire

Le prompt dit de ne pas modifier les fichiers, mais c'est une demande, pas un verrou. Si je veux en être sûr, j'ouvre la deuxième session en plan mode :

claude --permission-mode plan

En plan mode, Claude lit les fichiers et peut lancer des commandes pour explorer, comme git diff, mais il ne modifie pas le code tant que vous n'approuvez pas un plan. Si à la fin il vous propose un plan de corrections, ne l'approuvez pas : le rapport vous suffit. Si la session est déjà ouverte, vous y entrez en appuyant sur Shift+Tab jusqu'à ce que « plan mode on » apparaisse en bas.

Rapporter le rapport

Dans la première session, je colle le rapport avec un prompt comme celui-ci :

Voici le rapport d'un relecteur externe : [colle le rapport]. Corrige d'abord les problèmes de gravité haute, un par un. Pour chacun, dis-moi ce que tu as changé et comment tu l'as vérifié. Ne touche pas aux gravités basses : c'est moi qui décide.

Si j'avais utilisé /clear, je reviens d'abord à la conversation de départ avec /resume, pour que la session qui corrige ait de nouveau tout le contexte du travail.

Les basses, je les garde pour moi pour une raison précise. Un relecteur à qui vous demandez de trouver des problèmes en trouve presque toujours, même quand le travail est bien fait, parce que c'est ce que vous lui avez demandé. Si vous corrigez tout, vous vous retrouvez avec du code en plus pour des cas qui n'arriveront jamais.

3. Avec un subagent, dans la même fenêtre

Si vous ne voulez pas ouvrir une autre fenêtre, le relecteur peut être un subagent : un assistant qui travaille dans votre session, avec son propre contexte, et qui ne voit pas la conversation. Dans le guide sur les subagents, j'explique comment créer un code-reviewer fixe avec seulement les outils pour lire.

L'avantage : le rapport revient directement à la session qui a écrit le code, sans copier-coller. Le risque : c'est Claude qui écrit la tâche du subagent, et Claude sait pourquoi il a fait comme ça. S'il le lui explique, le relecteur part déjà convaincu. Donc je lui demande de transmettre le prompt tel quel :

Fais relire les dernières modifications par le subagent code-reviewer. Transmets-lui ce prompt mot pour mot, sans ajouter d'explications sur comment ou pourquoi tu as écrit le code : [colle le prompt du relecteur]

Pour les parties sensibles, par contre, je préfère la nouvelle session : là, c'est moi qui colle le prompt et je sais exactement ce que le relecteur a reçu.

La règle d'or

Rien de la conversation d'avant : si vous lui expliquez pourquoi vous avez fait comme ça, elle finit par vous donner raison.

Ça vaut aussi pour vous. Quand vous collez le prompt, n'ajoutez pas « je l'ai fait comme ça parce que… ». Donnez les modifications et la tâche, c'est tout. Les explications servent après, quand vous décidez quels problèmes corriger.

Une nouvelle session lit quand même les instructions du projet (CLAUDE.md) et la mémoire automatique, si vous les utilisez. C'est très bien : ce sont des règles, pas l'histoire de la naissance de ce code.

Les erreurs les plus courantes

• Demander à la même session de se revérifier : ouvrez une nouvelle session, ou utilisez /clear, pour que celle qui vérifie n'ait pas écrit le code.
• Expliquer au relecteur pourquoi le code est fait comme ça : donnez-lui seulement les modifications et la tâche, sinon il finit par vous donner raison.
• Laisser le relecteur corriger : demandez-lui seulement le rapport et faites corriger la session qui a écrit le code.
• Corriger chaque problème signalé : commencez par la gravité haute et décidez vous-même pour les basses, sinon vous remplissez le code de protections inutiles.
• Se fier seulement à git diff quand il y a de nouveaux fichiers : ils n'apparaissent pas dans le diff, donc faites aussi lancer git status, comme dans le prompt.
• Ne pas relire la correction sur les parties sensibles : pour la connexion, les paiements et les données des utilisateurs, refaites la relecture dans une nouvelle session.

Check-list

• Le relecteur est dans une nouvelle session
• Le prompt est collé sans explications
• Avant le commit : git status et git diff. Après : les fichiers indiqués
• Chaque problème a l'endroit, les étapes, l'effet et la gravité
• Les problèmes de gravité haute sont corrigés et vérifiés
• Les parties sensibles ont eu une deuxième relecture

Questions fréquentes