A2A vs MCP : le guide complet des protocoles agent-à-agent et agent-à-outil

A2A et MCP ne sont pas des standards rivaux qui résolvent le même problème. MCP connecte une application ou un agent IA à des outils, des API, des fichiers et des données ; A2A connecte un agent autonome à un autre agent autonome capable d'accepter, de gérer et de mener à bien un travail délégué. Les architectures de production les plus utiles combinent souvent les deux : A2A entre les agents, et MCP derrière chaque agent.[^1][^2]

Le modèle mental le plus court est :

> MCP : « Utilise cette capacité. » > A2A : « Délègue cet objectif à un autre agent. »

Cette distinction détermine quel protocole choisir, ce qui est exposé, qui contrôle le raisonnement, et comment le travail de longue durée est représenté.

La réponse en 30 secondes

Les primitives officielles du serveur MCP sont les prompts, ressources et outils. Les concepts clés d'A2A incluent les Agent Cards, messages, tâches, états de tâche et artefacts.[^3][^4]

Ce que fait réellement MCP

Le Model Context Protocol standardise la façon dont un hôte propulsé par l'IA se connecte à des capacités externes. Un hôte — un assistant, un IDE ou un agent personnalisé — crée des clients MCP, et chaque client communique avec un serveur MCP. Le serveur expose des capacités ciblées, tandis que l'hôte conserve le contrôle des permissions, de l'agrégation de contexte et de l'orchestration.[^5][^6]

Un serveur MCP peut exposer :

• Des outils : des opérations exécutables, comme create_wordpress_draft, search_crm_contacts ou issue_refund.
• Des ressources : des données contextuelles, comme des fichiers, des schémas de base de données, des catalogues produits ou une fiche client.
• Des prompts : des modèles d'interaction réutilisables et paramétrables, sélectionnés par l'utilisateur.

La spécification distingue délibérément qui contrôle ces primitives : les prompts sont contrôlés par l'utilisateur, les ressources par l'application, et les outils par le modèle.[^4]

Exemple MCP : WordPress

Un serveur MCP WordPress pourrait exposer :

Outils
- list_posts(status, limit)
- create_draft(title, content, category)
- update_meta(post_id, title, description)
- get_product_stock(product_id)

Ressources
- wordpress://editorial-guidelines
- wordpress://categories
- wordpress://products/4821

Prompts
- /prepare-seo-brief
- /translate-page

Un hôte IA peut inspecter ces capacités et les invoquer. WordPress ne devient pas pour autant un agent pair simplement parce qu'il expose des outils MCP ; il reste un système qui fournit des fonctions et du contexte.

Exemple MCP : prospection export

Un seul agent export pourrait utiliser plusieurs serveurs MCP :

1. Un serveur MCP de registre d'entreprises pour identifier des fabricants en Allemagne. 2. Un serveur MCP de crawling de sites web pour examiner produits et certifications. 3. Un serveur MCP CRM pour détecter les doublons et créer des leads qualifiés. 4. Un serveur MCP email pour préparer des brouillons. 5. Un serveur MCP WordPress pour publier une landing page localisée.

L'agent export reste l'orchestrateur. Il décide quel outil appeler, combine les résultats et présente le plan final.

Exemple MCP : audit énergétique

Un assistant de rénovation énergétique peut utiliser des outils MCP pour :

• Récupérer une adresse et des informations cadastrales.
• Lire une fiche DPE.
• Interroger des données météo et d'irradiation.
• Lancer un calcul de production solaire.
• Créer une opportunité CRM.
• Générer un devis PDF.

Ce sont des capacités, pas des collègues indépendants. L'assistant reste responsable de l'objectif et du raisonnement.

Ce que fait réellement A2A

Le protocole Agent2Agent standardise la collaboration entre des agents indépendants, construits avec des frameworks, langages ou fournisseurs différents. Un serveur A2A publie une Agent Card qui décrit son identité, ses compétences, son endpoint, les modalités prises en charge et les exigences d'authentification. Un autre agent peut utiliser ce contrat pour décider s'il doit déléguer du travail, et comment.[^1][^3]

A2A v1.0 est devenue la première version stable et prête pour la production en mars 2026. Le protocole prend en charge plusieurs bindings — JSON-RPC, gRPC et HTTP+JSON/REST — et est hébergé par la Linux Foundation après sa contribution initiale par Google.[^7][^8]

Les objets centraux d'A2A

