Le juge aveugle : évaluation de Claude Code contre Codex en 36 duels

Thomas Ricouard (@Dimillian) l’a exprimé mieux que n’importe quel benchmark : « Claude Code, c’est comme un refactoring très, très moyen dont je sais qu’il peut l’exécuter. Codex, c’est une architecture à la pointe. Je ne suis pas encore sûr qu’il puisse vraiment le faire sans tout casser. »¹

J’ai cessé de me poser la question et j’ai commencé à mesurer. J’ai construit un système qui met en compétition Claude Code et Codex CLI sur la même tâche, étiquette les résultats aléatoirement comme Alpha et Beta, et évalue les deux plans à l’aveugle sur cinq dimensions avant de révéler quel agent a produit quoi. Trente-six duels plus tard, le tableau des scores indique que Claude a remporté 8 des 12 duels tranchés. Mais le tableau des scores n’est pas l’essentiel. L’essentiel, c’est ce que le juge aveugle produit après l’évaluation : une synthèse qui combine les éléments les plus forts des deux plans en quelque chose de meilleur que ce que l’un ou l’autre concurrent a livré seul.

En bref

Trente-six duels. Évaluation à l’aveugle sur cinq dimensions (Exactitude, Complétude, Simplicité, Décomposition, Actionnabilité). Claude Code a gagné 8 fois, Codex CLI 3 fois, un résultat indécis, sur 13 duels avec des manifestes de jugement structurés (12 avec un vainqueur déclaré). Le véritable produit n’est pas un vainqueur. C’est l’étape de synthèse qui sélectionne les meilleurs éléments des deux plans et produit un brief d’implémentation plus solide que celui de chaque agent pris isolément. L’article compagnon Thinking With Ten Brains couvre la délibération collaborative.¹² Le juge aveugle couvre l’évaluation compétitive. La méthodologie importe plus que le tableau des scores.

Pourquoi la comparaison est difficile

Tout le monde compare les agents de codage IA en ce moment. Personne ne s’accorde sur les résultats.

Le problème est structurel. Les comparaisons de modèles se dégradent selon trois axes : les impressions subjectives (vous avez testé une tâche sur chacun et suivi votre intuition), le biais de récence (le dernier succès efface tous les échecs précédents), et les forces spécifiques à chaque tâche (le modèle qui gagne sur votre tâche de refactoring perd sur votre revue de sécurité). Ce ne sont pas de mauvaises observations. Ce sont de mauvaises expériences.

Alex Finn (@AlexFinn) utilise un workflow de double validation où deux modèles vérifient mutuellement leurs résultats.² L’approche de double vérification détecte des erreurs que chaque modèle seul aurait manquées. L’intuition est juste : l’évaluation indépendante fait émerger les désaccords, et c’est dans les désaccords que se cachent les bugs.

@doodlestein fait tourner plus de 10 agents simultanément — Claude, Codex et Gemini — en utilisant des prompts standardisés qu’il appelle des « idea wizards » pour attaquer le même problème sous différents angles.³ Un planificateur qui excelle en décomposition peut passer à côté d’un bug d’exactitude qu’un agent plus minutieux repère immédiatement.

Les deux workflows améliorent l’évaluation mono-modèle. Aucun n’élimine la plus grande menace : le biais de confirmation. Si vous savez quel modèle a écrit quel plan, vous noterez plus généreusement le modèle auquel vous faites confiance. À chaque fois. Non pas parce que vous êtes négligent, mais parce que le biais opère en dessous du seuil de conscience. La pièce manquante, c’est la mise en aveugle. Si l’évaluateur ne sait pas quel agent a produit quel résultat, le biais de confirmation n’a rien à quoi s’accrocher.

Le protocole d’évaluation à l’aveugle

Le système /duel fonctionne en cinq phases :

1. Exécution parallèle. Les deux agents reçoivent le même prompt de tâche et le même contexte projet. Claude Code s’exécute dans un processus, Codex CLI dans un autre. Aucun ne voit le résultat de l’autre.
2. Étiquetage aléatoire. Un tirage au sort attribue un agent à « Alpha » et l’autre à « Beta ». Le système écrit le mapping dans agent-mapping.json et le scelle. Ni le juge ni moi ne voyons le mapping avant la fin de l’évaluation.
3. Évaluation à l’aveugle. Un agent juge lit les deux plans et note chacun sur cinq dimensions, de 0 à 4 par dimension, maximum 20 points au total. Le juge ne voit que « plan Alpha » et « plan Beta ».
4. Recommandation du vainqueur. Le juge déclare un vainqueur (ou un résultat indécis) avec un niveau de confiance et un raisonnement écrit.
5. Synthèse. Le juge combine les éléments les plus forts des deux plans en un brief d’implémentation affiné. La synthèse est le véritable livrable.

