Votre plan.md a besoin d'un avocat du diable (et Codex se porte volontaire)

Avez-vous déjà écrit un plan technique à 23 heures, convaincu qu’il était parfait, pour découvrir le lendemain matin que vous avez oublié l’authentification ?

Moi, ça m’est arrivé. Plus d’une fois. Et le pire, ce n’est pas l’oubli — c’est qu’en utilisant une IA pour planifier, le plan semble tellement cohérent que votre cerveau arrête de chercher les failles. Claude vous génère un document avec des sections, des dépendances, un ordre d’exécution, et tout semble logique. C’est comme un plan conçu par un ingénieur senior. Mais personne ne lui a tenu tête.

Aseem Shrey a publié un article qui résume parfaitement ce problème et propose une solution que je trouve élégante : utiliser un deuxième modèle pour revoir le plan du premier. Et pas juste une fois — en boucle, jusqu’à ce que le relecteur donne son approbation.

Le problème : personne ne discute avec votre IA

Lorsque vous utilisez un seul modèle pour planifier et exécuter, vous obtenez un résultat cohérent mais non contesté. L’IA ne se contredit pas elle-même. Elle ne vous dira pas “hé, ce modèle d’authentification est incomplet” ni “le quoting dans ton script shell est cassé”.

C’est comme si vous écriviez un document, que vous le relisiez vous-même, et que vous vous disiez “c’est parfait”. Bien sûr que c’est parfait — vous l’avez écrit. Notez bien cela : la relecture par les pairs existe en sciences, en ingénierie et en médecine pour une raison. Pas parce que les auteurs sont nuls, mais parce que le créateur est le pire relecteur de sa propre œuvre.

J’ai déjà écrit sur ce sujet lorsque j’ai conçu mon conseil Jedi de relectures de code par IA. Mais là, je parlais de revoir du code. Ce que propose Aseem, c’est de revoir le plan avant même de coder quoi que ce soit. C’est attaquer le problème une étape plus tôt.

Comment ça marche : Claude planifie, Codex révise

La mécanique est une skill spécifique de Claude Code — un simple fichier Markdown, sans infrastructure, sans services externes. Quand vous invoquez /codex-review :

1. Claude rédige un plan dans un fichier temporaire.
2. Le plan est envoyé à Codex CLI en mode read-only (il peut lire votre base de code pour avoir du contexte, mais il ne modifie rien).
3. Codex analyse et donne un verdict : VERDICT: APPROVED ou VERDICT: REVISE.
4. Si Codex dit REVISE, Claude corrige et renvoie le plan. Le détail crucial : Codex reprend la session précédente, donc il se souvient de ce qu’il a dit et vérifie si les corrections sont réelles.
5. Maximum 5 tours. En pratique, 3 suffisent souvent.

En gros : c’est une pull request entre deux IA, où l’une propose et l’autre cherche des failles. Sans intervention humaine.

14 bugs en 3 tours

Dans l’exemple de l’article — un tableau de bord pour un essaim d’agents — la boucle a trouvé 14 problèmes dans le plan original :

Tour 1 (8 problèmes) : Pas d’authentification sur les endpoints d’écriture. Bugs de quoting dans les scripts shell. Conflits dans les champs de schéma. Tableaux imbriqués sans limite. Pas de gestion de la concurrence. Stratégie de tests uniquement manuelle.

Tour 2 (6 problèmes restants) : Claims non atomiques. Permissions ACL trop larges. Rotation des clés non spécifiée. Modélisation des états inconsistante.

Tour 3 : Tout corrigé. Plan approuvé.

Le tableau avant/après parle de lui-même :

De zéro problème détecté à quatorze débusqués et corrigés. Sans qu’un humain ne lise une seule ligne du plan.

Pourquoi l’itération compte plus que la révision

Une révision en une seule passe détecte des problèmes mais ne vérifie pas les corrections. Aseem l’explique bien : le boucle itérative détecte les problèmes du type “j’ai corrigé une chose mais j’en ai cassé une autre”.

C’est exactement ce qui arrive dans une véritable revue de code. Vous dites à quelqu’un “ce lock n’est pas sûr”, il le modifie, et ce faisant il introduit un deadlock ailleurs. Si vous ne regardez qu’une fois, vous manquez ça. Si vous regardez deux fois, vous le rattrapez.

