Ce nouveau système va révolutionner les échanges entre vos agents IA (sans prise de tête)

QUAND LES AGENTS IA SE MULTIPLIENT, LES PROBLÈMES AUSSI

Imaginez que chaque fois qu’un nouveau agent IA arrive dans votre entreprise, vous devez créer une connexion directe avec tous les autres. C’est comme si chaque collègue devait avoir un câble dédié pour parler à tous les autres : avec 20 agents, ça fait 190 câbles à brancher. Sans compter les identifiants différents à gérer, les règles d’accès à définir, et les risques de sécurité qui s’accumulent. Résultat ? Vos équipes passent leur temps à configurer des connexions au lieu de travailler sur l’intelligence des agents. Et plus vous ajoutez d’agents, plus la situation devient ingérable.

LE PATRON DE LA CLASSE : LA PASSERELLE A2A

La solution s’appelle A2A Gateway. C’est une porte d’entrée unique qui se place devant tous vos agents, qu’ils tournent sur AWS Lambda, Amazon ECS, Bedrock AgentCore ou même hors d’AWS. Son rôle ? Gérer le routage des messages et les permissions, sans imposer un environnement technique précis. Cette passerelle s’appuie sur le protocole A2A, une norme qui définit comment les agents communiquent entre eux. Avec elle, plus besoin de 190 connexions : un seul point d’entrée suffit.

COMMENT ÇA MARCHE ? TROIS COUCHES POUR UNE MACHINE BIEN HUILÉE

La passerelle fonctionne en trois parties :

1. La couche d’entrée : c’est Amazon API Gateway, qui sert de réceptionniste. Elle reçoit toutes les demandes et les redirige vers la bonne destination. Pourquoi une API REST ? Parce qu’elle permet le streaming (flux continu de données), essentiel pour les réponses en temps réel des agents.

2. La couche de contrôle : ici, Lambda Authorizer vérifie que vous avez le Droit d’accéder à un agent. Il utilise un JWT (un jeton numérique) pour savoir quels agents vous êtes autorisé à utiliser. Par exemple, un jeton avec le scope billing:read vous donnera accès à l’agent de facturation, mais pas à celui des ressources humaines.

3. La couche d’exécution : c’est le cœur de la machine. Des fonctions Lambda agissent comme des proxy : elles reçoivent les messages, se connectent aux agents concernés via OAuth 2.0, et renvoient les réponses. Tout ça, sans que vous ayez à gérer les identifiants des agents.

DANS LES DÉTAILS : LES COMPOSANTS CLÉS

Pour fonctionner, la passerelle repose sur plusieurs services AWS :

• Amazon DynamoDB : stocke trois bases de données essentielles. La première, Agent Registry, liste tous les agents avec leurs URLs, leurs configurations d’authentification et leurs cartes d’agents en cache. La seconde, Permissions, associe les scopes JWT aux agents autorisés. La troisième, RateLimitCounters, compte les requêtes par minute pour éviter les abus.
• Amazon Cognito : gère l’authentification via le flux OAuth 2.0 client credentials. Quand un client s’identifie, il reçoit un JWT contenant des scopes comme billing:read ou support:write. L’authorizer vérifie ensuite dans la table Permissions quels agents ce client peut utiliser.
• AWS Secrets Manager : stocke les identifiants des agents. Quand la passerelle doit se connecter à un agent, elle récupère le secret via son ARN (un identifiant unique). Ces secrets ne sont jamais stockés dans DynamoDB.
• Amazon S3 Vectors : stocke les descriptions des agents après les avoir transformées en vecteurs avec Amazon Titan Text Embeddings. Cela permet aux clients de chercher des agents par mots-clés ou phrases, comme une recherche Google.

Les agents natifs A2A suivent la norme du protocole A2A. Ils peuvent utiliser deux types de liaisons :

JSON-RPC : l’agent a un seul endpoint par méthode, avec la méthode indiquée dans le corps de la requête. Par exemple, pour envoyer un message à l’agent météo, l’URL sera /agents/weather-agent/message:send.

HTTP+JSON/REST : pour ceux qui préfèrent les URLs classiques. L’agent a un endpoint unique par ressource, comme /agents/weather-agent/messages.

