Claude Code ou Codex, finalement lequel ? La vraie réponse : les faire cohabiter sans accident

« Bon, finalement, lequel je dois utiliser ? »

Claude Code et Codex d’OpenAI. Plus on a touché aux deux, plus cette question laisse un goût d’inachevé. Moi aussi, au début, je me disais « il faut que j’en choisisse un ».

Mais après six mois d’usage, la réponse était d’une simplicité déconcertante. Ce n’est pas l’un ou l’autre. On utilise les deux. En répartissant juste le travail qu’on confie à chacun. C’est tout.

La question n’est pas « lequel est le plus intelligent ». C’est comme ne pas comparer la grandeur d’un couteau et de ciseaux. Pour les légumes, le couteau ; pour le papier, les ciseaux. Chaque outil a une forme où il excelle, et se tromper, c’est se couper le doigt. Aujourd’hui, je parle de « à qui confier quel travail » et de la disposition qui permet de faire tourner les deux en parallèle sans accident.

Je ne survends rien. Pas de conclusion du genre « celui-ci est au-dessus ». J’aligne honnêtement les mines que j’ai vraiment posées en faisant tourner ce site.

D’abord, la différence de caractère entre les deux

Laissons de côté la comparaison d’intelligence, parlons caractère.

Claude Code, c’est le coéquipier qui range avec vous, à vos côtés, votre chambre en désordre. Il ouvre votre dépôt, lit les règles écrites dans CLAUDE.md, et corrige en dialoguant, en reliant le contexte : « si on touche ici, autant arranger ça aussi ». Il sait saisir les contraintes du code existant. D’où sa force sur le refactoring d’un projet en place et les réglages fins en local.

Codex, lui, tient plutôt du sous-traitant installé dans une autre pièce, qui avance seul le travail confié. Lui passer une tâche d’un geste pour qu’elle tourne côté cloud, lui faire ouvrir une Pull Request pour la mettre en revue : ce style de délégation lui va bien. OpenAI présente d’ailleurs Codex comme un coéquipier à qui confier du travail de code (OpenAI : Introducing Codex). Lâcher la main et confier, voilà son fort.

En gros : Claude Code, c’est « à côté de vous » ; Codex, c’est « on dépose et on attend ». Retenez cette différence de température et le partage des rôles entre tout seul.

Cela dit, les noms de modèles, les tarifs et les limites de capacités écrits ici changent assez vite. Les deux évoluent à toute allure. Pour les points forts, les points faibles et les prix définitifs, vérifiez donc toujours le plus récent côté officiel (la documentation d’OpenAI et la documentation de Claude Code). Voyez cet article comme une « carte des concepts ».

Quel travail confier à qui ?

La carte seule étant peu pratique, je pose ma répartition réelle. C’est mon ressenti à l’instant T, pas une vérité absolue.

Ce que je veux faire	Responsable principal	Pourquoi
Refactoring touffu d’un dépôt existant	Claude Code	il lit le contexte alentour et évite les dégâts collatéraux
Conception et réglages en dialoguant en local	Claude Code	les allers-retours « non, plutôt comme ça » sont rapides
Délégation d’une tâche indépendante bien découpée	Codex	on lâche et on passe à autre chose
Ouvrir une PR et la mettre en revue	Codex	s’inscrit bien dans le flux délégation + revue
Respect des règles propres au projet	Claude Code	il lit CLAUDE.md et l’applique facilement
Faire tourner plusieurs tâches en parallèle	les deux	l’un en dialogue, l’autre en délégation, et ça ne coince pas

L’important, c’est la dernière ligne. Pas un choix binaire, un partage des rôles. Je me suis fixé sur un double maniement : peaufiner la conception devant l’écran avec Claude Code, et lancer à Codex les corvées découpées pour qu’il les avance dans l’autre pièce.

Et voici le cœur du sujet. Quel que soit l’outil, la logique du dispositif de sécurité est la même. Plutôt que de choisir l’IA la plus intelligente, je commence par construire une disposition où, même en tombant, on ne se blesse pas. Je l’appelle le « harnais (harness) = l’échafaudage, le baudrier de l’IA ». Pour le concept, voyez le guide complet du harness engineering.

L’échafaudage se range bien en pensant par quatre couches. Rien de compliqué.

Votre demande
  ↓
IA (Claude Code / Codex)
  ↓
[1] Couche permissions   ce qu'on autorise, ce qu'on bloque
[2] Couche enchaînement  dans quel ordre faire
[3] Couche vérification  avec quoi confirmer le « OK » à la fin
[4] Couche récupération  comment revenir en arrière en cas d'échec
  ↓
Fichiers / shell / services externes / déploiement

Si ces quatre-là manquent, que ce soit Claude Code ou Codex, on tombe à peu près au même endroit.

