MCP vs A2A vs ANP : protocoles agents IA expliqués

Que sont les protocoles pour agents IA et pourquoi sont-ils importants ?

Les protocoles pour agents IA sont des standards ouverts qui définissent comment les agents se connectent aux outils, communiquent entre eux et découvrent des pairs sur le réseau. Sans eux, chaque intégration revient à écrire un wrapper d'API sur mesure. Avec eux, on peut remplacer le modèle ou l'outil sans tout casser.

Trois protocoles comptent pour les développeurs qui construisent des systèmes d'agents : MCP (Model Context Protocol), A2A (Agent-to-Agent Protocol) et ANP (Agent Network Protocol). Ce ne sont pas des concurrents. Ce sont des couches dans une pile.

MCP connecte les agents aux outils et aux données. A2A permet aux agents de déléguer des tâches à d'autres agents. ANP gère la découverte entre réseaux. Si vous hébergez vos agents sur un VPS, savoir où se situe chaque protocole vous évite de sur-concevoir un cas simple ou de sous-concevoir un cas complexe.

Cet article est le modèle mental. Pas de code. Juste la carte dont vous avez besoin avant de commencer à construire.

Qu'est-ce que MCP (Model Context Protocol) ?

MCP est un standard ouvert, créé à l'origine par Anthropic, qui définit comment les agents IA se connectent à des outils et des sources de données externes. Les serveurs MCP exposent des capacités aux clients MCP intégrés dans les applications IA. Imaginez un port USB pour l'IA : une interface unique entre n'importe quel agent et n'importe quel outil. Anthropic a transféré MCP à l'Agentic AI Foundation (AAIF) sous la Linux Foundation en décembre 2025.

Avant MCP, connecter un modèle IA à une base de données signifiait écrire une intégration sur mesure. Le connecter à une deuxième base demandait d'en écrire une autre. MCP remplace ce schéma par un protocole universel. On construit un serveur MCP pour sa base de données, et chaque agent compatible MCP peut l'utiliser.

Comment fonctionne MCP ?

MCP définit trois rôles :

Host : L'application IA (Claude Desktop, Cursor, votre application personnalisée). Il gère un ou plusieurs clients MCP.
Client : Un connecteur à l'intérieur du host qui maintient une connexion 1:1 avec un serveur MCP.
Server : Un service léger qui expose des outils, des ressources et des prompts aux clients.

La communication utilise JSON-RPC 2.0 sur l'un des deux types de transport :

stdio : Entrée/sortie standard. Idéal pour les serveurs locaux sur la même machine. Le host lance le serveur comme processus fils.
Streamable HTTP : Transport HTTP qui permet aux serveurs MCP de fonctionner comme services distants. Le client envoie des requêtes JSON-RPC par HTTP POST. Le serveur peut streamer les réponses. C'est ce qui permet d'exécuter des serveurs MCP sur un VPS et de s'y connecter à distance.

L'ancien transport SSE (Server-Sent Events) fonctionne encore, mais il est remplacé par Streamable HTTP, qui supporte le fonctionnement sans état et la scalabilité horizontale sans sessions persistantes.

Les serveurs MCP exposent trois types de primitives :

Primitive	Fonction	Contrôle
Tools	Fonctions que le modèle IA peut appeler (interroger une base, envoyer un email, exécuter un script)	Piloté par le modèle (le LLM décide quand invoquer)
Resources	Données que l'agent peut lire (fichiers, enregistrements, réponses API)	Piloté par l'application (le host décide quoi exposer)
Prompts	Messages et workflows modèles	Piloté par l'utilisateur (l'utilisateur choisit parmi les prompts disponibles)

