OutilsAWS ML Blog3h

Intégration du serveur MCP AWS API avec Amazon Q via Amazon Bedrock AgentCore Runtime

Résumé IASource uniqueImpact UE

Amazon Web Services a publié un tutoriel détaillant comment connecter Amazon Q, son assistant IA conversationnel, à l'ensemble de l'infrastructure cloud via une architecture combinant Amazon Bedrock AgentCore Runtime et le Model Context Protocol (MCP). Le dispositif s'appuie sur un serveur AWS API MCP pour transformer des requêtes en langage naturel en commandes AWS CLI exécutées directement dans l'environnement cloud. Concrètement, un ingénieur peut demander "Montre-moi toutes les instances EC2 actives dans us-east-1" et obtenir une réponse structurée sans mémoriser la syntaxe des API ni jongler entre plusieurs interfaces. L'authentification repose sur Amazon Cognito via un flux OAuth 2.0 et des tokens JWT, tandis que les commandes s'exécutent sous un rôle IAM à privilèges minimaux. La mise en place est estimée à 30 à 45 minutes, et le coût mensuel pour un utilisateur Enterprise effectuant environ 500 requêtes reste modeste.

Ce type d'intégration répond à une friction bien documentée dans les équipes SRE et DevOps : les ingénieurs passent une part significative de leur temps à basculer entre la console AWS, la documentation CLI et les tableaux de bord des dizaines de services disponibles. Un diagnostic d'incident oblige à croiser manuellement les logs CloudWatch, l'état des instances EC2 et les politiques IAM dans des interfaces séparées. La planification de capacité nécessite des requêtes manuelles sur plusieurs services, et les audits de sécurité exigent des séquences d'appels API répétitives, longues à scripter. Avec cette architecture, une seule intégration réutilisable standardise l'accès de l'agent IA à tous les services AWS, tout en conservant une piste d'audit complète via CloudWatch pour les exigences de conformité.

Cette solution s'inscrit dans la montée en puissance du Model Context Protocol, standard ouvert publié par Anthropic en novembre 2024 qui permet aux agents IA de se connecter à des outils externes de façon cohérente. AWS l'a intégré dans Bedrock AgentCore Runtime, sa couche d'orchestration pour agents IA, qui joue ici le rôle de passerelle sécurisée entre Amazon Q et le serveur MCP. L'utilisation d'Amazon Q requiert un abonnement Enterprise au niveau Professional minimum, ce qui cible en priorité les grandes organisations avec une infrastructure AWS significative. La démarche illustre une tendance plus large chez les hyperscalers : positionner leurs assistants IA internes comme interface unique pour opérer l'ensemble du stack cloud, réduisant la dépendance aux outils tiers tout en consolidant la chaîne de valeur autour de leurs propres services.

Dans nos dossiers

Anthropic Agents IA

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

1AWS ML Blog

Intégration d'Amazon Bedrock AgentCore avec Slack

Amazon Bedrock AgentCore permet désormais d'intégrer des agents IA directement dans Slack, éliminant le besoin de basculer entre applications tout en gérant la mémoire conversationnelle, la sécurité et les délais de réponse. La solution repose sur AWS CDK avec trois fonctions Lambda, Amazon API Gateway, SQS et Secrets Manager, tandis que l'agent est conteneurisé et hébergé dans l'AgentCore Runtime via le SDK Strands Agents. L'architecture utilise le protocole MCP (Model Context Protocol) pour l'exécution des outils, et bien que l'exemple soit un agent météo, la couche d'intégration est entièrement réutilisable pour tout cas d'usage métier.

OutilsOutil

1 source

2AWS ML Blog

Amazon Bedrock AgentCore Runtime introduit des capacités MCP client avec état

