Protocole A2A de Google en 2026 : adoption, engouement et réalité

A2A n'est pas mort. Il n'est simplement pas universel.

Sommaire

Le protocole Agent2Agent de Google, généralement abrégé en A2A, a connu une première année étrange.

Lorsque Google a annoncé A2A en avril 2025, la proposition était claire : les agents IA construits par différents fournisseurs, cadres (frameworks) et équipes avaient besoin d’une manière standardisée de communiquer. Le protocole promettait la découverte d’agents, la délégation de tâches, l’échange de messages, les mises à jour en continu (streaming) et le partage d’artefacts. La réaction, cependant, a été considérablement moins nette que l’annonce.

Certains développeurs voyaient en A2A la couche manquante d’interconnexion entre agents pour la stack agémique émergente. D’autres y voyaient un autre protocole Google, un autre acronyme, et une nouvelle tentative de définir un marché avant que celui-ci n’ait de besoins réels de production. L’approche sceptique se résumait en une seule question : « Nous avons déjà MCP. Pourquoi avons-nous besoin d’A2A ? » C’était une question légitime en 2025, et elle reste légitime en 2026 — bien que la réponse ait évolué considérablement.

Deux systèmes d’agents IA connectés par le pont du protocole A2A

A2A n’est pas mort, mais il n’est pas non plus universellement utile. La réalité pratique est qu’A2A devient réellement précieux dans un contexte spécifique : là où les agents sont des systèmes indépendants avec leur propre propriété, leurs propres outils et leurs propres frontières de confiance, plutôt que de simples fonctions internes ou enveloppes d’outils. Cette distinction entre l’intégration d’outils et la délégation d’agents est ce que le protocole est réellement conçu pour adresser, et la comprendre est la clé pour évaluer A2A sans se laisser emporter par l’hype, quelle que soit sa direction.

Qu’est-ce que le protocole A2A de Google ?

A2A signifie Agent2Agent Protocol, et ce nom capture précisément son objectif. C’est une norme ouverte pour la communication et l’interopérabilité entre des systèmes d’agents IA indépendants — spécifiquement, des agents qui peuvent être construits à l’aide de cadres, de langages ou de stacks de fournisseurs différents.

A2A ne concerne pas principalement la connexion d’un agent à une base de données, un système de fichiers, un calendrier, une API ou un index de recherche. Cela ressemble davantage au travail de MCP, le Model Context Protocol. A2A concerne quelque chose de différent : un agent communiquant avec un autre agent, traitant le système pair comme un acteur disposant de ses propres capacités plutôt que comme une source de données passive.

Un flux A2A typique pourrait impliquer :

La découverte d’un agent via une Agent Card (Carte d’agent)
La lecture des compétences et capacités de l’agent
L’envoi d’une tâche
L’échange de messages
La réception de mises à jour de statut
La gestion des états nécessitant une saisie (input-required)
La réception d’artefacts finaux
Le suivi de l’achèvement, de l’échec ou de l’annulation

Le mot important dans cette liste est « tâche ». A2A n’est pas simplement un appel de fonction avec une enveloppe différente — c’est un protocole de cycle de vie des tâches pour la collaboration entre agents, conçu pour gérer l’ensemble du cycle, de la découverte et de la délégation à l’exécution, aux mises à jour de statut et au retour des artefacts. Pour un examen technique approfondi de chaque concept — Agent Cards, cycle de vie des tâches, messages, parties et artefacts — consultez Qu’est-ce que le protocole A2A ? Explication des Agent Cards et des Tâches. Pour savoir comment le streaming, les notifications push et les pauses humaines (human-in-the-loop) fonctionnent en production, consultez Streaming A2A et Tâches Asynchrones pour les Workflows d’Agents Longs.

Pourquoi A2A a été facile à moquer

A2A est arrivé sur un marché déjà noyé sous les acronymes d’agents.

D’ici 2025, les développeurs étaient déjà confrontés à :

