Blog • AI / Agent

Les AI Coding Agents ne se limitent plus à la complétion : que se disputent Codex, Claude Code, OpenCode et DeepSeek Harness ?

Il y a deux ans, « l’IA qui écrit du code » voulait encore dire la suggestion de la ligne suivante dans l’éditeur. En 2026, ce qui tourne dans le terminal est une autre catégorie de produits : Codex, Claude Code, OpenCode, DeepSeek Harness — ils modifient des fichiers, lancent des tests, appellent MCP, et peuvent ouvrir des sous-Agents pour enquêter en parallèle.

En surface, les quatre vendent le même ensemble : LLM + outils + Agent loop. Le vrai champ de bataille n’est pas la checklist de fonctionnalités, mais le centre d’architecture : qui renforce l’Agent, qui gère les frontières d’exécution, qui mise sur l’indépendance du modèle, qui fait du runtime lui-même une pièce remplaçable.

Cet article clarifie :

• Ce qu’un Coding Agent apporte vraiment au-delà de la complétion
• Le problème central que chacune des quatre optimise
• Les différences d’architecture entre Claude Code / Codex / OpenCode / DeepSeek Harness
• La carte du contrôle : ce que gèrent le modèle, le runtime, la politique et l’humain
• Pourquoi JSON Schema et les contrats d’outils restent le socle commun, et comment les valider localement dans JSONNote

Ce qui se dispute vraiment

La complétion répond à « que mettre sur la ligne suivante ». Un Coding Agent répond à « comment finir cet objectif dans un vrai dépôt » : lire le contexte, choisir des outils, modifier le code, lancer des commandes, lire le résultat, décider à nouveau.

La boucle sous-jacente est presque identique :

User goal
  → Agent loop
  → LLM decides next action
  → Tool / environment executes
  → Result returns to context
  → Agent decides again

Le modèle raisonne et choisit la prochaine action ; le harness décide ce qu’il voit, quels outils il peut appeler, ce que les outils font vraiment, comment l’état est persisté, quelles actions exigent une approbation, et ce qui compte comme tâche terminée. Même un modèle fort échoue si le contexte est incomplet, le contrat d’outil lâche, les permissions trop larges, ou les échecs non récupérables.

Aussi la concurrence 2026 ne se résume plus à « qui a le meilleur score de benchmark », mais à « qui organise le plus clairement l’intelligence, l’exécution, la politique, les outils et le contrôle humain ». Pour l’assemblage en quatre couches, voir :

Pile technique Agent IA 2026 : LLM, MCP, Function Calling, JSON Schema

Quatre centres d’architecture

D’abord tracer les frontières. Les checklists de fonctionnalités vont se ressembler, mais la question centrale diffère :

La dernière ligne n’est pas un classement, mais la frontière produit : achetez-vous « un assistant plus fort », « un environnement d’exécution plus contrôlable », ou « une plateforme Agent extensible ».

Claude Code : centré Agent

Claude Code se comprend mieux comme un produit centré sur l’Agent principal. Skills, MCP, sous-Agents, Hooks, permissions servent tous à rendre le même Claude Agent plus efficace — pas à découper l’Agent loop lui-même en noyau remplaçable.

Points d’extension typiques :

• CLAUDE.md : contexte et conventions au niveau projet
• Skills : paquets d’expérience et de workflows réutilisables
• MCP : connexion aux systèmes externes
• Subagents : isolation de sous-tâches spécialisées et de leur contexte
• Hooks / Permissions : règles déterministes accrochées au cycle de vie

Le compromis d’ingénierie est clair : Agent probabiliste + Hooks déterministes. Lancer les tests après une modification, bloquer les commandes dangereuses, approuver d’abord les chemins protégés — on ne doit pas compter sur le modèle pour « s’en souvenir à chaque fois ».

Adapté à : workflows clairs, priorité à l’expérience et à la qualité de contexte, équipes qui étendent la boucle principale avec Skills et sous-Agents.

Codex : centré exécution

Codex (y compris Codex CLI) pousse le problème vers la couche d’exécution : dès qu’un Agent peut modifier des fichiers, lancer un shell, installer des dépendances, toucher le réseau et les credentials, il faut répondre à deux questions distinctes — frontières de capacité et permission actuelle.

Deux mécanismes, deux rôles :

