Les classements d'agents induisent en erreur — benchmark sur tes propres outils

Les classements publics d'agents semblaient faire autorité — jusqu'à ce que des équipes mettent en production le modèle classé premier. Le taux d'échec des appels d'outils en production n'avait alors aucun rapport avec le score affiché sur le graphique. La raison est structurelle : chaque benchmark publié teste un ensemble fixe et sélectionné d'outils génériques, et ton stack interne n'en fait presque certainement pas partie. La position honnête est la suivante : le choix du modèle pour des charges de travail agentiques est impossible à trancher sans un harness d'évaluation pointé sur tes propres surfaces d'outils.

Ce qui a changé dans la façon dont le domaine mesure la capacité des agents

Le billet de l'équipe Hugging Face "Is it agentic enough?" formule la critique structurelle de façon explicite. Les benchmarks agentiques dominants — dont des suites très citées construites autour de la recherche web, de calculatrices et d'entrées/sorties fichiers — partagent une seule contrainte de conception : les surfaces d'outils sont fixes et standardisées pour que les résultats soient comparables entre labs. C'est la bonne propriété pour un classement comparatif. C'est la mauvaise propriété pour un opérateur qui cherche à choisir un modèle pour un agent interne qui appelle un ERP propriétaire, une API de récupération de documents sur mesure, et un service SOAP hérité enveloppé dans une fine surcouche REST.

Le billet met également en évidence le problème de composition sur plusieurs étapes. Un modèle qui atteint 80 % de précision sur un appel d'outil en étape unique ne délivre pas 80 % de complétion de tâche sur une chaîne de 5 étapes — il délivre environ 33 % (0,8⁵). Les classements rapportent presque toujours des scores en étape unique ou sur des horizons courts. L'écart entre ces scores et la complétion réelle des tâches s'élargit de façon non linéaire à mesure que la longueur des chaînes augmente — ce qui est précisément là où vivent les agents en entreprise : recherches multi-sauts, branches conditionnelles, étapes d'écriture.

Les sorties de modèles open source ont accéléré ce problème en 2025 et dans la première moitié de 2026. Quand un nouveau modèle affiche une amélioration de 3 points sur un benchmark public, la fiche modèle circule vite. Le schéma d'appel d'outils sur lequel il a été entraîné — qu'il préfère un function-calling JSON strict, un scratchpad de style ReAct, ou une boucle d'exécution de code — reçoit beaucoup moins d'attention dans l'annonce. Pourtant, c'est lui qui détermine si le modèle se dégrade de façon progressive ou catastrophique sur ton schéma.

Pourquoi cela change le calcul sur la possession de ton évaluation d'agents

La plupart des équipes à l'échelle 50–500 ETP n'ont pas d'infrastructure d'évaluation pour les agents. Elles ont un environnement de staging, une poignée de tests manuels, et quelqu'un qui fait tourner le modèle sur quelques prompts représentatifs avant un déploiement. C'était suffisant quand les LLMs complétaient du texte. Ce ne l'est plus quand le modèle appelle des outils avec des effets de bord — écriture d'enregistrements, déclenchement de workflows, mise à jour d'état.

L'implication stratégique est que la décision "quel modèle utiliser pour notre agent interne ?" se prend actuellement sans données valides dans la plupart des entreprises. Les équipes font du pattern-matching sur les titres des benchmarks, la réputation du fournisseur, ou le coût par token. Les trois sont des critères de départage raisonnables quand deux modèles sont par ailleurs équivalents pour ta tâche. Aucun n'est un substitut à la mesure de la précision des appels d'outils, de l'adhérence au schéma, et du taux de complétion multi-étapes sur tes outils réels.

Il y a aussi un risque d'approvisionnement qui joue dans l'autre sens. Si tu n'as pas construit le harness d'évaluation, tu ne peux pas non plus détecter une régression quand tu mets à jour le modèle ou changes le schéma d'un outil. Les stacks agentiques ne sont pas statiques — les outils évoluent, les modèles sont échangés, les templates de prompts dérivent. Sans évaluation continue sur des traces représentatives, tu voles sans instruments à chaque changement.

Le premier geste concret à faire dès lundi matin

La première question est de savoir si tu as les prérequis pour mener une évaluation significative. Travaille cette séquence avant de passer du temps sur la comparaison de modèles :

• As-tu des traces d'appels d'outils depuis la production ou le staging ? Sinon, instrumente ton framework agentique pour journaliser chaque appel d'outil, le schéma d'entrée envoyé, la sortie brute du modèle, et le résultat parsé. 2 à 3 jours de trafic, même à volume modéré, suffisent pour construire un corpus de replay.
• As-tu des étiquettes ground-truth pour un sous-ensemble de ces traces ? Tu as besoin d'au minimum 50 à 100 exemples labellisés — bon outil sélectionné, bons arguments, bonne réponse finale — pour obtenir un signal qui ne soit pas du bruit. Ce sont les experts métier de ton équipe, pas les ingénieurs ML, qui doivent labelliser.
• Ton nombre d'outils est-il suffisamment élevé pour que le choix du modèle compte ? En dessous d'environ 5 outils, presque tout modèle open source capable se comportera de façon similaire. Au-delà de 10 outils, surtout avec des schémas qui se chevauchent ou sont ambigus, le choix du modèle commence à compter significativement. Au-delà de 20, c'est probablement la variable dominante dans la fiabilité de l'agent.

Une fois ces prérequis réunis, l'évaluation en elle-même n'est pas coûteuse à lancer. Choisis 2 à 3 modèles candidats — au minimum celui que tu utilises actuellement, un challenger issu de la cohorte open-weight actuelle, et un modèle plus petit optimisé sur les coûts comme référence. Fais-les tous tourner sur ton corpus de replay avec des prompts identiques. Mesure séparément la précision des appels d'outils en étape unique, la validité du schéma des arguments, et la complétion de bout en bout sur les traces multi-étapes. Les deltas t'apprendront plus en une après-midi qu'une année à lire des posts de classements.

Si ton équipe n'a pas la capacité de construire le harness cette semaine, la version minimale viable est un log structuré et un échantillon labellisé. Tu pourras construire le runner de replay plus tard. Ne laisse pas l'infrastructure d'évaluation parfaite te bloquer dans la collecte des données dont tu auras besoin.

Ce que ça coûte, et ce que ça économise

Construire un harness d'évaluation d'agents minimal demande environ 2 à 4 semaines-ingénieur pour bien faire les choses — instrumentation, runner de replay, workflow de labellisation, et une couche de reporting assez simple pour qu'un product manager puisse la lire. C'est un coût réel, qui ressemblera à une taxe d'infrastructure dans un trimestre où la feuille de route est déjà chargée.

Le coût de l'alternative est plus difficile à voir, mais plus important. Les équipes qui sautent l'étape de l'évaluation découvrent généralement les modes de défaillance spécifiques à un modèle en production. Dans le meilleur des cas, cela signifie une expérience utilisateur dégradée pendant un sprint pendant que tu corriges les templates de prompts en urgence. Dans le pire des cas — quand les agents ont un accès en écriture aux systèmes d'enregistrement — cela signifie des problèmes d'intégrité des données qui prennent des semaines à démêler. Le risque de régression justifie à lui seul l'investissement dans l'infrastructure : chaque mise à jour de modèle sans harness est un changement non contrôlé sur un système avec des effets de bord. Les entreprises qui auront un avantage durable en fiabilité des agents au cours des 18 prochains mois ne sont pas celles qui ont choisi le bon modèle dans un classement. Ce sont celles qui ont construit la couche de mesure en premier.