Les cinq dimensions d’évaluation :

La décision de conception clé : la synthèse n’est pas un mélange 50/50. Elle pondère fortement la stratégie centrale du vainqueur tout en sélectionnant les apports véritables du perdant. Les premiers essais de synthèse à poids égal produisaient des plans incohérents qui héritaient des pires propriétés des deux. La synthèse pondérée produit des plans structurellement solides (grâce au vainqueur) et minutieusement renforcés (grâce aux cas limites valides du perdant).

Étude de cas : le duel de remédiation sécurité

En février 2026, un audit de sécurité à trois agents a révélé 7 findings CRITIQUES et 7 ÉLEVÉS dans ResumeGeni, une application FastAPI avec authentification Supabase et paiements Stripe.⁴ J’avais déjà livré deux corrections triviales. Il en restait neuf. J’ai lancé un duel pour générer le plan de remédiation.

Les deux agents ont reçu le même briefing : la liste des findings avec chemins de fichiers et numéros de ligne, le contexte d’architecture, la contrainte qu’un pattern de correction éprouvé existait déjà dans un fichier, et l’exigence de produire un plan de déploiement phasé.

Plan d’Alpha : 11 stories pour 9 findings, organisées en trois vagues de déploiement. Une story de référentiel de tests (SEC-01) bloquait tout le travail suivant. Des portes de déploiement avec des métriques spécifiques : taux de succès d’authentification, surveillance des 5xx, compteurs de rejets de webhooks. Discussion approfondie des alternatives rejetées. Les stories utilisaient une structure Quoi/Pourquoi/Succès avec des plages de lignes.

Plan de Beta : Mapping direct 1:1 des findings aux stories. Trois vagues de déploiement : les Critiques en bloc unique, les Élevés déployables indépendamment, le Nettoyage. Investigation avant correction pour le finding middleware. Numéros de ligne spécifiques, noms de fonctions, chemins d’import et commandes curl de vérification par story.

L’écart d’exactitude racontait l’histoire. Beta a détecté deux choses qu’Alpha avait complètement manquées.

Premièrement : le finding middleware (C3) signalait get_user(jwt=...) comme vecteur de contamination de session. Beta a correctement identifié que get_user() est un appel de vérification sans état. gotrue-py n’appelle _save_session() que dans verify_otp et exchange_code_for_session, pas dans get_user. Alpha l’a traité comme nécessitant définitivement la même correction que les deux autres routeurs, ce qui aurait ajouté une surcharge inutile par requête sur chaque requête authentifiée. Beta a dit : investiguer d’abord, corriger seulement si confirmé.

Deuxièmement : les routeurs magic link et passkeys utilisent à la fois admin.generate_link() (qui nécessite le singleton SERVICE_KEY) et verify_otp() (qui a besoin d’un client frais par requête). Le plan d’Alpha appliquait le pattern de client frais uniformément. Un implémenteur suivant ce plan aurait cassé les opérations admin. Beta a explicitement signalé la séparation : client frais pour verify_otp, singleton partagé pour admin.generate_link().

Les scores :

Alpha était Codex. Beta était Claude. Confiance élevée.⁴

La synthèse combinait la précision technique de Beta avec la rigueur opérationnelle d’Alpha. Voici une story issue de la synthèse, montrant comment elle a fusionné les deux plans :

Story 1.1 (C1 — Singleton partagé Magic Link) : Dans magic_link.py, ajouter _create_auth_client(). Utiliser un client anon frais UNIQUEMENT pour verify_otp (ligne 224). Conserver le singleton partagé pour admin.generate_link() (ligne 213) qui nécessite SERVICE_KEY.

