Sept tests pour fiabiliser les agents IA avant production

Sept tests de régression ciblés permettent d'évaluer la robustesse d'un agent IA face aux défaillances de la couche d'orchestration, bien plus fréquentes que celles du modèle. Leur efficacité repose sur des modèles figés, des paramètres contrôlés et des essais répétés. Ces tests ne couvrent pas les aspects de coût ou de latence, mais visent à sécuriser le passage en production.

Ce que la batterie ne couvre pas et les conditions pour qu’elle dure

Les sept tests ciblent des défaillances structurelles situées à la frontière du système, pas les régressions de coûts ou de latence. Ils ne traitent pas non plus la dérive des contrats d’outils quand un schéma d’API change, les fuites de données personnelles dans les arguments ou les traces d’outils, ni les écarts d’espace d’intégration liés au déploiement d’un nouvel encodeur sans réindexation du magasin de vecteurs. Construire la suite n’est que le départ ; son utilité dans la durée dépend d’exécutions cohérentes sur des versions de modèle fixées, avec des seuils de confiance bornés.

Assurer la continuité d’état: réhydrater et maîtriser l’idempotence

Dans un environnement distribué, il est rare que le processus initiant une session d’agent soit également celui qui la clôture. C’est pourquoi un test de réhydratation s’impose : il consiste à faire progresser l’agent à une étape intermédiaire d’un workflow, à enregistrer l’état en base de données, à supprimer l’objet de la mémoire, puis à restaurer cet état dans un processus différent. Il réussit si l’agent termine correctement après la prochaine entrée utilisateur. Deux causes d’échec reviennent: l’écart de version, qui exige un chemin de migration testé explicitement, et le couplage à l’idempotence, indispensable pour savoir si un effet de bord a déjà été engagé. Une clé d’idempotence fournit cette information, ce qui justifie de faire cohabiter et d’outiller ensemble ces deux tests. Un agent doté d’accès en écriture finira, en conditions réseau réalistes, par répéter un même appel d’outil. Les réessais viennent du harnais, du client HTTP ou de la boucle d’orchestration, et le modèle peut aussi réémettre face à une observation ambiguë. Sans idempotence à la frontière d’exécution, ces trajectoires produisent des doublons. Le test force trois fois le même appel ; il ne passe que si une seule écriture est consignée, les suivantes recevant une réponse de cache. Les clés d’idempotence doivent reposer sur l’identité logique de l’opération (nom d’outil haché, arguments canonisés, ID de corrélation métier), pas sur un ID d’étape ou une position de message. En concurrence, mieux vaut retourner la réponse stockée qu’un 409, et poser un TTL sur les clés.

L’état, pas le modèle: où naissent l’essentiel des pannes

Les incidents observés en production sous trafic réel relèvent majoritairement de la gestion d’état plutôt que du modèle. Ici, l’« état » renvoie à l’enregistrement déterministe et transactionnel des étapes d’exécution, quand la « mémoire » désigne le contexte probabiliste réinjecté dans le prompt. La check-list proposée couvre sept volets — dont un verdict binaire, exploitable en CI/CD, cible une limite système par test — pour des défaillances que l’évaluation de prompts ignore. Comme le comportement des agents est stochastique, l’exécution des tests impose de figer l’instantané de modèle, de régler la température à zéro quand c’est possible, et de multiplier les essais jusqu’à établir un taux de réussite assorti d’une marge de confiance. Des échecs aléatoires se voient réessayés en silence et vident le test de sa valeur.

Entrées hostiles et contexte externe: résister sans divulguer

Le test d’injection de prompt insère des charges adversariales, à la fois via les messages utilisateurs et via des documents issus du web ou d’une base externe. Il n’est validé que si l’agent atteint un état terminal sûr sans exécuter l’instruction injectée ni exposer le prompt système. Les assertions doivent cibler la trace des appels d’outils et les effets de bord : une sortie polie peut masquer un appel nuisible. La sécurité est une question de frontière d’exécution, avec un contrôle d’accès par rôles au niveau des outils. Quand un classificateur sert de garde, la décision repose sur un niveau de confiance à rendre explicite. Côté RAG, un fait synthétique contradictoire est injecté dans la chaîne de récupération avant interrogations. Vérifier que l’agent suit le contexte plutôt que la mémoire paramétrique est nécessaire mais insuffisant. Un agent trop dépendant du contexte devient vulnérable au poisoning ; la suite doit vérifier les deux directions : adopter un fait synthétique correct contre une connaissance paramétrique obsolète, et rejeter un fait récupéré manifestement faux quand la contradiction est détectable. Des benchmarks de fidélité et d’attribution offrent un cadre plus robuste qu’un simple succès/échec.

Sorties structurées: gérer troncature, refus et écarts de version

Avec le décodage contraint par schéma en mode strict, les invalidités syntaxiques et les clés hors schéma ne devraient plus apparaître. Les défaillances à cibler sont ailleurs. La troncature — atteindre le budget de jetons en pleine émission — produit des réponses incomplètes que l’application ne peut réparer. Il faut donc asserter le finish_reason en plus du succès de l’analyse. Un refus se manifeste par une analyse nulle avec champ de refus et doit être traité comme un 403, non comme une erreur transitoire. Plus subtile, la conformité sémantique renvoie des types corrects mais des valeurs erronées. Enfin, l’écart de version mérite un test dédié : un alias qui route vers un instantané ancien peut réintroduire un mode JSON hérité. Pour l’éviter, mieux vaut fixer explicitement les chaînes de modèles que s’en remettre aux alias.

Contexte long et boucles: récupérer l’essentiel et savoir s’arrêter

Quand la conversation s’approche du budget de prompt, évincer les premiers tours — typiquement via FIFO — expose à une perte de contexte, et non à de l’oubli catastrophique. Un test dédié injecte un historique synthétique couvrant environ 80 % du budget, puis pose une question dont la bonne réponse dépend d’un fait du premier échange. La réussite peut venir d’une récupération réussie depuis la mémoire sémantique ou d’une politique de résumé qui a conservé les relations d’entités avec une fidélité mesurable (rappel d’entités de référence). Ces deux cas doivent faire l’objet de validations distinctes. Autre famille de défaillances, la non-termination : ce qui passe souvent pour un blocage est un livelock où l’agent enchaîne pensée–action–observation sans progresser. Le vrai blocage concerne les systèmes multi-agents et appelle un test séparé si l’architecture en comporte. Pour la non-termination, le test soumet une tâche impossible ou renvoie une erreur persistante via un outil simulé, et il n’est validé que si l’exécution s’arrête proprement après un budget codé et renvoie une charge d’échec structurée. Ce budget doit agréger un nombre maximal d’étapes, un coût cumulatif en jetons et un délai réel, un simple compteur d’étapes n’identifiant pas une étape figée. Le coût réel d’une dérive est la dépense d’inférence et la famine de file d’attente, plus que l’épuisement d’une limite de taux.