OutilsAWS ML Blog · 31 juil. 2026, 19:33· 2 min de lecture

Optimiser les agents en production avec Amazon Bedrock AgentCore Observability

Amazon publie la deuxième partie de sa série consacrée à l'observabilité des agents IA construits sur Amazon Bedrock AgentCore, en s'appuyant sur la fonctionnalité AgentCore Observability et sur Amazon CloudWatch. Après un premier volet dédié au débogage des agents défaillants (boucles infinies, erreurs d'invocation d'outils), ce second article s'attaque à un problème différent : les agents qui fonctionnent correctement mais trop lentement, ou dont la consommation mémoire dérive au fil du temps. Les prérequis restent identiques à la partie 1 : un compte AWS avec accès à Bedrock AgentCore, la fonction CloudWatch Transaction Search activée, et un agent déjà déployé. Un exemple concret illustre le problème : trois invocations successives d'un même agent affichent une latence moyenne de 7,5 à 8,2 secondes par span, révélant un goulot d'étranglement systémique plutôt qu'un simple ralentissement ponctuel. Amazon fournit une requête CloudWatch type pour repérer ces cas, filtrant les opérations InvokeAgent dont la latence dépasse 3 000 millisecondes, triées par ordre décroissant et limitées à 50 résultats.

Ce type de dégradation est particulièrement insidieux car il ne déclenche aucune alerte d'erreur : le taux d'échec reste bas, mais les temps de réponse P95 grimpent progressivement, de 2 secondes à 5, puis 10, jusqu'à devenir inutilisables pour un cas d'usage interactif comme un chatbot de service client. Les utilisateurs finissent par abandonner leurs sessions sans que le système ne signale de panne. Pour les entreprises qui déploient des agents en production, cela signifie qu'un monitoring classique basé sur les taux d'erreur ne suffit plus : il faut définir des budgets de performance spécifiques à chaque cas d'usage et surveiller activement la dérive de latence avant qu'elle n'affecte l'expérience utilisateur.

Amazon détaille ensuite une méthode d'analyse en profondeur : une fois une requête lente identifiée par son RequestId, une seconde requête CloudWatch permet de décomposer la chronologie complète de l'exécution, opération par opération. L'exemple fourni montre une trace OpenTelemetry de 17 spans répartis sur trois cycles d'exécution successifs (executeeventloopcycle), où des outils comme customerlookup et order_history s'exécutent l'un après l'autre au lieu d'être parallélisés, chaque cycle attendant la fin du précédent. Ce schéma séquentiel démultiplie la latence à chaque nouvel appel d'outil. Les causes les plus fréquentes identifiées par Amazon incluent la récupération de mémoire, l'invocation d'outils, la génération de tokens, et l'absence de parallélisation des opérations indépendantes, un diagnostic également accessible via des requêtes CloudWatch ciblées sur la latence spécifique de récupération mémoire.

Dans nos dossiers

AWS Agents IA

Cet article vous a été utile ?

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

À lire aussi

1AWS ML Blog

Amazon Bedrock AgentCore Observability : déboguer les agents en production

Amazon vient de détailler le fonctionnement d'AgentCore Observability, un outil intégré à sa plateforme Bedrock destiné à déboguer les agents d'intelligence artificielle en production. Contrairement aux applications traditionnelles qui génèrent des erreurs explicites, les agents IA échouent souvent en silence : ils peuvent retourner des réponses plausibles mais incorrectes, entrer dans des boucles de raisonnement infinies, ou sélectionner de mauvais outils sans déclencher la moindre alerte. AgentCore Observability répond à ce problème en exposant trois couches d'instrumentation : des métriques agrégées, des traces d'exécution pas à pas, et des journaux structurés. L'outil permet de suivre chaque étape de raisonnement de l'agent, d'inspecter les appels d'outils, et de localiser précisément où l'exécution dévie des attentes, même en l'absence d'erreur explicite. Le service s'appuie sur Amazon CloudWatch et nécessite l'activation de la fonctionnalité CloudWatch Transaction Search. L'enjeu est considérable pour les équipes qui déploient des agents en production : jusqu'ici, un monitoring classique pouvait afficher 100 % de succès d'exécution pendant que les utilisateurs recevaient de fausses informations. AWS identifie trois grandes familles de défaillances. Les problèmes de qualité regroupent les hallucinations, les erreurs factuelles, et les erreurs de raisonnement : un agent peut citer des politiques inexistantes ou répéter un calcul erroné. Dans les architectures multi-agents, ces erreurs se propagent en cascade lorsque la sortie d'un agent alimente l'entrée d'un autre. Les problèmes de fiabilité couvrent les échecs d'appels d'outils (erreurs 401, 403, 400), les pertes de contexte de session, et les workflows incomplets. Enfin, les problèmes d'efficacité affectent les coûts et les performances sans nécessairement compromettre l'exactitude : latence excessive, consommation de tokens gonflée par des réponses trop verbeuses ou des appels d'outils répétés faute de mise en cache. Ce lancement s'inscrit dans la course que mènent les grands fournisseurs cloud pour rendre les agents IA opérationnellement viables en entreprise. AWS, Microsoft Azure et Google Cloud investissent massivement dans des couches d'observabilité spécifiques aux LLMs, un segment qui n'existait pas il y a deux ans. La complexité croissante des architectures agentiques, où plusieurs modèles coopèrent et s'enchaînent, rend l'observabilité traditionnelle insuffisante. AgentCore Observability est présenté comme une première partie d'une série en deux volets : une seconde publication couvrira l'optimisation des performances et la gestion de la mémoire. La direction prise par AWS suggère que l'outillage autour des agents autonomes va devenir un différenciateur clé des plateformes cloud dans les prochains mois.

