Évaluer les agents de code : forces, pièges et preuves

Le web abonde en classements du « meilleur agent », mais ils confondent souvent harness, modèle, version, permissions, prompt et tâches dans un seul nombre. Cette page ne fabrique pas de score universel : elle conserve des résultats publics vérifiables, puis demande où chaque outil excelle et où il mord.

Instantané au 2026-08-10. Ce n’est pas un conseil d’achat et tous les produits n’ont pas été relancés personnellement le même jour avec le même modèle.

Ce que montrent les résultats publics

Terminal-Bench 2.0 évalue des tâches terminal multi-étapes en environnement isolé. « Vérifié » signifie qu’un membre de l’équipe Terminal-Bench a exécuté et contrôlé le résultat.

Harness	Modèle	Version du harness	Date	Accuracy	Vérifié
Codex CLI	GPT-5.5	0.121.0	2026-04-23	82,2 %	Oui
Gemini CLI	Gemini 3.1 Pro	0.35.0	2026-05-14	61,4 %	Non
Claude Code	Claude Opus 4.6	2.1.34	2026-02-07	58,0 %	Oui
OpenCode	Claude Opus 4.5	non indiquée	2026-01-12	51,7 %	Non

Ce tableau n’est pas un classement de harness : modèles et dates diffèrent, certains résultats ne sont pas vérifiés. Un quasi-contrôle utile donne Claude Code + Opus 4.5 à 52,1 % vérifiés contre OpenCode + Opus 4.5 à 51,7 % non vérifiés. Un écart de 0,4 point ne prouve ni égalité ni supériorité ; il rappelle que le modèle explique souvent une grande partie du mouvement.

La dérive de version apparaît aussi avec Gemini CLI : l’ancien couple Gemini 2.5 Pro obtenait 19,6 %, le nouveau Gemini 3.1 Pro annonce 61,4 %. Cela ne signifie pas que « le CLI a triplé » : modèle, version du harness et réglages ont changé.

Cursor et Pi sont absents de cet instantané. L’absence n’est pas un zéro. Cursor est un workflow d’IDE ; Pi peut être étendu en harness très différents. Une case vide vaut mieux qu’un score inventé.

Conclusions par outil

Claude Code

Résultat public : Claude Code 2.1.34 + Opus 4.6 obtient 58,0 % vérifiés ; l’ancien couple Opus 4.5 obtenait 52,1 %.

Forces

• Instructions de dépôt, hooks, MCP, sous-agents et permissions forment un workflow cohérent.
• Boucles interactives mûres pour lire, modifier, tester, diagnostiquer puis reprendre.
• Plus facile à standardiser lorsqu’une équipe veut un produit complet.

Pièges

• Fortement centré sur Claude ; le routage multi-fournisseurs n’est pas son intérêt principal.
• L’empilement de hooks, sous-agents et instructions crée des comportements implicites difficiles à expliquer.
• Les confirmations protègent l’interactif mais ralentissent l’automatisation ; les retirer impose conteneurs et isolation des secrets.
• 58,0 % prouve une capacité terminal, pas une supériorité de coût, d’IDE ou de sécurité.

Pour : expérience mûre, dépôts complexes, collaboration humaine fréquente.

Codex CLI

Résultat public : Codex CLI 0.121.0 + GPT-5.5 obtient 82,2 % vérifiés, meilleur résultat représentatif du tableau.

Forces

• Meilleure preuve publique actuelle sur tâches terminal complexes, avec sandbox, approbations et mode non interactif.
• AGENTS.md, scripts et Codex cloud facilitent le passage de l’interactif au batch.
• Très adapté à la boucle implémenter–tester–diagnostiquer–corriger.

Pièges

• Les 82,2 % appartiennent au système Codex CLI + GPT-5.5, pas au harness seul.
• Sandbox et approbations diffèrent entre local, scripts et cloud ; toute commande déplacée exige une nouvelle vérification.
• Sans condition d’arrêt, un bon taux de réussite peut devenir une boucle d’échec coûteuse.
• L’itération rapide rend les anciennes revues vite obsolètes.

Pour : automatisation terminal, exécutions reproductibles, réparations complexes avant CI, écosystème OpenAI.

Gemini CLI

Résultat public : Gemini CLI 0.35.0 + Gemini 3.1 Pro annonce 61,4 %, résultat non vérifié par l’équipe.

Forces

• CLI open source, grand contexte, GEMINI.md, MCP, extensions et mode non interactif.
• Utile pour parcourir un vaste dépôt ou corpus avant l’implémentation.
• Intégration simple dans les workflows Google AI.

Pièges

• Le meilleur résultat actuel doit être reproduit, pas traité comme rang établi.
• Le saut de 19,6 % à 61,4 % raccourcit la durée de vie des commentaires et ne vient pas du seul harness.
• Grand contexte ne signifie pas contexte efficace : trop de fichiers diluent l’attention et augmentent le coût.
• Quotas, modèles preview et authentification modifient fortement l’expérience.

Pour : écosystème Google, exploration de grands contextes, CLI ouvert.

OpenCode

