Claude Code et Codex ensemble : 3 modèles de travail

Ressources pratiques sur le travail avec des agents et le vibe coding : documentation Ailoot.

Pourquoi combiner Claude Code et Codex ?#

En mai 2026, OpenAI est entré sur le terrain d’Anthropic avec le modèle GPT-5.5 dans Codex CLI. Dans les benchmarks récents, Codex a une nette avance sur les tâches de terminal et en mode SWE-bench Verified. Anthropic a répondu avec Opus 4.8 et Dynamic Workflows, conservant son avance sur SWE-bench Pro (un test conçu pour empêcher les fuites de données, où entraîner un modèle sur le benchmark ne l’aide pas). Une comparaison détaillée est présentée dans le guide Codex vs Claude Code—ici, passons directement à leur association.

En 2026, il n’y a pas de vainqueur unique. Un modèle domine—les équipes gardent Codex pour le travail autonome peu coûteux et Claude Code pour les décisions d’architecture risquées.

La différence clé qui détermine comment répartir le travail :

• Claude Code est le chercheur. Il soutient un dialogue long et approfondi, remet en question les hypothèses et envisage plusieurs approches avant de choisir une solution. Il convient aux situations où la bonne action n’est pas évidente dès le départ.
• Codex est l’exécutant. Il reçoit une tâche et va jusqu’au résultat dans un bac à sable. Il convient aux tâches clairement définies qui nécessitent un cycle rapide « demande et résultat ».

Si vous avez les deux outils à disposition, vous n’avez pas à choisir entre « réfléchir » et « agir ». Vous déléguez selon le type de tâche. Si vous n’avez pas encore décidé lequel installer en premier, vous trouverez une comparaison directe dans le guide Codex vs Claude Code.

Modèle 1 : Claude Code écrit le code, Codex le relit#

Dans ce modèle, Claude Code reste l’éditeur principal. Codex n’intervient qu’au niveau de la PR, via son mode cloud (Codex s’exécute directement depuis ChatGPT ou l’application GitHub, sans qu’un deuxième terminal soit nécessaire).

Voici comment cela se passe en pratique :

1. Étape 1 : Écrire la fonctionnalité dans Claude Code

   Ouvrez le dépôt dans VS Code, lancez Claude Code, passez en Plan Mode et discutez de l’architecture de la fonctionnalité. Vous obtenez du code préliminaire, des tests et des migrations. Faites un commit sur une branche de fonctionnalité.

2. Étape 2 : Créer une PR dans GitHub

   Ouvrez une pull request de la branche de fonctionnalité vers main. Dans la description, saisissez @codex review this PR for edge cases, security issues, and test coverage gaps.

3. Étape 3 : Codex effectue la revue de manière asynchrone

   En mode cloud, Codex clone le dépôt dans son bac à sable, lit le diff, lance les tests et le linter, puis recherche des vulnérabilités. Après 5-15 minutes, il laisse des commentaires directement sur la PR.

4. Étape 4 : Apporter les modifications dans Claude Code

   Revenez dans Claude Code et donnez-lui les commentaires de Codex comme contexte : « Voici les conclusions de la revue ; corrige les points 1, 3 et 5. » Claude apporte les modifications et les publie dans le dépôt.

Ce modèle fonctionne parce que Claude et Codex ont été entraînés sur des jeux de données différents et ont des philosophies différentes. Codex voit ce que Claude a manqué à cause d’un angle mort de son modèle, et inversement.

Risques du modèle 1 :

• Codex peut approuver une PR sans remarquer un problème d’architecture. Vérifiez vous-même les décisions importantes.
• Coût doublé en tokens : Claude et Codex analysent le même code. Cela vaut le coup pour les fonctionnalités complexes, mais coûte cher pour les petites.
• En mode cloud, Codex ne voit pas votre environnement local—variables d’environnement ou bases de données locales. Si la fonctionnalité les concerne, passez à une exécution manuelle.

Modèle 2 : Codex prépare un brouillon, Claude Code corrige l’architecture#

