J’hésite entre Claude et Codex

J’hésite entre Claude et Codex parce que chaque plateforme l’emporte sur une partie différente de mon travail. Codex me laisse travailler plus longtemps, propose une interface plus simple, répond plus clairement et produit de meilleurs frontends. Claude applique mes plans multi-agents et termine les modifications beaucoup plus vite, ce qui compte davantage quand une fonctionnalité touche plusieurs systèmes.

Partie du travail	Claude	Codex
Vue de l’architecture	Mon premier choix	Solide, mais perd le fil plus tôt
Orchestration de grosses fonctionnalités	Arrive généralement au bout en premier	Se transforme souvent en exécution bien plus longue
Implémentation frontend	Fiable mais souvent familière	Meilleure adaptation, meilleurs espacements et sens visuel
Communication écrite	Fable garde une vision claire du système	Sol l’explique généralement plus simplement
Quota inclus	Fable s’arrête à la moitié du quota hebdomadaire	Les resets donnent l’impression d’un quota bien plus élevé
Interruptions de sécurité	Plus de faux positifs dans mon travail	Imparfait, mais mieux réglé pour mes tâches
Passage du téléphone à l’ordinateur	Complet, mais réparti entre plusieurs modes	Plus cohérent au quotidien

Ce tableau explique pourquoi j’hésite. Codex gagne sur davantage d’aspects de l’expérience, mais Claude gagne sur les fonctionnalités d’envergure qui me prennent le plus de temps. Dans mon usage, aucun des deux modèles n’est clairement plus intelligent. Ce sont les systèmes qui les entourent qui déterminent celui que j’ouvre.

Pourquoi payer les deux ? Chacun répond à un besoin essentiel

Je paie les deux parce que Claude correspond à ma façon de développer de grosses fonctionnalités, tandis que je préfère Codex pour de nombreuses tâches plus petites. Abandonner l’un des deux me priverait de quelque chose que j’utilise chaque semaine. La réponse m’agace un peu, car ce sont deux de mes plus grosses dépenses logicielles récurrentes.

J’utilise des assistants de développement depuis les débuts de GitHub Copilot, y compris à l’époque où coder avec ChatGPT signifiait copier des extraits depuis une conversation dans le navigateur. Pendant des années, j’ai surtout utilisé Claude Max 20x pour le code et une formule ChatGPT moins chère pour la recherche. J’ai tendance à faire des recherches avant mes décisions techniques comme personnelles, et l’expérience proposée par OpenAI m’a toujours mieux convenu pour cela.

GPT-5.6 a changé l’équilibre. Dans mon travail, Sol offre à peu près les mêmes capacités que Fable 5. Je suis donc passé à la formule Pro 20x d’OpenAI tout en gardant Claude Max 20x. [4] [9] Je les utilise si intensivement qu’il m’est parfois arrivé d’avoir besoin d’un second abonnement Claude Max. Lorsqu’un quota s’épuise plus vite ou qu’une formule s’arrête plus tôt, la quantité de travail que je peux terminer dans la journée en dépend directement.

Dans la pratique, le quota d’OpenAI paraît souvent plus généreux. J’ai vu trois nouveaux resets globaux arriver entre le 26 août et le 1er septembre 2026, en plus de la campagne de resets que j’ai couverte en août. À mes yeux, ces célébrations servent aussi de marketing à un modèle capable de consommer très vite son quota. L’effet pour moi est plus simple : les resets ont augmenté la capacité disponible sur mon compte, ce qui rend Codex difficile à quitter.

Que fait Codex de mieux ? Le frontend et l’usage quotidien

Codex est meilleur dans les aspects du travail quotidien que je remarque immédiatement : le design frontend au premier essai, les explications écrites, le contrôle à distance et la façon dont les limites interrompent une tâche. Il est plus agréable à utiliser pour enchaîner les tâches bien délimitées, même si Sol n’écrit pas toujours un meilleur code backend.

Le travail frontend montre le mieux cette différence de qualité. Dès la première tentative, GPT-5.6 produit souvent des interfaces dont l’espacement, les alignements et la hiérarchie visuelle sont plus soignés. OpenAI affirme que le modèle améliore l’esthétique frontend et le jugement en matière de design. [1] Cette documentation décrit la capacité, mais ne compare pas Sol à Fable 5. La comparaison vient de mon propre usage : Codex crée plus souvent un design adapté au produit existant, tandis que Claude revient davantage à une structure familière si je ne décris pas précisément la direction visuelle.

