Agent IA en production : que déléguer à Bedrock AgentCore ?

Amazon Bedrock AgentCore mérite un pilote lorsque votre agent IA fonctionne, mais que l’infrastructure qui l’entoure devient un produit à part entière. L’offre actuelle d’AWS compte 13 services et fonctionnalités modulaires. Retenez ceux qui vous déchargent d’une tâche d’exploitation précise ; le comportement métier de l’agent reste sous votre responsabilité.

Informations vérifiées dans la page produit et la documentation AWS en ligne le 30 octobre 2026. L’inventaire des composants ci-dessous provient de la présentation destinée aux développeurs, accessible depuis la page produit AgentCore. L’analyse de ce que ces composants peuvent remplacer est celle de cet article.

Amazon Bedrock AgentCore, qu’est-ce que c’est ?

AgentCore permet de confier à AWS certaines tâches nécessaires à l’exploitation d’agents en production. Un agent est un logiciel qui s’appuie sur un modèle pour choisir des actions, appeler des outils et accomplir une tâche. Faire fonctionner cette boucle en local laisse encore beaucoup à faire : gestion des identités, exécution, état, contrôle d’accès et débogage.

Imaginez une salle de concert. Le comportement de votre agent, c’est le spectacle. Runtime fournit la scène et l’infrastructure technique ; les contrôles d’accès régissent les entrées ; la mémoire conserve le contexte utile ; l’observabilité enregistre ce qui s’est passé. À vous de définir ce que le spectacle doit accomplir et de juger s’il a atteint son objectif.

AWS présente explicitement AgentCore avec la formule « Any framework. Any model. », soit « Tout framework. Tout modèle. ». Sa page produit cite LangChain, OpenAI Agents SDK, Claude Agent SDK, Strands SDK et la possibilité d’utiliser votre propre framework. Il s’agit du périmètre annoncé par AWS pour la plateforme. Cela ne garantit ni des intégrations identiques pour toutes les fonctionnalités optionnelles, ni une migration sans effort. Présentation produit AWS.

La responsabilité de la boucle d’exécution fait aussi l’objet d’un choix distinct. Avec Runtime, vous déployez le code de votre agent. Avec Harness, vous décrivez l’agent par sa configuration et utilisez la boucle gérée par AWS, qui repose sur Strands Agents, le framework d’agents open source d’AWS. La documentation de Harness explicite cette distinction. Un responsable technique dont le code d’orchestration fonctionne déjà devrait commencer par évaluer Runtime.

Bedrock Agents ou AgentCore : comment choisir ?

L’arrivée d’AgentCore ne justifie pas, à elle seule, la migration d’un déploiement Amazon Bedrock Agents existant. AWS indique que les utilisateurs actuels de Bedrock Agents peuvent continuer à l’utiliser. AgentCore mérite d’être étudié lorsqu’un besoin précis appelle ses capacités d’exécution, d’intégration ou d’exploitation. FAQ AWS.

La distinction utile ne se résume plus à opposer « boucle gérée » et « infrastructure » : AgentCore propose lui aussi une boucle gérée, avec Harness. Déterminez d’abord si vous souhaitez garder la maîtrise du code d’orchestration, puis choisissez la voie adaptée. Gardez à portée de main la vue d’ensemble de l’architecture des agents IA, pour qu’un choix d’hébergement ne vous conduise pas, par inadvertance, à revoir toute l’application.

Quels composants AgentCore choisir pour votre agent IA ?

Choisissez les composants en fonction de ce que vous devriez autrement développer et exploiter vous-même. AWS les décrit comme des fonctionnalités modulaires, utilisables ensemble ou séparément. La dernière colonne précise les responsabilités qui restent du côté de l’application, même lorsque le service sous-jacent est fourni par AWS.

Un assistant de support peut avoir immédiatement besoin de Runtime, Gateway et Identity, puis de Memory lorsque le contexte des clients qui reviennent devient utile. Payments n’a aucun rôle à jouer si l’assistant n’achète jamais l’accès à une ressource externe. Registry devient pertinent quand retrouver les ressources approuvées dans l’organisation pose problème. Multiplier les composants n’est pas un objectif en soi.

