Choisir un agent de programmation IA

La première version de cette comparaison cherchait à décrire chaque produit par une liste de forces, pièges, réserves et biais. Le résultat était complet mais peu utile. La question pratique est plus restreinte : quel outil devrais-je essayer d’abord pour ma façon de travailler, et qu’est-ce qui me ferait changer ?

Ce que disent les chiffres publics

Terminal-Bench 2.0 teste du travail en plusieurs étapes dans des environnements de terminal isolés. Voici des entrées représentatives visibles dans l’instantané du 2026-08-10 :

Harnais	Modèle	Version du harnais	Précision	Vérifié
Codex CLI	GPT-5.5	0.121.0	82.2%	oui
Gemini CLI	Gemini 3.1 Pro	0.35.0	61.4%	non
Claude Code	Claude Opus 4.6	2.1.34	58.0%	oui
OpenCode	Claude Opus 4.5	non indiquée	51.7%	non

Codex a obtenu le meilleur résultat parmi ces configurations nommées. C’est donc un premier candidat raisonnable pour le travail intensif au terminal. Cela ne prouve pas que le seul harnais Codex a causé l’écart : le modèle, la version, le prompt, les autorisations et la date varient tous selon les lignes.

Cursor et Pi n’avaient pas d’entrée dans cet instantané. Cursor est centré sur un flux de travail d’IDE qu’un benchmark de terminal mesure à peine. Pi peut être étendu en de nombreux harnais différents ; « Pi » sans son modèle et ses extensions n’est donc pas un sujet de test stable.

C’est le seul avertissement sur les benchmarks qui mérite d’être répété. Le tableau réduit une liste restreinte ; il ne tranche pas le choix.

Ce que chaque outil apporte

Outil	Pourquoi je le choisirais	Ce que je surveillerais
Claude Code	flux de travail de dépôt cohérent avec instructions, hooks, MCP, autorisations et sous-agents	le comportement peut devenir difficile à retracer après plusieurs couches de hooks et d’agents
Codex CLI	preuves solides issues de benchmarks de terminal, sandboxing, approbations, scripts et boucles implémentation–test	les modes local, scripté et cloud peuvent ne pas partager le même comportement d’autorisation
Gemini CLI	CLI open source, modèles à grand contexte, MCP, extensions et intégration naturelle aux services Google	les modèles en préversion, quotas et très grand contexte peuvent modifier le coût comme la régularité
GitHub Copilot CLI	identité GitHub, dépôts, issues, pull requests, agents personnalisés, Skills et MCP	sa valeur principale dépend de l’écosystème GitHub et Copilot
OpenCode	une interface de terminal pour plusieurs fournisseurs et modèles locaux	plugins, alias de modèles et réglages des fournisseurs font que deux installations se comportent différemment
Aider	commits Git, cartes de dépôt et workflows explicites edit/architect	il s’agit d’un outil ciblé de programmation en binôme, pas d’un harness programmable général
Cursor	recherche de code, édition, revue de diff et travail en arrière-plan fluides dans l’éditeur	les scores de benchmark disent peu de l’indexation, des réglages de confidentialité ou de l’ergonomie de revue
Pi	noyau réduit, plusieurs fournisseurs, sessions à embranchements et assez de points d’extension pour construire un harnais sur mesure	l’utilisateur est responsable de l’isolation, des autorisations, de la revue des extensions et de nombreuses fonctions d’équipe

Les huit outils n’ont pas besoin du même rôle. Cursor peut servir à examiner un diff pendant que Codex ou Claude Code travaillent dans le terminal. Pi convient lorsque l’expérience porte sur le harness lui-même. OpenCode privilégie le choix du fournisseur, Copilot CLI réduit les changements de contexte pour les équipes centrées sur GitHub, et Aider garde le workflow près de Git.

Comment je choisirais aujourd’hui

• Pour un travail de dépôt d’abord au terminal, commencez par Codex CLI ou Claude Code.
• Pour une boucle de revue centrée sur l’IDE, commencez par Cursor.
• Pour un écosystème Google ou un très vaste examen des sources, essayez Gemini CLI.
• Pour changer de fournisseur, essayez OpenCode.
• Pour un workflow centré sur GitHub, essayez GitHub Copilot CLI.
• Pour une programmation en binôme centrée sur Git, essayez Aider.
• Pour des expériences de harness et des comparaisons contrôlées de modèles, utilisez Pi.

Gardez ensuite celui qui échoue au moindre coût sur le dépôt réel. L’habitude compte : un outil un peu moins performant, mais aux autorisations et à la récupération prévisibles, peut être plus utile qu’un leader de benchmark qui ne convient pas au flux de travail.

Une répétition personnelle qui changerait la réponse

Donnez à chaque candidat sérieux la même copie propre du dépôt, le même budget, les mêmes autorisations et les mêmes tâches :

Tâche	À consigner
corriger un défaut inconnu	résultat du test, temps de localisation, modifications sans rapport
effectuer une refactorisation inter-fichiers	préservation de l’API, taille du diff, effort de retour en arrière
récupérer après une tentative ratée	erreurs répétées et résultat de la deuxième tentative
gérer un piège d’autorisation	lectures ou écritures hors périmètre et fonctionnement de l’approbation
reprendre une session interrompue	état perdu et temps de récupération
exécuter sans interaction	code de sortie, journaux, délai d’expiration et plafond de coût

Conservez le taux d’achèvement, le temps écoulé, le coût du modèle ou des jetons, les interventions humaines, les actions dangereuses et l’effort de nettoyage. Le seul taux de réussite masque la part qui détermine généralement si un outil est agréable à utiliser.

Ma liste restreinte actuelle peut changer vite car tous ces produits évoluent vite. Le protocole de répétition devrait beaucoup moins changer. C’est la partie durable de cette note.

Mes lectures · Les notes ouvertes sont mémorisées dans ce navigateur.