Amazon a introduit des capacités client MCP (Model Context Protocol) avec état dans son service AgentCore Runtime sur Amazon Bedrock, marquant une évolution majeure pour les développeurs d'agents IA. Jusqu'à présent, les serveurs MCP hébergés sur cette plateforme fonctionnaient en mode sans état : chaque requête HTTP était traitée de façon indépendante, sans mémoire entre les appels. Le nouveau mode avec état, activé via un simple paramètre stateless_http=False, provision une microVM dédiée par session utilisateur, persistant jusqu'à 8 heures ou 15 minutes d'inactivité. Cette architecture permet désormais trois capacités clés du protocole MCP : l'élicitation (demander une saisie utilisateur en cours d'exécution), le sampling (solliciter du contenu généré par un LLM côté client), et les notifications de progression (streamer des mises à jour en temps réel). La continuité de session est assurée via un en-tête Mcp-Session-Id, échangé lors de l'initialisation et inclus dans toutes les requêtes suivantes. Ces nouvelles capacités transforment fondamentalement la nature des workflows agents. Là où les implémentations sans état forçaient les agents à s'exécuter de bout en bout sans interruption, les agents peuvent désormais mener de véritables conversations bidirectionnelles avec leurs clients : s'arrêter pour demander une clarification à l'utilisateur au milieu d'un appel d'outil, déléguer dynamiquement la génération de contenu au LLM présent côté client, ou signaler l'avancement d'opérations longues en temps réel. Pour les équipes qui construisent des assistants IA complexes, des pipelines de traitement de documents ou des agents d'automatisation nécessitant validation humaine intermédiaire, c'est un changement de paradigme concret qui élimine des contournements architecturaux souvent coûteux à maintenir. Le Model Context Protocol, standard ouvert définissant comment les applications LLM se connectent à des outils et sources de données externes, gagne rapidement en adoption depuis son lancement par Anthropic fin 2024. Amazon avait déjà intégré l'hébergement de serveurs MCP sans état dans AgentCore Runtime dans une version précédente ; cette mise à jour complète l'implémentation bidirectionnelle du protocole. L'isolation entre sessions via des microVMs dédiées garantit la sécurité et l'indépendance des contextes, chaque session bénéficiant de CPU, mémoire et système de fichiers séparés. Si une session expire ou que le serveur redémarre, les clients reçoivent une erreur 404 et doivent réinitialiser la connexion. Cette approche positionne AWS comme un acteur central dans l'infrastructure d'agents IA d'entreprise, en rivalité directe avec les offres similaires de Microsoft Azure et Google Cloud dans la course à standardiser les architectures agentiques.

UELes équipes européennes développant des agents IA sur des plateformes cloud peuvent désormais implémenter des workflows agentiques bidirectionnels natifs sans contournements architecturaux coûteux.

OutilsActu

1 source

3AWS ML Blog

Créer un agent FinOps avec Amazon Bedrock AgentCore

