Protocole A2A : faire communiquer les agents IA entre eux

Comment faire collaborer des agents IA développés par des équipes, des frameworks et des éditeurs différents ? Tant que chaque agent reste enfermé dans son propre écosystème, la délégation d'une tâche d'un agent à un autre passe par des intégrations sur mesure, fragiles et coûteuses à maintenir. C'est le problème que le protocole Agent2Agent (A2A) cherche à résoudre.

Créé par Google puis confié à la Linux Foundation, A2A est un standard ouvert qui définit comment un agent en découvre un autre, lui confie une tâche et récupère le résultat, sans rien savoir de son implémentation interne. Passé en version 1.0, il est soutenu par plus de 150 organisations et intégré dans Azure AI Foundry, Amazon Bedrock AgentCore et l'Agent Development Kit (ADK) de Google. Pour un AI Engineer, c'est devenu une brique à connaître au même titre que le Model Context Protocol.

Dans cet article, nous allons voir ce qu'est A2A et en quoi il complète MCP, puis détailler les Agent Cards et la découverte, le cycle de vie des tâches, les transports (JSON-RPC, gRPC) et la sécurité, avant de mettre en pratique la délégation d'une tâche entre deux agents.

Qu'est-ce que le protocole A2A ?

Le protocole A2A est un standard de communication entre agents : il décrit le format des messages, les opérations disponibles et les états d'une tâche confiée à un agent distant. Lancé par Google en 2025, il a rejoint la Linux Foundation, ce qui le place sous une gouvernance neutre, à l'image de ce qui s'est fait pour d'autres standards d'infrastructure. La version 1.0 en est la première spécification stable : elle apporte la prise en charge de plusieurs protocoles de transport, le multi-tenant, des flux de sécurité modernisés, les Agent Cards signées et un chemin de migration pour les premiers adopteurs.

L'idée centrale est celle de l'agent opaque (« blackbox »). Un agent client n'a pas besoin de connaître le modèle, les prompts, les outils ou le framework de l'agent distant. Il lui suffit de savoir ce qu'il sait faire et comment lui parler. Cette opacité protège la propriété intellectuelle de chaque équipe et permet de faire collaborer un agent construit avec LangGraph, un autre avec ADK et un troisième hébergé chez un fournisseur tiers.

Le protocole repose sur quelques notions :

• Client et serveur A2A : l'agent qui délègue joue le rôle de client, l'agent qui exécute celui de serveur
• Agent Card : le document JSON qui décrit l'identité, les compétences et les modalités d'accès d'un agent
• Task : l'unité de travail confiée à un agent, avec un identifiant et un état
• Message : un tour d'échange entre client et serveur, composé de parts (texte, fichier ou données structurées)
• Artifact : le résultat produit par l'agent à l'issue d'une tâche

Cette approche est particulièrement utile dans les architectures de systèmes multi-agents, où les agents ne s'exécutent plus tous dans le même processus ni sous la responsabilité de la même équipe.

A2A et MCP : deux protocoles complémentaires

Une confusion fréquente consiste à opposer A2A et MCP. En réalité, ils ne se situent pas au même niveau de la pile. MCP connecte un agent à ses outils et à ses données : un serveur MCP expose des fonctions déterministes (interroger une base, lire un fichier, appeler une API) que le LLM invoque par tool calling. A2A, lui, connecte un agent à d'autres agents, c'est-à-dire à des entités capables de raisonner, de négocier et de travailler sur plusieurs tours.

Le schéma ci-dessus, issu de la documentation officielle, résume la répartition des rôles. Le tableau suivant détaille les différences.

En pratique, les deux se combinent. Un agent de support reçoit une demande client, délègue l'analyse d'une facture à un agent comptable via A2A, tandis que ce dernier interroge l'ERP de l'entreprise via un serveur MCP. Il serait d'ailleurs possible d'exposer un agent comme un simple outil MCP, mais on perdrait alors la notion de tâche longue, les états intermédiaires et les demandes de précision, que A2A gère nativement.

Agent Cards et découverte

Avant de déléguer, un agent client doit savoir qui peut faire quoi. A2A répond avec l'Agent Card, un document JSON publié par chaque agent serveur. Par convention, il est disponible à l'adresse /.well-known/agent-card.json du domaine de l'agent. Le client le télécharge, lit les compétences annoncées et décide s'il peut s'en servir.

Une Agent Card minimale ressemble à ceci :

