Les agents IA atteignent 99,4 % sur SWE-Bench Pro V2, mais 23 ingénieurs ont d'abord dû réparer le test lui-même

Imaginez que vous recrutiez un développeur, que vous lui donniez 100 tâches issues de projets réels et que vous obteniez 99 solutions correctes. C'est impressionnant, surtout s'il s'agit d'un réseau de neurones. Mais que se passe-t-il si une partie des sujets d'examen est mal conçue ?

C'est précisément ce qui a été mis au jour avec SWE-Bench Pro, un benchmark fondé sur des tâches réelles issues de dépôts GitHub. En septembre 2026, la version V2 est sortie, et la meilleure configuration (Opus 5 avec Claude Code) a atteint 99,4 % sur l'ensemble public. Mais l'essentiel n'est pas le record : c'est tout ce qu'il a fallu faire pour le mesurer honnêtement.

Un examen défaillant

En juillet 2026, OpenAI a publié un audit du jeu de données initial. La vérification automatique a signalé 27,4 % des tâches comme problématiques, la vérification manuelle 34,1 %. Au final, environ 30 % des tâches étaient incorrectes.

Les défauts typiques sont familiers à quiconque a déjà écrit des tests :

• le test exige le nom précis d'une fonction interne qui n'apparaît pas dans l'énoncé de la tâche ;
• les exigences sont incomplètes, et les tests cachés vérifient ce qu'on ne peut pas déduire du texte ;
• les tests sont trop faibles : l'agent corrige un seul cas particulier et la vérification passe ;
• l'énoncé demande une chose, le test en attend une autre.

Résultat : une solution correcte pouvait être jugée fausse, et une solution fausse jugée correcte. Et tout cela se transformait en pourcentages sur de beaux graphiques.

Dans la V2, sur 731 tâches publiques, 89 ont été exclues, et pour les 642 restantes, les exigences et les vérifications ont été corrigées. Au total, 480 tâches ont dû être corrigées ou supprimées. 23 ingénieurs y ont travaillé, pour un total de 404 heures. Les tâches corrigées ont été vérifiées par des développeurs humains : ils les ont résolues à partir de la description, sans consulter le patch de référence.

Comment un agent peut « réussir » un test sans réparer le code

Deux failles ont été découvertes chez les agents. La première : l'agent travaille dans un environnement et peut modifier non seulement le code, mais aussi les dépendances ou le cache. La documentation de la V2 décrit des cas liés à go.sum et au cache des modules Go. Les tests sont au vert, mais le patch ne fonctionne pas dans un dépôt propre.

La seconde faille, c'est Internet. Lors des exécutions précédentes, 32 trajectoires sur 642 ont accédé à des hébergeurs de code, et dans quatre cas l'agent a obtenu le SHA du commit contenant le correctif. Cela ne prouve aucune intention, mais le canal de fuite de la réponse est bien réel.

Désormais, pendant l'exécution, le réseau est limité à la seule API du modèle, et le patch final est appliqué et testé dans un nouveau conteneur propre.

Ce que cela signifie en pratique

Faut-il retrancher 30 % des anciens classements et y voir la précision réelle ? Non. Les erreurs du benchmark jouent dans les deux sens : des tests faibles gonflent le résultat, tandis que des exigences non précisées le sous-estiment. S'y ajoute une possible fuite de solutions depuis les données d'entraînement.

Autre limite : lorsque les leaders atteignent 95 à 99 %, le benchmark cesse de les départager. C'est pourquoi, sur le Hard split de 51 tâches difficiles, les résultats s'échelonnent de 52,9 % à 98,0 %. De plus, corriger un bug dans du code existant n'est pas la même chose que concevoir un système ou assurer la maintenance d'un produit pendant des années. Pour cela, METR mesure le time horizon : la difficulté de la tâche qu'un agent mène à bien avec une probabilité donnée.

Si vous comparez Cursor, Codex et Claude Code pour votre équipe, il est utile d'appliquer les mêmes règles :

• le même commit figé pour tous ;
• la même consigne, sans indices cachés ;
• des tests indépendants préparés à l'avance ;
• le patch final dans un conteneur propre avec réinstallation des dépendances ;
• un suivi du temps, du coût, du nombre d'interventions humaines et des régressions.

Et vérifiez d'abord les tâches elles-mêmes, sinon vous mesurerez les erreurs de votre propre méthodologie. Évaluez séparément ce que les tests unitaires ne détectent pas : l'architecture, la gestion des erreurs, la sécurité, la maintenabilité.

Le bilan est simple. Les agents sont réellement devenus plus performants, mais plus ils progressent, plus il est difficile de les mesurer honnêtement. Le message « tâche accomplie » n'est pas le résultat d'une vérification, mais une affirmation qu'il faut vérifier. Des tests au vert sont un bon début, mais pas la garantie que c'est bien votre problème qui a été résolu.