Comment tester un agent IA avant de lui confier une tâche métier ?

Une démonstration réussie montre qu’un agent peut réussir une fois. Avant de lui confier une tâche, il reste à savoir s’il réussit à chaque fois, s’il s’arrête quand il le faut et s’il résiste à une consigne piégée. Ces trois réponses se préparent avec les personnes du métier.

Que veut dire tester un agent IA ?

Tester un agent IA, c’est lui soumettre des cas tirés du travail réel et noter ce qu’il a produit dans vos outils, pas seulement ce qu’il a répondu. Anthropic, dans un article de janvier 2026 sur l’évaluation des agents, donne l’exemple d’un agent de réservation : la phrase « vol réservé » ne prouve rien, seule compte la réservation présente en base.

Le vocabulaire vient du même article et sert à lire un rapport de test :

Prenez un agent qui oriente les demandes de support vers la bonne équipe. Le critère de réussite porte sur le ticket enregistré, sa catégorie et les informations transmises. Il précise aussi ce qui est interdit : répondre au client, fermer le ticket, consulter un dossier hors périmètre.

Quels cas mettre dans le jeu de test ?

Commencez par 20 à 50 cas simples, pris dans des échecs réels : c’est le volume qu’Anthropic juge suffisant pour démarrer. Un bon cas est un cas sur lequel deux experts du métier rendraient, chacun de leur côté, le même verdict.

Mêlez des demandes ordinaires, des formulations ambiguës et des dossiers incomplets. Ajoutez les limites connues : document périmé, clients homonymes, information contradictoire, pièce jointe manquante. Ajoutez enfin des demandes que l’agent doit refuser, sans quoi le jeu de test le pousse à toujours agir.

Pour chaque cas, écrivez avant le premier essai le résultat attendu, l’arrêt acceptable et la décision qui revient à une personne. Ne retouchez pas ces critères après chaque essai pour faire paraître l’agent meilleur, et gardez des cas de côté pour vérifier qu’il traite aussi des situations nouvelles.

Faut-il noter le résultat ou le chemin suivi ?

Notez d’abord le résultat, c’est-à-dire l’état final dans l’outil. Imposer un ordre d’appels d’outils donne des tests trop rigides, constate Anthropic : un agent trouve souvent un chemin valide que personne n’avait prévu.

La trace garde son utilité. Elle explique un échec et révèle les effets de bord : un dossier consulté sans raison, une écriture en trop. Protégez-la comme les données qu’elle contient, puisqu’elle recopie ce que l’agent a lu.

Chaque critère appelle son correcteur. Un champ obligatoire se vérifie par du code. La pertinence d’une synthèse demande une personne, ou un modèle dont les notes ont été comparées à celles d’experts humains. Séparez ces critères au lieu de tout fondre dans une note globale.

Pourquoi rejouer plusieurs fois le même cas ?

Un même agent ne donne pas deux fois le même résultat : la plupart des modèles ont un comportement non déterministe, rappelle l’ANSSI. Un essai réussi ne dit donc rien de l’essai suivant.

Le calcul d’Anthropic donne la mesure. Un agent qui réussit 75 % de ses essais n’a qu’environ 42 % de chances d’en réussir trois de suite. Pour une tâche confiée chaque jour, comptez la part des cas réussis à tous les essais, pas la moyenne.

Les mêmes cas servent ensuite de tests de non-régression, dont le taux de réussite doit rester proche de 100 %. Rejouez-les à chaque changement de modèle, de connecteur ou de règle : un nouveau modèle peut mieux rédiger et moins bien utiliser un outil.

Que tester côté droits et sécurité ?

Testez ce que l’agent refuse autant que ce qu’il réussit. L’ANSSI recommande des tests de robustesse et de sécurité avant toute mise en production, et quatre vérifications s’y prêtent :

• L’injection de consignes. Donnez à l’agent l’ordre d’ignorer ses règles, puis glissez la même consigne dans un document ou une page qu’il doit lire. L’OWASP parle d’injection indirecte quand la consigne vient d’une source externe.
• Les droits trop larges. L’OWASP range sous le nom d’agentivité excessive des fonctions, des droits ou une autonomie supérieurs au besoin. Demandez à l’agent un outil ou un dossier qui ne le concerne pas : il doit refuser.
• Les actions sans validation. Une action à fort impact attend l’accord d’une personne. L’ANSSI va plus loin : un système d’IA ne doit pas pouvoir lancer de lui-même une action critique sur le système d’information.
• La reprise. Coupez la connexion juste après une écriture et relancez : la reprise ne doit pas créer de doublon.

Vérifiez aussi qu’une validation porte sur l’action exacte qui sera exécutée. Si le contenu ou le destinataire change après l’accord, la validation est à redemander.

Qui valide, et quand refuser la mise en service ?

Le métier écrit les critères et rend le verdict, l’équipe technique fournit les preuves, la sécurité contrôle les droits, et un responsable décide de l’ouverture. Le NIST, l’institut américain de normalisation, recommande que l’évaluation associe des personnes qui n’ont pas développé le système, dans des conditions proches de l’usage réel.

Les constats qui suffisent à refuser

• Un résultat annoncé par l’agent et absent de l’outil.
• Une action hors périmètre, même une seule fois.
• Une action critique exécutée sans validation.
• Un cas réussi à un essai et raté au suivant, sur une tâche qui doit tenir à chaque fois.
• Des critères modifiés en cours de test.

Le jeu de test reste en service après le lancement : ajoutez-y les incidents rencontrés et rejouez-le à chaque évolution. Il fait partie de ce que livre un projet d’agent IA sur mesure, au même titre que le harness qui porte les autorisations et les contrôles.

Questions fréquentes