97 modèles, zéro arbitre : comment le classement est devenu un argument de vente

Il y a une scène qui résume l’année 2026 pour quiconque doit choisir un modèle open-weight. Vous ouvrez un premier leaderboard, disons LLMBoard, dont le snapshot est daté du 4 novembre 2026. En tête : Kimi K3 (Moonshot AI), avec un score de 84,59, suivi de Qwen3.8 Max (Alibaba) et GLM 5.3 (Zhipu AI). DeepSeek-V4.1 n’arrive qu’en cinquième position, V4-Pro en sixième. Vous ouvrez ensuite le classement d’Awesome Agents, un « Open-Source LLM Leaderboard » arrêté au 22 avril 2026. Là, c’est DeepSeek V4 qui trône en première place, avec un MMLU-Pro à 88,2 %, un GPQA Diamond à 87,6 %, un SWE-bench Verified à 83,7 % et un Elo Chatbot Arena de 1394. Kimi K3 ? Absent de la liste.

Deux plateformes, deux « numéros un » qui ne se recoupent pas, et un modèle qui disparaît purement et simplement d’un classement à l’autre. Voilà le paradoxe fondateur de ce dossier : le rang n’est pas une mesure, c’est le produit d’un protocole. Et tant que le protocole reste invisible, le rang ne dit presque rien.

La prolifération des leaderboards open-weight est réelle et documentée : aux côtés de LLMBoard et d’Awesome Agents, on trouve LM Market Cap, Artificial Analysis — qui revendique le classement de plus de 250 modèles sur des métriques d’intelligence, de prix, de vitesse et de fenêtre de contexte —, ou encore LMArena, l’arène de préférence humaine rebaptisée en janvier 2026, qui revendique plus de 7,1 millions de votes et 369 modèles évalués au 1er juillet 2026. Chacun de ces opérateurs a ses propres jeux de tâches, ses propres pondérations, son propre modèle économique.

C’est dans cet écosystème que le chiffre « 97 modèles classés » circule. Il faut être clair : ce décompte est un argument marketing à géométrie variable. Aucun opérateur unique ne chapeaute ces classements, aucune méthodologie commune ne les relie, et le nombre de modèles évalués dépend entièrement du bon vouloir de la plateforme qui publie. Un classement qui aligne 97 modèles n’est pas plus rigoureux qu’un classement qui en aligne 40 ; il est simplement plus large, et souvent plus hétérogène dans ce qu’il compare.

La vague open-weight a évidemment nourri cette inflation. Les modèles cités dans les classements de 2026 sont majoritairement chinois — DeepSeek (V4, V3.2-Speciale, V4.1, V4-Pro), Qwen (3.5, 3.6-35B-A3B, 3.8 Max/Flash), GLM (5.1, 5.2, 5.3), Kimi K3, MiMo de Xiaomi, Hy4 de Tencent — aux côtés de Meta (Llama 4 Maverick et Scout, puis Muse Spark Open, un MoE de 816 milliards de paramètres dont 42 milliards actifs, sorti le 15 octobre 2026), Mistral (Mistral Large 4, lancé le 6 octobre 2026) et Gemma 4. Chaque sortie réclame son rang, et chaque rang devient un argument de communication. Le leaderboard est devenu le terrain de sport d’une course à l’armement où le podium vaut communication.

MMLU-Pro, GPQA, SWE-bench, Elo : la boîte à outils du scoreur et ses angles morts

Pour comprendre pourquoi deux classements divergent, il faut d’abord regarder les briques de base. Chaque famille de benchmarks mesure une chose différente, et il est essentiel de ne pas les confondre.

MMLU-Pro évalue les connaissances académiques sur des questions à choix multiples, dans des domaines variés (droit, médecine, sciences, humanités). C’est un test de culture générale de haut niveau. GPQA Diamond sonde le raisonnement scientifique de niveau doctorat, sur des questions conçues pour être difficiles même pour des experts. SWE-bench Verified mesure le génie logiciel : le modèle doit résoudre de vrais problèmes de code issus de dépôts open source, en produisant un patch qui passe les tests. HumanEval évalue la génération de fonctions à partir d’une signature et de tests unitaires. MATH teste le raisonnement mathématique. IFEval mesure le respect d’instructions formelles. LiveCodeBench évalue le code sur des problèmes récents, précisément pour limiter la contamination. Et les arènes de préférence humaine, comme LMArena, produisent un score Elo (ou un classement Bradley-Terry) à partir de votes humains comparant deux réponses.