Je trouve aussi Sol plus facile à lire. Il explique généralement ses décisions dans un langage courant, même lorsque le travail sous-jacent est technique. Fable me donne une meilleure vue de l’architecture, mais ses explications peuvent rester plus difficiles à suivre. Cette différence compte, car l’agent principal passe surtout son temps à discuter des compromis et à rendre compte de l’avancement, pas seulement à écrire du code.

Cette simplicité se retrouve lorsque je quitte mon bureau. OpenAI documente un accès à distance qui permet de poursuivre sur un téléphone une conversation Codex active sur un Mac ou un PC Windows connecté. Depuis le téléphone, je peux réorienter le travail et consulter les validations, les diffs ainsi que la sortie du terminal. [7] Codex propose aussi des tâches isolées dans le cloud, même si j’utilise surtout la connexion à ma propre machine. [21]

Claude couvre les mêmes usages à travers plusieurs modes. Il permet de poursuivre une session locale depuis un téléphone, de lancer un travail sur l’app de bureau avec Dispatch et de laisser tourner des sessions cloud une fois l’ordinateur éteint. [17] [18] [22] Les deux plateformes répondent donc aux principaux besoins, mais Codex les présente d’une manière que je trouve plus facile à suivre. Claude répartit des tâches proches entre Remote Control, Dispatch, les sessions locales et les sessions cloud.

Les limites d’utilisation accentuent cette différence. D’après la documentation actuelle d’OpenAI, les messages locaux et les tâches cloud de la formule Pro 20x partagent une fenêtre de cinq heures, et des limites hebdomadaires peuvent aussi s’appliquer. La formule ne repose donc pas uniquement sur un quota hebdomadaire. La documentation précise également qu’une exécution en cours peut continuer après que le compte a atteint sa limite, sous réserve des règles d’usage raisonnable. [4] Claude peut désormais attendre, puis reprendre une tâche interrompue après le reset d’une session. [20] Dans mon usage, la limite ressemble toujours davantage à un arrêt brutal au pire moment. Les règles exactes du reset m’importent moins que la possibilité d’amener la modification du jour jusqu’à une étape où je peux l’interrompre sans risque.

Pourquoi Claude termine-t-il plus vite ? Son orchestrateur reste concentré

Claude termine en premier parce que son orchestration correspond à ma façon de répartir le travail. Je confie le plan, les décisions et nos échanges à un modèle capable, pendant que des agents distincts mènent la recherche, l’implémentation, les tests et l’audit. Dans mes projets, Claude maintient plus efficacement cet agent principal dans son rôle de coordination.

Anthropic appelle ce principe général « orchestrator-workers » : un modèle central décompose la tâche, la délègue et rassemble les résultats. OpenAI documente le même principe sous le nom d’orchestration de type manager. [14] [15] Le nom compte moins que la séparation des rôles : l’orchestrateur garde l’objectif et les décisions, tandis que les agents exécutants reçoivent des tâches délimitées et renvoient des éléments vérifiables.

Les dynamic workflows de Claude Code rendent cette séparation particulièrement explicite. Claude écrit un script d’orchestration, lance des agents en parallèle et laisse l’environnement d’exécution gérer les embranchements ainsi que les résultats intermédiaires. Selon Anthropic, une même exécution peut lancer des dizaines ou des centaines d’agents au fil du temps, dont jusqu’à 16 simultanément si la machine possède assez de ressources CPU. [11] [12] Je n’ai pas besoin de centaines d’agents, mais j’apprécie que la conversation principale n’ait pas à absorber chaque lecture de fichier, résultat de commande et détour de débogage.

Dans mon workflow, Fable 5 tient le rôle principal. Il définit l’architecture avec moi et rédige le plan, puis des agents Opus implémentent des parties bien délimitées pendant que d’autres agents les testent et les relisent. Fable décide quels constats méritent une modification et me consulte lorsqu’un changement s’écarterait du plan. Je détaille l’implémentation dans mon workflow Opus 5 fondé sur un plan initial ; ici, le point important est que Fable reste responsable du résultat dans son ensemble.

orchestrateur

• Fable 5 conserve l’objectif, le plan, les décisions et la conversation avec l’utilisateur

délègue un travail délimité

agents exécutants

• agents de recherche cartographient le dépôt et les questions ouvertes
• agents Opus implémentent des parties bien délimitées
• agents de test et d’audit renvoient des preuves et des constats

