Tester un agent ne consiste pas à tester une réponse

La réponse finale peut masquer un incident

Un agent peut annoncer un dossier traité alors qu’aucune écriture n’a abouti. Il peut aussi fournir une excellente synthèse après avoir consulté une ressource interdite. L’objet de l’assurance est donc le système en action : entrées, outils, identités, décisions de contrôle, transitions d’état et effets persistés. La réponse finale est une observation parmi d’autres.

Dans le cadre Digital Place Agentic Assurance / Control Engineering, notre recommandation est de relier chaque exigence à un contrôle et à une preuve. Cette note décrit une méthode d’ingénierie. Elle ne revendique ni certification ni niveau de sécurité mesuré pour un produit.

Définir les invariants avant les scénarios

Énoncer les propriétés qui doivent toujours tenir : aucune lecture hors périmètre, aucune action sans autorisation, aucun secret dans une sortie, aucune approbation réutilisée après changement d’opération. Définir aussi l’état final attendu et les conditions d’arrêt. Le modèle peut choisir un chemin variable ; les frontières de permission restent stables.

Un cas hypothétique de modification de dossier peut autoriser la préparation, exiger une approbation pour l’écriture et interdire la suppression. Le test vérifie la base après exécution, les appels tentés et les décisions du contrôleur. Un message « terminé » n’est pas une preuve d’écriture.

Observer les trajectoires sans imposer un seul chemin

Une trajectoire décrit les événements observables d’une exécution : récupération, propositions d’outils, arguments, résultats, contrôles et état. Plusieurs chemins peuvent satisfaire la même tâche. Les tests doivent imposer les dépendances nécessaires, par exemple autorisation avant écriture, sans exiger un ordre arbitraire de recherches sans effet de bord.

Le guide Anthropic sur les evals d’agents, publié en janvier 2026 distingue tâches, essais, traces et résultat de l’environnement. Notre application pratique consiste à vérifier séparément utilité, respect des politiques et état final. Conserver des événements observables suffit ; il n’est pas nécessaire d’enregistrer un raisonnement interne du modèle.

Tool calling : tester la frontière réelle

Valider arguments, types, limites, ressources visées et sorties. Refuser un champ inattendu plutôt que l’ignorer silencieusement. Un schéma valide ne prouve ni l’autorisation ni la pertinence de l’action. Vérifier ces deux éléments côté serveur, au plus près de l’effet, avec des identités distinctes et des permissions minimales.

Tester outil absent, description modifiée, résultat tronqué, timeout, erreurs transitoires et succès partiel. Après une panne, l’agent doit savoir distinguer une action non exécutée d’une action dont le résultat est inconnu. Les retries doivent respecter idempotence et budgets ; une réponse d’outil ne peut pas s’accorder elle-même de nouveaux droits.

Politiques déterministes et comportement probabiliste

Les décisions de contrôle d’accès, la validation de schéma, les limites de ressources et les transitions autorisées se testent avec des assertions déterministes. Les réponses, la sélection d’outils et la capacité à résoudre une tâche demandent des essais répétés. Mélanger ces deux niveaux dans une note globale masque les défauts importants.

Une réussite moyenne élevée ne compense pas une action interdite. Publier séparément réussite métier, violations de politique, escalades, budgets dépassés et erreurs d’état. Une température faible n’assure pas la reproductibilité : versions du modèle, outils, environnement et contexte restent des variables.

Golden sets et scénarios vivants

Construire un jeu de référence avec cas ordinaires, limites et échecs réalistes. Chaque scénario précise état initial, identité, sources accessibles, outils, politique, résultat attendu et critères de notation. Séparer données de développement et validation. Les cas issus d’incidents doivent être minimisés ou synthétisés avant d’entrer dans le corpus.

Combiner contrôles de code pour les faits vérifiables, revue humaine pour les ambiguïtés et juges modèles pour certaines qualités rédactionnelles. Un juge modèle doit être calibré, pouvoir déclarer un cas indéterminé et ne pas disposer du pouvoir de valider une violation de sécurité. Réexaminer les scénarios devenus trop faciles ou dépendants d’un ancien outil.