Ce modèle a été utilisé dans le projet décrit en 2026, lorsqu’il a fallu créer en une soirée un prototype d’entonnoir d’inscription avec notifications par e-mail. Dans ce scénario, vous auriez pu passer une heure à discuter de l’architecture avec Claude Code. Codex a produit un brouillon fonctionnel en 12 minutes.

Voici comment cela fonctionne :

Le fonctionnement est le suivant : Codex fait le gros du travail pendant les 15 premières minutes, puis Claude amène le résultat au niveau de qualité requis en production.

Demandez à Codex de tout peaufiner immédiatement et il restera bloqué sur les ambiguïtés. Demandez à Claude Code d’aller vite dès le départ et il commencera à remettre les choses en question. Confiez à chacun le travail pour lequel il a été conçu.

Risques du modèle 2 :

• Codex génère un brouillon fondé sur des hypothèses qui peuvent être difficiles à corriger par la suite. Si le brouillon part dans la mauvaise direction, il coûte moins cher de le jeter et de recommencer que de le corriger.
• Claude Code peut passer une demi-heure à renommer des variables et oublier le véritable problème d’architecture. Demandez-lui des modifications précises, pas « remets ça au propre ».
• Le contexte se perd entre les sessions. Pour que Claude Code comprenne l’intention de Codex, il vous faut un fichier AGENTS.md (voir le modèle 5) ou un commentaire détaillé au début du fichier.

Modèle 3 : Codex pour l’infrastructure, Claude Code pour la logique métier#

L’idée est simple : différentes parties d’une base de code nécessitent différentes façons de travailler.

Ce modèle complète l’approche consistant à exécuter plusieurs instances de Claude Code en parallèle—dans ce cas, le même modèle traite différentes tâches via des worktrees Git ; ici, deux agents différents se répartissent les domaines de responsabilité.

Couche d’infrastructure (Codex) :

• GitHub Actions : ajouter un nouveau job, ajuster la mise en cache, accélérer CI.
• Tests : écrire une suite de tests d’intégration après une refactorisation.
• Migrations Prisma : générer une migration et vérifier qu’elle peut être annulée.
• Configurations Docker / Coolify : ajouter des variables d’environnement, mettre à jour le contrôle d’état.
• Tâches Cron : écrire un ensemble de gestionnaires Cron.

Codex est avantagé ici parce que les tâches d’infrastructure comprennent souvent de nombreux petits fichiers avec du code répétitif. Codex ne s’enlise pas à vouloir « tout réfléchir » ; il va jusqu’au bout.

Logique métier (Claude Code) :

• Entonnoir d’inscription : ce qu’il faut montrer à l’utilisateur à chaque étape.
• Calcul des prix tenant compte des réductions, des paiements échelonnés et des codes promotionnels cadeaux.
• Workflows de notification automatisés : quels déclencheurs et quelles conditions.
• Intégrations d’API externes : gestion des erreurs, nouvelles tentatives, mise en cache.
• Modèles financiers : calculs d’économie unitaire et prévisions de revenus.

Claude Code est avantagé ici parce que ces tâches exigent un dialogue approfondi et une réflexion sur le produit. Sans discuter des scénarios, vous obtenez une solution technique qui ne tient pas compte des vrais problèmes des utilisateurs.

Répartition du travail dans le dépôt :

project/
├── .github/workflows/      ← Codex (CI, tests)
├── infra/                  ← Codex (Docker, Coolify, migrations)
├── scripts/                ← Codex (scripts de tâches)
├── tests/                  ← Codex (tests d’intégration)
├── src/
│   ├── lib/                ← Claude Code (logique métier)
│   ├── app/                ← Claude Code (routes, formulaires, pages)
│   └── components/         ← Claude Code (interface utilisateur)
└── prisma/
    └── schema.prisma       ← Claude Code (modèles de données—décision produit)

Ce n’est pas une règle stricte. Il peut y avoir des chevauchements—par exemple, Claude Code peut modifier une GitHub Action si celle-ci a une signification produit (envoyer une notification après une publication, par exemple). Mais 80% des tâches s’intègrent bien dans cette répartition.

Comment synchroniser CLAUDE.md et AGENTS.md ?#