Les connexions sont avec état. Client et serveur négocient les capacités pendant l'initialisation, puis échangent des messages sur une connexion persistante. Les serveurs peuvent aussi demander du sampling (demander au LLM de générer du texte) et de l'elicitation (demander une saisie à l'utilisateur), ce qui active un comportement agentique récursif.

Quel est l'état de l'écosystème MCP en 2026 ?

MCP est le protocole d'intégration par défaut pour l'outillage IA en 2026 :

97M+ téléchargements mensuels des SDK en Python et TypeScript
10 000+ serveurs MCP publics en production
Adopté par toutes les grandes plateformes IA : Claude, ChatGPT, Gemini, Copilot, Cursor, VS Code
Gouverné par l'AAIF sous la Linux Foundation, co-fondée par Anthropic, OpenAI et Block
Version actuelle de la spécification : 2025-11-25

La feuille de route 2026 se concentre sur la mise en production de Streamable HTTP à grande échelle : gestion sans état des requêtes, scalabilité horizontale simplifiée, et méthode standard pour que les registres découvrent les capacités des serveurs sans se connecter.

Qu'est-ce que A2A (Agent-to-Agent Protocol) ?

A2A (Agent-to-Agent Protocol) est un protocole ouvert créé à l'origine par Google qui standardise la communication et la collaboration entre agents IA. Un agent envoie une tâche à un autre en JSON-RPC sur HTTP. L'agent receveur publie une Agent Card décrivant ses capacités, ses exigences d'authentification et son URL d'endpoint. A2A gère le cycle de vie des tâches, le streaming des résultats et les notifications push pour les opérations longues.

MCP connecte un agent aux outils. A2A connecte un agent à d'autres agents. Les serveurs MCP sont transparents : on voit exactement ce qu'ils font. Les agents A2A sont opaques. L'agent appelant ne sait pas et n'a pas besoin de savoir quel modèle, framework ou logique tourne dans l'agent distant. Il envoie une tâche et récupère les résultats.

Comment fonctionne A2A ?

A2A définit trois acteurs :

User : L'humain ou le service automatisé qui demande du travail.
A2A Client : L'application qui envoie des tâches au nom de l'utilisateur.
A2A Server : Un agent distant exposant un endpoint HTTP. Il fonctionne comme une boîte noire.

Les Agent Cards sont le mécanisme de découverte. Chaque serveur A2A publie un document JSON (généralement à /.well-known/agent-card.json) qui décrit :

L'identité de l'agent (nom, description, fournisseur)
L'URL de l'endpoint de service
Les capacités supportées (streaming, notifications push)
Les compétences disponibles avec descriptions
Les exigences d'authentification
Une signature numérique optionnelle pour vérification

Une Task (tâche) est l'unité de travail. Chaque tâche a un identifiant unique et progresse à travers un cycle de vie :

submitted → working → completed
                   → failed
                   → canceled
                   → rejected
           → input-required (multi-tour : l'agent a besoin de plus d'informations du client)

Les messages contiennent des Parts : texte, références de fichiers ou données JSON structurées. Les résultats de tâches sont appelés Artifacts, qui contiennent aussi des Parts. Un agent peut retourner un fichier de code, un résumé textuel et un rapport JSON en une seule réponse.

A2A supporte trois modèles de communication :

Request/Response : Le client envoie une tâche, interroge le statut avec GetTask.
Streaming (SSE) : Mises à jour incrémentales en temps réel sur des connexions HTTP persistantes. Le client appelle SendStreamingMessage et reçoit des événements au fil du travail de l'agent.
Push Notifications (Webhooks) : Pour les tâches longues, l'agent envoie les mises à jour de statut par POST à une URL webhook enregistrée par le client.

Toute la communication utilise JSON-RPC 2.0 sur HTTPS. La version 0.3 a ajouté le support gRPC et les Agent Cards signées. La version actuelle est A2A v1.0.0.

Comment A2A et ACP ont-ils fusionné ?

IBM a lancé l'Agent Communication Protocol (ACP) en mars 2025 pour alimenter sa plateforme BeeAI. Google a annoncé A2A le mois suivant. Les deux protocoles résolvaient le même problème : la communication entre agents.

En août 2025, la Linux Foundation a annoncé la fusion d'ACP dans A2A. L'équipe ACP d'IBM, dirigée par Kate Blair, a rejoint le comité de pilotage technique d'A2A aux côtés de Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow et SAP. La plateforme BeeAI est passée d'ACP à A2A, et le développement spécifique à ACP a cessé.

Si vous évaluiez ACP séparément, arrêtez. La réponse est A2A.

Qu'est-ce que ANP (Agent Network Protocol) ?

ANP (Agent Network Protocol) est un protocole pair-à-pair qui permet aux agents IA de se découvrir et de communiquer sur des réseaux ouverts sans autorité centrale. Contrairement au modèle client-serveur de MCP et à la délégation de tâches client-serveur d'A2A, ANP traite chaque agent comme un pair égal. Il utilise les identifiants décentralisés W3C (DIDs) pour l'identité, JSON-LD pour l'échange de données, et inclut une couche de méta-protocole où les agents négocient leur mode de communication.

ANP cible un problème différent de MCP et A2A. Ces protocoles supposent que l'on sait quel serveur ou agent contacter. ANP répond à la question : comment un agent trouve-t-il d'autres agents avec lesquels il n'a jamais interagi, au-delà des frontières organisationnelles, sans annuaire central ?

En quoi ANP diffère-t-il d'A2A ?

ANP a une architecture à trois couches :

Couche 1 : Identité et communication chiffrée. Chaque agent reçoit un identifiant décentralisé W3C utilisant la méthode did:wba (Web-Based Agent). Chaque DID correspond à un document DID hébergé en HTTPS, la résolution d'identité utilise donc l'infrastructure web existante. Deux agents peuvent vérifier mutuellement leur identité et établir des canaux chiffrés sans autorité centrale.

Couche 2 : Méta-protocole. Les agents négocient dynamiquement les protocoles de communication. Au lieu que les deux agents doivent supporter le même protocole fixe, ils échangent des propositions structurées, s'accordent sur un protocole, puis communiquent en l'utilisant. Cela rend ANP adaptable à des scénarios que l'approche JSON-RPC fixe d'A2A ne peut pas gérer.

Couche 3 : Protocole applicatif. Les descriptions d'agents utilisent JSON-LD lié aux ontologies schema.org. La découverte fonctionne de deux manières :

Découverte active : Interroger l'endpoint /.well-known/agent-descriptions d'un domaine.
Découverte passive : Les agents s'inscrivent auprès de services d'indexation qui parcourent et cataloguent les descriptions.

Comparaison architecturale entre ANP et A2A :

Aspect	A2A	ANP
Topologie	Client-serveur	Pair-à-pair
Identité	Agent Cards (JSON auto-publié)	W3C DIDs (décentralisés, vérifiables)
Découverte	URL connue (`/.well-known/agent-card.json`)	Indexation décentralisée + endpoints well-known
Flexibilité du protocole	Fixe (JSON-RPC 2.0)	Négociation par méta-protocole
Format de données	JSON Parts (texte, fichiers, données structurées)	JSON-LD avec liens sémantiques

Statut actuel : ANP est encore au stade de proposition et de développement initial. Il dispose d'un dépôt GitHub et d'un livre blanc du W3C Community Group, mais pas de SDK de production ni d'adoption large. La spécification n'est pas gouvernée par l'AAIF.

Comment se comparent MCP, A2A et ANP ?

Les trois protocoles comparés sur les dimensions qui comptent quand on conçoit un système d'agents :

	MCP	A2A	ANP
Problème résolu	Connexion agent-outil	Délégation de tâches agent-agent	Découverte et communication entre agents sur réseau ouvert
Architecture	Client-serveur (host → client → server)	Client-serveur (client → agent distant)	Pair-à-pair (agent ↔ agent)
Transport	stdio, Streamable HTTP	HTTPS (JSON-RPC 2.0), SSE, gRPC	HTTPS, négociable via méta-protocole
Modèle d'identité	Identité du serveur implicite (configurée par le host)	Agent Cards (JSON auto-publié)	W3C DIDs (`did:wba`)
Format de données	JSON-RPC 2.0	JSON-RPC 2.0 avec Parts (texte, fichiers, structuré)	JSON-LD (sémantique, données liées)
Découverte	Configuration manuelle ou consultation de registre	`/.well-known/agent-card.json`	Résolution DID + indexation décentralisée
Gouvernance	AAIF / Linux Foundation	AAIF / Linux Foundation	W3C Community Group (indépendant)
Version de la spec	2025-11-25	v1.0.0	Stade livre blanc
Maturité	Production (97M+ téléchargements mensuels des SDK)	Production (v1.0.0, SDK des principaux éditeurs)	Développement initial (pas de SDK de production)
Cas d'usage	Donner à votre agent l'accès aux bases, API, fichiers	Faire déléguer du travail par votre agent à des agents spécialisés	Permettre aux agents de se trouver sur l'internet ouvert

Comment ces protocoles fonctionnent-ils ensemble ?

Ces protocoles ne sont pas des alternatives. Ce sont des couches. Prenons un exemple concret.

Imaginons que vous faites tourner un agent de programmation sur votre VPS. Il doit :

Lire des fichiers depuis votre dépôt Git
Interroger la base de données de votre projet pour obtenir le schéma
Demander à un agent de revue séparé de vérifier son travail
Trouver un agent de déploiement géré par l'équipe infrastructure de votre client

Les protocoles s'empilent ainsi :

┌─────────────────────────────────────────────────────────┐
│                    Votre VPS                             │
│                                                         │
│  ┌──────────────┐    MCP     ┌───────────────────────┐  │
│  │              │◄──────────►│ MCP Server: Git tools  │  │
│  │  Agent de    │            └───────────────────────┘  │
│  │  program-    │    MCP     ┌───────────────────────┐  │
│  │  mation      │◄──────────►│ MCP Server: DB schema  │  │
│  │  (Host)      │            └───────────────────────┘  │
│  │              │                                       │
│  │              │    A2A     ┌───────────────────────┐  │
│  │              │───────────►│ Review Agent (A2A)     │  │
│  └──────┬───────┘            └───────────────────────┘  │
│         │                                               │
└─────────┼───────────────────────────────────────────────┘
          │
          │  ANP (découverte inter-réseau)
          ▼
┌─────────────────────┐
│ Agent de déploiement │
│ du client (découvert │
│ via résolution DID)  │
└─────────────────────┘

Couche 1 (MCP) : L'agent de programmation utilise des clients MCP pour se connecter à des serveurs MCP locaux pour les opérations Git et les requêtes en base. Ce sont des intégrations d'outils. L'agent appelle des fonctions et lit des données.

Couche 2 (A2A) : L'agent de programmation délègue la revue de code à un agent de revue séparé sur le même serveur (ou un autre). Il envoie une tâche via A2A, l'agent de revue travaille de façon asynchrone et streame les résultats. L'agent de programmation ne sait pas quel modèle ou framework l'agent de revue utilise.

Couche 3 (ANP) : L'agent de programmation doit trouver un agent de déploiement avec lequel il n'a jamais interagi, géré par une autre organisation. La découverte par DID d'ANP localise l'agent, vérifie son identité et négocie un protocole de communication.

Pour la plupart des configurations auto-hébergées aujourd'hui, MCP suffit. Ajoutez A2A quand vous avez plusieurs agents spécialisés qui doivent collaborer. ANP n'est pas encore utile en production, mais il comptera quand les écosystèmes d'agents franchiront les frontières organisationnelles.

Quel protocole utiliser ?

Commencez par le protocole le plus simple qui résout votre problème. N'ajoutez des couches que quand vous atteignez une limite.

Guide de décision :

Votre agent doit-il accéder à des outils, bases de données ou API ? Oui → Implémentez MCP. Construisez ou installez des serveurs MCP pour vos sources de données. Cela couvre 80 % des besoins d'intégration d'agents.
Avez-vous plusieurs agents qui doivent se déléguer des tâches ? Oui → Ajoutez A2A. Publiez des Agent Cards pour chaque agent. Utilisez A2A pour la délégation de tâches et le streaming de résultats. Non → Vous n'avez pas besoin d'A2A. Si un seul agent appelle des API via MCP, c'est suffisant.
Vos agents doivent-ils découvrir des agents inconnus au-delà des frontières organisationnelles ? Oui → Évaluez ANP quand des SDK de production seront disponibles. Aujourd'hui, vous géreriez cela avec un registre manuel ou un annuaire A2A partagé. Non → Ignorez ANP pour l'instant.

Schémas courants :

Configuration	Protocoles nécessaires
Agent unique + outils (la plupart des projets)	MCP seul
Plusieurs agents spécialisés sur un serveur	MCP + A2A
Collaboration inter-organisations	MCP + A2A + ANP (à maturité)
Place de marché d'agents / découverte ouverte	A2A + ANP

Si vous débutez avec les agents IA sur un VPS, commencez par MCP. Connectez un agent à un outil. Faites-le fonctionner. Puis faites évoluer l'architecture selon vos besoins.

Quels sont les risques de sécurité de chaque protocole ?

Chaque protocole ouvre une surface d'attaque différente. Si vous hébergez vos agents vous-même, voici les menaces qui comptent.

Protocole	Menace	Conséquence	Atténuation
MCP	Server-Side Request Forgery (SSRF)	Un prompt malveillant pousse l'agent à appeler un outil MCP qui envoie des requêtes vers des services internes (endpoints de métadonnées, bases de données, panneaux d'administration).	Exécutez les serveurs MCP dans des espaces réseau isolés. Restreignez les connexions sortantes par pare-feu. Validez les entrées côté serveur.
MCP	Descriptions d'outils non fiables	Les annotations d'outils MCP (descriptions, schémas de paramètres) viennent du serveur. Un serveur compromis peut mentir sur ce que fait un outil pour manipuler le LLM.	Ne connectez que des serveurs MCP que vous contrôlez ou en lesquels vous avez confiance. Vérifiez les descriptions. La spécification MCP marque explicitement les annotations d'outils comme non fiables.
A2A	Usurpation d'identité d'agent	Sans Agent Cards signées, un attaquant peut publier une fausse Agent Card à une URL connue et intercepter les tâches destinées à un agent légitime.	Utilisez la signature numérique des Agent Cards d'A2A (ajoutée en v0.3). Vérifiez les signatures avant d'envoyer des tâches. Épinglez les endpoints d'agents connus.
A2A	Exfiltration de données de tâches	Les tâches peuvent contenir des données sensibles (code, identifiants, logique métier). Si l'agent distant est compromis, ces données fuitent.	Chiffrez les données sensibles au niveau applicatif. Utilisez TLS mutuel entre agents. Minimisez les données envoyées dans les tâches.
ANP	Amorçage de confiance DID	La méthode `did:wba` repose sur des documents DID hébergés en HTTPS. Si un domaine est compromis, toutes les identités d'agents de ce domaine sont compromises.	Utilisez des domaines séparés pour l'identité des agents. Surveillez les changements de documents DID. Implémentez l'épinglage de documents DID pour les agents connus.
ANP	Abus du méta-protocole	La couche de négociation pourrait être exploitée pour amener un agent à utiliser un protocole de communication non sécurisé ou malveillant.	Restreignez la négociation du méta-protocole à une liste blanche de protocoles connus. Journalisez et auditez toutes les négociations de protocole.

Pour un guide complet sur la sécurisation de votre serveur d'agents, consultez .

Où va la gouvernance ?

MCP et A2A sont tous deux sous l'Agentic AI Foundation (AAIF), au sein de la Linux Foundation. L'AAIF a été créée en décembre 2025 par trois co-fondateurs : Anthropic, OpenAI et Block. Google, Microsoft, AWS, Bloomberg et Cloudflare ont rejoint comme membres platinum. Aucun éditeur ne contrôle seul la direction du protocole.

L'AAIF héberge aussi goose (le framework d'agents open source de Block) et AGENTS.md (le standard d'OpenAI pour donner aux agents IA des consignes spécifiques au projet).

ANP est gouverné de manière indépendante par un W3C Community Group. Il ne fait pas partie de l'AAIF. Que ANP rejoigne l'AAIF ou reste indépendant aura un impact sur sa trajectoire d'adoption.

Cette séparation de gouvernance a une conséquence pratique : MCP et A2A évolueront ensemble sous une direction coordonnée. ANP évoluera selon son propre calendrier. Si vous faites des paris architecturaux, MCP et A2A présentent un risque de gouvernance plus faible.

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.