Les API LLM
L’appel de fonctions (Function calling)
L’appel d’outils (Tool calling)
Les frameworks d’agents
Les serveurs MCP
Les pipelines RAG
Les moteurs de workflows
Les bibliothèques d’orchestration multi-agents
Les protocoles JSON personnalisés
Les systèmes de plugins internes

Ainsi, lorsque Google a annoncé A2A, une réaction courante était prévisible :

« Avons-nous vraiment besoin d’une autre norme ? »

Le scepticisme n’était pas irrationnel, et il venait de plusieurs directions à la fois. A2A semblait chevaucher MCP. Il venait de Google, ce qui inquiétait certains développeurs quant à l’engagement à long terme. Il est arrivé avant que la plupart des équipes n’aient même résolu l’accès aux outils, l’injection de prompts, l’observabilité, le contrôle des coûts et la sécurité pour les systèmes à agent unique.

Dans cet environnement, « l’interopérabilité agent-à-agent » semblait ambitieuse, mais aussi un peu prématurée.

Et pour être franc, de nombreuses démos d’agents IA en 2025 n’avaient pas du tout besoin d’A2A.

Elles avaient besoin de meilleurs prompts, de meilleurs outils, de meilleures permissions, d’une meilleure logique de réessai et de meilleurs logs.

La mise à jour 2026 : A2A n’est pas mort

Le grand changement en 2026 est qu’A2A n’est plus seulement une annonce de Google.

D’ici avril 2026, la Linux Foundation a rapporté que le projet A2A avait dépassé les 150 organisations soutenant le projet, avait obtenu des intégrations majeures avec les plateformes cloud et avait atteint des déploiements de production dans plusieurs industries.

Cela ne signifie pas que chaque affirmation doit être acceptée sans scepticisme. « Soutenu par » n’est pas la même chose que « profondément utilisé en production par la plupart des développeurs ». Les écosystèmes de protocoles semblent souvent plus grands dans les communiqués de presse qu’ils ne le paraissent dans le travail d’ingénierie quotidien.

Le signal compte, cependant, car il est plus difficile à ignorer. A2A a franchi une ligne importante : ce n’est plus seulement un article de blog de Google. Il a une spécification formelle, une dynamique de gouvernance, des exemples publics, des travaux sur les SDK, l’attention des plateformes cloud et un écosystème croissant autour de l’interopérabilité des agents. Cela rend l’étiquette « mort » difficile à défendre sur des bases techniques ou d’adoption.

Une critique plus défendable est qu’A2A est vivant, mais que son champ d’application utile est plus étroit que ce que suggère l’hype.

A2A vs MCP : La confusion qui ne voulait pas mourir

La plupart des confusions autour d’A2A viennent de sa relation avec MCP.

MCP, créé par Anthropic, normalise la manière dont les applications IA se connectent aux outils et sources de données externes. Les serveurs MCP exposent des outils, des ressources et des prompts. Les hôtes et clients IA les consomment.

En termes simples :

MCP connecte les agents aux outils.
A2A connecte les agents à d’autres agents.

Cela semble clair, mais le monde réel est considérablement plus chaotique. Un serveur MCP peut exposer quelque chose qui ressemble beaucoup à un agent — par exemple, un outil MCP nommé research_company qui exécute internement une recherche, une récupération, une résumé, un classement et la rédaction d’un rapport. Du point de vue de l’hôte MCP, c’est un outil. Du point de vue de l’architecture, cela cache un workflow semblable à un agent derrière une frontière d’appel de fonction. Cette ambiguïté est précisément la raison pour laquelle certains développeurs affirmaient qu’A2A était inutile : si un agent peut être représenté comme un outil MCP, pourquoi créer un protocole séparé ?

La réponse est qu’A2A donne une structure de premier ordre à des choses que MCP traite plus maladroitement :

La découverte d’agents
Les capacités des agents
Le cycle de vie des tâches
Le travail de longue durée
L’état des tâches multi-tours
La messagerie agent-à-agent
Les artefacts
La collaboration entre agents opaques
La délégation à travers les frontières organisationnelles