• Agent Card : la carte de visite lisible par machine de l'agent.
• Skill (compétence) : un domaine de compétence déclaré.
• Message : un échange entre agents.
• Task (tâche) : une unité de travail délégué avec état.
• Context (contexte) : la continuité à travers des échanges et tâches liés.
• Artifact (artefact) : un livrable concret, comme un rapport, une image, un tableur ou un résultat structuré.

Une tâche peut traverser plusieurs états de cycle de vie et demander davantage d'informations avant d'être complétée. Les artefacts peuvent être livrés de façon incrémentale, ce qui rend A2A adapté aux travaux longs ou produisant plusieurs livrables.[^9][^3]

Exemple A2A : entrée sur un marché international

Un agent de stratégie s'adressant au dirigeant reçoit cet objectif :

> « Évalue le marché espagnol pour notre pompe à chaleur industrielle et prépare un plan d'entrée sur trois mois. »

Il délègue via A2A à :

• Un agent de veille marché pour la taille du marché, la réglementation et la concurrence.
• Un agent réglementaire pour les certifications et obligations locales.
• Un agent de génération de leads pour distributeurs et installateurs.
• Un agent financier pour le pricing et les scénarios de marge.
• Un agent de localisation pour les messages en espagnol.

Chaque agent distant peut utiliser ses propres modèles, bases de données privées et outils MCP. L'agent de stratégie n'a pas besoin de connaître la séquence interne des recherches et calculs ; il suit les tâches et consomme leurs artefacts.

Exemple A2A : voyage

Un agent concierge voyage délègue des objectifs distincts :

• « Trouve un itinéraire Paris–Tokyo remboursable à moins de 2 000 €. »
• « Trouve un hôtel à Shinjuku répondant à ces exigences d'accessibilité. »
• « Conçois un itinéraire art et technologie sur cinq jours. »

Les agents vol, hôtel et itinéraire peuvent demander des informations manquantes, travailler de façon asynchrone et retourner des réservations candidates ou des plans sous forme d'artefacts. C'est bien plus qu'appeler search_flights ; chaque spécialiste possède un sous-objectif.

Exemple A2A : chaîne d'approvisionnement multi-entreprises

L'agent d'achat d'un fabricant communique avec l'agent commercial d'un fournisseur :

1. L'agent acheteur demande 10 000 unités avec des contraintes techniques. 2. L'agent fournisseur vérifie la capacité de production via ses outils MCP internes. 3. Il interroge son agent logistique pour des scénarios de livraison via A2A. 4. L'agent logistique consulte les API transporteurs via MCP. 5. L'agent fournisseur retourne un artefact de proposition. 6. L'agent acheteur demande des conditions de paiement révisées.

A2A est approprié car les agents appartiennent à des organisations différentes, et leurs outils et raisonnements internes doivent rester opaques.

La différence architecturale

MCP est généralement vertical : un agent descend vers des outils et des données. A2A est généralement horizontal : un agent délègue à un pair ou à un agent spécialiste. La spécification officielle d'A2A définit explicitement les deux protocoles comme complémentaires.[^2][^1]

                         A2A
┌──────────────────┐  objectif/tâche  ┌──────────────────┐
│ Agent            │ ───────────────► │ Agent spécialiste│
│ orchestrateur    │ ◄─────────────── │                  │
└────────┬─────────┘  artefact/statut └────────┬─────────┘
         │ MCP                                  │ MCP
         ▼                                      ▼
┌──────────────────┐                   ┌──────────────────┐
│ CRM, WordPress,  │                   │ Base de données  │
│ analytics, email │                   │ privée, API,     │
│                  │                   │ calculateurs     │
└──────────────────┘                   └──────────────────┘

Une erreur de conception fréquente est d'exposer chaque API de bas niveau comme un « agent » supplémentaire. Si un composant se contente de lire un stock ou d'envoyer un e-mail, c'est généralement un outil, et MCP en est l'interface la plus propre. À l'inverse, aplatir un agent spécialiste sophistiqué en dizaines d'outils MCP peut exposer sa complexité interne et forcer l'appelant à reproduire son orchestration.

Douze comparaisons pratiques

1. Lire un fichier

Demande : « Lis le tableur des ventes du T3. » Utilisez MCP. Le tableur est une ressource ; aucun collaborateur autonome n'est nécessaire.

2. Analyser une entreprise