Cette story hérite des numéros de ligne précis de Beta et de la séparation critique client admin/anon, encapsulée dans une structure qui s’insère dans la séquence de déploiement en trois vagues d’Alpha. La synthèse complète conservait l’approche investigation-d’abord de Beta pour C3, les commandes curl de vérification spécifiques de Beta, les portes de déploiement d’Alpha (surveillance du taux de succès d’authentification, suivi des 5xx), et la stratégie de tests de régression d’Alpha (suite E2E Playwright d’authentification après la Vague 1, webhook Stripe de test après la Vague 2). Le résultat : un plan en 3 vagues avec 12 stories, exécutable en une journée, avec des garde-fous opérationnels qu’aucun des deux plans ne fournissait seul.

Le tableau des scores (et pourquoi il est trompeur)

Sur 36 duels, 13 ont produit des manifestes de jugement structurés. Un manifeste a déclaré un résultat indécis, laissant 12 avec un vainqueur clair :

Claude : 8. Codex : 3. Indécis : 1.¹¹

Ne traitez pas le tableau des scores comme un benchmark de modèles. Ce n’en est pas un.

Les victoires de Claude se concentrent sur les tâches de revue, de vérification et de sécurité : 7 de ses 8 victoires sont à confiance élevée sur des tâches impliquant la revue de code, l’analyse de sécurité ou l’évaluation technique. L’unique victoire à confiance élevée de Codex portait sur une tâche de revue de code où sa rigueur procédurale et ses chaînes de dépendances explicites surpassaient l’approche moins structurée de Claude. Les deux autres victoires étaient à confiance faible. Le pattern : Claude produit des plans plus actionnables et techniquement précis. Codex produit des processus opérationnels plus solides et une couverture théorique plus large.

Ricouard avait raison. Qualité de planification contre fiabilité d’exécution est un axe réel.¹ Mais le tableau des scores reflète ma répartition de tâches (fortement orientée revue de sécurité et d’architecture), pas un classement objectif de modèles. Quelqu’un exécutant des duels sur du développement greenfield ou de l’automatisation d’infrastructure verrait probablement des résultats différents. L’analyse de Nathan Lambert sur l’ère post-benchmark fait le même constat : les benchmarks traditionnels ne transmettent plus de signal significatif quand les écarts fins entre Opus 4.6 et Codex 5.3 dépendent de la forme de la tâche et de la méthodologie d’évaluation.¹⁰

Le tableau des scores vous renseigne sur mon workflow. Il ne vous dit pas quel modèle est « meilleur ».

La synthèse est le produit

Le plan gagnant n’est pas l’essentiel. La synthèse l’est.

Chaque duel produit trois artefacts : le plan Alpha, le plan Beta et la Synthèse. La synthèse suit une structure cohérente : adopter la stratégie centrale du vainqueur, intégrer les cas limites valides du perdant, supprimer le périmètre superflu des deux. Elle n’est pas diplomatique. Elle ne coupe pas la poire en deux. Elle fait des choix explicites sur les éléments à conserver et ceux à écarter, avec une justification écrite pour chacun.

Dans le duel d’expansion du corpus de jobs, le plan de Claude activait d’abord l’infrastructure existante (scripts de seed pour 8 780 boards connus que le système ne consultait pas encore), puis s’étendait aux nouvelles plateformes ATS, puis construisait des systèmes de découverte.⁶ Le plan de Codex commençait par un audit du codebase et une spécification d’instrumentation avant d’ingérer un seul job. Claude a gagné en simplicité et actionnabilité. Mais Codex a identifié quelque chose que Claude avait manqué : la nécessité d’une machine à états de cycle de vie des boards (actif/en échec/en quarantaine). Codex a également signalé un audit de régression de déduplication pour empêcher l’expansion de volume de masquer une explosion de doublons. La synthèse a conservé le séquencement activate-first de Claude et intégré le suivi d’observabilité et de cycle de vie de Codex en Phase 1.5, après que le seeding initial ait livré des résultats mesurables. Le même pattern est apparu dans le duel du système d’ingestion de jobs, où le plan de Claude réutilisait les tables APScheduler et registry existantes tandis que Codex proposait un schéma de provenance à deux tables plus complet. La synthèse a adopté l’architecture pragmatique de Claude et sélectionné l’amélioration du hash de déduplication de Codex.⁷

Dans le duel de revue ATS, Claude a trouvé des crashes P0 à l’exécution (incompatibilités de signatures de méthodes dans le scheduler qui auraient silencieusement cassé le suivi des jobs) que Codex avait complètement manqués.⁵ Codex a trouvé la prévention de chevauchement du scheduler et des vecteurs d’abus des endpoints admin que Claude n’avait pas signalés. La synthèse commençait par les corrections P0 de Claude et les complétait avec le renforcement opérationnel de Codex.

