Outils CLI Agentic : Codex vs Claude Code
Les outils CLI d'Agentic sont des outils de codage IA capables de créer et de supprimer des fichiers, d'exécuter des commandes, de planifier et d'exécuter le codage de l'ensemble du projet. Nous avons évalué les principaux outils sur 10 scénarios de développement web concrets, en effectuant environ 600 contrôles de validation atomiques par agent et plus de 5 000 exécutions de tests automatisés au total, incluant la logique backend, les fonctionnalités frontend et la vérification de la cohérence sur plusieurs exécutions.
Résultats du benchmark Agentic CLI
Analyse des performances des outils CLI Agentic
Codex affiche le meilleur score global (67,7 %) et les meilleures performances côté serveur (58,5 %). Son score côté serveur devance de plus de 5 points de pourcentage celui de Junie (54,3 %), qui arrive en deuxième position.
Junie se classe deuxième au classement général (63,5 %), alliant une infrastructure backend robuste (54,3 %) à d'excellentes performances frontend (85,0 %). Son écart backend-frontend (30,7 points de pourcentage) est modéré par rapport aux autres agents, et il a mené à bien les 10 tâches avec une infrastructure backend opérationnelle pour 9 d'entre elles.
Claude Code obtient le meilleur score côté client (95,0 %), mais son score côté serveur (38,6 %) pénalise son résultat global (55,5 %). Ceci illustre la principale dynamique du graphique : si les performances côté client sont relativement élevées pour plusieurs agents, la correction du code côté serveur et le respect des contrats sont les principaux facteurs d’écart dans le classement.
L'écart le plus important entre l'interface utilisateur et le backend se trouve dans Claude Code (95,0 % pour le frontend contre 38,6 % pour le backend). À l'inverse, Codex combine un score élevé pour le frontend (89,2 %) avec le meilleur score pour le backend, ce qui explique sa première place au classement général avec une pondération de 0,7 pour le backend et de 0,3 pour le frontend.
Les agents les moins bien classés échouent pour différentes raisons. Goose obtient des scores proches de zéro, tant au niveau du backend (3,1 %) que du frontend (10,0 %), ce qui indique des problèmes d'exécution et d'exhaustivité basiques. Forge et Cline affichent des scores frontend modérés (45,8 % et 33,3 %) mais de faibles scores backend (20,1 % et 26,7 %), ce qui confirme que les problèmes de contrats et de routage côté backend sont prépondérants dans leurs résultats.
Vitesse vs score et utilisation des jetons vs score
Nous avons évalué l'efficacité d'exécution à l'aide du temps d'exécution moyen (secondes), de l'utilisation effective des jetons (entrée + sortie) et du score de précision combiné :
Aider occupe la position la plus équilibrée du graphique. Avec un score combiné de 52,7 %, il effectue les tâches en 257 secondes et consomme 126 000 jetons. C'est le seul agent qui allie une précision moyenne à élevée à un temps d'exécution relativement court et une consommation de jetons modérée.
Codex obtient le meilleur score global (67,7 %), mais à un coût plus élevé. Son temps d'exécution moyen est de 426 secondes et sa consommation de jetons est de 258 000. Le compromis en termes d'efficacité semble proportionnel au gain de précision.
Junie se classe deuxième en termes de précision (63,5 %) avec un temps d'exécution moyen de 483 secondes et 370 000 jetons effectifs. Comparé à Codex, il consomme 43 % de jetons en plus, ce qui représente une baisse de score de 4,2 points de pourcentage. Son ratio jetons/précision est moins favorable que celui d'Aider ou de Codex, mais il surpasse Claude Code tant en précision qu'en efficacité d'utilisation des jetons.
Claude Code est l'agent le plus coûteux parmi les plus performants. Il se classe troisième en termes de précision (55,5 %), mais nécessite 745 secondes et 397 000 jetons. Comparé à Aider, Claude consomme plus de trois fois plus de jetons pour un gain de score de seulement 2,8 points de pourcentage.
Kiro CLI est l'agent le plus rapide, avec un temps d'exécution de 168 secondes et un score combiné de 58,1 %. Cependant, Kiro n'a pas communiqué ses données d'utilisation des jetons. Nous avons donc mesuré sa consommation de crédits (46,1 crédits). Une comparaison complète de l'efficacité de Kiro est donc impossible, mais compte tenu de sa consommation de crédits, il figure parmi les plus économiques.
Dans les cas les plus simples, Goose affiche une faible efficacité. Il consomme 300 000 jetons et met 587 secondes pour un score de seulement 5,2 %. Une consommation élevée de jetons ne garantit pas l'exactitude des calculs dans ce cas précis.
Globalement, une consommation plus élevée de jetons n'est pas systématiquement corrélée à une meilleure précision. Le comportement architectural en matière de nouvelles tentatives et la stratégie de validation semblent influencer davantage l'utilisation des jetons que la profondeur brute de la résolution du problème.
Vous pouvez consulter notre méthodologie ci-dessous.
Comment fonctionnent les outils CLI d'agentic
Les outils CLI Agentic sont des agents autonomes qui fonctionnent au sein du terminal. Bien que la plupart des utilisateurs les déploient pour des tâches de programmation, ils peuvent exécuter n'importe quel flux de travail réalisable via des commandes shell.
Ces agents fonctionnent généralement en boucle, selon trois phases :
- Rassemblez le contexte
- Agissez
- Vérifier les résultats
Après vérification, l'agent recueille le contexte mis à jour et répète la boucle jusqu'à ce qu'il termine la tâche ou atteigne une condition d'arrêt.
La boucle est influencée par deux sources :
- L'utilisateur humain, qui fournit la tâche initiale et peut interrompre son exécution
- Le modèle, qui effectue la planification, le raisonnement et la sélection des actions
Le cadre d'agents structure le modèle. Il définit la planification du modèle, le moment d'exécution des commandes, la validation des résultats et les outils disponibles. Ces outils peuvent inclure l'exécution de commandes shell, l'accès au système de fichiers, le contrôle du navigateur , l'utilisation de l'ordinateur , les intégrations MCP ou des « compétences » réutilisables.
Les différentes architectures d'agents imposent des stratégies de planification, des politiques de nouvelle tentative et des logiques de vérification différentes. Certains agents privilégient la précision et un raisonnement plus approfondi, au prix d'une consommation de jetons et d'une latence plus élevées. D'autres privilégient la vitesse et un coût moindre, au détriment d'une robustesse comportementale réduite.
Intelligence modélisée vs architecture d'agent
Les différences de performances entre les outils CLI d'agents ne proviennent pas d'une seule source. Elles émergent de deux couches : le modèle de base et le cadre d'orchestration qui l'entoure.
Le modèle de base détermine la capacité du système à comprendre les exigences, à planifier les tâches en plusieurs étapes et à générer un code correct. Si le modèle interprète mal une contrainte ou produit une logique incorrecte, aucune orchestration ne pourra compenser entièrement cette erreur.
L'architecture de l'agent détermine cependant l'utilisation de ce modèle. Elle définit comment le contexte est recueilli dans l'espace de travail, quand les commandes shell sont exécutées, comment les résultats sont validés et si le système effectue des tentatives de redémarrage après un échec. Ces décisions influent sur le comportement d'exécution, le coût et la fiabilité.
Deux agents, dotés de modèles aux performances identiques, peuvent se comporter différemment. L'un peut tenter de se rattraper après un échec partiel, consommant ainsi davantage de jetons mais corrigeant ses erreurs initiales. L'autre peut s'arrêter rapidement à la première incohérence. L'un peut imposer une validation stricte avant de poursuivre, tandis que l'autre peut continuer avec des hypothèses non vérifiées.
Ce test évalue le système dans son intégralité. Il ne dissocie pas l'intelligence brute du modèle de la logique d'orchestration. Lorsqu'un agent consomme un nombre excessif de jetons ou qu'un contrat backend échoue, la cause peut résider dans la qualité de la planification, la politique de nouvelle tentative, la gestion du contexte ou la rigueur de la validation.
Il est essentiel de comprendre cette distinction. Un usage élevé des jetons n'indique pas nécessairement un raisonnement plus approfondi, et un score plus faible n'implique pas automatiquement une capacité de modèle sous-jacente moindre. Dans les environnements autonomes, l'architecture et le raisonnement du modèle interagissent en permanence.
Comportements des agents sur la tâche 6
Nous avons évalué les agents sur 10 tâches. Ci-dessous, nous présentons une analyse détaillée de la tâche 6 afin d'illustrer le comportement des différentes architectures d'agents soumises aux mêmes contraintes.
Tâche 6 : Système de tickets d'assistance (Web)
La tâche 6 consistait à construire un système de gestion des tickets d'assistance complet comprenant :
- Deux rôles d'utilisateur (client et agent)
- Authentification basée sur JWT
- Transitions strictes du flux de travail d'état
- Isolation des données (404 au lieu de 403 pour l'accès inter-utilisateurs)
- backend FastAPI
- Interface React/Vue/Svelte + Vite
- Commandes d'exécution déterministes
Le test de fumée a validé :
- bilan de santé
- Authentification à double rôle
- Opérations CRUD sur les billets
- Devoir et réponses
- transitions de statut
- Application des rôles
- Isolation des données
- Comportement lors de la connexion à l'interface utilisateur et après la connexion
Cette tâche met l'accent sur la gestion d'état, la validité des authentifications, le respect des contrats REST et l'intégration front-end/back-end. Consultez GitHub pour plus de détails.
Manuscrit
Installation
Installation globale avec :
- npm install -g @openai/codex
Vous pouvez également l'installer globalement avec Homebrew (macOS/Linux).
- brew installer –cask codex
Authentification
Après avoir configuré Codex, vous pouvez continuer avec votre compte ChatGPT ou avec votre clé API OpenAI. Aucune autre option de fournisseur n'est disponible.
Rapport de tâche
Codex a conçu un système fonctionnellement correct, mais s'est écarté du contrat REST spécifié. Un choix de méthode a réduit la conformité stricte malgré une logique métier correcte.
Comportement du backend
L'authentification, la gestion des tickets (CRUD), les réponses et les changements de statut ont fonctionné correctement. L'application des rôles et l'isolation des données ont été correctement mises en œuvre.
Le problème principal résidait dans une incompatibilité de méthode HTTP. Codex avait implémenté /tickets/{id}/assign et /tickets/{id}/status comme points de terminaison PATCH, alors que le test de validation nécessitait PUT.
Le mode adaptatif a permis de récupérer certaines fonctionnalités en tentant des méthodes alternatives. Le mode strict a échoué à toutes les étapes liées à ces points de terminaison.
Comportement de l'interface utilisateur
L'interface utilisateur a passé avec succès toutes les étapes de validation. Le processus de connexion et l'état post-connexion se sont déroulés correctement.
Junie
Installation
Junie est disponible via JetBrains Toolbox ou en tant qu'interface de ligne de commande autonome :
- curl -fsSL https://junie.jetbrains.com/install | bash
Authentification
Poursuivez avec votre compte JetBrains ou générez une clé API JUNIE sur junie.jetbrains.com/cli, ou exportez votre propre clé API depuis Anthropic, OpenAI, Google ou d'autres fournisseurs compatibles. Plusieurs options de fournisseurs sont disponibles.
Rapport de tâche
Junie a produit un système full-stack complet en 327 secondes. L'authentification, les opérations CRUD et l'isolation des données fonctionnaient correctement. Deux choix de conception de points de terminaison ont entraîné six défaillances du backend. L'interface utilisateur a passé avec succès toutes les étapes de validation fonctionnelle, mais affichait une interface uniquement textuelle, sans style visuel ni identité visuelle.
Comportement du backend
Junie a généré un backend FastAPI composé de 8 fichiers et un frontend React + Vite avec Tailwind CSS. Les données initiales comprenaient 2 utilisateurs et 3 tickets de statuts différents.
L'authentification, les opérations CRUD sur les tickets, les réponses, l'affichage des détails et l'isolation des données ont fonctionné correctement. Neuf des seize étapes de l'API ont été validées.
Les six échecs constatés étaient dus à deux problèmes. Premièrement, l'URL `/tickets/{id}/assign` était implémentée en POST au lieu de PUT, comme prévu, ce qui entraînait l'échec de l'attribution. Deuxièmement, aucun point de terminaison dédié `/tickets/{id}/status` n'existait. Les transitions de statut étaient gérées via un point de terminaison PUT unifié `/tickets/{id}` avec un champ `body`. Le test de non-réponse, qui ciblait directement `/tickets/{id}/status`, a renvoyé une erreur 404.
La logique de transition était correctement implémentée. La table de transition valide imposait le passage de « ouvert » à « en cours », de « en cours » à « en attente du client » ou « résolu », de « résolu » à « rouvert » et de « rouvrir » à « en cours ». Les restrictions de rôle pour la résolution (agent uniquement) et la réouverture (client uniquement) étaient présentes dans le gestionnaire de mises à jour unifié. Le point de terminaison d'attribution effectuait également la transition automatique des tickets ouverts vers l'état « en cours ».
Comportement de l'interface utilisateur
L'interface utilisateur a passé avec succès les 8 étapes de validation. Le formulaire de connexion s'est affiché correctement, l'authentification a été conservée et le comportement post-connexion s'est déroulé comme prévu. Aucun plantage ni erreur de console n'a été constaté.
Kiro CLI
Installation
Pour macOS/Linux/WSL :
- curl -fsSL https://cli.kiro.dev/install | bash
Image d'application Linux alternative (option portable) :
- Téléchargement : https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.appimage
Ensuite, exécutez :
- chmod +x kiro-cli.appimage && ./kiro-cli.appimage
Authentification
Vous pouvez conserver votre forfait Kiro-Code. Aucune autre option de fournisseur n'est disponible.
Rapport de tâche
Kiro a produit l'implémentation la plus rapide et la plus compacte. Les transitions d'état, l'application des rôles et l'isolation des données ont été correctement implémentées au niveau logique.
Cependant, le même modèle de conception de point de terminaison de mise à jour unifiée que celui utilisé dans Aider a provoqué six échecs de contrat. Un problème lié au cycle de vie de l'interface utilisateur a encore dégradé la note de l'interface. Le système est structurellement sain, mais s'écarte de la conception d'API spécifiée.
Comportement du backend
Kiro a généré une implémentation complète et compacte en environ 97 secondes. Le backend se composait d'un fichier main.py de 324 lignes, et le frontend d'une application React monofichier de 276 lignes. Au total, seulement 9 fichiers ont été produits. Les données initiales comprenaient 4 exemples de tickets avec différents statuts.
L'authentification, les opérations CRUD sur les tickets, les réponses, l'affichage des détails et l'isolation des données ont fonctionné correctement. Neuf des seize étapes de l'API ont été validées.
Les six étapes ayant échoué correspondent aux points de terminaison `/tickets/{id}/assign` et `/tickets/{id}/status`. Kiro a implémenté un point de terminaison PATCH unifié pour `/tickets/{id}` qui met à jour le statut, la priorité et l'affectation via des champs JSON. La logique métier est correcte, mais la structure du point de terminaison ne correspond pas au contrat attendu, ce qui entraîne des réponses 404.
Comportement de l'interface utilisateur
La vérification préalable du serveur a réussi et le serveur a démarré avec succès. Vite s'est lancé sans plantage.
Cependant, le formulaire de connexion ne s'est pas affiché. Playwright a expiré après 7 secondes d'attente pour le champ de saisie de l'adresse e-mail. Les diagnostics de la console ont révélé une erreur 422 lors du chargement initial de la page, probablement due à un appel `/auth/me` exécuté au montage sans jeton valide. Cela a empêché l'affichage du composant de connexion et bloqué les étapes suivantes de l'interface utilisateur.
Code Claude
Installation
Pour macOS/Linux/WSL, selon votre gestionnaire de paquets préféré, vous pouvez installer Claude Code avec l'une des méthodes suivantes :
- curl -fsSL https://claude.ai/install.sh | bash
- brew installer –cask codex
Authentification
Après avoir configuré votre code Claude, vous pouvez continuer à utiliser votre compte Claude. Aucune autre option de fournisseur n'est disponible.
Rapport de tâche
Claude Code a produit l'une des bases de code les plus structurées pour cette tâche. Cependant, un problème fondamental de validation JWT a rendu le backend inutilisable.
Ceci met en évidence une distinction clé dans l'évaluation des agents : l'exhaustivité structurelle ne compense pas l'exactitude de l'authentification.
Il a également consommé le plus grand volume de jetons parmi les agents évalués dans la tâche 6.
Comportement du backend
Les points de terminaison de connexion ont renvoyé un code 200 et émis des jetons JWT avec succès. Cependant, toutes les requêtes authentifiées suivantes ont renvoyé une erreur 401 « Impossible de valider les informations d'identification ».
Le problème semble provenir d'une incompatibilité entre OAuth2PasswordBearer(tokenUrl="auth/login") et le préfixe de route /auth. L'adaptateur Smoke a correctement détecté le point de terminaison de connexion, mais les jetons émis n'ont pas été acceptés par le middleware.
En conséquence, 13 des 16 étapes du système dorsal ont échoué.
De plus, Claude Code a implémenté un point de terminaison PATCH unique `/tickets/{id}` pour les mises à jour au lieu des points de terminaison dédiés `/assign` et `/status`. Cependant, ce choix de conception est devenu caduc suite à l'échec d'authentification.
Comportement de l'interface utilisateur
Le formulaire de connexion s'est affiché correctement. L'envoi du formulaire a renvoyé un code 200. Cependant, après la connexion, Playwright a détecté un plantage de navigation :
« Le contexte d’exécution a été détruit. »
Les journaux du navigateur ont affiché des réponses 401 sur les appels API authentifiés, ce qui a provoqué une rupture de l'état post-connexion.
Aide
Installation
Si vous avez déjà installé Python 3.8-3.13, commencez par installer aider :
- python -m pip install aider-installer
- aider-installer
Authentification
Connectez-vous à votre compte OpenRouter et autorisez-vous, ou exportez votre clé API dans votre environnement avec :
- export OPENROUTER_API_KEY="sk-or-v1-…"
Rapport de tâche
Aider était le générateur le plus rapide et le plus économe en jetons. Cependant, la conception de son API s'écartait des spécifications et l'interface de connexion ne s'affichait pas correctement.
Comportement du backend
L'authentification, les opérations CRUD sur les tickets, les réponses, la vue détaillée et l'isolation des données ont été correctement implémentées.
Au lieu de points de terminaison dédiés `/assign` et `/status`, Aider utilisait un point de terminaison PUT unifié `/tickets/{id}` pour toutes les mises à jour. Le test de non-régression s'attendait à des points de terminaison distincts, ce qui a entraîné des erreurs 404 pour les étapes d'attribution et de statut.
Comportement de l'interface utilisateur
L'interface utilisateur affichait le contenu, mais le formulaire de connexion n'apparaissait pas. Playwright a expiré en attendant le champ de saisie de l'adresse e-mail. Les étapes suivantes de l'interface utilisateur étaient bloquées.
OpenCode
Installation
Pour macOS/Linux/WSL :
- curl -fsSL https://opencode.ai/install | bash
Installation globale avec :
- npm i -g opencode-ai
Pour macOS/Linux, en tenant compte de votre gestionnaire de paquets préféré :
- bun ajouter -g opencode-ai
- brew install anomalyco/tap/opencode
- paru -S opencode
Authentification
De nombreux fournisseurs sont disponibles ; sélectionnez celui de votre choix et authentifiez-vous avec /connect.
Rapport de tâche
OpenCode a produit l'implémentation la plus conforme aux spécifications, avec une seule déviation dans un cas limite. Il a également consommé le plus faible volume de jetons parmi tous les agents de cette tâche.
Comportement du backend
L'authentification, les opérations CRUD, les réponses, l'attribution, les transitions de statut, l'application des rôles et l'isolation des données ont été correctement implémentées.
Les deux points de terminaison /tickets/{id}/assign et /tickets/{id}/status ont été implémentés comme prévu.
Le seul incident s'est produit lorsque l'agent a tenté de passer le statut à « en cours » après l'attribution. L'opération d'attribution ayant déjà fait passer le ticket à l'état « en cours », la seconde tentative a renvoyé une erreur 400 en raison d'une restriction stricte interdisant toute opération.
Le comportement du système dorsal était logiquement correct, mais le test de fumée attendait un succès idempotent pour des transitions répétées.
Comportement de l'interface utilisateur
L'interface utilisateur a passé avec succès les 8 étapes de validation. La page de connexion s'est affichée correctement, l'authentification a été maintenue et le comportement post-connexion a fonctionné comme prévu.
Forge
Installation
Pour macOS/Linux/WSL :
- curl -fsSL https://opencode.ai/install | bash
Authentification
Configurez vos identifiants de fournisseur de manière interactive en procédant comme suit :
- Connexion au fournisseur Forge
Et choisissez votre fournisseur.
Rapport de tâche
Une simple erreur de configuration du routage a provoqué des défaillances en cascade au niveau du serveur. Le nombre relativement faible de jetons de sortie suggère une implémentation peu profonde.
Comportement du backend
La connexion a réussi et des jetons ont été émis.
La création du ticket a renvoyé des redirections 307 au lieu de 200/201. Comme la création du ticket a échoué, les étapes suivantes faisant référence à $created_ticket.id ont échoué avec des erreurs 422.
Les réponses 307 proviennent probablement du comportement de redirection avec barre oblique finale dans FastAPI.
Les points de terminaison /assign et /status ont renvoyé une erreur 404.
Comportement de l'interface utilisateur
Le contenu a bien été servi par l'interface utilisateur, mais les composants de connexion n'ont pas pu s'afficher correctement en raison d'erreurs d'exécution dans AuthContext.tsx. Les étapes suivantes de l'interface utilisateur ont été bloquées.
Gemini CLI
Installation
Exécutez instantanément avec :
- npx @google/gemini-cli
Installation globale avec :
- npm install -g @google/gemini-cli
Installation globale avec Homebrew (macOS/Linux) :
- brew install gemini-cli
Installation globale avec MacPorts (macOS) :
- sudo port install gemini-cli
Installation avec Anaconda (pour les environnements restreints) :
- conda créer -y -n gemini_env -c conda-forge nodejs
- conda activer gemini_env
Authentification
Option 1 : Se connecter avec Google (connexion OAuth à l’aide de votre compte Google) :
Commencez par Gemini et écrivez :
- export GOOGLE_CLOUD_PROJECT="VOTRE_ID_DE_PROJET"
Ensuite, lancez Gemini.
Option 2 : Clé API Gemini
Commencez par Gemini et écrivez :
- export GEMINI_API_KEY="VOTRE_CLÉ_API"
Ensuite, lancez Gemini.
Option 3 : IA Vertex
Commencez par Gemini et écrivez :
- export GOOGLE_API_KEY="VOTRE_CLÉ_API"
- exporter GOOGLE_GENAI_USE_VERTEXAI=true
Rapport de tâche
Gemini CLI a permis de développer un backend performant, mais a échoué en raison d'une incompatibilité avec la chaîne d'outils frontend. De plus, il a consommé le plus grand volume de jetons parmi les implémentations backend réussies.
Comportement du backend
L'authentification, les opérations CRUD, les réponses, l'attribution, l'application des rôles et l'isolation des données ont été correctement implémentées.
Cependant, le point de terminaison /tickets/{id}/status était totalement absent, ce qui a entraîné le retour d'une erreur 404 à toutes les étapes de transition de statut.
Comportement de l'interface utilisateur
L'interface utilisateur n'a pas pu démarrer. Vite 7.3.1 était installé et nécessitait Node.js 20.19 ou une version ultérieure, alors que l'environnement de test utilisait Node.js 18.18.0. L'API crypto.hash requise par Vite était indisponible.
Par conséquent, l'interface utilisateur ne s'est jamais lancée et a obtenu la note de 0/8.
Cline
Installation
Installation globale avec :
- npm install -g cline
Authentification
En saisissant `cline auth`, vous pouvez sélectionner votre compte Cline ou continuer avec le fournisseur de votre choix.
Rapport de tâche
Le mécanisme de limitation des erreurs de Cline a interrompu la compilation avant son terme. L'architecture du backend est conforme aux intentions initiales, mais des problèmes d'enregistrement des routes et une implémentation incomplète ont empêché la validation fonctionnelle.
L'absence d'interface utilisateur et les défaillances en cascade du système dorsal placent ce résultat parmi les plus faibles de la tâche 6.
Comportement du backend
Cline a généré un backend composé de cinq fichiers : main.py, models.py, schemas.py, auth.py et database.py, ainsi que d’un fichier requirements.txt. La structure comprenait des modèles appropriés, l’échafaudage d’authentification JWT et des ébauches de points de terminaison.
Cependant, l'agent a atteint sa limite de huit erreurs lors du développement du backend et s'est arrêté avant la finalisation du système.
Seuls les points de terminaison de connexion ont fonctionné correctement. Trois des seize étapes de l'API ont été validées.
La création du ticket a renvoyé des redirections 307 au lieu de 200 ou 201, probablement en raison d'une incompatibilité de route (slash final). L'échec de la création du ticket a empêché la récupération de l'identifiant `$created_ticket.id`. Toutes les étapes suivantes utilisant cet identifiant ont transmis sa valeur littérale, provoquant des erreurs 422.
Les points de terminaison /tickets/{id}/assign et /tickets/{id}/status n'ont pas été implémentés, ce qui a entraîné des réponses 404.
Cela a produit un schéma de défaillance en cascade similaire à celui de Forge, où un problème de routage précoce invalidait les étapes suivantes.
Comportement de l'interface utilisateur
Le serveur a démarré correctement. Cependant, le répertoire frontend/ était vide et aucun fichier package.json n'existait.
Seule l'étape de vérification préliminaire côté serveur a réussi. Toutes les autres étapes de l'interface utilisateur ont été bloquées.
Oie
Installation
Pour macOS/Linux/WSL :
- curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash
Modèle : Aperçu du Gemini 3 Pro (via OpenRouter)
Durée : 1 297 s
Jetons : 17 000 en entrée / 752 en sortie
Score API : 60 %
Score d'interface utilisateur : 0 %
Goose a démontré une capacité d'autocorrection limitée, mais n'a pas réussi à satisfaire aux exigences de la pile complète. Des problèmes de fiabilité lors des exécutions répétées soulèvent des inquiétudes quant à sa stabilité.
Comportement du backend
L'authentification, la gestion des tickets (CRUD), les réponses, la vue détaillée et l'isolation des données ont fonctionné.
Cependant, les points de terminaison /assign et /status n'ont pas été implémentés, ce qui a entraîné des réponses 404 pour toutes les étapes associées.
Dans une version précédente, Goose a rencontré des erreurs de compatibilité avec bcrypt, s'est auto-corrigé en fixant la version de la dépendance, et a finalement lancé le backend.
Une nouvelle tentative a échoué suite à une erreur de décodage du flux après la génération d'un fichier minimal.
Comportement de l'interface utilisateur
Aucune interface utilisateur n'a été créée. Le répertoire d'installation était vide et aucun fichier package.json n'existait. Le test d'interface utilisateur a immédiatement échoué.
outils de codage IA
Les outils de codage IA peuvent être regroupés en trois catégories :
- Agentic CLI : Outils pour les flux de travail de développement basés sur le terminal, générez, modifiez et refactorisez du code via des invites et des interactions en ligne de commande.
- Exemples : Aider, Junie, Opencode, Claude Code, Codex
- Éditeurs de code IA : également connus sous le nom d’IDE agentsifs, ces outils fournissent une interface graphique similaire à VS Code (la plupart d’entre eux sont construits sur VS Code).
- Exemples : Antigravité, Curseur, Code Kiro, Windsurf
- Créateurs d'applications par invites : Plateformes low-code/no-code permettant de créer des applications à l'aide d'invites en langage naturel et de flux de travail visuels.
- Exemples : Bolt, Lovable, v0.dev, Firebase Studio, Dazl
outils d'analyse de code IA
Avec la généralisation du code généré par l'IA, les outils d'analyse de code sont essentiels pour détecter les bogues et les vulnérabilités. Nous avons évalué les meilleurs outils sur 309 demandes de fusion dans notre benchmark RevEval .
Que peuvent faire les outils CLI d'agent ?
Les outils tels que Codex, Junie, Kiro et Claude Code présentent des fonctionnalités communes :
- Travail de bout en bout sur le code : création et modification de fichiers, correction de bogues, refactorisation du code et exécution de tests ou d’analyseurs de code directement depuis le terminal.
- Flux de travail automatisés : Exécuter des tâches en plusieurs étapes telles que l’enchaînement de tâches, le dépannage, la recherche et le débogage itératif.
- Git et gestion de projet : consulter l’historique, résoudre les fusions, gérer les branches et créer des commits ou des demandes de tirage.
- Command Exécution et automatisation : Exécutez des commandes shell, automatisez les analyses et traduisez le langage naturel en opérations CLI complexes.
- Gestion approfondie du contexte : opérer sur des référentiels complets en tenant compte des dépendances et de la structure du projet.
- Flexibilité du modèle : Prise en charge de plusieurs modèles cloud et, dans certains cas, de modèles locaux ; certains outils permettent d’utiliser votre propre clé API ou de choisir entre différents forfaits.
- Accès contrôlé ou en mode sandbox : proposez des modes allant de la simple lecture à l’automatisation complète, souvent avec des environnements isolés pour des raisons de sécurité.
Méthodologie
Nous avons évalué les agents dans le cadre d'une exécution unique afin de mesurer leurs capacités autonomes sans intervention humaine. Les agents ont ensuite été évalués à l'aide de nos tests de validation côté serveur et côté client afin de mesurer la disponibilité de l'infrastructure et la justesse de leur comportement.
Les scores reflètent la fiabilité avec laquelle chaque agent a produit des systèmes exécutables et le nombre d'exigences fonctionnelles validées.
Configuration du modèle
Nous avons souhaité utiliser Google et gemini-3-pro-preview en raison de sa fenêtre de contexte étendue, adaptée à l'orchestration de plusieurs fichiers et aux invites de tâches longues. Cependant, certaines interfaces de ligne de commande d'agents sont étroitement liées à des fournisseurs spécifiques :
- Claude Code a été évalué en utilisant claude-opus-4-5-20251101 via l'API officielle de Anthropic.
- Codex a été évalué en utilisant gpt-5.2-codex-medium via la configuration native de OpenAI.
Pour ces agents, l'architecture CLI actuelle ne prend pas en charge les fournisseurs de modèles alternatifs. Chaque agent a été évalué avec sa configuration par défaut. Nous n'avons modifié ni la température, ni les politiques de nouvelle tentative, ni les paramètres de raisonnement.
Notre objectif d'évaluation était de séparer et de mesurer :
- Capacité de compilation (l'agent peut-il produire du code exécutable ?)
- correction du comportement du backend
- correction du comportement du frontend
- Fiabilité de l'orchestration autonome
Versions de l'interface de ligne de commande (mi-février 2026)
- Opencode : v1.2.10
- Cline : v3.41
- Aider : v0.86.0
- Gemini CLI : v0.29.0
- Forge : v1.28.0
- Codex : 0.104.0
- Oie : v1.25.0
- Code Claude : v2.1.62
- Junie : 888.212
- Kiro CLI : 1.26.0
Pour la méthodologie d'évaluation, consultez : Méthodologie d'évaluation comparative du codage IA
En savoir plus
Pour ceux qui explorent l'écosystème plus large des outils de développement d'agents, voici nos derniers benchmarks :
- Analyse comparative MCP : Une comparaison des meilleurs serveurs MCP pour l’accès Web.
- Navigateurs distants : comment l’infrastructure de navigateur émergente permet aux agents d’IA d’interagir avec le Web en toute sécurité.
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.