Le problème, c’est que ces briques ne sont pas commensurables. Un score de 88,2 % en MMLU-Pro et un Elo de 1394 ne mesurent pas la même chose, ne s’expriment pas dans la même unité, et ne se comparent pas. Pourtant, les agrégateurs les alignent dans une même colonne, comme si un 88,2 % de connaissances académiques et un Elo de préférence humaine pouvaient se ranger sur une même échelle. C’est là que se fabrique une fausse hiérarchie.

Chaque brique a par ailleurs ses angles morts. Les jeux de test publics sont saturés : quand plusieurs modèles atteignent 100 % sur AIME 2025, le benchmark cesse d’être discriminant. La contamination est un risque structurel pour tout jeu de test public, puisque les modèles sont entraînés sur des corpus web massifs qui peuvent contenir les questions et les réponses. Et la sensibilité au format est réelle : un modèle peut réussir une tâche en zero-shot et échouer en few-shot, ou l’inverse, selon la façon dont la question est posée.

Un classement qui agrège MMLU-Pro, GPQA, SWE-bench et Elo sans publier ses pondérations ne dit pas ce qu’il mesure. Il dit seulement qu’il a mesuré quelque chose.

Moyenne simple, Elo ou win-rate : l’agrégation comme choix politique

Voici le cœur méthodologique du problème. À partir des mêmes résultats bruts, deux modes d’agrégation produisent deux classements différents. Une moyenne simple (non pondérée) traite chaque tâche à égalité. Une moyenne pondérée par tâche accorde plus de poids à certaines dimensions. Un Elo ou un win-rate pairwise compare les modèles deux à deux, ce qui donne un classement relatif plutôt qu’absolu.

L’effet est mécanique. Prenez un modèle excellent en code mais moyen en raisonnement. Si le classement accorde un poids fort à SWE-bench, il grimpe. Si le poids est mis sur GPQA, il chute. Le même modèle, les mêmes scores bruts, deux rangs différents — parfois à dix places d’écart.

C’est exactement ce qui se joue entre LLMBoard et Awesome Agents. LLMBoard publie un « LLMBoard Score » unique (84,59 pour Kimi K3), sans que la composition de ce score soit explicite dans les extraits disponibles. Awesome Agents, de son côté, attribue des métriques distinctes (MMLU-Pro, GPQA, SWE-bench, Elo) sans publier de score agrégé unique. Les deux approches ne sont pas convertibles : un « LLMBoard Score » et un « indice Intelligence » d’Artificial Analysis ne sont pas des unités convertibles, pas plus qu’un Elo et un pourcentage de réussite.

Il faut aussi noter que les échelles ne sont pas les mêmes. Artificial Analysis classe plus de 250 modèles sur un indice d’intelligence, de prix, de vitesse et de contexte. Selon Slash Digital, citant Artificial Analysis, les meilleurs modèles open-weight atteignent 30 à 32 points sur l’indice Artificial Analysis v5.0, contre 58 pour le meilleur modèle fermé. Mais le leaderboard officiel d’Artificial Analysis place Gemini 4 Carbon (high) et Claude Opus 5.5 (max) en tête avec des scores de 60 et 59 — des modèles fermés. La cohérence entre ces chiffres n’est pas vérifiable dans les extraits disponibles, ce qui illustre à quel point les indices propriétaires sont opaques.

Le choix d’agrégation n’est donc pas neutre. C’est un choix politique : il décide de ce qui compte, et donc de qui gagne.

Zero-shot, CoT, few-shot, température : le protocole invisible qui déplace dix places

Il y a un angle mort encore plus grand que l’agrégation : le protocole de prompting. La plupart des leaderboards open-weight ne publient pas les paramètres qui déterminent pourtant le score.

