Pourquoi votre framework d'agent d'IA n'est pas suffisant : sept capacités de plateforme manquantes en production

Votre agent fonctionne. Je le sais. Vous l'avez conçu avec LangChain, CrewAI ou un outil personnalisé, vous l'avez testé dans des scénarios réels et il les a traités. Le problème ne vient pas de l'agent. Le problème, c'est tout ce qui l'entoure.

Dans le livre numérique « Pourquoi les bons agents d'IA échouent en production : La couche d'infrastructure manquantePage affichée en Anglais (Français non disponible) », trois défaillances ont perturbé le déploiement d'un seul agent d'IA du jour au lendemain : 43 demandes d'assistance en double, 4 000 dollars facturés sur le mauvais compte et une politique de remboursement inventée par l'agent, qui a contraint l'entreprise à honorer un retour de 280 dollars. Cet agent a parfaitement fonctionné en développement, mais il a échoué en production parce que l'infrastructure de production était insuffisante. Le fossé qui sépare un agent opérationnel en développement d'un déploiement prêt pour la production n'est pas un problème de framework, mais d'infrastructure.

Cet article met en lumière cet écart. J'aborderai les points suivants :

• Sept capacités spécifiques qu'aucun framework ne fournit actuellement
• Où s'arrête votre framework
• Pourquoi trois solutions de contournement courantes échouent
• Ce qui aide réellement à combler l'écart, sans vous demander de réécrire votre agent

Sept éléments que votre framework ne fournit pas

L'incident de 6 h a révélé trois échecs. Mais ces trois échecs sont les symptômes d'un ensemble plus large d'infrastructures manquantes. Lorsque je cartographie les défaillances des agents de production dans les entreprises, les sept mêmes écarts apparaissent à chaque fois.

1. Identité cryptographique

L'identité cryptographique fournit une preuve vérifiable de la charge de travail qui envoie une requête, avec des attributs d'identité qui déterminent les services auxquels elle peut accéder. La facturation de US$ 4 000 sur le mauvais compte est survenue parce que l'agent utilisait des informations d'identification étendues qui n'avaient jamais été limitées pour la production. Un grand modèle de langage (LLM) a sélectionné le mauvais identifiant de compte et rien dans l'infrastructure ne l'a arrêté. Avec l'identité cryptographique, la plateforme limite les services auxquels l'agent peut accéder, et les API en aval correctement configurées vérifient quels paramètres sont valides pour un appelant donné. Le modèle peut toujours sélectionner le mauvais identifiant, mais l'impact potentiel est circonscrit, les dommages sont limités aux ressources comprises dans le champ d'application autorisé de l'agent, et non à tous les comptes du système. Pour les décideurs, c'est la différence entre « un seul compte a été touché » et « tous les comptes ont été exposés ».

2. Sandboxing d'exécution

Le sandboxing d'exécution assure l'isolation au niveau du matériel et des applications afin qu'une charge de travail compromise ou défaillante ne puisse pas atteindre le système d'exploitation hôte ni affecter d'autres charges de travail. Cela n'est pas propre aux agents, toute charge de travail a besoin d'isolation, mais les agents rendent cette mesure urgente car ils fonctionnent de manière autonome, appelant des API et exécutant des actions à la vitesse de la machine. Sans sandboxing, la défaillance d'une charge de travail devient la défaillance de toutes les charges de travail sur la même machine. Un agent capable d'écrire dans le système de fichiers ou d'ouvrir des connexions réseau en dehors de son champ d'application est un risque que l'équipe de sécurité n'approuvera jamais pour la production.

3. Gouvernance des outils

La gouvernance des outils est une politique au niveau de l'infrastructure qui détermine quels outils un agent peut appeler, appliquée au niveau de la couche réseau afin qu'aucune injection d'instructions (une technique par laquelle une entrée malveillante trompe un agent pour l'inciter à effectuer des actions non prévues) ne puisse la contourner. J'ai vu des équipes essayer d'imposer l'accès aux outils par le biais de l'ingénierie de prompt, mais cela ne tient pas. Un adversaire déterminé, ou un modèle suffisamment créatif, contourne les restrictions au niveau des instructions. La gouvernance relève de l'infrastructure, et non du prompt.

4. Observabilité et traçage

L'observabilité et le traçage incluent des traces d'exécution complètes capturant chaque instruction, appel d'outil et résultat intermédiaire. Les trois défaillances de l'incident de 6 h sont passées inaperçues jusqu'à ce que les clients et les factures les révèlent. Avec des traces d'exécution complètes, chaque défaillance aurait été visible avant qu'un client ne la signale. Pour les développeurs, cela signifie déboguer une interaction d'agent en plusieurs étapes de la même manière que l'on débogue un appel de microservice distribué. Pour l'entreprise, cela signifie des pistes d'audit qui satisfont les responsables de la conformité.

5. Évaluation continue

