Un éditeur vous présente son agent de codage. Sur sa diapositive, un chiffre en gros : 95 % sur SWE-bench Verified. La promesse implicite est simple, neuf tickets sur dix seraient réglés tout seuls. Avant d'aligner ce chiffre sur un budget, il faut comprendre ce qu'il mesure vraiment, parce que la réponse a beaucoup changé depuis le début de l'année.
Le benchmark que tout le monde cite ne discrimine plus
SWE-bench Verified est un jeu de 500 problèmes tirés de vrais tickets GitHub sur des dépôts Python populaires. Pendant deux ans, il a servi d'étalon. En juillet 2026, les classements publics placent Claude Mythos 5 à 95,5 %, Fable 5 à 95,0 % et Opus 4.8 à 88,6 %. Quand les meilleurs candidats se tiennent dans un mouchoir au-dessus de 90 %, le test ne sépare plus les modèles. Il est saturé.
Le coup de grâce est venu d'OpenAI. Le 23 février 2026, son équipe d'évaluation a cessé de publier ses scores sur ce benchmark1. En auditant 138 problèmes que son modèle o3 avait échoués, elle a trouvé que 59,4 % contenaient des tests défectueux. Certains exigeaient un nom de fonction jamais cité dans l'énoncé. Plus gênant, la contamination se voyait à l'œil nu : plusieurs modèles régurgitent le correctif de référence mot pour mot à partir du seul identifiant de la tâche, signe qu'ils l'ont vu à l'entraînement. La formule d'OpenAI mérite d'être reprise, les progrès sur SWE-bench Verified « ne reflètent plus une amélioration réelle des capacités de développement des modèles [...] mais plutôt le degré d'exposition du modèle au benchmark pendant l'entraînement ».
Un score de 95 % sur ce test dit donc surtout que le dépôt Django faisait partie des données d'entraînement.
Les tests plus durs racontent une autre histoire
Quand on change la règle du jeu, les chiffres s'effondrent. Sur SWE-bench Pro, conçu fin 2025 avec des dépôts sous licence copyleft pour limiter la contamination, Opus 4.8 tombe à 69,2 %2. Fable 5 affiche 80 %, mais ce score a été produit avec le scaffolding maison d'Anthropic et non avec un harnais d'évaluation neutre, ce qui invite à la prudence. L'écart avec les 88 à 95 % de Verified donne la mesure de ce que la saturation cachait.
Il reste un second facteur que les argumentaires commerciaux passent sous silence. Le modèle ne travaille jamais seul, il est enveloppé dans un harnais qui gère le contexte, les outils et les boucles de correction. Sur Terminal-Bench, un même modèle peut gagner ou perdre 30 à 50 points selon le harnais qui l'entoure. Sur la version 2.1 de ce test, Codex CLI sur GPT-5.5 mène à 83,4 %, Claude Code sur Fable 5 suit à 83,1 %, et Claude Code sur Opus 4.8 tient 78,9 %3. Un score d'agent mesure un système, modèle plus outillage, et non un cerveau isolé. Le jour où vous branchez le modèle sur vos propres outils, vous construisez votre propre harnais, et sa qualité déplacera votre taux de réussite d'autant.
Du code écrit au code livré
Reste le trou le plus large, celui qui sépare le code produit du code qui part en production. Une étude publiée par le NBER en mai 2026, portant sur plus de 100 000 développeurs GitHub, a mesuré cet écart génération d'outils par génération d'outils4. Les agents autonomes font grimper le volume de commits de 180 %. Ce gain retombe pourtant à 50 % pour le nombre de projets et à seulement 30 % pour les livraisons réelles. La revue, l'intégration, les tests, l'empaquetage et la mise en ligne restent des étapes humaines qui ne s'accélèrent pas au même rythme.
Autrement dit, même un agent parfait sur un benchmark bute sur votre chaîne de livraison. Nous avions déjà creusé ce point sous l'angle de l'adoption dans notre article sur l'écart entre usage et livraison.
Ce que ça change côté achat
Pour une PME ou une ETI qui évalue un outil, quelques réflexes valent mieux qu'un chiffre isolé. Demandez sur quel benchmark le score a été obtenu et à quelle date. Un résultat sur Verified en 2026 pèse moins qu'un résultat sur Pro ou sur Terminal-Bench. Demandez ensuite si l'évaluation a tourné sur un harnais neutre ou sur l'outillage du vendeur, l'écart entre les deux est loin d'être marginal. Et surtout, faites tourner l'agent sur vos propres tickets, dans votre dépôt, avec votre pipeline, sur une ou deux semaines. Le seul benchmark qui prédit votre résultat, c'est le vôtre.
Notre lecture
Le chiffre de benchmark n'est pas inutile, il est simplement mal lu. Il répond à la question « ce modèle sait-il résoudre des tickets Python déjà vus » et pas à la question « cet agent va-t-il réduire mon délai de livraison ». Quand un fournisseur met un 95 % en avant sans préciser le test, la date et le harnais, le chiffre sert sa démonstration commerciale plus que votre décision. Nous conseillons de traiter ces scores comme un filtre d'entrée grossier, utile pour écarter les outils clairement en retard, puis de faire reposer le choix final sur un pilote mené dans vos conditions. La capacité d'un agent se mesure là où votre code part en production, pas sur une diapositive.
Sources
- OpenAI, « Why we no longer evaluate SWE-bench Verified » : https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
- Forbes, « AI Coding Agents Write 180% More Code But Ship Only 30% More Software » (étude NBER WP 35275) : https://www.forbes.com/sites/josipamajic/2026/06/10/ai-coding-agents-write-180-more-code-but-ship-only-30-more-software/
- Terminal-Bench 2.1 leaderboard : https://www.tbench.ai/leaderboard/terminal-bench/2.1
- SWE-bench Pro leaderboard 2026 : https://www.morphllm.com/swe-bench-pro
- SWE-bench Verified leaderboard : https://llm-stats.com/benchmarks/swe-bench-verified
Footnotes
-
OpenAI, « Why we no longer evaluate SWE-bench Verified », 23 février 2026 : audit de 138 tâches, 59,4 % de tests défectueux et contamination avérée. ↩
-
SWE-bench Pro, classements publics 2026 : Opus 4.8 à 69,2 %, Fable 5 à 80 % avec le scaffolding d'Anthropic. ↩
-
Terminal-Bench 2.1, classement public tbench.ai, juin 2026. ↩
-
NBER Working Paper 35275, « Writing Code vs. Shipping Code », Demirer, Musolff et Yang, mai 2026, plus de 100 000 développeurs GitHub. ↩