A2A, le protocole de Google pour faire converser les agents IA entre eux

Comment fonctionne A2A, un « complément » à Model Context Protocol

Plus précisément, A2A est un protocole d’échange entre trois acteurs : un utilisateur qui utilise un système agentique, un client (une application, un agent, un service) qui réclame qu’une action soit effectuée par un autre agent distant (le serveur). Le client et l’agent distant sont connectés par le protocole HTTP. Le SSE peut être utilisé pour envoyer (streamer) des mises à jour de la part de l’agent distant. A2A prend également en charge un modèle asynchrone : l’agent distant peut recevoir des notifications push quand il est déconnecté. JSON-RPC 2.0 est utilisé comme format d’échange de données.

Le premier attribut de l’agent distant n’est autre que sa carte d’agent. Il s’agit ni plus ni moins d’un fichier JSON qui décrit ses fonctionnalités, son rôle et son mécanisme d’authentification.

Ces cartes peuvent être stockées dans un catalogue privé ou publiées à une adresse standard, via un registre DNS. Il s’agit là de permettre leur découverte automatique par les clients. Si le client est un LLM, il peut potentiellement sélectionner le meilleur agent pour accomplir la tâche réclamée par l’utilisateur.

Oui, la communication entre client et agent distant sert en premier lieu à accomplir des tâches. Avec A2A, ces actions ont une durée de vie tout en étant potentiellement évolutives.

« L’agent peut : exécuter immédiatement la requête, planifier son traitement pour plus tard, la rejeter, proposer une autre modalité d’exécution, demander des informations complémentaires au client, ou encore déléguer la tâche à d’autres agents ou systèmes », peut-on lire dans la documentation du projet.

Pour accomplir une tâche, l’agent peut avoir besoin d’un outil. Alors, le framework associé ou le LLM choisi peuvent s’appuyer sur MCP pour l’appeler.

Une fois une tâche accomplie, l’agent génère un ou plusieurs artefacts, les résultats générés dans un fichier JSON. Ces artefacts peuvent être transmis dans le flux d’une autre tâche avec des « messages », c’est-à-dire des cheminements de pensées, des instructions, du contexte utilisateur, des réponses d’échanges précédents, des erreurs ou encore des métadonnées.

« Chaque message comprend des “parties”, qui sont des éléments de contenu entièrement formés, comme une image générée », explique Google. Les tâches peuvent également inclure ces parties.

« Chaque partie a un type de contenu spécifié, ce qui permet au client et aux agents distants de négocier le format correct nécessaire et d’inclure explicitement des négociations sur les capacités de l’interface utilisateur, par exemple les iframes, la vidéo, les formulaires web, etc. ».

« A2A aborde également un défi majeur de l’industrie : permettre aux agents construits sur différents frameworks et plateformes de travailler ensemble. »

Précisons qu’il est d’ores et déjà prévu qu’A2A soit compatible avec les LLM multimodaux : il devrait être possible d’interagir avec les agents à l’aide de message textuel, à la voix, leur transmettre des images ou des flux vidéo.

De son côté, Google donne l’exemple d’un système de recrutement accessible à travers Agentspace permettant à l’utilisateur-recruteur de confier différentes tâches de sélection de candidats, d’organisation et de vérifications d’information aux agents, tout au long du processus.

« A2A aborde également un défi majeur de l’industrie : permettre aux agents construits sur différents frameworks et plateformes de travailler ensemble », assure le porte-parole de Google Cloud.

Sur la page GitHub du projet, les ingénieurs du fournisseur de cloud illustrent la manière d’intégrer A2A dans les frameworks CrewAI, LangGraph, GenKit et Google Agent Development Kit (ADK). Les exemples portent sur la génération d’images, la réponse à des questions sur des films, la conversion actualisée de devises (un cas d’usage pas si évident que cela) et le traitement des dépenses professionnelles. A2A semble principalement compatible avec les langages Python et JavaScript.

Un protocole soutenu par plus de 50 acteurs technologiques, dont SAP, ServiceNow et Salesforce

Mais il faut surtout retenir l’établissement de partenariats entre Google Cloud et plus de 50 partenaires technologiques, dont Atlassian, Elastic, SAP, ServiceNow, Box, Cohere, Datadog, Salesforce, Oracle, MongoDB, Intuit, Mckinsey, Wipro, LangChain ou encore KPMG.

« A2A connecte les agents à travers l’ensemble de l’écosystème de l’entreprise, en leur donnant un langage commun pour collaborer, quel que soit le framework ou la plateforme sur lesquels ils sont construits », affirme Amin Vahdat, vice-président et directeur général Machine Learning, Systems and Cloud AI chez Google Cloud.

« Travailler avec des entreprises telles que Salesforce, ServiceNow et SAP nous permettra d’assurer une communication fonctionnelle entre les agents », ajoute-t-il.

De fait, les porte-parole des éditeurs avec lesquels LeMagIT a pu discuter du sujet, dont Microsoft, Salesforce, ServiceNow, SAP ou Atlassian, sont convaincus que les agents s’inscrivent dans un contexte ou une interface particulière. En clair, l’utilité d’un agent est fonction des données et du contexte auquel il a accès. Et qui de mieux (pensent-ils) que l’éditeur de la solution renfermant ces informations, pour développer ces agents sur étagère ou en guider la conception. Comme dit la fameuse expression, « chacun son métier, les vaches seront bien gardées ». Ces acteurs-là ne rejettent évidemment pas la dimension économique de cette approche.

Eux (les clients) ne veulent pas attendre que ces acteurs s’entendent pour développer des agents manipulant des données en provenance de ces différents SI. A2A ressemble donc à un compromis acceptable.

Entre méfiance et enthousiasme modéré

La collaboration n’est pas encore évidente : huit contributeurs, des ingénieurs chez Google Cloud, ont pour l’instant participé à la conception du projet. A2A est directement géré par Google LLC. Ce qui n’a pas tardé à attiser les méfiances.

« Pour moi, il semble que Google essaie de créer son propre référentiel d’agents, en contrôlant le protocole, ce qui lui permet de devenir la source de facto pour trouver des agents de confiance. »

« Le fait qu’A2A n’ait pas été proposé comme une extension de MCP semble au mieux fallacieux », lance sur X Alan Braithwaite, cofondateur de RunReveal, éditeur d’une plateforme qui promet de simplifier le SIEM. « Pour moi, il semble que Google essaie de créer son propre référentiel d’agents, en contrôlant le protocole, ce qui lui permet de devenir la source de facto pour trouver des agents de confiance ».

LeMagIT a demandé au porte-parole cité plus haut si le groupe avait pour ambition de confier A2A à une fondation open source. « Notre objectif actuel est de lancer ce protocole et de le voir gagner le soutien de la communauté la plus large possible », répond-il.

À l’heure d’écrire ces lignes, le dépôt GitHub a tout de même récolté plus de 600 étoiles et été forké plus de 30 fois. Reste à voir comment le fournisseur gérera les pull requests.

« Il faudra voir plus d’exemples concrets avant de s’emballer, mais d’après la liste des fournisseurs réunie par Google, il semble que ce soit une solution gagnante », réagit pour sa part Lee Mager, responsable du développement de l’innovation en matière d’IA à la London School of Economics.