Code Interpreter et Runtime répondent à des besoins différents. Runtime héberge l’agent ; Code Interpreter fournit un bac à sable pour le code qu’il exécute. Si votre seul besoin manquant est l’exécution de code isolée, étudiez les options du guide des bacs à sable de code pour agents IA avant de déplacer votre orchestration.

Les choix d’architecture qui restent à votre charge

La frontière à tracer sépare l’infrastructure gérée du pouvoir de décision de l’application. Prenons un workflow de support : l’agent pourrait lire une commande, en expliquer l’état et proposer une action. AWS peut fournir l’infrastructure d’exécution et d’accès, mais c’est à votre application d’établir à qui appartient la commande et si l’action est autorisée.

Runtime : isoler une session ne dit pas à qui elle appartient

Runtime peut isoler l’exécution sans savoir à quel client appartient une session. AWS décrit des environnements microVM dédiés aux sessions, qui séparent les ressources de calcul, de mémoire et de système de fichiers. Cette même documentation précise qu’AgentCore ne fait pas respecter les associations entre sessions et utilisateurs : le backend de votre application cliente doit maintenir ce lien. Sessions Runtime.

Pour l’assistant de support, un identifiant de session envoyé par le navigateur ne prouve pas que cette session appartient au client. Authentifiez la requête, déterminez dans votre backend quelle session est autorisée et limitez les accès en aval à ce client. L’isolation assurée par l’infrastructure et la décision d’autorisation prise par l’application relèvent de responsabilités distinctes.

Memory : décider ce qui mérite d’être conservé

Memory prend en charge l’infrastructure de gestion du contexte ; vous décidez de son contenu. AWS propose un contexte conversationnel à court terme et des informations conservées à long terme, d’une session à l’autre. Documentation de Memory.

Retenir qu’un client préfère les réponses concises n’a pas le même rôle que conserver le solde d’une commande faisant foi. Les données métier de référence doivent rester dans votre application. Définissez comment l’agent récupère des données à jour, quels éléments de la conversation il peut conserver et ce qui se passe lorsqu’une préférence mémorisée devient erronée. Un service de mémoire ne tranche pas ces choix de conception des données à votre place.

Gateway et MCP : connecter l’agent à ses outils

Gateway est utile lorsque la connexion aux outils devient un travail d’ingénierie répétitif. Model Context Protocol, ou MCP, est une interface commune permettant de rendre des outils accessibles aux agents. Gateway peut transformer des API et des fonctions AWS Lambda en outils compatibles MCP, et se connecter à des serveurs MCP existants. Sa documentation actuelle couvre également le routage vers d’autres agents et modèles. Documentation de Gateway.

Pour un assistant de suivi des commandes, commencez par exposer une opération ciblée, comme la consultation de l’état d’une livraison, avant de donner accès à un outil généraliste de requête en base de données. Gateway peut acheminer l’appel ; votre API reste responsable du sens de l’opération, des données auxquelles elle peut accéder et du risque qu’une nouvelle tentative répète un effet de bord.

Identity : les identifiants d’accès ne suffisent pas sans règles métier

Identity gère l’identité de celui qui agit et ses identifiants d’accès ; Policy régit les actions autorisées au niveau de Gateway. Identity fournit une identité aux charges de travail et gère les identifiants nécessaires pour accéder aux ressources AWS et aux services tiers, y compris pour agir au nom d’un utilisateur. Documentation d’Identity.

Policy évalue le trafic qui passe par un AgentCore Gateway associé avant d’autoriser l’accès aux outils. Cette frontière est essentielle : une règle appliquée à Gateway ne régit pas nécessairement un appel réseau direct que l’agent peut effectuer en dehors de celui-ci. Faites passer les opérations sensibles par le point de contrôle prévu et limitez les possibilités de contournement. Documentation de Policy.

