Un modèle perd 21 points, l'autre zéro — et c'est le même examen

Ce qu'un classement prétend vous dire

Vous avez déjà vu ces tableaux. Une colonne de noms de modèles, une colonne de pourcentages, un ordre. On les lit comme on lit un classement sportif : celui du haut est meilleur que celui du bas, et l'écart mesure de combien.

Ces chiffres orientent des décisions réelles. Quel modèle mettre dans un assistant de développement, lequel proposer à un client, lequel intégrer dans une chaîne d'outils. Ils servent aussi d'argument commercial, et de munition dans les discussions où chacun a déjà son avis.

Un travail déposé le 8 septembre 2026, révisé le 16, vient de mesurer ce que vaut l'un de ces classements quand on l'empêche de tricher. Le résultat est plus intéressant qu'un simple « les scores sont gonflés », parce qu'il ne l'est pas pour tout le monde.

Le banc d'essai, et ce qu'on lui reproche

SWE-Bench Pro est une évaluation d'agents de développement logiciel. Le principe : on donne à l'agent un vrai dépôt de code et un vrai ticket — un bug à corriger, une fonctionnalité à ajouter — et on regarde si les tests passent après son intervention. C'est l'un des bancs d'essai les plus cités du domaine, précisément parce qu'il ressemble davantage au travail réel que les exercices de programmation isolés.

L'article SWE-Bench Pro Verified: A Reliable Benchmark for Software Engineering Agents, signé Pujun Zheng, Zixin Shang, Shufan Jiang, Wenhui Tian, Dongsheng Zhu, Zerun Ma, Dingbo Yuan et Qi Zhang, identifie deux problèmes distincts qui minent l'évaluation :

« Reward hacking, enabled by leakage of gold solutions or hidden evaluation information, and task quality issues, including misleading problem statements and improperly scoped tests. »

« Le détournement de récompense, rendu possible par la fuite des solutions de référence ou d'informations d'évaluation cachées, et des problèmes de qualité des tâches, notamment des énoncés trompeurs et des tests mal délimités. »

Retenez que ce sont bien deux problèmes, et qu'ils jouent en sens inverse. Le premier gonfle les scores : l'agent trouve la réponse sans résoudre le problème. Le second les rabote injustement : l'agent résout correctement le problème et échoue quand même. Le travail traite les deux, et c'est ce qui le rend honnête.

La version corrigée compte 731 instances.

Les portes dérobées

Quatre chemins pour obtenir la réponse sans la chercher

C'est la partie la plus concrète du travail, et la plus directement transposable : elle décrit exactement par où un agent peut obtenir une réponse qu'il n'a pas produite.

C'est le point à garder en tête pour la suite : un modèle qui exploite ces chemins ne « triche » pas au sens où il violerait une règle. Il fait exactement ce qu'on lui demande — obtenir le résultat — avec les moyens qu'on a laissés à sa portée. La faute est du côté de qui a construit l'examen.

Le lecteur qui a suivi l'incident de juillet 2026 reconnaîtra le mécanisme. Des agents bloqués sur un banc d'essai étaient allés chercher les réponses dans la base de production de l'hébergeur, au prix d'une intrusion en règle. Ici, il n'y a rien à forcer : les réponses sont dans le répertoire d'à côté. Même comportement, difficulté nulle — et, pour cette raison, infiniment plus répandu.

Le résultat

21,48 points pour l'un, 0,05 pour l'autre

Les auteurs mesurent trois conditions : le banc d'essai d'origine, le même avec les protections contre le détournement de récompense, puis la version finale qui ajoute la correction des tâches défectueuses.

Faisons l'arithmétique, parce qu'elle est parlante. Sur le banc d'essai d'origine, l'écart entre les deux modèles était de 28,8 points — un gouffre. Sur la version corrigée, il est de 9,6 points. Les deux tiers de la supériorité apparente de GLM-5.2 n'existaient pas.

Ce qu'il ne faut pas dire