Le détail technique qui fait que cela fonctionne : Codex supporte la reprise de session (resume). Il ne redémarre pas de zéro à chaque tour. Il se souvient de ce qu’il a dit, de ce qu’il a demandé de corriger, et il vérifie que la correction est réelle — pas un rafistolage qui déplace le problème.

Ce que je veux tester

Après avoir lu l’article, j’ai eu envie de mettre en place quelque chose de similaire. J’ai mon plan.md comme étape essentielle avant toute fonctionnalité sérieuse, et jusqu’à maintenant, c’est moi qui fais la relecture. Ce qui revient à dire qu’il n’y a pas de relecture, parce qu’après trois heures plongé dans une tâche Linear, ma capacité critique est au plus bas.

L’idée d’un /second-opinion me semble naturelle. Pas pour tout — je ne vais pas passer trois tours de révision pour un changement de CSS. Mais pour les plans qui touchent aux modèles de données, à l’authentification, à la concurrence, ou à tout ce qui va nécessiter plusieurs jours de mise en œuvre, avoir un adversaire automatique qui vous dit “qu’est-ce qui se passe si deux agents réclament la même ressource en même temps ?” vaut de l’or.

Ce qui m’attire particulièrement :

• C’est un fichier Markdown. Pas de serveur, pas de wrapper API, pas de dépendances exotiques. Un SKILL.md et à vous de jouer.
• C’est à la demande. Ce n’est pas exécuté à chaque commit ni sur chaque plan. Vous décidez quand cela en vaut la peine. Continuer à fond seulement quand il y a un gros sujet.
• C’est adversarial par conception. Vous ne demandez pas au relecteur de “vérifier le plan”. Vous lui demandez de chercher des failles. D’essayer de le casser. Cette intention change complètement le résultat.

L’éléphant dans la pièce

Une question évidente que l’article ne répond pas entièrement : avez-vous besoin de Codex spécifiquement, ou tout modèle ferait l’affaire comme relecteur ?

Mon intuition dit que ce qui compte, c’est qu’il s’agisse d’un modèle différent. La valeur réside dans la diversité des biais. Si Claude planifie et Claude révise, c’est comme si vous vous relisiez vous-même — ils partagent les mêmes angles morts. Introduire un modèle avec un entraînement différent, des heuristiques différentes, c’est ce qui produit l’effet “avocat du diable” réel.

Cela dit, l’implémentation avec Codex CLI présente un avantage pratique majeur : la reprise de sessions (resume). Que le relecteur se souvienne des tours précédents n’est pas juste un nice-to-have — c’est ce qui transforme ceci en un véritable cycle d’amélioration, plutôt qu’en trois révisions indépendantes où les mêmes problèmes se répètent.

Quand ne pas l’utiliser

Aseem le dit lui-même : lorsque la vitesse est plus importante que l’exhaustivité, cela ne vaut pas la peine. Un correctif urgent en production à 3 heures du matin n’a pas besoin de trois tours de révision adversarial. Il a besoin d’un patch, d’un test et d’un déploiement.

Je pourrais aussi imaginer que pour des plans simples — “ajouter un champ à un formulaire” —, les efforts investis ne sont pas rentables. La règle que je m’impose : si le plan fait plus d’une page ou touche quelque chose partagé entre plusieurs modules, il mérite un /second-opinion.

La morale

Ce qui est le plus intéressant dans cette idée, ce n’est pas l’implémentation technique — qui est simple — mais le changement de mentalité. Jusqu’ici, le consensus était “utilisez une IA pour planifier, puis exécutez le plan”. Personne ne remettait en question le plan. Le plan était sacré parce qu’il avait été généré par un modèle intelligent.

Mais un plan non révisé est un plan truffé de bugs latents. Peu importe qu’il ait été écrit par GPT-4, Claude, Codex ou un ingénieur avec vingt ans d’expérience. Sans relecture adversarial, sans quelqu’un pour dire “et si ça échouait ?”, vous jouez à la roulette russe avec une complexité que vous ne percevez pas encore.

Un fichier Markdown. Deux modèles. Trois tours. Quatorze bugs en moins. Pas mal pour quelque chose qui tient sur un simple gist.