Une identité dédiée au support client peut être autorisée à consulter une commande tout en ayant l’interdiction d’effectuer un remboursement. Les instructions du modèle doivent décrire ce workflow ; les couches d’outils et d’autorisation doivent en faire respecter les permissions.

Observability : une trace montre ce qui s’est passé, pas si l’objectif est atteint

Observability aide à reconstituer le comportement de l’agent ; Evaluations aide à l’évaluer. AgentCore fournit des vues d’exécution et une télémétrie compatible avec OpenTelemetry, un format standard pour les traces et les métriques, ainsi que des tableaux de bord s’appuyant sur Amazon CloudWatch. AWS distingue les métriques intégrées des traces et métadonnées métier supplémentaires que vous instrumentez dans votre application. Documentation d’Observability.

Pour l’assistant de support, enregistrez si la consultation de commande demandée a abouti et si une action a été approuvée. Un appel d’outil techniquement réussi peut tout de même répondre à la mauvaise question métier.

Evaluations propose des évaluations intégrées et personnalisées, y compris avec un modèle comme juge. Définissez vos propres cas représentatifs et examinez les échecs aux conséquences importantes. La documentation des évaluations précise les frameworks et les modalités d’instrumentation pris en charge. Vérifiez le parcours que vous avez choisi, sans étendre à chaque fonctionnalité la promesse générale de compatibilité de la plateforme.

Les limites techniques à intégrer dans votre conception

Distinguez la durée de vie des ressources de calcul de celle de l’état à conserver. La documentation actuelle d’AWS sur le cycle de vie indique un délai d’inactivité par défaut de 15 minutes et une durée de vie maximale des ressources de calcul d’une microVM de 8 heures. Instances, l’option qui utilise de la capacité Amazon Elastic Compute Cloud gérée dans votre compte, permet de configurer une durée allant jusqu’à 14 jours, selon les paramètres de son fournisseur de capacité. Paramètres du cycle de vie, Instances.

Une session logique peut reprendre sur des ressources de calcul nouvellement provisionnées. Par défaut, l’état en mémoire et sur le système de fichiers local dépend du cycle de vie de ces ressources. Un stockage de session configuré peut conserver les données du système de fichiers entre les arrêts et les reprises. Déterminez explicitement ce qui doit survivre à une interruption. Cycle de vie et stockage des sessions.

Avant d’arrêter votre choix de fonctionnalités, consultez la matrice de disponibilité par région AWS. La mention « disponible sur AWS » ne suffit pas pour une application liée à une région précise.

Quand AgentCore vaut-il le détour ?

Lancez-vous lorsqu’un manque opérationnel précis bloque la livraison et que le composant géré correspondant répond à vos exigences. Évaluez le choix selon l’isolation de l’exécution, le contrôle d’accès aux outils, la conservation de l’état, la possibilité de diagnostiquer les problèmes et la charge que représente l’exploitation de ces capacités en interne.

Pour les développeurs, un pilote se justifie lorsque la logique de l’agent fonctionne déjà, mais que l’hébergement ou l’intégration des outils retarde sa mise en service. Garder votre boucle existante sur Runtime permet une expérimentation plus ciblée que de changer à la fois le framework et la plateforme de déploiement.

Pour les équipes d’exploitation, l’intérêt grandit lorsque chaque agent a besoin des mêmes mécanismes de gestion des identifiants, de contrôle d’accès et d’investigation des incidents. Choisissez un workflow qui permette de vérifier ces responsabilités, y compris face à un échec qu’il faudra diagnostiquer.

Pour les décideurs techniques, la question est de savoir quelles tâches récurrentes disparaissent et quel travail d’intégration reste à accomplir. Il faut toujours désigner les personnes responsables de la configuration AWS, de la conception des permissions, du comportement de l’application et des interventions d’astreinte.

Attendez si votre stack fournit déjà les contrôles nécessaires et qu’aucun problème concret ne reste à résoudre. Une migration devrait alors avoir une autre justification, par exemple une capacité que votre stack ne peut pas fournir. Vous n’êtes pas concerné si le workflow suit une séquence fixe d’opérations connues et n’a pas besoin qu’un agent choisisse l’action suivante.