MCP peut envelopper beaucoup de choses, mais envelopper tout sous forme d’outil finit par devenir une mauvaise abstraction. À un certain point, un système spécialisé a suffisamment de son propre état, de ses propres politiques, de son propre cycle de vie et de son propre pouvoir de décision pour que le modéliser comme un outil obscurcisse l’architecture plutôt que de la simplifier. C’est le point d’inflexion où traiter un agent pair comme un agent pair — plutôt que comme un appel d’outil — commence à porter ses fruits. Pour une comparaison détaillée de l’endroit où la frontière se situe en pratique, consultez A2A vs MCP : Les agents IA ont-ils vraiment besoin des deux protocoles ?

Le meilleur modèle mental : MCP en dessous, A2A au-dessus

L’architecture la plus propre n’est pas « A2A vs MCP ».

L’architecture la plus propre est stratifiée :

flowchart TD U["Utilisateur ou application"] O["Assistant principal / orchestrateur"] S1["Agent spécialisé A"] S2["Agent spécialisé B"] T1["Outils, API, fichiers, bases de données"] T2["Plus d'outils et sources de données"] U --> O O -->|A2A| S1 O -->|A2A| S2 S1 -->|MCP| T1 S2 -->|MCP| T2

Dans ce modèle :

A2A est la couche de collaboration entre agents.
MCP est la couche d’intégration des outils.

C’est le modèle qui a le plus de sens en 2026, et c’est le cadre vers lequel la plupart des architectes d’agents sérieux convergent. A2A ne devrait pas remplacer MCP, et MCP ne devrait pas être forcé de représiter chaque frontière d’agent — ils résolvent des problèmes différents à différentes couches de la stack. Le cadre de la « guerre des protocoles » est principalement une analyse paresseuse qui fait de bons titres tout en ne faisant rien pour aider les ingénieurs à concevoir de meilleurs systèmes.

Où A2A est réellement utile

A2A devient utile lorsqu’un agent n’est plus seulement un appel de bibliothèque à l’intérieur de votre application.

Il est utile lorsque les agents sont :

Déployés indépendamment
Possédés par différentes équipes
Construits avec différents frameworks
Exposés par des fournisseurs
Exécutés avec leurs propres outils et permissions
Responsables de tâches de longue durée
Retournant des artefacts plutôt que de simples valeurs
Partie d’un workflow multi-agents plus large

Par exemple, imaginez un assistant d’entreprise qui doit préparer un rapport de risque fournisseur.

Il pourrait déléguer le travail à :

Un agent d’approvisionnement
Un agent de révision juridique
Un agent financier
Un agent de conformité
Un agent de recherche de marché
Un agent de rédaction de rapports

Chaque agent a son propre domaine, outils, règles, permissions et exigences d’audit.

Pour ce type de système, A2A n’est pas absurde. C’est une frontière raisonnable.

L’assistant principal ne devrait pas avoir besoin d’un accès direct à chaque base de données d’approvisionnement, stockage de politiques juridiques, tableur financier et workflow de conformité. Il devrait demander à l’agent responsable d’effectuer la tâche.

C’est la distinction essentielle : l’accès aux outils est une connexion verticale entre un agent et ses ressources, tandis que la délégation de domaine est un transfert horizontal entre agents autonomes, chacun avec sa propre frontière d’autorité et de responsabilité. Le modèle stratifié de la manière dont ces composants se combinent — LLM, mémoire, outillage, routage et observabilité — est couvert dans Architecture d’Assistant IA : LLM, Mémoire, Outils, Routage, Observabilité.

Où A2A est encore surhypé

A2A est surhypé lorsque les gens le présentent comme une infrastructure obligatoire pour chaque projet IA.

La plupart des projets n’en ont pas besoin.

Si vous construisez un assistant de codage local, un chatbot pour votre documentation, un petit agent d’automatisation interne ou un workflow unique qui appelle une poignée d’outils, A2A est probablement inutile.

Vous pourriez avoir besoin de :

MCP
De bons schémas d’outils
De garde-fous (Guardrails)
D’évaluation
De journalisation (Logging)
Du contrôle des coûts
De la logique de réessai
De meilleurs prompts
D’une meilleure récupération (retrieval)

