Claude Code 29 outils vs Codex 7 outils : deux philosophies de conception aux antipodes

J’en avais assez de courir après les mises à jour hebdomadaires de Claude Code et de Codex, alors je suis reparti aux fondamentaux. J’ai ouvert chaque définition de type SDK, chaque system prompt, chaque schéma de configuration que j’ai pu trouver. Je voulais comprendre non seulement ce que chaque outil fait, mais pourquoi le nombre d’outils diverge aussi radicalement.

Claude Code expose 29 outils. Codex en expose 7. Ce ratio me taraudait, parce qu’il ne peut pas s’expliquer par un simple écart de fonctionnalités. Deux équipes bien financées avec des ingénieurs de haut niveau n’atterrissent pas accidentellement sur un ratio de 4:1. L’écart est délibéré, et le raisonnement qui le sous-tend révèle deux philosophies genuinement différentes sur la façon dont l’IA devrait interagir avec votre environnement de développement.

La granularité des outils est une décision de sécurité

La différence la plus frappante concerne la gestion des opérations sur les fichiers. Claude Code découpe la manipulation des fichiers en quatre outils distincts : Read, Write, Edit et MultiEdit. La recherche dispose aussi de ses propres outils dédiés, avec Grep et Glob totalement indépendants de Bash. Cela signifie que vous pouvez configurer settings.json pour autoriser Read tout en bloquant Write. Vous pouvez laisser l’agent explorer votre codebase sans jamais lui accorder la permission de modifier un seul fichier. Le contrôle des permissions s’exerce au niveau de l’outil.

Codex emprunte une autre voie. Il donne à l’agent shell, apply_patch et file_read comme primitives de base. Tout le reste passe par le shell. Vous voulez chercher dans des fichiers ? C’est une commande shell. Vous voulez lister des répertoires ? Shell encore. La sécurité ne vient pas des permissions au niveau de l’outil, mais des règles execpolicy qui font du pattern-matching sur des commandes shell spécifiques, les classifiant en catégories allow, prompt ou block.

Aucune des deux approches n’est mauvaise. Le modèle de Claude Code vous offre des verrous granulaires, mais exige de maintenir une surface d’outils plus large. Le modèle de Codex est plus simple à raisonner, mais reporte l’application de la sécurité sur du string-matching de commandes shell, ce qui devient fragile quand les commandes se font créatives. J’ai vu des cas où une chaîne de pipes bien construite contourne une règle execpolicy écrite pour la version simple de la même commande.

Le tableau complet :

• Claude Code (29 outils) : 4 outils fichiers (Read/Write/Edit/MultiEdit), 3 outils de recherche (Glob/Grep/LS), 2 outils web, 3 outils cron, 4 outils MCP, Bash, et d’autres encore
• Codex (7 outils) : shell, apply_patch, file_read, web_search, update_plan, write_stdin, js_repl

Le déploiement des skills divise l’écosystème

Les deux outils ont adopté le standard ouvert Agent Skills, où un seul fichier SKILL.md définit le comportement d’un skill. La structure est identique. Le modèle de distribution ne l’est pas.

Codex a construit un système de distribution centralisé. Exécuter $skill-installer tire des skills sélectionnés depuis le dépôt officiel de skills d’OpenAI. Passez une URL GitHub et vous pouvez installer des skills tiers. Il y a même $skill-creator pour générer de nouveaux skills de façon interactive par conversation. L’expérience ressemble à npm : une commande, un registre, disponibilité immédiate.

Claude Code a pris le chemin inverse. Vous créez des fichiers SKILL.md dans .claude/skills/ manuellement, ou vous installez des bundles depuis des dépôts git via /plugin marketplace add. Il n’existe pas de registre officiel unique. Les skills se découvrent à travers des dépôts communautaires, des liens partagés et le bouche-à-oreille.

J’ai d’abord préféré le modèle centralisé de Codex parce que la découvrabilité est meilleure. Mais après avoir utilisé les deux pendant plusieurs semaines, l’approche décentralisée présente un véritable avantage : je peux modifier un fichier skill en cours de session et les changements s’appliquent immédiatement sans redémarrage. Avec les skills installés de Codex, les modifications nécessitent une réinstallation. Quand vous itérez sur un workflow personnalisé, cette différence compte plus que prévu.

Comparaison en un coup d’oeil :

• Invocation : Claude Code utilise /skill-name, Codex utilise $skill-name
• Stockage : .claude/skills/ vs .agents/skills/
• Skills intégrés : Claude Code livre /simplify, /batch, /loop, /claude-api ; Codex livre $skill-installer, $skill-creator
• Distribution : marketplace décentralisé vs dépôt centralisé

Les diagnostics de session, c’est là que l’écart devient concret

Les deux outils partagent les bases : /model, /plan, /review, /clear, /fast. La divergence apparaît dans l’introspection de session.

Claude Code a beaucoup investi pour vous permettre de comprendre ce qui se passe à l’intérieur de votre session. /compact déclenche manuellement la compression du contexte. /context montre ce qui est chargé. /cost suit les dépenses en tokens en temps réel. /doctor diagnostique les problèmes de configuration. /rewind revient à un état de conversation précédent. /insights analyse un mois de patterns d’utilisation et suggère des améliorations. /usage affiche la consommation cumulée sur plusieurs sessions. Ce sont sept commandes dédiées uniquement à la compréhension et à la gestion de l’état de session.

Codex s’est concentré ailleurs. /personality ajuste le style de communication de l’agent. /theme modifie l’apparence visuelle. /apps gère les applications connectées. Ce sont des fonctionnalités de personnalisation UX, pas des outils de diagnostic.

