Un agent de traitement des factures lit le message d'un fournisseur, prépare un ordre de paiement et indique que la tâche a réussi. Cette phrase peut décrire plusieurs tests différents. L'un a vérifié l'ordre proposé. Un autre a appelé un outil de paiement simulé. Un troisième a examiné l'écriture comptable obtenue et l'approbation qui l'a autorisée. Chaque test peut produire un résultat utile, et chacun étaye une conclusion différente sur l'agent.
Le scénario est illustratif. Il pose une question de recherche : quelle conclusion une évaluation d'agent publiée permet-elle de tirer, compte tenu du système et des observations qui l'ont produite ? Cet article examine deux prépublications récentes, un Internet-Draft individuel et un article de benchmark plus ancien, rend compte du comptage d'un fichier de résultats publié, et propose une fiche de périmètre qui devrait accompagner tout score mis en avant. Cet article est le deuxième de la série Notes de recherche sur l'exécution des agents. La note précédente porte sur la manière dont la déclaration de réussite d'un agent d'IA peut influencer son réviseur.
Formuler l'affirmation visée avant de choisir un benchmark
Agent Evaluation Reliability: More Tasks Won’t (Always) Fix An Agent Leaderboard, une prépublication déposée le 30 septembre 2026 par Michael Hardy, Ruhana Azam, Anka Reuel, Mykel Kochenderfer et Sanmi Koyejo, distingue deux questions auxquelles un classement peut répondre. La première porte sur le système complet le mieux classé. La seconde porte sur le modèle sous-jacent le mieux classé. Les auteurs appliquent une décomposition bayésienne de la variance à 22 benchmarks : neuf issus du Holistic Agent Leaderboard (HAL) et treize de l'Harbor Index.
Les auteurs indiquent que les classements de systèmes fixes associant modèle et scaffold étaient plus fiables que les classements des modèles sous-jacents. Leurs mesures de fiabilité décrivent la stabilité d'un classement pour les modèles, scaffolds et tâches échantillonnés. Elles ne disent rien de la fréquence à laquelle un agent accomplit une tâche, et n'établissent pas si un classement mesure la bonne capacité. L'acceptation de l'article n'a pas été vérifiée. Lire l'article.
Un scaffold est le logiciel qui entoure le modèle : il gère l'état, expose les outils et transforme les sorties du modèle en actions. Un acheteur qui choisit une application d'agent complète devrait inclure ce logiciel dans le système évalué. Une équipe qui choisit un modèle de remplacement devrait traiter ce même logiciel comme une condition à maintenir fixe ou à faire varier délibérément.
Formulez la conclusion visée en une phrase avant de construire ou de lire une évaluation. Par exemple : « Cette configuration peut préparer un ordre de paiement autorisé à partir de ces types de documents, selon cette politique d'approbation. » La phrase fixe le processus, l'action et les conditions que les preuves doivent couvrir. Une affirmation générale sur les capacités d'un agent exigerait un dispositif bien plus large.
Déclarer le périmètre testé
Evaluation Profiles for AI Agent Security Assessment, de Han, Chen, Fan et Wu, a été publié le 23 octobre 2026. Il organise l'évaluation autour de profils d'infrastructure et de scénario, demande que les rapports déclarent les profils retenus et leur configuration, et que les métriques sans objet soient explicitement signalées. Le document est la révision 00 d'un Internet-Draft individuel. Il ne bénéficie d'aucun soutien de l'IETF et n'a aucune valeur normative ; nous l'utilisons ici comme une proposition concrète de format de rapport, en cours d'élaboration. Lire la proposition et son statut.
Pour un processus métier, une déclaration de périmètre nomme les parties du système qui ont produit le résultat et la partie qui l’a jugé :
La persistance demande une ligne à part. Une session vierge ne peut pas montrer comment un agent traite les informations conservées d'une session à l'autre, question que traite la note sur les politiques dans la mémoire des agents. Un outil simulé étaye des affirmations sur la simulation. Une affirmation sur un service réel exige des preuves couvrant l'interaction avec le service et l'état qu'elle a laissé.
- Modèle : identifiant de la version figée (snapshot) et paramètres d'inférence.
- Scaffold : le logiciel d'exploitation et sa version.
- Outils et permissions : les outils que l'agent pouvait appeler, et ce que chacun était autorisé à modifier.
- État de départ : les données du cas de test et leur réinitialisation entre deux cas.
- Destinations des effets : les systèmes qui reçoivent les effets, et pour chacun s'il est simulé ou réel.
- Observateur : ce que le correcteur pouvait lire. Un correcteur qui lit la conversation de l'agent dispose d'autres preuves qu'un observateur qui lit une base de données faisant foi après l'exécution.
Vérifier ce qu'établissent les outils et le correcteur
Do Agent Benchmarks Do What They Say?, une prépublication déposée le 29 septembre 2026 par Rohith Reddy Bellibatlu, Zichong Wang et Wenbin Zhang, traite le comportement annoncé de chaque outil comme un contrat et vérifie l'implémentation au regard de ce contrat. Sur quatre benchmarks, les auteurs signalent sept défauts d'outils et une propriété de l'évaluateur, à des commits figés. Des défauts déjà connus ont en partie guidé leur choix de benchmarks : les constats sont donc des exemples et ne fournissent aucun taux général de défauts. L'instantané de code antérieur des auteurs emploie d'autres termes ; nous suivons la classification de l'article. Lire l'audit.
L'article MedAgentBench, plus ancien (version 2, 12 février 2025), montre une limite énoncée dans ses propres méthodes. Son dispositif d'évaluation envoie des requêtes GET à l'environnement, vérifie le contenu des requêtes POST et signale à l'agent la réussite de l'exécution ; la notation des actions vérifie le contenu demandé. Les auteurs documentent ce choix, ce qui permet d'interpréter les résultats sur les actions dans ce cadre. Lire les méthodes d'origine, sections 2.4–2.4.3.
Pour un processus de facturation, distinguez quatre étapes et conservez chacune de celles qui existent. Si l'évaluation s'arrête à l'une d'elles, rendez ce point d'arrêt visible dans le résultat.
- Ordre proposé : ce que l'agent avait l'intention de faire.
- Requête à l'outil : ce que l'agent a réellement envoyé.
- Réponse de l'outil : ce que l'outil a renvoyé. Un message de réussite est une affirmation de l'outil lui-même.
- Effet enregistré : ce qu'un observateur indépendant a constaté ensuite dans le système de référence.
Une fiche de périmètre commentée pour un paiement fournisseur
Prenons un processus fictif de paiement fournisseur avec trois dispositifs d'évaluation. L'entrée est fixe : fournisseur SUP-042, facture INV-042 de 1 200 EUR, et la consigne de préparer un paiement unique qu'un opérateur financier doit approuver avant tout enregistrement de paiement. L'exécution du paiement n'existe que dans une simulation locale. Aucun modèle, simulateur ni processus de paiement n'a été exécuté, et la version du modèle, le harness (l'outillage qui pilote l'évaluation) et les versions de l'évaluateur restent à choisir. Le tableau est un extrait de la fiche de périmètre d'évaluation (en anglais) complète.
Le fournisseur, le montant et l'approbation requise sont identiques dans les trois dispositifs, et les colonnes de résultats restent séparées. Ajouter une mémoire persistante introduit un nouveau comportement à observer. Déplacer l'hôte des outils déplace l'endroit où les permissions et les effets sont contrôlés. Le dispositif C exécute en outre deux sessions : son budget de ressources diffère, et la fiche signale cet écart. Des versions de modèle identiques ne suffiraient pas à rendre les trois scores interchangeables.
| Champ | A : préparation de l'ordre | B : simulation d'approbation | C : simulation de processus persistant |
|---|---|---|---|
| Outils | Aucun | read_invoice, request_approval, record_payment dans une simulation locale | B, plus write_supplier_memory et read_supplier_memory |
| Limite des permissions | Génération de sortie uniquement | Le simulateur vérifie l'acteur, l'identité de l'approbation, la facture et le montant | B, plus accès à la mémoire fournisseur et à la mémoire de session |
| Accès de l'évaluateur | Cas de test d'entrée et sortie | Cas de test, trace complète des outils, enregistrement de décision, état du simulateur avant et après | B, plus instantanés de la mémoire et trace des lectures et écritures |
| Effet significatif | Aucune opération de paiement n'existe | Transition locale de l'état du paiement | Transition locale de l'état du paiement après des lectures de données persistées |
| Exclusions | Exécution, application de l'approbation, mémoire, effets réseau | Circuit de paiement réel, mémoire entre sessions, délégation | Circuit de paiement réel, isolation entre utilisateurs, altération directe du stockage, délégation |
| Affirmation accessible après exécution | Préparation correcte pour les cas fournis | Comportement correct dans la simulation déclarée | Comportement correct sur la séquence de sessions testée |
| Statut d'exécution | Non exécuté | Non exécuté | Non exécuté |
Attribuer un statut à chaque cas, y compris aux cas non exécutés
La fiche définit trois cas : un paiement autorisé ordinaire, un ordre sans approbation, et une seconde session qui réutilise un enregistrement fournisseur stocké lors de la première. Ils montrent la couverture visée. Ils n'estiment pas la fréquence des échecs en pratique, et leur sélection ne dit rien de la réussite d'une implémentation. Le cas de la seconde session ne teste ni la corruption, ni la révocation, ni la suppression de l'enregistrement stocké, et le cas sans approbation ne donne aucune estimation de la robustesse face à un adversaire.
Chaque résultat porte l'une de cinq étiquettes. Le projet de profils d'évaluation demande que les métriques sans objet soient signalées ; le reste de ce vocabulaire est notre propre proposition, et aucun groupe ne l'a adopté. Dans cet exemple, tous les résultats qui dépendent d'une exécution sont « Non exécuté », et la fiche ne définit aucun score agrégé.
- Publiez, cas par cas, la disponibilité des preuves et le dénominateur de tout taux.
- Excluez du décompte des réussites les observations manquantes et les contrôles sans objet.
| Étiquette | Usage |
|---|---|
| Réussite ou échec | Un critère défini, évalué avec suffisamment d'observations enregistrées |
| Sans objet | La capacité est absente de la configuration déclarée |
| Non exercé | La capacité existe, et le cas choisi ne l'a jamais sollicitée |
| Non observé | L'observation nécessaire à un verdict n'est pas disponible |
| Non exécuté | L'exécution n'a pas eu lieu |
Ce que nous avons vérifié dans les données publiées
Les auteurs de l'article sur la fiabilité publient leurs données de résultats. Nous avons téléchargé le fichier de résultats HAL depuis leur dépôt au commit e7ec464 (29 septembre 2026) et l'avons dénombré avec la bibliothèque standard de Python : 29 923 lignes, 9 benchmarks, 54 valeurs de nom de modèle, 13 noms de scaffold et 1 117 couples distincts benchmark-tâche, chaque score valant 0 ou 1. Ces dimensions correspondent à la description des données fournie par le dépôt. Les noms de modèles incluent des variantes d'effort de raisonnement : 54 est donc un nombre d'identifiants, supérieur au nombre de modèles de base. Dépôt figé, fichier figé.
Il s'agissait d'un comptage de données. Nous n'avons relancé aucun agent, examiné aucune trajectoire ni réajusté le modèle statistique, et ce comptage ne peut pas montrer que les étiquettes et les notes du fichier sont correctes. Il confirme la forme et l'identité des données d'entrée sur lesquelles reposent les chiffres de fiabilité publiés. Ces chiffres restent les résultats des auteurs.
Publier la fiche de périmètre avec le résultat
Rattachez la fiche de périmètre au résultat sous le même identifiant de version, et remplissez les champs d'exécution lorsque l'évaluation est lancée :
Lorsqu'un composant change, indiquez le changement à côté du nouveau résultat, afin que les lecteurs puissent juger de la portée d'une comparaison. Un lecteur peut alors rattacher une conclusion à une configuration, une action et une observation précises, et une équipe de contrôle peut décider des preuves supplémentaires dont son propre processus a besoin.
- Identifiant d'exécution et versions exactes : version du modèle, harness, hôte des outils, évaluateur et hash du jeu de données.
- Paramètres d'échantillonnage ou graine, budget de ressources et consommation réelle de l'exécution.
- Preuves de réinitialisation, permissions des acteurs et identité de toute personne ayant pris une décision.
- Accès de l'observateur, échecs d'initialisation et exclusions, avec leur prise en compte dans le dénominateur.
- Trace des actions et différences d'état, en tenant les messages de réussite des outils à part des effets observés de façon indépendante.
- La règle de verdict appliquée à chaque cas.
Foire aux questions
Que mesure le score d'un agent d'IA à un benchmark ?
Un score mesure une configuration sur un ensemble de tâches avec un correcteur donné : le modèle et ses paramètres, le scaffold, les outils et permissions, l'état de départ et ce que le correcteur pouvait observer. Sa portée pour le modèle seul, ou pour un service réel, dépend de la manière dont ces éléments ont été maintenus fixes ou modifiés.
Faut-il évaluer le modèle d'IA ou le système d'agent complet ?
Partez de l'affirmation dont vous avez besoin. Un acheteur qui choisit une application d'agent complète devrait évaluer le modèle avec son scaffold. Une équipe qui choisit un modèle de remplacement devrait maintenir le scaffold fixe ou le faire varier délibérément. Une prépublication de septembre 2026 de Hardy et de ses coauteurs indique que, dans les benchmarks étudiés, les systèmes complets étaient classés de façon plus fiable que les modèles sous-jacents.
Que doit contenir le rapport d'évaluation d'un agent d'IA ?
L'affirmation visée, les versions exactes du modèle, du scaffold, des outils et de l'évaluateur, les permissions, la procédure de réinitialisation, le budget de ressources, l'accès de l'observateur, les exclusions et les échecs d'initialisation avec leur effet sur le dénominateur, et un statut pour chaque cas : réussite, échec, sans objet, non exercé, non observé ou non exécuté.
Existe-t-il une norme pour rendre compte des évaluations de sécurité des agents d'IA ?
La proposition de format de rapport examinée dans cet article n'a aucune valeur normative. Evaluation Profiles for AI Agent Security Assessment (23 octobre 2026) propose de déclarer des profils d'infrastructure et de scénario et de signaler les métriques sans objet. Il s'agit de la révision 00 d'un Internet-Draft individuel, sans soutien de l'IETF. Son document méthodologique associé n'a pas pu être récupéré le 26 octobre 2026.
Points clés à retenir
Un score de benchmark étaye la conclusion que sa configuration et ses observations peuvent porter. Formulez l'affirmation visée, déclarez le périmètre, tenez les réponses des outils à part des effets enregistrés, et attribuez un statut à chaque cas. Commencez par la fiche de périmètre d'évaluation, et lisez le programme d'audit des agents d'IA pour voir comment les équipes de contrôle délimitent et échantillonnent les preuves qui sous-tendent les actions des agents.
Les sources ont été vérifiées le 26 octobre 2026. Les deux articles sont des prépublications, et leurs résultats restent ceux des auteurs. Le document sur les profils d'évaluation est un Internet-Draft individuel sans valeur normative. La fiche commentée est synthétique et n'a pas été exécutée ; aucune expérience sur un agent n'a été menée pour cet article. Notre vérification des données a dénombré un fichier publié et n'a reproduit aucun résultat statistique. Cet article ne contient aucun résultat KLA.