Demande : « Donne-moi le chiffre d'affaires de l'entreprise d'après son dernier bilan. » Généralement MCP. Un outil de bilan/base de données peut récupérer le chiffre. Utilisez A2A si la demande devient : « Effectue une due diligence commerciale complète, résous les contradictions et livre un mémo d'investissement. » C'est un objectif délégué avec un livrable.

3. Publier un brouillon WordPress

Demande : « Crée cet article approuvé en tant que brouillon. » Utilisez MCP. create_draft est une action bornée.

4. Faire tourner une rédaction éditoriale

Demande : « Surveille cinq concurrents, sélectionne les évolutions pertinentes, commande des mises à jour et tiens notre calendrier éditorial. » Utilisez A2A pour déléguer à un agent éditorial. Celui-ci peut utiliser MCP pour chercher des sources, inspecter WordPress et créer des brouillons.

5. Vérifier un stock WooCommerce

Demande : « Combien d'unités du produit 4821 sont disponibles ? » Utilisez MCP. Un outil get_product_stock suffit.

6. Négocier un réapprovisionnement

Demande : « Évite les ruptures de stock tout en gardant l'inventaire sous 45 jours, et négocie la prochaine commande avec les fournisseurs. » Utilisez A2A entre les agents achats, fournisseur et logistique ; utilisez MCP en interne pour l'ERP, l'inventaire et l'accès transporteurs.

7. Envoyer un e-mail

Demande : « Envoie ce message approuvé à Marie. » Utilisez MCP, avec une confirmation explicite pour cet effet de bord.

8. Mener une prospection sortante

Demande : « Construis et lance une campagne conforme de distributeurs France-vers-Allemagne, en ajustant le ciblage selon les réponses. » Utilisez A2A si la prospection est déléguée à un agent spécialiste qui gère la recherche, la segmentation, les conversations et le feedback. Cet agent peut utiliser MCP pour les bases de données, l'e-mail et le CRM.

9. Réserver un vol déjà identifié

Demande : « Réserve l'AF276 du 18 novembre après mon approbation du tarif. » Utilisez MCP pour appeler l'API de réservation, avec confirmation utilisateur.

10. Organiser un déplacement professionnel complet

Demande : « Organise mon déplacement à Tokyo autour de ces réunions, optimise coût et flexibilité, et gère les changements. » Utilisez A2A pour un agent voyage qui coordonne plusieurs fournisseurs et des tâches de longue durée. Ses fonctions de réservation peuvent être des outils MCP.

11. Calculer une production solaire

Demande : « Estime la production annuelle pour cette géométrie de toiture. » Utilisez MCP pour invoquer un calculateur déterministe et récupérer des données météo.

12. Concevoir un plan de rénovation énergétique

Demande : « Compare les scénarios pompe à chaleur, isolation et solaire, vérifie les aides, identifie des installateurs et produis un plan d'investissement par phases. » Utilisez A2A pour la collaboration entre les agents audit, aides, ingénierie et achats ; chaque agent peut utiliser MCP pour accéder aux données et calculateurs.

Un workflow utilisant les deux

Prenons un système de développement export pour une PME industrielle française.

Étape 1 : délégation via A2A

L'agent principal délègue trois tâches :

Agent marché :
« Évalue la demande, la réglementation et la concurrence en Pologne. »

Agent leads :
« Identifie et qualifie 75 distributeurs polonais. »

Agent localisation :
« Crée le positionnement et les supports de campagne en polonais. »

Étape 2 : exécution via MCP

L'agent marché utilise MCP pour interroger des données commerciales, des bases réglementaires et des outils de recherche web. L'agent leads utilise des registres d'entreprises, des services d'enrichissement et le CRM. L'agent localisation lit la charte éditoriale et rédige des brouillons WordPress.

Étape 3 : mises à jour de tâche A2A

L'agent leads signale input-required car le seuil de chiffre d'affaires annuel cible n'a pas été précisé. L'agent principal le fournit. La tâche se poursuit alors, plutôt que de repartir de zéro.

Étape 4 : artefacts

Les spécialistes retournent :

• Un rapport de marché.
• Un tableur de leads scorés.
• Un document de messages localisés.
• Un fichier d'import de campagne.

L'agent principal synthétise ces artefacts en un plan exécutif.

À quoi ressemblent les concepts au niveau protocole

Les objets simplifiés suivants illustrent la différence conceptuelle ; ce sont des exemples pédagogiques, pas des payloads de production à copier tels quels.

Outil MCP simplifié

