Pourquoi les bons agents d'IA échouent en production : la couche d'infrastructure manquante

Il était 6 heures du matin lorsque la première alerte s'est déclenchée. Puis la deuxième. Puis la troisième.

L'ingénieur d'astreinte a ouvert son ordinateur portable pour constater trois défaillances indépendantes provenant d'un seul agent d'IA. L'agent gérait les tickets d'assistance, traitait les ajustements de facturation et répondait aux questions des clients. Il fonctionnait sur LangChain. Il avait réussi tous les tests en préproduction et fonctionnait, jusqu'au moment où il a cessé de fonctionner.

J'ai vu des équipes consacrer des mois à l'ingénierie de prompt et au choix des modèles, pour finalement perdre un week-end à résoudre un incident qui n'avait rien à voir avec l'un ou l'autre. Les défaillances qui suivent ne sont pas hypothétiques. C'est le genre de situation qui se produit la première fois qu'un agent passe en production sans l'infrastructure nécessaire pour le prendre en charge correctement. Et je n'ai pas encore vu de framework intégrant cette infrastructure (les barrières d'identité, l'application des mesures de sécurité et la gouvernance opérationnelle qu'exige un déploiement en production).

43 tickets d'assistance en double

L'agent (un système d'IA qui raisonne sur les objectifs, sélectionne les outils et exécute des actions en plusieurs étapes de manière autonome) surveillait une file d'attente d'assistance. Un client a soumis une demande. L'agent a appelé l'API de gestion des tickets pour créer un enregistrement, puis l'API a accepté la requête et a créé le ticket. Mais le délai d'attente de la réponse a expiré.

Du point de vue de l'agent, l'appel avait échoué. LangChain a fait ce que tout framework bien conçu fait lors d'un échec d'appel d'outil : il a relancé la requête. Cette nouvelle tentative a créé un deuxième ticket. Le délai de réponse a de nouveau expiré. Nouvelle tentative. Nouveau ticket.

À 6 heures du matin, le système comptait 43 tickets en double. Chacun a déclenché l'envoi d'un e-mail d'accusé de réception automatique, ce qui s'est traduit par 43 messages arrivés dans les boîtes de réception des clients. L'équipe d'assistance a passé la matinée à fermer manuellement les doublons et à présenter des excuses au lieu de faire son travail habituel.

Je tiens à préciser exactement ce qui s'est passé ici, car c'est important. LangChain a géré cela correctement. Le framework a détecté une réponse en échec et a relancé l'appel. C'est exactement ce pour quoi la logique de nouvelle tentative est conçue. Le problème ne venait pas de la nouvelle tentative, mais du fait que rien dans l'infrastructure ne vérifiait si la requête initiale avait réussi. Il n'existait aucune enveloppe d'idempotence (un mécanisme qui garantit qu'une requête répétée produit le même résultat que l'originale, évitant ainsi les doublons). Aucune couche de déduplication. Aucune détection au niveau de la plateforme qu'il s'agissait d'une nouvelle tentative pour une opération déjà terminée.

Pour tout décideur faisant le calcul : le coût ne s'est pas limité à une matinée embarrassante. Il s'est traduit par des heures de travail de l'équipe d'assistance consacrées au nettoyage, une confiance des clients érodée par des e-mails automatiques en double, et un système auquel on ne pouvait plus se fier avant d'avoir audité manuellement chaque ticket ouvert. Pour tout développeur examinant la logique de nouvelle tentative, le code était correct. La lacune se situait en dessous.

Le framework a fait son travail. L'infrastructure qui l'entourait n'existait tout simplement pas.

4 000 dollars facturés sur le mauvais compte

Les lacunes d'infrastructure peuvent être bruyantes (à l'image de 43 tickets), mais elles peuvent aussi être silencieuses. Le même agent d'IA traitait les ajustements de facturation. Il avait accès à une API de facturation provisionnée avec un compte de service lors du déploiement. Le compte de service pouvait accéder à plusieurs comptes de facturation, car c'était le moyen le plus rapide de faire fonctionner l'agent en développement. Personne n'a restreint la portée des informations d'identification avant de passer l'agent en production, car personne n'avait mis en place de barrière d'identité (la couche d'infrastructure qui contrôle les ressources auxquelles une charge de travail donnée peut accéder sur la base d'une identité vérifiée, et pas seulement de la configuration).

