Wood Mackenzie construit une plateforme d’agents partagée sur Amazon Bedrock AgentCore

Wood Mackenzie a construit une plateforme d’IA agentique partagée appelée APEX sur Amazon Bedrock AgentCore, offrant aux équipes une base commune pour déployer des agents en production au lieu de reconstruire, pour chaque application, les runtimes, les contrôles d’identité, l’observabilité et les garde-fous.

Le compte rendu de l’entreprise, publié par AWS, indique qu’APEX prend en charge trois applications : Woody, Lens AI et la ST Trading App. L’architecture est conçue pour permettre aux équipes produit de choisir différents frameworks et modèles d’agents tout en s’appuyant sur une couche opérationnelle standardisée. Cela répond à un problème central de l’IA d’entreprise : les prototypes peuvent être créés rapidement, mais exploiter en toute sécurité des systèmes non déterministes à travers les utilisateurs, les outils et les données est beaucoup plus difficile.

Le même ensemble d’articles de blog AWS documente également la façon dont Abnormal AI utilise AgentCore Code Interpreter dans ses systèmes de sécurité des e-mails. Ensemble, ces exemples montrent qu’AWS positionne AgentCore non seulement comme un service de développement, mais comme une infrastructure pour des agents qui ont besoin d’isolation, d’application des politiques et d’un accès contrôlé au calcul dans des workflows en direct.

Une base commune pour les agents de Wood Mackenzie

Avant APEX, selon Wood Mackenzie, Woody, Lens AI et la ST Trading App développaient chacune leurs propres piles d’agents. Cette approche aurait nécessité des implémentations distinctes de l’authentification, du dimensionnement, du tracing, de l’accès aux modèles et des garde-fous. Elle aurait aussi rendu plus difficile le partage d’outils, de mémoire et de pratiques d’évaluation entre les équipes.

APEX centralise ces capacités. Son backend utilise Amazon Bedrock AgentCore Runtime, Identity, Gateway, Memory et Observability, ainsi qu’un orchestrateur, une infrastructure de récupération, l’accès aux modèles via le catalogue de modèles Amazon Bedrock et Amazon Bedrock Guardrails. Un kit de développement logiciel pour l’interface utilisateur connecte la plateforme aux applications destinées aux utilisateurs.

La conception n’impose pas à chaque équipe d’utiliser le même framework d’agents. Wood Mackenzie indique que son environnement peut prendre en charge Strands Agents, LangGraph, CrewAI, n8n, Vertex et les outils d’agents d’OpenAI. AgentCore prend également en charge le Model Context Protocol, ou MCP, ainsi que le protocole Agent-to-Agent, permettant à des systèmes et agents externes de se connecter via des interfaces standardisées plutôt que par des intégrations ponctuelles.

Cette flexibilité constitue une part importante de l’attrait de la plateforme. Selon Wood Mackenzie, les équipes peuvent changer de modèle sans réécrire la logique applicative, utiliser un modèle pour la planification et un autre pour l’exécution, ou comparer prix et performances entre fournisseurs. L’entreprise cite Claude, GPT-4.1, Amazon Nova, Mistral et Llama comme accessibles via la plateforme, bien que l’article ne fournisse pas de mesures indépendantes de la qualité des modèles ni des coûts de changement.

L’identité et les opérations montent dans la couche plateforme

APEX traite l’autorisation comme une propriété de chaque invocation d’agent plutôt que comme une vérification effectuée uniquement lorsqu’un utilisateur entre dans une application. Wood Mackenzie explique qu’AgentCore Identity transporte les permissions d’un utilisateur à travers les appels d’outils et de données en aval, permettant aux agents d’agir au nom d’un utilisateur ou sous des contrôles d’accès définis séparément. L’entreprise utilise Okta comme source de vérité de son fournisseur d’identité.

La plateforme comprend également un Woodmac Agent Registry, où les équipes peuvent découvrir et réutiliser des agents, des outils et des compétences soumis à des processus de gouvernance et d’approbation. Ce registre vise à éviter que les équipes copient du code lorsqu’une capacité existante pourrait être partagée.

AWS décrit AgentCore Runtime comme un environnement sans serveur, isolé par session, capable de passer de zéro à des milliers d’invocations simultanées, avec des fenêtres d’exécution allant jusqu’à huit heures. AWS indique également que les services AgentCore prennent en charge des fonctionnalités telles qu’Amazon Virtual Private Cloud, AWS PrivateLink, CloudFormation et le balisage des ressources, après la disponibilité générale d’octobre 2025.

Pour la gestion des coûts, le service applique une tarification basée sur la consommation, sans engagement initial ni frais minimum annoncés. AWS précise que la facturation du runtime repose sur la consommation active de CPU et de mémoire par seconde, les frais CPU étant exclus pendant les attentes d’entrée/sortie. L’entreprise note que les workflows d’agents peuvent passer 30 % à 70 % de leur temps à attendre des réponses de modèles, des outils ou des bases de données, ce qui rend ce modèle de facturation pertinent pour les charges de travail qui laisseraient autrement du calcul provisionné inactif.

Les preuves sont détaillées, mais contrôlées par le fournisseur

Les affirmations les plus fortes de l’article proviennent d’AWS et de Wood Mackenzie, et non d’audits indépendants. Wood Mackenzie indique en interne que 88 % de ses preuves de concept en IA n’atteignent pas un déploiement à grande échelle. L’article cite également des enquêtes sectorielles et des recherches de Forrester pour soutenir l’idée que l’évaluation, l’observabilité, la gouvernance et l’identité sont des obstacles majeurs à la montée en charge des agents, mais il ne fournit pas suffisamment de détails de source pour permettre d’évaluer indépendamment ces statistiques plus larges.

L’architecture elle-même est décrite en termes pratiques, notamment le chemin de requête allant de l’authentification à l’orchestration, au runtime, à l’accès au modèle et aux appels d’outils. Cependant, l’article ne divulgue ni le trafic de production d’APEX, ni le nombre d’agents, ni la latence, les taux d’erreur, les coûts opérationnels ou des résultats business mesurables. Les acheteurs devraient donc considérer ce compte rendu comme une référence d’implémentation et une étude de cas soutenue par un fournisseur, plutôt que comme la preuve qu’AgentCore produira les mêmes résultats dans une autre entreprise.

L’exemple d’Abnormal AI apporte une affirmation de portée différente. AWS dit qu’Abnormal AI utilise AgentCore Code Interpreter pour des agents impliqués dans la détection en temps réel des menaces e-mail sur des milliards de messages, tandis que le système de détection plus large n’applique des analyses plus coûteuses qu’aux cas les plus difficiles. AWS rapporte également que plus de 25 % du Fortune 500 utilisent Abnormal AI, et que 80 % des changements de code de l’entreprise impliquent d’une manière ou d’une autre un agent. Il s’agit de chiffres communiqués par l’entreprise ou le fournisseur, et l’article n’offre pas de vérification indépendante.

Code Interpreter ajoute une capacité différente au récit AgentCore. Il fournit des bacs à sable éphémères MicroVM dans lesquels les agents peuvent exécuter du code Python ou Node.js, traiter des fichiers, effectuer des calculs, produire des sorties et vérifier le travail généré. AWS indique que les sessions peuvent durer de 15 minutes à huit heures, prendre en charge le réseau public ou le mode VPC, et fournir des journaux via CloudWatch et CloudTrail. Le cas d’usage d’Abnormal AI illustre pourquoi les agents peuvent avoir besoin d’un environnement d’exécution contrôlé plutôt que de s’appuyer uniquement sur le raisonnement d’un modèle de langage.

Ce que la plateforme signifie pour les développeurs et les entreprises