L'évaluation continue permet de noter en production les résultats de l'agent par rapport aux politiques et à la vérité de terrain, de sorte que les régressions apparaissent avant que les clients ne les signalent. La politique de remboursement inventée par l'agent — où celui-ci a indiqué à un client que le délai de retour était de 90 jours au lieu de 30 — a été communiquée par erreur au client car aucune étape d'évaluation n'avait comparé le résultat à la politique réelle. Les suites de tests statiques détectent ce que vous avez anticipé, l'évaluation continue détecte ce que vous n'avez pas prévu.

6. Application des mesures de sécurité

L'application des mesures de sécurité fournit des garde-fous à la limite d'inférence qui interceptent les résultats avant qu'ils n'atteignent les clients, les bases de données ou les agents en aval. Dans l'exemple où un agent a échoué trois fois en une journée, le framework a acheminé la réponse inventée du modèle directement vers le client sans aucune vérification. L'application des mesures de sécurité fait de la limite d'inférence un point de contrôle, et non un simple passage.

7. Gestion du cycle de vie

La gestion du cycle de vie comprend le déploiement, la mise à jour, la mise à l'échelle et le retrait des agents au sein d'un parc avec une posture d'exploitation et de sécurité cohérente. Un seul agent est un projet, mais 10 agents répartis sur trois équipes constituent un défi opérationnel. Sans gestion du cycle de vie, chaque équipe invente son propre processus de déploiement, son propre modèle de sécurité et sa propre cadence de mise à jour. La cohérence disparaît.

Où s'arrête votre framework

La cohérence entre ces sept capacités est ce que la production exige. Alors, où vous laissent réellement les frameworks que vous utilisez déjà ? LangChain et LangGraph vous fournissent des chaînes, des agents, des appels d'outils, des sorties structurées, une orchestration basée sur des graphes, une mémoire de session et une intégration de la recherche. La modularité est réellement forte. CrewAI vous permet la coordination multi-agents, la conception d'agents basés sur les rôles, la délégation de tâches et l'orchestration d'équipes, et les modèles multi-agents sont bien pensés. Google ADK s'intègre étroitement à l'écosystème Google. Les agents Claude apportent une profondeur de raisonnement. Strands (AWS) fournit une intégration de workflow native pour AWS.

Chaque framework excelle dans la boucle de l'agent, ce cycle de perception, de raisonnement et d'action qui fait d'un agent un agent. Aucun d'entre eux ne fournit d'identité cryptographique ni de sandboxing d'exécution. La gouvernance des outils au niveau de la couche réseau est absente. Le traçage distribué de niveau production, l'évaluation continue, l'application des mesures de sécurité à la limite d'inférence et la gestion du cycle de vie du parc n'existent dans aucun d'entre eux.

Ce n'est pas une critique, c'est simplement une distinction de catégorie. Les frameworks sont des outils de la couche application, mais les sept capacités que j'ai énumérées relèvent de la couche plateforme. S'attendre à ce que votre framework les fournisse, c'est comme s'attendre à ce que Django fournisse Kubernetes : l'orchestration de conteneurs relève de l'infrastructure, non de la logique applicative, et il serait déraisonnable d'attendre d'un framework web qu'il l'inclue. Il en va de même ici. Les couches sont simplement différentes.

Si vous avez déjà essayé de déployer un agent LangChain avec une identité, un traçage et une gouvernance appropriés, vous l'avez déjà ressenti. Vous finissez par écrire plus de code d'intégration de plateforme que de code d'agent. L'agent était la partie la plus facile.

Trois approches qui ne passent pas à l'échelle

Si l'agent était la partie facile, les équipes doivent encore résoudre la partie difficile. Toutes les équipes avec lesquelles j'échange ont essayé au moins l'une de ces approches avant de chercher une solution de plateforme.

Le construire soi-même. Les équipes écrivent leurs propres scripts d'injection d'identité, d'intégration du traçage et de déploiement. Pour un seul agent, cela fonctionne. C'est même satisfaisant car vous comprenez chaque élément. Avec 10 agents répartis sur trois équipes, chaque équipe a son propre modèle de sécurité, son propre format de traçage et son propre processus de déploiement. Il n'y a plus de cohérence ni de gouvernance, seulement une charge de maintenance croissante qui détourne les ingénieurs seniors des agents eux-mêmes. J'ai vu des équipes passer plus de temps à maintenir leur liant de plateforme maison qu'à développer des capacités d'agent.

Les plateformes d'agents hébergées comme Salesforce Agentforce, AWS Bedrock Agents ou Azure AI Agent Service comblent l'écart de production en s'appropriant l'ensemble de la pile. Le compromis est qu'elles contrôlent également le cheminement des données. Chaque instruction, chaque appel d'outil et chaque artéfact de raisonnement passe par un service tiers. Dans les secteurs réglementés, où les données ne doivent pas quitter votre réseau, c'est inenvisageable. Et lorsque la plateforme modifie ses tarifs ou abandonne une fonctionnalité, vos agents doivent s'adapter.