L'agent devait débiter le compte A. Son invite incluait l'identifiant du compte. Le modèle a sélectionné le compte B, une erreur plausible pour tout grand modèle de langage (LLM). L'API de facturation a accepté l'appel et 4 000 dollars ont été facturés au mauvais client.

Il ne s'agissait pas d'une défaillance du modèle. Les LLM produisent des résultats plausibles, mais il leur arrive d'avoir tort. La cause probable était l'appel à la même API de facturation avec un paramètre de compte erroné, une erreur de sélection plausible.

Dans les logiciels traditionnels, l'impact potentiel d'un appel d'API mal acheminé est limité par deux couches : la restriction de portée des informations d'identification limite les services qu'une charge de travail peut atteindre, et l'API en aval vérifie la validité des paramètres pour un appelant donné. Un développeur ne déploierait jamais une application web dans laquelle un jeu unique d'informations d'identification permettrait d'écrire dans le dossier de facturation de chaque client, mais c'est exactement ce qui s'est produit ici.

L'agent avait été configuré avec des informations d'identification suffisamment étendues pour accéder à n'importe quel compte du système, et rien dans la pile (ni la plateforme ni l'API en aval) ne restreignait cette portée. Aucun framework n'intègre actuellement la restriction de portée des informations d'identification. Aucun ne fournit d'identité cryptographique des charges de travail ni n'impose les services auxquels un agent peut accéder en fonction de stratégies définies au niveau de l'infrastructure plutôt que du contenu de l'invite.

Personne ne s'en est aperçu avant le lundi suivant, lorsque la facture a été vérifiée. J'ai observé des variantes de cette défaillance à toutes les échelles : les détails changent, mais la cause première reste toujours la même. L'agent disposait d'informations d'identification qu'il n'aurait pas dû détenir, et rien dans la pile n'appliquait de limite.

Une politique de remboursement que l'entreprise n'a jamais rédigée

L'absence de limites effectives a causé une erreur de 4 000 dollars cette nuit-là, mais la troisième défaillance a coûté quelque chose de bien plus difficile à chiffrer. Un client a interrogé l'agent sur le délai de retour d'un produit acheté. Le modèle a généré une réponse claire et assurée : la politique de remboursement autorise les retours sous 90 jours. La politique réelle prévoyait 30 jours. La réponse était bien formulée, serviable et complètement fausse.

LangChain a transmis la sortie du modèle au canal de réponse destiné aux clients. Une fois de plus, le framework a fait exactement ce pour quoi il avait été conçu : acheminer les résultats du modèle vers l'étape suivante de la chaîne. Il n'y avait pas de garde-fou à la frontière d'inférence (le point où la sortie d'un modèle entre dans le monde réel, qu'elle soit envoyée à un client, écrite dans une base de données ou utilisée pour déclencher une action). Aucune couche de validation n'a comparé la sortie à la politique officielle. Aucun mécanisme n'a vérifié si la réponse de l'agent contredisait des faits établis avant qu'elle ne parvienne au client. La sortie est passée directement du modèle au client, sans aucun intermédiaire.

Le client a retourné un produit de 280 dollars au 47e jour, en invoquant la réponse de l'agent. L'équipe a accepté le retour. Le coût ne s'est pas limité au remboursement : il a engendré un risque juridique, car un agent d'IA avait pris un engagement contractuel non autorisé auprès d'un client et l'entreprise ne disposait d'aucune piste d'audit montrant les contrôles en place pour l'empêcher.

L'erreur de facturation est quantifiable en dollars. Les tickets en double se comptent. Une politique inventée transmise à un client est plus difficile à chiffrer et plus difficile à maîtriser. C'est un risque qui s'accumule : chaque réponse envoyée par l'agent sans validation constitue un nouvel engagement contractuel potentiel que votre équipe juridique n'a jamais approuvé. Toute entreprise exploitant un agent qui communique avec des clients s'expose à ce risque, et la plupart le font sans le savoir.

L'agent fonctionnait correctement

Trois défaillances en une seule nuit pour un agent qui fonctionnait parfaitement en développement.

