Claude Code ou Codex : la méthode compte plus que l’outil
Mike Codeur
J’ai annoncé que j’arrêtais Claude Code et Codex pour un outil inconnu. La formule attire l’attention, mais la conclusion de la vidéo est moins confortable : je n’ai abandonné ni Claude Code ni Codex.
Je les ai remis à leur place.
Comparer les modèles et les outils reste utile. Leur qualité, leur prix, leur vitesse, leur sécurité et leur ergonomie changent réellement le travail. Le problème commence quand on transforme ce choix temporaire en compétence durable. Si chaque nouvelle sortie oblige à reconstruire tout son processus, on a surtout appris une interface.
Trois couches à ne plus confondre
Le développement avec des agents devient plus lisible quand on sépare trois couches.
| Couche | Rôle | Exemples | Ce qui change vite |
|---|---|---|---|
| LLM | Comprendre, raisonner et générer | Claude, GPT, Gemini | capacités, prix, contexte |
| Harness, autrement dit harnais agentique | Donner au modèle un contexte, des outils, des permissions et une boucle d’exécution | Claude Code, Codex CLI, OpenCode | interfaces, intégrations, comportements |
| Méthode | Cadrer le problème, découper le travail et contrôler le résultat | critères d’acceptation, tests, review, portes de validation | beaucoup moins vite |
Le LLM est le moteur. Le harness organise l’exécution autour de ce moteur. La méthode décide quel travail doit être fait, dans quel ordre et avec quelles preuves.
Claude Code et Codex CLI ne sont donc pas des modèles. Ce sont des environnements d’exécution qui assemblent le contexte, appellent les outils, lisent le dépôt, gèrent les permissions et bouclent sur une tâche. Deux harnesses peuvent utiliser des modèles proches tout en produisant une expérience très différente.
Les outils comptent, sans devenir ton identité
Rester agnostique ne veut pas dire que tous les outils se valent. Un meilleur modèle peut résoudre un bug qu’un autre rate. Un harness mieux intégré peut réduire les frictions, limiter les erreurs et rendre les revues plus simples.
Je continue donc à comparer les outils. Je choisis le meilleur exécuteur pour le problème du moment. Je refuse seulement de placer toute ma méthode dans un produit que je devrai peut-être remplacer dans trois mois.
C’est le même piège que les anciennes guerres IntelliJ contre Eclipse. L’IDE influence le confort et la vitesse. Il ne remplace ni l’architecture, ni le diagnostic, ni les tests, ni la capacité à livrer un changement sûr.
Ce que je conserve au-dessus de Claude Code et Codex
Une méthode portable laisse des traces exploitables par le prochain outil :
- Un besoin borné. L’objectif, le périmètre et les contraintes sont écrits avant l’exécution.
- Un découpage visible. Les dépendances et l’ordre des tâches ne restent pas dans une conversation.
- Des artefacts de décision. Le PRD, l’architecture, les choix et les critères d’acceptation vivent dans le dépôt.
- Des rôles séparés. L’agent qui écrit ne valide pas seul son propre travail.
- Des portes bloquantes. Une étape ne passe pas si les tests, la review ou les preuves attendues manquent.
- Une boucle de retour. Les erreurs observées deviennent des tests, des règles ou de meilleures instructions.
Ces éléments survivent à un changement de modèle. Ils survivent aussi à un changement de harness, car ils ne dépendent pas d’un bouton ou d’une commande propriétaire.
Killer SaaS comme exemple, pas comme recette universelle
J’utilise cette logique dans Killer SaaS, ma méthode pour remplacer des logiciels trop coûteux par des produits ciblés. Le cadrage produit se fait une fois. Ensuite, chaque fonctionnalité passe par un cycle répété de recherche, design, plan, exécution, review et validation.
Claude Code ou Codex peuvent exécuter ce cycle. Leur rôle reste important, mais ils ne portent pas à eux seuls le savoir accumulé. Le périmètre, les décisions, les tests et les retours de review restent disponibles si je change d’exécuteur.
Cette méthode n’est pas universelle. Un projet legacy, un prototype, une migration réglementée et un produit greenfield n’ont pas le même niveau de risque. La compétence consiste à construire les bons contrôles pour le contexte, pas à copier un dossier de prompts.
Un test simple pour ton propre système
Pose-toi cette question : si tu remplaces demain Claude Code par Codex, ou Codex par un autre outil, que perds-tu ?
- Si tu perds surtout quelques raccourcis, ton système est portable.
- Si tu perds le contexte, les décisions, les critères et les tests, ton processus dépend trop de l’outil.
- Si personne ne sait expliquer pourquoi une modification est correcte, le problème n’est pas le modèle. Il manque une méthode de validation.
Utilise les meilleurs outils disponibles. Garde tes besoins, décisions, tests et preuves dans des formats que le prochain outil pourra reprendre.