Ce que les benchmarks ne mesurent pas

Chaque nouvelle génération de modèles s'annonce avec un tableau de scores. MMLU : 88,7%. HumanEval : 92%. GPQA Diamond : 71%. Les chiffres montent. Les modèles s'améliorent. Et pourtant, quiconque utilise ces outils en production sait que les chiffres ne racontent pas toute l'histoire.

Il y a un écart réel entre ce que les benchmarks mesurent et ce qui compte en pratique. Comprendre cet écart est devenu une compétence nécessaire pour quiconque prend des décisions sur les outils IA.

Le problème de la contamination

Les benchmarks sont des ensembles de questions-réponses connus. Les données d'entraînement des modèles sont massives. La probabilité que ces questions aient été vues pendant l'entraînement — et que les réponses aient été mémorisées plutôt qu'apprises — est non nulle et difficile à quantifier.

Les équipes de recherche reconnaissent ce problème et tentent de le mitiger. Certains benchmarks sont maintenus privés. D'autres sont renouvelés régulièrement. Mais la contamination reste une préoccupation réelle qui affecte la confiance qu'on peut accorder aux scores annoncés.

Ce qui n'est pas dans MMLU

MMLU (Massive Multitask Language Understanding) teste des connaissances factuelles dans 57 domaines. Il mesure bien ce qu'il mesure : la capacité à répondre à des QCM de connaissances.

Ce qu'il ne mesure pas : la calibration (le modèle dit-il quand il ne sait pas ?), la cohérence sur un dialogue long, la capacité à suivre des instructions complexes multi-étapes, la fiabilité sur des tâches répétées, le comportement sous ambiguïté.

Un modèle peut scorer 90% sur MMLU et halluciner de façon confiante sur des sujets hors distribution. La confiance du modèle — son estimation de sa propre incertitude — est rarement capturée par les benchmarks standard.

Le cas HumanEval et la génération de code

HumanEval mesure la capacité à générer du code Python correct pour des problèmes de type interview. C'est un signal utile. Mais en production, les ingénieurs travaillent sur des codebases de milliers de fichiers, avec des dépendances, des conventions maison, des contraintes de sécurité.

Écrire une fonction triée en isolation, c'est facile. Comprendre pourquoi un bug de concurrence apparaît dans un système distribué réel, c'est autre chose. Les benchmarks de code existants ne testent presque jamais le deuxième cas.

Les dimensions non mesurées

Quelques dimensions qui manquent systématiquement dans les benchmarks publics :

Robustesse à la reformulation. Un bon modèle donne la même réponse à une question posée différemment. Beaucoup de modèles sont sensibles à la formulation exacte de manière surprenante.

Comportement en cas d'information contradictoire. Les problèmes réels présentent souvent des données incohérentes. Comment le modèle gère-t-il la contradiction ?

Latence et débit en conditions réelles. Les benchmarks mesurent la qualité des réponses, rarement le temps nécessaire pour les produire sous charge.

Comportement en boucle agentique. Un modèle utilisé dans un agent fait des dizaines d'appels en cascade. Les erreurs se composent. Aucun benchmark standard ne mesure la dégradation sur une chaîne de 20 appels.

Comment en tenir compte

La bonne pratique n'est pas de rejeter les benchmarks — ils donnent un signal utile sur la capacité générale. C'est de les compléter par une évaluation sur ses propres cas d'usage, avec ses propres données.

Un "benchmark interne" de 50 à 100 cas représentatifs de votre usage réel vaut souvent plus qu'un score MMLU pour choisir entre deux modèles. Ce n'est pas glamour. Ce n'est pas ce que les communiqués de presse annoncent. C'est ce qui fonctionne.