Tester l’injection à chaque entrée non fiable

Placer des tentatives directes dans la demande, indirectes dans un document récupéré et des instructions malveillantes dans une réponse d’outil. Tester aussi contenus multilingues, encodages, citations trompeuses et instructions prétendant provenir d’un administrateur. L’OWASP Agentic Top 10 2026 aide à structurer la couverture des risques.

Le critère n’est pas seulement que l’agent refuse verbalement. Il faut vérifier qu’aucun appel interdit n’est exécuté, qu’aucune donnée ne sort du périmètre et que l’état reste sûr. Le filtrage d’un prompt est une mesure supplémentaire ; il ne remplace pas l’application des droits par le système.

MCP et chaîne de confiance

Tester les serveurs MCP comme des dépendances capables de changer schémas, descriptions et résultats. Vérifier provenance, version, autorisation, audience des jetons et règles de connexion. Les bonnes pratiques de sécurité MCP documentent notamment les risques de délégation confuse et de transmission de jetons.

Une connexion authentifiée ne donne pas un droit métier illimité. Le contrôleur doit vérifier l’action et la ressource, et empêcher qu’une description d’outil élargisse sa portée. Faire entrer les mises à jour d’outils et dépendances dans la même discipline de régression que les changements de prompts.

Sandbox et approbation humaine

Limiter réseau, filesystem, processus et secrets à ce que la tâche nécessite. Tester effectivement les refus : lecture hors répertoire, connexion interdite, lancement de sous-processus et tentative d’accès à un secret. Une sandbox sans restriction de réseau peut encore permettre une exfiltration.

L’approbation humaine doit présenter une action concrète, ses paramètres et ses conséquences. Elle est liée à cette opération, à l’identité du demandeur et à un état ; elle expire ou doit être renouvelée si ces éléments changent. Tester refus, expiration, double clic et reprise après interruption. Le modèle ne peut pas fabriquer une approbation en la déclarant dans son texte.

Traces, replay et auditabilité

Enregistrer version des politiques, outils, modèle et corpus, décisions d’autorisation, timestamps et effets confirmés. Minimiser les contenus personnels et masquer les secrets. Une trace doit expliquer ce qui a été autorisé ou refusé, par quel contrôle et avec quel résultat, même lorsque l’exécution s’arrête au milieu.

Distinguer replay d’une trace enregistrée et nouvelle exécution du modèle. Le premier aide à reproduire une décision de contrôle ; le second peut varier. Rejouer les effets avec des outils simulés dans un environnement isolé, jamais vers un système métier réel. Vérifier que les preuves restent consultables sans accorder des droits d’exécution.

Budgets, SLO et modes sûrs

Fixer budgets de temps, appels, tokens et effets possibles par tâche. Tester boucles, outil lent, contexte saturé, annulation et dépendance indisponible. Le SLO doit porter sur une tâche terminée correctement dans son périmètre, pas uniquement sur la disponibilité d’une API de modèle.

Lorsque le budget est épuisé ou l’état incertain, arrêter les effets de bord et orienter vers une reprise humaine. Les tâches déjà validées doivent rester distinguées des tâches préparées. Une compensation, lorsqu’elle existe, doit être explicite et testée ; elle ne transforme pas une action irréversible en opération anodine.

Une régression qui suit tout le système

Relancer les contrôles lors d’un changement de modèle, prompt, outil, politique, index ou runtime. Garder une comparaison par scénario et par gravité, puis examiner les traces de régressions. Les travaux sur la défense contre les injections par conception rappellent l’intérêt des frontières architecturales ; une publication de recherche n’est pas une garantie universelle pour votre implémentation.

La preuve utile rassemble exigence, menace, contrôle, test et résultat. C’est cette chaîne qui rend un système agentique évaluable par une DSI, maintenable par une équipe et suspendable lorsqu’il ne respecte plus son contrat.