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

L'A2A n'est pas mort. Il n'est tout 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, 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 et le partage d’artefacts. La réaction, cependant, a été nettement moins nette que l’annonce.

Certains développeurs ont vu en A2A la couche manquante agent-à-agent pour la pile agémique émergente. D’autres y ont vu un protocole Google de plus, un acronyme de plus, et une nouvelle tentative de définir un marché avant que celui-ci n’ait des besoins réels de production. Le point de vue sceptique se résumait à 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 considérablement évolué.

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é, outils et limites 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 conçu pour adresser, et la comprendre est la clé pour évaluer A2A sans le battage médiatique dans aucune 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 un standard ouvert pour la communication et l’interopérabilité entre des systèmes d’agents IA indépendants — spécifiquement, des agents qui peuvent être construits en utilisant différents frameworks, langages ou piles de fournisseurs.

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 relève plus du 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 ayant ses propres capacités plutôt que comme une source de données passive.

Un flux A2A typique pourrait impliquer :

Découvrir un agent via une Agent Card (Carte d’agent)
Lire les compétences et capacités de l’agent
Envoyer une tâche
Échanger des messages
Recevoir des mises à jour de statut
Gérer les états nécessitant une saisie
Recevoir les artefacts finaux
Suivre l’achèvement, l’échec ou l’annulation

Le mot important dans cette liste est « tâche ». A2A n’est pas juste un appel de fonction avec une enveloppe différente — c’est un protocole de cycle de vie de tâches pour la collaboration d’agents, conçu pour gérer l’arc complet de la découverte et de la délégation à travers l’exécution, les mises à jour de statut et le retour des artefacts. Pour un examen technique approfondi de chaque concept — Agent Cards, cycle de vie des tâches, messages, parties et artefacts — voir Qu’est-ce que le protocole A2A ? Agent Cards et Tâches Expliqués.

Pourquoi A2A était facile à moquer

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

D’ici 2025, les développeurs avaient déjà à gérer :

Les API LLM
L’appel de fonctions
L’appel d’outils
Les frameworks d’agents
Les serveurs MCP
Les pipelines RAG
Les moteurs de workflow
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’un autre standard ? »

Le scepticisme n’était pas irrationnel, et il venait de plusieurs directions à la fois. A2A semblait se chevaucher avec 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 de base, l’injection de prompts, l’observabilité, le contrôle des coûts et la sécurité pour les systèmes mono-agent.

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 besoin d’A2A du tout.

Elles avaient besoin de meilleurs prompts, de meilleurs outils, de meilleures permissions, d’une meilleure logique de nouvelle tentative et de meilleurs journaux.

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é 150 organisations soutenant, gagné des intégrations majeures de plateformes cloud et atteint des déploiements en production à travers plusieurs industries.

Cela ne signifie pas que chaque affirmation doit être avalé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 font dans le travail d’ingénierie quotidien.

Le signal compte cependant, car il est plus difficile à rejeter. A2A a franchi une ligne importante : ce n’est plus seulement un article de blog Google. Il a une spécification formelle, un élan de gouvernance, des exemples publics, un travail 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 le plan technique 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 le battage médiatique.

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, standardise la façon 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 propre, mais le monde réel est considérablement plus désordonné. Un serveur MCP peut exposer quelque chose qui ressemble beaucoup à un agent — par exemple, un outil MCP nommé research_company qui exécute internement la recherche, la récupération, la résumé, le classement et la rédaction de rapports. 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 limite d’appel de fonction. Cette ambiguïté est précisément la raison pour laquelle certains développeurs ont affirmé 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 première classe à des choses que MCP traite plus maladroitement :

Découverte d’agents
Capacités des agents
Cycle de vie des tâches
Travail de longue durée
État de tâche multi-tours
Messagerie agent-à-agent
Artefacts
Collaboration entre agents opaques
Délégation à travers les limites organisationnelles

MCP peut envelopper beaucoup de choses, mais envelopper tout comme un outil finit par devenir une mauvaise abstraction. À un certain point, un système spécialisé a assez de son propre état, politique, cycle de vie et autorité 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 à payer. Pour une comparaison détaillée de là où la limite tombe en pratique, voir 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 empilé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 d’agents.
MCP est la couche d’intégration d’outils.