Si le budget détermine votre choix, consultez les tarifs AgentCore d’AWS ainsi que le guide des tarifs Amazon Bedrock du site.

Réaliser un premier pilote avec la CLI AWS

Partez du modèle de projet AWS fondé sur du code, puis ajoutez une opération métier représentative. Ce parcours suit le guide de démarrage rapide de Runtime et le guide complet de la CLI dans leur version actuelle. Il est tiré de la documentation ; le déploiement n’a pas été testé pour cet article.

Le guide complet exige Node.js 20.12 ou une version ultérieure, npm, Python 3.10 ou une version ultérieure, le gestionnaire de dépendances Python uv, des identifiants AWS configurés, les permissions de déploiement et l’accès aux modèles. Ce modèle de projet utilise CodeZip : Docker n’est donc pas nécessaire.

1. 1

   Installer et créer le projet

   Utilisez un compte ou un environnement AWS de développement.

   npm install -g @aws/agentcore
   agentcore --version
   agentcore create --name MyProject --template agent-python-strands

   Le modèle de projet comprend un Runtime nommé agent et une ressource AgentCore Memory. Examinez les deux dans la configuration générée.

2. 2

   Tester en local

   cd MyProject
   agentcore dev --mode browser

   Testez l’agent dans l’inspecteur local, puis arrêtez le serveur avant de poursuivre dans le même terminal.

3. 3

   Compiler, déployer et invoquer l’agent

   agentcore build
   agentcore deploy
   agentcore status
   agentcore invoke --runtime agent --payload '{"prompt":"Hello, what can you do?"}'

   Le déploiement provisionne les ressources AWS au moyen d’AWS Cloud Development Kit, ou CDK.

4. 4

   Examiner les traces, puis nettoyer

   agentcore logs runtime
   agentcore traces runtime list

   Depuis le répertoire de ce projet pilote, ces commandes suppriment ses ressources et démantèlent la stack déployée :

   agentcore remove all --yes
   agentcore deploy --yes

Avant d’envoyer du trafic de production, remplacez le message d’accueil par une tâche délimitée, comme la consultation d’une commande de test. Les vérifications d’acceptation recommandées dépendent de l’application : renvoi des bonnes données, rejet des accès non autorisés, visibilité d’un appel d’outil en échec dans la trace et compréhension de la reprise après interruption. Ce sont des critères de décision pour votre pilote, pas des promesses de performances d’AWS.

Ce que les promesses ne doivent pas faire oublier

Une exécution gérée ne garantit pas qu’un agent prenne les bonnes décisions métier. L’hébergement, les traces, l’évaluation et l’application des règles répondent à des problèmes différents. Aucun de ces services ne vous dispense de choisir une tâche utile, de définir les actions acceptables et d’examiner les échecs.

« Any framework », c’est-à-dire « tout framework », ne doit pas non plus devenir « aucune intégration à prévoir ». La souplesse de la plateforme vous laisse la responsabilité de valider les dépendances, l’authentification, l’instrumentation et les contrats de chaque service adopté.

Enfin, adopter tous les composants ne prouve pas qu’un agent est prêt pour la production. Un assistant de support en lecture seule ne devient pas meilleur parce qu’on lui donne le droit de payer ou un navigateur dont il n’a pas besoin. Ajoutez des capacités lorsqu’une tâche concrète l’exige et incluez l’élargissement des permissions dans la revue.

Par quoi commencer lundi ?

Choisissez une tâche déjà confiée à un agent et notez la responsabilité d’exploitation qui retarde sa mise en service. Testez uniquement les capacités AgentCore nécessaires pour lever ce frein. Comparez le déploiement obtenu, la gestion des échecs et la charge qui reste à votre équipe avec votre stack actuelle. Élargissez l’adoption lorsque les résultats le justifient.

Recevez dans la newsletter des guides pratiques pour développer et exploiter des systèmes d’IA.