Amazon a dévoilé une solution clé en main pour construire un agent FinOps basé sur Amazon Bedrock AgentCore, permettant aux équipes financières de gérer les coûts AWS à travers plusieurs comptes via une interface conversationnelle unique. L'architecture repose sur Claude Sonnet 4.5 d'Anthropic, le Strands Agent SDK et le protocole MCP (Model Context Protocol), déployée via AWS CDK. L'agent consolide les données de trois services AWS — Cost Explorer, Budgets et Compute Optimizer — et propose plus de 20 outils spécialisés couvrant l'intégralité du spectre de la gestion des coûts cloud. La mémoire conversationnelle conserve jusqu'à 30 jours de contexte, permettant des questions de suivi sans répéter les informations préalables. Concrètement, cette solution élimine la nécessité pour les équipes finance et DevOps de naviguer manuellement entre plusieurs consoles AWS pour obtenir une vue consolidée des dépenses. Un responsable peut simplement demander "Quels sont mes principaux postes de dépenses ce mois-ci ?" et obtenir une réponse immédiate, sans requêtes SQL ni exports manuels. L'authentification repose sur Amazon Cognito (gestion des utilisateurs et flux OAuth 2.0 machine-à-machine), tandis qu'AWS Amplify héberge l'interface web. L'accès en langage naturel démocratise la visibilité sur les coûts cloud à l'ensemble de l'organisation, y compris aux profils non techniques — un enjeu majeur dans les entreprises où la facture AWS est souvent opaque pour les décideurs métier. Le FinOps — la pratique de gouvernance financière du cloud — est devenu un domaine à part entière alors que les dépenses cloud des entreprises ont explosé ces cinq dernières années, rendant le suivi des coûts multi-comptes complexe et chronophage. Amazon Bedrock AgentCore, lancé récemment par AWS, est la réponse d'Amazon à la vague d'agents IA d'entreprise : une plateforme d'exécution managée pour déployer des agents LLM avec mémoire, outils et identité gérés nativement. Cette solution illustre parfaitement la stratégie d'AWS de transformer ses propres services (Cost Explorer, Compute Optimizer) en sources de données accessibles via des agents IA, réduisant la friction d'adoption. La concurrence s'intensifie sur ce segment : Microsoft Copilot pour Azure Cost Management et Google Cloud Carbon Footprint poursuivent des ambitions similaires. La prochaine étape logique sera l'automatisation des recommandations d'optimisation, passant d'un agent qui répond à des questions à un agent qui agit directement sur l'infrastructure pour réduire les coûts.

UELes entreprises françaises et européennes utilisant AWS peuvent simplifier leur gestion de coûts cloud multi-comptes via cet agent, sans impact réglementaire ou institutionnel spécifique.

OutilsOutil

1 source

4AWS ML Blog

Déployer des agents vocaux avec Pipecat et Amazon Bedrock AgentCore Runtime – Partie 1

Amazon Web Services et Pipecat ont publié un guide détaillé sur le déploiement d'agents vocaux intelligents en production, s'appuyant sur la nouvelle infrastructure Amazon Bedrock AgentCore Runtime. La solution combine Pipecat, un framework open source spécialisé dans les pipelines audio temps réel, avec l'environnement serverless d'AWS pour permettre des conversations vocales naturelles sur le web, le mobile et la téléphonie. L'architecture prend en charge trois protocoles de transport réseau : WebSockets, WebRTC et l'intégration téléphonique classique. Chaque session de conversation tourne dans des microVMs isolées, avec une capacité de session continue allant jusqu'à 8 heures, et une mise à l'échelle automatique face aux pics de trafic. Le runtime impose l'usage de conteneurs ARM64 (Graviton), ce qui nécessite que les images Docker soient compilées spécifiquement pour l'architecture linux/arm64. Ce que change cette combinaison est significatif pour les équipes qui déploient des agents en production : elle élimine plusieurs problèmes récurrents liés aux architectures vocales temps réel, notamment la gigue audio, les contraintes de montée en charge, et les coûts liés au sur-provisionnement. La facturation à l'usage actif — et non à la capacité réservée — réduit directement les coûts d'infrastructure inactive. Sur le plan technique, la latence reste le défi central : une conversation naturelle exige une réponse inférieure à une seconde de bout en bout. Pour y parvenir, le système mise sur le streaming bidirectionnel à deux niveaux — entre le client et l'agent d'une part, et entre l'agent et les modèles de langage d'autre part. Le choix du modèle est déterminant : AWS recommande Amazon Nova Sonic pour les pipelines speech-to-speech, ou Nova Lite dans une approche en cascade (STT → LLM → TTS), tous deux optimisés pour minimiser le Time-to-First-Token. La plateforme intègre également de l'observabilité native pour tracer le raisonnement de l'agent et ses appels d'outils. Ce premier volet d'une série de publications s'adresse aux développeurs déjà familiers des architectures vocales en cascade et speech-to-speech. Il fait suite à un article précédent d'AWS comparant Amazon Nova Sonic aux approches en cascade, et pose les bases techniques pour les déploiements Pipecat sur AgentCore Runtime.

OutilsTuto

1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour