J’utilise Claude Code pour tout le reste, sauf pour coder

Le 3 avril 2026, j’ai dit que je reviendrais dans 30 jours pour raconter honnêtement ce qui s’était passé après l’annulation de Claude Max.

Je reviens avec onze jours d’avance.

Pas parce que je suis impatient. Parce que le schéma s’est déjà installé, et attendre jusqu’au 2 mai relèverait surtout de la mise en scène.

La chute paraît fausse au premier abord. Un outil qui s’appelle Claude Code est désormais l’outil que j’utilise pour presque tout sauf le code.

La version courte, c’est celle-ci :

• Codex avec GPT-5.4 en xHigh thinking a pris le siège du code.
• Claude Code avec Opus 4.7 en xHigh a pris tous les autres sièges de mon bureau.
• Le récit du "Codex pas cher" s’est fissuré dès que les vraies limites sont apparues.

Si je devais le résumer en une thèse la plus propre possible, ce serait probablement ça :

Codex-GPT-5.4 en xHigh pour tout ce qui touche au code. Claude Code avec Opus 4.7 en xHigh pour tout le reste.

C’est une séparation plus nette que ce que j’attendais il y a dix-neuf jours.

C’est aussi une réponse plus chère, et plus révélatrice psychologiquement, que ce que j’imaginais.

Ce qui a cassé en premier, ce n’était pas la qualité du code

Quand j’ai écrit le post d’annulation, l’histoire simple était séduisante :

• Claude Max : 200 $/mois
• Codex / ChatGPT : 20-25 $/mois
• l’écart de qualité d’exécution se réduisait très vite
• la fiabilité d’OpenAI paraissait meilleure

Ça ressemblait à un downgrade facile.

Ça ne l’était pas.

La première chose qui a cassé, ce n’était ni l’architecture, ni la qualité des plans, ni la discipline d’exécution.

C’était l’histoire des limites.

Ma vraie chronologie ressemble davantage à ça :

• Apr 6 : j’ai pris deux sièges ChatGPT Business à 25 $/mois chacun, avec une facturation mensuelle.
• Apr 6 : j’étais déjà en train de penser en termes de contournement. Pour garder à peu près le même rythme de code, je soupçonnais que j’allais avoir besoin d’environ trois comptes capables de faire tourner Codex.
• Apr 10 : après quelques jours passés à essayer de vivre dans cette configuration, j’avais assez d’éléments pour le dire clairement : trois comptes bon marché ne recréaient toujours pas ce que le plan Claude Max m’avait donné à son meilleur niveau.
• Apr 12 : j’ai pris ChatGPT Pro à 100 $/mois parce que plus j’utilisais Codex pour du pur travail de code, plus je voulais davantage de GPT-5.4 en high et xHigh reasoning, pas moins.

Voilà la première correction honnête à mon post du 3 avril.

Le remplacement n’a pas été "Claude Max à 200 $ devient Codex à 20 $".

C’était plutôt quelque chose comme :

• "Je n’ai plus besoin du même plan Anthropic qu’avant."
• "J’ai quand même besoin de plus de capacité Codex que ce que donne l’offre la moins chère."
• "La vraie comparaison, c’est la qualité du workflow sous de vraies limites, pas des captures d’écran de benchmarks."

Ma lecture actuelle, c’est qu’OpenAI est probablement agressif sur les limites parce qu’il veut gagner des parts de marché. C’est une inférence, pas une information interne. Et si c’est vrai, cette fenêtre ne restera peut-être pas ouverte éternellement.

Donc si tu fondes toute ta décision sur l’économie actuelle à 20 $, il faut au moins reconnaître que l’environnement tarifaire est peut-être tactique, pas stable.

Codex a pris le siège du code

La plus grosse chose que j’ai apprise, c’est que GPT-5.4 en xHigh thinking donne vraiment l’impression d’être un spécialiste du code.

Pas un spécialiste charismatique.

Pas un spécialiste chaleureux.

Pas spécialement quelqu’un qui cherche à devenir ton ami.

Mais un spécialiste.

Il y a une forme de dépouillement chez Codex que j’ai fini par aimer plus que je ne l’aurais cru. On a l’impression de travailler avec un ingénieur sans fioritures, soigneux, méthodique, et qui n’essaie pas de te jouer un personnage.

Ça compte plus que je ne l’imaginais pendant les longues journées de travail.