{
  "name": "get_product_stock",
  "description": "Return current stock for a WooCommerce product",
  "inputSchema": {
    "type": "object",
    "properties": {
      "productId": { "type": "integer" }
    },
    "required": ["productId"]
  }
}

L'appelant connaît l'opération précise et fournit ses arguments. L'outil retourne une information ou effectue une action bornée.

Agent Card A2A simplifiée

{
  "name": "European Distributor Research Agent",
  "description": "Finds and qualifies B2B distributors in Europe",
  "version": "1.0.0",
  "url": "https://agents.example.com/a2a",
  "skills": [
    {
      "id": "qualify-distributors",
      "name": "Distributor qualification",
      "description": "Researches, scores and documents distributors",
      "inputModes": ["application/json", "text/plain"],
      "outputModes": ["application/json", "text/csv"]
    }
  ]
}

L'appelant découvre un spécialiste capable de porter un objectif. Il n'a pas besoin de savoir si ce spécialiste utilise cinq API, un analyste humain, un modèle interne ou vingt appels MCP.

État, temps et autonomie

Les deux protocoles se recoupent techniquement plus que ne le suggère le slogan « outils contre agents ». MCP prend en charge le streaming, les notifications, l'annulation, l'elicitation et le sampling de modèle ; A2A prend en charge aussi bien les messages immédiats que les tâches avec état. La distinction décisive n'est donc pas de savoir si une requête est asynchrone, mais où se situent l'autonomie et la responsabilité.[^10][^11][^12]

Les recommandations d'architecture de Microsoft arrivent à la même conclusion pratique : utiliser MCP pour l'accès authentifié aux outils et aux données, et A2A pour l'intégration d'agents entre plateformes via des contrats publiés.[^11]

Différences de transport

MCP 2026-07-28 standardise deux bindings principaux :

• stdio, dans lequel le client lance un sous-processus serveur MCP local.
• Streamable HTTP, dans lequel chaque message JSON-RPC est envoyé par POST HTTP et la réponse est un JSON ou un flux SSE propre à la requête.[^13][^14][^15]

A2A v1.0 prend en charge les bindings JSON-RPC, gRPC et HTTP+JSON/REST sur infrastructure web. Cela le rend naturellement adapté aux services déployés indépendamment et à la communication entre plateformes.[^8][^1]

Cela ne signifie pas que « MCP est local et A2A est distant ». MCP prend en charge des serveurs HTTP distants, tandis que des agents A2A peuvent tourner localement. La vraie différence reste leur contrat d'interaction.

Implications de sécurité

Aucun des deux protocoles ne rend automatiquement une architecture agentique sûre. Les deux définissent des mécanismes de communication ; les implémenteurs restent responsables de l'identité, de l'autorisation, du moindre privilège, de la gouvernance des données, de la validation et de l'auditabilité.

Risques liés à MCP

• Empoisonnement d'outil ou descriptions trompeuses.
• Outils excessivement larges, comme du SQL ou de l'exécution shell non restreints.
• Injection de prompt via des ressources.
• Problèmes de « confused deputy » et de transfert de token.
• Effets de bord destructeurs sans confirmation.
• Ressources sensibles exposées sous des portées (scopes) trop larges.

Pour le transport HTTP, MCP fournit un cadre d'autorisation, tandis que les déploiements stdio sont censés obtenir leurs identifiants via l'environnement plutôt que via le flux d'autorisation HTTP.[^16][^17]

Les contrôles pratiques incluent :

• Séparer les outils de lecture et d'écriture.
• Exiger une approbation explicite pour publier, envoyer, supprimer, payer ou rembourser.
• Valider chaque argument côté serveur.
• Restreindre les portées (scopes) par serveur et par utilisateur.
• Traiter le contenu récupéré comme une donnée non fiable.
• Journaliser les appels d'outils et leurs résultats sans faire fuiter de secrets.

Risques liés à A2A

• Faire confiance à une Agent Card frauduleuse ou compromise.
• Déléguer des objectifs sensibles à un agent externe non approuvé.
• Fuite de données via les messages, le contexte ou les artefacts.
• Chaînes de délégation excessives, avec une responsabilité floue.
• Artefacts malveillants ou injection de prompt retournés par des pairs.
• Responsabilité ambiguë lorsque plusieurs agents agissent à travers plusieurs organisations.