Un problème inattendu est apparu dans l’expérience décrite d’utilisation parallèle de Claude Code et Codex. Claude Code suivait les règles de CLAUDE.md (« ne pas toucher aux migrations sans confirmation »). Codex ne voyait pas ces règles et exécutait les migrations dans un environnement de travail sans hésiter. Après la troisième base de données endommagée, il a fallu trouver comment synchroniser correctement les deux fichiers.

Les deux fichiers peuvent contenir contexte, préférences conversationnelles, commandes de test, exclusions de dossiers et conventions de commit. Réutilisez les règles applicables aux deux outils et séparez leurs commandes et configurations propres. L’interdiction de modifier les migrations doit figurer des deux côtés si elle vaut pour les deux agents.

Éléments communs aux deux fichiers :

• Stack : les frameworks, la base de données et l’ORM utilisés.
• Description du projet : de quoi il s’agit, à qui il s’adresse et quelles sont ses principales entités.
• Interdictions : les dossiers à ne pas toucher et les commandes à ne pas exécuter.

Différences :

• Les hooks, couches de réglages et configurations MCP propres à Claude Code relèvent de ses fichiers de configuration. CLAUDE.md peut décrire et référencer ces conventions ; les copier en prose ne les transforme pas en configuration portable.
• AGENTS.md est un standard ouvert. Codex, Cursor, Aider, Continue, Cline et Factory Droid le lisent—plus de 25 agents. Le guide séparé traite plus en détail du format AGENTS.md. Les configurations MCP de Codex sont stockées dans ~/.codex/config.toml (TOML, et non JSON comme pour Claude).

