Un score public dit ce qu'un modèle sait faire sur des tâches choisies par d'autres. Il ne dit pas ce que votre agent fera sur vos données, avec vos outils et sous vos règles. SWE-bench mesure la résolution de vrais tickets de code (Jimenez et al., 2024), GAIA l'assistance générale (Mialon et al., 2023), τ-bench le dialogue outillé avec un utilisateur simulé (Yao et al., 2024). Ce sont de bons instruments pour comparer des modèles. Un agent qui y brille peut pourtant échouer chez vous, parce que la distribution des cas réels ne ressemble pas à celle du benchmark.
Notre pratique tient en trois idées. Un jeu d'évaluation propre à chaque agent, construit à partir de cas réels. Trois familles de métriques : la réussite de bout en bout, la conformité du chemin et le coût par résolution. Et des juges, humains, programmés ou confiés à un modèle, que l'on évalue eux-mêmes avant de leur confier la décision de livrer.
Ce qu'un benchmark mesure, et ce qu'il tait
Même un benchmark bâti sur des cas réels doit être corrigé. Quand OpenAI a fait relire par 93 développeurs 1 699 tâches de SWE-bench, une partie s'est révélée difficile, voire impossible à résoudre en l'état ; la version « Verified » (13 août 2024) n'en retient que 500, validées à la main. Un score vaut ce que valent ses cas.
Kapoor et ses coauteurs (« AI Agents That Matter », 2024) ajoutent que les classements regardent la précision en ignorant le coût, que beaucoup de benchmarks d'agents manquent d'un jeu de test réservé, ce qui autorise surapprentissage et raccourcis, et qu'ils confondent les besoins de qui développe un modèle et de qui déploie une application.
< 25 %
Yao et al., « τ-bench », arXiv:2406.12045, 2024
En production, un agent répond des milliers de fois à la même question, formulée de mille manières. La métrique pass^k, qui exige le succès sur k essais indépendants, mesure cette constance. C'est elle qui décide si l'on peut laisser l'agent travailler seul.
Un jeu de cas né du terrain
Un bon jeu d'évaluation ne s'invente pas en réunion. Chaque cas naît d'une question telle qu'on la pose vraiment, fautes et créole compris, ou d'un échec réellement constaté. On y fixe les outils exigés, les outils absurdes dans ce contexte, et les cas où aucun outil ne doit être appelé. Les outils exécutés se lisent dans la trace du flux de réponse, pas dans ce que le modèle affirme avoir fait. Le reste est toléré : on chasse l'absurde, pas la nuance.
| Famille | Cas | Ce qui est vérifié |
|---|---|---|
| Découverte | 11 | L'outil des sites est appelé ; les vols ou le prix du carburant ne le sont pas |
| Langues | 9 | Une question en anglais, espagnol, allemand, italien ou portugais revient dans sa langue, avec les bons outils |
| Risques naturels | 7 | Cyclone, volcan, séisme, qualité de l'air : l'outil propre à chaque aléa |
| Petite conversation | 6 | « Bonjour », « ok », une salutation en créole : aucun outil appelé |
| Ancrage | 5 | La prose ne contredit pas la carte affichée : houle, commune d'une plage, date |
| Secours | 4 | Pharmacie de garde, hôpital, vol de sac : une orientation utile, pas une adresse de loisir |
| Honnêteté | 3 | Prix et disponibilité d'un hébergement : dire le trou plutôt qu'inventer |
| Hors champ | 3 | Une aide sociale, une cantine, la ligne directe d'un dirigeant : aucun outil appelé |
| Sept autres familles | 27 | Restaurants, déplacements, journée type, sorties, plages, achats, actualité |
Byss Research, harnais d'évaluation de l'assistant touristique, octobre 2026
Le harnais de notre assistant municipal ajoute un niveau bloquant, la sûreté : une urgence vitale renvoie aussitôt vers les numéros d'urgence, une question d'éligibilité est orientée, jamais tranchée, et aucun numéro ni lien n'est inventé. Un échec ici bloque la livraison, quel que soit le score moyen.
Évaluer la prose, pas seulement les outils
Vérifier qu'un agent appelle le bon outil ne suffit pas. Les mensonges polis vivent dans le texte : « cette formation n'existe pas », un taux national présenté comme celui d'une école, une adresse complétée de mémoire. Le 5 août 2026, trois défauts de cette nature ont été trouvés à la main sur un agent d'orientation vers la formation professionnelle. Chacun est devenu un cas, noté sur deux plans : les outils appelés, et des motifs exigés ou interdits dans la réponse.
81 % → 100 %
Byss Research, doctrine « Construire un agent qu'on peut prouver », 5 août 2026
Seconde précaution : séparer ce que l'agent affiche de ce qu'il dit. Noter la prose sur un prix que porte déjà une carte structurée fait osciller le score sans que l'agent ait changé. On note le texte visible quand l'agent doit le dire lui-même, le flux complet quand l'information doit seulement atteindre la personne.
Juger les juges
Zheng et ses coauteurs (NeurIPS 2023) ont montré qu'un grand modèle employé comme juge atteint plus de 80 % d'accord avec les préférences humaines, le niveau observé entre humains, mais qu'il porte des biais propres : préférence liée à la position, à la longueur, à ses propres réponses. Shankar et ses coauteurs (2024) décrivent la « dérive des critères » : il faut des critères pour noter des réponses, mais c'est en notant des réponses qu'on découvre ses critères.
D'où notre règle : un juge est évalué avant d'être cru. Confié à un modèle, il est d'abord confronté à un échantillon noté par des humains. Écrit en code, il est testé hors réseau : les réponses fautives recopiées de la production doivent échouer, les bonnes doivent passer. Et les attentes s'écrivent sur le sens : « 55 ans n'est pas trop vieux » contenait « trop vieux », et l'agent qui écrivait « gratwi » en créole échouait sur un motif qui cherchait « gratuit ». Un test qui punit une bonne réponse coûte plus cher qu'un test manquant : il fait corriger ce qui marche.
On peut aussi casser exprès ce qu'on prétend vérifier. Dans MAIVAR, notre outil de relevé de posture d'un poste de travail, 44 garanties ont été cassées une à une : chaque fois, un test est tombé. Un banc qu'aucune mutation ne fait échouer ne prouve rien.
Les métriques qui comptent
| Mesure | La question posée | Le piège |
|---|---|---|
| Réussite de bout en bout | La tâche est-elle accomplie, du point de vue de la personne ? | Compter les conversations closes plutôt que les problèmes résolus |
| Constance (pass^k) | La même demande réussit-elle à chaque essai ? | Juger sur un seul passage par cas |
| Conformité du chemin | Permissions, garde-fous et ordre des étapes ont-ils été respectés ? | Valider un bon résultat obtenu par un chemin interdit |
| Honnêteté sur les trous | L'agent dit-il ce qu'il ne sait pas, et ce qu'il a écarté ? | Récompenser la réponse la plus complète, même inventée |
| Coût par résolution | Combien d'appels, de temps et d'escalades humaines par tâche réussie ? | Mesurer la précision seule, sans le coût |
| Escalade justifiée | Les cas transmis à un humain devaient-ils l'être ? | Lire un taux de déflexion comme un indicateur de qualité |
Synthèse Byss Research, d'après Yao et al. (2024), Kapoor et al. (2024) et notre pratique
Une régression bloque la livraison
Un jeu d'évaluation ne sert que s'il est rejoué à chaque modification, comme une suite de tests unitaires. Nous l'organisons en filets, du moins cher au plus cher. D'abord des tests hors réseau et hors modèle, qui tournent en quelques millisecondes à chaque build. L'un vérifie le sélecteur d'outils d'un assistant dans les six langues qu'il promet : le 9 septembre 2026, avant correction, une question en allemand sur la météo n'exposait aucun outil, et le modèle répondait de mémoire sans le signaler. Ensuite seulement, l'évaluation de bout en bout, qui coûte des appels payants.
Deux précautions évitent les fausses alertes. Une panne de fournisseur se déguise en régression : un appel de modèle en échec, une limite de débit atteinte ou une synthèse revenue vide répondent tous avec un statut HTTP 200, et se comptent à part. Et l'évaluation juge avec les mêmes tables que la production : une évaluation qui juge avec ses propres règles finit par déclarer vert ce que la production compte en rouge.
Lire les traces, sans lire les gens
Les évaluations rejouent des cas connus ; les traces de production révèlent les autres. Notre journal mesure la forme, jamais le contenu : outil appelé, nombre de résultats, contraintes appliquées, durée, élargissements. La question de la personne n'y est jamais écrite : quand une page promet de ne rien conserver, une télémétrie bavarde en ferait un mensonge. Pour les agents qui agissent, la trace porte aussi la prédiction : dans Orion, chaque action est journalisée avec son impact attendu, puis confrontée au résultat réel sept jours plus tard.
Ce que nous en retenons
Un benchmark public sert à choisir un modèle ; un jeu de cas issu du terrain sert à décider si un agent peut travailler seul.
Évaluer les juges avant de les croire, et écrire les attentes sur le sens.
Bloquer la livraison sur régression, en distinguant la panne d'un fournisseur du défaut de l'agent.
Quand un décideur demande « comment savez-vous qu'il ne raconte pas n'importe quoi ? », la réponse ne peut pas être un adjectif : c'est un nombre de cas rejoués à chaque livraison, un journal que l'on peut ouvrir et une liste d'interdits vérifiable en conversation. Les principes de conception qui rendent ces mesures possibles font l'objet de notre note « Concevoir pour des systèmes agentiques dignes de confiance ».
Références
- [1]Jimenez, C. et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024.
- [2]Mialon, G. et al. (2023). GAIA: A Benchmark for General AI Assistants.
- [3]Yao, S. et al. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains.
- [4]Zheng, L. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023.
- [5]OpenAI, « Introducing SWE-bench Verified », 13 août 2024. lien ↗
- [6]Kapoor, S. et al. (2024). AI Agents That Matter. arXiv:2407.01502.
- [7]Shankar, S. et al. (2024). Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences. arXiv:2404.12272.
