● Journal du Net 📅 15/04/2026 à 11:24

Cybersécurité 👤 Madhvesh Kumar

🏷️ Tags : injection de prompt llm cert rag rte

Les agents autonomes sont faciles à présenter en démo. Voici ce que les équipes d'ingénierie découvrent vraiment lorsqu'elles tentent de rendre leurs agents suffisamment fiables pour la production. La démo fonctionne toujours. Un agent autonome se connecte à un ensemble d’outils, raisonne sur une tâche en plusieurs étapes et livre un résultat impeccable. L’auditoire acquiesce. La direction valide le projet. L’équipe technique reçoit un calendrier. Et c’est là que le vrai travail commence, celui dont personne ne vous avait parlé. Tester des agents autonomes est fondamentalement différent de tester un logiciel classique. Le chemin d’exécution change à chaque appel. Les modes de défaillance sont subtils, différés et souvent invisibles sans une instrumentation rigoureuse. Et le manuel de test habituel (tests unitaires, tests d’intégration, suites de régression de bout en bout) ne couvre qu’une fraction de ce dont vous avez réellement besoin. Au cours des deux dernières années, en travaillant sur des systèmes agentiques en production dans des environnements d’entreprise, de l’orchestration de pipelines de données aux workflows de génération augmentée par récupération (RAG), j’ai accumulé un ensemble de leçons durement apprises sur ce qu’il faut réellement pour tester des agents autonomes. Ce ne sont pas des principes théoriques. Ce sont des schémas découverts par l’échec, débogués par la persévérance et validés par le trafic de la mise en production. Leçon 1 : le déterminisme est un spectre, pas un binaire Le premier réflexe de toute équipe d’ingénierie est d’essayer de rendre le comportement de l’agent déterministe. Régler la température à zéro. Fixer le générateur de nombres aléatoires. Mettre en cache les réponses du modèle. Verrouiller la version du modèle. Ce réflexe va dans la bonne direction, mais il est trompeur en pratique. Même avec une température à zéro, les grands modèles de langage ne garantissent pas des sorties identiques d’un appel à l’autre. Le non-déterminisme au niveau de l’infrastructure (stratégies de batching, ordre d’accumulation des calculs en virgule flottante sur les cœurs GPU, arrondis de quantification) introduit une variation qu’aucune configuration applicative ne peut totalement éliminer. La leçon pratique : arrêtez de chercher un déterminisme parfait et commencez à concevoir des tests qui évaluent le comportement dans des marges acceptables. Plutôt que de vérifier que l’agent produit exactement la chaîne « Requêter la table inventaire et filtrer par statut = actif », vérifiez que la séquence d’actions de l’agent inclut une requête ciblant la bonne table avec une condition de filtre sémantiquement équivalente. Concrètement, cela signifie construire des fonctions d’évaluation qui opèrent sur la structure et l’intention des actions de l’agent, pas sur leur texte littéral. En pratique, nous avons constaté qu’une combinaison d’analyse de sorties structurées (extraction des appels d’outils, des paramètres et du séquençage) et de vérifications légères de similarité sémantique (pour les étapes de raisonnement en langage naturel) offrait la couverture de test la plus fiable, sans fragilité excessive. Leçon 2 : les bugs les plus difficiles se cachent entre les étapes Les bugs logiciels traditionnels sont locaux. Une fonction reçoit une entrée erronée, calcule mal et renvoie un résultat faux. Les bugs d’agents sont différents. Chaque étape prise individuellement peut être parfaitement raisonnable, mais la composition des étapes produit une défaillance. Prenons un agent chargé d’enquêter sur une anomalie de qualité de données dans un pipeline lakehouse. Première étape : il interroge le catalogue de métadonnées et identifie correctement la table concernée. Deuxième étape : il récupère le profil de données le plus récent et note correctement un pic de valeurs nulles. Troisième étape : il vérifie les logs d’exécution du pipeline amont et constate correctement que la dernière exécution a réussi. Quatrième étape, celle de la défaillance : il conclut que le problème de qualité des données n’est pas lié au pipeline, puisque l’exécution a réussi. Ce qu’il a manqué, c’est que le pipeline avait réussi mais traité zéro enregistrement en raison d’une partition source vide, un scénario où « succès » et « exactitude » sont totalement décorrélés. Aucune étape individuelle n’était fausse. La faille de raisonnement vivait entre les étapes trois et quatre : un échec à poser la bonne question de suivi compte tenu du contexte accumulé. Tester ces défaillances inter-étapes nécessite une approche différente du test unitaire sur chaque appel d’outil. La stratégie la plus efficace que nous ayons trouvée est l’évaluation au niveau de la trajectoire : capturer la séquence complète des actions, décisions et observations de l’agent, et les évaluer de façon globale en les comparant à des trajectoires de référence annotées. La question n’est pas « l’agent a-t-il appelé le bon outil ? » mais « la trajectoire de l’agent a-t-elle convergé vers le bon diagnostic ? » Leçon 3 : votre suite d’évaluation ne vaut que ce que vaut votre taxonomie des échecs Au début de nos efforts de test, nous avons commis l’erreur de traiter toutes les défaillances d’agents comme une catégorie unique. Un agent qui appelait le mauvais outil, un agent qui appelait le bon outil avec les mauvais paramètres, un agent pris dans une boucle infinie et un agent qui produisait une réponse finale plausible mais factuellement incorrecte étaient tous enregistrés comme « test échoué ». Cela rendait impossible toute hiérarchisation des corrections ou mesure de la progression. Nous avons finalement développé une taxonomie structurée des défaillances, en six catégories. Défaillances de planification : l’agent a choisi une stratégie ou une décomposition incorrecte pour la tâche. Défaillances de sélection d’outil : l’agent a sélectionné le mauvais outil pour une sous-tâche donnée. Défaillances d’extraction de paramètres : l’agent a sélectionné le bon outil mais extrait ou construit des paramètres incorrects. Défaillances de gestion du contexte : l’agent a perdu la trace d’informations pertinentes collectées lors d’étapes antérieures, entraînant des actions redondantes ou des conclusions contradictoires. Défaillances de terminaison : l’agent s’est arrêté trop tôt (complétion prématurée) ou trop tard (boucles, appels d’outils excessifs). Défaillances de synthèse : l’agent a collecté les bonnes informations mais produit une sortie finale incorrecte ou trompeuse. Une fois les défaillances catégorisées de cette manière, des schémas ont émergé immédiatement. Nous avons par exemple découvert que plus de 40 % de nos défaillances en production relevaient de la gestion du contexte : l’agent avait déjà récupéré l’information nécessaire mais échouait à l’exploiter efficacement dans les étapes de raisonnement suivantes. Cela pointait vers un problème d’architecture de prompt, pas d’intégration d’outils, et nous ne l’aurions jamais identifié sans cette taxonomie. Leçon 4 : le test adversarial n’est pas optionnel Les agents déployés en environnement d’entreprise rencontreront des entrées qu’aucun développeur n’avait anticipées. Les utilisateurs poseront des questions ambigüés. Les systèmes amont renverront des données malformées. Les API expireront en pleine exécution. Et dans les contextes sensibles en matière de sécurité, des acteurs malveillants fabriqueront délibérément des entrées conçues pour manipuler le comportement de l’agent. Nous avons appris à construire des suites de tests adversariaux couvrant quatre dimensions. Premièrement, l’ambiguïté : des tâches avec des instructions incomplètes ou contradictoires, où le comportement correct de l’agent est de demander des clarifications plutôt que de deviner. Deuxièmement, la robustesse : des entrées contenant des données bruitées, partielles ou malformées provenant des outils amont, où l’agent doit dégrader gracieusement plutôt qu’halluciner sur des données corrompues. Troisièmement, les cas limites : des tâches situées exactement à la frontière des capacités définies de l’agent, où le comportement correct est de reconnaître et de communiquer ses limites. Quatrièmement, l’injection de prompt : des entrées conçues pour contourner les instructions système de l’agent, exfiltrer du contexte sensible ou rediriger l’agent vers des actions non autorisées. La dimension de l’injection de prompt mérite une attention particulière. Dans les systèmes agentiques où le LLM traite du contenu non fiable (messages utilisateurs, documents récupérés, sorties d’outils), la surface d’attaque pour l’injection indirecte de prompt est considérable. Nous avons établi comme pratique standard d’inclure des tentatives d’injection dans les données de mock des sorties d’outils pendant les tests. Si un agent peut être redirigé par une chaîne de caractères fabriquée et intégrée dans un enregistrement de base de données ou une réponse d’API, cette vulnérabilité doit être détectée avant le déploiement, pas après. Leçon 5 : l’observabilité est votre test le plus important L’investissement de test le plus précieux que nous ayons réalisé ne consistait pas à écrire davantage de cas de test. Il consistait à intégrer une observabilité complète dans le runtime de l’agent. Chaque appel d’outil, chaque invocation du LLM, chaque trace de raisonnement, chaque compteur de tokens, chaque mesure de latence, le tout capturé dans un format de trace structuré, requêtable, visualisable et comparable d’une exécution à l’autre. Cette couche d’observabilité a transformé la production elle-même en environnement de test continu. Lorsqu’un agent traitait une requête utilisateur réelle, la trajectoire complète était journalisée et disponible pour une évaluation rétrospective. Nous avons construit des moniteurs automatisés signalant les schémas anormaux : des exécutions d’agents dépassant le nombre d’étapes typique, des séquences d’appels d’outils jamais observées en test, des sorties finales obtenant de mauvais scores aux vérifications de cohérence avec les preuves récupérées. Avec le temps, cette observabilité en production a généré plus d’insights actionnables que notre suite de tests hors ligne. Nous avons découvert des modes de défaillance statistiquement rares mais à fort impact, le type de scénarios qui n’apparaîtrait jamais dans un jeu de tests rédigé manuellement mais qui survient inévitablement à l’échelle de la production. L’architecture pratique était simple : du tracing compatible OpenTelemetry pour le runtime de l’agent, une journalisation structurée de toutes les entrées et sorties du LLM, et un pipeline d’évaluation léger tournant de manière asynchrone sur un échantillon de traces de production. L’investissement total en ingénierie était modeste comparé au coût d’une seule défaillance non détectée en production. Leçon 6 : l’évaluation humaine ne passe pas à l’échelle, mais on ne peut pas s’en passer Les métriques automatisées (précision des appels d’outils, scores de similarité de trajectoire, vérifications d’équivalence sémantique) fournissent une couverture essentielle pour les tests de régression et l’intégration continue. Mais elles ont un plafond. La subtilité des défaillances d’agents, en particulier les défaillances de synthèse et de gestion du contexte, nécessite souvent un jugement humain pour être correctement évaluée. Nous avons adopté une stratégie d’évaluation à plusieurs niveaux. L’évaluation automatisée gérait environ 80 % de notre volume de tests : vérifications déterministes de la correction des appels d’outils, validation des sorties structurées, seuils de latence et de coût, conformité aux filtres de sécurité. Les 20 % restants, consacrés aux scénarios inédits, aux cas limites ambigus et aux catégories de tâches à fort enjeu, faisaient l’objet d’une évaluation humaine via un protocole de relecture structuré. L’enseignement clé : l’évaluation humaine doit être structurée, pas ad hoc. Les relecteurs évaluaient les trajectoires à l’aide de grilles avec des critères explicites pour chaque catégorie de défaillance de notre taxonomie. L’accord inter-évaluateurs était mesuré et calibré régulièrement. Et les résultats de l’évaluation humaine étaient réinjectés dans le pipeline automatisé : chaque schéma de défaillance identifié par un humain devenait candidat à un nouveau contrôle automatisé. Leçon 7 : testez le système, pas seulement l’agent Un agent autonome en production n’est pas un composant isolé. Il opère au sein d’un système qui comprend des API d’outils, une infrastructure de récupération, des garde-fous et filtres de sécurité, des couches d’authentification et d’autorisation, des limiteurs de débit, des gestionnaires de repli et des parcours d’escalade vers l’humain. Tester l’agent de manière isolée, avec des outils mockés et des données synthétiques, est nécessaire mais insuffisant. Les défaillances les plus conséquentes que nous avons rencontrées en production étaient des défaillances au niveau du système : l’agent avait pris la bonne décision, mais l’API de l’outil avait changé son format de réponse. L’agent avait récupéré le bon document, mais l’index vectoriel était obsolète en raison d’une tâche de rafraîchissement échouée. L’agent avait correctement identifié une tâche hors périmètre et tenté une escalade, mais le canal d’escalade était mal configuré. Nous avons appris à maintenir une suite de tests d’intégration système distincte, sollicitant l’ensemble de la pile avec une infrastructure réelle (ou réaliste en mode shadow). Ces tests tournaient à une cadence plus lente que les tests unitaires et de trajectoire (quotidiennement plutôt qu’à chaque commit), mais ils interceptaient toute une catégorie de défaillances qu’aucun test d’agent isolé ne pouvait révéler. La vérité qui dérange Tester des agents autonomes est coûteux, lent et jamais vraiment terminé. L’espace combinatoire des comportements possibles d’un agent est effectivement infini. Chaque mise à jour de modèle, chaque changement d’outil, chaque évolution de la distribution des entrées utilisateurs peut introduire de nouveaux modes de défaillance que les tests existants ne détecteront pas. Les équipes qui réussissent à déployer des agents fiables ne sont pas celles qui atteignent une couverture de test parfaite. Ce sont celles qui construisent des systèmes conçus pour l’apprentissage continu, où chaque interaction en production est une occasion de découvrir, catégoriser et traiter de nouveaux schémas de défaillance, et où la boucle de rétroaction entre l’observabilité en production et l’évolution de la suite de tests se mesure en heures, pas en trimestres. Les agents autonomes représentent un véritable changement de paradigme dans la façon dont les systèmes logiciels sont conçus. Les tester exige un changement tout aussi fondamental dans la façon dont la qualité logicielle est assurée. Le guide de référence est encore en cours d’écriture, et chaque équipe qui déploie des agents en production en rédige un chapitre. Les leçons partagées ici ne sont pas des réponses définitives. Ce sont des points de départ, des schémas qui ont survécu au contact de vrais systèmes de production et de vrais comportements utilisateurs. Le domaine évolue vite, et les pratiques de test qui paraissent avant-gardistes aujourd’hui sembleront élémentaires d’ici un an. L’idée de fond, elle, perdurera : dans un monde où le comportement logiciel est probabiliste, le test doit évoluer de la vérification de la correction vers la gestion de l’incertitude. Et cette transition, aussi inconfortable soit-elle, est déjà en cours.

🔗 Lire l'article original 👁️ 0 lecture