AWS Agent Registry : le Google Drive des agents IA pour les entreprises ?

LE PROBLÈME : DES AGENTS IA DISPERSÉS COMME DES FICHIERS PERDUS SUR UN ORDINATEUR

Quand une entreprise commence à utiliser des agents IA et des Outils, tout fonctionne bien au début. Mais dès que plusieurs équipes se mettent à en développer, les choses deviennent ingérables. Chaque équipe crée ses propres agents, outils et compétences sans partager l’information avec les autres. Résultat : plus personne ne sait ce qui existe, qui en est responsable, ou si ces outils sont encore à jour.

Ce n’est plus un problème de construction, mais de découverte et de gouvernance. Les équipes passent leur temps à recréer ce qui existe déjà ailleurs dans l’entreprise. Les coûts explosent avec des infrastructures redondantes, et la maintenance devient un cauchemar. Sans compter le risque de sécurité : comment vérifier qui a accès à quoi, si les outils ont passé les contrôles, ou qui est responsable en cas de problème ?

LA SOLUTION AWS : UN CATALOGUE UNIQUE POUR TOUT GÉRER

AWS Agent Registry est conçu pour résoudre ces trois défis majeurs. C’est un catalogue centralisé, recherchable et gouverné où les équipes peuvent enregistrer leurs agents, outils, compétences et ressources personnalisées. Plus besoin de chercher partout : tout est au même endroit, avec un système de contrôle d’accès et un suivi des versions.

Le registre fonctionne sur deux plans complémentaires :

Le Discovery Plane est l’interface que les utilisateurs voient au quotidien. Il affiche uniquement les ressources qui ont été validées par l’entreprise, avec une recherche performante pour les retrouver rapidement. Ces deux plans séparent clairement les responsabilités : les administrateurs gardent le contrôle total, tandis que les utilisateurs accèdent facilement aux outils approuvés.

DES ENTREPRISES DÉJÀ CONVAINCUES : SONY, PEPSICO, SYNGENTA…

Des entreprises de tous secteurs utilisent AWS Agent Registry pour éviter le chaos des agents dispersés. Par exemple, Sony l’utilise pour réutiliser des modèles d’agents entre ses différentes unités. Mitsubishi Electric s’en sert pour donner aux développeurs un endroit unique où découvrir et faire confiance aux outils qu’ils construisent.

Pour Southwest Airlines, cette centralisation a tout changé. Avant, l’entreprise comptait des dizaines d’agents et outils éparpillés entre plusieurs équipes techniques, sans aucun registre partagé. Aujourd’hui, avec AWS Agent Registry, la plateforme a une visibilité complète sur ce qui est déployé, qui en est responsable, et si c’est approuvé. Les développeurs trouvent des outils validés en quelques secondes grâce à la recherche sémantique, au lieu de tout recréer.

PepsiCo, de son côté, souligne l’importance d’avoir un système centralisé pour la découverte et l’utilisation des agents. Syngenta a fait du registre la pierre angulaire de sa stratégie de gouvernance des agents IA, éliminant les doublons entre équipes.

AMDOCS ET INFORMATICA : DES INTÉGRATIONS POUR RENDRE LES AGENTS PLUS SÛRS

Des partenaires comme Amdocs et Informatica étendent les capacités d’AWS Agent Registry. Amdocs, spécialiste des solutions logicielles pour le secteur des télécoms, l’a intégré à sa plateforme aOS Cognitive Core pour offrir une vue unifiée des actifs d’agents dans différents environnements. Résultat : une gouvernance simplifiée, une meilleure conformité, et une accélération de l’adoption de l’IA.

Informatica, via son protocole MCP (Model Context Protocol), permet aux serveurs MCP hébergés par l’entreprise d’être listés, découverts et intégrés de manière sécurisée dans les workflows d’agents IA. Cela donne aux agents un accès à des données fiables et gouvernées, améliorant leur précision et leur conformité.

Check Point, leader en cybersécurité, utilise AWS Agent Registry pour surveiller en continu la sécurité des workloads Amazon Bedrock AgentCore. En combinant les métadonnées du registre avec les données de télémétrie, Check Point peut corréler ce qu’un agent est censé faire avec ce qu’il fait réellement, détectant ainsi les comportements suspects et appliquant des politiques adaptatives.

UNE GOUVERNANCE CONÇUE POUR LES GRANDES ENTREPRISES