A2A s'appuie sur des schémas de sécurité HTTP établis : le trafic de production utilise HTTPS ; les exigences d'authentification sont déclarées via l'Agent Card ; les identifiants sont obtenus hors bande et transmis via les en-têtes HTTP appropriés. Les Agent Cards sensibles doivent elles-mêmes être soumises à un contrôle d'accès et ne jamais contenir de secrets en clair.[^18]

Les contrôles pratiques incluent :

• Maintenir une liste blanche ou un registre de confiance des agents.
• Vérifier l'identité, la propriété et les endpoints annoncés.
• Signer et scanner les artefacts.
• Limiter les données partagées pour chaque tâche déléguée.
• Propager l'identité et l'autorisation de l'utilisateur de façon délibérée, jamais implicite.
• Fixer une profondeur, un budget et des limites de temps à la délégation.
• Maintenir des identifiants de corrélation de bout en bout, pour les tâches comme pour l'audit.

Idées reçues courantes

« A2A remplace MCP »

Faux. La documentation d'A2A v1.0 décrit explicitement MCP comme la couche agent-vers-outil, et A2A comme la couche agent-vers-agent.[^2]

« Tout serveur MCP est un agent »

Faux. Un serveur exposant read_file ou get_stock ne possède pas nécessairement d'objectif, de boucle de planification ou de responsabilité autonome. Il se comprend mieux comme un fournisseur de capacités.

« Tout microservice devrait devenir un agent A2A »

Généralement faux. Une API de pricing déterministe, une base de données ou un calculateur ne gagnent pas grand-chose à se faire passer pour autonomes. Exposez-les via une API classique ou un outil MCP.

« Longue durée signifie A2A »

Pas automatiquement. Un export de base de données long peut rester une opération d'outil. Utilisez A2A lorsque la partie distante possède un objectif et gère son propre workflow, pas simplement parce que l'exécution prend du temps.

« MCP ne peut pas se connecter à un agent »

Si, il le peut. Un agent peut être encapsulé en tant que serveur MCP. C'est utile lorsqu'un hôte veut y accéder de façon contrôlée, comme à un outil. A2A devient préférable lorsque l'identité du pair, les tâches déléguées, la continuité de contexte, l'orchestration opaque et les artefacts comptent.[^11]

« A2A découvre automatiquement tous les agents d'internet »

Non. Les Agent Cards standardisent la façon dont les capacités sont annoncées, mais la découverte en production, les registres de confiance, la politique et la sélection d'agents restent des préoccupations architecturales.

Quand utiliser seulement MCP

Utilisez MCP sans A2A lorsque :

• Un seul agent ou assistant possède l'intégralité du workflow.
• Les composants externes exposent des outils ou des données bornés.
• Un contrôle centralisé strict est souhaitable.
• Les intégrations sont majoritairement internes.
• Le service distant n'a pas besoin d'identité indépendante ni de propriété de tâche.

Exemples :

• Un assistant de code utilisant des serveurs GitHub, Sentry et système de fichiers.
• Un assistant de contenu utilisant WordPress, l'analytics et des outils de génération d'images.
• Un assistant commercial lisant les données CRM et rédigeant des e-mails.
• Un calculateur énergétique lisant le DPE, la météo et les données tarifaires.
• Un assistant support récupérant des commandes et émettant des remboursements approuvés.

Quand utiliser seulement A2A

Utilisez A2A sans MCP lorsque chaque agent participant possède déjà tous les outils dont il a besoin, et que seule la collaboration inter-agents doit être standardisée.

Exemples :

• Deux éditeurs SaaS qui exposent des agents autonomes l'un à l'autre.
• Un agent acheteur qui demande des propositions à des agents fournisseurs.
• Un concierge central qui délègue à des agents voyage existants.
• Un agent de coordination hospitalière qui communique avec des agents de planning indépendants, sous réserve des contraintes de conformité sectorielles.

Même ici, ces agents distants peuvent utiliser en interne des API classiques plutôt que MCP.

Quand utiliser les deux

Utilisez les deux lorsque des agents indépendants doivent collaborer, et que chacun a également besoin d'un accès standardisé à des outils ou des données.

Exemples :

Plateforme export B2B

• A2A : les agents stratégie, étude de marché, génération de leads et localisation collaborent.
• MCP : chaque agent accède aux registres, au CRM, à l'e-mail, à la mémoire de traduction et à WordPress.

Opérations e-commerce