Le pattern à travers 36 duels : le modèle juge produit systématiquement des synthèses plus solides que le plan de chaque concurrent. Le juge n’est pas plus intelligent. La structure adversariale force une couverture complète.⁹ Chaque agent identifie indépendamment des risques et des cas limites. Le juge les voit tous. La synthèse hérite de l’union des apports des deux agents, moins leurs angles morts individuels.

Ce pattern rejoint une conclusion plus large issue de la délibération multi-agents : l’indépendance est le mécanisme. Dix agents de délibération évaluant une décision sous différentes perspectives détectent des biais que n’importe quel agent seul manquerait. Deux agents en duel attaquant la même tâche depuis des architectures différentes détectent des lacunes d’implémentation que chaque agent seul aurait livrées. L’étape de synthèse est la même dans les deux systèmes : combiner des évaluations indépendantes en un artefact unique qui bénéficie de toutes les perspectives.

Je documente la couche d’orchestration qui supporte les deux systèmes séparément. Ce qui compte ici, c’est que le duel et la délibération remplissent des fonctions complémentaires. La délibération répond à « devrait-on construire cela ? » Le duel répond à « quelle est la manière la plus solide de le construire ? »

Quand utiliser le duel vs. la délibération

Les deux systèmes utilisent l’évaluation indépendante et la synthèse. Ils servent des types de décisions différents.

Mon pattern : délibérer la conception, mettre en duel le plan d’implémentation, exécuter la synthèse.

Une décision de remédiation sécurité passe d’abord par la délibération (« Est-ce la bonne priorisation ? Passons-nous à côté de problèmes systémiques ? »), puis par le duel (« Quel est le plan phasé le plus solide pour exécuter ces corrections ? »), puis par l’exécution à partir de la synthèse du juge. Le système de délibération et le système de duel partagent une infrastructure mais servent des objectifs distincts dans le pipeline de décision.

Ce que j’ai mal fait

Les premiers duels n’avaient pas d’étiquetage en aveugle. Je lisais les deux plans en sachant quel modèle avait écrit lequel. Le biais de confirmation était réel et mesurable : je notais systématiquement Claude plus haut en Actionnabilité avant la mise en aveugle, puis j’ai vu l’écart se réduire (sans disparaître) après l’introduction de l’assignation aléatoire Alpha/Beta. Le protocole d’aveuglement n’est pas optionnel.

J’ai commencé avec trois dimensions d’évaluation (Exactitude, Complétude, Actionnabilité). Au bout de deux duels, j’ai réalisé que je confondais la structure du plan avec son contenu. Ajouter la Simplicité (est-ce sur-ingéniéré ?) et la Décomposition (les étapes sont-elles bien ordonnées ?) a séparé ces préoccupations et produit des évaluations plus utiles.

Les premières tentatives de synthèse mélangeaient les deux plans à parts égales. Les résultats étaient incohérents : la stratégie de tests d’Alpha greffée sur la séquence de déploiement de Beta, sans que les hypothèses de l’un ou l’autre ne tiennent. La synthèse pondérée, où le juge adopte explicitement le cadre du vainqueur et incorpore sélectivement les apports du perdant, a été la percée.

N=36 sur ma répartition de tâches n’est pas un benchmark de modèles. C’est une évaluation d’outil de workflow. Le système de duel me dit quel agent a produit le plan le plus solide pour ma tâche spécifique dans mon codebase spécifique. Extrapoler vers « Claude est meilleur que Codex » serait le même raisonnement basé sur les impressions que le système existe pour éliminer.

J’utilise Claude pour juger des duels entre Claude et Codex. Je reconnais le conflit.⁸ L’atténuation est structurelle : étiquetage en aveugle, dimensions structurées, et le fait que Codex a gagné 3 duels et s’est approché de la victoire dans plusieurs autres. Un test plus rigoureux ferait passer les mêmes duels par un juge non-Claude (Gemini ou GPT) et comparerait les distributions de scores. Je ne l’ai pas encore fait. En attendant, le ratio 8-3 devrait porter un astérisque : le juge et l’un des concurrents appartiennent à la même famille de modèles.

Références