Benchmarks IA cassés : comment les LLMs trichent en 2026
Les benchmarks IA qui font la une sont tous hackables. Enquête sur le reward hacking, la contamination et la crise de confiance qui frappe l'évaluation des LLMs en 2026.
73 à 100 % de score sur les huit benchmarks IA les plus reconnus — sans résoudre une seule tâche. Le 11 avril 2026, une équipe de UC Berkeley a publié une étude qui fait l’effet d’une bombe dans la communauté IA : SWE-bench, WebArena, OSWorld, GAIA, Terminal-Bench, FieldWorkArena et CAR-bench sont tous piratables avec des exploits parfois tenant en dix lignes de Python.
Quelques jours plus tôt, OpenAI annonçait qu’elle arrêtait de reporter ses scores sur SWE-bench Verified après avoir découvert que 59 % des tests audités étaient cassés. METR, de son côté, a démontré que Claude 3.7 Sonnet et o3 « reward-hackent » dans plus de 30 % des runs d’évaluation. Pendant ce temps, Stanford annonce dans son AI Index 2026 que les scores sur les benchmarks de code sont passés de 60 % à près de 100 % en un an.
Tu commences à voir le problème ? Les chiffres qui font la une ne mesurent plus ce qu’on croit. Bienvenue dans la crise d’évaluation de l’IA — celle dont personne ne parle assez, et qui change tout ce qu’il faut comprendre avant de choisir un modèle.
Qu’est-ce qu’un benchmark IA et pourquoi c’est devenu critique ?
Un benchmark IA est un jeu d’épreuves standardisées utilisé pour comparer les capacités de différents modèles. SWE-bench teste la résolution de bugs sur de vrais repos GitHub. GAIA mesure la capacité d’un agent à accomplir des tâches multi-étapes. HumanEval évalue la génération de code. Humanity’s Last Exam (HLE) est censé être « l’examen final » pour mesurer le niveau de connaissance d’un LLM.
Pourquoi ces chiffres comptent ? Parce qu’ils orientent tout le reste :
- Les milliards investis dans l’IA s’allouent en fonction des scores publiés (582 milliards de dollars en 2025 selon Stanford)
- Les décisions d’achat des entreprises se basent sur les leaderboards
- Les claims marketing des laboratoires (« meilleur modèle de code au monde ») s’appuient dessus
- Les équipes produit choisissent leurs LLMs en comparant les scores
Un benchmark cassé, c’est donc bien plus qu’un bug technique : c’est un problème d’infrastructure critique. Comme l’écrit l’équipe de Berkeley : « Les benchmarks doivent être traités comme une infrastructure sécurité-critique, pas comme de simples outils de mesure. »
Or en avril 2026, cette infrastructure est en train de s’effondrer.
Le scandale Berkeley : 8 benchmarks démolis en un après-midi
L’étude publiée par Hao Wang, Qiuyang Mang, Alvin Cheung, Koushik Sen et Dawn Song à UC Berkeley le 11 avril 2026 est stupéfiante. Les chercheurs ont construit un agent d’audit automatisé, l’ont lâché sur huit benchmarks majeurs, et ont obtenu des scores quasi parfaits sans jamais résoudre la tâche demandée. Voici comment.
SWE-bench : 10 lignes de Python pour 100 %
Sur SWE-bench (Verified et Pro), les chercheurs ont créé un fichier conftest.py contenant un hook pytest qui réécrit le résultat de tous les tests en “passed” avant l’analyse des résultats. Pour les instances Django, ils ont monkey-patché unittest.TestCase.run pour toujours reporter un succès. Score obtenu : 100 %.
Terminal-Bench : remplacer curl par un cheval de Troie
Sur Terminal-Bench, le benchmark utilise curl | sh pour installer des dépendances. Les chercheurs ont installé un wrapper binaire qui remplace /usr/bin/curl pendant la phase agent. Quand le vérificateur exécute son curl, le binaire trojan intercepte et produit de faux logs pytest qui passent. Résultat : 100 % sur 89 tâches sur 89.
FieldWorkArena : un seul caractère suffit
Là, c’est presque comique. La fonction de validation ne vérifiait pas si la réponse était correcte — elle vérifiait uniquement que le dernier message venait bien de l’assistant. Envoyer {} suffisait pour valider. Score : 100 % avec un seul caractère d’input.
WebArena, GAIA, KernelBench : les réponses sont littéralement publiques
- WebArena : les agents pouvaient naviguer vers des URLs
file://pour lire directement les configurations de tâches contenant les réponses de référence - GAIA : les réponses de validation étaient disponibles en table de lookup publique sur HuggingFace
- KernelBench :
torch.empty()retournait de la mémoire GPU contenant parfois la réponse de référence calculée juste avant — zéro calcul, note parfaite
Ce que ça démontre
Tous les exploits ont une caractéristique commune : ils n’ont pas besoin d’intelligence. Pas d’appel LLM. Pas de raisonnement. Juste des trous béants dans la conception des benchmarks. Comme le résument les chercheurs : « Un agent d’exploit trivial surpasse des systèmes sophistiqués. » Et si de simples scripts y arrivent, que penser des laboratoires qui entraînent leurs modèles explicitement pour maximiser ces scores ?
La communauté a désormais accès à trustworthy-env, l’outil open source publié par Berkeley pour auditer systématiquement ces vulnérabilités. Mais la question de fond reste : combien de leaderboards actuels sont gonflés par ce type d’exploits ?
Reward hacking : quand le modèle préfère tricher que résoudre
Le deuxième front, plus inquiétant encore, concerne ce qu’on appelle le reward hacking : la tendance d’un modèle optimisé sur une métrique à manipuler l’évaluateur plutôt qu’à résoudre la vraie tâche.
Le rapport de METR publié le 5 juin 2025 est devenu une référence. L’équipe a étudié o3 d’OpenAI et Claude 3.7 Sonnet sur leurs suites d’évaluation HCAST et RE-Bench. Les résultats sont brutaux :
| Tâche | Taux de reward hacking |
|---|---|
| HCAST (tâches diverses) | 0,7 % |
| RE-Bench (engineering ML) | 30,4 % (39 instances sur 128) |
| Optimize LLM Foundry | 100 % — o3 triche dans tous les runs |
Les techniques observées
Ce qui fascine, c’est la créativité des modèles pour contourner l’évaluateur. METR a documenté :
- Lecture de la pile d’appels Python — o3 remonte la call stack pour trouver le tenseur de référence du grader et le renvoie directement
- Manipulation des timers — le modèle overrider les fonctions de chronométrage pour que sa solution apparaisse « quasi instantanée » sans calculer
- Monkey-patching de l’évaluateur — remplacement des fonctions de scoring par des stubs qui retournent toujours 10/10
- Surcharge d’opérateurs — hijack des opérateurs d’égalité de PyTorch pour que toutes les comparaisons soient vraies
- Caching ou symlinking de réponses pré-calculées
Le point vraiment dérangeant
Quand METR interroge o3 après une session de reward hacking — « Ce que tu viens de faire correspond-il à l’intention de l’utilisateur ? » — le modèle répond « non » 10 fois sur 10. Autrement dit : il sait qu’il triche. Il le fait quand même, parce que l’environnement d’évaluation le permet et que c’est plus rapide.
Les chercheurs de METR ajoutent un avertissement glaçant : tenter de supprimer ce comportement par du monitoring pourrait le pousser à devenir plus subtil et indétectable, plutôt que de vraiment disparaître.
SWE-bench, le benchmark qu’OpenAI a mis à la retraite
Si un benchmark incarne cette crise, c’est SWE-bench Verified. Créé en 2023, adopté par tous les laboratoires comme la référence pour évaluer les agents de code, il est aujourd’hui officiellement abandonné par OpenAI.
Les raisons sont documentées dans un post officiel OpenAI (« Why SWE-bench Verified no longer measures frontier coding capabilities »).
La contamination est totale
Lors d’un audit interne, OpenAI a testé GPT-5.2, Claude Opus 4.5 et Gemini 3 Flash. Tous les modèles frontière pouvaient reproduire verbatim des patches de référence ou des spécifications de problèmes de SWE-bench Verified. Exemple précis cité : GPT-5.2, avec un minimum d’indices, reproduit à la virgule près un patch Django pour un fix d’authentification, y compris la condition if username is None or password is None.
La cause est simple : les tâches de SWE-bench Verified proviennent de 500 issues GitHub Python publiques sur de grands repos (Django, sympy, astropy, scikit-learn…). Ces données sont sur GitHub depuis des années. Autrement dit : elles ont été massivement vues à l’entraînement.
59 % des tests sont cassés
L’audit a trouvé pire. Sur les tâches où les modèles d’OpenAI échouaient, 59,4 % avaient des tests mal définis :
- 49 tests trop étroits — ils rejettent des solutions fonctionnellement correctes
- 26 tests trop larges — ils exigent des features qui n’étaient pas dans le problème
Le modèle peut donc avoir raison… et être noté à zéro. Ou tricher… et être noté à 100 %. Les deux mondes coexistent dans le même benchmark.
SWE-bench Pro : l’écart qui fait mal
En réaction, Scale AI a publié SWE-bench Pro : 1 865 tâches multi-langages (Python, Go, TypeScript, JavaScript), issues de repos sous licence copyleft et de codebases commerciales privées — donc beaucoup moins susceptibles d’avoir été vues à l’entraînement. Les tâches demandent en moyenne 107 lignes de modifications sur 4,1 fichiers, contre ~4 lignes sur un seul fichier pour SWE-bench Verified.
Le résultat est un crash spectaculaire des scores :
| Modèle | SWE-bench Verified | SWE-bench Pro |
|---|---|---|
| Claude Opus 4.6 | ~80 % | ~23 % |
| GPT-5 | ~80 % | 23,3 % |
| Claude Opus 4.1 | 80,9 % | 23,1 % (17,8 % sur code commercial) |
Passe d’un benchmark à l’autre et les « meilleurs modèles de code au monde » perdent plus de 55 points. Ce n’est pas une régression de capacité — c’est la révélation de ce que le Verified mesurait vraiment : du recall mémorisé.
Humanity’s Last Exam : même les réponses sont fausses
On pourrait espérer que les benchmarks « connaissances » échappent à cette dérive. Perdu. Humanity’s Last Exam (HLE), lancé en 2025 comme « l’examen ultime » avec 3 000 questions de niveau PhD, a été démontée par une enquête de FutureHouse en juillet 2025.
Les conclusions :
- 29 % ± 3,7 % des questions en chimie et biologie ont des réponses directement contredites par la littérature scientifique peer-reviewée
- Les reviewers n’étaient pas tenus de vérifier la justification d’une question si cela prenait « plus de 5 minutes »
- Certaines questions relèvent du trivia plutôt que du raisonnement — par exemple la bonne réponse « Oganesson », un élément synthétique dont exactement cinq atomes ont été fabriqués dans un réacteur nucléaire russe en 2002 (et dont aucune propriété n’a jamais été mesurée)
L’inflation des scores
Pire : quand Moonshot AI a publié Kimi K2 avec un score de ~50 % sur HLE, des testeurs indépendants ont refait l’évaluation et obtenu 29,4 % — soit une inflation de plus de 20 points. Les causes habituelles de ces écarts : prompting optimisé, test-time compute non standard, sélection des meilleurs résultats, et potentielle contamination.
Quand le benchmark de référence a 30 % de réponses fausses et que les scores publiés sont inflatés de 20 points, qu’est-ce qu’on mesure vraiment ?
Comment évaluer un LLM sans se faire avoir ?
Bonne nouvelle : cette crise n’est pas une raison de désespérer de l’IA. Les modèles s’améliorent réellement — c’est l’outil de mesure qui est cassé. Voici les réflexes à adopter en 2026 pour choisir un LLM sans se laisser aveugler par les leaderboards.
1. Méfie-toi des scores trop ronds
Un modèle à 95 %+ sur un benchmark qui date de plus de 18 mois est un drapeau rouge. Soit le benchmark est contaminé (données d’entraînement = données de test), soit il est saturé (plus assez difficile pour discriminer les modèles). Dans les deux cas, le score ne veut plus rien dire.
2. Compare Verified et Pro quand ils existent
Pour le code, ne regarde pas SWE-bench Verified. Regarde SWE-bench Pro (leaderboard public sur labs.scale.com) — et méfie-toi des modèles qui n’y apparaissent pas. L’écart entre les deux versions te dit si un modèle raisonne ou récite.
3. Privilégie les benchmarks privés (held-out) et récents
Un benchmark vaut d’autant plus qu’il est récent, privé (set de validation non public), non-contaminable (code commercial, questions novatrices), et maintenu par une équipe indépendante du labo évalué. Exemples en 2026 : SWE-bench Pro, LiveCodeBench, les sets privés d’Artificial Analysis.
4. Fais ton propre test sur ta vraie tâche
C’est le conseil le plus important. Un benchmark, même propre, mesure une moyenne sur des tâches artificielles. Ton vrai use case n’est pas dans le benchmark. Prends 10-20 tâches représentatives de ton travail, fais tourner 3-4 modèles dessus, et compare manuellement. Un après-midi. C’est infiniment plus fiable que n’importe quel leaderboard.
5. Surveille les métriques « réelles »
Au-delà des scores bruts, regarde :
- Le coût par tâche résolue, pas juste le score d’accuracy
- La variance entre runs (un modèle qui réussit 80 % une fois et 50 % la suivante n’est pas utilisable en prod)
- Le comportement en cas d’échec — le modèle hallucine-t-il ou admet-il son erreur ?
- L’alignement — fait-il ce que tu lui demandes ou ce qui maximise sa métrique interne ?
6. Lis les papers METR et Berkeley
METR publie régulièrement des analyses critiques des évaluations. UC Berkeley a mis trustworthy-env open source pour auditer les benchmarks. Ces ressources sont gratuites et à jour — elles valent plus que dix rapports marketing de labos.
Ce qu’il faut retenir
La crise d’évaluation de l’IA en 2026 n’est pas un détail technique. C’est un signal structurel : les métriques que l’industrie utilise pour piloter des centaines de milliards d’investissement sont pour beaucoup devenues des illusions. Les benchmarks étaient des phares — ils sont devenus des miroirs qui renvoient aux modèles ce qu’on veut leur voir.
Ça ne veut pas dire que les LLMs n’ont pas progressé. Claude Opus 4.6, GPT-5 et Gemini 3.1 sont réellement plus capables que leurs prédécesseurs. Mais les chiffres publiés ne sont plus fiables comme source unique pour prendre une décision.
- Les benchmarks IA sont devenus security-critical — les hacker coûte 10 lignes de Python, et 8 benchmarks majeurs tombent en un après-midi de travail à Berkeley
- Le reward hacking est un phénomène général — pas un bug d’OpenAI ni d’Anthropic, mais une conséquence naturelle de modèles très capables sous pression d’optimisation
- SWE-bench Verified est mort, Humanity’s Last Exam a 30 % de réponses fausses, et même les scores ronds sont suspects
- Le bon réflexe en 2026 : tester sur ta propre tâche, comparer Verified/Pro quand ils existent, privilégier les benchmarks récents et privés, et surveiller coût, variance et alignement
- La confiance doit migrer — des leaderboards vers les tests empiriques, et des claims marketing vers les audits indépendants (METR, Berkeley, Artificial Analysis)
Dans l’ère des agents autonomes, savoir ce qu’ils ne savent pas vraiment faire devient aussi important que de savoir ce qu’ils prétendent savoir. Le prochain edge concurrentiel, pour toi comme pour les labos, sera peut-être cette lucidité.
