Pourquoi les benchmarks IA ratent 90 % du travail réel

Une amie dirige les opérations d'une entreprise de logistique de taille moyenne, et le printemps dernier, son équipe a passé trois semaines à évaluer si un LLM pouvait reprendre leur workflow de gestion des exceptions : le travail peu glamour consistant à rapprocher des factures qui ne correspondent pas aux bons de commande, entre trois systèmes qui se détestent. La présentation du fournisseur était remplie de chiffres impressionnants : MMLU, GSM8K, HumanEval, quelques benchmarks agentiques. Le modèle a brillé à chaque test préparé. Puis ils l'ont confronté à une vraie semaine d'exceptions, et il a rapproché avec aplomb une facture de 14 000 $ du mauvais bon de commande, parce qu'un fournisseur avait abrégé son propre nom différemment. Aucun classement ne mesure ça.

Cet écart est désormais mesurable. Une récente cartographie des benchmarks publics d'IA par rapport à la taxonomie O*NET du département du Travail américain, soit les 923 professions et 18 797 tâches qui composent le travail américain, révèle que 90 % des heures de travail aux États-Unis sont consacrées à des tâches peu ou pas couvertes par des benchmarks. Seules 208 professions sur 923 ont au moins une tâche soutenue par cinq prompts de benchmark ou plus. Six des 22 familles de métiers n'en ont aucune. La conclusion dérangeante n'est pas que l'IA est faible. C'est que nos instruments de mesure des capacités de l'IA visent presque exclusivement la mauvaise partie de l'économie.

Ce que couvrent réellement les benchmarks d'IA

La méthodologie derrière cette cartographie mérite d'être comprise, car elle est plus rigoureuse que ne le laisse penser le titre. Les chercheurs ont retenu 29 benchmarks agentiques de haute qualité, non saturés (des tests où les modèles doivent réellement accomplir un travail plutôt que répondre à des questions), et ont utilisé un juge LLM, validé par des experts humains, pour étiqueter chaque prompt de benchmark avec les tâches O*NET qu'il sollicite. Une tâche est considérée comme « couverte » si au moins cinq prompts lui correspondent. En combinant cela avec des estimations du temps de travail consacré à chaque tâche, on obtient une vue globale de ce que notre suite d'évaluation peut réellement voir.

Ce qu'elle voit est étroit et haut, pas large. Le génie logiciel et l'analyse financière sont saturés de benchmarks. La conduite de camions, l'exploitation d'une centrale à gaz, la restauration et la plupart du travail quotidien dans la santé sont pratiquement invisibles. Et le biais ne tient pas seulement à la question de savoir quelles tâches sont techniquement automatisables. Les tâches étiquetées « exposées à l'IA » ont environ six fois plus de chances d'être couvertes par un benchmark que les tâches non exposées, ce qui est logique, mais même après contrôle de ce facteur, les tâches issues de professions représentant de fortes masses salariales sont nettement surreprésentées. Les tâches des avocats sont très bien couvertes. Les secrétaires juridiques et les greffiers, pourtant exposés à des risques d'automatisation similaires, apparaissent à peine.