C’est le modèle qui a le plus de sens en 2026, et c’est le cadre sur 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 limite d’agent — ils résolvent des problèmes différents à différentes couches de la pile. Le cadre de la « guerre de 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 juste un appel de bibliothèque dans votre application.

Il est utile lorsque les agents sont :

Déployés indépendamment
Propriété de différentes équipes
Construits avec différents frameworks
Exposés par des fournisseurs
Fonctionnant 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-agent 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 légale
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 limite raisonnable.

L’assistant principal ne devrait pas avoir besoin d’un accès direct à chaque base de données d’approvisionnement, stock de politiques légales, 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 limite d’autorité et de responsabilité. Le modèle empilé pour la façon 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 surestimé

A2A est surestimé 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
D’évaluation
De journalisation
De contrôle des coûts
De logique de nouvelle tentative
De meilleurs prompts
D’une meilleure récupération

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 seule 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, l’adoption d’A2A est du cosplay architectural — emprunter le vocabulaire des systèmes d’agents distribués sans aucun des problèmes de limites réels qui rendent le protocole précieux.

A2A et le problème Google

Une partie du scepticisme d’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 entièrement juste pour 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. A2A devenant partie 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 n’est qu’un mouvement stratégique contrôlé par Google.

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

C’est un angle plus sain, et c’est celui 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 elles ne doivent pas être confondues avec une adoption universelle par les développeurs. « Soutenu par » est un spectre, pas un binaire, et il aide à lire les affirmations d’adoption avec cela en tête.

À l’extrémité la plus faible se trouve l’adoption de logo : une entreprise dit qu’elle soutient le standard, ce qui peut refléter une mise en œuvre genuine, un positionnement stratégique, un prototype, ou simplement un soutien prévu qui n’a pas pris forme. Un peu plus fort est l’adoption 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 mise en œuvre fonctionnelle, et de vrais ingénieurs l’ont trouvé de leur temps. Plus fort encore est l’adoption de plateforme, où les clouds, frameworks d’agents et systèmes d’entreprise exposent un support natif réel, faisant d’A2A un choix architectural par défaut plausible plutôt que quelque chose que les équipes doivent câbler 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 adoptateurs 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 2026 de la Linux Foundation revendique une utilisation en production à travers 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 vrai incident opérationnel ? » La rétention à long terme sous pression est le signal qui sépare l’infrastructure genuine du théâtre de protocole.

Le vrai test : Rétention en production

Le battage médiatique des développeurs est bon marché, et la rétention en production est coûteuse. Les deux sont rarement proportionnels, ce qui est pourquoi la question de rétention à 90 jours compte plus que l’enthousiasme de la semaine de lancement.

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

Problèmes d’authentification
Problèmes d’autorisation
Problèmes d’identité d’agent
Problèmes de débogage
Cas limites du cycle de vie des tâches
Échecs de streaming
Compatibilité des versions
Différences de fournisseurs
Surprises de coûts
Révisions de sécurité
Exigences d’audit
Workflows d’approbation humaine

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

A2A a une bonne raison d’exister, mais de bonnes raisons ne se traduisent pas automatiquement en résilience en 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 vraies limites 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 retombent sur des 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 limites organisationnelles ou systémiques.

Quand 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 rend la collaboration d’agents plus facile. Il crée aussi de nouveaux endroits où la confiance peut se briser.

Par exemple :

Un agent malveillant pourrait mal représenter 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 limites 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 :

D’une identité d’agent forte
D’une autorisation étendue
De journaux d’audit au niveau de la tâche
Du suivi de délégation
D’approbation humaine pour les actions risquées
De provenance des artefacts
De limites de débit
De l’application de politiques
D’observabilité à travers les limites des agents

A2A n’est pas une architecture de sécurité par lui-même — c’est un protocole de communication qui doit être déployé à l’intérieur d’une, avec des décisions explicites prises sur l’identité, l’autorisation, l’audit et l’application de politiques à chaque limite qu’il traverse.

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

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

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

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