Le principe est la minimisation des capacités : ne pas donner d’abord tous les droits puis demander « d’être prudent », mais resserrer l’environnement d’abord, puis élargir au besoin. CLI en Rust, défaut collé aux endpoints OpenAI, et un récit sandbox assez fort — tout cela suit la ligne « l’Agent doit travailler sur un vrai ordinateur ».

Adapté à : effets de bord à haut risque, traces d’exécution auditables, scénarios où approbation et isolation sont des citoyens de première classe. Dépôt open source :

openai/codex.

OpenCode : indépendance du modèle

La différenciation d’OpenCode n’est pas « une syntaxe Skills de plus », mais une posture par défaut : le modèle est interchangeable. Open source MIT, terminal-first, avec de nombreux fournisseurs et modèles locaux (ex. Ollama / LM Studio). La flexibilité vit surtout dans la config — providers, models, permissions, themes — pas dans un bus de plugins qui démonte le noyau du harness.

Conclusion produit très concrète : si vous vous méfiez du verrouillage, ou si la même session doit basculer entre plusieurs modèles, la question centrale d’OpenCode est « comment ne pas être lié à un fournisseur de modèles ».

Il gagne souvent sur :

• Multi-modèles / multi-fournisseurs comme capacité par défaut
• Licence open source et écosystème communautaire
• « Changer de modèle » comme opération de première classe, pas un bonus vendeur

Le coût : frontières d’exécution et profondeur de plugins ne sont pas forcément le premier argument de vente. Vous achetez un harness à modèles interchangeables, pas le produit sandbox le plus lourd, ni un noyau plateforme « Everything is a plugin ».

DeepSeek Harness : centré runtime

DeepSeek Harness (dsh) pousse encore plus loin : et si l’Agent Loop lui-même n’était pas un noyau permanent ? Le slogan de la preview publique est Everything is a plugin — modèles, outils, skills, sessions, sandbox, stockage, loop, ordonnancement, UI sont tous remplaçables.

Ce n’est pas « noyau stable + points d’extension périphériques ». La frontière est poussée vers l’intérieur : le mécanisme qui pilote l’Agent peut aussi être recombiné. Les capability seams font dépendre les consommateurs du contrat, pas d’une seule implémentation : shell local vs shell conteneur, modèle distant vs inférence locale, ReAct loop vs workflow loop — on change de fournisseur sans réécrire tous les outils.

D’où une posture plus plateforme :

• Coding Agent : boucle ReAct
• Workflow Agent : workflow + Agent
• Tâches longues : objectif + ordonnancement + Job
• Sous-Agents hétérogènes : jusqu’à brancher d’autres backends produit

La composabilité a un coût : la surface conceptuelle Plugin / Service / Provider / Effect / Session est plus large. Pour un utilisateur terminal qui « veut juste que le dépôt soit modifié », la courbe d’apprentissage peut dépasser Claude Code ou Codex ; pour une équipe qui construit une plateforme Agent extensible, c’est précisément l’argument de vente.

Si vous vous intéressez surtout à l’API modèle DeepSeek et à la sortie JSON, commencez par :

DeepSeek V4-Pro : analyse complète

Carte du contrôle

Plus utile qu’une checklist de fonctionnalités : demander à qui revient chaque décision. Le tableau ci-dessous condense les styles de contrôle des quatre (OpenCode et dsh sont proches sur la « remplaçabilité », mais pas à la même profondeur) :

Un cran plus bas : comprendre la tâche et générer le plan penche vers le modèle ; valider les paramètres, juger les permissions, exécuter les outils, terminer l’exécution penche vers programmes et politiques ; les actions à haut risque impliquent encore l’humain. Les quatre couvrent ces mots, mais placent le poids sur des cases différentes.

Le contrat JSON reste le socle commun

Quel que soit le harness choisi, l’appel d’outil finit par une structure exécutable par machine : nom de fonction + paramètres JSON. inputSchema / outputSchema MCP, parameters de Function Calling, response_format de Structured Output — le langage sous-jacent reste JSON Schema.

Où apparaît le contrat :

Accident classique : parameters côté modèle et MCP inputSchema écrits en double, champs ou enums qui dérivent — on croit que « le modèle n’arrive jamais à appeler l’outil ». La correction : un seul contrat, deux points d’accroche. Contexte :

