MCP, WebMCP et A2A : quel protocole choisir pour vos agents IA en 2026

Par l'équipe de Kiwop · Agence Digitale spécialisée en Développement Logiciel et Intelligence Artificielle appliquée pour clients mondiaux en Europe et aux États-Unis · Publié le 19 avril 2026 · Dernière mise à jour : 19 avril 2026

TL;DR — À avril 2026 coexistent trois protocoles clés pour les agents IA. MCP (Model Context Protocol) connecte un agent avec ses outils et ses données ; c'est le standard de facto, donné à la Linux Foundation. WebMCP est la variante navigateur pour que les sites exposent des actions aux agents ; il reste émergent. A2A (Agent-to-Agent) connecte les agents entre eux ; v1.0 en production avec plus de 150 organisations. Utilisez MCP pour les tools, A2A pour orchestrer et WebMCP pour votre site.

Chaque semaine nous recevons la même question de comités de direction et d'équipes produit : « Nous construisons un agent IA, quel protocole utilisons-nous ? ». La bonne réponse n'est plus « MCP point final » — c'était le cas en 2025, mais 2026 a apporté une constellation de standards qui se complètent plus qu'ils ne se concurrencent. Ce qui est intéressant n'est pas lequel gagne : c'est lequel résout chaque problème.

Cet article est la comparaison technique qui nous aurait fait économiser des semaines de recherche il y a six mois. Elle est basée sur notre expérience réelle de construction d'assistants personnels avec Claude Code et MCP, sur le travail interne sur Nexo (notre SaaS de workspace en développement), et sur les sources officielles les plus récentes publiées par Anthropic, Google, Cloudflare, Vercel, la Linux Foundation et le W3C lui-même. Si vous cherchez une réponse binaire, vous ne l'aurez pas ici. Si vous cherchez un critère de décision, continuez à lire.

Pourquoi 2026 est l'année des protocoles agents IA

2023 a été l'année du prompt. 2024 a été l'année de l'outil (tool use). 2025 a été l'année de l'agent. Et 2026 est, sans aucun doute, l'année des protocoles. La raison est simple : quand il n'y a qu'un seul agent parlant avec une seule API, n'importe quel contrat ad hoc fonctionne. Quand vous avez des dizaines d'agents, des dizaines de modèles de différents fournisseurs, des centaines d'outils internes et externes, et des clients qui veulent connecter leurs propres agents aux vôtres, le chaos mange le produit.

L'explosion a été brutale. Anthropic reporte plus de 10 000 serveurs MCP publics actifs et 97 millions de téléchargements mensuels de SDK entre Python et TypeScript selon la note officielle de donation de MCP à la Linux Foundation. A2A, de son côté, est passé d'une proposition de Google en avril 2025 à compter plus de 150 organisations et être sous le parapluie de la Linux Foundation début 2026. Le 9 décembre 2025 s'est formalisée l'Agentic AI Foundation (AAIF) sous la Linux Foundation, avec Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare et Bloomberg comme membres platine — un mouvement couvert par TechCrunch qui marque la fin de l'ère des protocoles propriétaires.

La photo à avril 2026 est la suivante. Il y a trois protocoles que toute équipe technique doit comprendre : MCP, WebMCP et A2A. Il y a un quatrième, ACP (Agent Communication Protocol) d'IBM, qui se recoupe conceptuellement avec A2A et dont l'adoption aujourd'hui est considérablement moindre. Et il y a une pléthore d'initiatives adjacentes — AGENTS.md, Open Responses, ANP, LLMFeed — qui gravitent sans encore atteindre la même masse critique. Nous nous concentrerons sur les trois qui importent pour des décisions d'architecture réelles.

La fragmentation est un vrai problème. Comme le souligne l'enquête académique d'arXiv sur les protocoles d'interopérabilité d'agents, chaque protocole résout une couche différente du stack : le problème n'est pas d'en choisir un, c'est de comprendre dans quelle couche opère chacun et de les combiner sans créer des couplages inutiles. Voilà la thèse que nous allons développer.

MCP — Model Context Protocol (Anthropic, 2024)