LES ENDPOINTS DE LA PASSERELLE : PLUS QU’UN SIMPLE ROUTER

La passerelle ne se contente pas de rediriger les messages. Elle offre aussi des fonctionnalités pour découvrir et gérer les agents :

/agents : liste tous les agents disponibles pour un utilisateur autorisé. Par exemple, un appel GET /agents avec un JWT valide renvoie la liste des agents accessibles.

/admin/agents/register : permet d’enregistrer un nouvel agent. Il faut fournir son ID, son nom, son URL de backend, son URL de carte d’agent, et sa configuration d’authentification OAuth.

Recherche sémantique : grâce aux vecteurs stockés dans S3, les clients peuvent chercher des agents par description. Par exemple, au lieu de connaître le nom exact d’un agent, vous pouvez demander « un agent qui calcule des pourcentages » et obtenir une liste de résultats pertinents.

Chaque requête suit le même chemin : le client envoie une requête avec un JWT dans l’en-tête Authorization. API Gateway déclenche l’authorizer, qui valide le JWT et vérifie les scopes dans la table Permissions. Si tout est bon, la requête est routée vers la bonne fonction Lambda : Proxy pour les messages A2A, Registry pour la découverte, Search pour les recherches sémantiques, ou Admin pour la gestion.

LES PERMISSIONS : UNE CLÉ POUR CHAQUE AGENT

Dans une entreprise, tous les utilisateurs n’ont pas accès à tous les agents. La passerelle gère cela via des scopes dans les JWT. Par exemple :

• Un scope billing:read permet d’accéder à l’agent de facturation.
• Un scope support:admin donne accès à tous les agents de support.
• Un scope gateway:admin autorise la gestion des agents (enregistrement, suppression).

L’authorizer utilise la table Permissions pour mapper ces scopes aux agents autorisés. Par exemple, pour autoriser le scope gateway:admin à accéder à l’agent météo, il faut ajouter cette entrée dans DynamoDB :

aws dynamodb put-item \
  --table-name "$PERMISSIONS_TABLE" \
  --item '{
    "scope": {"S": "gateway:admin"},
    "allowedAgents": {"L": [{"S": "weather-agent"}]},
    "description": {"S": "Admin scope with access to weather agent"}
  }'

Sans cette entrée, la requête serait rejetée dès API Gateway, sans même atteindre les fonctions Lambda.

Autre fonctionnalité : la limitation de débit. La passerelle compte les requêtes par utilisateur et par agent. Si un client dépasse son quota, elle renvoie une erreur 429 Too Many Requests avec un en-tête Retry-After indiquant quand réessayer. Les limites sont gérées dans la table Permissions.

LA ROUTINE DES MESSAGES : DE L’ENTRÉE À LA SORTIE

Prenons un exemple concret. Un utilisateur veut savoir la météo à New York. Voici ce qui se passe :

1. Il envoie une requête POST /agents/weather-agent/message:send avec un JWT valide.
2. API Gateway déclenche l’authorizer, qui valide le JWT et vérifie que le scope permet d’accéder à l’agent météo.
3. Si tout est bon, la requête est envoyée à la fonction Lambda Proxy.
4. Le Proxy récupère les identifiants de l’agent météo depuis Secrets Manager et obtient un jeton OAuth via l’endpoint tokenUrl de l’agent.

   TOKENRESPONSE=$(curl -s -X POST "$AGENTTOKEN_ENDPOINT" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "granttype=clientcredentials&clientid=$AGENTCLIENTID&clientsecret=$AGENTCLIENTSECRET")
   export AGENTJWT=$(echo $TOKENRESPONSE | jq -r .access_token)

5. Le Proxy envoie le message à l’agent météo via son URL de backend, en incluant le jeton OAuth.
6. L’agent météo traite la requête et renvoie une réponse, qui est transmise au client via la passerelle.

Pour les réponses en temps réel (comme un agent qui génère du texte mot par mot), la passerelle supporte le Server-Sent Events (SSE). Le client reçoit les données au fur et à mesure, sans avoir à attendre la réponse complète.

DÉPLOYER LA PASSERELLE EN 10 MINUTES (AVEC TERRAFORM)