UELes entreprises européennes déployant des agents IA sur AWS Bedrock peuvent adopter immédiatement cet outil pour détecter les défaillances silencieuses en production, un manque opérationnel réel pour les équipes MLOps.

OutilsOutil

1 source

2AWS ML Blog

Détecter les défaillances silencieuses d'agents grâce à l'optimisation d'Amazon Bedrock AgentCore

Amazon a présenté une nouvelle fonctionnalité d'observabilité pour Amazon Bedrock AgentCore, baptisée insights, conçue pour détecter les défaillances silencieuses des agents d'intelligence artificielle déployés en production. Le problème que cible ce nouvel outil est bien connu des équipes qui opèrent des agents IA à grande échelle : les tableaux de bord affichent des indicateurs au vert, un taux de complétion de 99%, une latence normale et aucun pic d'erreur, alors même que des clients signalent des résultats incorrects. Amazon cite plusieurs exemples concrets : une modification de commande jamais réellement exécutée, un produit annoncé comme disponible alors que l'API d'inventaire avait expiré, ou encore une étape de validation silencieusement sautée. Ces défaillances comportementales n'apparaissent dans aucun signal d'erreur classique et ne remontent souvent que plusieurs semaines plus tard, via les réclamations clients. Le système analyse chaque trace de session à l'aide d'une taxonomie structurée couvrant onze catégories de défaillances, dont l'hallucination et les réponses incorrectes. Cette évolution répond à un enjeu très concret pour les entreprises qui déploient des agents IA à grande échelle : au delà de la simple détection d'erreurs, il devient essentiel de prioriser les correctifs. Quand un agent traitant des milliers de sessions quotidiennes accumule des centaines d'erreurs, l'examen individuel de chaque trace ne permet pas de savoir si l'on est face à un problème systémique touchant 30% du trafic ou à un cas isolé concernant trois sessions seulement. AgentCore insights regroupe les sessions par clusters, classés selon la proportion de sessions affectées, avec une explication agrégée pour chaque groupe de défaillances, exploitable sans avoir à rouvrir chaque trace individuellement. L'outil propose aussi une analyse de l'intention des utilisateurs, révélant les écarts entre les requêtes réellement adressées à l'agent et sa conception initiale, ainsi que des insights d'exécution montrant les stratégies effectivement employées par l'agent en conditions réelles. Cette annonce s'inscrit dans une tendance plus large du secteur : à mesure que les agents IA autonomes se multiplient en production, les outils d'observabilité traditionnels, pensés pour l'infrastructure logicielle classique, montrent leurs limites face à des défaillances de nature comportementale plutôt que technique. Amazon positionne ainsi AgentCore insights comme une couche complémentaire à la pile d'observabilité existante, exploitant les données de traces déjà collectées plutôt que d'exiger une nouvelle instrumentation. L'enjeu dépasse la seule correction de bugs : il s'agit de combler l'écart entre le comportement prévu d'un agent et son comportement réel une fois confronté à des utilisateurs et des cas d'usage imprévus, un défi appelé à prendre de l'ampleur à mesure que les entreprises industrialisent le déploiement d'agents IA autonomes dans leurs processus métier.

OutilsOutil

1 source

3AWS ML Blog

Analyser AWS Health en libre-service avec les agents IA d'Amazon Bedrock