Le moment le plus clair pour moi, c’était le 17 avril. J’ai donné à Codex-GPT-5.4 en xHigh un plan validé, puis je l’ai laissé travailler. Il a tourné pendant trente à quarante-cinq minutes sur une seule session, en suivant le plan de près, en écrivant et en exécutant des unit tests, des integration tests et des browser tests en local, sans que j’aie besoin de le surveiller en permanence.

Je n’ai pas eu un autre outil capable de faire ça pour moi avec le même niveau de constance.

Ça a changé ma façon de voir Codex. Ce n’est plus seulement "assez bon sur des petites tâches". Il est capable d’une exécution longue et disciplinée quand le plan est clair.

Pour le pur travail de code, je m’appuie maintenant sur Codex presque tout le temps :

• architecture
• implémentation
• debugging
• design d’evals
• cadrage des tests
• nettoyage de pipeline
• logique produit pensée pour la prod

Le meilleur exemple d’avril, c’est Prova.

La majeure partie du travail utile sur Prova n’avait rien de glamour. Ce n’était pas "regarde comme le modèle est intelligent". C’était :

• évaluer des sprints composables
• resserrer la logique d’onboarding
• trouver des contradictions entre la génération de roadmap et l’état du sprint assigné
• améliorer le produit à partir de vraies lignes utilisateurs et d’un vrai comportement de prod

Ce type de travail s’accorde en fait très bien avec Codex.

Il est compétent, minutieux et étonnamment précis quand le job consiste à :

1. identifier la contradiction
2. isoler le bug logique
3. séparer la correction du territoire RFC
4. recommander le plus petit prochain mouvement défendable

L’un des exemples les plus clairs est venu d’une seule ligne de production Prova pour un utilisateur avec une intention builder.

Le système avait :

• étiqueté un utilisateur à intention builder comme marketing_vp
• assigné table-stakes-diagnostic
• généré une roadmap qui commençait plus tard dans le parcours
• affiché une carte Context Check juste après l’onboarding

Ce qui a rendu cet épisode utile, ce n’était pas seulement le diagnostic, mais la boucle de relecture croisée.

Opus 4.7 m’a amené aux trois premiers problèmes :

• un bug de calcul de track
• un bug de timing
• une question builder-opener / RFC

Puis GPT-5.4 a poussé l’analyse plus loin et a attrapé la contradiction qu’Opus avait manquée :

• le premier sprint assigné et la roadmap générée racontaient déjà deux vérités différentes au même utilisateur

Ça comptait. La conversation est passée de "est-ce qu’on shippe le Builder RFC maintenant ?" à "corrigeons d’abord la contradiction live, puis on reviendra au RFC".

Je n’ai pas eu l’impression d’un modèle qui essayait de m’impressionner. J’ai eu l’impression d’un senior SWE qui disait : règle d’abord la contradiction actuelle, ensuite on parlera théorie produit.

Ce schéma s’est répété assez souvent ce mois-ci pour que je cesse de voir Codex comme "l’alternative moins chère". Je le vois comme mon instrument principal pour coder.

Claude Code a pris tous les autres sièges

Si l’histoire s’arrêtait là, la réponse serait simple : passe à Codex et avance.

Ce n’est pas ce qui s’est passé.

Claude Code avec Opus 4.7 reste meilleur pour les travaux où le résultat dépend du goût, ou quand la boucle est longue, itérative et lourde en contexte.

C’est là que le titre de ce post cesse de paraître contradictoire et devient exact. Claude Code, la CLI vers laquelle je me tournais d’instinct quand il fallait écrire du code, est maintenant l’outil vers lequel je me tourne quand il faut faire tout ce qui n’est pas écrire du code.

Par "tout le reste", j’entends :

• écrire d’une façon qui sonne comme moi
• itérer sur la structure et le rythme
• naming et positioning
• slogans et formulation de marque
• prompts d’image pour les couvertures d’articles
• exploration de logo et d’identité
• meilleures passes /frontend-design quand le travail demande du jugement visuel, pas seulement une UI fonctionnelle
• longs fils de recherche où je construis une vision sur plusieurs sessions

D’après mon expérience de ces dix-neuf derniers jours, ça s’est maintenu encore et encore.

L’écart devient particulièrement visible quand il y a une boucle de feedback.

Claude comme Codex peuvent lire les anciens posts, inspecter les anciens prompts, et utiliser le travail existant comme référence. Mais quand je fais plusieurs tours de raffinement avec un feedback après chaque tentative, Claude continue à mieux comprendre, de façon plus fiable, la direction que je veux prendre.

Ça vaut pour l’écriture.

Ça vaut aussi pour les prompts d’image.

Ça vaut aussi pour le naming.