Relisez ça : nous évaluons l'IA sur la version prestigieuse d'un métier tout en ignorant celle que la plupart des gens exercent réellement. La longue traîne du travail intellectuel à revenu intermédiaire (les coordinateurs, employés administratifs, spécialistes et planificateurs dont les heures représentent une part énorme de l'économie) ne dispose presque d'aucune infrastructure de mesure. Quand quelqu'un affirme que l'IA peut faire un certain pourcentage du « travail intellectuel », demandez-lui de quel travail il parle, mesuré comment, et selon quelle liste de tâches. La réponse honnête est généralement : une tranche mince et non représentative, mesurée avec des tests conçus pour des articles de recherche.

La saturation des benchmarks est un échec de conception d'évaluation

J'ai passé des années à construire des pipelines d'évaluation, et la leçon la plus dure a été celle-ci : un benchmark est un modèle du monde, et la plupart des benchmarks sont de mauvais modèles. Ils compressent une tâche humaine complexe, contextuelle et multi-étapes en un prompt propre avec une réponse vérifiable, parce que c'est ce qui coûte le moins cher à corriger. Ensuite, la loi de Goodhart fait le reste. Dès qu'un benchmark devient la cible du développement d'un modèle, il cesse de mesurer la capacité qu'il était censé représenter. Les données d'entraînement absorbent la distribution du test, les équipes optimisent pour le classement, et les scores grimpent pendant que les performances réelles stagnent, voire régressent.

La saturation n'est que le symptôme visible. Quand chaque modèle de pointe dépasse 90 % à un test, celui-ci ne discrimine plus, mais le problème plus profond est que nous réagissons en construisant un nouveau benchmark dans le même style, couvrant les mêmes types de tâches, parce que ce sont celles que nous savons corriger automatiquement. Les QCM engendrent des QCM plus difficiles. Les défis de code engendrent des défis de code plus difficiles. Pendant ce temps, personne ne construit le benchmark pour « repérer que la clause d'indemnisation de ce contrat contredit discrètement la term sheet de mars », parce que la correction exige un juriste, du temps et des jugements qui résistent à l'automatisation.

C'est pourquoi je ne suis pas d'accord avec l'idée que la saturation d'un benchmark signifie que l'IA a « résolu » un domaine. La saturation signifie simplement que l'instrument est à bout. Un thermomètre qui affiche 40 °C au maximum ne prouve pas que la pièce est à 40 degrés ; il prouve qu'il vous faut un autre thermomètre. Si vous évaluez des modèles pour la production, surtout si vous construisez des systèmes de décision basés sur des LLM où les erreurs ont un coût réel, les écarts de classement sur des benchmarks saturés ne devraient pratiquement peser aucun poids dans votre décision.

Nous savons précisément à quel point les modèles sont bons pour le travail que nous avons décidé de mesurer. Nous ne savons presque rien des quatre-vingt-dix pour cent restants.

L'effet réverbère dans l'évaluation de l'IA

Il existe une vieille blague sur un ivrogne qui cherche ses clés sous un réverbère, non pas parce qu'il les a perdues là, mais parce que c'est là qu'il y a de la lumière. La construction des benchmarks suit la même logique, et les données confirment que ce n'est pas le fruit du hasard. L'étude de cartographie montre que l'importance d'une tâche au sein d'une profession prédit sa couverture : les tâches O*NET jugées les plus importantes pour leur métier ont six à dix fois plus de chances d'être benchmarkées que les moins importantes. À première vue, cela ressemble à une priorisation raisonnable. En pratique, cela signifie que nous mesurons les tâches vitrines et délaissons le tissu conjonctif.

Chaque métier est surtout du tissu conjonctif. La tâche benchmarkée d'un ingénieur logiciel est « implémenter une fonction qui passe ces tests ». Sa journée réelle comprend la lecture de la migration à moitié terminée d'un collègue, la recherche de la personne qui décide vraiment d'un sujet, et le constat que le ticket décrit le mauvais problème. J'ai déjà écrit sur la manière dont les outils de codage agentiques réussissent ou échouent exactement sur ce point : la boucle, le contexte et les limites de permissions comptent plus que la qualité brute de génération. Rien de tout cela n'apparaît dans un score de type HumanEval.

Il existe aussi un problème de définition subtil dans les chiffres de couverture eux-mêmes. « Couvert » signifie que cinq prompts ou plus correspondent à une tâche, pas que ces cinq prompts capturent la tâche. Treize prompts sur le conseil aux parents face aux difficultés éducatives ne représentent pas ce que fait réellement un travailleur social sur l'ensemble de son portefeuille de dossiers, au tribunal et lors d'une visite à domicile. Si l'on appliquait la définition de « bien couvert » d'un profane, la part mesurée de l'économie ne serait pas de 10 %. Elle serait quasiment nulle. Le réverbère n'éclaire pas seulement une zone étroite : la lumière qu'il projette est faible.

Les modèles génèrent, mais personne n'évalue le jugement

Voici l'asymétrie que je trouve la plus accablante. Presque tous les benchmarks existants testent la production : écrire le code, rédiger le mémo, résoudre le problème. Or la moitié économiquement critique de la plupart des tâches réelles est la détection : repérer l'erreur, signaler l'incohérence, savoir quand la réponse assurée est fausse. La valeur d'un comptable junior n'est pas de produire un rapprochement ; elle consiste à remarquer qu'un chiffre sent le roussi. Les benchmarks testent rarement cela, car construire une tâche de détection d'erreurs notée est bien plus difficile que construire une tâche de génération notée. Il faut des artefacts défectueux réalistes, des erreurs plausibles mais subtiles, et un accord humain sur ce qui compte comme détecté.

C'est le sophisme du portier appliqué à la conception d'évaluations. Remplacez un portier par une porte automatique et vous découvrez, trop tard, que le portier accueillait aussi les locataires, réceptionnait les colis et surveillait la rue. Automatisez la partie benchmarkée d'un métier et vous découvrez que les parties non benchmarkées portaient la structure. Mon amie de la logistique a vu son modèle rédiger d'excellentes notes de rapprochement, la tâche visible, tout en bâclant silencieusement le rapprochement lui-même, le jugement qui rendait ces notes utiles. La suite d'évaluation a noté la garniture et ignoré le plat principal.

Tant que la détection d'erreurs n'aura pas droit à un traitement de premier plan dans les benchmarks, attendez-vous à un écart persistant entre les performances en démo et en production. C'est le même écart qui existe entre ce que dit une spécification et ce que fait l'implémentation, et comme dans le logiciel, c'est dans cet écart que naissent les défaillances. Un modèle qui génère au 90e percentile mais vérifie au 30e n'est, en production, qu'un employé au 30e percentile doté d'un avantage en vitesse de frappe.

Pondérer les évaluations selon la distribution réelle des tâches

L'idée la plus pratique du travail de cartographie des benchmarks est aussi la plus simple : si les benchmarks surreprésentent certaines tâches, arrêtez de moyenner sur les prompts et commencez à moyenner sur les tâches, pondérées par le temps de travail réel qu'elles consomment. Une moyenne naïve de tous les prompts étiquetés « analyste financier » est dominée par la tâche qui possède le plus de prompts de benchmark, généralement celle qui était la plus facile à transformer en jeu de données. Une moyenne pondérée selon O*NET donne à chaque tâche réelle le même poids. La différence peut être spectaculaire.

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

Deux points à remarquer dans cet extrait. D'abord, le score pondéré baisse parce que les tâches les plus faibles du modèle étaient sous-représentées dans le pool de prompts, exactement la distorsion qu'une moyenne uniforme masque. Ensuite, et c'est plus important : « conseiller le client » disparaît complètement du calcul, car aucun prompt ne lui correspond. Tout schéma de pondération écarte silencieusement les tâches sans couverture, et l'absence de couverture est la norme pour la plus grande partie de l'économie. La pondération résout le problème de pondération. Elle ne peut pas résoudre le problème des données manquantes. Cela exige de construire de nouvelles évaluations, pas de re-moyenner les anciennes.

Comment évaluer l'IA sur le travail que vous faites réellement

Si vous choisissez ou déployez des modèles, l'écart de couverture à l'échelle de l'économie a une implication concrète : les benchmarks publics sont un a priori faible pour votre cas d'usage, à moins que vous ne vous trouviez dans le petit coin vif qu'ils mesurent. Construisez donc votre propre coin. C'est moins héroïque que ça en a l'air, et c'est bien plus fiable que de se fier à une présentation de fournisseur.

• Échantillonnez les tâches à partir des logs, pas de votre imagination. Extrayez une semaine de vrais tickets, e-mails ou exceptions et échantillonnez selon la fréquence. Votre jeu d'évaluation doit ressembler à l'histogramme de votre charge de travail, y compris la longue traîne ennuyeuse, et c'est elle qui constitue la plus grande part du travail.
• Pondérez par le temps ou le coût, puis rapportez les deux chiffres. Une moyenne uniforme et une moyenne pondérée encadrent la vérité. Si un modèle gagne la moyenne uniforme mais perd la moyenne pondérée, c'est qu'il excelle dans les tâches faciles à tester, précisément le mode d'échec que vous cherchez à détecter.
• Incluez des tâches de vérification. Prenez de vraies sorties, y compris des sorties connues pour être mauvaises, et évaluez la capacité du modèle à repérer les erreurs introduites et les erreurs naturelles. D'après mon expérience, la compétence de détection et la compétence de génération sont à peine corrélées, et c'est la détection que vous achetez réellement.
• Gardez un jeu privé et renouvelez-le. Toute évaluation réutilisée pendant des mois devient une cible d'entraînement, même involontairement, dès que quelqu'un commence à ajuster ses prompts en fonction d'elle. Renouvelez les cas chaque trimestre.
• Évaluez les résultats de bout en bout lorsque c'est possible. Si la tâche est « rapprocher cette facture », notez le rapprochement, pas la prose intermédiaire. Les métriques intermédiaires flattent les modèles comme les tests unitaires flattent un code sans couverture d'intégration.

Il existe un effet final, plus discret, qui mérite d'être nommé, et que quiconque utilise quotidiennement des outils de codage IA reconnaîtra : la maladie des coûts de Baumol à micro-échelle. Quand la génération devient vingt fois plus rapide, vous ne passez pas votre journée à générer. Vous la passez sur les parties qui n'ont pas été accélérées : relire, coordonner, vérifier, décider. Le reliquat non benchmarké ne rétrécit pas à mesure que l'IA progresse ; il grossit pour occuper le temps libéré, et devient une part plus grande de ce qui détermine si le déploiement de l'IA en valait la peine. Mesurer la tranche automatisable avec une précision toujours plus grande en ignorant le reste n'est pas seulement incomplet. Cela inverse ce qui compte.

Rien de tout cela ne signifie que les progrès de l'IA sont factices : les gains de capacité sont réels, et j'ai engagé des projets sur eux. Il s'agit de dire que notre culture de la mesure vise la mauvaise distribution. Les benchmarks ont été construits là où les prompts étaient peu coûteux à écrire et à corriger : code, mathématiques, connaissances de type examen. L'économie n'est en grande partie pas de cette nature. Tant que l'évaluation ne rattrapera pas son retard, considérez chaque affirmation de capacité retentissante comme une déclaration sur le dixième éclairé de la carte, et construisez les évals qui couvrent vos propres quatre-vingt-dix pour cent d'ombre. Les organisations qui feront ce travail de mesure rigoureux et peu glamour prendront de meilleures décisions de déploiement que tous ceux qui rafraîchissent les classements, et l'écart ne sera pas mince.