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

Amazon Bedrock AgentCore au service des stratégies de vente par agents IA

AWS a déployé en interne un assistant conversationnel baptisé Field Advisor, construit sur Amazon Bedrock AgentCore, pour résoudre un problème concret apparu dans ses propres équipes commerciales mondiales : la prolifération d'agents IA spécialisés sans coordination centrale. L'organisation AWS Sales utilisait plus de 20 agents distincts couvrant la gestion CRM, la planification de réunions, les recommandations produits, les analyses clients et les vérifications de conformité. Les représentants commerciaux devaient eux-mêmes choisir quel agent invoquer selon la tâche, gérer les changements de contexte entre systèmes fragmentés et assembler manuellement les résultats, une charge cognitive qui réduisait d'autant le temps passé avec les clients. Field Advisor agit comme une couche d'orchestration centrale : les commerciaux posent leurs questions en langage naturel, et le système route automatiquement les requêtes vers l'agent ou l'outil approprié, maintient le contexte conversationnel entre les interactions et livre une réponse unifiée via une interface unique. L'impact est concret pour les équipes de vente : Field Advisor s'intègre directement dans les outils déjà utilisés au quotidien, systèmes CRM, Slack, applications internes, évitant toute rupture de flux de travail. Le système inclut des mécanismes de validation humaine pour les opérations sensibles : avant de modifier des données CRM, il présente les changements proposés et attend une approbation explicite, ce qui préserve la fiabilité des données et la responsabilité des commerciaux. La mémoire persistante, combinant historique de session à court terme et mémoire sémantique à long terme, permet aux représentants de reprendre une conversation là où elle s'était arrêtée sans avoir à répéter le contexte à chaque interaction. L'ensemble de ces fonctionnalités réduit la charge opérationnelle et libère du temps pour les échanges à valeur ajoutée avec les clients. Ce projet illustre un défi structurel qui émerge dans de nombreuses grandes entreprises à mesure que l'adoption des agents IA s'accélère : la multiplication d'agents spécialisés crée paradoxalement une nouvelle complexité si aucune orchestration ne les unifie. AWS a choisi Bedrock AgentCore précisément pour ses capacités natives à l'échelle enterprise, environnements d'exécution isolés pour les opérations multi-locataires sécurisées, passerelle unifiée pour les outils et agents répartis sur plusieurs comptes AWS, propagation d'identité cohérente via OAuth et observabilité intégrée sur les flux complexes. En s'appuyant sur une infrastructure clé en main plutôt que sur du développement sur mesure, l'équipe d'ingénierie a pu concentrer ses efforts sur la logique métier plutôt que sur les fondations techniques. Field Advisor représente ainsi autant un cas d'usage commercial qu'une démonstration de la viabilité d'AgentCore comme substrat pour des déploiements agentiques en production à grande échelle.

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.

💬 Selon Le Fil IA, le vrai piège des agents IA en prod, c'est qu'ils dégradent sans jamais planter : le taux d'erreur reste plat pendant que la latence P95 grimpe de 2 à 10 secondes, et personne ne le voit venir avant que les utilisateurs se cassent. L'exemple d'AWS est parlant, des appels d'outils exécutés en séquence au lieu d'être parallélisés, ça multiplie la latence sans qu'aucune alerte se déclenche. Bon, sur le papier l'outillage CloudWatch est bien pensé, mais ça confirme surtout un truc qu'on sous-estime encore trop : monitorer un agent, c'est plus proche du monitoring de perf que du monitoring d'erreurs, et la plupart des équipes ne sont pas encore équipées pour ça.

Cohere Health numérise ses politiques cliniques avec Amazon Bedrock AgentCore