Vous n’avez probablement pas besoin d’un protocole complet agent-à-agent.

A2A peut être une erreur lorsque :

Il n’y a qu’un seul agent
Tous les composants vivent dans une même base de code
Les workflows sont courts et synchrones
Les agents n’ont pas besoin de découverte
Les agents n’ont pas besoin d’un état de tâche indépendant
Il n’y a pas de fournisseurs d’agents externes
Une API ou une file d’attente serait plus simple
L’équipe ne peut pas gérer la complexité supplémentaire

Un protocole n’est pas gratuit. Il ajoute des concepts, des modes de défaillance, une surcharge de débogage, des préoccupations de sécurité et du travail opérationnel.

Dans de nombreux petits systèmes, adopter A2A est du cosplay architectural — emprunter le vocabulaire des systèmes d’agents distribués sans aucun des problèmes réels de frontières qui rendent le protocole précieux.

A2A et le problème Google

Une partie du scepticisme envers A2A vient de Google lui-même.

Les développeurs ont une longue mémoire. Lorsque Google lance une plateforme, un protocole, un produit ou un écosystème, de nombreux ingénieurs demandent immédiatement :

« Existera-t-il encore dans trois ans ? »

Cette réaction n’est pas tout à fait juste envers la conception technique d’A2A, mais c’est un facteur d’adoption réel.

L’histoire d’hébergement par la Linux Foundation aide ici. Le fait qu’A2A devienne partie intégrante d’un environnement de gouvernance ouverte plus large le rend moins dépendant des priorités internes de Google.

Cela ne garantit pas le succès. La gouvernance ouverte ne crée pas magiquement l’adoption par les développeurs. Mais cela réduit l’une des plus grandes préoccupations : qu’A2A soit seulement un mouvement stratégique contrôlé par Google.

En 2026, A2A devrait être jugé moins comme « le protocole de Google » et plus comme une norme émergente d’interopérabilité des agents que Google a aidé à démarrer.

C’est une perspective plus saine, et c’est celle qui rend les mérites techniques d’A2A plus faciles à évaluer sur leurs propres termes plutôt que à travers le filtre de la relation historique de Google avec les écosystèmes de développeurs.

Adoption : Signal fort, mais pas l’histoire complète

Les 150+ organisations soutenantes rapportées sont significatives, mais cela ne doit pas être confondu avec une adoption universelle par les développeurs. « Soutenu par » est un spectre, pas un binaire, et il aide de lire les affirmations d’adoption avec cela en tête.

À l’extrémité la plus faible se trouve l’adoption par logo : une entreprise dit qu’elle soutient la norme, ce qui peut refléter une implémentation réelle, un positionnement stratégique, un prototype, ou simplement un soutien prévu qui ne s’est pas matérialisé. Un peu plus fort est l’adoption des SDK, où les développeurs peuvent réellement construire avec des bibliothèques, exemples et documentation disponibles — cela signifie que le protocole est passé des diapositives à une implémentation fonctionnelle, et que de vrais ingénieurs ont trouvé cela de leur temps. Plus fort encore est l’adoption de plateforme, où les clouds, les frameworks d’agents et les systèmes d’entreprise exposent un support natif réel, rendant A2A un choix architectural par défaut plausible plutôt que quelque chose que les équipes doivent assembler elles-mêmes.

Le seul niveau d’adoption qui compte vraiment pour la santé à long terme de l’écosystème est la rétention en production. Pour une idée de ce à quoi ressemblent les courbes d’adoption réelles dans l’espace des agents IA — mesurées en étoiles GitHub, jetons OpenRouter et tendances de téléchargement — les données de popularité OpenClaw vs Hermes Agent montrent à quelle vitesse la dynamique se construit et atteint un plateau une fois que l’énergie des premiers adopteurs s’estompe. : équipes s’appuyant sur le protocole pour des workflows en direct au-delà de la lune de miel initiale de 90 jours. La mise à jour de la Linux Foundation de 2026 revendique une utilisation en production dans plusieurs industries, ce qui est une preuve significative. Mais la question plus utile n’est pas « qui soutient A2A ? » — c’est « qui garde A2A en production après le premier incident opérationnel réel ? » La rétention à long terme sous pression est le signal qui sépare l’infrastructure genuine du théâtre protocolaire.