Un agent fiscal
Un agent légal
Un agent de révision 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à où le battage médiatique devient dangereux.

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

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

A2A est un bloc de construction utile pour ce type d’avenir, 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 limites :

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

A2A s’adapte naturellement à ces limites, car le protocole est conçu autour du même besoin fondamental : 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 empilé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 à usage général un accès direct à chaque système de l’organisation, tant du point de vue de la sécurité que de celui de l’opération. Chaque agent spécialisé peut être possédé, opéré, 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 besoin d’un protocole agent-à-agent encore.

Utilisez du code normal. Utilisez des API HTTP. Utilisez des files d’attente. Utilisez MCP où l’intégration d’outils compte.

Ajoutez A2A lorsque vous avez réellement :

Plusieurs agents indépendants
Des limites 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 compte plus que l’ambition. Commencez avec l’architecture la plus simple qui expose les vrais 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 lorsque vous décidez si A2A appartient à 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 approprié pour la plupart des équipes construisant des agents aujourd’hui.

A2A lorsque l’agent a besoin de pairs. Utilisez A2A lorsque votre agent a besoin de 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 limite 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 pile de protocoles d’agents 2026, et l’architecture qui s’adapte le plus proprement à la façon 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 limite qui existe dans l’architecture, pas un inventé pour justifier le choix du protocole. S’il n’y a pas de limite 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, et l’abstraction d’agent ajoute de la surcharge sans ajouter de clarté lorsqu’elle est appliquée à des composants qui n’ont pas d’autonomie, d’état ou de cycle de vie significatifs de leur propre chef.

Cacher un agent complet derrière un seul outil. L’erreur opposée est aussi courante. Si un « outil » a son propre cycle de vie de tâches, 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 limite 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 pile d’observabilité complète pour les systèmes IA et LLM, y compris les métriques, traces distribuées et SLOs qui traversent les limites des agents, est couverte dans Observabilité pour les systèmes LLM : Métriques, Traces, Logs et Tests en Production.

Alors, A2A est-il surestimé ?

Oui, en partie. A2A est surestimé 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 de battage médiatique qui font sonner A2A plus universel qu’il ne l’est.

Mais surestimé ne signifie pas inutile. De nombreuses technologies importantes sont surestimées avant de devenir une infrastructure ennuyeuse, et le battage médiatique arrive souvent bien avant que l’écosystème ne soit assez mature pour le supporter. La vraie question n’est pas si le marketing est excessif — il l’est clairement par moments. La vraie question est si l’abstraction sous-jacente est utile, et pour A2A, la réponse est oui lorsque les agents deviennent de véritables acteurs indépendants dans un système avec de vraies limites, une vraie propriété et de vrais enjeux.

Alors, 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 à la dynamique 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 est clairement pas mort. Une meilleure déclaration est qu’A2A est vivant et prouve encore sa valeur en production au-delà des écosystèmes d’entreprise et de plateforme, c’est là que la plupart des déploiements confirmés vivent actuellement.

Alors, A2A est-il enfin utile en 2026 ?

Oui, mais seulement dans la bonne architecture. A2A est utile lorsque votre système a de vraies limites 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 d’agents a vraiment besoin de structure standard :

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

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

Mon avis tranchant

A2A n’est pas le protocole avec lequel la plupart des développeurs devraient commencer — MCP l’est. 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 limites 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 aux 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 limite agent-à-agent standard devient évident et la surcharge du protocole commence à payer pour elle-même.

Ma recommandation pratique est de commencer avec MCP, concevoir des limites d’agent propres dès le début, et ajouter A2A seulement lorsque ces limites deviennent de vraies contraintes de déploiement, de propriété ou d’interopérabilité. N’adoptez pas A2A pour les vibes. Adoptez-le lorsque l’architecture l’exige.

Verdict final

Le protocole A2A de Google n’est pas mort.

Ce n’est pas non plus le futur universel de chaque projet d’agent IA.

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

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

Si vous construisez un système d’entreprise multi-agent, 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 cadrage 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 de protocoles, mais c’est aussi plus précis et plus utile aux ingénieurs qui doivent prendre de vraies décisions architecturales.