AWS Agent Registry est pensé pour les réalités des grandes organisations. Les administrateurs peuvent créer un registre unique pour toute l’entreprise ou plusieurs instances, chacune avec ses propres politiques d’accès, workflows d’approbation et règles de cycle de vie. Chaque instance peut être configurée avec OAuth ou IAM pour l’authentification, selon les besoins.

Les administrateurs gèrent le cycle de vie complet des ressources : ils configurent des workflows d’approbation avec des approbateurs désignés, et des curateurs (des humains) examinent chaque agent, outil ou compétence avant publication. Quand une ressource devient obsolète, les curateurs la marquent comme dépréciée. AWS CloudTrail enregistre toutes les actions pour un audit complet.

COMMENT ÇA MARCHE ? LE PROCESSUS EN 7 ÉTAPES

Le processus de publication et d’approbation dans AWS Agent Registry suit un workflow précis :

Étape 1 : CRUD du registre – L’administrateur accède à l’interface de gestion (via AWS CLI, SDK ou Console) pour créer, lire, mettre à jour ou supprimer des ressources dans le registre. C’est ici que le registre est configuré et maintenu.

Étape 2 : Création et administration du workflow d’approbation – En parallèle, l’administrateur conçoit et configure le workflow qui validera les soumissions d’agents et d’outils. Cela peut inclure des scans de sécurité, des vérifications de duplication, et d’autres contrôles.

Étape 3 : Publication des enregistrements – Les enregistrements sont publiés dans le registre. Les administrateurs peuvent aussi ajouter directement des enregistrements en spécifiant des endpoints actifs (dont le registre peut récupérer les métadonnées) ou en publiant directement les enregistrements complets.

Étape 4 : Déclenchement via Amazon EventBridge – Une fois un enregistrement soumis et en attente d’approbation, le registre envoie un événement via Amazon EventBridge, qui sert de courtier pour les événements. Cet événement peut être routé vers le workflow d’approbation configuré à l’étape 2.

Étape 5 : Workflow d’approbation – Le workflow d’approbation doit inclure des contrôles pour décider si les enregistrements doivent être rendus accessibles à toute l’organisation. Les contrôles exacts dépendent des exigences internes définies par l’administrateur.

Étape 6 : Approbation et découverte – Une fois la décision finale d’approbation prise (via l’API ou la Console), le registre met à jour le statut de l’enregistrement en « approuvé » et le publie sur le Discovery Plane du registre.

Étape 7 : Découverte par les consommateurs – Les utilisateurs peuvent maintenant trouver l’enregistrement dans le Discovery Plane du registre, qui supporte la navigation et la recherche sémantique ou lexicale (hybride).

LA DÉTECTION AUTOMATIQUE POUR ÉVITER LES « AGENTS FANTÔMES »

Pour lutter contre le phénomène de « Shadow AI » (agents non déclarés), AWS Agent Registry propose une détection automatique au niveau de l’organisation AWS. Un administrateur active une fois la détection des endpoints au niveau de l’organisation, et le registre détecte automatiquement les agents et serveurs MCP exécutés sur le runtime AgentCore d’Amazon Bedrock, ainsi que le Gateway AgentCore, dans tous les comptes de l’organisation.

Les ressources détectées apparaissent dans une vue centralisée « Endpoints détectés », avec leurs identifiants, endpoints et métadonnées descriptives. L’administrateur peut ensuite connecter des comptes spécifiques (ou des unités organisationnelles entières) à un registre central. Les ressources détectées deviennent alors des enregistrements en brouillon qui suivent le cycle de vie standard : revue, approbation et publication sur le Discovery Plane. La relation est continue : quand un nouvel agent est déployé dans un compte connecté, il apparaît automatiquement dans le registre sans que l’équipe de publication n’ait à faire quoi que ce soit. Cela évite les agents fantômes et donne aux administrateurs une visibilité complète pour imposer la gouvernance à grande échelle.

PUBLIER UN AGENT OU UN OUTIL : LE PROCESSUS EN 4 ÉTAPES

Pour les développeurs qui souhaitent publier un agent ou un outil dans le registre, le processus est intégré aux pipelines CI/CD existants :

Étape 1 : Découvrir le registre – Le développeur utilise son IDE et son SDK pour construire un agent ou un outil. Il commence par interagir avec le registre pour découvrir ce qui est déjà enregistré.

Étape 2 : Pipeline CI/CD contrôlé par le développeur – Le code du développeur est intégré à un pipeline CI/CD qui automatise le packaging et la préparation de l’agent ou de l’outil pour l’enregistrement.