Premier paramètre : le mode de prompting. Un modèle évalué en zero-shot (on lui pose la question directement) ne donne pas le même résultat qu’en chain-of-thought (on lui demande de raisonner étape par étape) ou en few-shot (on lui fournit des exemples). Un modèle peut gagner plusieurs points selon qu’on lui laisse dérouler un raisonnement ou non. Sur des tâches de raisonnement comme GPQA ou MATH, l’écart peut être significatif.

Deuxième paramètre : les paramètres de décodage. La température, le top-p, le nombre maximum de tokens générés influencent la qualité et la reproductibilité des réponses. Une température élevée favorise la diversité mais peut dégrader la précision ; une température basse favorise la déterminisme mais peut bloquer le raisonnement créatif.

Troisième paramètre : le nombre de runs et la variance. Un score unique masque la variabilité. Si un modèle obtient 88,2 % en moyenne sur cinq runs avec un écart-type de 3 points, le score réel est une fourchette, pas un chiffre. La plupart des leaderboards ne publient ni le nombre de runs ni la variance.

Quatrième paramètre : la gestion des refus et des réponses non parsables. Un modèle qui refuse de répondre à une question, ou qui produit une réponse impossible à parser automatiquement, est-il compté comme un échec ? La réponse dépend du protocole, et elle change le score.

L’absence de ces informations dans la plupart des leaderboards open-weight rend le rang non reproductible. Deux équipes qui évaluent le même modèle avec des protocoles différents obtiendront des scores différents. C’est ici que se joue l’écart de dix places entre deux classements « sérieux ».

Contamination, fuites et jeux de test publics : le talon d’Achille des benchmarks ouverts

Le problème de la contamination est structurel. Les modèles open-weight sont entraînés sur des corpus web massifs, qui peuvent contenir les questions et les réponses des benchmarks publics. MMLU-Pro, GPQA, HumanEval, SWE-bench : tous ces jeux de test sont publics, donc tous sont potentiellement contaminés.

Les stratégies de mitigation existent. Les jeux de test privés, non publiés, réduisent le risque de fuite. LiveBench et LiveCodeBench utilisent des problèmes récents, renouvelés régulièrement, pour limiter la contamination. La rotation des items est une autre approche. Mais ces stratégies ont un coût : elles demandent plus de travail, plus de ressources, et elles ne sont pas toujours compatibles avec un leaderboard public et gratuit.

Car c’est là le nœud : un leaderboard public et gratuit a structurellement intérêt à réutiliser des benchmarks connus. C’est moins cher, plus rapide, et plus facile à comparer. Mais c’est aussi plus vulnérable à la contamination.

La question de la licence et de la traçabilité des données d’entraînement est liée. Les modèles de tête cités en 2026 sont majoritairement chinois (DeepSeek, Qwen, GLM, Kimi, MiMo), et leurs licences maison — « Kimi K3 License », « Qwen3.8-Max License » — imposent des vérifications que le rang ne dit pas. À l’inverse, des projets comme Olmo 3 et 3.1 (Ai2) et Apertus v1.5 (Swiss AI Initiative) sont cités comme réellement ouverts : poids, code, checkpoints et jeux de données sous Apache 2.0. Ces projets permettent de vérifier — ou non — la propreté des données d’entraînement, ce que les modèles à licence maison ne permettent pas.

Le CEPD a d’ailleurs averti en décembre 2024 que des données d’entraînement traitées illicitement peuvent affecter la licéité d’un déploiement. Un rang élevé ne dit rien de la traçabilité des données.

Lire un score selon son cas d’usage : code, raisonnement, agents, multilingue, contexte long

La bonne question n’est pas « quel est le meilleur modèle ? » mais « quel benchmark regarder pour mon cas d’usage ? ». Voici une grille de lecture pratique.

Assistant de code. Regardez SWE-bench Verified et LiveCodeBench. Ignorez MMLU-Pro et les scores de culture générale. Un modèle qui excelle en code peut être médiocre en raisonnement général, et inversement.

Moteur de raisonnement. Regardez GPQA Diamond et MATH. Vérifiez le protocole de prompting : un score en chain-of-thought n’est pas comparable à un score en zero-shot.