Le vrai test : La rétention en production

L’hype des développeurs est bon marché, et la rétention en production est coûteuse. Les deux sont rarement proportionnels, c’est pourquoi la question de la rétention à 90 jours importe plus que l’enthousiasme de la semaine de lancement.

A2A se prouvera si les équipes continuent de l’utiliser après avoir rencontré :

Des problèmes d’authentification
Des problèmes d’autorisation
Des problèmes d’identité d’agent
Des problèmes de débogage
Des cas limites du cycle de vie des tâches
Des échecs de streaming
La compatibilité des versions
Les différences entre fournisseurs
Des surprises de coût
Des revues de sécurité
Des exigences d’audit
Des workflows d’approbation humaine

C’est là que de nombreux frameworks et protocoles d’agents échouent. Ils semblent élégants sur les diagrammes, puis deviennent douloureux en production.

A2A a une bonne raison d’exister, mais les bonnes raisons ne se traduisent pas automatiquement en résilience de production. Le protocole doit survivre à la réalité opérationnelle qu’il rencontre sur le chemin de la démo au déploiement.

Le meilleur signe pour A2A en 2026 n’est pas que les gens écrivent des articles de blog à son sujet. Le meilleur signe est que les entreprises commencent à l’utiliser pour de véritables frontières multi-agents.

Le pire signe serait si les développeurs ne l’utilisaient que dans des démos tandis que les systèmes de production revenaient aux API et files d’attente personnalisées.

La sécurité est la plus grande question non résolue

Les problèmes les plus difficiles d’A2A ne sont pas des problèmes de syntaxe ou de spécification. Ce sont des problèmes de confiance qui émergent lorsque vous déployez réellement des agents autonomes à travers des frontières organisationnelles ou systémiques.

Lorsqu’un agent parle à un autre agent, plusieurs questions deviennent urgentes :

Qui est cet agent ?
Qui le possède ?
Qu’a-t-il le droit de savoir ?
Qu’a-t-il le droit de faire ?
Peut-il déléguer le travail plus loin ?
Peut-il appeler des outils au nom d’un utilisateur ?
Peut-il préserver l’intention de l’utilisateur ?
Peut-il prouver ce qui s’est passé ?
Peut-il être audité après l’achèvement de la tâche ?

Ces questions ne sont pas optionnelles dans les environnements d’entreprise.

A2A facilite la collaboration entre agents. Il crée également de nouveaux endroits où la confiance peut se briser.

Par exemple :

Un agent malveillant pourrait fausser ses capacités.
Un agent compromis pourrait demander un contexte sensible.
Une tâche déléguée pourrait dépasser l’autorité de l’utilisateur.
Un agent pourrait retourner des artefacts empoisonnés.
Une chaîne d’agents pourrait rendre la responsabilité floue.
Des données sensibles pourraient circuler à travers les frontières sans journalisation appropriée.

C’est pourquoi les systèmes A2A sérieux ont besoin de plus que la conformité au protocole.

Ils ont besoin de :

Une identité d’agent forte
Une autorisation scoped (limitée à un périmètre)
Des journaux d’audit au niveau des tâches
Un suivi de la délégation
Une approbation humaine pour les actions risquées
La provenance des artefacts
Des limites de débit (Rate limits)
L’application des politiques
L’observabilité à travers les frontières des agents

A2A n’est pas une architecture de sécurité en soi — c’est un protocole de communication qui doit être déployé à l’intérieur d’une telle architecture, avec des décisions explicites prises sur l’identité, l’autorisation, l’audit et l’application des politiques à chaque frontière qu’il traverse. Sécurité des Agents A2A et MCP : Identité, Délégation et Traçabilité détaille cette architecture environnante.

A2A et l’idée de marketplace d’agents

L’un des cas d’utilisation à long terme plus intéressants d’A2A est les marketplaces d’agents.

