Codex ou Claude Code : lequel pour quelle équipe ?

La question arrive presque toujours sous la même forme, en fin de réunion, sur le ton de l'arbitrage rapide : « on part sur Codex ou sur Claude Code ? » Comme s'il s'agissait de choisir entre deux voitures sur un parking, avec une fiche technique pour chacune. J'y réponds de plus en plus lentement, parce que les équipes que j'accompagne m'ont appris que la réponse ne se trouve presque jamais dans les outils.

Codex et Claude Code produisent tous les deux du code correct : ce qui les sépare n'est pas leur niveau, c'est la posture de travail que chacun installe par défaut dans une équipe. L'un tire vers la délégation asynchrone relue en pull request, l'autre vers le pilotage synchrone dans votre arbre de travail, et le bon choix est celui que votre organisation sait déjà tenir.

Un comparatif de fonctionnalités est périmé avant d'être lu

Il existe déjà dix pages qui alignent les cases à cocher de ces deux outils, et toutes se sont trompées au moins une fois dans l'année : les deux éditeurs se copient en quelques semaines, une capacité exclusive d'un côté apparaît de l'autre au trimestre suivant, et la fiche technique que vous avez lue décrit un objet qui a déjà bougé. Quand je regarde en arrière les décisions d'outillage prises avec mes clients, la séparation est nette. Celles qui portaient sur la capacité technique ont mal vieilli, toutes sans exception, parce qu'une capacité de modèle se rattrape en un cycle de développement. Celles qui portaient sur la façon de travailler autour de l'outil tiennent encore, parce qu'une habitude d'équipe met des mois à s'installer. Le guide de l'IA agentique que je maintiens est construit sur ce constat. La seule comparaison qui vaille porte donc sur ce qui bouge lentement : ce que l'outil attend de vous, à qui il rend des comptes, et quelle trace il laisse.

Deux postures : confier un lot, ou tenir la barre

La première posture, c'est la délégation. Vous découpez un lot de travail, vous le décrivez le plus précisément possible, vous le confiez à un agent qui travaille hors de votre vue, dans un environnement qui n'est pas votre machine, et qui revient avec un diff. Vous le relisez comme vous reliriez la contribution d'un prestataire extérieur : sans avoir vu le chemin, uniquement sur le résultat. Le travail humain se concentre aux deux extrémités, la spécification et la revue, et il n'y a presque rien au milieu. Codex pousse naturellement vers cette forme, parce que toute son ergonomie est organisée autour de la remise d'un résultat relu.

La seconde posture, c'est le pilotage. L'agent tourne là où vous êtes, dans votre arbre de travail, avec vos accès, et vous voyez chaque étape pendant qu'elle se produit. Vous corrigez une hypothèse à la dixième ligne au lieu de découvrir l'erreur à la centième, et le travail humain est étalé en continu plutôt que concentré aux extrémités. Claude Code pousse vers cette forme. Aucune des deux n'est un palier de maturité : ce ne sont pas le niveau débutant et le niveau avancé d'un même métier, ce sont deux métiers différents. Et chacun des produits peut être tordu vers la posture de l'autre, au prix d'un frottement quotidien.

Ce que chaque posture réclame de votre contexte

Les deux ont besoin que votre projet soit écrit quelque part : les conventions, les contraintes métier, les arbitrages et leurs raisons. Sur ce point, rien de nouveau, et c'est le chantier que je décris dans la préparation qui prime sur l'exécution. Mais les deux postures ne tolèrent pas du tout la même dose de contexte implicite, et c'est là que les équipes se trompent. En pilotage synchrone, l'humain présent comble les trous en direct, sans même s'en apercevoir : il précise, il recadre, il répond à une question que l'agent n'aurait jamais pu résoudre seul. Le résultat est bon, et le trou reste entier.

En délégation asynchrone, personne n'est là pour combler quoi que ce soit. Chaque hypothèse manquante se transforme en pull request à jeter, et vous payez le contexte absent en travail perdu, visible, mesurable. C'est un paradoxe que je trouve utile à poser franchement : la posture vendue comme la plus confortable, celle où l'on confie et où l'on revient plus tard, est en réalité la plus exigeante des deux sur l'écrit. Elle marche très bien sur un dépôt dont la mémoire est à jour, et c'est précisément pour ça que j'ai investi dans le dépôt-mémoire avant de déléguer quoi que ce soit.