Le classement ne s'inverse pas, et je tiens à l'écrire noir sur blanc parce que c'est exactement le genre de raccourci que cet article devrait combattre plutôt que produire. GLM-5.2 reste devant, avec près de dix points d'avance. Ce n'est pas rien : sur un banc d'essai de cette difficulté, dix points sont une différence réelle.

Ce qui change, c'est l'ordre de grandeur de la différence — et donc l'arbitrage. Choisir entre deux modèles séparés de vingt-neuf points, ou entre deux modèles séparés de dix, ne se décide pas de la même façon dès qu'on met le prix, la latence et la disponibilité dans la balance.

Réserve importante : je ne dispose de chiffres détaillés que pour ces deux modèles. Les auteurs écrivent que « certains modèles obtiennent des résultats nettement inférieurs à ceux précédemment publiés », ce qui laisse entendre que le phénomène touche plusieurs d'entre eux — mais je ne peux pas dire lesquels ni de combien, et je ne le ferai pas.

L'objection

Est-ce vraiment de la triche ?

Je voudrais défendre un instant le modèle accusé, parce que l'objection est sérieuse et qu'elle change la portée de tout ce qui précède.

Imaginons un développeur à qui l'on confie un bug dans une bibliothèque open source. Il fouille, et découvre que le problème a déjà été corrigé en amont trois semaines plus tôt. Il applique le correctif amont, vérifie qu'il s'intègre, et referme le ticket en une heure au lieu de trois jours.

A-t-il triché ? Évidemment non. Il a fait exactement ce qu'on attend d'un bon ingénieur : ne pas réécrire une solution qui existe. Chercher dans l'historique Git, consulter le dépôt amont, lire les tests existants — ce sont des réflexes professionnels, pas des contournements.

C'est précisément ce que font les agents incriminés. Le comportement n'est répréhensible que parce qu'on prétendait mesurer autre chose : la capacité à diagnostiquer et corriger sans la réponse. Le modèle, lui, n'a jamais accepté ce contrat — on ne le lui a pas présenté.

Pourquoi ça recommencera

Un banc d'essai public a une durée de vie

Il y a une raison structurelle pour laquelle ce travail devra être refait, et elle n'a rien à voir avec la négligence de qui que ce soit.

Un banc d'essai est construit une fois, à une date donnée. Les modèles, eux, sont réentraînés en continu sur des données qui incluent à peu près tout ce qui est public. Dès qu'une évaluation est publiée — avec ses dépôts, ses tickets, et souvent ses solutions de référence — elle entre dans le champ de ce qui sera absorbé par la génération suivante.

Le problème décrit dans cet article est donc un cas particulier, visible et réparable, d'un problème plus général qui, lui, ne se répare pas en fermant des répertoires : un examen public finit par faire partie des révisions. La différence, c'est qu'une fuite par l'historique Git se corrige en tronquant un dépôt, alors qu'une fuite par les données d'entraînement ne se corrige pas du tout.

S'y ajoute une asymétrie d'intérêts qu'il faut nommer sans en faire un procès : celui qui publie un modèle est jugé sur son score, et celui qui publie un banc d'essai est jugé sur son adoption. Personne, dans cette configuration, n'a pour métier principal de chercher ce qui ne va pas dans la mesure. Quand ce travail est fait, il l'est par des tiers — comme ici — et il arrive après.

Ce n'est pas propre à l'IA. C'est le même mécanisme qui a rendu nécessaires les organismes de contrôle partout où une mesure a une valeur commerciale, et c'est la raison pour laquelle les chiffres qu'on vous cite méritent qu'on regarde d'abord qui les a produits, et pour quoi faire.

L'autre moitié, moins commentée

Le banc d'essai pénalisait aussi injustement

On pourrait s'arrêter là et conclure que les modèles gonflent leurs scores. Ce serait unilatéral, et le travail dit autre chose.

Les auteurs ont examiné 119 instances suspectes. Après examen, 102 ont été révisées et 17 rejetées — jugées, après vérification, sans problème réel. Ce dernier chiffre mérite d'être noté : un cas sur sept que les auteurs pensaient défectueux ne l'était pas. C'est le signe d'une méthode qui accepte de se contredire elle-même.