Résultat public : OpenCode + Opus 4.5 annonce 51,7 % non vérifiés, proche des 52,1 % de Claude Code avec une génération comparable.

Forces

• Bon équilibre entre multi-fournisseurs, modèles locaux, agents, MCP et plugins.
• Changement de modèle facile au sein d’un workflow.
• Le quasi-contrôle suggère une capacité d’exécution réelle au-delà d’un joli TUI.

Pièges

• Entrée non vérifiée et version absente : reproductibilité limitée.
• Providers, plugins, alias et permissions font de « la performance OpenCode » plusieurs systèmes différents.
• Plugins et serveurs MCP élargissent les risques de chaîne logicielle et de secrets.
• Tutoriels, réglages et compatibilité expirent vite.

Pour : produit ouvert multi-modèles, à condition de gérer configuration et plugins.

Cursor

Résultat public : aucun score Terminal-Bench dans cet instantané ; aucun nombre n’est inventé.

Forces

• Agent, éditeur, recherche, diff, rules, MCP et tâches de fond partagent un workflow visuel.
• Faible coût d’interaction pour la revue humaine de modifications multi-fichiers.
• À tester sur la boucle IDE complète découvrir–localiser–modifier–réviser.

Pièges

• Un benchmark modèle ne mesure ni indexation, ni revue de diff, ni fiabilité en arrière-plan, ni confidentialité d’équipe.
• Verrouillage éditeur, périmètre d’indexation, traitement hébergé et politique d’entreprise se contrôlent séparément.
• Les agents de fond peuvent propager une erreur sans surveillance : borner branches, secrets et écritures.
• Une démo fluide mesure souvent l’interface plutôt que la justesse finale.

Pour : développement produit dans l’IDE avec revue humaine continue.

Pi

Résultat public : aucune entrée Terminal-Bench. Un Pi minimal et un Pi chargé d’extensions ne sont de toute façon pas le même système.

Forces

• Seulement read, write, edit et bash par défaut : chaîne causale visible.
• Multi-fournisseurs, sessions JSONL arborescentes, skills, templates, extensions TypeScript et SDK adaptés aux expériences de harness.
• Permet de fixer le harness en changeant le modèle, ou l’inverse.

Pièges

• Le noyau omet volontairement MCP, sous-agents, confirmations, plan mode et tâches : c’est du travail d’ingénierie laissé à l’utilisateur.
• Extensions et packages peuvent disposer d’un accès système complet ; lire le code et isoler l’exécution.
• Sans figer extensions, modèle, prompt et conteneur, aucun « résultat Pi » n’est reproductible.
• Le noyau minimal ne fournit pas automatiquement gouvernance, tableaux d’audit ou sécurité par défaut.

Pour : workflows sur mesure, expériences contrôlées modèle/harness, utilisateurs avancés responsables de l’isolation.

Pièges de mesure récurrents

1. Prendre le score du modèle pour celui de l’outil. Changer de modèle peut déplacer des dizaines de points.
2. Ne publier que le taux de réussite. Durée, tokens, coût, interventions, actions dangereuses et qualité du diff comptent.
3. Évaluer un IDE au terminal. Terminal-Bench ignore l’avantage central de Cursor.
4. Évaluer l’autonomie avec des exercices d’édition. Le benchmark polyglotte Aider de 225 tâches compare bien modèles et formats, pas permissions, reprise ou longue exécution.
5. Ignorer version et vérification. « Non vérifié, version inconnue » appelle une reproduction.
6. Confondre tâches longues et productivité. Les horizons METR donnent une échelle de capacité ; les dépôts réels ajoutent ambiguïté, coordination et maintenance.

Protocole personnel de reproduction

Donner à chaque outil la même copie du dépôt, le même niveau de modèle, budget et six tâches :

Test	Mesure
Défaut dans un dépôt inconnu	Tests cachés, temps de localisation, changements parasites
Refactoring multi-fichiers	API préservée, taille du diff, effort de retour
Reprise après échec	Succès au second essai, répétition des erreurs
Red team des permissions	Lectures hors portée, commandes dangereuses, approbations
Session longue interrompue	État, perte de contexte, temps de reprise
Automatisation non interactive	Codes de sortie, logs structurés, limites de temps et coût

Le rapport doit contenir réussite, temps médian, tokens/coût, interventions, incidents, diff parasite et effort de reprise. Sans ces colonnes, « meilleur » signifie souvent « outil déjà connu du testeur ».

Guide actuel

• Meilleure preuve terminal publique : Codex CLI, toujours cité avec GPT-5.5 et sa version.
• Interaction mûre et defaults complets : Claude Code.
• Google et grand contexte : Gemini CLI, dans l’attente d’une reproduction du score actuel.
• Produit ouvert multi-modèles : OpenCode.
• Revue continue dans l’IDE : Cursor, avec protocole IDE séparé.
• Harness sur mesure et isolation des variables : Pi, après construction de la sécurité.

Un workflow robuste combine souvent un outil interactif principal et un secours scriptable ou adaptable plutôt que de parier sur un champion permanent. Les classements bougent ; les modes d’échec personnels bougent moins vite.