Là où la « cohabitation » fait mouche (trois cas)

1. La conception à Claude Code, la production en série à Codex

Un travail qui réclame des « allers-retours », comme la conception des données d’une nouvelle fonctionnalité, je le peaufine devant l’écran avec Claude Code. Une fois décidé, la tâche simple du genre « encore 8 fichiers de la même forme », je la découpe et la lance à Codex. Le temps où l’on réfléchit et le temps où l’on attend se sont proprement séparés.

2. Le corps à Claude Code, la revue à Codex

Le code écrit avec Claude Code, on veut parfois qu’un autre œil le regarde. Alors on passe la revue de PR à Codex. Plutôt que la même IA qui écrit et relit, le point de vue décale et les remarques se multiplient. Comme « premier tamis » avant la revue humaine, ce n’est pas mal.

3. Les opérations dangereuses, c’est toujours l’humain qui appuie en dernier, dans les deux cas

C’est le plus important. Déploiement, mise à jour de la base de prod, envoi de mail, git push, npm publish. Ce genre d’« opération qui ne se rattrape pas », que ce soit avec Claude Code ou Codex, on conçoit que ce soit l’humain qui presse le bouton en dernier. La génération et les brouillons, qu’ils soient automatiques. Mais les opérations qui partent vers l’extérieur, on les bloque. En les forçant côté échafaudage, on n’a pas d’accident en pleine nuit.