Agent outillé. Regardez le taux de réussite multi-étapes et la robustesse au format. Les benchmarks classiques ne mesurent pas la capacité à utiliser des outils, à planifier, à corriger ses erreurs. Les scores Tau2-Bench et BFCL v4 sont plus pertinents — à titre d’exemple, Aleph Alpha Kolibri-1, sorti le 3 octobre 2026, affiche un Tau2-Bench Telecom à 94,7 %, un Tau2-Bench Airline à 76,7 %, un Tau2-Bench Retail à 69,9 % et un BFCL v4 à 61,4 %. Ces chiffres, issus de la fiche éditeur, illustrent la granularité nécessaire : un score unique masquerait ces écarts.

Application multilingue. Vérifiez la couverture des langues dans les jeux de test. Un modèle évalué uniquement en anglais peut être excellent en anglais et médiocre en français. Aleph Alpha Kolibri-1, par exemple, est annoncé avec l’allemand et l’anglais comme langues principales, ce qui ne dit rien de sa performance en français.

Pipeline à contexte long. Distinguez la fenêtre annoncée de la fenêtre réelle. Un modèle avec un contexte de 1M de tokens (comme Kimi K3, Qwen3.8-2.4T-A95B jusqu’à ~1M, ou Meta Muse Spark Open avec 1M) peut dégrader ses performances en milieu de contexte. La fenêtre recommandée en production est souvent inférieure à la fenêtre maximale : Aleph Alpha Kolibri-1 annonce une fenêtre maximale de 1 048 576 tokens mais une fenêtre recommandée en production d’environ 262 144 tokens.

Licence et traçabilité. Vérifiez la licence : Apache 2.0 (Kolibri-1, Olmo 3, Apertus v1.5) ou licence maison (Kimi K3, Qwen3.8-Max). La licence maison impose des vérifications que le rang ne dit pas.

Deux classements, un même modèle à dix places d’écart : dissection d’une divergence

Revenons à notre étude de cas. LLMBoard (4 novembre 2026) place Kimi K3 n°1 à 84,59, Qwen3.8 Max et GLM 5.3 sur le podium, avec DeepSeek-V4.1 seulement 5e et V4-Pro 6e. Awesome Agents (22 avril 2026) place DeepSeek V4 n°1 (MMLU-Pro 88,2 %, GPQA 87,6 %, SWE-bench 83,7 %, Elo 1394) et n’inclut même pas Kimi K3.

Comment expliquer cette divergence ? Plusieurs hypothèses.

Dates de snapshot différentes. LLMBoard est daté du 4 novembre 2026, Awesome Agents du 22 avril 2026. Entre les deux, sept mois se sont écoulés, et des modèles sont sortis : Kimi K3 (juillet 2026), Qwen3.8 (août 2026), GLM 5.3, Muse Spark Open (octobre 2026), Mistral Large 4 (octobre 2026). Un classement d’avril ne peut pas inclure un modèle de juillet.

Jeux de tâches différents. LLMBoard semble utiliser un score agrégé unique (LLMBoard Score), Awesome Agents attribue des métriques distinctes (MMLU-Pro, GPQA, SWE-bench, Elo). Les deux ne mesurent pas la même chose.

Agrégation différente. Si LLMBoard pondère fortement le code et Awesome Agents pondère fortement le raisonnement, les classements divergent mécaniquement.

Absence de protocole publié. Ni l’un ni l’autre ne publie les paramètres de prompting, de décodage ou de nombre de runs. Le rang n’est pas reproductible.

La leçon générale : les classements ne sont comparables ni dans le temps (un snapshot d’avril et un snapshot de novembre ne mesurent pas le même état de l’art) ni entre plateformes (deux agrégations différentes produisent deux hiérarchies différentes).

Croiser leaderboards, évaluations internes et tests maison : la méthode reproductible

Comment transformer un classement en décision d’architecture ? Voici une grille en plusieurs étapes.

Étape 1 : vérifier la fraîcheur du snapshot et l’opérateur. Un classement de six mois est périmé dans un écosystème où des modèles sortent tous les mois. Vérifiez qui publie, et si l’opérateur a un intérêt commercial.

Étape 2 : identifier les tâches et les pondérations. Regardez quels benchmarks sont utilisés, et comment ils sont agrégés. Si les pondérations ne sont pas publiées, considérez le score comme indicatif, pas comme décisif.