Pour déployer cette solution, il suffit de suivre ces étapes. Tout est automatisé avec Terraform, un outil qui crée les ressources AWS pour vous. Voici comment faire :

1. Préparer l’environnement

Clonez le dépôt GitHub aws-samples/a2a-gateway et configurez les variables :

cp terraform/terraform.tfvars.example terraform/terraform.tfvars

Éditez le fichier terraform.tfvars pour définir votre région AWS et le nom du projet :

aws_region = "us-east-1"
project_name = "a2a-gateway"
environment = "poc"

2. Construire le package Lambda

Exécutez le script de construction :

./scripts/buildlambdapackage.sh

3. Déployer les ressources AWS

Initialisez Terraform, planifiez le déploiement et appliquez-le :

cd terraform
terraform init
terraform plan
terraform apply

Terraform crée automatiquement :

• Les tables DynamoDB (Agent Registry, Permissions, RateLimitCounters).
• Un pool d’utilisateurs Amazon Cognito pour l’authentification.
• Un dépôt Amazon ECR pour stocker l’image Docker de la fonction Proxy.
• Les fonctions Lambda (Proxy, Registry, Search, Admin).
• L’API Gateway et les rôles IAM nécessaires.

4. Récupérer les identifiants

Après le déploiement, récupérez les informations nécessaires pour utiliser la passerelle :

GATEWAYURL=$(terraform output -raw apigateway_url)
TOKENENDPOINT=$(terraform output -raw cognitotoken_endpoint)
CLIENTID=$(terraform output -raw cognitoclient_id)
CLIENTSECRET=$(terraform output -raw cognitoclient_secret)
PERMISSIONSTABLE=$(terraform output -raw permissionstable_name)

5. Obtenir un jeton JWT

Authentifiez-vous pour obtenir un jeton d’accès :

TOKENRESPONSE=$(curl -s -X POST "$TOKENENDPOINT" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "granttype=clientcredentials&clientid=$CLIENTID&clientsecret=$CLIENTSECRET")
export JWT=$(echo $TOKENRESPONSE | jq -r .accesstoken)

6. Déployer des agents exemples

Le dépôt inclut deux agents exemples : un agent météo et un agent calculatrice. Pour les déployer :

cd examples/terraform && terraform apply

Récupérez ensuite leurs identifiants :

WEATHERBACKEND=$(terraform output -raw weatheragentbackendurl)
WEATHERCARD=$(terraform output -raw weatheragentcardurl)
AGENTTOKENENDPOINT=$(terraform output -raw cognitotokenendpoint)
AGENTCLIENTID=$(terraform output -raw cognitoclientid)
AGENTCLIENTSECRET=$(terraform output -raw cognitoclientsecret)

7. Enregistrer un agent dans la passerelle

Pour ajouter l’agent météo à la passerelle, envoyez une requête POST :

curl -X POST "$GATEWAY_URL/admin/agents/register" \
  -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "weather-agent",
    "name": "Weather Agent",
    "backendUrl": "'"$WEATHER_BACKEND"'",
    "agentCardUrl": "'"$WEATHER_CARD"'",
    "authConfig": {
      "type": "oauth2clientcredentials",
      "tokenUrl": "'"$AGENTTOKENENDPOINT"'",
      "clientId": "'"$AGENTCLIENTID"'",
      "clientSecret": "'"$AGENTCLIENTSECRET"'",
      "scopes": ["a2a-gateway/weather:read"]
    }
  }'

8. Configurer les permissions

Autorisez le scope gateway:admin à accéder à l’agent météo :

aws dynamodb put-item \
  --table-name "$PERMISSIONS_TABLE" \
  --item '{
    "scope": {"S": "gateway:admin"},
    "allowedAgents": {"L": [{"S": "weather-agent"}]},
    "description": {"S": "Admin scope with access to weather agent"}
  }'

9. Tester la passerelle

Listez les agents disponibles et envoyez un message à l’agent météo :

curl "$GATEWAY_URL/agents" -H "Authorization: Bearer $JWT"

curl -X POST "$GATEWAY_URL/agents/weather-agent/message:send" \
  -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "message": {
      "messageId": "msg-001",
      "role": "user",
      "parts": [{"text": "What is the weather in New York"}]
    }
  }'

