Un nouveau modèle sort, prend la tête du tableau, et en quelques heures quelqu'un dans ton entreprise transfère le graphique avec un « on devrait passer à celui-là ». Le tableau est joli, les barres sont plus longues que le mois dernier, et la conclusion paraît évidente : celui qui score le plus haut est le meilleur, donc c'est celui à utiliser. Un raisonnement propre, rapide, et presque toujours faux.
La thèse en une phrase : les benchmarks de LLM pour l'entreprise ne prédisent pas ton résultat. Le numéro un du classement gagne un examen standardisé —questions de quiz, problèmes de code jouets, énigmes de logique— qui ne ressemble en rien à ton vrai travail. Qui performe dans TON cas, ce sont tes données, ta tâche précise et ton contexte qui le décident, et ces trois facteurs n'apparaissent dans aucun tableau public. Choisir un modèle par le classement, c'est commencer au mauvais endroit, comme choisir un outil avant de savoir ce que tu vas automatiser.
Pourquoi les benchmarks de LLM pour l'entreprise ne prédisent pas ton résultat
Un benchmark est un examen : un ensemble fixe de questions à réponses connues, le même pour tous les modèles, qui produit un chiffre comparable. C'est très bien pour ce que c'est —comparer des modèles entre eux sur un test commun— et inutile pour ce que les gens croient : dire lequel marchera dans ton entreprise. Parce que ton entreprise ne demande pas au modèle de résoudre des énigmes de maths d'olympiade ; elle lui demande de lire tes mails, comprendre ton jargon, classer tes documents et ne pas inventer des données de ton catalogue. Rien de tout ça n'est à l'examen.
Il y a un problème plus gênant encore : l'examen fuite. Quand un benchmark est célèbre, ses questions finissent, d'une manière ou d'une autre, dans les données d'entraînement des modèles suivants. Résultat : bien scorer à un test connu mesure, en partie, combien le modèle a vu de ce test —pas comme il raisonne sur quelque chose qu'il n'a jamais vu, ce que tu vas justement lui demander—. Le tableau récompense celui qui a bachoté l'examen. Ton travail, c'est l'examen qu'aucun modèle n'a vu.
Le benchmark mesure un examen ; ton entreprise, c'est autre chose
Pense à la différence entre un candidat major à un test standardisé et celui qui fait vraiment bien ton travail. Ce ne sont pas toujours la même personne, pour la même raison : le test mesure une capacité générale et hors contexte, le vrai travail mesure l'adéquation avec un problème concret. Un modèle peut être brillant à raisonner dans l'abstrait et médiocre à résumer tes comptes rendus de réunion parce qu'il ne connaît ni tes sigles, ni ton ton, ni ce qui compte pour toi. Un autre, plus modeste au tableau, peut clouer ta tâche parce qu'il colle mieux à la forme de tes données.
Cela rejoint une erreur d'ordre qui coule des projets entiers, bien racontée dans le guide sur pourquoi les projets d'automatisation avec l'IA échouent : on choisit la technologie avant de comprendre le problème. Commencer par « quel est le meilleur modèle ? » est la version raffinée de cette même erreur. La question utile n'est pas lequel gagne le tableau, c'est lequel résout ta tâche avec tes données —et cette réponse n'est publiée nulle part, il faut aller la chercher.
Ce qui prédit ton résultat : tes données, ta tâche, ton contexte
Si le classement ne commande pas, qui commande ? Trois choses, et aucune ne tient dans une barre colorée :
- Tes données. Le modèle va travailler sur TON information —ton catalogue, tes mails, tes documents, ton jargon interne—, pas sur le corpus propre de l'examen. Un modèle qui brille sur du texte de manuel peut trébucher sur tes PDF mal scannés et tes tableaux bizarres. La qualité et la forme de tes données prédisent le résultat plus que n'importe quel classement. C'est pourquoi le premier travail n'est pas de choisir un modèle, c'est de regarder les données.
- Ta tâche précise. « Bien écrire » n'est pas une tâche ; classer des tickets, extraire des champs d'une facture ou rédiger avec ton ton, oui. Les modèles ne performent pas pareil sur toutes : l'un gagne à classer, l'autre à résumer, un autre à raisonner par étapes. Celui qui gagne ta tâche n'est pas celui qui gagne la moyenne de l'examen ; c'est celui qui gagne CETTE colonne, que le tableau agrégé cache.
- Ton contexte. Coût par usage, latence acceptable, si la donnée peut sortir de ton périmètre ou non, si tu dois l'autohéberger, quelles intégrations tu as. Un modèle un poil moins bon mais qui tourne dans ton cloud et respecte ton RGPD peut être le bon choix face au numéro un que tu ne peux pas utiliser. Le contexte n'est pas un détail : souvent c'est ce qui décide.
Le seul benchmark qui compte est celui que tu lances
La conclusion pratique n'est pas « ignore les modèles », c'est « monte ton propre examen ». Tu prends ta tâche réelle, tu prépares un jeu de cas à toi —avec les réponses que tu considères correctes— et tu y passes les deux ou trois modèles candidats. En une après-midi tu as ce qu'aucun classement ne te donne : lequel performe sur TON travail, avec TES données, à un coût que tu peux payer. C'est un eval, et c'est la différence entre choisir avec discernement et choisir par la barre la plus longue du graphique de la semaine.
Et cet eval n'est pas un luxe de labo : c'est la même discipline que décider bien quels processus automatiser avec l'IA —la tâche d'abord, le « avec quoi » après—. Il a en plus un atout que le classement n'aura jamais : il est stable. Le tableau change chaque mois et te pousse à courir après le modèle à la mode ; ton eval sur ta tâche reste valable quand sort le prochain numéro un, parce qu'il mesure la seule chose qui ne change pas : ton problème.
Alors, à quoi servent les benchmarks ?
Pas à rien. Ils servent à ce qu'ils sont : un filtre grossier et une carte du terrain. Ils te disent quels modèles sont dans la conversation, écartent ceux clairement à la traîne et te donnent une intuition d'où se trouve la frontière. Comme premier tri —« ces cinq-là valent le coup d'œil »— ils sont utiles. L'erreur n'est pas de lire le tableau ; c'est de le traiter comme la réponse finale au lieu du point de départ. Le classement te dit qui inviter au test ; ton eval décide qui tu recrutes.
Il y a une raison de fond pour laquelle on l'oublie : choisir le modèle top donne l'impression de progresser, c'est gratuit et ça ne demande aucun travail ; monter ton eval est ennuyeux et t'oblige à regarder tes propres données. Mais c'est le même auto-aveuglement que raconte le post sur pourquoi l'adoption, pas le modèle, décide du ROI de l'IA : la part qui décide du résultat est toujours celle qui n'est pas dans le keynote. Le modèle est la dernière décision, pas la première, et certainement pas celle qu'on prend en fixant un tableau.