renvoie des preuves

décision

• revue par l’orchestrateur accepte, refuse, réoriente ou consulte l’utilisateur
• fonctionnalité terminée plan respecté et vérifications réussies

Dans Claude Code, Fable et Opus disposent d’une fenêtre de contexte d’un million de tokens, mais le principal avantage vient du fait que les détails des agents exécutants restent en dehors de la conversation de l’orchestrateur. [13] Même une grande fenêtre finit par se remplir si chaque lecture de fichier, journal d’agent et résultat de test y entre. Les dynamic workflows séparent ces détails et laissent à l’orchestrateur un contexte encore exploitable.

OpenAI décrit la même séparation pour Codex : la conversation principale doit conserver les exigences et les décisions, tandis que les agents exécutants gèrent l’exploration, les tests et les journaux. [5] C’est pourquoi je pensais pouvoir transposer mon workflow. Pourtant, dans mes exécutions, l’agent principal de Codex sort plus souvent de ce rôle que celui de Claude.

Pourquoi Sol, pourtant plus rapide, termine-t-il plus tard ? Codex crée plus de travail

Sol peut générer du texte plus vite et terminer plus tard, car le débit ne mesure qu’une partie du travail d’un agent. Une grosse fonctionnalité prend surtout du temps pour choisir la suite, appeler des outils et coordonner les agents. Un débit plus élevé ne sert à rien si Codex crée du travail ou rouvre des décisions déjà prises.

Le 1er septembre 2026, Artificial Analysis a mesuré GPT-5.6 Sol à 77,1 tokens de sortie par seconde et Fable 5 à 66,9 dans les configurations comparées avec l’effort maximal. [3] Cet avantage de débit d’environ 15 % correspond à ce que je ressens lorsque je regarde Sol répondre. Il ne correspond pas à mes résultats de bout en bout, car Codex se crée souvent du travail supplémentaire alors que l’implémentation d’origine est déjà presque terminée.

L’élargissement du périmètre absorbe l’avantage de Sol

Une grande partie du temps supplémentaire vient de la sur-ingénierie. Je dois préciser très clairement que Codex doit conserver l’architecture existante, signaler les constats hors périmètre au lieu de les corriger, puis s’arrêter dès que les critères d’acceptation sont remplis. Sinon, Sol risque d’ajouter des couches de protection, de nouvelles fonctions utilitaires ou tout un sous-système pour résoudre un problème qui ne demandait qu’une modification ciblée. J’ai mesuré la même tendance pendant des audits : Sol relevait bien plus de problèmes possibles que Fable, mais la plupart étaient écartés lors du tri.

La coordination ajoute un autre délai. Dans les exécutions Codex Ultra que j’ai utilisées, l’agent principal avait du mal à se limiter au rôle d’orchestrateur. Il déléguait le travail, puis continuait à inspecter des fichiers, à les modifier ou à rouvrir des décisions pendant que ses agents exécutaient leurs propres tâches. OpenAI présente Ultra comme un mode de raisonnement maximal avec délégation automatique et indique que la conversation principale collecte les résultats des agents exécutants. [5] [19] La documentation ne promet pas que l’agent principal n’implémente rien. Mes tentatives pour lui imposer cette séparation ont réduit le problème sans le supprimer.

Plus de contexte et moins d’effort ne suffisent pas

Les longues exécutions exercent plus de pression sur le contexte, mais agrandir la fenêtre n’a pas résolu le ralentissement. Au départ, l’indicateur d’état de Codex affichait 272K tokens chez moi. J’ai donc réglé model_context_window sur un million dans la configuration. OpenAI documente ce paramètre, et Sol lui-même accepte jusqu’à 1,05 million de tokens. [6] [2] Ce chiffre de 272K correspond à ce qu’affichait ma configuration, pas à une valeur par défaut universelle établie par OpenAI. La fenêtre plus grande aide, mais Codex la remplit toujours rapidement lors d’une longue exécution multi-agents. Dès que la compaction du contexte commence, je suis moins certain qu’une contrainte donnée au début conserve le même poids six heures plus tard.

Un contexte long n’est pas gratuit non plus. Dans l’API d’OpenAI, les requêtes de plus de 272K tokens sont facturées au double du tarif d’entrée et à 1,5 fois le tarif de sortie, sur la totalité de la requête. [2] OpenAI n’indique pas qu’un quota ChatGPT Pro applique exactement les mêmes multiplicateurs, je n’utilise donc pas cette formule pour estimer mon abonnement. Elle montre néanmoins pourquoi agrandir une fenêtre ne rend pas automatiquement un long travail plus efficace.