Pour les développeurs d’IA, le principal changement est un déplacement de l’effort d’ingénierie. Les équipes peuvent se concentrer sur les workflows métier, la qualité de la récupération, la conception des outils et l’évaluation, tandis qu’une plateforme partagée gère les préoccupations récurrentes d’infrastructure. Cela peut raccourcir le chemin entre une démo réussie et un service capable de prendre en charge plusieurs utilisateurs et des sessions simultanées.

Le compromis est une dépendance architecturale à une équipe plateforme centrale. Un registre partagé, une couche de politiques commune et une observabilité standardisée peuvent réduire la duplication, mais ils peuvent aussi devenir des goulots d’étranglement si l’intégration, les approbations ou la prise en charge des frameworks sont lents. La décision de Wood Mackenzie de préserver le choix des frameworks et des modèles réduit ce risque, mais n’élimine pas la nécessité d’une conception d’interface soignée et d’une gouvernance de plateforme rigoureuse.

Pour les entreprises, la propagation de l’identité et l’isolation des sessions sont plus importantes qu’une longue liste de modèles pris en charge. Un agent qui peut appeler des outils internes a besoin d’autorisations qui restent compréhensibles et révocables tout au long du workflow. AgentCore Identity, les politiques Gateway et les règles basées sur Cedar sont conçus pour répondre à cette exigence, mais les organisations devront tout de même tester le comportement des politiques face à des prompts inhabituels, des appels d’outils chaînés et des défaillances partielles.

Le déploiement d’Abnormal AI renforce également un modèle de coûts à plusieurs niveaux pour les systèmes d’agents. Des règles légères et des classificateurs peuvent traiter les cas à fort volume, tandis que les agents plus coûteux et l’exécution de code sont réservés aux cas incertains ou complexes. Ce schéma peut être plus pratique que d’envoyer chaque tâche à un grand modèle, en particulier lorsque la latence et le coût par opération comptent.

Ce qu’il faut surveiller ensuite

Les prochains signaux significatifs seront opérationnels plutôt que promotionnels. APEX de Wood Mackenzie serait plus évaluable avec des données publiées sur l’adoption dans ses applications, les taux d’échec des agents, la couverture d’évaluation, la latence, les violations de politiques et le coût par workflow.

Les développeurs devraient également surveiller si l’agnosticisme de framework et de modèle d’AgentCore reste pratique à mesure que les équipes passent d’expériences isolées à des outils partagés et à des workflows multi-agents. La prise en charge de MCP et des connexions Agent-to-Agent pourrait accroître la réutilisation, mais aussi augmenter le nombre de frontières de confiance que les équipes plateforme doivent surveiller.

Pour les acheteurs d’entreprise, les points de suivi importants sont des références clients indépendantes, une tarification plus claire en cas de concurrence soutenue, des contrôles de réponse aux incidents et la preuve que les agents peuvent être désactivés ou annulés sans perturber les applications connectées. Les déploiements de Code Interpreter méritent un examen supplémentaire concernant la conservation des données, l’accès au réseau, le contrôle des paquets et l’isolation du code généré.

Perspective Creati.ai

APEX de Wood Mackenzie est remarquable moins parce qu’il introduit une nouvelle application d’agents que parce qu’il traite la couche de production manquante comme un produit réutilisable. Le compte rendu de l’entreprise suggère que les équipes d’entreprise se dirigent vers des plateformes internes d’agents qui standardisent l’identité, le comportement d’exécution, l’observabilité et les politiques, tout en laissant aux équipes métier la liberté de choisir leurs propres modèles et frameworks.

Les preuves restent contrôlées par le fournisseur, et aucun donnée de performance ou financière n’est divulguée pour établir APEX comme un modèle éprouvé. Néanmoins, l’architecture indique une direction pratique pour l’IA d’entreprise : l’adoption des agents dépendra probablement moins de la production d’un nouveau prototype impressionnant que de la capacité à rendre les autorisations, l’évaluation, l’isolation et les coûts suffisamment visibles pour être exploités au quotidien.