Le tracé des permissions, on le tient ainsi dans un fichier pour ne plus hésiter. Avec Claude Code, on l’écrit dans .claude/settings.json.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(node scripts/content-trend-report.mjs *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

L’astuce, c’est de ne pas écrire les interdits « au pif, ça a l’air dangereux ». rm -rf, git reset --hard, la lecture de .env, les commandes de déploiement de prod. On les écrit avec leur nom de commande précis. Pour le détail du montage, Claude Code settings est la porte d’entrée. Pour la pratique de la validation et du sandbox, j’ai tout regroupé dans le guide de configuration validation / sandbox.

Côté Codex, on retrouve la même idée. Avec un sandbox (espace de travail isolé) et l’approbation (approval), on cloisonne « jusque-là tu peux y aller seul, à partir d’ici tu demandes à un humain ». Les noms des réglages diffèrent, mais l’intention est la même. Une fois la logique du harnais acquise, elle se transpose même si l’outil change.

Mes trois plantages personnels

Sans frime. La cohabitation, au début, ça a pas mal accidenté.

Le premier. J’ai confié le même travail aux deux, et ça a viré au combat de réécriture. Un fichier que je corrigeais avec Claude Code, je l’ai aussi lancé à Codex avec « corrige ici ». Forcément, le changement de l’un écrasait celui de l’autre, et on ne savait plus ce qui était juste. Aujourd’hui, je sépare les périmètres : « ce fichier est côté Claude Code en ce moment ». On n’utilise pas la même planche à découper à deux en même temps. C’est l’évidence, je sais.

Le deuxième. La tâche que je passais à Codex était trop vague. Lancer au côté délégation une demande dépendante du contexte, du genre « corrige au mieux », ça ne donne rien de bon. La délégation, c’est de la sous-traitance ; règle d’or : on la déchire en une forme qui se boucle de façon autonome avant de la passer. À l’inverse, un travail qui exige du contexte, on ne force pas la délégation et on l’avance en dialogue avec Claude Code. La forme de la demande décide du choix de l’outil.

Le troisième. J’ai tourné sur « je vérifierai moi-même plus tard », et ça a lâché les jours chargés. Il m’est arrivé d’avancer sans m’apercevoir qu’une URL publique restait en 404, qu’une balise pub avait disparu. Le contrôle à l’œil, quand on est débordé, on le saute immanquablement. Alors les vérifications qu’une machine peut faire, on les confie à la machine. Par exemple, je tape désormais une petite vérification du genre « la page publiée est-elle vivante ? » avec ce script.

// scripts/verify-published-page.mjs
const url = process.argv[2];

if (!url) {
  throw new Error("Usage : node scripts/verify-published-page.mjs <url>");
}

const response = await fetch(url, { redirect: "follow" });
if (!response.ok) {
  throw new Error(`La page a renvoyé ${response.status} : ${url}`);
}

const html = await response.text();
const checks = [
  ["title", /<title>.+<\/title>/i],
  ["description", /<meta name="description"/i],
  ["contenu principal", /<article|data-pagefind-body|blog-post/i],
];

for (const [name, pattern] of checks) {
  if (!pattern.test(html)) {
    throw new Error(`Élément manquant : ${name} sur ${url}`);
  }
}

console.log(`OK : ${url}`);

Ce n’est pas une vérification parfaite. Mais les accidents idiots du genre « je croyais avoir publié et c’est un 404 », « une balise importante avait disparu », ça les arrête. L’IA a tendance à ne regarder que la dernière ligne du log d’échec et à corriger à côté ; décider d’avance, en code, ce qui vaut OK, ça fait mouche.

Par où commencer

Ne montez surtout pas un double maniement entièrement automatique d’emblée. Il y a un ordre.

D’abord, répartir une tâche du jour entre le côté « qui demande de réfléchir » et le côté « qui peut attendre ». La partie qui exige du jugement, en dialogue avec Claude Code. La tâche simple découpée, en délégation à Codex. Rien que ça, et la vitesse ressentie change.

Ensuite, basculer toutes les opérations dangereuses sur « demander à un humain (ask) ». Déploiement, push, envoi, base de prod : au départ, attente de validation sans discussion. Seules celles qu’on a vues sûres montent ensuite en automatique. On élargit plus tard. Au départ, étroit.

Enfin, garder sous la main un gabarit de demande prêt à l’emploi évite de dévier à chaque fois. Voici mon modèle pour déléguer à Codex. On copie-colle et on remplit les trous.

# Tâche (en unité qui se boucle de façon autonome)
<ex. : ajouter des tests unitaires aux fonctions de formatage de date sous src/utils/>

# Périmètre autorisé
- toucher : <ex. : seulement src/utils/date.ts et tests/date.test.ts>
- ne pas toucher : <ex. : les autres fichiers. Ne pas lire les fichiers de config ni .env>

# Conditions d'achèvement (ce qui vaut OK)
- npm run test passe en entier
- ne pas changer la signature des fonctions existantes
- garder le diff minimal en dehors des nouveaux fichiers

# À ne pas faire
- ne pas git push (s'arrêter à la présentation de la PR / du diff)
- ne pas ajouter de dépendances de sa propre initiative
- aucune opération de prod, déploiement ou envoi

Le truc, c’est de mettre noir sur blanc le « périmètre à ne pas toucher » et l’« à ne pas faire ». L’IA déléguée a parfois la bonne idée de toucher à des endroits superflus ; on l’enclôt dès le départ. C’est aussi une parade contre l’accident où des instructions d’un document externe sont prises pour des ordres de travail (l’injection de prompt). Cette façon d’éviter les demandes dangereuses, je l’ai détaillée dans le contrôle terrain pour éviter les prompts dangereux.

Ce que j’ai testé, concrètement

Voici ma conclusion après six mois de cohabitation des deux pour faire tourner ce site.

Là où l’effet a été le plus grand, c’est, contre toute attente, moins les « règles d’interdiction » que la « frontière laissée en ask ». Brouillons d’articles, traductions, propositions de refactoring : automatiser ça avec Claude Code ou Codex pose peu de problèmes. Mais le déploiement, le git push, l’envoi de mail, la mise à jour de l’URL de prod, on garde la validation humaine. Rien qu’en défendant ce point, le nombre de frissons a chuté d’un coup.

À l’inverse, le franc échec, c’est la méthode qui entasse toute la marche à suivre dans un long prompt. À vouloir tout faire faire d’un coup, la session s’alourdit et s’arrête plus facilement en route. Des consignes courtes, et les règles d’exécution déplacées côté échafaudage (settings, ligne d’approbation). Cette voie-là est nettement plus reproductible.

Et le ressenti du partage. Lâcher le « je dois en choisir un » a été le plus efficace. Comme tenir à la fois couteau et ciseaux : Claude Code à côté, Codex dans l’autre pièce, en parallèle. Cette sensation d’avancer deux fois plus avec un seul cerveau, une fois goûtée, on n’en revient pas. Mais, je le répète, les points forts, les prix et les modèles des deux évoluent vite ; avant d’investir sérieusement, vérifiez le plus récent côté officiel.

En résumé

Ma réponse à « Claude Code ou Codex, lequel ? », c’est « les deux. Mais en répartissant le travail qu’on confie et les opérations qu’on bloque ».

• corriger à vos côtés, c’est Claude Code ; déposer et attendre, c’est Codex
• un travail qui exige du contexte, en dialogue ; un travail découpable, en délégation
• quel que soit l’outil, la logique du dispositif (permissions, enchaînement, vérification, récupération) est la même
• les opérations dangereuses (déploiement, envoi, base de prod), c’est l’humain qui appuie en dernier

Le temps passé à hésiter sur le choix de l’outil, convertissez-le en temps pour construire un échafaudage. La qualité du travail se joue moins sur l’IA la plus intelligente que sur la disposition qui l’entoure.

Si vous voulez cadrer ensemble la conception des permissions, la CI et les règles d’exploitation d’équipe, j’ai réuni des modèles prêts à l’emploi dans la liste des supports. Et pour un accompagnement adapté à votre dépôt, passez par formation et conseil.