MCP, A2A et ACP : comparatif des protocoles pour agents d’IA

Trois sigles reviennent sans cesse dans les discussions sur les agents d’IA, et beaucoup de gens les utilisent indifféremment. MCP, A2A et ACP ont tout l’air de rivaux, pourtant ils résolvent des problèmes différents à des couches différentes de la pile. L’un connecte un agent à des outils. Un autre permet aux agents de se confier du travail entre eux. Le troisième était une idée pertinente, absorbée par un autre protocole avant que la plupart des équipes ne l’aient réellement mise en œuvre. Choisissez le mauvais et vous devrez réécrire votre couche d’intégration quelques mois plus tard.

Ce comparatif met les trois protocoles côte à côte, avec les faits qui comptent en octobre 2026 : qui a créé chacun, ce qu’il transmet sur le réseau, qui le gouverne et lequel convient à votre projet. Pas de battage, juste une carte.

La réponse courte

Voici toute l’histoire en un seul tableau. Gardez-le ouvert pendant la lecture.

💡 La version en une ligne : MCP est la façon dont un agent atteint vers le bas les outils. A2A est la façon dont un agent atteint latéralement d’autres agents. ACP a tenté le travail latéral, puis a rejoint A2A.

Si vous ne retenez qu’une chose, retenez que MCP et A2A sont complémentaires, pas concurrents. ACP est celui qui ne tient plus debout tout seul.

Ce que fait MCP

Anthropic a publié en open source le Model Context Protocol en novembre 2024 pour résoudre un problème banal mais coûteux. Chaque application d’IA avait besoin d’un code de liaison sur mesure pour chaque outil utilisé, donc dix applications et vingt outils représentaient deux cents intégrations. MCP remplace cette grille par une prise standard unique.

L’USB-C des outils d’agents

La comparaison que tout le monde utilise est celle de l’USB-C, et elle tient la route. Un éditeur d’outil écrit un seul serveur MCP. Toute application qui parle MCP peut l’utiliser, qu’il s’agisse d’un éditeur de code, d’un client de chat ou d’un agent maison écrit le week-end dernier.

Les chiffres expliquent pourquoi il s’est imposé sur la couche des outils. Tous les grands fournisseurs d’IA, dont Anthropic, OpenAI, Google DeepMind, Microsoft et AWS, l’ont adopté. Au début de 2026, les SDK totalisaient environ 97 millions de téléchargements mensuels, et plus de 10 000 serveurs publics étaient actifs. Le 9 décembre 2025, Anthropic a confié MCP à l’Agentic AI Foundation, un fonds à vocation précise placé sous l’égide de la Linux Foundation, cofondé par Anthropic, Block et OpenAI. Aucun éditeur unique ne le possède plus.

Outils, ressources et prompts

Un serveur MCP peut proposer trois types d’éléments :

• Outils : des fonctions que le modèle peut appeler, comme interroger une base de données, créer un ticket ou redimensionner une image.
• Ressources : des données en lecture seule, comme des fichiers, des enregistrements ou des documents que l’application hôte peut charger dans le contexte.
• Prompts : des modèles réutilisables qu’un utilisateur peut déclencher volontairement.

L’application hôte (votre IDE ou votre client de chat) exécute un client MCP par serveur et transmet les messages en JSON-RPC 2.0. Les serveurs locaux communiquent via stdio. Les serveurs distants utilisent Streamable HTTP. Un appel d’outil ressemble à ceci :

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_orders",
    "arguments": { "customer_id": "C-1042" }
  }
}

Copier le prompt

Il y a un inconvénient pratique. Chaque description d’outil est un texte que le modèle doit lire avant d’agir, donc un serveur de soixante outils consomme la fenêtre de contexte avant même le début de la conversation. Les équipes qui utilisent bien MCP gardent des serveurs petits, nomment clairement leurs outils et ne chargent que ce dont la tâche a besoin.

💡 Là où MCP s’arrête : un serveur MCP est passif. Il répond quand on l’appelle. Il ne planifie pas, ne négocie pas, ne conteste pas et ne lance pas un travail de quatre heures pour vous prévenir à la fin. C’est précisément là que A2A commence.

Ce que fait A2A

Google a annoncé le protocole Agent2Agent en avril 2025 avec plus de 50 partenaires de lancement, puis l’a confié à la Linux Foundation en juin 2025. L’objectif : permettre à des agents conçus par différents éditeurs, sur différents frameworks, de travailler ensemble comme des pairs plutôt que comme des inconnus.

Cartes d’agent et tâches

Chaque agent A2A publie une Agent Card, un petit document JSON à une URL bien connue. Elle indique le nom de l’agent, ce qu’il sait faire, où le joindre et quelle authentification il attend. Un agent client lit d’abord la carte, puis décide si cet agent distant convient à la mission.

Le travail circule sous forme de tâche. Une tâche reçoit un identifiant et passe par plusieurs états : soumise, en cours, parfois suspendue en attendant une information supplémentaire, puis terminée, en échec ou annulée. Les messages transportent du texte, des fichiers ou des données structurées, et le résultat final revient sous forme d’artefacts.

Opaques par conception

Voici le choix de conception le plus important. Les agents A2A restent opaques. Ils ne partagent ni leur mémoire, ni leurs prompts internes, ni leurs listes d’outils. L’appelant ne voit que la carte de l’agent et les résultats, rien d’autre. Un agent d’achats dans une entreprise peut confier une mission à un agent logistique dans une autre sans exposer le moindre système interne.

Les longs traitements sont eux aussi pris en charge nativement. A2A gère le streaming via les server-sent events et les notifications push pour les travaux qui durent des minutes ou des heures. La version 1.0 est sortie en 2026, et le comité technique directeur compte Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow et SAP. Cette liste compte, car un protocole soutenu par des concurrents est un protocole sur lequel vous pouvez miser.

Ce qu’il est advenu d’ACP

Le pari REST d’IBM

IBM Research et l’équipe BeeAI ont présenté l’Agent Communication Protocol en mars 2025, avec une conception délibérément simple. Il reposait sur des points d’accès REST classiques. Vous pouviez appeler un agent avec cURL ou Postman, sans SDK. Il était conçu pour être asynchrone d’abord, ce qui convenait aux travaux d’agents de longue durée, et il s’intégrait parfaitement à la plateforme BeeAI.

La fusion dans A2A

Deux protocoles visant le même problème latéral, c’était un de trop. En août 2025, IBM Research et Google ont annoncé qu’ACP rejoindrait A2A sous l’égide de LF AI & Data, rattaché à la Linux Foundation. Kate Blair, qui dirigeait ACP chez IBM Research, a rejoint le comité technique directeur d’A2A. Le développement d’ACP s’est arrêté, la spécification a été archivée, et les utilisateurs de BeeAI ont reçu des chemins de migration vers A2A.

Les idées d’ACP, avec état et asynchrones, vivent désormais dans A2A. Si une présentation d’éditeur en 2026 cite ACP comme une troisième option active, vérifiez la date de la diapositive.

💡 Attention à la collision de noms. D’autres projets utilisent les mêmes trois lettres. L’Agent Client Protocol de Zed relie les éditeurs de code aux agents de programmation. L’Agentic Commerce Protocol d’OpenAI et Stripe gère le paiement au sein des chats d’IA. Ni l’un ni l’autre n’est l’ACP d’IBM, et aucun ne concurrence MCP ou A2A.

Comparaison côte à côte

Lisez la première ligne deux fois. L’accès aux outils et la collaboration entre agents sont deux missions différentes, et chaque protocole en couvre une.

Différences de sécurité

La sécurité diffère d’une couche à l’autre.

Pour MCP, les risques résident dans ce qu’un outil peut atteindre. Les serveurs distants utilisent une autorisation basée sur OAuth, mais le vrai danger vient des permissions trop larges et des sorties d’outils qui contiennent des instructions cachées, appelées injection de prompt. Un serveur capable de lire des fichiers et d’envoyer des e-mails offre à un modèle manipulé un chemin court vers une fuite.

Pour A2A, le risque est la confiance. Une Agent Card déclare les schémas d’authentification qu’elle accepte, et les appels reposent sur la sécurité HTTP standard. La question ouverte est de savoir s’il faut croire une carte trouvée sur internet. Traitez chaque carte distante comme une entrée non fiable.

Une courte liste de contrôle vaut pour les deux :

1. Limitez les jetons à un seul serveur ou agent, avec les permissions les plus restreintes qui fonctionnent.
2. Journalisez chaque appel d’outil et chaque tâche déléguée : qui a demandé, et ce qui est revenu.
3. Exigez un clic humain avant toute action destructive, comme une suppression, un paiement ou un e-mail sortant.
4. Relisez les descriptions d’outils et les Agent Cards comme vous relisez vos dépendances, car elles orientent le modèle.

Transport et format sur le réseau

Les trois utilisent des variantes de HTTP et de JSON, donc le débogage est moins exotique que ne le laissent penser les sigles. MCP sur stdio est le plus simple à essayer : lancez un serveur local, envoyez du JSON en entrée, lisez du JSON en sortie. Le MCP Inspector offre une vue visuelle du même trafic. A2A demande un peu plus de formalités, car un client doit récupérer une carte avant d’envoyer une tâche. L’ACP d’IBM était le plus simple des trois à tester avec une simple commande cURL, ce qui explique en partie son succès auprès des développeurs.

Comment les trois s’articulent

Imaginez un assistant de planification de voyage. Un utilisateur lui demande de réserver un week-end à Lisbonne. Le déroulement est le suivant :

1. L’agent orchestrateur de l’utilisateur lit la demande et la découpe en missions.
2. Il utilise MCP pour consulter l’agenda de l’utilisateur et ses préférences enregistrées.
3. Il utilise A2A pour confier « trouver un hôtel » à un agent hôtelier exploité par une autre entreprise.
4. Cet agent hôtelier utilise MCP en interne pour interroger son inventaire de chambres et son outil de paiement.
5. Le résultat revient via A2A sous forme d’artefact, et l’orchestrateur le présente.

MCP fonctionne à l’intérieur de chaque agent. A2A fonctionne entre les agents. Cette superposition explique pourquoi on parle de pile et non d’affrontement.

Les standards de ce type tendent à s’imposer pour la même raison que les conteneurs maritimes. Dès que chaque port, chaque camion et chaque grue s’accordent sur une même boîte, plus personne ne se soucie de qui l’a fabriquée. La valeur se déplace vers tout ce qui s’y insère. MCP l’a fait pour les outils. A2A tente le même mouvement pour la collaboration entre agents, et la fusion avec ACP a retiré la principale raison d’attendre.

La gouvernance neutre joue aussi son rôle. MCP relève de l’Agentic AI Foundation et A2A de la Linux Foundation, donc aucun des deux ne dépend de la feuille de route d’une seule entreprise. Pour une équipe qui valide un projet pluriannuel, cela vaut plus que n’importe quelle fonctionnalité d’une fiche technique.

Lequel utiliser

Partez de la mission, pas du sigle.

Choisir MCP quand

• Votre agent doit appeler des outils comme des bases de données, des systèmes de fichiers, un moteur de recherche ou des applications SaaS.
• Vous voulez une seule intégration qui fonctionne avec plusieurs applications et modèles d’IA.
• Vous livrez un produit et souhaitez que les agents d’autres personnes accèdent à vos données.
• Le côté distant est une fonction, pas un décideur.

Choisir A2A quand

• Le côté distant est un autre agent qui planifie, décide et peut nécessiter plusieurs échanges.
• Les agents proviennent d’équipes, d’éditeurs ou de frameworks différents.
• Les travaux durent assez longtemps pour que vous ayez besoin de streaming ou de mises à jour push.
• Vous devez garder les éléments internes de chaque agent privés.