MCP est, à avril 2026, le standard de facto pour connecter un agent IA avec des outils externes. Il a été publié par Anthropic en novembre 2024 comme protocole ouvert, et en sa première année il a parcouru le chemin que d'autres standards ont mis une décennie à parcourir : de proposition individuelle à infrastructure partagée de l'industrie.

Qu'est-ce que MCP conceptuellement

MCP définit un contrat entre deux parties : un client MCP (généralement l'agent ou l'hôte du modèle) et un serveur MCP (généralement un adaptateur vers un service externe : Gmail, GitHub, une base de données, un système interne). Le client découvre quels outils offre le serveur, lit son schéma, et les invoque avec des paramètres typés. La communication utilise JSON-RPC 2.0 sur un transport.

Le protocole ne couvre pas seulement les outils (tools) : il définit aussi des resources (contenu lisible statiquement, comme des fichiers ou des registres), des prompts (templates réutilisables) et — depuis la spécification du 25 novembre 2025 — opérations asynchrones, stateless servers, server identity et extensions officielles selon la spécification officielle. Cette évolution est ce qui a permis à MCP de passer de « connecter un client local » à « alimenter une infrastructure d'agents en production ».

Transports : stdio et Streamable HTTP

MCP supporte deux transports officiels selon la documentation de transports du spec :

• stdio : le client lance le serveur comme sous-processus local et communique par entrée/sortie standard. Idéal pour les exécutions locales, CLI et assistants personnels.
• Streamable HTTP : le serveur vit comme processus indépendant et expose un unique endpoint HTTP qui accepte POST et GET. Peut utiliser Server-Sent Events pour le streaming. C'est le standard de facto pour les serveurs distants en 2026, et il remplace l'ancien transport HTTP+SSE.

La règle rapide : stdio pour assistants personnels sur une machine, Streamable HTTP pour services partagés en production.

Serveurs disponibles et écosystème

À avril 2026, l'écosystème MCP couvre pratiquement tout service d'entreprise pertinent : Gmail, Google Calendar, Google Drive, Slack, Linear, GitHub, Notion, Jira, Confluence, Salesforce, HubSpot, Stripe, PostgreSQL, Snowflake, BigQuery et des dizaines d'autres. L'adoption traverse les frontières de fournisseur : OpenAI l'a supporté nativement dans ChatGPT en mars 2025, Microsoft l'a intégré dans Copilot, Google le supporte dans Gemini, et des éditeurs comme Cursor, Windsurf et VS Code parlent MCP nativement.

Cas d'usage optimaux

MCP brille quand il y a un agent qui a besoin d'accès à de nombreuses sources hétérogènes : un assistant personnel qui lit votre courrier et votre calendrier, un copilote de développement qui consulte votre code et vos tickets, un agent commercial qui croise les données de CRM et de facturation. Dans tous ces cas, le pattern est le même : l'agent invoque des outils typés sur des serveurs qui parlent avec des systèmes concrets.

Limitations

MCP n'est pas le bon outil quand le trafic est agent↔agent (c'est là qu'entre A2A), quand le consommateur est un navigateur et non un processus avec OAuth credentials préinstallés (c'est là qu'entre WebMCP), ni quand l'opération requiert des streams binaires massifs ou des latences submilliseconde (c'est là qu'entrent des API spécifiques). Et bien que l'adoption soit énorme, la sécurité reste un domaine de travail actif : il y a une littérature croissante sur le tool poisoning, le prompt injection via les descriptions d'outils, et des permissions difficiles à auditer. Tout agent MCP en production a besoin d'une couche de sandboxing et de confirmation que le protocole n'impose pas par lui-même.

WebMCP — le MCP pour le web (2025-2026)

WebMCP est le pari de Google et Microsoft pour transposer la philosophie MCP au navigateur et au web lui-même. Ce n'est pas une extension de MCP : c'est un standard parallèle, coordonné au sein du W3C Web Machine Learning Community Group, qui adapte le contrat client-serveur à l'environnement spécifique du navigateur. Nous avons déjà couvert la proposition initiale dans WebMCP : votre site web préparé pour les agents IA ; ici nous nous concentrons sur comment il se positionne face à MCP et A2A.

