Blog / · 6 min de lecture
Les benchmarks d'agents de code mentent moins qu'avant. Nous, on les lit toujours mal.
SWE-bench, Terminal-Bench, leaderboards d'agents : les chiffres progressent, mais ils ne disent pas si un agent va vraiment survivre à ta codebase.
On adore les tableaux.
Un modèle à 87%. Un autre à 83%. Une flèche verte. Une courbe. Trois captures Twitter. Et soudain, tout le monde sait quel agent “gagne”.
Sauf que personne ne travaille dans un benchmark.
On travaille dans des repos mal rangés, avec des tests incomplets, des conventions non écrites, des secrets d’environnement, des tickets flous, des APIs internes, des migrations oubliées, et un collègue qui a nommé un dossier new-new-final.
Les benchmarks d’agents de code sont utiles. Le problème, c’est notre façon de les lire.
SWE-bench a gagné, puis il s’est fatigué
SWE-bench a eu un mérite énorme : sortir les modèles du simple “écris-moi une fonction” et les forcer à résoudre de vrais issues GitHub. Lire un repo, comprendre un bug, modifier plusieurs fichiers, passer les tests. C’était une rupture saine.
Mais quand un benchmark devient le terrain de jeu principal du marché, il s’use.
Les modèles s’améliorent vraiment, oui. Les harnesses aussi. Les prompts aussi. Les systèmes autour du modèle aussi. Et parfois, les résultats finissent par mesurer autant l’optimisation du banc que la capacité générale de l’agent.
Ce n’est pas un scandale. C’est normal.
Tous les benchmarks populaires finissent par devenir des produits.
Terminal-Bench est intéressant pour une raison bête
Terminal-Bench et les évaluations plus orientées environnement réel ont un avantage : elles testent la partie sale du travail.
Pas seulement “trouve le patch”. Plutôt :
- naviguer dans un shell ;
- installer ce qu’il faut ;
- lire des erreurs ;
- manipuler le filesystem ;
- comprendre une commande qui échoue ;
- ne pas casser l’environnement en chemin.
C’est moins propre. Donc plus proche de nos journées.
Un agent qui sait écrire du code mais panique dès que bun install sort un warning ne m’intéresse pas beaucoup. Un agent qui comprend qu’un test échoue parce que la fixture locale est vieille vaut plus cher qu’un modèle qui brille sur une issue déjà bien cadrée.
Le logiciel, ce n’est pas seulement produire un diff. C’est survivre à l’environnement.
Le chiffre qui manque : le coût de review
À mon sens, le meilleur benchmark d’agent de code n’existe pas encore.
Il mesurerait ceci :
combien de temps un humain compétent met-il à accepter ou rejeter le travail produit ?
C’est brutal, mais c’est la vraie métrique.
Un agent peut résoudre une tâche avec tous les tests verts et quand même te laisser un diff atroce :
- trop de fichiers touchés ;
- abstractions inutiles ;
- commentaires verbeux ;
- renommages hors scope ;
- comportement subtilement modifié ;
- migration correcte mais impossible à relire.
Sur le papier, c’est “pass”. Dans ta journée, c’est une dette.
À l’inverse, un agent qui s’arrête à 80%, explique précisément le blocage, garde un diff propre, et propose deux options peut être plus utile qu’un agent qui force jusqu’au bout.
Les benchmarks aiment les fins nettes. Le travail réel aime les sorties propres.
Ce qu’il faut regarder dans un leaderboard
Je ne dis pas qu’il faut ignorer les scores. Je les regarde aussi. Mais je les lis comme un signal faible, pas comme une décision d’achat.
Je regarde surtout :
Le type de tâches. Bugfix Python ? Front React ? DevOps ? Terminal ? Large repo ? Les agents n’ont pas tous les mêmes muscles.
Le harness. Qui exécute ? Avec quels outils ? Quelles permissions ? Quel temps ? Combien de tentatives ? Un bon modèle dans un mauvais harness peut perdre. Un modèle moyen dans un harness très optimisé peut briller.
Le coût. Un score sans coût est une publicité. Si un agent gagne avec 10 fois plus de tokens, ce n’est pas le même produit.
La variance. Je préfère un agent un peu moins haut mais stable qu’un agent génial un run sur deux et catastrophique le reste du temps.
Les échecs. Les leaderboards montrent qui réussit. Moi je veux savoir comment ça rate. Un agent qui échoue en s’arrêtant proprement est exploitable. Un agent qui échoue en réécrivant la moitié du repo est dangereux.
Le test maison vaut plus que le tableau public
Chaque équipe sérieuse devrait avoir son mini-benchmark interne.
Pas 500 tâches. Dix suffisent pour commencer.
Des tâches réelles :
- un bug déjà résolu ;
- une petite feature ;
- une migration ;
- une review de PR ;
- un test à écrire ;
- une erreur de prod anonymisée ;
- une tâche de doc technique ;
- un refactor volontairement ambigu.
Tu fais tourner trois agents dessus. Tu mesures :
- résultat ;
- temps ;
- coût ;
- taille du diff ;
- fichiers touchés ;
- temps de review ;
- nombre de relances humaines ;
- qualité du résumé final.
Là, tu apprends quelque chose.
Pas “quel modèle est le meilleur du monde”. Quel modèle est bon chez toi.
Le piège marketing de 2026
La guerre des agents va pousser tout le monde à publier des scores. C’est normal. Les clients veulent des repères. Les équipes marketing veulent une phrase simple.
Mais pour un dev ou un CTO, la phrase simple est rarement la bonne.
Un agent à 90% sur un benchmark public peut être médiocre sur ton monorepo Symfony. Un agent moins impressionnant peut très bien comprendre ton stack parce que son outil lit mieux les logs, respecte mieux tes instructions, ou se branche mieux à ton CI.
La frontière n’est plus seulement le modèle.
C’est le couple : modèle + outils + contexte + garde-fous + ergonomie de review.
Quand tu achètes un agent de code, tu n’achètes pas un cerveau. Tu achètes une manière de travailler.
À retenir
Les benchmarks ne sont pas faux. Ils sont incomplets.
Ils disent : “dans ce cadre contrôlé, avec ce harness, sur ces tâches, voilà ce qui s’est passé”.
Nous, on traduit trop vite en : “ce modèle va bien coder dans mon repo”.
La différence entre les deux phrases, c’est là que se cachent les bugs, les factures et les vendredis soir gâchés.
Regarde les scores. Puis fais ton test maison.
Le leaderboard peut te dire où commencer. Il ne peut pas décider à ta place.
Sources
Continuer la lecture