Agents IA : Démo parfaite, échecs cachés en production

La démo parfaite, le cauchemar en production

Lorsqu'un agent IA est testé en démonstration, il peut sembler fonctionner sans faille. Les tests répétés, les présentations à l'équipe, et même aux dirigeants techniques, montrent souvent des résultats impeccables. Chaque requête semble produire la réponse attendue. Cependant, une fois déployé en production, la réalité peut être bien différente.

Quelques jours après le déploiement, un client peut signaler que l'agent a fourni des informations totalement incorrectes, et ce, avec une assurance déconcertante. Les journaux d'activité montrent des réponses HTTP 200, indiquant que tout semble fonctionner correctement. Pourtant, l'agent a pu halluciner des réponses erronées pendant plusieurs jours sans que l'infrastructure ne le détecte.

Ce problème ne réside pas dans la qualité du modèle lui-même, mais dans l'architecture qui le sous-tend. C'est un problème souvent ignoré, car il ne devient apparent qu'une fois que l'agent est en production.

Les chiffres alarmants

Avant d'explorer les différents types d'échecs, il est crucial de comprendre un chiffre clé. Si un agent IA atteint une précision de 85 % par étape, ce qui est considéré comme un bon résultat, et que le flux de travail comporte 10 étapes, la probabilité de compléter ce flux avec succès n'est que de 19,7 %.

Dans ce modèle simplifié, chaque étape est indépendante et le succès est binaire. Cela signifie que même si chaque étape est « plutôt bonne », environ huit flux de travail sur dix échoueront. Les échecs réels sont souvent plus complexes, et les étapes ne sont pas toujours indépendantes. Le problème architectural est donc que les flux de travail à plusieurs étapes accumulent les échecs. La solution réside dans l'intégration de la gestion des échecs à chaque étape, et non seulement à la fin.

Les six modes d'échec

Échec 1 : Dégradation du contexte

Dans un flux de travail d'agent à plusieurs étapes, le modèle peut perdre la mémoire des événements passés. Chaque appel API inclut l'historique complet de la conversation, qui s'allonge à chaque étape.

Les ingénieurs peuvent ne pas réaliser que le contexte ne fait pas que croître, il se dégrade. Le rapport "State of AI Engineering 2026" de Datadog montre que le nombre moyen de tokens dans les flux de travail des agents en production a doublé d'une année sur l'autre pour les utilisateurs moyens, et quadruplé pour les utilisateurs intensifs. À mesure que le contexte grandit, l'instruction originale s'efface, remplacée par de nouvelles sorties et résumés, ce qui conduit l'agent à agir sur des signaux de plus en plus corrompus.

L'agent ne signale pas ce phénomène. Les sorties deviennent progressivement erronées, presque impossibles à détecter sans outils d'évaluation. Les ingénieurs construisent souvent des agents qui passent des sorties entre les étapes sous forme de résumés en texte brut. Chaque résumé est une compression avec perte, et à l'étape 8, l'agent agit sur un résumé d'un résumé d'un résumé de l'instruction originale.

La solution est de préserver les sorties structurées entre les étapes, en utilisant des contrats de données typés plutôt que des transmissions en langage naturel.

Échec 2 : Échecs silencieux

Ce type d'échec est particulièrement redouté car il passe souvent inaperçu. La surveillance traditionnelle ne détecte pas les échecs des agents. Un agent qui hallucine une réponse erronée mais confiante renvoie toujours HTTP 200. La latence et le taux d'erreur semblent normaux, et les tableaux de bord restent verts.

La recherche de Latitude sur l'observabilité en production montre que l'utilisation incorrecte des outils est le mode d'échec le plus courant et le plus insidieux en production. Un seul argument mal formé peut corrompre chaque étape suivante dépendante de cette sortie.

Un exemple classique est un agent de support client répondant à des questions sur le statut du compte. En test, les requêtes sont en anglais structuré. En production, elles sont désordonnées, multilingues, et émotionnellement chargées. L'agent renvoie des réponses plausibles mais erronées, et le seul signal est une escalade client, souvent bien après le début de la dégradation.

La solution est d'ajouter une couche d'évaluation LLM légère qui évalue chaque sortie d'agent avant qu'elle n'atteigne l'utilisateur. Ce modèle rapide vérifie la pertinence de la réponse par rapport à la requête, sa conformité avec les données sources, et si le langage de confiance est justifié.

Échec 3 : Dérive du schéma d'exécution des outils

Les agents appellent divers outils comme des APIs, des requêtes de base de données, ou des services internes. Ces outils évoluent, mais l'agent n'en est pas informé.

C'est un problème de version d'API. Un agent ne valide pas que le schéma de réponse de l'outil correspond à ce qu'il attend. Lorsqu'une API tierce met à jour son format de réponse, ou qu'un service interne modifie un champ requis, l'agent peut recevoir une réponse mal formée ou vide, et halluciner une réponse plausible ou entrer dans une boucle de réessai.

Le rapport "State of AI Engineering 2026" de Datadog indique que les erreurs de limite de taux ont représenté près de 8,4 millions d'erreurs dans leur ensemble de données d'observabilité LLM. Ces échecs sont souvent traités par une logique de réessai, ce qui mène au mode d'échec suivant.

La solution est de valider explicitement les schémas de réponse des outils avant de les passer au modèle, traitant les sorties des outils comme des données externes non fiables.

Échec 4 : Exécution incontrôlée et cascades de coûts

Cet échec a des implications financières directes.

En novembre 2025, quatre agents LangChain sont entrés dans une boucle de clarification infinie. Un Analyseur et un Vérificateur échangeaient des requêtes sans qu'un orchestrateur ne décide de l'arrêt. Sans limite d'étape, ni budget par conversation, ni disjoncteur, la boucle a duré 11 jours, coûtant 47 000 $. La première semaine a coûté 127 $, mais la quatrième semaine a atteint 18 400 $. Personne ne l'a remarqué jusqu'à la réception de la facture.

Un autre cas en 2026 a vu un agent effectuer 14 000 appels répétés avant que le compte ne soit suspendu. Chaque appel API LLM est sans état, et les agents envoient l'historique complet de la conversation à chaque appel. Une boucle à l'étape 20 avec des sorties d'outils accumulées peut dépasser 50 000 tokens d'entrée par appel. À des prix de modèle de pointe, une seule étape tardive de boucle coûte des centimes, mais ces centimes s'accumulent rapidement.

La solution est d'imposer des plafonds budgétaires stricts au niveau de l'agent, des disjoncteurs sur les boucles de réessai, et des limites de nombre d'étapes.

Échec 5 : Explosion des permissions

Les agents ont besoin d'accès pour fonctionner, mais cet accès peut s'accumuler de manière incontrôlée.

Le schéma typique est que les rôles IAM sont réutilisés à travers plusieurs déploiements d'agents, plutôt que d'être spécifiquement adaptés à chaque agent. Cela peut mener à des permissions excessives, augmentant le risque de sécurité.

La solution est de définir des rôles IAM spécifiques pour chaque agent, limitant l'accès aux seules ressources nécessaires pour leur tâche, et de réévaluer régulièrement ces permissions pour éviter une accumulation dangereuse.