Observez le schéma récurrent. Dans chaque cas, le framework a fonctionné correctement. LangChain a orchestré les appels d'outils, acheminé les sorties et effectué une nouvelle tentative en cas d'échec. La boucle d'agent (raisonnement, planification, appels d'outils et orchestration) a fonctionné comme prévu.

Chaque défaillance s'est produite parce que l'infrastructure de production était absente. La première défaillance nécessitait de l'idempotence et de la déduplication au niveau de la plateforme. La deuxième nécessitait une barrière d'identité avec des informations d'identification à portée restreinte et une identité cryptographique des charges de travail. La troisième nécessitait des garde-fous à la frontière d'inférence (une validation des sorties par rapport aux faits documentés avant que la réponse ne parvienne au client).

Ces aspects ne relèvent pas du framework. L'identité, la gouvernance des outils (contrôler les outils auxquels un agent peut accéder et dans quelles conditions), l'observabilité (suivre chaque action effectuée par un agent pour l'audit et le débogage) et l'application des mesures de sécurité relèvent de la plateforme : aucun framework n'a été conçu pour résoudre ces problématiques.

J'ai échangé avec des équipes qui exécutent des agents sur LangChain, CrewAI, LangGraph et des frameworks personnalisés. Le choix du framework varie. La lacune reste la même. Elles se heurtent toutes au même mur : l'écart entre « fonctionner en développement » et « tourner en production » n'est pas un problème de framework, mais d'infrastructure, et cela coûte de l'argent réel, entame la confiance des clients et mobilise du temps d'ingénierie tant qu'il n'est pas résolu.

Comment combler cette lacune

Ce problème d'infrastructure présente une forme bien précise. Les frameworks d'agents résolvent le fonctionnement de la boucle d'agent. Ils n'ont jamais été conçus pour gérer l'infrastructure de production, et ce n'est d'ailleurs pas leur rôle. On n'attendrait pas d'un framework web qu'il fournisse sa propre autorité de certification TLS (Transport Layer Security). Il s'agit de domaines d'ingénierie distincts.

Red Hat AI fournit l'infrastructure de production que les frameworks n'intègrent pas. Red Hat OpenShift AI sert de base. Le principe de fonctionnement repose sur le BYOA (Bring Your Own Agent) : la plateforme rend opérationnel tout environnement d'exécution d'agent, qu'il s'agisse de LangChain, CrewAI, LangGraph ou d'un code personnalisé, sans nécessiter de modification de l'agent. Votre investissement dans le framework est préservé. Le code de votre agent ne change pas. La plateforme injecte les couches d'identité, de sécurité, de gouvernance et d'observabilité sous-jacentes.

Une lacune déjà bien présente

L'agent qui a flanché à 6 heures du matin n'était pas un mauvais agent. C'était un bon agent fonctionnant sans aucun socle sous ses pieds. Chaque framework fournit la boucle de raisonnement, les appels d'outils et l'orchestration. Aucun ne fournit l'infrastructure qui détermine si ces fonctionnalités peuvent être exécutées en toute sécurité dans des conditions réelles. Cette distinction (entre ce que le framework gère et ce que la plateforme doit prendre en charge) constitue le fossé de la mise en production. Ce n'est pas une lacune que votre framework a été conçu pour combler.

Si vous avez des agents en développement actuellement, il y a fort à parier qu'ils reposent sur le même vide. Non pas parce que vous les avez mal conçus, mais parce que ce socle n'est pas fourni avec le framework. Notre prochain article présente les éléments spécifiques qui composent ce socle et ce qu'il faut pour les mettre en place.

Lancez-vous

Vous souhaitez découvrir à quoi ressemble une infrastructure d'agents prête pour la production ? Commencez ici :

• Essayez gratuitement OpenShift AI dans la Developer Sandbox : un environnement préconfiguré pour tester des charges de travail d'IA
• Découvrez les démos interactives de Red Hat AI : des initiations pratiques à Red Hat AI
• Démarrez avec les kits de démarrage BYO Agent : modèles préconfigurés pour LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK et plus encore
• Consultez la documentation de Red Hat AI : documentation complète sur la plateforme
• Mise en œuvre du BYOA sur Red Hat AI : L'édition OpenClaw : un article pratique sur le déploiement d'un agent réel sur la plateforme