• A2A : les agents merchandising, achats, support et logistique se coordonnent.
• MCP : WooCommerce, l'ERP, le paiement, les transporteurs et le helpdesk fournissent des outils.

Marketplace des énergies renouvelables

• A2A : les agents audit, installateur, finance et aides échangent des tâches.
• MCP : les données cadastrales, le DPE, la simulation solaire, les bases d'aides et le CRM sont des outils/ressources.

Réseau de publication

• A2A : les agents rédacteur, recherche, fact-checking et localisation échangent des briefs et des artefacts.
• MCP : la recherche, les archives, l'analytics, la DAM et WordPress exposent des capacités.

Réponse à incident

• A2A : les agents sécurité, infrastructure, application et communication possèdent des chantiers parallèles.
• MCP : le SIEM, les logs, le ticketing, les consoles cloud et les pages de statut exposent des opérations contrôlées.

Grille de décision

Posez ces questions dans l'ordre :

1. Le système en face se contente-t-il d'exposer une donnée ou une opération ? Utilisez MCP. 2. S'agit-il d'un spécialiste autonome capable de porter un résultat ? Envisagez A2A. 3. L'appelant doit-il contrôler chaque outil et chaque étape de raisonnement ? Privilégiez MCP. 4. Le workflow interne du spécialiste doit-il rester privé ? Privilégiez A2A. 5. Le travail a-t-il besoin d'un état de tâche, de questions de suivi et d'artefacts ? A2A est probablement approprié. 6. Le spécialiste lui-même a-t-il besoin de CRM, de fichiers, d'API ou de bases de données ? Ajoutez MCP derrière lui. 7. Tous les agents sont-ils dans un seul framework et une seule frontière de confiance ? Une orchestration native peut être plus simple qu'A2A. 8. Les agents traversent-ils des plateformes ou des frontières organisationnelles ? A2A devient plus précieux.[^11]

Un test utile consiste à formuler l'interaction :

• Si la commande naturelle est « appeler », « lire », « écrire », « chercher », « calculer » ou « mettre à jour », cela correspond probablement à MCP.
• Si la commande naturelle est « enquêter », « négocier », « planifier », « surveiller », « gérer » ou « livrer », cela peut mériter un agent A2A.

Un chemin d'implémentation pragmatique

Étape 1 : stabiliser les outils

Commencez par des API et des serveurs MCP autour des systèmes de référence. Séparez les opérations de lecture et d'écriture, définissez des schémas et mettez en œuvre l'autorisation et les journaux.

Étape 2 : construire un orchestrateur unique

Laissez un agent utiliser ces capacités MCP. Cela permet de tester le workflow sans ajouter immédiatement la complexité multi-agents.

Étape 3 : extraire de véritables spécialistes

Ne transformez un composant en agent que s'il possède :

• Une responsabilité de domaine cohérente.
• Son propre processus de planification ou de décision.
• Plusieurs outils ou sources de données.
• Un résultat mesurable.
• Une raison de rester opérationnellement indépendant.

Étape 4 : exposer les spécialistes via A2A

Publiez des Agent Cards claires, définissez des contrats de tâche et des artefacts de sortie, et établissez des politiques d'authentification et de confiance.

Étape 5 : gouverner le système combiné

Mettez en œuvre une traçabilité à travers les tâches A2A et les appels MCP, des approbations pour les actions à fort impact, des limites de coût, l'annulation, les retentatives et l'escalade humaine.

FAQ

A2A est-il meilleur que MCP ?

Non. Ils optimisent des interfaces différentes. MCP est généralement meilleur pour un accès contrôlé aux outils et aux données ; A2A est généralement meilleur pour la délégation entre agents indépendants.

Un même agent peut-il utiliser les deux ?

Oui. C'est le schéma de référence : l'agent expose une interface A2A à ses pairs et utilise des serveurs MCP pour effectuer son travail interne. La spécification A2A décrit explicitement cette composition.[^1]

Les deux utilisent-ils JSON-RPC ?

MCP utilise des messages JSON-RPC. A2A propose un binding JSON-RPC, mais standardise aussi les bindings gRPC et HTTP+JSON/REST.[^19][^1]

Les deux sont-ils des projets de la Linux Foundation ?

Oui. A2A a été initialement développé par Google puis donné à la Linux Foundation ; MCP est également hébergé par la Linux Foundation.[^20][^7]

Quel protocole convient à WordPress ?