Pourquoi WebMCP et pas simplement MCP sur HTTP

A priori cela semble redondant : si MCP a déjà le transport Streamable HTTP, pourquoi un autre standard ? L'écosystème WebMCP est en early-preview à avril 2026, mais la raison d'exister va au-delà de l'immaturité. La réponse technique est que le navigateur est un environnement radicalement différent d'un serveur. Dans le navigateur :

• L'authentification est gérée par l'utilisateur, pas par l'agent (le cookie de session vit dans le navigateur, il ne voyage pas avec l'agent).
• Les actions doivent être visibles et supervisables par l'humain (il n'y a pas de place pour des automatisations opaques).
• La surface exposée est celle du site web visité, pas un endpoint dédié.
• La découvrabilité se produit quand l'utilisateur navigue vers la page, pas à travers un registre global.

WebMCP résout exactement ces différences. Selon la documentation officielle de Cloudflare Browser Run sur WebMCP, le site web expose un ensemble de tools — par exemple searchFlights() ou bookTicket() — avec des paramètres typés. Un agent qui navigue sur la page peut découvrir ces tools, lire leurs schémas et les appeler directement sans simuler des clics ni faire du scraping du DOM.

Implémentation : Cloudflare et Vercel

Les deux fournisseurs qui ont bougé le plus rapidement sont Cloudflare et Vercel, bien qu'avec des approches différentes.

• Cloudflare a ajouté le support WebMCP à son produit Browser Run (anciennement Browser Rendering) le 15 avril 2026, selon son changelog officiel. L'intégration permet qu'un agent IA connecte son client MCP contre Browser Run via l'endpoint CDP et découvre des tools exposées par n'importe quel site qui implémente WebMCP — même quand ce site ne contrôle pas l'infrastructure.
• Vercel a orienté son produit vers le déploiement de serveurs MCP sur sa plateforme Functions, en profitant de Fluid Compute pour optimiser des patterns d'usage irréguliers typiques des agents. La documentation officielle de Vercel MCP décrit comment monter des endpoints Streamable HTTP avec OAuth built-in, et son AI SDK inclut un client MCP expérimental. Bien que Vercel soit plus MCP classique que WebMCP pur, c'est le fournisseur de référence quand votre backend vit déjà sur Next.js.

Cas d'usage optimaux

WebMCP est la bonne réponse quand votre produit est un site web public et que vous voulez que les agents IA l'utilisent bien : e-commerce (recherche, filtres, panier, checkout), SaaS avec formulaires complexes (configurateurs, devis), marketplaces, systèmes de réservation. Tout cas où un utilisateur humain utiliserait des boutons et des formulaires et où vous voulez qu'un agent fasse de même avec moins de friction.

État d'adoption à avril 2026

Ici il faut être honnête : WebMCP est émergent, pas mature. Chrome le supporte de manière expérimentale sur Canary, Cloudflare a une production partielle, et la couverture d'AB Magency sur la « guerre des formats agentic » rapporte que WebMCP concurrence simultanément des propositions comme Markdown for Agents de Cloudflare (lancé le 12 février 2026). Les deux coexistent ; aucune n'a gagné. Pour une équipe qui doit décider aujourd'hui, WebMCP est un pari d'avenir raisonnable pour des sites avec trafic agent prévisible, mais ce n'est pas un standard sur lequel parier toute l'architecture.

A2A — Agent-to-Agent protocol (2026)

Si MCP connecte un agent avec ses outils, A2A connecte les agents entre eux et, à avril 2026, est le standard horizontal de référence. C'est la différence entre « un travailleur utilise ses outils » et « un travailleur délègue une tâche à un autre travailleur ». Ce n'est pas une distinction académique : cela résout des problèmes réels que MCP ne peut pas résoudre.

Origine et état actuel

A2A a été annoncé par Google à Google Cloud Next 2025 le 9 avril 2025, avec plus de 50 partenaires de lancement (Accenture, Atlassian, Box, Cohere, Deloitte, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UiPath, entre autres). En juin 2025 Google l'a donné à la Linux Foundation. En mars 2026 a été publiée A2A v1.0, la version que la communauté considère apte pour la production. La documentation officielle sur a2a-protocol.org décrit le modèle en détail ; l'annonce de mise à niveau du Google Cloud Blog documente les améliorations de la v1.0.

Architecture : Agent Cards et découverte

Le concept central d'A2A est l'Agent Card : un document JSON qui décrit ce qu'un agent sait faire, quelles skills il expose, quelle authentification il requiert et où le contacter. Les agents se découvrent en lisant les Agent Cards d'autres agents, comme les services web se découvrent par OpenAPI. En v1.0 les Agent Cards portent une signature cryptographique (Signed Agent Cards), ce qui permet de vérifier qu'une card a été émise par le domaine propriétaire de l'agent — une amélioration importante contre l'usurpation.

Le transport est JSON-RPC 2.0 sur HTTP, Server-Sent Events, ou gRPC, avec authentification via API keys, HTTP auth, OAuth 2.0/OIDC et mutual TLS. C'est-à-dire : les mêmes pièces que tout backend d'entreprise utilise depuis une décennie, sans rien réinventer.

Cas d'usage optimaux

A2A est la bonne réponse quand il y a plusieurs agents spécialisés qui doivent collaborer : un agent orchestrateur qui délègue « chercher un vol » à un agent voyages, « réserver un hôtel » à un agent hôtels, et « payer » à un agent de paiement. Chaque agent spécialisé a ses propres outils (MCP en interne) et offre son Agent Card à l'extérieur pour être orchestré. Scénarios typiques : purchasing concierges multi-fournisseurs, workflows multi-départements dans les grandes entreprises, marketplaces d'agents.

Différence fondamentale avec MCP

La clé, bien résumée par IBM dans son article sur A2A, est que MCP est vertical (agent↔tool) et A2A est horizontal (agent↔agent). Les deux sont complémentaires. Un agent A2A peut utiliser MCP en interne pour accéder à ses données. Un agent MCP peut ne jamais avoir besoin d'A2A s'il est un seul agent. La décision n'est pas « MCP ou A2A » ; c'est « j'ai besoin de l'un, de l'autre, ou des deux ».

Limitations et maturité

A2A v1.0 est récent. Bien qu'il y ait des déploiements de production chez Microsoft, AWS, Salesforce, SAP et ServiceNow selon la couverture de Stellagent, l'écosystème d'agents interopérables est encore petit comparé à celui des outils MCP. Construire avec A2A aujourd'hui implique construire beaucoup des pièces que MCP a déjà matures : librairies, gateways, debuggers, observabilité. Si votre problème est « un agent avec beaucoup de tools », A2A ajoute de la complexité sans rien résoudre de nouveau.

Tableau comparatif : MCP vs WebMCP vs A2A

Le tableau est dense à dessein. Si nous devions le résumer en une phrase : MCP commande à l'intérieur de l'agent, A2A commande entre les agents, WebMCP commande dans le navigateur. Toute décision architecturale commence par identifier où vous êtes et travailler à partir de là.

Exemple réel 1 : le PA de Kiwop utilise MCP stdio

Notre PA (Personal Assistant) — l'assistant personnel IA que nous avons construit chez Kiwop après la coupure OAuth d'Anthropic du 4 avril 2026, documenté en détail dans d'OpenClaw à PA avec Claude Code et MCP — est un cas d'école de l'usage optimal de MCP stdio.

L'architecture en une phrase

Claude Code tourne sur une machine locale (macOS, avec launchd comme gestionnaire de processus). Il a besoin d'accès à Gmail, Google Calendar, Google Drive et Slack. Pour chacun de ces quatre services, nous avons un serveur MCP local démarré comme sous-processus de la session. Le client MCP intégré dans Claude Code lance les serveurs par stdio, découvre leurs tools, et les invoque quand nécessaire.

Pourquoi stdio et pas Streamable HTTP

La tentation était de déployer les serveurs MCP sur un endpoint HTTP et que Claude Code s'y connecte par réseau. Nous l'avons écarté pour trois raisons :