Cela reflète une division philosophique plus profonde. Claude Code traite la session comme quelque chose que vous devriez activement surveiller et piloter. Codex la traite comme quelque chose qui devrait simplement fonctionner en arrière-plan pendant que vous vous concentrez sur la personnalisation de l’expérience. Après des mois d’utilisation, je me retrouve à vouloir les deux. Les diagnostics me sauvent quand une session déraille, mais j’apprécie aussi de pouvoir ajuster la personnalité quand je passe d’un travail d’architecture détaillé à des corrections de bugs rapides.

• Claude Code (~35 commandes + 4 skills intégrés) : fort sur les diagnostics de session comme /compact, /context, /cost, /doctor, /rewind, /insights, /usage
• Codex (~19 commandes) : plus fort en personnalisation UX avec /personality, /theme, /copy, /apps, /skills, /agent, /tools

Les architectures d’équipes partent d’hypothèses différentes

La façon dont chaque outil gère la collaboration multi-agents révèle peut-être la différence de conception la plus profonde.

Les Agent Teams de Claude Code utilisent une communication pair-à-pair. Les membres de l’équipe s’envoient des messages directement sans passer par un agent principal. Ils partagent une liste de tâches et se coordonnent de façon autonome. Vous pouvez faire tourner de 2 à 16 agents, et ils négocieront entre eux qui fait quoi. J’ai testé cela avec trois agents sur une tâche de refactorisation, et la consommation de tokens était 3 à 7 fois plus élevée qu’une session unique faisant le même travail. Le surcoût de coordination est bien réel. Mais quand la tâche bénéficie genuinement d’une exploration parallèle (comme le débogage d’une race condition où vous voulez des agents sondant différentes hypothèses simultanément), le modèle P2P trouve des réponses plus vite.

Codex utilise un modèle hub-spoke. Les agents enfants ne rapportent qu’au parent. Il n’y a pas de communication latérale. La commande spawn_agents_on_csv crée des agents en masse depuis un fichier CSV, optimisé pour les tâches embarrassingly parallel où chaque unité de travail est indépendante. Par exemple : “appliquer cette migration à 200 fichiers” ou “exécuter cette vérification sur chaque endpoint de cette liste.”

Le P2P n’est pas universellement meilleur. J’ai gaspillé des tokens significatifs sur une tâche batch simple parce que les agents de Claude Code ne cessaient de discuter de leurs travaux qui se chevauchaient. Le hub-spoke de Codex aurait été le bon choix pour ce travail en particulier.

• Claude Code : messagerie P2P avec liste de tâches partagée, 2 à 16 agents, support tmux split-pane
• Codex : architecture hub-spoke, création d’agents en masse depuis CSV via spawn_agents_on_csv

La granularité des hooks détermine la profondeur de l’automatisation

Claude Code vous permet d’intercepter l’exécution des outils à plusieurs points du cycle de vie. PreToolUse se déclenche avant l’exécution d’un outil, vous permettant de valider ou modifier l’appel. PostToolUse se déclenche après, pour que vous puissiez attacher un formateur qui s’exécute automatiquement à chaque sauvegarde de fichier. Les hooks Notification capturent les communications de l’agent. PreCompact se déclenche avant la compression du contexte, vous donnant l’occasion de préserver les informations critiques. Les HTTP Hooks peuvent envoyer du JSON en POST vers des URLs externes, connectant Claude Code à des pipelines CI, Slack, ou des tableaux de bord personnalisés.

Codex reste simple. Un fichier execpolicy avec des règles allow/prompt/block appliquées aux commandes shell. C’est toute la surface d’extensibilité pour contrôler le comportement de l’agent.

J’ai mis en place un hook PostToolUse qui exécute Prettier après chaque opération Write. Cela m’a pris cinq minutes et a éliminé toute une catégorie de prompts de suivi liés au formatage. Ce type d’automatisation chirurgicale n’est pas possible dans le modèle de Codex, où il faudrait inclure “et exécuter prettier après l’écriture” dans chaque prompt ou l’intégrer dans un skill.

Mais la simplicité de Codex a aussi de la valeur. Je n’ai jamais accidentellement cassé mon setup Codex avec un hook mal configuré. Je l’ai fait deux fois avec Claude Code, une fois avec un hook PreToolUse qui bloquait silencieusement des lectures de fichiers légitimes et a causé vingt minutes de débogage confus.

• Claude Code : PreToolUse, PostToolUse, Notification, PreCompact et HTTP Hooks
• Codex : fichier de règles execpolicy avec trois niveaux (allow/prompt/block)

Choisissez l’architecture, pas la liste de fonctionnalités

La comparaison 29 contre 7 n’est pas une question d’un outil plus capable que l’autre. C’est deux réponses différentes à la même question de conception : dans quelle mesure un agent IA de codage doit-il décomposer ses capacités en unités individuellement contrôlables ?

Claude Code répond “tout”. Chaque opération obtient son propre outil, sa propre surface de permissions, ses propres points de hook. Cela vous donne un contrôle maximal au prix d’une complexité de configuration. Codex répond “seulement l’essentiel”. Les opérations de base obtiennent des outils dédiés ; tout le reste passe par le shell avec des garde-fous basés sur des politiques. Cela vous donne la simplicité au prix de la granularité.

Quand je choisis quel outil utiliser pour un projet donné, la liste de fonctionnalités compte à peine. Ce qui compte, c’est si le projet a besoin d’un contrôle de permissions granulaire (codebase réglementé, plusieurs contributeurs avec des niveaux d’accès différents) ou d’une simplicité légère (projet solo, itération rapide, configuration minimale). L’architecture sur laquelle vous construisez façonne chaque décision de workflow qui s’ensuit.