AWS propose une architecture à sept couches pour les agents : du prototype à la production

Le prototype d'un agent paraît presque toujours convaincant. Il répond aux questions, appelle des outils et fait bonne figure en démo. Puis arrivent le trafic réel, la facture de tokens et la revue des équipes sécurité, et le projet reste bloqué. Selon AWS, le modèle est rarement en cause. Le coupable, c'est l'infrastructure périphérique, que chaque équipe écrit de zéro, et généralement après le lancement plutôt qu'avant.

Le blog AWS Machine Learning a publié une analyse du Pluggable Agentic AI Framework. Il s'agit d'une architecture de référence en sept couches pour les applications multi-agents. Chaque couche a sa zone de responsabilité et un contrat stable avec ses voisines. Les services concrets du schéma ne sont qu'un exemple d'implémentation, pas un choix obligatoire.

Sept couches sans magie

La première couche est celle des données et des connaissances. Elle reçoit une requête et renvoie le contexte pertinent à l'agent. Dans l'exemple, on trouve Bedrock Knowledge Base, OpenSearch Serverless, S3 Vectors et DynamoDB.

La deuxième couche est celle des modèles et de l'inférence. Le choix du modèle doit résider dans la configuration, pas dans le code de l'agent. Les tâches simples vont vers un petit modèle rapide, les raisonnements complexes vers un grand modèle. Entre les agents et les fournisseurs se trouve un proxy comme LiteLLM, avec une interface unique. On peut changer de modèle après une nouvelle évaluation sans toucher à la logique de l'application.

La troisième couche est l'orchestration. Pour une tâche simple, un seul agent suffit. Pour des scénarios complexes transverses à plusieurs domaines, il faut un superviseur et des spécialistes ciblés, chacun avec son propre jeu d'outils. Un agent universel unique finit par accumuler instructions et outils, le contexte gonfle, la latence augmente et la précision baisse. Les spécialistes sont enregistrés dans un registre unique, et le superviseur les trouve et les appelle via les protocoles standard MCP et A2A. Le registre, qui décrit les outils, les compétences et le responsable de chaque agent, sert aussi à la gouvernance et à éviter de développer deux fois la même chose.

La quatrième couche est celle de la sécurité et des garde-fous. Tout contenu externe est considéré comme non fiable. Chaque requête est authentifiée, qu'elle provienne d'un utilisateur, d'un autre agent ou d'un processus automatique. Les droits pour chaque appel d'outil sont vérifiés avant son exécution, et au lieu de secrets permanents, l'agent reçoit des identifiants temporaires à portée limitée. Les données personnelles et médicales sont masquées dans les requêtes et les réponses. Les décisions clés sont consignées dans un journal d'audit, les actions risquées passent par une validation humaine, et des interrupteurs d'urgence stoppent les comportements anormaux.

La cinquième couche est l'application. On recommande de la garder légère : un chat, une API ou un widget transmettent la requête à l'orchestrateur, et c'est tout. La logique métier n'y a pas sa place. À la frontière, on peut placer un modèle classifieur rapide et peu coûteux. En un seul appel, il évalue si la requête entre dans le périmètre thématique, si un humain est nécessaire et quel est le degré d'urgence. Le modèle renvoie des probabilités, pas du texte, et un code classique décide, à partir de seuils, s'il faut lancer la boucle agentique complète.

La sixième couche est l'observabilité. Des traces de bout en bout, le coût et les tokens par requête, le temps jusqu'au premier token, ainsi que des tableaux de bord de latence et d'erreurs sont nécessaires avant le lancement, pas après le premier incident. La septième couche concerne les opérations : une évaluation continue de chaque session de production sur le plan de l'ancrage factuel, de la précision et de la sécurité. S'y ajoute une barrière de non-régression qui empêche de livrer aux clients une version dont la qualité a chuté.

À quoi cela ressemble dans l'exemple

L'implémentation de référence porte sur le support client dans le commerce de détail : statut de commande et possibilité de retour. Le superviseur reçoit une demande de retour et la transmet à deux spécialistes. L'agent des commandes récupère les données de livraison et d'achat dans DynamoDB. L'agent des retours prend dans la base de connaissances les règles par niveau de fidélité et calcule l'éligibilité d'après la date de livraison, la date du jour et le niveau du client. Chaque appel passe par AgentCore Gateway, qui vérifie les droits. Chaque appel est tracé, et si le calcul est erroné, la trace montre à quelle couche et dans quelle décision.

Ce qu'il faut en retenir

L'idée centrale : l'architecture d'abord, les technologies ensuite. Si les frontières entre couches sont définies par des contrats, changer de modèle, de garde-fous ou de système de supervision ne revient pas à réécrire toute la pile. Pour les entreprises, c'est aussi la possibilité de conserver les outils qui fonctionnent déjà et d'ajouter le nouveau progressivement.

Il faut aussi voir les limites. L'article est rédigé par un éditeur et orienté vers la pile AWS : AgentCore, Bedrock, CloudWatch. La substituabilité des composants est affirmée, mais il faudra la vérifier soi-même sur sa propre infrastructure. Les auteurs précisent eux-mêmes que l'exemple ne remplace ni le durcissement de la sécurité, ni les tests, ni la revue.

La conclusion pratique est simple. Même si vous n'utilisez pas AWS, la liste des sept couches fait office de check-list de planification. Avez-vous un registre d'agents ? Les droits sont-ils vérifiés avant l'appel d'un outil ou après ? Savez-vous prouver que l'agent fonctionne aussi bien que le jour du lancement ? Si la réponse est « non » à au moins une de ces questions, vous avez trouvé l'endroit où votre projet risque de rester coincé entre le prototype et la production.