Ta barre d'éval pour agents est obsolète — EVA-Bench 2.0 en fixe une nouvelle

ServiceNow AI vient de publier EVA-Bench 2.0, un dataset public d'évaluation d'agents couvrant 121 outils, 3 domaines et 213 scénarios. Pour les CTOs qui ont validé un pilote agent cette année, c'est important — parce que le benchmark qu'utilise probablement ton équipe, un mélange de démos internes et d'impressions subjectives, a désormais un nom : "pas suffisant." Notre lecture : EVA-Bench 2.0 est le premier artefact externe assez concret pour ancrer une vraie conversation sur la production readiness. Si tu n'as pas encore défini ta propre surface d'éval, quelqu'un vient de le faire à ta place.

Ce qui a changé dans le benchmarking d'agents cette semaine

EVA-Bench 2.0, publié par ServiceNow AI sur Hugging Face, étend l'EVA-Bench original avec un dataset structuré conçu pour tester des agents sur des workflows multi-outils réalistes. Le benchmark est organisé en 3 domaines distincts — chacun représentant une classe de charge de travail enterprise — et couvre 121 outils avec 213 scénarios distincts, construits pour faire apparaître des modes d'échec que les évals mono-outil ratent systématiquement.

La philosophie de conception est délibérée. Plutôt que de tester si un modèle peut appeler une API correctement en isolation, EVA-Bench 2.0 enchaîne l'utilisation des outils sur des séquences réalistes — là où les agents en production échouent vraiment. Un scénario peut demander à un agent d'interroger une base de connaissances, de croiser les données d'un système de ticketing, puis de produire un output structuré — en séquence, avec un état maintenu entre les étapes. C'est un test fondamentalement différent de "est-ce que le modèle a choisi le bon nom de fonction."

Le dataset est public, structuré pour la reproductibilité, et sous licence MIT. Concrètement : ton équipe peut le télécharger aujourd'hui, faire tourner ses propres modèles dessus, et obtenir des chiffres au moins comparables à ce que les autres publient. Ça suffit à le placer devant la plupart des rigs d'éval internes qu'on a vus dans des entreprises qui déploient leur premier agent en production.

Pourquoi ton processus d'éval actuel ne survivra probablement pas à ce test

La plupart des pilotes agents qu'on audite en 2026 ont la même architecture d'évaluation : un ensemble de démos happy-path construites à la main, quelques cas limites qu'un membre de l'équipe a évoqués dans un thread Slack, et une barre implicite du type "le PM a validé après la revue du jeudi." Ce processus trouve les bugs que ton équipe connaissait déjà. Il ne trouve pas les modes d'échec qui émergent quand un agent rencontre des combinaisons d'outils qu'il n'a jamais vues, ou quand un appel API à la 4e étape retourne un schéma que ton prompt n'avait jamais anticipé.

La surface de 121 outils d'EVA-Bench 2.0 est significative parce qu'elle force une question que la plupart des équipes n'ont pas encore formellement posée : combien d'outils ton agent touche-t-il réellement en production, et as-tu évalué son comportement sur chaque combinaison significative ? Pour un agent de support client qui touche un CRM, une base de connaissances, un système de ticketing et une API email, la surface combinatoire est large — et le risque de régression à chaque mise à jour du modèle sous-jacent est bien réel. Sans éval structurée, tu ne sauras qu'une régression s'est produite que quand un client te le signalera.

Il y a aussi un angle sélection de fournisseur. Si tu évalues des frameworks d'agents tiers ou des modèles de fondation pour ton prochain build, EVA-Bench 2.0 te donne un vocabulaire commun pour exiger des chiffres comparables des vendors. "Comment votre modèle performe-t-il sur le domaine 2 d'EVA-Bench 2.0 ?" est une question d'achat bien plus solide que "pouvez-vous nous montrer une démo qui ressemble à notre cas d'usage."

Réserver un audit d'architecture Domani AI →

Le mouvement du lundi matin dépend de là où en est ton agent dans son cycle de vie

La bonne réponse à EVA-Bench 2.0, ce n'est pas "faire tourner le benchmark complet sur tout." C'est diagnostique. Commence par répondre à 5 questions sur ton agent actuel :

• Combien d'outils distincts appelle-t-il en production ? Si la réponse dépasse 5, tu as presque certainement des modes d'échec non couverts dans les séquences multi-étapes.
• As-tu une suite d'éval écrite, distincte de tes scripts de démo ? Si la démo et l'éval sont le même artefact, tu n'as pas d'éval.
• As-tu testé le comportement après ta dernière montée de version de modèle ? La plupart des équipes n'ont pas relancé de régression structurée depuis le build initial.
• Quelle est ta taxonomie d'erreurs ? Peux-tu catégoriser les échecs par type — mauvaise sélection d'outil, extraction de paramètre incorrecte, output halluciné — ou sais-tu juste que quelque chose a mal tourné ?
• As-tu un mapping de domaine ? La structure à 3 domaines d'EVA-Bench est une contrainte utile : peux-tu mapper la charge de travail de ton agent sur un domaine cohérent, ou s'étale-t-il sur des contextes pour lesquels il n'a jamais été conçu ?

Si tu as répondu "non" ou "je ne suis pas sûr" à 3 de ces questions ou plus, le mouvement du lundi est de cadrer un sprint d'éval structuré avant ton prochain déploiement en production. Télécharge le dataset EVA-Bench 2.0 depuis Hugging Face, identifie lequel des 3 domaines correspond le mieux à la surface d'outils de ton agent, et fais tourner ton modèle actuel contre le sous-ensemble de scénarios pertinents. Tu ne couvriras pas tout, mais tu auras une baseline documentée — ce qui est déjà plus que ce que la plupart des équipes qui déploient des agents aujourd'hui peuvent dire.

Si tu es plus tôt dans le cycle — en train d'évaluer s'il faut construire ou acheter une capacité agent — utilise EVA-Bench 2.0 comme ossature pour ton RFP vendor. Demande à tout fournisseur de modèle ou de framework de te montrer des scores par domaine. S'ils ne peuvent pas, c'est un signal qui mérite d'être pris en compte.

Ce que ça coûte, et ce que s'en passer coûte davantage

Faire tourner un sous-ensemble d'EVA-Bench 2.0 n'est pas gratuit. Un sprint d'éval structuré — cadrer les scénarios pertinents, instrumenter ton agent pour produire des outputs loggables, et analyser réellement les modes d'échec — prend de 2 à 4 semaines de temps ingénieur selon ton setup d'observabilité actuel. Si tu n'as aucune infrastructure d'éval aujourd'hui, compte la première semaine uniquement pour construire le harness avant de générer un seul chiffre utile.

Le coût de l'alternative est plus difficile à quantifier, mais plus facile à reconnaître après coup : une mise à jour de modèle qui dégrade silencieusement un workflow critique, un incident en production qui remonte à un échec de chaînage d'outils que ta démo n'a jamais touché, ou une décision d'achat qui semblait solide jusqu'à ce que les chiffres d'un vendor s'avèrent avoir été sélectionnés sur un benchmark qui ne correspond pas à ton stack. EVA-Bench 2.0 n'élimine pas ces risques — aucun benchmark ne le fait — mais il te donne un standard externe commun contre lequel mettre la pression, ce qui est une tout autre catégorie de défense que "ça marchait quand on l'a montré au board."