Évaluer les agents IA : de la bonne impression au résultat utile

La transmission comme point de contrôle

Un agent reçoit un dossier pour préparer une décision. Une synthèse bien rédigée arrive rapidement. Tout semble terminé. Mais tous les documents pertinents ont-ils été pris en compte ? Les chiffres correspondent-ils aux sources ? Les informations manquantes restent-elles visibles ? L’agent s’est-il limité à ce qu’il devait préparer ?

Cet exemple est construit, et ne rapporte pas un essai mesuré de produit. Il illustre une distinction importante pour moi : qualité de la formulation et qualité du travail réalisé sont deux questions différentes.

Pour un test utile, je pars de la transmission. Je décris d’abord ce qu’une autre personne doit pouvoir utiliser à la fin. Cela détermine les critères d’évaluation de l’agent. « La réponse était-elle bonne ? » est une question trop large.

Un petit cahier de test

Pour cet exemple documentaire, la consigne pourrait être :

Domaine	À définir avant l’essai
Tâche	Comparer trois offres selon des exigences explicitement définies.
Résultat	Un tableau comparatif avec références aux sources et questions ouvertes.
Limites	Ne pas compléter les prix manquants, contacter les fournisseurs ni modifier les fichiers hors du dossier de travail.
Cas d’échec	Signaler les informations contradictoires et laisser la décision ouverte.
Vérification	Une personne peut relier toute affirmation déterminante à sa source.

Ce tableau n’est pas une norme universelle, mais une aide adaptable à une tâche concrète. Sa préparation peut révéler des attentes floues : le système doit-il comparer ou aussi recommander ? Peut-il pondérer les sources ? Quelle information empêcherait une recommandation ?

Examiner séparément le résultat et le parcours

On peut d’abord vérifier le résultat : le tableau existe-t-il, les informations obligatoires sont-elles présentes et les fichiers référencés existent-ils ? De simples contrôles techniques répondent à une partie de ces questions.

Vient ensuite l’examen du fond : la comparaison est-elle pertinente, une limite a-t-elle été oubliée, une question ouverte est-elle restée ouverte ? Il faut une personne connaissant le contexte ou une grille d’évaluation soigneusement définie.

Le parcours compte aussi. Un résultat correct peut provenir d’un accès non autorisé ; un processus bien documenté peut aboutir à un résultat faux. Le respect des autorisations doit donc être vérifié avec le résultat. Le guide d’Anthropic sur l’évaluation des agents distingue également le parcours enregistré de l’état final réel, ainsi que les évaluations techniques, par modèle et humaines.

Inclure les cas difficiles dès le départ

Pour un premier ensemble de tests, je ne choisirais pas uniquement des documents complets et lisibles. Une annexe manquante, deux versions contradictoires et une source inaccessible peuvent en révéler plus sur la gestion de l’incertitude qu’un nouvel essai sans difficulté.

Il faut aussi un cas où le système devrait refuser ou demander une précision. Si chaque test attend une solution complète, l’arrêt justifié devient invisible. Or cet arrêt peut être décisif en usage réel.

Les essais peuvent donner des résultats différents. Les répétitions aident à repérer une réussite due au hasard. Il faut documenter tâche, entrées, version, accès aux outils et évaluation. Un pourcentage sans ces informations dit peu sur ce qui a été testé.

Commencer petit, décider concrètement

On aboutit à une décision délimitée : pour quelles tâches le processus convient-il, où faut-il davantage de contrôle, quelles autorisations restent fermées et que faut-il changer avant un autre contexte d’utilisation ?

C’est ce lien entre espace de travail, processus et transmission qui m’intéresse dans le développement d’agents. Alpine-X est l’une de mes approches de projet. Un nom ne remplace toutefois pas une preuve. L’étape solide suivante est un essai compréhensible dont le résultat peut être vérifié par quelqu’un d’autre.