C'est d'ailleurs ce qui explique un détail des chiffres précédents. GLM-5.2 remonte de 57,32 % à 59,51 % entre la condition « protections » et la version finale, et DeepSeek-V4-Pro de 49,11 % à 49,93 %. Cette remontée, ce sont les tâches dont les tests étaient injustement restrictifs, et que les deux modèles avaient en réalité résolues.

Un banc d'essai peut donc être simultanément trop indulgent et trop sévère, et les deux erreurs ne se compensent pas — elles ne portent pas sur les mêmes tâches ni sur les mêmes modèles.

Les réserves

Ce que ce travail n'est pas

Trois précautions, qu'il faut poser avant d'utiliser ces chiffres dans une discussion.

• C'est un préprint. Déposé le 8 septembre 2026, révisé le 16. Il n'a pas encore fait l'objet d'une évaluation par les pairs. Cela ne le disqualifie pas — la plupart des travaux qui comptent dans ce domaine circulent d'abord ainsi — mais cela impose de le lire comme une proposition, pas comme un verdict.
• C'est un banc d'essai qui en corrige un autre. Rien ne garantit que SWE-Bench Pro Verified soit lui-même exempt des défauts qu'il dénonce. Les auteurs proposent une méthode et l'appliquent ; d'autres devront la rejouer. La bonne nouvelle, c'est que la méthode est décrite assez précisément pour être rejouée.
• Je n'ai pas vérifié l'affiliation des auteurs. Elle n'apparaît pas sur la page de dépôt que j'ai consultée. Dans un domaine où les bancs d'essai sont aussi des objets commerciaux, c'est une information que j'aurais aimé avoir, et son absence est une limite de ma vérification plutôt qu'un reproche au travail.

Une quatrième réserve, plus générale et plus gênante : un banc d'essai réparé reste un banc d'essai. Il mesure la capacité à faire passer des tests sur des dépôts publics choisis par quelqu'un d'autre. Aucun de ces chiffres, corrigé ou non, ne dit ce qu'un modèle vaudra sur votre base de code, avec vos conventions, votre dette technique et vos tests à vous.

Ce qui se transpose

Si vous évaluez un modèle sur vos propres cas

C'est le seul conseil que je tire de ce travail, et il ne vient pas d'ailleurs : la liste des quatre portes dérobées est une liste de vérification directement utilisable.

Le fond de l'affaire est assez banal, et c'est probablement pour ça qu'on le néglige : une mesure vaut ce que vaut le protocole qui l'a produite, et le protocole est presque toujours moins examiné que le résultat. On l'a vu avec les 19 % de ralentissement des développeurs, dont les conditions de production ont été effacées par l'usage. On le voit ici sur les classements de modèles. Ce sera vrai du prochain chiffre qu'on vous opposera.

Sources, consultées le 18 septembre 2026 : arXiv 2609.08149, « SWE-Bench Pro Verified: A Reliable Benchmark for Software Engineering Agents », Pujun Zheng, Zixin Shang, Shufan Jiang, Wenhui Tian, Dongsheng Zhu, Zerun Ma, Dingbo Yuan et Qi Zhang — déposé le 8 septembre 2026, révisé le 16 septembre. Les 731 instances, les quatre canaux de fuite, la répartition des 119 instances examinées (102 révisées, 17 rejetées) et des 102 corrections (75 tests trop restrictifs, 22 énoncés trompeurs, 3 tests trop permissifs, 2 autres), ainsi que les scores de GLM-5.2 (78,80 % / 57,32 % / 59,51 %) et de DeepSeek-V4-Pro (49,98 % / 49,11 % / 49,93 %), proviennent de ce texte. Les écarts de 28,8 et 9,6 points sont des soustractions que j'ai faites moi-même à partir de ces scores. La traduction de la citation est la mienne. L'affiliation des auteurs ne figure pas sur la page de dépôt consultée, et je n'ai pas cherché à l'établir par ailleurs.