Cohere Health, entreprise spécialisée dans l'intelligence clinique au service des plans de santé américains, a développé une plateforme baptisée Cohere Policy Studio en s'appuyant sur Amazon Bedrock AgentCore, le service d'infrastructure agentique d'AWS. L'outil vise à transformer les politiques cliniques qui encadrent l'autorisation préalable (prior authorization), c'est-à-dire l'approbation qu'un assureur santé doit donner avant de couvrir certains actes médicaux ou médicaments, en données structurées et exploitables par des systèmes d'IA. La solution repose sur plusieurs briques d'AgentCore : le Runtime, qui isole chaque session dans des microVM sécurisées pour garantir une séparation stricte entre les différents clients assureurs ; la Gateway, qui donne un accès unifié aux outils via le protocole MCP (Model Context Protocol) ; la Memory, qui conserve le contexte des retours des analystes ; et le standard ouvert Agent Skills. Le calendrier réglementaire pèse lourd dans ce projet : les Centers for Medicare & Medicaid Services (CMS) imposent aux assureurs de proposer une autorisation préalable électronique via API d'ici janvier 2027, tandis que l'association America's Health Insurance Plans (AHIP) s'est engagée à atteindre 80 % d'approbations en temps réel pour les demandes soumises électroniquement. Cette digitisation répond à un goulot d'étranglement bien identifié dans le secteur de la santé américain. Les politiques cliniques qui déterminent quels traitements nécessitent une autorisation varient selon la zone géographique, la spécialité médicale, la ligne d'activité et l'assureur, et elles évoluent au rythme des avancées médicales. Jusqu'ici, ces règles restaient enfermées dans des documents PDF statiques et non structurés, rendant leur gestion, leur audit et leur mise à jour largement manuels, un processus qui affecte directement des centaines de millions de patients chaque année. En automatisant l'extraction et la structuration de ces politiques tout en conservant une traçabilité complète des versions, Cohere Health cherche à accélérer les flux de travail sans retirer aux médecins la responsabilité du jugement clinique, préservant ainsi la supervision humaine sur les décisions sensibles. Le projet illustre une tendance plus large : l'adoption d'architectures agentiques multi-tenants par les grands acteurs de l'assurance santé, poussée à la fois par la pression réglementaire et par la nécessité de gérer des volumes croissants de contenus cliniques hétérogènes. Cohere Health avait déjà un moteur AgentCore décomposant les politiques ; l'entreprise y a ajouté de nouvelles compétences (skills) pour produire différentes représentations d'une même politique selon les besoins des systèmes en aval, chacun avec sa propre boucle de retour utilisateur, dans une logique d'amélioration continue.

Créer un agent d'édition d'images sans serveur avec le harnais Amazon Bedrock AgentCore

Amazon a publié un article technique détaillant la construction d'un agent d'édition d'images serverless grâce à Amazon Bedrock AgentCore harness, un environnement d'orchestration qui exécute des agents IA dans des microVM isolées et à état persistant. La démonstration présente une application où l'utilisateur télécharge une photo, décrit une modification en langage naturel comme "changer la couleur de la voiture en bleu" ou "étendre l'image de 200 pixels vers la droite", et reçoit le résultat en quelques secondes. L'agent, propulsé par Claude Sonnet 4.6, découpe la demande en plusieurs étapes et orchestre l'appel de trois outils, chacun associé à un modèle Stability AI différent pour l'édition d'image proprement dite. Une fois la modification appliquée, un script s'exécute directement sur la microVM pour ajouter un filigrane, sans consommer de tokens supplémentaires. L'architecture complète, déployée en une seule commande via AWS CDK, comprend un frontend React hébergé sur AWS Amplify, une fonction Lambda faisant office de proxy de sécurité, l'agent AgentCore avec sa mémoire conversationnelle, et trois fonctions Lambda exposées via le protocole Model Context Protocol (MCP). Cette démonstration illustre un changement de philosophie important dans la construction d'agents IA en production. Là où les développeurs devaient jusqu'ici écrire du code d'orchestration personnalisé, gérer eux-mêmes le routage des outils et la mémoire, AgentCore harness permet de définir un agent entièrement par configuration, via des paramètres passés à une API, sans framework ni conteneur à maintenir. L'application bascule aussi dynamiquement entre modèles selon le type de requête, Claude Haiku 4.5 pour les échanges simples et Claude Sonnet 4.6 pour les modifications d'image, tout en conservant le contexte de la conversation d'un modèle à l'autre. Elle permet également d'injecter des personas métier, immobilier, retail, automobile, sans redéploiement. Pour les équipes qui construisent des produits IA orientés client, cela réduit significativement la charge d'ingénierie nécessaire pour faire tourner un agent fiable en production. Ce lancement s'inscrit dans la course entre fournisseurs cloud pour simplifier le déploiement d'agents IA, un domaine où AWS, Google et Microsoft rivalisent d'outils d'orchestration managés. La mémoire conversationnelle d'AgentCore conserve l'historique des échanges pendant 30 jours via son service dédié, accessible par une API ListEvents même après un rafraîchissement du navigateur ou l'effacement des données locales. Les trois outils d'édition d'image sont exposés via une passerelle utilisant le protocole MCP, un standard émergent pour connecter des agents à des outils externes, avec un routage sémantique qui laisse le modèle choisir lui-même l'outil pertinent selon la formulation de la demande. Cette approche configuration-first pourrait devenir un modèle de référence pour les prochaines générations d'applications d'agents IA grand public.