Réduire le niveau d’effort de Sol n’a pas résolu le problème chez moi. Codex devient un peu plus rapide, mais le gain de temps reste faible face à la baisse de qualité du plan et de la revue. Définir un objectif n’aide pas non plus. OpenAI présente les objectifs comme un moyen de poursuivre le travail sur plusieurs échanges jusqu’à une condition d’arrêt vérifiable, ce qui correspond exactement à mon besoin. [8] Dans mes longues exécutions, l’objectif maintient Codex en activité sans l’aider à finir plus tôt.

Pourquoi Claude reste-t-il difficile à utiliser ? Limites et interruptions de sécurité

L’avantage de Claude pour l’orchestration s’accompagne de limites plus strictes et de davantage d’interruptions causées par des faux positifs. Son workflow pour les grosses fonctionnalités me convient mieux, mais je passe davantage de temps à surveiller quel modèle peut encore travailler et à reprendre le fil lorsqu’un contrôle de sécurité interrompt un travail ordinaire.

La limite de Fable est le problème le plus direct. Je paie Max 20x, mais Fable ne peut utiliser que la moitié du quota hebdomadaire inclus. [10] Je comprends qu’un fournisseur puisse rationner plus sévèrement son modèle le plus coûteux. Cela ne rend pas cette interruption compatible avec mon travail. Une grosse fonctionnalité ne devient pas moins importante lorsque ce quota réduit est épuisé.

Les interruptions de sécurité sont pires, car elles brisent ma concentration sans faire avancer le travail. Anthropic a reconnu que Fable 5 signalait des requêtes inoffensives pendant des tâches courantes de développement et de débogage, après sa sortie de juin 2026 et son retrait temporaire. [16] J’en rencontre moins qu’au début, mais elles surviennent toujours plus souvent que je ne le voudrais sur du travail sans danger.

OpenAI avertit également que les protections de GPT-5.6 peuvent intervenir sur des demandes légitimes. [1] Codex n’échappe donc pas aux faux positifs. Dans mes projets, ses classificateurs sont toutefois mieux réglés : je comprends généralement pourquoi une demande à double usage a provoqué une pause, et le développement ordinaire a moins de risques d’en déclencher une. Il s’agit de mon expérience, pas d’une comparaison publiée des taux d’erreur des filtres.

Ces défauts ne l’emportent pas sur l’avantage de Claude en matière d’orchestration. Ils expliquent pourquoi je continue à envisager Codex, même lorsque Claude vient une fois de plus de terminer une grosse implémentation.

Quand choisir Claude ou Codex ? Cela dépend du périmètre

Je choisis Claude quand il faut explorer le dépôt, choisir l’architecture, répartir l’implémentation et mener un audit indépendant. Je choisis Codex pour les modifications délimitées, le frontend et les sessions où son interface plus claire et son quota plus généreux en pratique comptent davantage. Pour la recherche, je commence par ChatGPT plutôt que par ces deux outils de développement.

Cette répartition repose sur le workflow, pas sur l’idée que Fable 5 serait plus intelligent que Sol. Si je donnais aux deux modèles une seule petite tâche clairement définie, je ferais confiance à chacun pour produire du code de qualité. La différence apparaît lorsqu’une fonctionnalité doit être découpée en plusieurs tâches dépendantes et qu’une seule conversation doit conserver le raisonnement qui les relie.

Codex deviendrait mon choix par défaut si son orchestrateur pouvait rester en dehors de l’implémentation, mieux maîtriser le périmètre, utiliser plus efficacement un long contexte et conduire une longue exécution jusqu’à un résultat vérifié. Il me serait plus facile de ne garder que Claude si le quota inclus de Fable était moins restrictif et si les tâches courantes de développement déclenchaient moins souvent ses protections.

Pour l’instant, je continue à payer les deux. Je lance mes grosses fonctionnalités dans Claude parce que son orchestration mène le travail jusqu’au résultat que j’ai demandé. Codex reste le produit que j’ai envie d’utiliser, car le reste de l’expérience est plus simple. Aucune des deux plateformes ne réunit encore l’orchestration de Claude et l’expérience produit de Codex dans un même workflow.