Amazon Web Services a présenté Chaplin, acronyme de Customer Health and Planned Lifecycle Intelligence Nexus, une solution open source conçue pour transformer la gestion des notifications de santé d'infrastructure cloud. Disponible sur GitHub avec des instructions de déploiement détaillées, Chaplin repose sur Amazon Bedrock et le Model Context Protocol (MCP) pour offrir une analyse en langage naturel des événements AWS Health. Concrètement, une équipe d'exploitation peut interroger directement son assistant IA depuis Claude Code ou Kiro CLI pour obtenir, par exemple, la liste des événements RDS à venir dans les 60 prochains jours, un résumé des retraits d'instances EC2 classés par urgence, ou les correctifs de sécurité affectant les environnements de production, sans avoir à attendre une réponse humaine. Le problème auquel répond Chaplin est réel et coûteux pour les grandes organisations. Un lundi matin type, une équipe opérationnelle peut recevoir simultanément des alertes sur la fin de vie d'Amazon Linux 2, des dépréciations de versions RDS et des retraits d'instances EC2 répartis sur plus de 50 comptes AWS. Sans outil d'analyse centralisé, les équipes dépendaient jusqu'ici de leurs Technical Account Managers (TAMs) pour interpréter ces événements et évaluer leur impact métier, ce qui créait des goulots d'étranglement dans la prise de décision. Les tableaux de bord BI classiques, figés dans des schémas prédéfinis, ne permettaient pas de répondre à des questions dynamiques ou contextuelles. Le résultat : du temps perdu en réaction plutôt qu'en anticipation, et des migrations ou maintenances planifiées trop tard. Chaplin s'inscrit dans un mouvement plus large d'adoption du Model Context Protocol comme standard d'interopérabilité entre outils IA et systèmes d'entreprise. Parce qu'il repose sur MCP, Chaplin peut être combiné avec d'autres outils compatibles comme JIRA, GitHub ou ServiceNow, permettant aux équipes DevOps, sécurité et opérations d'agir directement depuis leur flux de travail habituel. AWS prévoit également de lier prochainement les événements Health éligibles aux templates AWS Transform, ce qui permettra aux clients de passer directement de l'alerte à l'action corrective. Chaplin est conçu pour prioriser et remonter ces événements actionnables en premier. La solution illustre une tendance de fond : déléguer aux agents IA non plus seulement l'analyse de données, mais la coordination opérationnelle dans des environnements cloud complexes et multi-comptes.

OutilsOutil

1 source

4AWS ML Blog

Créer des agents multi-locataires avec Amazon Bedrock AgentCore

Amazon a lancé Bedrock AgentCore, un service managé et serverless conçu pour permettre aux éditeurs de logiciels SaaS de déployer des applications agentiques en environnement multi-tenant sur AWS. Le service offre des primitives pour héberger des agents et des serveurs MCP (Model Context Protocol), avec une gestion intégrée des identités, de la mémoire, de l'observabilité et des évaluations. Le coeur de son architecture repose sur des microVMs isolées par session: chaque session client obtient son propre environnement d'exécution éphémère, avec un système de fichiers persistant propre, sans le coût ni la latence d'une machine virtuelle complète. Le contexte du tenant transite via des en-têtes HTTP personnalisés, portant l'identifiant du tenant, son niveau de service, ses préférences régionales et ses droits d'accès aux outils, ce qui permet à l'agent d'adapter dynamiquement son comportement sans logique de routage codée en dur. Cette approche répond directement au fossé qui sépare un prototype fonctionnel d'un déploiement en production dans un contexte SaaS. Les architectes d'applications agentiques devaient jusqu'ici résoudre manuellement six problèmes distincts: l'isolation des tenants, la propagation de leur identité, l'observabilité par tenant, l'isolation des données, l'attribution des coûts et la mitigation du "noisy neighbor" (un tenant monopolisant les ressources au détriment des autres). AgentCore propose trois patterns d'isolation, appelés Silo, Pool et Bridge, chacun offrant un compromis différent entre protection stricte et mutualisation des coûts. Pour les éditeurs gérant des centaines ou des milliers de clients sur une même plateforme, cette capacité à choisir un modèle d'isolation par segment tarifaire change concrètement l'équation économique et de conformité. Le lancement s'inscrit dans une course des grands fournisseurs cloud à imposer leurs infrastructures agentiques comme standard de facto pour la prochaine génération d'applications IA. AWS fait face à la concurrence directe de Google avec Vertex AI Agent Builder et de Microsoft avec Azure AI Agent Service, tous trois cherchant à capter les équipes d'ingénierie qui passent de l'expérimentation à la production. L'article publié par AWS est le premier d'une série, ce qui suggère que d'autres composants d'AgentCore (évaluation, fine-tuning par tenant, facturation granulaire) seront détaillés dans les prochaines semaines. La question centrale pour les équipes SaaS reste le degré de lock-in accepté en échange de la simplicité opérationnelle qu'offre un service pleinement managé.

UELes éditeurs SaaS européens construisant sur AWS peuvent exploiter les patterns d'isolation et les préférences régionales d'AgentCore pour satisfaire les exigences de résidence des données imposées par le RGPD.

OutilsOpinion

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

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic