A2A : le protocole qui apprend aux agents IA à travailler en équipe

A2A : le protocole qui apprend aux agents IA à travailler en équipe

Les agents IA savent utiliser des outils, mais comment collaborent-ils entre eux ? Le protocole A2A leur donne un langage commun pour se découvrir, se déléguer des tâches et travailler en équipe — comme sur un chantier de construction.

Introduction au concept

Si le concept de protocole A2A te paraît flou, retiens simplement l'image ci-dessous. Elle permet de comprendre l'essentiel en quelques secondes.

A2A_intro.png

Les agents IA deviennent de plus en plus autonomes. Ils raisonnent, planifient, agissent. Mais dès qu'ils doivent collaborer, un problème apparaît.

Chaque entreprise construit ses propres agents, avec ses propres frameworks, ses propres modèles et ses propres conventions. Un agent construit avec LangGraph ne sait pas nativement communiquer avec un agent construit avec CrewAI, ni avec un agent maison développé par une autre équipe.

Résultat : ils savent très bien travailler seuls, beaucoup moins bien travailler ensemble.

Entre eux se trouve le protocole A2A (Agent2Agent).

Pour comprendre son rôle, imagine un chantier de construction.

L'analogie du chantier

Tu veux construire une maison. Tu ne vas pas tout faire toi-même : tu fais appel à un chef de chantier.

Ce chef de chantier ne sait pas tout faire non plus. Il ne sait pas couler une dalle, tirer des câbles électriques ou poser une toiture. En revanche, il sait une chose essentielle : à qui déléguer chaque partie du travail.

À partir de là, observe comment le chantier fonctionne.

Chaque spécialiste affiche ses qualifications

Le maçon, l'électricien et le couvreur ont chacun une carte professionnelle : leur métier, leurs qualifications, leurs coordonnées, leurs conditions de travail. Le chef de chantier consulte ces cartes pour savoir qui contacter et pour quoi.

Dans le monde A2A, cette carte professionnelle s'appelle l'Agent Card. C'est un simple document JSON que chaque agent publie à une adresse standardisée (/.well-known/agent-card.json). Elle décrit son identité, ses compétences, son point d'accès et ses exigences d'authentification.

C'est le mécanisme de découverte : avant de collaborer, un agent commence par lire la carte d'un autre agent pour savoir ce qu'il sait faire.

A2A_analogie.png

Exemple simplifié à but pédagogique. Le schéma exact (avec notamment la distinction entreskillsetcapabilities) est défini dans la spécification officielle A2A.

Le chef de chantier délègue sans regarder par-dessus l'épaule

Quand le chef de chantier confie l'électricité à l'électricien, il ne lui demande pas de détailler chaque geste. Il lui confie une mission, avec un résultat attendu, et il suit l'avancement : commencé, en cours, terminé, ou bloqué en attente d'une information.

Dans A2A, cette mission s'appelle une Task. C'est l'unité de travail fondamentale du protocole. Chaque Task possède un identifiant unique et un cycle de vie précis :

submitted → working → completed / failed / canceled

Avec un état particulier :input-required. Si l'agent a besoin d'une information pour continuer, la tâche se met en pause dans cet état, attend la réponse, puis retourne àworking. Ce n'est pas une étape du flux principal, c'est une boucle — la plupart des tâches ne passent jamais par là.

A2A_task.png

Ce cycle de vie est une des grandes forces du protocole : il est pensé pour les travaux longs. Une tâche peut durer quelques secondes ou plusieurs heures, avec un humain dans la boucle. L'agent qui a délégué peut suivre l'avancement, être notifié, ou fournir l'information manquante qui débloque la tâche — exactement comme un chef de chantier qui passe voir où en est l'électricien et répond à ses questions.

Les ouvriers ne prêtent pas leurs outils

Point crucial de l'analogie : l'électricien travaille avec sa propre caisse à outils. Le chef de chantier ne sait pas quel multimètre il utilise, ni comment il organise son travail en interne. Ça ne le regarde pas : ce qui compte, c'est le résultat.

C'est exactement le principe des agents dans A2A : chaque agent est une boîte noire. Il ne partage ni sa mémoire, ni ses outils, ni sa logique interne. Les agents collaborent uniquement à travers le protocole, sans exposer leur fonctionnement.

Ce choix de conception a deux conséquences importantes : la sécurité (aucun agent n'a accès aux entrailles d'un autre) et la protection de la propriété intellectuelle (une entreprise peut exposer un agent sans révéler comment il est construit).

À la fin, un livrable concret

Quand l'électricien a terminé, il ne rend pas un discours : il livre une installation qui fonctionne, un schéma électrique, un certificat de conformité.

Dans A2A, ce livrable s'appelle un Artifact: le résultat concret et structuré d'une Task. Ça peut être un document, une image, des données JSON — le protocole est multi-modal par conception.

Comment les agents se parlent concrètement

Derrière l'analogie, la mécanique repose sur des technologies que tu utilises déjà tous les jours en tant que développeur web. Pas de protocole exotique à apprendre.

A2A fonctionne sur HTTP(S), avec JSON-RPC 2.0 comme format d'échange. Trois modes de communication existent selon la durée de la tâche :

Requête/réponse avec polling: pour les tâches rapides. L'agent client envoie la mission et vérifie régulièrement son état.

Streaming via Server-Sent Events (SSE): pour suivre une tâche en temps réel, événement par événement.

Notifications push via webhook: pour les tâches très longues. L'agent distant préviendra quand ce sera terminé, inutile d'attendre.

Chaque échange à l'intérieur d'une Task passe par des Messages, qui portent un rôle (userouagent) et un contenu découpé en Parts: du texte, un fichier, des données structurées.

A2A_communication.png

Si tu résumes la pile complète : un agent découvre un autre agent via son Agent Card, lui envoie une Task, échange des Messages composés de Parts, suit le cycle de vie, et reçoit un Artifact. Cinq briques, et tout le protocole tient dedans.

Une nuance importante : A2A ne remplace pas MCP

C'est la confusion la plus fréquente quand on découvre A2A. Google a lancé ce protocole en avril 2025, quelques mois après que le MCP d'Anthropic est devenu un standard de fait. Beaucoup de développeurs ont donc cru à une guerre de protocoles.

En réalité, ils ne jouent pas au même étage.

Le MCP connecte un agent à ses outils: une base de données, une API, un système de fichiers. C'est la télécommande qui permet à un assistant d'agir sur un appareil.

A2A connecte un agent à d'autres agents: des systèmes autonomes qui raisonnent, planifient et maintiennent leur propre état.

Pour le dire avec notre chantier : le MCP, c'est la caisse à outils personnelle de chaque ouvrier. A2A, c'est la façon dont les ouvriers se coordonnent entre eux. Un électricien sans outils ne sert à rien ; des ouvriers qui ne se parlent pas non plus. Une architecture d'agents moderne a besoin des deux couches.

Mais alors, pourquoi Google n'a pas simplement utilisé MCP ?

C'est la question logique. Si MCP existait déjà et fonctionnait, pourquoi créer un second protocole ?

Parce que MCP modélise des outils: des primitives avec des entrées et sorties structurées, souvent sans état, dans un modèle essentiellement synchrone — tu appelles, tu reçois une réponse. Or un agent n'est pas un outil : il est autonome, il maintient un état, il peut poser des questions en retour, et ses tâches peuvent durer des heures.

Forcer un agent à rentrer dans le moule d'un « outil MCP » revient à demander à l'électricien de se comporter comme un tournevis. Techniquement possible, mais on perd tout ce qui fait sa valeur : la négociation, le suivi de mission, l'autonomie. A2A a été conçu précisément pour cette couche-là.

Un article complet comparant les deux protocoles en détail arrivera prochainement sur ce blog.

Où en est A2A aujourd'hui

Le protocole a connu une trajectoire rare pour un standard aussi jeune.

A2A_adoption.png

Lancé par Google en avril 2025 avec plus de 50 partenaires (Salesforce, SAP, ServiceNow, PayPal, MongoDB, LangChain…), il a été donné à la Linux Foundation dès juin 2025 pour garantir une gouvernance neutre — ce n'est plus « le protocole de Google », c'est un standard ouvert de l'industrie. En août 2025, le protocole concurrent d'IBM (ACP) a même fusionné volontairement dans A2A.

La version 1.0, sortie début 2026, a marqué le passage au niveau production, avec notamment les Signed Agent Cards: une signature cryptographique qui garantit qu'une carte d'agent a bien été émise par le propriétaire du domaine. Sans cette protection, un attaquant pourrait publier une fausse carte et détourner des agents vers un imposteur — l'équivalent d'un faux artisan qui se présenterait sur ton chantier avec de faux papiers.

Aujourd'hui, plus de 150 organisations utilisent A2A en production, dont Microsoft, AWS, Salesforce et SAP, avec des SDK officiels en Python, JavaScript, Java, Go et .NET. Les principaux frameworks d'agents (LangGraph, CrewAI, Semantic Kernel, AutoGen) le supportent nativement.

Ce qu'il faut retenir

Les agents IA passent d'expériences isolées à des systèmes qui collaborent. Et dès que plusieurs agents doivent travailler ensemble — surtout s'ils viennent de vendeurs différents — la question de leur langage commun devient bloquante.

A2A répond à cette question avec des idées simples : une carte de visite pour se découvrir (Agent Card), une mission avec un cycle de vie pour déléguer (Task), des échanges structurés (Messages et Parts), un livrable concret (Artifact), et une règle d'or : chaque agent reste une boîte noire.

En 1991, HTTP a permis à des serveurs du monde entier de se parler — et le web est né.

En 2025, A2A est né pour faire exactement la même chose. Mais cette fois, entre des agents IA.

Et comme pour HTTP à l'époque, ceux qui comprennent le protocole maintenant auront une longueur d'avance.

FAQ

C'est quoi le protocole A2A ?

A2A (Agent2Agent) est un standard ouvert, initié par Google et gouverné par la Linux Foundation, qui permet à des agents IA construits sur des frameworks différents de se découvrir, de se déléguer des tâches et de collaborer, sans exposer leur fonctionnement interne.

A2A remplace-t-il MCP ?

Non. MCP connecte un agent à ses outils (bases de données, API, fichiers). A2A connecte des agents entre eux. Les deux protocoles sont complémentaires : une architecture d'agents en production utilise généralement les deux.

Qu'est-ce qu'une Agent Card ?

C'est la carte de visite numérique d'un agent : un document JSON publié à l'adresse/.well-known/agent-card.json, qui décrit son identité, ses compétences, son point d'accès et ses exigences d'authentification. Depuis la v1.0, elle peut être signée cryptographiquement pour empêcher l'usurpation.

Sur quelles technologies repose A2A ?

Sur des standards web classiques : HTTP(S), JSON-RPC 2.0, Server-Sent Events pour le streaming et webhooks pour les notifications. Aucun protocole exotique à apprendre.

Qui utilise A2A en production ?

Plus de 150 organisations, dont Microsoft, AWS, Salesforce et SAP. Des SDK officiels existent en Python, JavaScript, Java, Go et .NET, et les principaux frameworks d'agents (LangGraph, CrewAI, Semantic Kernel, AutoGen) le supportent nativement.

Lire l'article sur sahelstack.tech →