AWS supprime l’infrastructure des agents, mais le crochet reste

AWS a livré deux éléments constamment confondus : l’Agent Toolkit, qui met entre les mains d’un agent de codage IA 300 services et 15 000 actions d’API, et Bedrock AgentCore, la plateforme d’exploitation avec runtime serverless pour les agents en production. Les deux éliminent des semaines, voire des mois de travail d’infrastructure. Le prix ne figure pas sur la facture, il se trouve dans l’architecture.

Les points clés en bref

• Deux produits, une confusion : L’Agent Toolkit connecte votre agent développeur à AWS, AgentCore fait ensuite fonctionner les agents en serverless. Qui les confond évalue le mauvais outil.
• L’infrastructure est l’offre réelle : L’isolation des sessions, la mémoire, l’identité et l’observabilité sont habituellement construits par chaque équipe. AgentCore les regroupe en modules prêts à l’emploi et élimine ainsi la partie la plus fastidieuse.
• Ouvert en haut, lié en bas : Les frameworks comme LangGraph ou CrewAI restent portables. La couche d’exploitation sous-jacente, elle, est AWS. C’est précisément là que naît l’engagement que l’on ressent par la suite.

En lien :Cursor Cloud-Agents : coder même quand l’ordinateur portable est éteint  /  Instances réservées : le taux de couverture qui ne prouve rien

Deux outils constamment confondus

La plupart des confusions lors de la première phase d’architecture proviennent du fait que deux annonces partagent le même prénom. L’un s’appelle Agent Toolkit for AWS, l’autre Amazon Bedrock AgentCore. Ils résolvent des problèmes différents et interviennent à des étapes distinctes.

Qu’est-ce que l’Agent Toolkit for AWS ? Un ensemble composé d’un serveur MCP, de compétences sélectionnées et de plugins, qui offre aux agents de codage IA comme Claude Code, Cursor ou Codex un accès sécurisé et auditable à AWS. Le serveur MCP couvre plus de 300 services et plus de 15 000 actions d’API, auxquels s’ajoutent des scripts exécutés en sandbox et un accès en temps réel à la documentation actuelle.

Le Toolkit aide donc à construire. Il donne à l’agent, qui écrit votre code, les moyens d’accéder aux logs CloudWatch, au statut CloudFormation et aux procédures de dépannage. Aucun coût supplémentaire n’est facturé, vous ne payez que les ressources AWS que l’agent utilise réellement.

AgentCore commence là où le Toolkit s’arrête : au niveau du runtime pour l’exploitation. Une fois l’agent construit et prêt à gérer des sessions utilisateurs, il s’exécute ici, en serverless, avec des sessions isolées et une mémoire persistante. Ensemble, ces deux produits forment une chaîne allant du premier prompt jusqu’au trafic de production. Évalués séparément, ils ont du sens. Mélangés, ils conduisent à une liste d’exigences qui ne correspond à rien de précis.

Ce que l’infrastructure sous-jacente épargne au développeur

La partie la plus honnête de l’offre est aussi la plus invisible. Toute équipe ayant déployé un agent en production connaît la liste des éléments que personne ne veut développer, mais que tout le monde doit implémenter. AgentCore décompose précisément cette liste en modules prêts à l’emploi. Voici les sept qui transforment le quotidien :

• Runtime : environnement serverless à faible latence avec isolation des sessions, ouvert à tous les frameworks.
• Memory : contexte à court terme par session et connaissances à long terme via extraction sémantique.
• Identity : accès sécurisés de l’agent aux services AWS et aux outils tiers comme GitHub, Salesforce ou Slack.
• Gateway : transforme les API existantes et les fonctions Lambda en outils exploitables par l’agent via MCP.
• Observability : suivi pas à pas de l’exécution avec intégration OpenTelemetry.
• Browser : instances de navigateur gérées pour l’automatisation web à grande échelle.
• Code Interpreter : environnement isolé pour le code généré par l’agent.

Ceux qui ont déjà dû tout mettre en place manuellement en perçoivent immédiatement la valeur. La gestion des sessions, le courtage d’identité et une couche mémoire qui ne se brise pas à chaque déploiement peuvent coûter des semaines, voire des mois, à une petite équipe. Un temps rarement consacré au produit, mais presque toujours à du bricolage technique. Nous avons nous-mêmes écrit ce manuel de bricolage une fois de trop.

Un exemple rend la différence tangible. Le Gateway prend une fonction Lambda existante ou une API REST interne et en fait un outil que l’agent peut appeler via le Model Context Protocol. Auparavant, cela signifiait : créer manuellement un adaptateur, une description de schéma et une couche d’authentification pour chaque fonction. Désormais, il suffit d’une simple inscription. Cela peut sembler anodin, mais multiplié par une douzaine d’outils, cela représente exactement le type de travail que personne ne veut voir figurer dans le sprint planning. Identity fonctionne de manière similaire : au lieu de stocker les clés pour GitHub ou Salesforce dans des variables d’environnement, le composant gère l’accès en temps réel. Moins de code, moins de surface d’attaque.

Là où se joue l’équation : l’engagement plutôt que les frais

Un deuxième regard vaut le coup. AWS vend de l’ouverture, et c’est même vrai. AgentCore supporte CrewAI, LangGraph, LlamaIndex, Strands et vos propres frameworks. Votre code d’agent n’est donc pas enfermé. Ce que vous pourriez porter, c’est la logique.

Ce que vous ne portez pas, c’est la couche d’exploitation. Runtime, Gateway, Identity et Memory sont propres à AWS. Dès que votre agent tourne en production sur cette base, la manière dont il est déployé, authentifié et surveillé dépend de cette stack. L’engagement se situe un niveau plus bas que le framework, précisément dans la partie que vous venez de vous faire épargner.

Ce n’est pas un argument contre AWS. C’est le modèle habituel de toute plateforme managée. La question est simplement de savoir si l’on achète cet engagement en toute conscience ou si on le récupère comme effet secondaire d’un prototype rapide. La différence entre les deux équivaut à peu près à un audit.

Quand le saut en vaut la peine

Pour la majorité des équipes qui planifient aujourd’hui leur premier agent en production, l’échange est équitable. Ceux qui n’exploitent pas encore leur propre couche Memory et Identity gagnent plus de temps qu’ils ne perdent en flexibilité. Cet avantage compte tant que le cas d’usage n’est pas encore prouvé.

La donne change si le multi-cloud est déjà une exigence ou si la résidence des données et la souveraineté sont strictement régulées. La couche d’exploitation devient alors une décision stratégique que l’on ne prend pas à la légère. Dans ce cas, il est judicieux de comparer avec un auto-hébergement propre au framework avant que le premier agent de production ne soit déployé sur AgentCore.

Concrètement, cela signifie : prototyper sur la stack managée, puis prendre la décision architecturale avant le déploiement en production. Ceux qui utilisent la boîte à outils pour construire et ne fixent le runtime qu’après un calcul sobre des coûts de verrouillage obtiennent le meilleur des deux mondes. Ceux qui inversent l’ordre laissent le prototype dicter l’architecture. Cela fonctionne un temps, mais devient coûteux précisément quand on a le moins de temps pour une migration.

Foire aux questions

Plus d’articles du réseau MBF Media

Source de l’image : générée par IA (Juli 2026)