Avec la version 0.3, Google Cloud muscle le protocole Agent2Agent

Dorénavant géré par la Fondation Linux, le protocole open source Agent2Agent passe en version 0.3. Cette dernière introduit le support gRPC, une sécurité renforcée et des fonctions axées développeurs.
Google Cloud reste un des principaux contributeurs du protocole Agent2Agent (A2A) qu’il avait présenté à Next en avril 2025. Il vient d’annoncer la version 0.3 du projet open source désormais chapeauté par la Fondation Linux. La dernière itération propose plusieurs évolutions et améliorations sur le plan fonctionnel et sécurité. En premier lieu, le fournisseur de cloud a annoncé le support du gRPC, un framework open source développé par la firme de Mountain View. Il vise à assurer la communication entre applications via des appels distants.
Cet outil a la particularité de pouvoir fonctionner de manière très performante, même lorsque les applications se trouvent sur des machines différentes ou sont écrites dans des langages différents. « Les performances élevées du gRPC et la prise en charge de plusieurs langages de programmation en font un outil adapté aux applications complexes et distribuées », a déclaré Stephanie Walter, analyste chez Hyperframe Research. De plus, selon Dion Hinchcliffe, analyste chez The Futurum Group, les capacités de faible latence et de haut débit du framework lorsqu’il est intégré à l’A2A le rendront plus adaptable à l’orchestration multi-agents en temps réel. « Pour les entreprises, le support du gRPC donne la capacité aux agents d’interopérer via un protocole largement adopté et indépendant du langage qui simplifie l’intégration avec les microservices et les architectures cloud natives existantes », a fait remarquer Dion Hinchcliffe.
Des cartes d’identités sécurisées des agents
Pour stimuler encore un peu plus l’adoption de son protocole par les entreprises, Google a introduit dans A2A une capacité de signature des cartes de sécurité. « Celle-ci est essentielle pour les développeurs et les grandes entreprises, en particulier les entreprises du Fortune 500, car elles ne déploieront pas d’agents qui ne peuvent pas prouver leur identité de manière cryptographique », a rappelé Paul Chada, cofondateur de DoozerAI, une plateforme de travailleurs numériques alimentés par des agents.
De la même manière, Stéphanie Walters pense que « cette capacité de sécurité va aider les entreprises à s’assurer de la bonne application des politiques appropriées de contrôle d’accès et d’exécution. Ainsi, elles se protégeront contre une attaque qui pourrait nuire à la réputation, exposer des secrets commerciaux ou avoir un impact négatif sur le résultat net ». Elle ajoute que « les développeurs peuvent aussi utiliser cette fonctionnalité pour s’assurer que tout agent, en particulier ceux qui ne sont pas écrits par l’entreprise, provient d’une source fiable ».
Intégration de l’A2A dans l’Agent Development Kit
L’analyste estime par ailleurs que l’intégration par Google d’A2A à son framework open source Agent Development Kit (ADK) pour la création d’agents va accélérer l’intégration et la composabilité des agents pour les entreprises utilisant ADK. « Essentiellement, Google intègre la prise en charge du protocole A2A directement dans ADK, de sorte que les agents construits avec cet outil bénéficient automatiquement des capacités de communication A2A. C’est un peu comme si l’intégration de Slack se faisait directement dans le framework de développement sans avoir besoin d’effectuer un travail d’intégration distinct », a expliqué M. Chada de Doozer.
Le fournisseur a également étendu la prise en charge côté client dans le SDK Python intégré à son kit de développement d’agents. « Cette extension donnera aux développeurs la capacité de créer et de gérer plus facilement des agents A2A à l’aide de Python », a fait remarquer Dion Hinchcliffe. « Pour les entreprises, ce support va fluidifier le développement, car les équipes pourront construire, tester et déployer des flux de travail agentiques plus rapidement tout en restant dans leur chaîne d’outils d’IA existante », poursuit l’analyste. Afin de stimuler la diffusion de l’A2A, Google autorise désormais à ses partenaires de vendre des agents supportés par l’A2A sur sa place de marché AI Agents Marketplace. Il est donc possible d’évaluer les systèmes d’agents qui prennent en charge l’A2A par l’intermédiaire du service d’évaluation Vertex GenAI Evaluation Service.
A2A ou MCP ?
En ce qui concerne les deux protocoles open source qui promettent aux agents de communiquer entre eux, les experts affirment que le Model Context Protocol (MCP) a une longueur d’avance sur l’A2A. « D’après ce que l’on observe dans la communauté des développeurs, le MCP a le vent en poupe en termes de facilité d’utilisation et il est très bien adopté par la communauté », observe Paul Chada. Selon Dion Hinchcliffe, MCP le bénéficie également d’un soutien plus large de la part des fournisseurs et il est plus neutre sur le plan de l’écosystème. Google fait valoir qu’actuellement au moins 150 partenaires l’aident à construire, codifier et adopter l’A2A comme protocole standard pour les agents IA. Cependant, les deux spécialistes sont divisés sur les cas d’usage qui conviennent à chaque protocole. De son côté, M. Hinchcliffe pense que l’A2A est plus adapté aux écosystèmes d’agents liés à la pile de Google, et que le MCP s’adresse plus aux environnements hétérogènes et multifournisseurs dans lesquels les entreprises ont besoin d’interopérabilité entre différents modèles et fournisseurs.
Pour sa part, Paul Chada note que le MCP excelle dans les scénarios d’intégration d’outils à agent unique, tandis que l’A2A cible l’orchestration multi-agents dont les entreprises ont réellement besoin. « Le MCP est plus réputé auprès des développeurs, mais l’A2A dispose des partenariats d’entreprise qui comptent pour les déploiements à grande échelle. La question est de savoir si les utilisateurs veulent la simplicité ou les fonctionnalités d’entreprise », glisse-t-il. Par contre, les deux experts s’accordent à dire que l’A2A est plus sûr que le MCP. « L’A2A offre actuellement des primitives de sécurité intégrées plus robustes : des cartes de sécurité signées et le réseau zero trust de Google. Il est donc plus facile pour les entreprises de mettre en place des interactions sécurisées avec les agents. La sécurité du MCP est plus flexible, mais nécessite une mise en œuvre minutieuse entre les fournisseurs, ce qui peut introduire des écarts », conclut Dion Hinchcliffe.