Trois erreurs courantes

1. Encapsuler chaque agent comme un outil MCP. Cela paraît propre, mais vous perdez l’état de la tâche, le streaming et la négociation. Un travail de quatre heures ne peut pas se cacher derrière un appel de fonction synchrone.
2. Utiliser A2A pour une simple fonction. Une conversion de devise n’a pas besoin d’une Agent Card ni d’un cycle de vie de tâche. Utilisez MCP.
3. Faire confiance aux anciens tutoriels ACP. Ils figurent encore en bonne place dans les résultats de recherche. Vérifiez la date de publication avant de copier le moindre point d’accès.

Et ACP ? Pour un nouveau projet, passez-le. Si vous faites déjà tourner l’ACP d’IBM dans un projet BeeAI, prévoyez une migration vers A2A et traitez les anciens points d’accès comme un pont, pas comme une destination.

La plupart des systèmes réels ont besoin des deux protocoles. Commencez par MCP pour les outils, car ce besoin apparaît dès le premier jour. Ajoutez A2A quand un second agent entre en jeu.

Essayez sur Picasso IA

Le travail sur les protocoles consiste surtout à écrire : Agent Cards, schémas d’outils, spécifications et diagrammes. Un modèle de langage performant accélère chacune de ces tâches.

Utiliser Claude Sonnet 5 sur PicassoIA

Claude Sonnet 5 gère les tâches de programmation et d’utilisation d’outils en plusieurs étapes, ce qui en fait un partenaire de rédaction pratique pour le travail sur les protocoles. Voici une façon rapide de l’utiliser :

1. Ouvrez la page du modèle sur Picasso IA et repérez la zone Prompt.
2. Rédigez une demande précise. Par exemple : « Rédigez une Agent Card A2A pour un agent de réservation d’hôtel avec trois compétences : rechercher des chambres, bloquer une chambre et annuler un blocage. Utilisez OAuth pour l’authentification. »
3. Réglez le niveau d’effort. La valeur par défaut est low, qui désactive la réflexion pour des réponses plus rapides et moins chères. Utilisez medium ou high pour relire des schémas, et xhigh ou max quand un bug s’étend sur plusieurs fichiers.
4. Ajoutez un prompt système une seule fois, par exemple « Vous êtes un relecteur de protocoles. Signalez d’abord les failles de sécurité. » Il s’applique ensuite à toute la session.
5. Augmentez le nombre maximal de tokens si besoin. La valeur par défaut est de 8 192 tokens de sortie, suffisant pour un long schéma ou un squelette de serveur complet.
6. Joignez une image si vous en avez une. Une photo de votre croquis au tableau blanc sert de contexte, car le modèle lit les images.

Vous préférez un autre modèle ? Kimi K2.6 est optimisé pour la création d’agents d’IA et l’écriture de code, et GPT 5.6 Sol est conçu pour les tâches de programmation complexes.

Créez vos propres images

Chaque photo de cet article provient d’un prompt textuel. La méthode était simple : décrire le sujet, la lumière, l’objectif et la texture, puis laisser le modèle générer le rendu. Vous pouvez faire de même pour les visuels de blog, les photos de produits ou la planche d’inspiration de votre prochain lancement.

Essayez l’un de ces modèles sur Picasso IA :

• Seedream 4.5 pour des scènes photoréalistes riches en détails.
• Flux 2 Pro pour un très bon respect du prompt et un éclairage naturel.
• GPT Image 2 pour des images qui nécessitent un texte lisible.
• P-Image pour des ébauches rapides quand vous voulez tester des idées vite.

Ouvrez Picasso IA, choisissez un modèle et collez un prompt construit comme ceux derrière ces photos : sujet, décor, lumière, objectif, texture. Lancez trois variantes, gardez la meilleure et insérez-la dans votre prochain document ou présentation. Votre première image n’est qu’à un prompt.