# Claude Code 29 outils vs Codex 7 outils : deux philosophies de conception aux antipodes > Author: Tony Lee > Published: 2026-03-12 > URL: https://tonylee.im/fr/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ > Reading time: 9 minutes > Language: fr > Tags: claude-code, codex, ai-agents, developer-tools, ai-coding, security ## Canonical https://tonylee.im/fr/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Rollout Alternates en: https://tonylee.im/en/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ko: https://tonylee.im/ko/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ja: https://tonylee.im/ja/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ zh-CN: https://tonylee.im/zh-CN/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ zh-TW: https://tonylee.im/zh-TW/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Description J'ai épluché les définitions de types SDK et les system prompts des deux outils. L'écart 29 contre 7 n'est pas une question de fonctionnalités. C'est deux réponses fondamentalement différentes à la même question : comment un agent IA doit-il interagir avec votre système ? ## Summary Claude Code 29 outils vs Codex 7 outils : deux philosophies de conception aux antipodes is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - La granularité des outils est une décision de sécurité - Le déploiement des skills divise l'écosystème - Les diagnostics de session, c'est là que l'écart devient concret - Les architectures d'équipes partent d'hypothèses différentes - La granularité des hooks détermine la profondeur de l'automatisation - Choisissez l'architecture, pas la liste de fonctionnalités ## Content 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. ## Related URLs - Author: https://tonylee.im/en/author/ - Publication: https://tonylee.im/en/blog/about/ - Related article: https://tonylee.im/fr/blog/eight-hooks-that-guarantee-ai-agent-reliability/ - Related article: https://tonylee.im/fr/blog/claude-code-layers-over-tools-2026/ - Related article: https://tonylee.im/fr/blog/codex-folder-structure-why-config-breaks/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/fr/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/fr/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.