L’exemple produit le plus clair, c’est Prova. Je ne suis pas arrivé à ce nom avec Codex. J’ai eu besoin d’Opus pour ce type de travail. Et la même chose vaut pour beaucoup d’exploration autour du langage de marque. GPT-5.4 me donne des réponses solides, compétentes. Opus m’a donné une amplitude créative plus forte.

Le même schéma se retrouve aussi dans le design du site.

Le workflow /frontend-design sous Superpowers fonctionne toujours mieux pour moi avec Opus qu’avec GPT-5.4 quand le travail est piloté par le design plutôt que par l’ingénierie. Codex me donne quelque chose de fonctionnel. Claude me donne plus souvent quelque chose que j’aurais réellement envie de shipper avec fierté.

Donc si la question est :

"Est-ce que Codex a remplacé Claude pour tout ?"

Non.

Il a remplacé Claude sur le siège du code. Il ne l’a pas remplacé pour tout le reste.

Cette distinction compte.

L’habitude était réelle, et le manque aussi

J’utilisais Claude Code depuis environ 13 mois.

Une telle durée change ton langage corporel au travail, pas seulement ta liste de préférences.

Quand j’ai basculé plus franchement vers Codex, j’ai vraiment ressenti une forme de manque.

Pas parce que Codex était mauvais.

Parce qu’il était différent.

Les points de friction étaient petits, mais persistants :

• certaines confirmations de permission
• l’impression qu’il posait parfois une question de trop
• le ton stérile des réponses
• l’absence de cette "voix" familière de Claude dans la boucle

Ce ne sont pas des défauts objectifs.

Ce sont des différences de workflow.

Et l’habitude change la façon dont tu les ressens.

Je ne veux pas prétendre avoir traversé cette transition comme un économiste parfaitement rationnel.

Ce n’était pas le cas.

À un moment, je me suis surpris à faire passer du travail par Claude comme filet de sécurité de relecture, non pas parce que j’avais besoin du second avis, mais parce que l’attraction était plus forte que mon propre récit de "je fais une transition propre".

Ce que ça m’a appris, c’est que la vraie dépendance n’était pas seulement à la capacité brute de Claude. Elle tenait aussi au sentiment de sécurité que me donnait le fait d’avoir un autre système intelligent dans la boucle, auquel je faisais confiance autrement.

C’est aussi la raison pour laquelle la réponse finale, pour moi, n’allait jamais être "en choisir un pour toujours".

La psychologie du workflow compte aussi.

Codex a ses propres modes de défaillance

Cette période n’a pas été une longue série de victoires pour Codex.

J’ai aussi rencontré de vrais problèmes.

Le premier qui m’a paru spécifiquement lié à Codex est arrivé le 14 avril. Sur deux sessions terminal, j’ai eu cette erreur :

{
  "error": {
    "message": "Unknown parameter: 'prompt_cache_retention'.",
    "type": "invalid_request_error",
    "param": "prompt_cache_retention",
    "code": "unknown_parameter"
  }
}

Ce genre de chose compte parce que ça casse la confiance au niveau du harness, pas au niveau du raisonnement.

J’ai aussi remarqué que Codex semble plus strict sur ce que le modèle est autorisé à faire autour du déploiement ou en touchant la prod, même quand les approvals avaient déjà été accordés plus tôt dans la session.

Parfois c’est bien.

Parfois c’est agaçant.

Mais ça fait clairement partie de l’expérience utilisateur réelle.

Un petit exemple que je préfère vraiment chez Codex : vérifier le statut et les limites sans interrompre le flux principal. Pouvoir lancer /status sans attendre la fin du travail en cours, c’est une petite chose, mais au bout de dix-neuf jours ces micro-ergonomies s’additionnent.

C’est ce que je veux dire quand je dis que les outils ne se distinguent pas seulement par la qualité de leurs sorties. Ils se distinguent aussi par le ressenti du harness.

La fiabilité compte toujours, et avril n’a pas aidé Claude

L’une des raisons pour lesquelles je me suis senti à l’aise pour faire ce basculement au départ, c’était la fiabilité.

J’avais déjà écrit sur l’écart de statut à 90 jours entre Anthropic et OpenAI dans mon follow-up du 31 mars. Le tableau d’ensemble reste important :

Et avril a ajouté un autre rappel très concret.

Le 15 avril, Claude a de nouveau connu des elevated errors sur Claude.ai, l’API et Claude Code. La connexion a été touchée. L’API s’est rétablie d’abord. Les utilisateurs de Claude Code déjà connectés ont pu continuer à travailler, mais la connexion elle-même a été cassée pendant un moment.