Pourquoi l’IA a besoin de JSON Schema et JSON Schema pour AI Agents : guide complet.

{
  "name": "run_tests",
  "description": "Run the project test suite and return a structured summary.",
  "parameters": {
    "type": "object",
    "properties": {
      "suite": { "type": "string", "enum": ["unit", "integration", "e2e"] },
      "path": { "type": "string", "minLength": 1 }
    },
    "required": ["suite"],
    "additionalProperties": false
  }
}

Pour déboguer ce chemin, tout se fait localement dans le navigateur, sans upload :

1. 1
   Formater les arguments

   Collez la chaîne arguments renvoyée par le modèle dans Formatage JSON, pour vérifier d’abord que c’est du JSON valide.

2. 2
   Valider contre le Schema

   Utilisez JSON Schema pour vérifier required, enum, additionalProperties.

3. 3
   Comparer la dérive

   parameters côté modèle et MCP inputSchema avec JSON Diff pour voir si les champs restent alignés.

Comment choisir

Choisissez selon les contraintes, pas selon la hype :

• Workflows clairs, forte expérience et Skills : plutôt Claude Code
• Effets de bord lourds sur une vraie machine, besoin de sandbox et d’approbations : plutôt Codex
• Multi-modèles, anti-verrouillage, priorité open source : plutôt OpenCode
• Construire une plateforme Agent extensible, loop interchangeable : plutôt DeepSeek Harness

On peut aussi combiner : par ex. OpenCode / dsh pour expérimenter multi-modèles, effets de bord de prod derrière des frontières façon Codex ; ou boucle principale Claude Code, systèmes externes via MCP. L’essentiel : ne pas faire du « score modèle » le seul critère d’achat.

FAQ

Quelle est la différence essentielle entre un AI Coding Agent et la complétion de code ?

La complétion ne propose que la ligne suivante ; un Coding Agent lit le dépôt, modifie des fichiers, lance des commandes, appelle des outils, et continue à décider dans une boucle selon les résultats. L’enjeu passe de la « qualité de génération » aux « frontières d’exécution et au contrôle du runtime ».

Qui est le meilleur entre Codex, Claude Code, OpenCode et DeepSeek Harness ?

Il n’y a pas de champion unique. Cela dépend de ce que vous optimisez : expérience et Skills → Claude Code ; sandbox et approbations → Codex ; multi-modèles et anti-verrouillage → OpenCode ; runtime remplaçable et plateforme → DeepSeek Harness.

DeepSeek Harness et OpenCode sont tous deux open source — quelle différence ?

La flexibilité d’OpenCode porte surtout sur la config modèles et fournisseurs ; DeepSeek Harness (dsh) transforme modèles, outils, loop, sandbox, sessions, etc. en plugins remplaçables — plus proche d’une plateforme de runtime Agent composable.

Pourquoi parler encore de JSON Schema ?

Paramètres d’outils, MCP inputSchema/outputSchema, Structured Output : le langage sous-jacent reste JSON Schema. Même un harness puissant échoue si des paramètres sales atteignent la couche d’exécution — la validation du contrat reste une responsabilité du Runtime.

Quelle couche surveiller en priorité quand on choisit un Agent ?

Surveillez le contrôle : qui choisit les outils, qui valide les paramètres, qui approuve les actions à haut risque, qui termine la tâche. Le score du modèle n’est qu’une entrée ; le harness décide si la tâche peut être menée à bien en sécurité.

En résumé

Codex, Claude Code, OpenCode et DeepSeek Harness partagent le même vocabulaire : LLM, outils, loop, contexte, Skills, sous-Agents, permissions, sandbox. Ce ne sont plus de « meilleures complétions » — ils se disputent où tombe le contrôle.

Claude Code renforce un Agent ; Codex laisse l’Agent agir de façon contrôlée dans un vrai environnement ; OpenCode mise sur des modèles interchangeables ; DeepSeek Harness fait du runtime et des capacités une plateforme composable.

La question importante n’est plus « comment appeler le modèle », mais « comment organiser l’intelligence, l’exécution, la politique, les outils, le contexte et le contrôle humain ». Le JSON de la couche contrat d’outils reste la couche que vous pouvez vérifier localement.

← Retour au blog