Les extensions spécifiques aux frameworks proposent des modules complémentaires orientés production au sein d'un seul écosystème ; LangSmith pour le traçage en est un bon exemple et s'avère réellement utile. Mais une organisation utilisant LangChain, CrewAI et des agents personnalisés a désormais besoin de trois approches de production distinctes. Cela signifie trois formats de traçage, trois modèles de sécurité et trois ensembles d'outils à apprendre pour les équipes. L'infrastructure de production devrait être indépendante du framework, et non un élément supplémentaire verrouillé sur l'écosystème d'un seul fournisseur.

Chaque approche résout une partie du problème tout en introduisant une nouvelle contrainte. La première ne passe pas à l'échelle. La seconde troque la souveraineté contre la commodité. La troisième fragmente l'approche de production entre les limites des frameworks.

Votre agent, la plateforme Red Hat

La contrainte commune à chaque approche est l'hypothèse selon laquelle l'infrastructure de production doit provenir du même endroit que le framework d'agent, ou être construite de toutes pièces. Je pense que cette hypothèse est erronée. Le BYOA (Bring Your Own Agent), l'approche de Red Hat AI où la plateforme fournit l'infrastructure de production pour n'importe quel framework d'agent sans modification du code, part du principe opposé.

Red Hat n'est pas en concurrence au niveau de la couche framework. Que votre agent s'exécute sur LangChain, CrewAI, les agents Claude, Google ADK, Strands ou du code Python personnalisé, Red Hat AI l'opérationnalise. Le code de l'agent écrit par votre équipe en développement est le même que celui qui s'exécute en production. L'identité, le sandboxing, la gouvernance des outils, le traçage, l'évaluation et la gestion du cycle de vie sont injectés par la plateforme, et non écrits par le développeur de l'agent. De plus, l'infrastructure de production est cohérente pour chaque framework de l'organisation.

Pour les décideurs, cela signifie que l'investissement de l'organisation dans le framework choisi n'est pas perdu. Les équipes n'ont pas à choisir entre leur framework préféré et une infrastructure de production conforme aux restrictions réglementaires, elles bénéficient des deux. La plateforme apporte l'infrastructure de production au framework, et non l'inverse.

Le BYOA marque également le passage de la location d'une infrastructure d'IA à sa pleine possession. Red Hat identifie quatre piliers de la souveraineté numérique : la souveraineté des données, la souveraineté technologique, la souveraineté opérationnelle et la souveraineté de l'assurance. La plateforme BYOA répond à ces quatre piliers, dont nous parlerons dans les prochains articles.

La même infrastructure de plateforme qui alimente un agent SRE (Site Reliability Engineer) autonome peut prendre en charge un assistant d'intégration RH, un workflow d'approbation des achats ou un bot d'escalade du service client ; l'infrastructure est indépendante du domaine même si les cas d'utilisation diffèrent.

Red Hat propose des kits de démarrage pour LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK et bien d'autres avec une intégration de plateforme déjà câblée : authentification, connexion MCP (Model Context Protocol) et initialisation du traçage. Les équipes commencent à construire dès le premier jour, et non après des semaines de travail d'intégration.

La décision que vous savez déjà prendre

Le premier jour au lieu de plusieurs semaines, cette formulation devrait vous sembler familière. Il y a une décennie, les organisations étaient confrontées à la même question avec les conteneurs : chaque équipe pouvait créer un conteneur, mais personne ne pouvait les exécuter en production avec une gestion cohérente de la sécurité, du réseau et du cycle de vie à l'échelle de l'entreprise. La réponse n'était pas de « choisir un meilleur moteur d'exécution de conteneurs », la réponse était Red Hat OpenShift, une plateforme qui opérationnalisait n'importe quel moteur d'exécution avec l'infrastructure qu'il ne fournissait pas. Ce dont nous discutons ici vous semble familier car Red Hat AI s'appuie sur cette base.

L'écart lié aux agents a la même forme. La question n'est pas de savoir « quel framework utiliser ». Vous avez déjà pris cette décision, et c'était probablement la bonne. La question est : « qui fournit l'infrastructure de production que mon framework ne fournit pas », et le premier écart à combler est celui où la distance entre le développement et la production est la plus grande. Il s'agit de la sécurité, et notre prochain article reprend le sujet à ce point.

Lancez-vous

Prêt à combler l'écart de production pour vos agents ?

• Essayez OpenShift AI gratuitement dans la Developer Sandbox : créez et testez des agents dans un environnement préconfiguré sans frais.
• Explorez les kits de démarrage BYO Agent : Modèles préconfigurés pour LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK et bien plus encore.
• Suivez le cours gratuit Red Hat AI Foundations : Ateliers pratiques couvrant les bases de la construction sur Red Hat AI.
• En savoir plus sur Red Hat AI : Présentation de la plateforme et des capacités de l'infrastructure de production.
• Mise en œuvre du BYOA sur Red Hat AI : L'édition OpenClaw : Découvrez le BYOA en pratique avec un déploiement d'agent réel.