NETTOYER LE DÉPLOIEMENT

Quand vous n’avez plus besoin de la passerelle, supprimez toutes les ressources créées :

cd terraform
terraform destroy

Terraform vous demandera confirmation avant de tout effacer.

SÉCURITÉ : CE QU’IL FAUT SAVOIR AVANT DE PASSER EN PRODUCTION

Cette passerelle est une implémentation de référence. Avant de la mettre en production, voici les points à vérifier pour renforcer la sécurité :

1. Modèle de confiance

La passerelle fonctionne sur le principe « confiance après authentification ». Une fois qu’un agent est enregistré et que ses identifiants OAuth sont validés, la passerelle transmet les messages sans les inspecter. Les agents doivent donc implémenter leurs propres défenses contre les injections de prompts et la validation des entrées. En production, mettez en place un workflow d’approbation pour l’enregistrement des agents. Un administrateur doit valider chaque nouvel agent avant qu’il ne soit accessible.

2. Déploiement en VPC privé

Pour une sécurité maximale, déployez la passerelle dans un VPC privé (réseau virtuel isolé). Activez ce mode en ajoutant ces variables dans terraform.tfvars :

enableprivatedeployment = true
existingvpcid = "vpc-0123456789abcdef0"
existingsubnetids = ["subnet-aaa", "subnet-bbb", "subnet-ccc"]
existingroutetable_ids = ["rtb-aaa"]
existinglambdasecuritygroupid = "sg-aaa"
existingvpcendpointsecuritygroup_id = "sg-bbb"

Dans ce mode, les fonctions Lambda tournent dans des sous-réseaux privés, et API Gateway utilise un endpoint privé accessible uniquement depuis le VPC. Les services AWS (DynamoDB, S3, Secrets Manager) sont accessibles via des VPC endpoints, ce qui évite que le trafic ne passe par Internet. Seule l’échange de jetons OAuth avec Cognito nécessite une sortie vers Internet, généralement via un NAT Gateway ou un AWS Transit Gateway.

Pour activer la recherche sémantique avec Amazon Bedrock, ajoutez :

enablebedrockendpoint = true

3. Connexion aux agents hors AWS

La passerelle peut gouverner des agents déployés sur site ou dans d’autres clouds via AWS Direct Connect ou AWS Interconnect (en préversion). Cela permet de gérer des agents multi-environnements sans exposer le trafic à Internet.

4. Authentification avec Bedrock AgentCore

Si vous utilisez Bedrock AgentCore Runtime, une attention particulière est nécessaire pour l’authentification. Configurez le customJWTAuthorizer avec allowedClients (et non allowedAudience). Les jetons Cognito pour les machines n’incluent pas le claim aud standard, mais bien client_id. Utiliser allowedAudience renverrait une erreur 401.

POURQUOI CELA VA TOUT CHANGER POUR VOS AGENTS IA

Quand une entreprise passe de quelques agents à des dizaines, voire des centaines, les défis ne sont plus techniques (comment faire fonctionner un agent), mais organisationnels (comment les faire communiquer entre eux). Les connexions point à point ne sont pas scalables. Les équipes ne devraient plus avoir à :

• Savoir où se trouve chaque agent.
• Gérer des identifiants séparés pour chaque agent.
• Coder leur propre système de découverte et de contrôle d’accès.

La passerelle A2A offre un seul endroit pour :

• Enregistrer les agents.
• Contrôler qui peut y accéder.
• Router le trafic.

Le protocole A2A standardise la façon dont les agents communiquent. La passerelle standardise la façon dont votre organisation gère cette communication. Résultat ? Moins de temps perdu en configuration, moins de risques de sécurité, et une évolutivité garantie.

LE CODE EST DISPONIBLE POUR TOUT LE MONDE

Vous voulez tester par vous-même ? Le code complet de la passerelle est disponible sur le dépôt aws-samples/a2a-gateway sur GitHub. Vous y trouverez aussi les exemples d’agents (météo, calculatrice) pour faire vos premiers tests. Tout est open source, prêt à être adapté à vos besoins.