{
  "name": "Agent comptable",
  "description": "Analyse des factures fournisseurs et détection d'anomalies.",
  "supportedInterfaces": [
    {
      "url": "https://compta.exemple.fr/a2a/v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "version": "1.2.0",
  "capabilities": {"streaming": true, "pushNotifications": false},
  "defaultInputModes": ["text/plain", "application/pdf"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "analyse-facture",
      "name": "Analyse de facture",
      "description": "Extrait les montants et signale les écarts avec le bon de commande.",
      "tags": ["facture", "comptabilité"]
    }
  ]
}

Plusieurs champs méritent attention. supportedInterfaces indique les points d'accès et le transport utilisé pour chacun. capabilities précise les fonctionnalités optionnelles (streaming, notifications push, carte étendue réservée aux clients authentifiés). skills décrit les compétences, ce qui permet à un agent orchestrateur de choisir le bon interlocuteur, par exemple en soumettant les descriptions au LLM. La carte contient aussi les securitySchemes, qui indiquent comment s'authentifier.

La découverte peut se faire de plusieurs manières : en connaissant le domaine de l'agent, via un registre interne qui référence les cartes de l'entreprise, ou par configuration directe. La version 1.0 ajoute les Agent Cards signées, dont l'authenticité peut être vérifiée cryptographiquement. Cela limite le risque d'usurpation d'un agent, un point important quand les agents s'appellent entre organisations.

À lire : découvrez notre formation Agentic AI

Cycle de vie d'une tâche

Contrairement à un appel d'outil, la délégation à un agent est rarement instantanée. Il peut devoir interroger plusieurs sources, attendre une validation humaine ou demander une précision. A2A modélise cela avec la notion de Task, qui traverse une série d'états.

Les états principaux sont les suivants :

• SUBMITTED : la tâche est reçue par le serveur
• WORKING : l'agent la traite activement
• INPUT_REQUIRED : l'agent a besoin d'une information supplémentaire du client ou de l'utilisateur
• AUTH_REQUIRED : une authentification complémentaire est nécessaire pour poursuivre
• COMPLETED, FAILED, CANCELED, REJECTED : états terminaux, la tâche est finie et ne peut plus évoluer

Dans la spécification, ces valeurs portent le préfixe TASK_STATE_ (par exemple TASK_STATE_COMPLETED). Les états INPUT_REQUIRED et AUTH_REQUIRED sont dits « interrompus » : la tâche est suspendue en attendant le client, qui peut la reprendre en envoyant un nouveau message avec le même taskId. Le contextId permet de regrouper plusieurs tâches et messages appartenant à une même conversation.

Le résultat de la tâche est livré sous forme d'artifacts, construits à partir de parts. Les messages servent à communiquer pendant l'exécution (précisions, statuts), tandis que le livrable final se trouve dans les artifacts. Cette séparation facilite le traitement côté client, qui sait où trouver la réponse.

Les principales opérations exposées par le protocole sont :

• SendMessage : envoie un message et renvoie soit une tâche, soit un message direct
• SendStreamingMessage : même principe, avec un flux de mises à jour en temps réel
• GetTask et ListTasks : consultent l'état d'une ou plusieurs tâches
• CancelTask : demande l'annulation d'une tâche
• SubscribeToTask : se rattache au flux d'une tâche en cours

Pour les tâches très longues, le streaming laisse place aux notifications push : le client enregistre une URL de webhook et le serveur y envoie les changements d'état, sans qu'une connexion reste ouverte. On retrouve ici des problématiques proches de celles décrites dans l'article sur la gestion de l'état des agents IA.

Transports : JSON-RPC, gRPC et HTTP+JSON

A2A sépare le modèle de données des protocoles de transport. La spécification 1.0 définit trois liaisons (bindings) fonctionnellement équivalentes :

Un agent peut annoncer plusieurs interfaces dans son Agent Card, et le client choisit celle qu'il maîtrise. Le choix ressemble à celui décrit dans notre comparatif gRPC vs REST : JSON-RPC et HTTP+JSON privilégient la simplicité et la lisibilité, gRPC la performance et le typage strict, ce qui en fait un bon candidat pour des agents qui communiquent à l'intérieur d'un même cluster. La version du protocole est signalée par l'en-tête A2A-Version, ce qui permet de faire évoluer la spécification sans casser les clients existants.

Sécurité des échanges entre agents

Faire dialoguer des agents autonomes, parfois entre organisations, élargit la surface d'attaque. A2A ne réinvente pas la sécurité : il s'appuie sur les mécanismes web standards et laisse l'Agent Card déclarer ceux qu'il exige. Les schémas pris en charge sont la clé d'API, l'authentification HTTP (Bearer, Basic), OAuth 2.0 (Authorization Code, Client Credentials, Device Code), OpenID Connect et le TLS mutuel (mTLS).

Plusieurs bonnes pratiques s'imposent :

• Authentification à chaque appel : le jeton est transmis dans les en-têtes HTTP, jamais dans le corps du message
• Moindre privilège : utiliser des scopes OAuth limités aux compétences réellement nécessaires
• Vérification des Agent Cards : privilégier les cartes signées et ne déléguer qu'à des agents de confiance
• Validation des entrées et sorties : un agent distant reste une source non fiable, ses artifacts peuvent contenir une prompt injection
• Garde-fous : appliquer les guardrails aux messages reçus avant de les confier à un LLM
• Isolation des tenants : la multi-location introduite en 1.0 permet de séparer les données de plusieurs clients sur un même serveur

Le dernier point est souvent sous-estimé : un agent distant qui reçoit des données sensibles doit être traité comme n'importe quel sous-traitant, avec les mêmes exigences de traçabilité et d'audit.

Exemple : un agent qui délègue une tâche via A2A

Mettons le tout en pratique avec un agent orchestrateur qui confie l'analyse d'une facture à l'agent comptable décrit plus haut. Pour rester indépendant de toute version de SDK, l'exemple utilise directement le transport JSON-RPC avec httpx. Les SDK officiels (Python, JavaScript, Java, Go, .NET) et ADK encapsulent ces échanges.

import uuid
import httpx

AGENT_URL = "https://compta.exemple.fr"


def decouvrir_agent(base_url: str) -> dict:
    """Télécharge l'Agent Card publiée par l'agent distant."""
    reponse = httpx.get(f"{base_url}/.well-known/agent-card.json")
    reponse.raise_for_status()
    return reponse.json()


def deleguer(card: dict, texte: str, token: str) -> dict:
    """Envoie une tâche à l'agent via JSON-RPC et renvoie la réponse."""
    interface = next(
        i for i in card["supportedInterfaces"] if i["protocolBinding"] == "JSONRPC"
    )
    payload = {
        "jsonrpc": "2.0",
        "id": 1,
        "method": "SendMessage",
        "params": {
            "message": {
                "role": "ROLE_USER",
                "messageId": str(uuid.uuid4()),
                "parts": [{"text": texte}],
            }
        },
    }
    reponse = httpx.post(
        interface["url"],
        json=payload,
        headers={"Authorization": f"Bearer {token}", "A2A-Version": "1.0"},
        timeout=60,
    )
    reponse.raise_for_status()
    return reponse.json()["result"]


card = decouvrir_agent(AGENT_URL)
print("Compétences :", [s["id"] for s in card["skills"]])

resultat = deleguer(card, "Analyse la facture F-2026-0412 et signale les écarts.", token="...")
tache = resultat.get("task")
if tache:
    print("État :", tache["status"]["state"])

Le code suit les étapes du protocole : découverte de la carte, choix de l'interface compatible, envoi du message avec le jeton d'authentification, puis lecture de la réponse. Selon l'agent, le résultat est un message direct ou une tâche. Si l'état est TASK_STATE_INPUT_REQUIRED, l'orchestrateur renvoie un nouveau message en reprenant le taskId pour apporter la précision demandée. Si l'état est TASK_STATE_WORKING, il interroge la tâche avec GetTask ou s'abonne au flux.

Côté orchestrateur, un LLM peut jouer le rôle de routeur : il reçoit les descriptions de compétences de plusieurs Agent Cards et choisit à qui déléguer, selon le même principe qu'un superviseur d'agents. On obtient un réseau d'agents dont les membres restent indépendants et remplaçables.

À découvrir : notre formation Agentic AI

Conclusion

Le protocole A2A apporte aux systèmes multi-agents ce qui leur manquait pour sortir du prototype : un langage commun pour découvrir, mandater et suivre des agents hétérogènes. Avec les Agent Cards, un agent publie ses compétences et ses exigences de sécurité. Avec le modèle de tâche, il gère les traitements longs, les demandes de précision et les livrables sous forme d'artifacts.

Sa complémentarité avec MCP est la clé de lecture : MCP relie un agent à ses outils, A2A le relie à ses pairs. Une architecture agentique moderne combine les deux, avec des transports adaptés au contexte (JSON-RPC ou HTTP+JSON pour la simplicité, gRPC pour la performance) et une sécurité fondée sur OAuth 2.0, OpenID Connect ou mTLS.

La stabilisation en version 1.0, la gouvernance de la Linux Foundation et l'adoption par Google, Microsoft et AWS réduisent le risque d'investir dans le standard. Pour un AI Engineer, savoir concevoir des agents interopérables, exposables et sécurisés devient une compétence différenciante à mesure que les entreprises déploient des agents à l'échelle de plusieurs équipes, voire de plusieurs organisations.