La règle des deux corrections : quand arrêter de corriger l'agent pour corriger le système

Tu as dit la même chose à Claude Code trois fois. Même erreur, même correction, même résultat. La session a 20 minutes et tu es déjà frustré.

Ça arrive à tout le monde qui travaille avec des agents de code IA. Tu demandes un composant, Claude utilise des styles inline au lieu de Tailwind. Tu corriges. Deux fichiers plus loin, encore du style inline. Tu corriges plus fermement. Claude passe à styled-components. Trois corrections, tu n'es pas plus proche du résultat et le contexte de session est plein de bruit.

La plupart des développeurs blâment le modèle à ce stade. « Il n'écoute pas. » Mais après des mois à faire tourner des workflows agentic en production, j'ai trouvé que le problème n'est presque jamais la compréhension du modèle. C'est le set d'instructions que le modèle lit avant même que ta tâche ne commence.

La règle des deux corrections a changé comment je gère ces moments : si tu corriges Claude deux fois sur le même sujet et que ça persiste, arrête de corriger. Le problème est en amont.

Ce que la sur-correction te coûte vraiment

Chaque correction va dans la context window. Après trois rounds sur le même sujet, Claude lit ta description de tâche au milieu de ses propres tentatives ratées, de ta frustration montante, et de multiples instructions conflictuelles. C'est beaucoup de bruit en compétition avec le travail réel.

Le modèle ne t'ignore pas. Il suit des motifs qu'il voit dans le codebase, dans l'historique de conversation, ou dans la documentation manquante. Tes corrections rivalisent avec ces signaux. Parfois elles gagnent. Souvent non. Et chaque correction ratée rend la prochaine tentative légèrement pire, parce que Claude a maintenant plus d'informations conflictuelles à peser.

J'ai regardé cette spirale se jouer des dizaines de fois. Cinq minutes deviennent dix. Dix deviennent vingt. Le développeur continue de taper des instructions de plus en plus spécifiques. L'agent continue de dériver. Finalement quelqu'un ferme le terminal de frustration et traite ça de jour sans pour l'outil. Ça ne l'était pas. C'était un problème système déguisé en problème de session.

La règle des deux corrections en pratique

La règle est simple. Si tu as corrigé Claude deux fois sur le même sujet et que ça continue :

1. Stoppe la session.
2. Identifie où le bon comportement devrait être documenté.
3. Corrige ça là.
4. Démarre une nouvelle session.

Pas de troisième correction. Deux corrections, et tu remontes en amont.

Le fix amont dépend du type d'erreur. Une convention que Claude enfreint sans arrêt va dans CLAUDE.md : « Never import @jd/db/server in client components. Use @jd/db/browser instead. » Une contrainte de tâche que Claude rate sans arrêt veut dire que la spec a besoin d'être resserrée. Pas plus de détail, plus de frontières. Et si le codebase lui-même a des motifs conflictuels, la moitié de tes fichiers suivant une convention et l'autre moitié une autre, Claude va refléter cette incohérence. Corrige le codebase.

Pourquoi la deuxième correction est le signal

Une correction, c'est normal. Claude ne connaît pas chaque convention de ton projet. Il lit ce qui est disponible, fait un jugement, et parfois se trompe. Tu corriges, il ajuste. C'est le système qui marche comme prévu.

La deuxième correction porte de la vraie information. Elle signifie que Claude avait ta première correction en contexte et a quand même fait la même erreur. Le motif qui pilote le comportement est plus fort que ton instruction verbale. Ta correction remonte le courant à contre-courant contre le codebase ou l'historique de conversation.

La troisième correction est du gaspillage. Tu ajoutes du bruit au contexte, tu réduis la qualité de sortie future, et tu dépenses du temps sur un problème qui ne sera pas résolu dans cette session. J'ai observé ça de manière constante sur des mois d'usage quotidien de Claude Code. Quand j'ignore la règle et continue de corriger, je brûle 10 à 20 minutes avant d'obtenir un résultat qui tient à peine. Quand je suis la règle, le fix amont prend 30 secondes, la nouvelle session coûte une minute de setup, et le problème ne revient jamais.

Ce n'est pas de la dégradation de contexte

La règle des deux corrections adresse un mode d'échec spécifique : la même erreur qui se répète malgré les corrections. C'est différent de la dégradation de contexte, où Claude commence à faire de petites erreurs variées à mesure que la context window se remplit. Mauvais noms de variables. Motifs oubliés du début de session. Négligence générale qui n'était pas là il y a 30 minutes.

La dégradation de contexte a ses propres fixes. /compact compresse l'historique de conversation tout en préservant les décisions clés. « Summarize from here » cible juste la section bloatée. Parfois tu commit le bon travail et tu lances /clear pour repartir propre.

La règle des deux corrections gère autre chose entièrement. Le modèle lit un signal, un motif du codebase, une règle manquante, une spec ambiguë, qui contredit ta correction. Aucune quantité de fixing en session ne remplace ce signal de façon permanente. Seul un changement en amont le fait.

Le coût de repartir de zéro

La résistance à reset une session est psychologique, pas pratique. Une nouvelle session Claude Code charge ton CLAUDE.md et lit les fichiers pertinents en moins d'une minute. Si tu as commit avant le début de la tâche, rien n'est perdu.

Compare ça à l'alternative : 15 minutes de plus à lutter avec un contexte pollué de corrections ratées, chacune rendant la prochaine tentative moins fiable. La mauvaise approche précédente de Claude est juste là dans le contexte, en compétition avec ta dernière instruction. L'historique de corrections ne se contente pas de ne pas aider. Il fait mal activement.

Repartir avec une instruction amont corrigée prend deux minutes au total. Debugger une session confuse en prend quinze et échoue en général de toute façon. Le calcul est clair.

Je creuse plus loin la règle des deux corrections et le workflow de récupération complet dans Chapitre 3 : The Human in the Loop du cours d'agentic coding. Le chapitre couvre quand intervenir, quand abandonner une session, et comment construire les réflexes qui rendent le recadrage rapide.

Les fixes amont qui composent

Le vrai retour de la règle des deux corrections apparaît après quelques semaines.

Chaque fois que tu touches la frontière des deux corrections, tu ajoutes une règle à CLAUDE.md, resserres un motif de spec, ou corriges une incohérence du codebase. Chaque fix est petit. Mais ils composent. Après un mois, ton CLAUDE.md couvre la plupart des conventions qui causaient de la friction. Tes specs ont des frontières plus claires. Ton codebase a moins de motifs conflictuels.

Le nombre de corrections par session baisse. Non pas parce que le modèle est devenu plus intelligent, mais parce que ton système l'est devenu. C'est l'idée centrale derrière le recadrage en agentic coding : le but n'est pas de devenir meilleur à corriger. C'est de construire un système qui a besoin de moins de corrections dans le temps.

Les développeurs qui tirent le plus de l'agentic coding n'écrivent pas les prompts les plus malins. Ce sont ceux qui traitent chaque erreur répétée comme un signal, la tracent en amont, et la corrigent à la source.

La règle des deux corrections est une pièce d'un système de récupération plus large que j'enseigne dans le cours d'agentic coding, de l'architecture CLAUDE.md aux feedback loops au pattern de-sloppify. Si tu veux construire un système qui s'améliore à chaque session, démarrer le cours.