Si les agents peuvent annoncer leurs capacités via des Agent Cards, alors d’autres agents ou plateformes peuvent les découvrir, les évaluer et leur envoyer des tâches.

Cela crée un futur possible où les capacités des agents deviennent plus modulaires :

Un agent fiscal
Un agent juridique
Un agent de revue de code
Un agent de planification de voyage
Un agent d’analyse de sécurité
Un agent d’approvisionnement
Un agent de qualité des données

Chacun pourrait exposer une interface standard pour la collaboration basée sur les tâches.

Cela semble excitant, mais c’est aussi là que l’hype devient dangereuse.

Une marketplace d’agents ouverte nécessite plus que des Agent Cards. Elle a besoin d’identité, de réputation, de facturation, de conformité, de sandboxing (isolement), de responsabilité, de versionning et de résolution de litiges.

Sans cela, une marketplace d’agents devient un incident de sécurité en attente d’arriver.

A2A est un bloc de construction utile pour ce type de futur, mais c’est une pièce d’une énigme beaucoup plus grande qui nécessite également des systèmes d’identité, des mécanismes de réputation, une infrastructure de facturation, des contrôles de conformité et une résolution de litiges avant de devenir un marché sûr dans lequel opérer.

A2A pour les agents d’entreprise internes

Le cas d’utilisation à court terme plus réaliste n’est pas les marketplaces d’agents publiques.

Ce sont les réseaux d’agents d’entreprise internes.

Les grandes organisations ont déjà de nombreuses frontières :

Équipes
Départements
Systèmes
Fournisseurs
Domaines de données
Zones de conformité
Politiques de sécurité
Processus d’approbation

A2A s’aligne naturellement sur ces frontières, car le protocole est conçu autour du même besoin fondamental : une communication structurée entre des systèmes qui ont leur propre propriété et ne partagent pas une base de code. Le cluster plus large Systèmes IA couvre comment les agents spécialisés comme Hermes et OpenClaw s’intègrent dans ce type d’architecture stratifiée en pratique.

Au lieu de construire un seul assistant géant avec un accès direct à tout, une entreprise peut construire des agents spécialisés avec une responsabilité limitée :

Agent RH
Agent financier
Agent support
Agent DevOps
Agent sécurité
Agent de gestion des connaissances
Agent de plateforme de données

Chaque agent peut posséder ses outils et politiques internement. D’autres agents peuvent interagir avec lui via A2A.

C’est un bien meilleur modèle que de donner à un seul agent généraliste un accès direct à chaque système de l’organisation, tant d’un point de vue sécurité que d’un point de vue opérationnel. Chaque agent spécialisé peut être possédé, exploité, audité et sécurisé indépendamment, ce qui rend également le système global plus facile à raisonner lorsque quelque chose tourne mal.

A2A pour les petites équipes et les Indie Hackers

Pour les petites équipes construisant des produits avec un ou deux agents, A2A est réellement moins urgent — et souvent une distraction par rapport à des problèmes plus immédiats. Vous n’avez probablement pas encore besoin d’un protocole agent-à-agent.

Utilisez le code normal. Utilisez les API HTTP. Utilisez les files d’attente. Utilisez MCP là où l’intégration d’outils importe.

Ajoutez A2A lorsque vous avez réellement :

Plusieurs agents indépendants
Des frontières d’agents tiers
Des tâches déléguées de longue durée
Des exigences de découverte d’agents
Des exigences d’échange d’artefacts
Des besoins d’interopérabilité cross-framework

La séquence importe plus que l’ambition. Commencez par l’architecture la plus simple qui expose les véritables points de pression, et laissez ces points de pression vous dire si vous avez réellement besoin d’A2A avant de vous engager dans la complexité qu’il apporte. Pour la plupart des petits constructeurs, MCP d’abord et A2A plus tard est le bon chemin.

Un cadre de décision pratique

Utilisez ce cadre pour décider si A2A a sa place dans votre système.

Pas d’A2A lorsque le workflow est local. Évitez A2A lorsque tout s’exécute à l’intérieur d’une application et que les composants ne sont pas déployables indépendamment. Une fonction Python, une classe, un service, une file d’attente ou un moteur de workflow est probablement suffisant.

