Construire une plateforme d'IA à base d'agents sur Amazon Bedrock AgentCore
Faire passer un agent en production se heurte moins au modèle ou aux outils qu'à tout ce qui les entoure : comment de nombreuses équipes peuvent construire dans un environnement sécurisé, qui possède chaque modèle et chaque outil, comment l'exploitation des agents et la gestion des erreurs restent dans un cadre prédéfini, et comment les équipes plateforme, métier et finance suivent les coûts et la santé du parc sur plusieurs comptes. AWS détaille une architecture de référence pour une plateforme d'IA agentique d'entreprise fondée sur Amazon Bedrock et Amazon Bedrock AgentCore, ce dernier fournissant des services modulaires (runtime, gateway, identité, mémoire, politiques, registre, évaluations). Le « Enterprise Agentic AI Platform Blueprint » y ajoute, sous forme d'infrastructure as code déployable, les contrats d'entreprise : propriété, frontières de comptes, livraison logicielle, observabilité, gouvernance des coûts et retrait. L'architecture repose sur un modèle multi-comptes, un plan de contrôle géré par l'équipe Plateforme, un schéma de déploiement reproductible pour chaque « Workstream » (équipe produit ou métier qui construit et possède ses agents), des passerelles distinctes pour l'inférence et les outils, et un pipeline d'évaluation qui conditionne la mise en production de chaque agent.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu est d'éviter que chaque équipe réassemble ses propres contrôles, ce qui provoque une dérive, des goulets d'étranglement sur les services partagés et une propriété difficile à auditer. Chaque Workstream doit disposer d'une « voie balisée » : modèles et outils approuvés, identité de charge de travail à courte durée de vie, runtime et mémoire isolés, évaluation automatisée, retour arrière, télémétrie et attribution des coûts. Pour les organisations, cela signifie que les équipes peuvent livrer et revenir en arrière de façon autonome, sans attendre l'équipe plateforme ni disposer d'un accès direct en écriture à l'infrastructure. Les ingénieurs d'exploitation obtiennent journaux, métriques, traces et quotas, les responsables de Workstream voient le coût par agent face à leur budget, la finance peut facturer par équipe ou unité via AWS Cost Explorer et le rapport CUR, et les responsables sécurité disposent de preuves indiquant quelle charge de travail a appelé quel modèle ou outil.
Ces principes répondent à cinq besoins récurrents exprimés par les clients. Premièrement, un accès gouverné aux modèles : toute requête d'inférence non fiable passe par une passerelle approuvée qui applique les garde-fous (Amazon Bedrock Guardrails ou un fournisseur tiers), limite les modèles et les Régions AWS autorisés par Workstream, impose limites de débit, quotas de jetons et budgets pour qu'aucune équipe n'épuise la capacité partagée, et transporte l'identité tout en émettant les données d'attribution. Deuxièmement, un accès gouverné aux outils : les agents ne découvrent et n'invoquent que des outils approuvés via une passerelle Model Context Protocol (MCP) authentifiée, avec cibles exactes, rôles d'exécution à moindre privilège, décisions de politique et propriétaire auditable. S'y ajoutent la livraison déléguée, les opérations de parc avec suivi des coûts, ainsi que la preuve bornée et la gestion du cycle de vie de chaque version d'agent. Face à la multiplication des cas d'usage agentiques en entreprise, AWS positionne ainsi la plateforme comme un produit à concevoir et à exploiter, plutôt qu'un assemblage laissé à chaque équipe.
Pas d'impact direct sur la France/UE