Choisir un modèle quand les benchmarks ne suivent plus
TL;DR
À l'été 2026, les leaderboards LLM de référence ont gelé ou pivoté, et ce qui reste à jour est auto-rapporté par les constructeurs ou recopié par des agrégateurs non vérifiés. Un seul harnais indépendant tient encore — et il sature en haut de tableau. Résultat : la source de vérité qui reste, c'est ton propre codebase. Voici comment je tranche sans m'appuyer sur des chiffres que personne ne peut plus vérifier.
J’ai voulu comparer huit modèles ouverts pour choisir lesquels mettre sur mon layering. Je suis allé chercher des benchmarks indépendants et à jour. Il n’en reste presque plus un seul.
Où sont passés les leaderboards de référence ?
Pas « tous morts » — mais ceux sur lesquels on pouvait s’appuyer ont gelé ou changé de métier. HAL, le leaderboard de Princeton, a archivé son harness et pivoté vers la mesure de fiabilité plutôt que de performance brute. Le leaderboard officiel d’Aider n’a pas bougé depuis novembre 2025. Terminal-Bench officiel ne contient aucun des modèles que je voulais tester.
D’autres tournent encore — LiveCodeBench a même sorti une v2 en 2026, SWE-bench reste actif — mais leurs classements publics mélangent des harnais différents et des soumissions non reproductibles. Sur le tableau SWE-bench le plus consulté, la quasi-totalité des entrées sont auto-déclarées par les constructeurs, pas vérifiées indépendamment. Citer côte à côte le « 79 % » d’un modèle et le « 97 % » d’un autre n’a aucun sens : méthodes et dates différentes. C’est du marketing avec une décimale.
Restent des agrégateurs — llm-stats, benchlm — qui affichent des chiffres frais. Mais ils recopient sans vérifier : llm-stats admet lui-même n’avoir aucun résultat validé, et benchlm attribue des scores au mauvais modèle. « À jour » n’y veut pas dire « fiable ».
Le seul juge encore vivant sature
Il reste vals.ai : un harnais indépendant, encore mis à jour, qui couvre la plupart des modèles récents. C’est précieux, et je m’en sers. Mais il faut lire ce qu’il dit vraiment : sur SWE-bench Verified, les cinq premiers tiennent en quatre points, avec deux points d’erreur type. Autrement dit, le haut du classement n’est pas ordonnable statistiquement. Le benchmark ne te dit plus « celui-ci est meilleur que celui-là », il te dit « ces cinq-là jouent dans la même zone ». Utile pour éliminer le bas. Inutile pour départager le haut.
Le benchmaxxing n’est pas une théorie
Quand tu compares le score qu’un constructeur annonce à celui qu’un tiers indépendant mesure, l’écart va presque toujours dans le même sens. DeepSeek V4 Pro : 80,6 % annoncé, 74 % mesuré par le CAISI/NIST — six points et demi de moins. Hunyuan 3 : 53,2 annoncé, 31,6 % mesuré par Artificial Analysis — vingt et un points de moins. Une seule exception dans mon échantillon : Kimi, qui tient son chiffre à 0,8 point près quand on le vérifie. Un constructeur honnête sur six, c’est le taux de base qu’il faut avoir en tête avant de croire une slide.
Le critère qui compte n’est mesuré nulle part
Le pire, c’est que même un benchmark de code parfait ne répondrait pas à ma vraie question. Un agent CLI ne fait que du tool-calling : lire, éditer, lancer du bash, reboucler. Un modèle qui écrit du beau code mais rate un appel d’outil sur cinq est inutilisable — et aucun leaderboard de qualité ne mesure ça. Lequel tient vraiment, et pour quel rôle, c’est le sujet du guide ; ici je m’arrête au constat.
Je l’ai mesuré bêtement : la même tâche triviale, rejouée trois fois sur les modèles Go. Environ un tour sur trois sort faux — pas lent, pas imparfait : faux. Un échantillon unique donnait pourtant un « ça marche » impeccable. C’est exactement ce qu’un benchmark en une passe ne verra jamais, et ce qui compte le plus quand tu confies une chaîne d’outils à un modèle non déterministe.
Le verdict qui les couvre tous, d’un praticien qui les a tous poussés : « nothing seemingly comes close to GPT 5.5/5.6 xhigh for tasks beyond 5-10 minutes of work, they all more or less collapse after a while. » Traduit : ces modèles tiennent sur une tâche tightement scopée, et s’effondrent sur la durée. Aucun benchmark ne t’apprend ça — l’usage, oui.
Ce plafond tombe sur une habitude que j’avais déjà mesurée, et c’est ce qui le rend supportable : sur 267 sessions tracées, 62 % font moins de 10 minutes. La limite subie côté modèle est déjà, côté usage, le pattern dominant. Ça ne rend pas ces modèles bons sur la durée — ça veut dire que la durée est rarement ce que tu leur demandes.
Ce que je fais à la place
J’ai arrêté d’attendre un chiffre neutre qui n’existe plus. La seule source de vérité qui me reste, c’est mon propre codebase — et personne ne publie de benchmark PHP/Symfony, de toute façon. Alors je mesure moi-même : un vrai enchaînement d’outils sur une tâche réelle, quelques centimes de quota, et ça tranche là où les sources publiques divergent. Un run de cinq minutes sur ma stack m’en dit plus que n’importe quel leaderboard gelé.
Ce n’est pas très satisfaisant, et ça ne scale pas en tableau comparatif propre. Mais c’est la seule chose qui reste vraie. Les benchmarks te disaient quel modèle prendre ; maintenant ils te disent juste lesquels éliminer. Le choix final, il se fait chez toi, sur ton code — signé, daté, mesuré.