Utilisez MCP pour exposer des capacités WordPress bornées, comme lire des articles, créer des brouillons ou vérifier un stock WooCommerce. N'utilisez A2A que pour exposer un agent éditorial, commerce ou support autonome qui porte un résultat plus large. Pour un guide pas à pas, voir Serveur MCP WordPress : le guide complet d'installation.

Quel protocole convient à n8n ou Make ?

Utilisez MCP lorsqu'un agent IA a besoin que des workflows soient exposés comme des outils. Utilisez A2A lorsqu'un workflow fonctionnant de façon indépendante se comporte comme un agent spécialiste, accepte des objectifs, maintient un état de tâche et retourne des livrables.

A2A nécessite-t-il MCP ?

Non. Un agent A2A peut utiliser des API classiques, un accès direct à une base de données, ou aucun outil externe. MCP est simplement une façon standardisée et réutilisable de lui donner des capacités.

MCP nécessite-t-il A2A ?

Non. De nombreuses applications IA utiles ont besoin d'outils, mais pas de collaboration multi-agents.

MCP peut-il gérer une saisie humaine ?

Oui. L'elicitation MCP permet à un serveur de demander une information structurée via le client, y compris en mode formulaire et en mode URL pour les interactions externes sensibles.[^10]

A2A peut-il retourner des fichiers ?

Oui. Les artefacts A2A représentent des livrables concrets — documents, images, tableurs ou données structurées — et peuvent être diffusés de façon incrémentale.[^9][^3]

A2A est-il stable ?

A2A v1.0 a été publié en mars 2026 comme première version stable, prête pour la production.[^8]

Quelle est la spécification MCP actuelle ?

En octobre 2026, la dernière spécification stable est datée du 28 juillet 2026. Elle a introduit la révision la plus importante depuis le lancement, et l'adoption par les SDK peut encore varier.[^21][^22]

Busony : construire la bonne architecture d'agents

La partie difficile n'est que rarement de choisir un acronyme à la mode. C'est de définir la bonne frontière entre outils déterministes, données propriétaires, agents autonomes et approbation humaine.

Busony conçoit des systèmes agentiques pour le marketing, le développement export, la génération de leads, la publication, WordPress et l'automatisation métier. Une mission type peut inclure :

• Cartographier les fonctions qui doivent rester des API, devenir des outils MCP, ou devenir des agents A2A.
• Construire des serveurs MCP sécurisés pour WordPress, le CRM, les données et les workflows internes.
• Concevoir des agents spécialistes avec des contrats de tâche A2A clairs.
• Connecter des agents à Claude, ChatGPT, Gemini ou des modèles privés.
• Mettre en œuvre les permissions, la validation, les journaux d'audit et l'approbation humaine.
• Construire des pipelines export et contenu multilingues sans enfermer l'architecture dans un seul fournisseur de modèle.

L'objectif n'est pas de maximiser le nombre d'agents. C'est de créer le système fiable le plus petit possible, capable de déléguer un travail complexe tout en gardant les données, les permissions et les décisions métier sous contrôle.

Contactez Busony pour concevoir le bon équilibre entre outils MCP et agents A2A pour votre organisation.

Références

[^1]: Agent2Agent (A2A) Protocol Specification — A2A Project. [^2]: Agent2Agent (A2A) Protocol — A2A Project. [^3]: Key Concepts — Agent2Agent (A2A) Protocol. [^4]: Server overview — Model Context Protocol. [^5]: Architecture — Model Context Protocol. [^6]: Understanding MCP clients — Model Context Protocol. [^7]: Agent2Agent (A2A) Project — GitHub. [^8]: A2A Protocol Ships v1.0: Production-Ready Standard for Agent-to-Agent Communication — A2A Project. [^9]: Key Concepts — Agent2Agent Protocol (A2A). [^10]: Elicitation — Model Context Protocol. [^11]: Multi-agent patterns — Microsoft Learn. [^12]: Cancellation — Model Context Protocol. [^13]: Transports overview — Model Context Protocol. [^14]: Streamable HTTP — Model Context Protocol. [^15]: stdio — Model Context Protocol. [^16]: Basic overview — Model Context Protocol. [^17]: Authorization — Model Context Protocol. [^18]: Agent2Agent (A2A) Protocol Specification — A2A Project. [^19]: Specification — Model Context Protocol. [^20]: Model Context Protocol — GitHub. [^21]: Release notes — Model Context Protocol blog. [^22]: Releases — modelcontextprotocol/modelcontextprotocol, GitHub.