Étape 3 : contrôler le protocole de prompting et le nombre de runs. Si le protocole n’est pas publié, le rang n’est pas reproductible. Si le nombre de runs n’est pas publié, le score est une moyenne sans variance.

Étape 4 : construire un jeu d’évaluation interne. C’est l’étape la plus importante. Un jeu de 50 à 200 cas représentatifs de votre trafic réel suffit souvent à départager deux modèles. Il doit couvrir vos cas d’usage : code, raisonnement, agents, multilingue, contexte long.

Étape 5 : mesurer coût, latence et débit. La qualité n’est pas tout. Un modèle excellent mais lent ou cher peut être un mauvais choix. Artificial Analysis publie des métriques de prix, de vitesse (temps par tâche, latence) et de fenêtre de contexte — utilisez-les.

Étape 6 : tester la licence et la traçabilité des données. Vérifiez la licence (Apache 2.0 ou licence maison), et si les données d’entraînement sont traçables. Un modèle à licence maison impose des vérifications juridiques.

Critère de départage. Quand deux modèles sont à moins de deux points d’écart sur un leaderboard, le rang n’est généralement pas significatif. La variance, les intervalles de confiance et les différences de protocole rendent l’écart non concluant. Dans ce cas, départagez sur des critères opérationnels : coût, latence, licence, taille du modèle (un modèle de 2,4 billions de paramètres comme Qwen3.8-Max n’a pas les mêmes contraintes de déploiement qu’un modèle de 78 milliards comme Kolibri-1), et performance sur votre jeu interne.

Ce que le rang ne dira jamais : vers des évaluations ouvertes et auditables

La multiplication des leaderboards a un effet ambivalent. D’un côté, elle donne plus de signaux : on peut croiser plusieurs classements, comparer plusieurs méthodologies, et se faire une idée plus nuancée. De l’autre, elle réduit la comparabilité : deux classements qui ne mesurent pas la même chose ne peuvent pas être additionnés, et le praticien se retrouve à devoir interpréter des chiffres hétérogènes.

Ce que cette multiplication ne change pas, c’est la nécessité de tests maison. Aucun leaderboard ne connaît votre trafic, vos contraintes de latence, votre budget, vos exigences de licence. Un classement est un point de départ, pas une décision.

Les évolutions souhaitables sont claires. Publication des protocoles : les opérateurs devraient publier les tâches, les pondérations, les paramètres de prompting et de décodage, le nombre de runs et la variance. Jeux de test privés rotatifs : pour limiter la contamination, les benchmarks devraient être renouvelés régulièrement et ne pas être publics. Audits indépendants : des tiers devraient pouvoir vérifier les scores, ce qui suppose l’accès aux modèles et aux jeux de test. Benchmarks réellement ouverts : des projets comme Olmo 3 et Apertus v1.5, qui publient poids, code, checkpoints et jeux de données sous Apache 2.0, montrent la voie d’une évaluation traçable.

Le déplacement en cours est celui de la course au score unique vers des évaluations par cas d’usage. En 2026, choisir un modèle open-weight ne consiste plus à regarder le haut d’un classement, mais à croiser plusieurs sources, à construire son propre jeu d’évaluation, et à mesurer ce qui compte pour son cas d’usage. Le rang est un signal, pas une réponse. Et dans un écosystème où les modèles de tête changent tous les mois, la méthode reproductible vaut mieux que le chiffre unique.

Sources

• Open-Source LLM Leaderboard 2026: 97 Models Ranked — benchlm.ai
• Open-Source LLM Leaderboard 2026 | LM Market Cap
• LLMBoard
• Awesome Agents — Open-Source LLM Leaderboard, avril 2026
• Artificial Analysis
• Mistral launches open-source Mistral Large 4, details AI roadmap — SiliconANGLE
• Meta — Introducing Muse Spark Open
• Inception Releases Mercury 3 Diffusion LLM at 1,068 Tokens per Second — MarkTechPost
• OWASP GenAI Security Project Releases 2026 Top 10 for LLM Applications — Morningstar
• llm-d 1.0 Advances Open, Cost-Efficient AI Inference for Production Scale — Financial Times