1. Credentials : les OAuth tokens de Gmail, Calendar, Drive et Slack vivent dans le Keychain de macOS. Exposer ces tokens par réseau impliquerait du tunneling, de la rotation, et un modèle de secrets que nous ne voulions pas.
2. Latence : stdio est processus local avec pipe UNIX. Chaque invocation est submilliseconde. Un endpoint HTTP ajoute du temps de réseau sans gain fonctionnel.
3. Simplicité opérationnelle : le jour où quelque chose se casse, inspecter un processus local est infiniment plus facile que déboguer un service distant.

La décision cadre avec la logique générale que nous décrivons dans LLMOps : gérer les modèles de langage en production — garder près ce qui peut être près réduit la surface de défaillance. C'est la philosophie que nous allons aussi refléter dans le prochain post sur patrons et antipatrons d'agents IA en production.

Ce que nous N'AVONS PAS touché

Ni WebMCP ni A2A. Le PA est un seul agent (Claude Code) avec beaucoup d'outils, opéré par une seule personne. Introduire A2A serait de la sur-ingénierie pure : il n'y a aucun autre agent avec qui se coordonner. Introduire WebMCP ne s'applique pas : il n'y a pas de navigateur entre les deux, et les services MCP couvrent déjà tout ce dont nous avons besoin.

C'est important : un bon design est tout aussi précieux par ce qu'il laisse dehors que par ce qu'il inclut. Chaque protocole ajouté est du code à maintenir, une surface d'attaque, et une dépendance aux politiques du fournisseur.

Exemple réel 2 : Nexo (notre SaaS) planifie WebMCP pour les clients

Nexo est le SaaS interne que nous construisons chez Kiwop — un workspace collaboratif avec des capacités d'agents intégrés. Sans entrer dans les détails du produit (il sera lancé officiellement plus tard), nous pouvons raconter la décision architecturale sur les protocoles, parce qu'elle illustre parfaitement le dilemme auquel feront face la majorité des SaaS dans les 12-18 prochains mois.

Le problème : des clients qui veulent connecter leurs propres agents

Les clients beta nous demandaient deux choses très différentes :

1. « Nous voulons que nos propres agents (Claude, GPT, agents internes du client) accèdent aux données de leur workspace dans Nexo. »
2. « Nous voulons que vos agents internes dans Nexo puissent collaborer avec les agents que mon entreprise a déjà. »

Ce sont deux problèmes de protocoles complètement différents.

Décision : WebMCP (et MCP distant) pour le premier, A2A pour le second

Pour le premier problème (clients connectant des agents externes à leurs données dans Nexo) nous avons décidé d'exposer un serveur MCP Streamable HTTP par tenant et, en parallèle, de préparer des endpoints WebMCP pour que lorsque les utilisateurs naviguent dans l'UI de Nexo depuis un navigateur avec agent, cet agent puisse découvrir les actions disponibles sans scraper le DOM. Les tools exposées sont les mêmes dans les deux transports ; ce qui change c'est qui les consomme et comment elles s'authentifient. Cela cadre avec ce que nous recommandons déjà aux clients dans notre service d'intégration de LLMs.