MCP lorsque l’agent a besoin d’outils. Utilisez MCP lorsque votre agent a besoin d’un accès standardisé aux fichiers, bases de données, API, systèmes SaaS, index de recherche, dépôts, documentation interne ou systèmes d’observabilité. MCP donne une valeur pratique immédiate et est le point de départ idéal pour la plupart des équipes construisant des agents aujourd’hui.

A2A lorsque l’agent a besoin de pairs. Utilisez A2A lorsque votre agent doit communiquer avec d’autres agents indépendants — surtout lorsque ces agents ont leurs propres capacités, politiques, état, outils, propriétaires, cycle de vie de déploiement et frontière de sécurité.

Les deux lorsque l’architecture a des couches. Utilisez les deux lorsque les agents spécialisés collaborent entre eux et que chaque spécialiste a également besoin d’outils. Le modèle de production est A2A entre les agents et MCP entre les agents et les outils. C’est la version la plus sensée de la stack de protocoles d’agents de 2026, et l’architecture qui s’aligne le plus proprement sur la manière dont les systèmes multi-agents de production sont réellement construits.

Erreurs courantes avec A2A

Utiliser A2A parce que cela sonne stratégique. C’est le piège classique de l’architecture d’entreprise. A2A devrait résoudre un vrai problème de frontière qui existe dans l’architecture, pas un inventé pour justifier le choix du protocole. S’il n’y a pas de frontière genuine — pas de déploiement indépendant, pas de propriété séparée, pas de périmètre de sécurité distinct — il n’y a probablement pas besoin d’A2A.

Traiter MCP et A2A comme des concurrents. MCP n’est pas obsolète parce qu’A2A existe, et A2A n’est pas inutile parce que MCP existe. Ils adressent des problèmes structurels différents et fonctionnent le mieux comme des couches complémentaires, pas comme des alternatives concurrentes.

Exposer chaque capacité comme un agent. Une calculatrice n’a pas besoin d’être un agent. Une API météo n’a pas besoin d’être un agent. Une requête de base de données n’a pas besoin d’être un agent. Beaucoup de choses sont des outils straightforward (simples), et l’abstraction d’agent ajoute une surcharge sans ajouter de clarté lorsqu’elle est appliquée à des composants qui n’ont aucune autonomie, état ou cycle de vie significatif de leur propre chef.

Cacher un agent complet derrière un seul outil. L’erreur opposée est également courante. Si un « outil » a son propre cycle de vie de tâche, mémoire, politiques, artefacts et comportement de délégation, il mérite peut-être d’être modélisé comme un agent plutôt que d’être coincé derrière une frontière d’appel de fonction.

Ignorer l’observabilité. Les systèmes multi-agents sans traces sont douloureux à déboguer et impossibles à auditer. Vous devez savoir quel agent a reçu la tâche, quels messages ont été échangés, quels outils ont été appelés, quels artefacts ont été produits, quelles politiques ont été appliquées et quel agent a pris la décision finale. Sans cette visibilité, le débogage devient de l’archéologie — reconstruire ce qui s’est passé par inférence plutôt que par observation. La stack complète d’observabilité pour les systèmes IA et LLM, y compris les métriques, les traces distribuées et les SLO qui traversent les frontières des agents, est couverte dans Observabilité pour les Systèmes LLM : Métriques, Traces, Logs et Tests en Production.

Donc, A2A est-il surhypé ?

Oui, en partie. A2A est surhypé lorsqu’il est présenté comme le défaut inévitable pour tous les systèmes d’agents IA, lorsque les gens impliquent que chaque développeur doit l’adopter immédiatement, lorsque les démos d’agents utilisent A2A pour coordonner ce qui aurait pu être trois appels de fonction, ou lorsque la discussion sur le protocole ignore l’identité, l’autorisation, l’observabilité et les opérations de production. Ce sont des exemples réels d’hype qui rendent A2A plus universel qu’il ne l’est.

