#Pourquoi les benchmarks comptent (et vous trompent)

Un benchmark LLM, c'est un jeu de questions dont on connaît les réponses, qu'on pose à un modèle pour compter combien il en réussit. Le résultat est un score — un pourcentage, un classement Elo, un taux de résolution. C'est le seul langage commun qui permet de comparer deux modèles sans les tester soi-même pendant des heures, et c'est pour ça que tout le monde s'en sert.

Le problème n'est pas le principe, c'est l'écart entre ce que le score dit et ce que vous lisez dedans. Un modèle qui affiche 90 % à MMLU n'est pas « intelligent à 90 % » : il répond correctement à 90 % d'un QCM de culture académique. Ça ne dit rien de sa capacité à suivre vos instructions, à écrire du français correct, à ne pas halluciner sur votre domaine, ou à tenir une conversation de dix tours. Un benchmark mesure une compétence étroite dans des conditions de laboratoire.

La règle à garder en tête

Un benchmark répond à la question « ce modèle réussit-il CETTE tâche précise ? » — jamais à « ce modèle est-il meilleur pour MON usage ? ». Les deux se recoupent parfois, souvent partiellement, jamais totalement.

On peut ranger les benchmarks en trois grandes familles, qui ne mesurent pas la même chose et ne se manipulent pas de la même façon : les benchmarks académiques (des QCM de connaissance et de raisonnement), les benchmarks de tâches réelles (résoudre un vrai bug, utiliser des outils) et les arènes de préférence humaine (des humains votent pour la meilleure réponse). On va les prendre dans l'ordre.

#Les benchmarks académiques : MMLU, GPQA, MATH

C'est la famille historique, celle des tableaux de scores qu'on voit sur les pages de sortie de modèles. Ce sont des ensembles de questions à réponse vérifiable, souvent des QCM, notés automatiquement. Leur force est la reproductibilité ; leur faiblesse est qu'ils sont faciles à saturer et à contaminer.