Un modèle courant en 2026 est une source canonique de règles dans le dossier /context/ du monorepo, à partir de laquelle un script de synchronisation génère CLAUDE.md, .cursor/rules/*.mdc et AGENTS.md. Les fichiers propres à chaque outil sont marqués en lecture seule ; seule la source est modifiée.

Exécutez le script de synchronisation au moyen d’un hook pre-commit ou d’une GitHub Action. Si des modifications sont apportées directement à CLAUDE.md, CI échoue. Cela empêche les règles des différents outils de diverger.

Une autre option est le plugin Codex officiel pour Claude Code (annoncé le 30 mars 2026, version 1.0.4). Il ajoute les commandes /codex:review, /codex:adversarial-review et /codex:rescue à Claude Code. Codex s’exécute comme sous-agent avec son propre ~/.codex/config.toml et son propre AGENTS.md. Cela évite d’avoir besoin d’un deuxième terminal, mais AGENTS.md reste nécessaire.

Combien coûte l’utilisation des deux outils et où se trouvent les économies ?#

Voici les chiffres de juin 2026 (données des pages d’abonnement officielles d’Anthropic et d’OpenAI et de la page officielle de Codex) :

Association minimale fonctionnelle : Claude Pro ($20) + ChatGPT Plus ($20) = $40/mois. Suffisant pour des projets individuels avec quelques sessions par jour.

Une véritable association pour une personne qui code activement en mode vibe coding : Claude Max 5x ($100) + ChatGPT Plus ($20) = $120/mois. Selon l’expérience décrite, cette association a été utilisée pendant les 2 derniers mois : trois projets ont été mis en ligne pendant cette période, et les limites de Claude n’ont jamais été atteintes.

Une association pour une équipe : Claude Max 20x ($200) + Codex Pro ($200) = $400/mois. C’est pertinent lorsque les revues de PR et les tâches cloud s’enchaînent régulièrement en parallèle du travail local.

D’où viennent les économies :

• Moins de temps par fonctionnalité. Mesure de l’auteur : pour 12 fonctionnalités en mai-juin, le délai entre « une idée a émergé » et « mise en production » est passé de 4 heures (avec Claude Code seul) à 2.5 heures (avec l’association). Mesure effectuée sur les tâches de l’auteur ; vos chiffres dépendront de votre profil.
• Moins de défauts. D’après les observations décrites, les revues de PR par Codex détectent 2-3 problèmes sur 10 que Claude manque. Chaque problème de production de ce type représente une heure ou deux de correction, auxquelles peuvent s’ajouter des interruptions de service.
• Parallélisme. Codex travaille sur la fonctionnalité A en mode cloud pendant que l’utilisateur travaille avec Claude sur la fonctionnalité B. Le débit double ainsi.

Ce n’est pas rentable si vous écrivez 1-2 fonctionnalités par semaine. Dans ce cas, Claude Code Pro seul suffit.

Quand n’avez-vous pas besoin d’un deuxième outil ?#

Cette association n’est pas faite pour tout le monde. Souvent, elle ne fait qu’ajouter du bruit. Voici quatre situations où un deuxième outil est inutile :

1. Projet individuel au démarrage. Si vous avez une idée et êtes en train de la tester, Claude Code + Plan Mode suffira pendant un mois. Ajoutez l’association lorsque vous atteignez un goulot d’étranglement au niveau de la vitesse.

2. Budget strict. Si la limite est de $20/mois, prenez Claude Pro et n’y pensez plus. Claude seul couvre 80% des tâches d’une personne qui code en mode vibe coding.

3. Architecture simple. Un site Web avec un formulaire, un bot avec quelques scénarios, un script servant de wrapper d’API—répartir le travail par couches n’apporte rien ici. Claude Code seul peut s’en charger.

4. Tout fonctionne déjà. Si vous utilisez déjà Claude Code et que, depuis un mois, il n’a bloqué sur aucune tâche et n’en a échoué aucune, ne réparez pas ce qui fonctionne. Ajoutez Codex lorsque le besoin devient évident.

Et à l’inverse—des signes clairs qu’il est temps d’ajouter un deuxième outil :

• Claude Code est devenu un goulot d’étranglement : vous l’attendez au lieu de travailler.
• Beaucoup de tâches répétitives d’infrastructure sont apparues (migrations, CI, tests) que vous détestez faire avec Claude.
• Différentes personnes de l’équipe utilisent déjà différents outils—une langue commune est nécessaire.
• Les benchmarks montrent que Codex traite plus vite votre type de tâches (par exemple, les opérations de terminal).

Comment configurer cette association en une soirée#

Un plan concret pour votre première soirée :

1. Étape 1 : Installer Codex CLI

   Dans le terminal, exécutez npm install -g @openai/codex. Connectez-vous avec codex login—un navigateur s’ouvrira et vous vous connecterez à votre compte ChatGPT. Codex détectera votre abonnement (Plus / Pro) et utilisera ses limites.

2. Étape 2 : Rédiger AGENTS.md comme document opérationnel

   Examinez CLAUDE.md et réutilisez les règles communes dans AGENTS.md : tests, lint, format des commits, dossiers interdits et stack. Les préférences conversationnelles peuvent aussi être communes. Adaptez les commandes propres à chaque outil et gardez hooks exécutables et MCP dans leurs configurations respectives ; un Markdown copié ne les configure pas.

3. Étape 3 : Choisir un modèle pour votre projet

   Si vous codez seul avec CI, utilisez le modèle 1 (Claude écrit, Codex relit). S’il s’agit d’un nouveau projet et que vous avez besoin de rapidité, utilisez le modèle 2 (Codex rédige, Claude nettoie). Si le projet est établi et comporte une couche d’infrastructure, utilisez le modèle 3 (répartition par couches).

4. Étape 4 : Expérimenter pendant une semaine

   Utilisez le modèle choisi pour 5-7 fonctionnalités. Notez le temps passé. Consignez quel outil a mieux géré chacune d’elles. Au bout d’une semaine, vous aurez un profil réel de votre utilisation.

5. Étape 5 : Configurer la synchronisation des règles

   Ajoutez un script scripts/sync-agent-rules.sh (voir la section sur la synchronisation). Branchez-le comme hook pre-commit ou via une GitHub Action. Ensuite, les règles seront automatiquement propagées dans les deux fichiers.

Cette association n’a rien de magique. C’est simplement deux esprits au lieu d’un, chacun couvrant les points faibles de l’autre. L’essentiel est de ne pas rester bloqué sur « Claude ou Codex » alors que la bonne réponse est depuis longtemps « Claude et Codex—pour différents types de tâches ».

Ressources pratiques sur le travail avec des agents : documentation Ailoot.

Autres ressources et outils : Ailoot.