À qui l'agent rend des comptes, et quelle trace il laisse

La posture de délégation s'insère dans une mécanique de responsabilité que vous avez déjà : une proposition, un relecteur nommé, un historique. La trace est un diff et un fil de revue, exactement au même endroit que celle de vos développeurs, ce qui est un avantage considérable quand il faut justifier une modification six mois plus tard. Le prix de cette propreté, c'est que le raisonnement est perdu. Vous héritez du résultat sans le chemin, et quand une décision bizarre apparaît dans le code, plus personne ne sait si c'était un choix assumé ou un accident que le relecteur a laissé passer un jour de charge.

La posture de pilotage produit l'inverse. Le raisonnement est entièrement visible pendant qu'il se construit, vous pouvez le challenger, et c'est là que la compétence se transmet. Mais cette trace est volatile : elle vit dans une session, sur une machine, et elle disparaît si personne ne prend la peine d'écrire ce qui a été décidé. C'est exactement le rôle que joue la discipline du loop engineering : transformer une conversation en artefact relisable. Quant à la confidentialité, la question n'a rien à voir avec la marque : elle porte sur le lieu d'exécution et sur les accès que l'agent détient.

Le profil que chaque posture avantage, et celui qu'elle expose

La délégation avantage les gens capables d'écrire une spécification complète et de relire un diff avec méfiance : des seniors, des tech leads, des profils qui savent déjà ce qu'ils veulent. Elle désavantage ceux qui apprennent en tâtonnant, parce qu'elle leur retire justement le tâtonnement. Elle a aussi un effet de charge que personne n'anticipe : un agent qui ouvre cinq propositions par jour dans une équipe qui en relit deux ne crée pas de la vitesse, il crée une file d'attente, et la frustration qui va avec. Si votre revue de code est déjà le goulot d'étranglement, cette posture l'aggrave mécaniquement.

Le pilotage avantage les profils qui aiment rester dans la boucle, et il transmet beaucoup mieux : regarder un agent travailler et l'arrêter au bon moment apprend davantage que relire son résultat. En contrepartie, il ne passe pas à l'échelle sur l'attention disponible, puisqu'une personne ne pilote bien qu'une chose à la fois. Et il bute sur une habitude : si votre équipe ne vit pas dans un terminal, un outil dont le terminal est le centre de gravité sera adopté par deux personnes et ignoré par les dix autres. C'est l'un des mécanismes de rejet décrits dans pourquoi les développeurs seniors rejettent l'IA.

La grille que j'utilise quand on me pose la question

Cette grille ne désigne pas de vainqueur, et c'est volontaire. Elle désigne la posture qui a une chance de survivre à trois mois d'usage réel dans votre contexte, ce qui est une question très différente de celle du meilleur outil. Dans les faits, la plupart des équipes que j'accompagne finissent par utiliser les deux, avec une règle simple sur ce qui va où : le travail bien cadré et ennuyeux part en délégation, le travail d'exploration reste en pilotage. Cette règle vaut plus que le choix d'origine, parce qu'elle est écrite, qu'elle se discute en revue d'équipe et qu'elle survit au prochain changement d'outil.

Un dernier mot sur mon biais : j'écris ce blog avec l'un des deux, et cette familiarité n'est pas de l'objectivité. Ce que j'ai vu de plus solide ne dépend d'aucune des deux marques : une équipe avec une méthode claire et un outil moyen va plus loin qu'une équipe sans méthode avec le meilleur outil du marché. La ligne de budget qui change le résultat n'est pas la licence, c'est la semaine passée à écrire ce que votre dépôt sait de lui-même, et c'est par là que je commence quand j'accompagne un déploiement. Si vous devez trancher demain matin sans avoir ce temps, prenez celui que vos développeurs ont déjà envie d'ouvrir : l'envie est un critère plus fiable qu'un comparatif.