Comment lire un benchmark de modèle d'IA sans se faire avoir

Un nouveau modèle sort, un tableau circule, trois chiffres en gras et une conclusion : « il dépasse la concurrence ». Le lendemain, quelqu'un l'essaie sur son cas réel et trouve le résultat décevant. Les deux observations sont compatibles, parce qu'un benchmark IA ne mesure presque jamais ce que l'on croit qu'il mesure.

Ce n'est pas une accusation de tricherie généralisée. Les jeux d'évaluation publics sont des instruments de recherche utiles, construits pour comparer des systèmes sur une tâche précise et reproductible. Le problème naît de leur usage détourné : on transforme un score de recherche en argument d'achat, on compare des mesures obtenues dans des conditions différentes, et on en tire des décisions de production.

Cet article propose une lecture méthodique : ce que chaque famille de benchmarks couvre, les biais qui gonflent les scores, la raison pour laquelle un écart de deux points est invisible à l'usage, et la seule évaluation qui vous concerne vraiment, celle que vous construisez sur vos propres cas.

Ce qu'un benchmark IA mesure, et ce qu'il ne mesure pas

Un benchmark est un triplet : un jeu de questions, une méthode d'interrogation, une règle de notation. Changez un seul des trois et le score bouge, parfois de plusieurs points, sans que le modèle ait changé.

La règle de notation est le point le plus sous-estimé. Sur un questionnaire à choix multiples, on compare une lettre : c'est objectif et pauvre. Sur une tâche de code, on exécute des tests : c'est objectif et exigeant. Sur une tâche de rédaction, il faut un juge, humain ou modèle, et l'on retombe dans la subjectivité, avec en prime les préférences propres au juge, qui a tendance à récompenser les réponses longues et bien formatées.

Ce qu'aucun benchmark public ne mesure : votre vocabulaire métier, la qualité en français sur vos documents, la latence dans votre architecture, le comportement face à des données mal formatées, le coût d'un appel dans votre volume réel, et la stabilité de la réponse d'un jour sur l'autre. Ces six dimensions déterminent pourtant l'essentiel de votre satisfaction.

Les grandes familles de benchmarks et leur zone de validité

Pour comparer les modèles IA de façon utile, il faut d'abord savoir de quelle famille vient chaque chiffre.

Le point important : ces familles ne sont pas interchangeables. Un modèle excellent sur les tâches de code peut être médiocre en synthèse de documents en français. Les corrélations entre familles existent mais restent lâches, ce qui rend le classement LLM unique, toutes tâches confondues, largement décoratif.

Les six biais qui gonflent les scores

Avant de croire un écart, passez-le au filtre de cette liste. La plupart des chiffres spectaculaires meurent dès le deuxième point.

1. La contamination. Les jeux d'évaluation publics finissent dans les données d'entraînement. Un modèle qui a vu les réponses ne raisonne pas, il se souvient. C'est la raison pour laquelle les benchmarks les plus récents sont remplacés régulièrement et pourquoi les jeux privés gardent de la valeur.
2. Les conditions d'interrogation. Zéro exemple ou cinq exemples dans le prompt, avec ou sans raisonnement explicite demandé, avec ou sans plusieurs tentatives : ces choix valent plusieurs points. Deux chiffres obtenus dans des conditions différentes ne se comparent pas.
3. Le nombre de tentatives. Un score qui accepte la meilleure de plusieurs propositions n'a rien à voir avec un score à la première réponse. C'est pourtant le même tableau qui les affiche parfois côte à côte.
4. La sélection des tâches. Un tableau publié par un éditeur retient les épreuves où son modèle gagne. Ce n'est pas malhonnête, c'est du marketing. Cela impose simplement de chercher les épreuves absentes.
5. L'incertitude statistique. Sur un jeu de quelques centaines de questions, l'intervalle de confiance dépasse souvent deux points. Un écart inférieur à cet intervalle n'est pas un écart, c'est du bruit.
6. Le juge modèle. Quand un modèle note les réponses, il favorise les productions qui ressemblent aux siennes, préfère les textes longs et se laisse influencer par l'ordre de présentation.

Pourquoi deux points d'écart ne se voient jamais à l'usage

Faites le calcul. Sur un jeu de mille questions, deux points représentent vingt réponses qui basculent. Si vos utilisateurs traitent trente demandes par jour, il faudrait des semaines d'usage attentif pour percevoir statistiquement la différence, à condition que vos demandes ressemblent à celles du jeu de test. Ce qu'ils percevront en revanche dès le premier jour, ce sont trois autres choses.

• La latence. Un modèle qui répond en deux secondes est jugé meilleur qu'un modèle plus précis qui répond en douze, sur toutes les tâches interactives.
• Le format et le ton. Une réponse bien structurée en français correct sera préférée à une réponse plus exacte mais mal calibrée. C'est injuste et c'est ainsi.
• Le comportement aux limites. Comment le modèle réagit quand la question est mal posée, quand le document fourni est incomplet, quand il ne sait pas. Ce point ne figure dans presque aucun classement et détermine pourtant la confiance des équipes, comme le montre le sujet des hallucinations des IA génératives.

Conclusion pratique : au-delà d'un certain niveau, les modèles de la même génération se départagent sur le coût, la latence, la disponibilité et les garanties contractuelles, pas sur deux points de score.

La seule évaluation qui compte : la vôtre

Évaluer un modèle de langage pour votre usage demande moins de travail qu'on ne le croit. Comptez une journée pour la première version, puis une heure par mois d'entretien.

1. Constituez trente à cinquante cas réels. Prenez-les dans vos archives : vraies demandes clients, vrais documents, vrais courriers. Incluez volontairement dix cas tordus, ceux qui posent problème aux humains.
2. Écrivez la réponse attendue. Pas forcément mot pour mot : les points qui doivent figurer, ceux qui ne doivent pas, et le format acceptable.
3. Fixez les conditions. Un prompt figé, les mêmes paramètres, la même température pour tous les modèles comparés. Sans cela, vous reproduisez le biais numéro deux.
4. Notez sur trois axes. Exactitude, respect du format, absence d'invention. Une note binaire par axe suffit et se tient dans un tableur.
5. Mesurez aussi le coût et le temps. Consignez la latence médiane et le nombre de jetons consommés par cas. C'est ce qui rendra la décision arbitrable, avec la grille de décision par cas d'usage.

Ce jeu de tests a une seconde vie : il devient votre filet de sécurité lors des changements de version. Le jour où votre fournisseur met à jour son modèle, vous rejouez les cinquante cas et vous voyez en dix minutes ce qui a régressé. La méthode complète est détaillée dans notre article sur la façon d'évaluer les réponses d'une IA avec un jeu de tests.

Une lecture en cinq questions

Face au prochain tableau qui circule, posez ces cinq questions dans l'ordre. Elles suffisent à trier ce qui mérite votre attention.

• Qui a produit la mesure, et le modèle testé appartient-il à l'auteur du tableau ?
• Quel jeu, quelle version, et depuis combien de temps est-il public ?
• Dans quelles conditions d'interrogation, et sont-elles identiques pour tous les concurrents ?
• L'écart annoncé dépasse-t-il l'incertitude statistique du jeu ?
• La tâche mesurée ressemble-t-elle, même de loin, à ce que vous voulez faire ?

Un benchmark IA reste un outil précieux : il oriente une présélection, il signale une rupture réelle de capacité, il permet de suivre une tendance sur plusieurs années. Il ne remplace pas une heure passée à faire tourner cinquante de vos propres cas. La bonne nouvelle, c'est que cette heure est aussi la moins chère du projet.