Ça n’efface pas les forces de Claude.

En revanche, ça renforce l’argument pratique pour ne pas miser tout son workflow sur un seul fournisseur.

Ça reste l’une des leçons les plus durables de toute cette expérience :

Jouer sur deux tableaux n’est pas juste un luxe. C’est de la résilience opérationnelle.

Quand un fournisseur passe une mauvaise après-midi, tu continues de shipper.

Opus 4.7 a affiné le schéma, il ne l’a pas inversé

Claude Opus 4.7 est sorti le 16 avril. Publier un verdict honnête sans l’avoir sérieusement testé n’aurait pas été juste.

Je l’ai donc mis presque tout de suite face à un vrai diagnostic de code sur Prova.

Opus 4.7 m’a donné un bon premier passage. Il a identifié le bug de track, la carte Context Check mal timée, et la question plus large du builder-opener.

J’ai ensuite repassé ce diagnostic dans GPT-5.4 comme une critique, non pas comme un second avis aveugle, mais comme un reviewer relisant l’analyse écrite d’Opus. GPT-5.4 a capté la contradiction plus nette qu’Opus avait manquée : le produit assignait déjà un premier sprint tout en générant une roadmap qui commençait ailleurs. Ce n’était pas seulement une question de builder fit. C’était un vrai problème de correction en production.

Puis j’ai renvoyé le diagnostic révisé dans Opus, et il a convergé.

La surprise est venue dans l’autre sens.

Le 19 avril, j’ai remarqué quelque chose que je n’attendais pas : sur des tâches plus simples — une petite passe de code review, une exécution ciblée sur un petit changement — Opus 4.7 en xHigh est sensiblement plus lent que Codex-GPT-5.4 en xHigh. Je m’attendais à l’inverse.

Ce détail a re-fixé mon schéma.

Là où Opus continue de gagner clairement pour moi, c’est sur le travail chargé en goût, itératif et à long contexte que j’ai décrit plus haut. Là où Codex gagne clairement, c’est sur le diagnostic profond de code et aussi sur les petits tours de code du quotidien pour lesquels je me tournais autrefois vers Claude.

Donc la version honnête, c’est :

• Opus 4.7 peut encore me donner un bon premier passage sur des analyses de code plus profondes
• sur les tours de code plus légers, il me paraît actuellement plus lent que GPT-5.4 au même niveau de thinking
• combiné à l’expérience d’exécution continue du 17 avril, ça a poussé encore davantage le siège du code vers Codex au lieu de le rapprocher d’un match nul

Là où j’ai vraiment atterri

Si on retire le drama, les captures de prix, les captures de panne et le framing social, au 22 avril mon schéma de travail s’est stabilisé ainsi :

Pour tout ce qui touche au code

Je me tourne d’abord vers Codex avec GPT-5.4 en xHigh thinking.

Pourquoi :

• il se sent spécialisé
• il est méthodique
• il est soigneux
• il gère bien l’architecture et l’exécution
• il peut dérouler un plan complet validé avec unit tests, integration tests et browser tests pendant trente à quarante-cinq minutes d’affilée
• sur les tours de code du quotidien, il est pour le moment plus rapide qu’Opus 4.7 en xHigh
• il m’est maintenant plus facile de lui faire confiance sur du travail de code profond

Pour tout le reste

Je me tourne vers Claude Code avec Opus 4.7 en xHigh thinking.

Ça couvre maintenant :

• l’écriture qui doit sonner comme moi
• les prompts d’image pour les couvertures
• le naming, le positioning et le langage de marque
• les passes /frontend-design qui demandent du jugement visuel
• les longs fils de recherche où je construis une vision au fil des sessions
• la relecture de mes propres plans avant de les envoyer à Codex
• ce billet

Pourquoi :

• il suit mieux mon style
• il gère mieux l’itération créative guidée par le feedback
• il est plus fort sur le goût de marque et le goût design
• il reste le modèle auquel je fais le plus confiance quand le travail relève du jugement, pas de l’exécution

Pour les plans de code importants

J’aime toujours la boucle de relecture croisée :

• récupérer un plan chez l’un
• le faire critiquer par l’autre
• puis le resserrer à partir de là

Ce workflow me paraît toujours plus robuste que de miser sur la première réponse d’un seul modèle, aussi bon soit-il. La ligne builder-intent que j’ai détaillée plus haut est exactement la raison pour laquelle cette configuration me plaît encore.

Côté prix

Je n’ai pas fini sur une bascule simpliste et bon marché.