Pour le second problème (orchestration d'agents de client avec nos agents) nous parions sur A2A. Nous publierons des Agent Cards signées pour chaque capability interne (classify-document, summarize-meeting, draft-email), le client pourra les découvrir depuis son agent orchestrateur, et le trafic sera JSON-RPC sur HTTP avec OAuth 2.0. L'avantage clé d'A2A face à « je fais une autre API REST » est que le client n'a pas à apprendre notre API : son agent découvre, lit la card, et opère.

Ce que nous n'avons PAS choisi et pourquoi

Nous avons écarté tout monter sur MCP pur bien que ce soit techniquement possible. La raison est que MCP est optimisé pour agent↔tool : si un client veut déléguer à Nexo avec un agent propre et obtenir des résultats complexes (multi-step, avec états intermédiaires, avec raisonnements exposés), A2A cadre mieux. MCP n'est pas pensé pour des conversations agent↔agent avec mémoire partagée.

Nous avons aussi écarté commencer avec A2A pour tout, puisque pour le cas « client qui veut lire/écrire des données de son workspace avec Claude » un serveur MCP est la voie courte et standard, avec le plus grand écosystème de clients derrière.

La leçon plus large, pour tout SaaS qui pense à comment s'ouvrir aux agents : ce n'est pas une décision binaire, c'est une décision par cas d'usage. Exposer des données à un unique agent client → MCP distant. Exposer un site web public aux agents qui le visitent → WebMCP. Interopérer avec des agents de clients comme égaux → A2A.

Quand NE PAS utiliser MCP (ni WebMCP ni A2A)

Un chapitre qui manque dans beaucoup d'articles. Les protocoles d'agents sont très bons pour leur domaine et très mauvais en dehors. Certains signes que vous ne devriez pas mettre MCP, WebMCP ni A2A dans votre architecture :

• Latence extrême. Si l'opération requiert une réponse submilliseconde (trading haute fréquence, contrôle industriel, jeux vidéo), la surcharge de JSON-RPC, le handshake, la description des tools et le round-trip du modèle tuent n'importe quel protocole d'agents. Utilisez des API binaires spécifiques.
• Streams binaires massifs. Transcodage vidéo, traitement d'images en volume, streaming audio en temps réel. MCP peut invoquer le job, mais ce n'est pas le canal par lequel voyagent les bytes. Conservez vos pipelines spécifiques.
• Processus batch longs sans agent. Si votre cas est « cron job traite un CSV toutes les nuits », un agent IA avec MCP est de l'artillerie contre des moineaux. Un script et un scheduler restent la bonne réponse.
• Déterminisme strict. Opérations bancaires, transactions critiques, logs d'audit. Un agent avec des tools peut rester dans la boucle, mais le moteur transactionnel doit être déterministe, avec des réessais documentés et sans marge pour « le modèle a choisi une autre tool ».
• Compliance régulé avec audit exhaustif. Si chaque appel doit laisser une trace légalement reproductible, vous avez besoin d'une couche sous les protocoles d'agents — non pas au-dessus — qui garantisse cet enregistrement. Cela peut se faire, mais ajouter un agent IA ne simplifie pas le compliance ; cela le complique.

Associé : dans les secteurs régulés (santé, juridique, financier), toute architecture d'agents IA requiert de passer par une phase de conseil en intelligence artificielle pour comprendre ce qui est permis avant de choisir un protocole. Choisir un protocole sans passer par là est l'antipatron classique.

Interopérabilité : pouvez-vous combiner les trois ?

Oui, et de fait il est probable que vous le fassiez. Le pattern le plus propre en avril 2026 combine les trois protocoles dans un stack cohérent.

Le diagramme conceptuel :

1. Un agent orchestrateur (niveau le plus haut, parle A2A vers l'extérieur).
2. Quand il a besoin d'utiliser un outil interne (lire une base de données, appeler une API d'entreprise) → MCP.
3. Quand il a besoin de déléguer une sous-tâche complexe à un autre agent spécialisé → A2A vers cet agent.
4. Quand il a besoin d'agir sur un site web externe qui n'expose pas d'API propre mais oui WebMCP → client WebMCP via navigateur.

L'agent récepteur en A2A, à son tour, utilise MCP en interne pour ses propres tools. Et si l'agent récepteur est un SaaS public avec frontend, il exposera probablement aussi une surface WebMCP pour les utilisateurs humains avec agents. Le système est récursif et composable : chaque agent est un client des trois protocoles et (potentiellement) un serveur de deux (MCP et A2A).

Cette composition est précisément ce que décrivent des sources comme la carte de protocoles de Digital Applied ou le guide de WorkOS sur MCP/ACP/A2A : les protocoles ne concurrencent pas parce qu'ils résolvent des couches différentes. Ils concurrencent leurs alternatives sur la même couche (WebMCP vs Markdown for Agents ; A2A vs ACP), pas entre eux.

Une nuance : évitez la sur-orchestration

Avant de mettre les trois protocoles dans un système, demandez-vous si vous en avez besoin. La majorité des applications IA en production aujourd'hui ont besoin seulement de MCP. Une minorité importante a besoin de MCP + WebMCP (SaaS avec frontend public). Une minorité petite mais croissante a besoin de MCP + A2A (écosystèmes multi-agents). Le cas triple est réel mais rare. Si vous ne pouvez pas justifier pourquoi chaque couche résout un problème différent, il y en a probablement une de trop.

Tableau : quand utiliser chacun

Tableau : maturité d'adoption à avril 2026

Roadmap et adoption en 2026

Ce qui est à chaque étape selon des sources officielles au 19 avril 2026 :

• MCP : spécification stable du 25 novembre 2025 avec opérations asynchrones et servers stateless ; prochain jalon pertinent, le MCP Dev Summit Europe annoncé pour les 17-18 septembre 2026 à Amsterdam. Signaux à observer : consolidation du transport Streamable HTTP comme default distant, retrait progressif du SSE legacy, standardisation de patterns de sécurité pour tool poisoning.
• A2A : v1.0 publiée en mars 2026 avec Signed Agent Cards et extension formelle AP2. Signaux à observer : croissance du registre public d'Agent Cards, apparition de gateways A2A (équivalents aux API gateways traditionnels), intégration native avec les grands orchestrateurs (LangGraph, CrewAI, AutoGen).
• WebMCP : programme early preview ouvert, implémentation partielle chez Cloudflare, support limité sur Chrome Canary. Signaux à observer : acceptation du brouillon au W3C, décision de Chromium Stable sur le support par défaut, positionnement définitif face à Markdown for Agents.
• Standards adjacents : AGENTS.md (proposé par OpenAI, sous AAIF), Open Responses (spécification ouverte d'OpenAI pour loops agents interopérables, rapportée par InfoQ en février 2026), et Skills (contribués par Block/Anthropic). Aucun ne concurrence MCP/WebMCP/A2A directement, mais ils résolvent des pièces complémentaires : description de repos, interopérabilité de loops, bundling de prompts.

La prédiction la moins risquée pour les 6-12 prochains mois est que MCP se consolide comme commodity, A2A atteigne sa première grande vague de déploiements B2B, et WebMCP reste un terrain en dispute jusqu'à ce que Chrome Stable décide de le supporter ou non. Dans le cas de décider de ne pas le supporter, la proposition peut mourir ou migrer vers une solution alternative (Markdown for Agents ou une autre).

Questions fréquentes

MCP est-il uniquement d'Anthropic ?

Non depuis décembre 2025. Anthropic a donné MCP à l'Agentic AI Foundation récemment créée sous la Linux Foundation, avec Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare et Bloomberg comme membres platine. Aujourd'hui MCP a une gouvernance communautaire. Anthropic continue de contribuer fortement au développement mais n'est plus le seul décideur.

WebMCP remplace-t-il mon API REST ?

Non. WebMCP expose une surface pensée pour les agents qui opèrent depuis des navigateurs. Votre API REST reste la voie correcte pour les intégrations backend-backend, apps mobiles, et clients authentifiés avec des credentials propres. WebMCP ajoute une couche orientée vers l'agent de l'utilisateur, il ne la remplace pas.

A2A est-il prêt pour la production à avril 2026 ?

Oui pour les cas standard. La v1.0 publiée en mars 2026 inclut les Signed Agent Cards et est considérée apte pour la production. Il y a des déploiements chez Microsoft, AWS, Salesforce, SAP et ServiceNow. Cependant, l'écosystème de librairies et tooling est moins mature que celui de MCP — attendez-vous à consacrer plus d'ingénierie propre à des gateways, observabilité et gestion d'Agent Cards.

Quel SDK utiliser pour démarrer avec MCP ?

Les SDKs officiels en Python et TypeScript couvrent la majorité des cas. Pour construire des serveurs dans l'écosystème Anthropic, le SDK TypeScript officiel est la voie recommandée. Pour le scripting et les serveurs locaux, le SDK Python est le standard. Les deux sont maintenus par Anthropic avec support officiel.

Puis-je utiliser MCP avec des modèles qui ne sont pas d'Anthropic ?

Oui. Depuis mars 2025, ChatGPT supporte MCP nativement ; Copilot et Gemini aussi. Les serveurs MCP sont agnostiques au modèle : n'importe quel client qui parle le protocole peut les consommer. C'est la raison principale pour laquelle MCP a gagné — la portabilité entre fournisseurs est réelle, pas du marketing.

WebMCP, c'est la même chose que Markdown for Agents de Cloudflare ?

Non. Ce sont deux propositions concurrentes avec des philosophies différentes. WebMCP expose des actions typées que l'agent invoque ; Markdown for Agents expose une représentation markdown structurée du site pour que l'agent l'interprète. À avril 2026 les deux coexistent et aucune n'a gagné. Si vous voulez couvrir les deux flancs, Cloudflare documente comment implémenter un support parallèle.

Quelle est la différence réelle entre A2A et ACP ?

Conceptuellement ils résolvent le même problème : communication horizontale entre agents. A2A est porté par Google et a beaucoup plus de traction (150+ organisations, Linux Foundation, v1.0 production). ACP est porté par IBM (BeeAI) avec une adoption plus limitée. Techniquement ACP utilise des conventions HTTP plus directes ; A2A utilise JSON-RPC avec Agent Cards signées. Si vous commencez de zéro aujourd'hui, A2A a un meilleur rapport valeur/risque par écosystème.

Ai-je besoin des trois protocoles dans mon projet ?

Presque jamais. La majorité des projets IA commencent avec seulement MCP. Un SaaS avec frontend public ajoute WebMCP quand le trafic agent justifie l'investissement. Un écosystème avec plusieurs agents interopérant ajoute A2A. L'erreur courante est de mettre les trois dès le jour un sans cas métier clair ; le pattern sain est de commencer avec MCP et d'ajouter le reste seulement quand il y a un vrai problème à résoudre.

Conclusion : choisir par couche, pas par marque

La question correcte en 2026 n'est pas « quel protocole est le meilleur ? » mais « quelle couche est-ce que je résous ? ». MCP commande à l'intérieur de l'agent, dans le lien agent↔tool. A2A commande entre agents, dans le lien horizontal. WebMCP commande à la frontière entre votre web public et les agents qui la visitent. Ce sont trois couches différentes ; ils ne concurrencent pas, ils se composent.

La leçon opérationnelle, après avoir construit le PA sur MCP stdio et conçu Nexo sur MCP distant + A2A + WebMCP, est que le coût de mal choisir un protocole est énorme. Chaque protocole apporte avec lui un modèle mental, un ensemble de librairies, une courbe d'adoption de clients et un engagement de maintenance à long terme. Mais il est aussi vrai — et c'est peut-être le plus important — que la portabilité entre couches n'a jamais été aussi grande. Un serveur MCP bien conçu se consomme depuis Claude, ChatGPT, Copilot, Gemini et Cursor sans changements. Un agent A2A bien conçu est visible depuis n'importe quel orchestrateur qui parle le protocole. Un site avec WebMCP répond à n'importe quel agent qui le visite. L'investissement dans des protocoles ouverts s'amortit rapidement.

Chez Kiwop — Agence Digitale spécialisée en Développement Logiciel et Intelligence Artificielle appliquée pour clients mondiaux en Europe et aux États-Unis — nous construisons depuis deux ans sur des LLMs en production et depuis début 2025 sur MCP. Si votre équipe décide aujourd'hui comment ouvrir votre plateforme aux agents IA ou comment orchestrer un système multi-agents, nous pouvons vous aider à choisir la bonne architecture sans sur-ingénierie. Jetez un œil à nos services de développement d'agents IA, conseil en intelligence artificielle et intégration de LLMs — ou écrivez-nous et nous nous asseyons.

Et si le parcours technique vous a intéressé, suivez le fil avec les autres posts du cluster : d'OpenClaw à PA avec Claude Code et MCP, construisez votre PA avec Claude Code et MCP, agents IA en production : patrons et antipatrons 2026 et WebMCP : votre site web préparé pour les agents IA.