MMLU: Massive Multitask Language Understanding : ~14 000 questions de QCM réparties sur 57 matières (droit, médecine, histoire, maths…). Le benchmark de connaissance le plus cité. Aujourd'hui largement saturé : les bons modèles dépassent 88-90 %, l'écart entre eux se joue dans le bruit.
MMLU-Pro: Version durcie de MMLU : 10 choix au lieu de 4, questions retriées pour être plus difficiles, plus de raisonnement. Créée précisément parce que MMLU ne discriminait plus les modèles de tête.
GPQA (Diamond): « Google-Proof Q&A » : questions de niveau doctorat en biologie, physique et chimie, conçues pour qu'une recherche Google ne suffise pas. Le sous-ensemble « Diamond » est le plus dur. Bon indicateur du raisonnement scientifique de pointe.
MATH / AIME: Problèmes de mathématiques (MATH : niveau lycée/concours ; AIME : olympiades américaines). Réponse numérique unique, donc facile à noter. Devenu un marqueur des modèles « à raisonnement » (reasoning) qui réfléchissent en plusieurs étapes.
IFEval: Mesure la capacité à SUIVRE des instructions vérifiables (« réponds en exactement 3 puces », « n'utilise pas la lettre e »). Souvent plus révélateur pour un usage réel qu'un QCM de connaissance.
HLE (Humanity's Last Exam): Benchmark récent et volontairement extrême : questions expertes multi-domaines pensées pour rester difficiles longtemps. Les meilleurs modèles y plafonnent encore bas, ce qui en fait un bon discriminateur en 2026.

Attention au protocole de mesure

Un même modèle peut afficher deux scores MMLU différents selon la méthode : 0-shot vs 5-shot (avec exemples), avec ou sans chain-of-thought, avec un prompt exact vs reformulé. Comparer deux scores mesurés dans des conditions différentes n'a aucun sens. Vérifiez toujours que la comparaison est faite « à protocole égal ».

#Les benchmarks de tâches réelles : SWE-bench et les agents

Cette famille est plus jeune et beaucoup plus dure à tricher, parce qu'elle ne pose pas des questions : elle demande d'accomplir une tâche complète dont le résultat est vérifiable objectivement. Résoudre un vrai ticket GitHub, faire passer une suite de tests, naviguer dans un dépôt de code. On en parle en détail dans notre guide dédié aux benchmarks de code ; voici l'essentiel.

SWE-bench Verified: Un sous-ensemble de 500 vrais problèmes GitHub (issues + patch attendu) validés manuellement par OpenAI comme résolvables et bien spécifiés. Le modèle doit produire un patch qui fait passer les tests du dépôt. C'est devenu LE standard pour le code en conditions réelles, bien plus parlant que HumanEval (aujourd'hui saturé à 96-98 %).
SWE-bench (full / Lite): La version complète (~2 300 tâches) et une version allégée pour itérer vite. Les scores publiés dépendent énormément du « harnais » (l'agent qui orchestre le modèle) : un même modèle peut gagner 15 points selon l'outillage autour.
Tau-bench / agentiques: Benchmarks d'agents qui utilisent des outils (appels de fonctions, API, respect de règles métier) sur plusieurs tours. Mesurent la fiabilité en usage « assistant qui agit », pas seulement qui répond.
LiveCodeBench: Problèmes de programmation compétitive collectés en continu, avec une date de publication. On peut ne noter que les problèmes postérieurs à la date d'entraînement d'un modèle — un antidote direct à la contamination.

Pourquoi ces benchmarks sont plus fiables

Un patch qui fait passer les tests, c'est vérifiable objectivement et difficile à mémoriser bêtement : le modèle doit vraiment produire une solution qui marche. C'est pour ça que les benchmarks agentiques résistent mieux à la saturation que les QCM.

#LMArena : le classement par préférence humaine

LMArena (l'ex « Chatbot Arena » de LMSYS) fonctionne autrement : deux modèles anonymes répondent à la même question posée par un vrai utilisateur, qui vote pour la meilleure réponse. À partir de millions de duels, on calcule un score Elo (le même système que les échecs). C'est le benchmark le plus proche de « quel modèle les gens préfèrent-ils réellement ? ».

Ce que ça mesure bien: La qualité perçue en conversation ouverte : ton, structure, utilité globale, capacité à donner une réponse agréable. C'est très corrélé à la satisfaction d'usage réel.
Ce que ça mesure mal: La justesse factuelle. Les votants récompensent souvent les réponses longues, bien formatées et confiantes — même quand elles sont fausses. Un modèle « flatteur » peut monter au classement sans être plus exact.
Elo n'est pas un pourcentage: Un écart de 10-20 points Elo est du bruit statistique. Regardez toujours l'intervalle de confiance affiché : deux modèles peuvent être « à égalité » même s'ils ne sont pas sur la même ligne du tableau.
Les sous-classements: LMArena propose des catégories (code, maths, réponses longues, style contrôlé). Le sous-classement « hard prompts » ou « style control » est souvent plus informatif que le classement global, qui mélange tout.

→

Croisez les deux mondes

Un modèle fort en benchmarks académiques mais faible en Arena est souvent « bon élève mais rigide ». Un modèle fort en Arena mais moyen en GPQA est souvent « agréable mais moins fiable sur le fond ». Le bon compromis se lit à l'intersection des deux, pas dans un seul classement.

#Le piège n°1 : la contamination des données

La contamination, c'est quand les questions d'un benchmark (ou leurs réponses) se retrouvent, volontairement ou non, dans les données d'entraînement du modèle. Le modèle ne raisonne alors plus : il récite. Les benchmarks publics circulent sur le web, GitHub, Hugging Face — ils finissent mécaniquement dans les corpus de pré-entraînement. Résultat : un score gonflé qui ne prédit rien sur des questions inédites.

C'est le talon d'Achille de tous les benchmarks statiques et publics. Plus un benchmark est ancien et célèbre, plus le risque est élevé. Quelques signaux qui doivent alerter :

Écart entre versions: Un modèle qui cartonne sur MMLU mais s'effondre sur MMLU-Pro (mêmes matières, questions neuves) sent la mémorisation plus que la compréhension.
Score anormalement élevé pour la taille: Un petit modèle 7B qui bat des 70B sur UN benchmark précis et un seul : méfiance, souvent un entraînement ciblé (« benchmaxxing ») sur ce jeu de test.
Benchmarks datés: Les évaluations « live » (LiveCodeBench, questions horodatées) contournent le problème : on ne note que ce qui est postérieur à la date de coupe du modèle.
Trous de mémoire suspects: Certains tests injectent des variantes canari (« canary strings ») ou des reformulations pour détecter la récitation. Un gros écart entre question originale et reformulée trahit la contamination.

#Le piège n°2 : la saturation

Un benchmark est saturé quand les meilleurs modèles y atteignent des scores si hauts qu'il ne les distingue plus. Quand tout le monde est à 96-99 %, les 3 points restants sont du bruit de mesure (questions ambiguës, erreurs d'étiquetage) plutôt qu'une vraie différence de capacité. HumanEval (code) et MMLU (connaissance) sont les exemples canoniques : ils ont été très utiles, ils ne le sont plus pour départager le haut du classement.

C'est pour ça que de nouveaux benchmarks plus durs apparaissent en permanence : MMLU-Pro remplace MMLU, GPQA Diamond et HLE prennent le relais pour le raisonnement, SWE-bench Verified remplace HumanEval pour le code. Un benchmark a une durée de vie utile ; passé un certain niveau moyen, il faut le retirer de vos critères de décision.

Ne comparez pas dans la zone de saturation

Choisir entre deux modèles à 97,1 % et 97,8 % sur un benchmark saturé, c'est choisir sur du bruit. Descendez d'un cran : regardez un benchmark plus dur, ou mieux, testez-les sur vos propres tâches. La différence qui compte pour vous n'est presque jamais dans ces 0,7 point.

#Lire un leaderboard sans se faire avoir

Voici la méthode à appliquer devant n'importe quel tableau de scores, qu'il vienne d'un communiqué de modèle ou d'un classement public.

01
Identifiez qui publie
Un graphique dans l'annonce d'un modèle est du marketing : il choisit les benchmarks favorables et le protocole avantageux (cherry-picking). Un leaderboard tiers et neutre (Open LLM Leaderboard, LMArena, la page officielle de SWE-bench) est bien plus fiable qu'un slide de lancement.
02
Vérifiez le protocole
0-shot ou few-shot ? Avec chain-of-thought ? Avec quel harnais pour l'agentique ? Deux scores ne se comparent que si la méthode est identique. Un astérisque « self-reported » (auto-déclaré) vaut moins qu'un score reproduit par un tiers.
03
Regardez les intervalles de confiance
Sur LMArena, un écart Elo inférieur à ~15 points est du bruit. Sur les benchmarks à faible échantillon (GPQA Diamond, 198 questions), une poignée de bonnes réponses fait bouger le score de plusieurs points. Un classement sans marge d'erreur est un classement à prendre avec des pincettes.
04
Croisez plusieurs benchmarks
Ne décidez jamais sur un seul chiffre. Un modèle solide est bon sur une famille de tests variés, pas sur un seul pic. Un pic isolé et anormal évoque plutôt une optimisation ciblée.
05
Pondérez par VOTRE usage
Vous faites du code ? Regardez SWE-bench et LiveCodeBench, pas MMLU. Du français ? Aucun de ces benchmarks n'est en français — cherchez des évaluations FR ou testez vous-même. De la conversation ? LMArena prime. Le meilleur modèle « en moyenne » n'est pas forcément le meilleur pour vous.

#Évaluer un modèle local sur vos propres tâches

La conclusion logique de tout ce qui précède : le benchmark le plus fiable pour vous, c'est le vôtre. Il ne peut pas être contaminé (vos questions ne sont pas sur le web), il n'est jamais saturé (vous le calibrez sur vos cas difficiles), et il mesure exactement ce dont vous avez besoin. Pas besoin d'infrastructure lourde : une vingtaine d'exemples représentatifs suffisent pour départager deux modèles.

01
Constituez un mini-jeu de test
Rassemblez 15 à 30 prompts tirés de vos vrais cas d'usage (mails à rédiger, extractions, questions sur vos documents, bouts de code). Pour chacun, notez ce qu'une bonne réponse doit contenir. Gardez ce jeu privé et stable pour comparer les modèles dans le temps.
02
Installez les modèles à comparer
Avec Ollama, tirez les modèles candidats. Ollama expose une API compatible OpenAI sur http://localhost:11434, ce qui permet d'automatiser les appels.
03
Automatisez les appels
Un petit script boucle sur vos prompts et enregistre les réponses de chaque modèle côte à côte, dans un fichier, pour les comparer à froid sans vous laisser influencer par le nom du modèle.
04
Notez en aveugle
Relisez les réponses sans savoir quel modèle a produit quoi (mélangez l'ordre). Notez sur vos propres critères : exactitude, respect de la consigne, qualité du français, absence d'invention. C'est votre « Arena » personnelle.
05
Mesurez aussi le coût réel
La qualité ne fait pas tout : notez la vitesse (tokens/seconde) et la VRAM consommée. Un modèle 14B en Q4_K_M (~9 Go) qui tient sur votre RTX 4070 et répond vite peut battre un 70B (~40 Go) théoriquement « meilleur » mais injouable chez vous.

Terminal — préparer les modèles à comparer

# Récupérer deux candidats via Ollama
ollama pull qwen3:14b
ollama pull gemma3:12b

# Vérifier qu'ils répondent (API locale sur le port 11434)
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:14b",
  "prompt": "Résume ce texte en 3 puces : ...",
  "stream": false
}'

eval_local.py — comparer deux modèles sur vos prompts

import json, requests

OLLAMA = "http://localhost:11434/api/generate"
MODELES = ["qwen3:14b", "gemma3:12b"]

# Vos prompts réels — la clé d'une éval qui vous ressemble
prompts = [
    "Rédige un mail de relance poli à un client en retard de paiement.",
    "Extrais les dates et montants de ce texte : ...",
    "Explique la différence entre Q4_K_M et Q8_0 en 2 phrases.",
]

def interroger(modele, prompt):
    r = requests.post(OLLAMA, json={
        "model": modele, "prompt": prompt, "stream": False
    }, timeout=120)
    return r.json()["response"].strip()

resultats = []
for p in prompts:
    ligne = {"prompt": p}
    for m in MODELES:
        ligne[m] = interroger(m, p)
    resultats.append(ligne)

# À relire en aveugle, sans regarder la colonne du modèle
with open("comparaison.json", "w", encoding="utf-8") as f:
    json.dump(resultats, f, ensure_ascii=False, indent=2)
print("OK — comparaison.json généré, notez les réponses à froid.")

→

Outils si vous voulez industrialiser

Pour aller plus loin qu'un script maison, des outils comme lm-evaluation-harness (le standard académique, celui qui alimente l'Open LLM Leaderboard) ou promptfoo (orienté comparaison de prompts et de modèles) permettent d'automatiser la notation. Mais pour un choix perso, 20 exemples notés à la main battent n'importe quel score public.

#Pour aller plus loin

Ces guides prolongent les notions vues ici, du côté des benchmarks spécialisés et du choix concret d'un modèle local :

Benchmarks de code en détail: « HumanEval est mort : comprendre les benchmarks de code LLM en 2026 » creuse SWE-bench, LiveCodeBench et comment lire les scores de code — le prolongement direct de ce guide côté développement.
Choisir sa quantization: « Quantization GGUF en 2026 : Q4_K_M vs Q5_K_M vs Q6_K » montre comment mesurer l'impact réel d'une quantization sur la qualité — une éval maison appliquée à un cas concret.
Un test de modèle complet: « Qwen 3 en local : test complet et benchmarks réels » illustre la méthode d'évaluation locale (tokens/sec, qualité FR, VRAM) sur un modèle précis.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Premiers pas · 11 min

Benchmarks LLM : comprendre les leaderboards (MMLU, Arena, SWE-bench)