J’ai fini ici :

• ne plus vouloir de l’ancienne structure Claude Max à 200 $
• vouloir plus de capacité Codex, pas moins
• accepter ChatGPT Pro à 100 $ comme réponse plus réaliste pour mon plan code
• garder Claude dans la boucle pour tout ce qui n’est pas du code

Côté shipping

Le point entier de ce basculement, c’était de continuer à shipper. Ce n’étaient pas dix-neuf jours de benchmark d’outils sans rien à montrer. Dans la même fenêtre, la séparation Operator/Builder de Prova est sortie en live avec une vraie voie d’exécution Builder, deux gros billets sont sortis, et j’ai lancé un passage complet de traduction sur douze locales. La réponse à la question "est-ce que l’expérience m’a coûté en output ?" est non.

Si tu veux la version la plus comprimée :

J’ai annulé Claude Max, mais je n’ai pas éliminé Claude Code de mon travail. J’ai simplement déplacé Claude Code hors du siège principal du code, et je lui ai donné le reste du bureau.

C’est le résumé le plus vrai que je puisse donner.

Alors : est-ce que je prendrais la même décision une nouvelle fois ?

Oui.

Mais je la décrirais autrement maintenant.

Le 3 avril, le framing était :

"J’ai annulé Claude Max et je teste si Codex peut le remplacer."

Le 22 avril, le framing ressemble davantage à ceci :

"J’ai annulé Claude Max, constaté que Codex est pour moi le spécialiste du code le plus fort en ce moment, et j’utilise maintenant Claude Code pour tout le reste sur mon bureau — là où il reste le meilleur outil que j’ai."

Cette réponse est moins binaire, plus chère que la version simple pour les réseaux, et beaucoup plus proche de la vérité.

Questions fréquentes

Est-ce que Codex a réellement remplacé Claude pour le code ?

Pour moi, oui. Sur le pur travail de code, Codex avec GPT-5.4 en xHigh thinking est devenu mon siège par défaut. Opus 4.7 en xHigh peut encore me donner un bon premier passage sur le diagnostic profond, mais ce n’est plus pour moi le siège principal du code, et il me paraît plus lent sur les tours plus légers.

Est-ce que l’histoire du Codex bon marché a tenu ?

Pas vraiment. Dès que je l’ai utilisé à volume réel, l’économie de l’offre la moins chère a cessé de raconter toute l’histoire. Je suis passé à une offre OpenAI plus chère parce que je voulais plus de capacité, pas parce que l’expérience avait échoué.

Est-ce que tu as encore besoin de Claude ?

Oui, si ton travail comprend l’écriture, le design, le naming, les prompts d’image, les longs fils de recherche, ou toute autre boucle lourde en goût ou en jugement. Opus 4.7 en xHigh est devenu mon défaut pour tout ce qui n’est pas du code dans mon workflow.

Et la fiabilité ?

L’écart de fiabilité compte toujours. Avril l’a renforcé. La réponse n’est pas la panique. La réponse, c’est une couverture de secours.

Pourquoi publier avec onze jours d’avance ?

Parce que le schéma s’était déjà installé. Garder le billet jusqu’au 2 mai juste pour respecter le chiffre du titre initial aurait relevé du théâtre. La chose honnête était de dire ce que je fais réellement maintenant, puis d’avancer.

Alors, quel plan j’achèterais aujourd’hui ?

Si ton travail est surtout du code, je regarderais très sérieusement Codex / GPT-5.4 en premier. Si ton travail mélange code et beaucoup de travail créatif porté par le goût, je ne voudrais pas me passer de Claude. Et si 100 $ par mois est hors de portée pour l’instant, l’offre Codex à 20 $ reste utilisable pour des projets individuels plus petits — il faut simplement s’attendre à toucher les limites plus vite en travail soutenu sur plusieurs projets. Ma propre réponse, aujourd’hui, n’est plus une réponse à un seul outil.

---

Voilà la mise à jour honnête après dix-neuf jours.

Codex a pris le siège du code.

Claude Code a pris tous les autres sièges.

C’est pourquoi un outil littéralement appelé Claude Code est maintenant l’outil vers lequel je me tourne quand le travail consiste en tout ce qui n’est pas du code.

Et la vraie leçon, encore une fois, c’est que le workflow compte plus que le fandom.

Si tu as fait un basculement similaire ce mois-ci, j’aimerais vraiment savoir où tu as atterri. Est-ce qu’un outil a gagné complètement pour toi, ou est-ce que ta propre séparation s’est affinée elle aussi ?

À bientôt,
Chandler