Mais surhypé ne signifie pas inutile. De nombreuses technologies importantes sont surhypées avant de devenir des infrastructures ennuyeuses, et l’hype arrive souvent bien avant que l’écosystème ne soit assez mûr pour le supporter. La vraie question n’est pas si le marketing est excessif — il l’est clairement parfois. La vraie question est si l’abstraction sous-jacente est utile, et pour A2A, la réponse est oui lorsque les agents deviennent des acteurs véritablement indépendants dans un système avec de vraies frontières, une vraie propriété et de vrais enjeux.

Donc, A2A est-il mort ?

Non.

L’argument « A2A est mort » avait plus de sens pendant la phase de scepticisme initial, lorsque le protocole semblait être une réponse menée par Google à l’élan de MCP.

En 2026, cet argument est plus faible.

A2A a une spécification formelle, un soutien de l’écosystème, une dynamique de la Linux Foundation, l’attention des grands clouds et des déploiements de production rapportés.

Rien de cela ne rend A2A dominant, obligatoire ou universellement aimé par la communauté des développeurs — mais il n’est clairement pas mort. Une meilleure affirmation est qu’A2A est vivant et qu’il prouve encore sa valeur de production au-delà des écosystèmes d’entreprise et de plateforme, c’est là que la plupart des déploiements confirmés vivent actuellement.

Donc, A2A est-il enfin utile en 2026 ?

Oui, mais seulement dans la bonne architecture. A2A est utile lorsque votre système a de vraies frontières d’agents — pas seulement parce que votre code a plusieurs prompts, ou parce que votre système utilise le mot « agent » dans les noms de variables. Il devient utile lorsque la collaboration entre agents a réellement besoin d’une structure standard :

Découverte
Capacités
Cycle de vie des tâches
Messages
Artefacts
Travail de longue durée
Frontières d’implémentation opaques
Interopérabilité cross-fournisseur

C’est là qu’A2A mérite sa place, en fournissant un contrat commun pour la collaboration qui autrement nécessiterait du travail de protocole personnalisé à chaque frontière.

Mon avis personnel

A2A n’est pas le protocole avec lequel la plupart des développeurs devraient commencer — c’est MCP. MCP résout un problème plus immédiat et plus largement applicable : connecter les agents à des outils et un contexte utiles. A2A résout un problème de stade ultérieur : connecter des agents indépendants les uns aux autres à travers de vraies frontières de déploiement et de propriété. Cela rend MCP plus utile aujourd’hui pour la vaste majorité des développeurs individuels et des petites équipes.

A2A peut devenir plus important à mesure que les systèmes d’agents mûrissent des démos vers des workflows d’entreprise. Une fois que les organisations ont plusieurs agents spécialisés possédés par différentes équipes, le besoin d’une frontière standard agent-à-agent devient évident et la surcharge du protocole commence à payer pour elle-même.

Ma recommandation pratique est de commencer par MCP, de concevoir des frontières d’agent propres dès le début, et d’ajouter A2A uniquement lorsque ces frontières deviennent des contraintes réelles de déploiement, de propriété ou d’interopérabilité. N’adoptez pas A2A pour les « vibes » (les sensations). Adoptez-le lorsque l’architecture l’exige.

Verdict final

Le protocole A2A de Google n’est pas mort.

Ce n’est pas non plus l’avenir universel de chaque projet d’agent IA.

C’est un protocole utile, encore en maturation, pour un problème spécifique : la communication entre agents IA indépendants.

Si vous construisez un assistant simple, A2A est probablement inutile.

Si vous construisez un système d’entreprise multi-agents, une marketplace d’agents, un réseau d’agents neutre en matière de fournisseur, ou un ensemble d’agents spécialisés déployés indépendamment, A2A mérite une attention sérieuse.

Le meilleur cadre de 2026 n’est pas :

A2A vs MCP

C’est :

MCP pour les outils.
A2A pour les agents.
Les deux pour les systèmes multi-agents sérieux.

C’est moins dramatique qu’un récit de guerre des protocoles, mais c’est aussi plus précis et plus utile aux ingénieurs qui doivent prendre de vraies décisions architecturales.