Étape 3 : Générer la carte d’agent ou la définition MCP – Le pipeline CI/CD peut être configuré pour produire soit une Agent Card (contenant les métadonnées, capacités et spécifications de l’agent), soit un serveur MCP avec une URL d’endpoint qui définit l’interface de l’outil et où il peut être atteint.

Étape 4 : Soumettre et créer un enregistrement dans le registre – Le pipeline crée un enregistrement dans le registre, puis le soumet pour approbation. Les étapes 5 à 8 correspondent au workflow d’approbation décrit précédemment.

LA SYNCHRONISATION AUTOMATIQUE POUR ÉVITER LES SAISIES MANUELLES

Le registre peut aussi récupérer automatiquement les métadonnées depuis des serveurs MCP ou A2A externes grâce à la fonctionnalité de synchronisation. Il se connecte en utilisant OAuth, IAM ou un accès non authentifié selon la configuration du serveur, et synchronise les métadonnées des enregistrements automatiquement.

DÉCOUVRIR UN AGENT OU UN OUTIL : LE PROCESSUS EN 5 ÉTAPES

Pour les utilisateurs ou les agents qui veulent découvrir et utiliser des ressources dans le registre, le processus est le suivant :

Étape 1 : Rechercher dans le registre – Le développeur interroge le registre pour découvrir les agents, outils et compétences disponibles.

Étape 2 : Recevoir les informations d’authentification et les URI – Le registre répond avec les détails d’autorisation et les URI d’endpoint pour les ressources qui intéressent le développeur.

Étape 3 : Demander l’accès – Le développeur demande l’onboarding sur les serveurs A2A et MCP via le processus d’onboarding de l’organisation.

Étape 4 : Recevoir les identifiants – Le développeur reçoit les détails d’authentification pour les endpoints demandés (clientID/secret, clés API ou accès basé sur IAM).

Étape 5 : Appeler les ressources avec authentification – Le développeur (et son agent) peut alors faire des appels authentifiés aux agents et outils en utilisant les identifiants obtenus à l’étape 4.

L’INTÉGRATION AVEC LES IDE : TROUVER UN OUTIL EN UN CLIC

Le registre expose chaque instance comme un serveur MCP. Les IDE compatibles MCP, comme Kiro et Claude Code, peuvent s’y connecter nativement. Un développeur peut ainsi taper une requête en langage naturel comme « trouve-moi un serveur MCP pour les tickets de problème » directement dans son IDE. L’IDE interroge l’instance spécifique du registre, retourne les outils correspondants avec leurs métadonnées et détails de connexion, et si le développeur a les droits, il peut commencer à utiliser l’outil immédiatement, sans quitter son éditeur.

La configuration de la connexion est légère : l’IDE utilise l’inscription dynamique de client (DCR) pour établir une relation de confiance avec le registre au moment de l’exécution. Aucun administrateur n’a besoin de pré-provisionner des identifiants OAuth. Le développeur s’authentifie une fois via son organisation, et tout est prêt.

POURQUOI C’EST UNE RÉVOLUTION POUR LES ENTREPRISES ?

À mesure que le nombre d’agents augmente dans plusieurs environnements cloud, gérer leur cycle de vie, éviter les doublons et assurer la gouvernance devient critique. AWS Agent Registry agit comme une couche de gouvernance centralisée qui standardise la façon dont les enregistrements d’agents sont partagés, découverts et gérés.

Des experts comme le Dr. Binqi Zhang de PwC Australia soulignent la valeur de cette solution : « Elle gère les compétences des agents de manière cohérente entre les systèmes, tout en permettant une intégration personnalisée avec le paysage technologique existant. Au-delà d’accélérer l’adoption, le registre centralisé aide à atténuer un risque opérationnel émergent à grande échelle : l’expansion anarchique des agents. »

Chez Caylent, on résume ainsi l’impact : « À mesure que les agents se multiplient dans une organisation, il devient de plus en plus difficile pour les humains, les agents et les outils de savoir quel agent utiliser et quand. AWS Agent Registry enlève cette charge inutile, en fournissant le bon contexte au bon agent au bon moment, et offre une façon sécurisée et évolutive de croître à mesure que plus d’agents sont déployés. »

En résumé, AWS Agent Registry devient la pièce manquante pour une gouvernance des agents à l’échelle d’entreprise : une source unique de vérité pour découvrir, authentifier et faire confiance aux agents dans toute l’organisation. C’est la clé pour activer des architectures multi-agents à grande échelle, interconnectant les différentes unités métiers.