A2A 1.0 : quand les agents IA se parlent entre eux

Le protocole Agent2Agent (A2A) a passé le cap de la version 1.0 au cours de l'été 2026, après un SDK stabilisé dès juin. Porté par Google et une coalition d'acteurs, il vise l'interopérabilité des agents : un agent qui parle à un autre agent, quel que soit le vendeur ou le langage derrière chaque brique.

Pourquoi l'interopérabilité devient critique

A2A relie les îlots : découverte des capacités, délégation, suivi du résultat entre agents.

Les agents isolés créent des îlots : chacun sait faire une tâche dans son couloir, personne ne coordonne l'ensemble. A2A définit un langage commun de découverte, de délégation et de retour d'état. Un agent peut trouver la capacité d'un autre, lui confier une sous-tâche et en suivre le résultat.

Ce que ça change en architecture

Concrètement, l'architecture passe d'un monolithe agentique à une méso-architecture de services : chaque agent expose une carte de capacités, les flux sont composés à la volée, et les échecs sont visibles. C'est le même chemin que les API ont fait pour les services, appliqué aux agents.

Les points de décision pour les équipes

Trois décisions à prendre : quelles capacités exposer, à quels partenaires et systèmes internes, sous quelle gouvernance ; comment sécuriser les échanges entre agents, authentification et traçabilité comprises ; et comment mesurer la qualité des sous-tâches déléguées, car un agent intermédiaire peut masquer les erreurs de l'agent final.

Points de vigilance

La normalisation ne supprime pas la responsabilité : celui qui délègue reste responsable du résultat. Les permissions doivent être explicites et révocables, et les journaux d'échanges conservés pour l'audit, surtout dans les environnements réglementés.

Comment se répartissent MCP et A2A dans une architecture ?

Les deux protocoles répondent à des questions différentes, et les confondre produit des architectures inutilement compliquées.

MCP relie un agent à des ressources : outils, bases, fichiers, services. La relation est verticale — un agent consomme une capacité.

A2A relie un agent à un autre agent : découverte, délégation, suivi d'état. La relation est horizontale — deux systèmes autonomes coopèrent.

En pratique, la plupart des architectures ont besoin du premier bien avant le second. Un agent isolé qui accède proprement à vos systèmes crée de la valeur immédiate. La coordination entre agents ne devient utile qu'à partir du moment où plusieurs agents autonomes existent réellement, appartiennent à des équipes ou des fournisseurs distincts, et doivent se déléguer du travail.

Le piège consiste à adopter une architecture multi-agents avant d'avoir un seul agent qui fonctionne bien. Un système à cinq agents qui se parlent est cinq fois plus difficile à déboguer, et la valeur métier n'augmente pas d'autant.

Les questions que la délégation entre agents rend inévitables

Dès qu'un agent en mandate un autre, quatre questions se posent qui n'existaient pas avant.

L'identité. Sous quelle identité l'agent délégué agit-il — la sienne, ou celle de l'utilisateur d'origine ? La réponse détermine les droits, et donc le périmètre d'un incident.

La propagation des droits. Un agent doit-il transmettre l'intégralité de ses autorisations à celui qu'il mandate ? Presque jamais. La délégation devrait réduire les droits, pas les propager intégralement.

La responsabilité. Si l'agent B produit une erreur à la demande de l'agent A, qui répond ? Sans traçabilité de bout en bout, la question reste sans réponse — et c'est exactement celle qu'un auditeur posera.

La boucle. Deux agents qui se délèguent mutuellement une tâche peuvent boucler indéfiniment. Un compteur de profondeur et un budget maximal par chaîne ne sont pas des optimisations : ce sont des garde-fous.

Ces quatre points relèvent de la conception, pas du protocole. A2A fournit le vocabulaire ; les politiques restent à écrire.

Questions fréquentes

Faut-il adopter A2A maintenant ou attendre ? Attendre d'en avoir l'usage. Un protocole d'interopérabilité ne sert que s'il y a plusieurs parties à faire interopérer. La décision utile aujourd'hui est plus modeste : concevoir vos agents avec une frontière propre — des capacités déclarées, des entrées et sorties typées — pour qu'ils soient interopérables le jour où ce sera nécessaire.

Un protocole standard réduit-il la dépendance à un fournisseur ? En partie. Il rend le remplacement d'un composant plus simple, ce qui est réel. Mais la dépendance se loge surtout ailleurs : dans les prompts affinés, les jeux d'évaluation et la connaissance accumulée. Le protocole résout la plomberie, pas l'enfermement.

Comment déboguer une chaîne d'agents qui échoue ? Par une trace corrélée : un identifiant unique propagé sur toute la chaîne, avec l'enregistrement de chaque délégation, de son entrée, de sa sortie et de sa durée. Sans cela, un échec en bout de chaîne est impossible à attribuer. C'est le même problème que le traçage distribué dans les architectures de microservices, et il appelle les mêmes réponses.

Conclusion actionnable

A2A 1.0 rend pensable une organisation d'agents interopérables. Prochaine étape : identifier deux ou trois agents internes, les exposer via A2A sur un périmètre restreint, et tester un flux composé de bout en bout avant d'élargir.

Pour situer ce sujet dans une démarche complète, Noolya détaille l'intégration de cas d'usage IA en production.

Pour aller plus loin

• DeepSeek-R1-0528 : quand le raisonnement ouvert devient plus intégrable
• Llama 4 : l’open-weight multimodal entre dans l’ère MoE
• Claude 4 : le signal faible d’une IA pensée pour les agents longs

---

Sources principales

• Spécification A2A (Agent2Agent), version 1.0, été 2026

• Google, annonces du SDK A2A et écosystème

• Note Noolya : la maturité des implémentations varie selon les vendeurs.