Agents autonomes : les défis cachés de leur mise en production

Les agents autonomes, souvent impressionnants lors des démonstrations, posent de nombreux défis lorsqu'il s'agit de les déployer en production. Les équipes d'ingénierie découvrent rapidement que la fiabilité de ces systèmes nécessite bien plus que ce que les démonstrations laissent entrevoir. Au cours des deux dernières années, en travaillant sur des systèmes agentiques en production dans des environnements d'entreprise, un ensemble de leçons a été durement appris sur ce qu'il faut réellement pour tester des agents autonomes.

La démo fonctionne toujours

Lors d'une démonstration, un agent autonome se connecte à divers outils, raisonne sur une tâche en plusieurs étapes et livre un résultat impeccable. L'auditoire acquiesce, la direction valide le projet, et l'équipe technique reçoit un calendrier. C'est à ce moment que le véritable travail commence, celui dont personne n'avait parlé auparavant. Tester des agents autonomes est fondamentalement différent de tester un logiciel classique. Le chemin d'exécution change à chaque appel, et les modes de défaillance sont souvent subtils, différés et invisibles sans une instrumentation rigoureuse. Le manuel de test habituel, comprenant les tests unitaires, les tests d'intégration et les suites de régression de bout en bout, ne couvre qu'une fraction de ce qui est réellement nécessaire.

Le déterminisme : un objectif illusoire

Le premier réflexe des équipes d'ingénierie est de tenter de rendre le comportement de l'agent déterministe. Cela passe par des réglages comme la température à zéro, la fixation du générateur de nombres aléatoires, la mise en cache des réponses du modèle, et le verrouillage de la version du modèle. Cependant, même avec ces mesures, 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, comme les stratégies de batching, l'ordre d'accumulation des calculs en virgule flottante sur les cœurs GPU, et les arrondis de quantification, introduit une variation qu'aucune configuration applicative ne peut totalement éliminer. La leçon pratique est d'arrêter de chercher un déterminisme parfait et de commencer à 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", il est préférable de s'assurer 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. En pratique, 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. Une combinaison d'analyse de sorties structurées, d'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 offre la couverture de test la plus fiable, sans fragilité excessive.

Les défaillances inter-étapes : un défi majeur

Les bugs des agents ne se manifestent pas toujours au niveau des étapes individuelles, mais souvent dans la manière dont ces étapes interagissent. 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 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 ?"

Importance d'une 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, défaillances de sélection d’outil, défaillances d’extraction de paramètres, défaillances de gestion du contexte, défaillances de terminaison, et défaillances de synthèse. 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.

Tests adversariaux : une nécessité

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 ambiguë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 : ambiguïté, robustesse, cas limites, et injection de prompt. 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.

L'observabilité : un outil crucial

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 incorrectes, etc.