La guerre des protocoles : MCP, A2A et l'avenir de l'interopérabilité

De l'ère des copilotes à l'ère des agents : un changement de paradigme

Pendant plusieurs années, l'outillage IA pour les développeurs s'est construit autour d'une métaphore centrale : le copilote. Un assistant intelligent, assis à vos côtés, capable de suggérer la prochaine ligne de code, de compléter une fonction, d'accélérer les tâches répétitives. Utile, certes. Mais fondamentalement passif.

Le tournant de 2025 a tout changé. Avec l'émergence d'outils comme Claude Code — lancé en février 2025 — puis OpenAI Codex CLI, Gemini CLI ou encore les premières tentatives de Mistral dans cet espace, nous sommes entrés dans une nouvelle ère : celle de l'IA agentique. Ces systèmes n'attendent plus votre prochaine frappe au clavier. Ils agissent, planifient, exécutent, itèrent. Le développeur humain ne disparaît pas — il change de rôle, passant de rédacteur syntaxique à architecte d'intention et superviseur de qualité.

Mais cette mutation soulève immédiatement une question que beaucoup sous-estiment encore : si les agents peuvent agir de façon autonome, comment communiquent-ils entre eux ? Comment un agent de développement sait-il interroger un agent de supervision qualité ? Comment un orchestrateur métier pilote-t-il une constellation d'agents spécialisés sans que chaque intégration devienne un projet à part entière ?

C'est ici que s'ouvre la guerre des protocoles. Et ses enjeux dépassent largement la sphère technique.

Le problème fondamental : l'interopérabilité à l'ère agentique

Imaginez un système distribué où chaque agent — qu'il soit spécialisé dans la recherche documentaire, l'analyse de données, l'exécution de code ou la communication avec des APIs tierces — parle son propre dialecte. C'est précisément la situation dans laquelle se trouvait l'écosystème de l'IA agentique jusqu'à très récemment.

Chaque framework — LangChain, CrewAI, AutoGen, LlamaIndex — proposait ses propres abstractions, ses propres conventions d'appel d'outils, ses propres mécanismes de passage de contexte. Résultat : des silos applicatifs, des intégrations fragiles, et une dette architecturale qui s'accumulait à mesure que les cas d'usage se complexifiaient.

Le problème se décompose en réalité en deux niveaux distincts :

• Comment un agent interagit-il avec des outils et des sources de données externes ? C'est la question de la connectivité verticale, entre un agent et ses ressources.
• Comment plusieurs agents collaborent-ils entre eux pour accomplir une tâche complexe ? C'est la question de la collaboration horizontale, au sein d'un réseau d'agents.

Ces deux problèmes appellent des solutions différentes. Et c'est précisément ce que tentent de résoudre — chacun à leur manière — le Model Context Protocol (MCP) et le protocole Agent-to-Agent (A2A).

MCP : standardiser le dialogue entre agents et outils

Introduit par Anthropic fin 2024, le Model Context Protocol répond à la première grande question : comment un modèle de langage peut-il interagir de façon standardisée avec n'importe quel outil, API ou source de données ?

La métaphore la plus juste est celle de l'USB. Avant l'USB, chaque périphérique nécessitait son propre connecteur, ses propres drivers, sa propre logique d'installation. L'USB a créé un contrat universel entre les périphériques et les hôtes. MCP ambitionne de jouer ce rôle dans l'écosystème agentique.

Concrètement, MCP définit une architecture client-serveur où :

• Un serveur MCP expose des capacités — outils exécutables, ressources consultables, prompts préconfigurés — via une interface standardisée.
• Un client MCP (typiquement un agent ou un LLM orchestrateur) peut découvrir ces capacités dynamiquement et les invoquer sans connaissance préalable de l'implémentation sous-jacente.
• Le tout repose sur un protocole de communication léger, basé sur JSON-RPC, qui peut transiter aussi bien via stdio que via HTTP avec Server-Sent Events.

Ce qui rend MCP puissant, c'est son adoption rapide. En quelques mois, l'écosystème a vu émerger des centaines de serveurs MCP open source couvrant des cas d'usage aussi variés que l'accès à des bases de données PostgreSQL, l'interaction avec GitHub, la consultation de Slack, l'exécution de requêtes sur des APIs REST arbitraires, ou encore la manipulation de systèmes de fichiers locaux.

Pour les équipes de développement que nous accompagnons chez SFEIR, MCP représente un changement architectural majeur. Là où il fallait auparavant écrire du code d'intégration spécifique pour chaque combinaison d'agent et d'outil, il devient possible de construire une bibliothèque de serveurs MCP réutilisables, déployables et maintenables indépendamment des agents qui les consomment. La séparation des préoccupations entre la logique agentique et l'accès aux ressources est enfin une réalité pratique.

Les limites de MCP : quand les agents doivent parler entre eux

MCP résout élégamment la connectivité verticale. Mais il ne traite pas la question de la collaboration entre agents. Comment un agent orchestrateur délègue-t-il une sous-tâche à un agent spécialisé ? Comment un agent distant peut-il signaler sa progression, retourner des résultats partiels, ou négocier les paramètres d'une tâche ?

MCP n'a pas été conçu pour ça. Il manque de primitives pour la gestion du cycle de vie des tâches longues, pour la négociation de capacités entre pairs, pour la sécurité des échanges inter-agents dans un contexte multi-organisationnel. C'est le territoire d'A2A.

A2A : le protocole de la collaboration entre agents

Lancé par Google en avril 2025, le protocole Agent-to-Agent (A2A) s'attaque directement à la coordination horizontale entre agents. Sa prémisse de départ est simple mais structurante : dans un monde où les systèmes agentiques sont distribués, polyvalents et potentiellement déployés par des organisations différentes, les agents ont besoin d'un langage commun pour se trouver, se comprendre et collaborer.

A2A introduit plusieurs concepts fondamentaux :

• L'Agent Card : une carte d'identité standardisée (format JSON, exposée via HTTP) que chaque agent publie pour décrire ses capacités, ses modes d'interaction supportés, ses exigences d'authentification et ses modalités de communication. C'est le mécanisme de découverte du protocole.
• Les Tasks : une unité de travail structurée avec un cycle de vie défini — soumission, exécution, progression, complétion ou échec. A2A gère nativement les tâches longues via du streaming (Server-Sent Events) et un mécanisme de polling.
• Les Artifacts : les sorties produites par une tâche, qu'il s'agisse de texte, de fichiers, de données structurées ou de flux continus.
• La sécurité by design : A2A s'appuie sur les standards existants (OAuth 2.0, OpenID Connect) pour l'authentification et l'autorisation inter-agents, une considération critique dès lors qu'on envisage des collaborations cross-organisationnelles.

Là où MCP pense en termes d'outils et de ressources, A2A pense en termes de délégation et de collaboration. Un agent A2A ne se contente pas d'appeler une fonction ; il confie une mission à un autre agent, suit sa progression, et intègre ses résultats dans son propre raisonnement.

MCP et A2A : complémentaires, pas concurrents

Il serait tentant — et réducteur — d'opposer MCP et A2A comme deux protocoles en guerre pour la domination de l'écosystème. La réalité est plus nuancée et, finalement, plus encourageante : ces deux protocoles adressent des couches différentes de l'architecture agentique et sont fondamentalement complémentaires.

Un agent qui implémente A2A pour collaborer avec ses pairs peut parfaitement utiliser MCP pour accéder aux outils et données dont il a besoin pour accomplir sa mission. Dans une architecture bien conçue, MCP opère au niveau de l'accès aux ressources, A2A au niveau de la collaboration inter-agents. Les deux protocoles coexistent naturellement dans le même système.

C'est d'ailleurs la direction que prend l'industrie. Anthropic, Google, Microsoft, et un nombre croissant d'acteurs de l'écosystème ont rejoint des initiatives de standardisation qui visent à faire coexister ces protocoles dans un cadre cohérent plutôt qu'à les faire s'affronter.

L'Agentic Mesh : vers une infrastructure de collaboration distribuée

Si MCP et A2A sont les protocoles, l'Agentic Mesh est l'architecture qui les met en œuvre à l'échelle de l'entreprise. Le terme, encore émergent, désigne un réseau maillé d'agents autonomes capables de se découvrir mutuellement, de négocier des collaborations, et d'accomplir collectivement des missions complexes sans orchestration centralisée rigide.

L'analogie avec le Service Mesh du monde microservices est éclairante. Tout comme Istio ou Linkerd ont permis de gérer la complexité des communications inter-services sans polluer le code applicatif, un Agentic Mesh vise à prendre en charge les préoccupations transversales de la collaboration agentique : découverte, routage, sécurité, observabilité, gestion des pannes.

Concrètement, un Agentic Mesh d'entreprise doit répondre à plusieurs défis architecturaux :

• Découverte dynamique : les agents doivent pouvoir trouver leurs pairs en fonction de leurs capacités déclarées, pas d'une configuration statique. Les Agent Cards d'A2A constituent le mécanisme naturel pour cela.
• Routage intelligent : dans un réseau de plusieurs dizaines ou centaines d'agents, comment l'orchestrateur sait-il à quel agent déléguer quelle sous-tâche ? Le routage sémantique basé sur les embeddings des descriptions de capacités est une piste prometteuse.
• Observabilité : tracer une exécution agentique distribuée est un défi de taille. Les standards d'observabilité existants (OpenTelemetry) doivent être étendus pour capturer la sémantique des interactions inter-agents.
• Résilience : quand un agent échoue au milieu d'une chaîne de collaboration, comment le système récupère-t-il ? Les mécanismes de retry, de fallback et de compensation doivent être pensés dès la conception.
• Gouvernance et contrôle : dans un Agentic Mesh, qui est responsable de quoi ? Comment audit-on les décisions prises par un réseau d'agents ? La traçabilité des raisonnements et des actions n'est pas une option dans un contexte entreprise.

Chez SFEIR, nous voyons dans l'Agentic Mesh l'une des grandes transformations architecturales de la prochaine décennie pour nos clients. Non pas une technologie à déployer clé en main, mais un paradigme architectural à construire progressivement, en partant des cas d'usage à forte valeur et en posant des fondations solides en matière de gouvernance et d'observabilité.

Les enjeux concrets pour les architectes et les équipes engineering

La guerre des protocoles n'est pas qu'un débat académique entre chercheurs et responsables de standards. Elle a des implications concrètes et immédiates pour les équipes engineering qui construisent des systèmes agentiques aujourd'hui.

Choisir ses abstractions avec soin

La tentation est grande de s'appuyer sur un framework agentique de haut niveau — LangGraph, AutoGen, CrewAI — et de laisser ce framework gérer les détails des protocoles. C'est une approche raisonnable pour les prototypes et les preuves de concept. Mais pour des systèmes en production, la question de la portabilité et de l'interopérabilité finit toujours par se poser.

Nos équipes recommandent une approche en couches : utiliser MCP comme couche d'accès aux outils (ce qui garantit la réutilisabilité des serveurs MCP quelle que soit l'évolution des frameworks), et concevoir les interfaces inter-agents dans l'esprit d'A2A dès le départ, même si l'implémentation complète du protocole n'est pas encore requise.

La sécurité n'est pas une afterthought

Un agent autonome qui peut appeler des outils et déléguer des tâches à d'autres agents est, par définition, un vecteur d'attaque potentiel. Les risques spécifiques à l'IA agentique — injection de prompt via des données externes, escalade de privilèges via un agent compromis, exfiltration de données via des chaînes d'agents malveillantes — sont des préoccupations nouvelles qui ne sont pas couvertes par les modèles de sécurité traditionnels.

MCP et A2A intègrent tous deux des mécanismes de sécurité. Mais ces mécanismes ne valent que si l'architecture globale les exploite correctement : principe du moindre privilège pour les serveurs MCP, validation stricte des Agent Cards, audit systématique des interactions inter-agents. C'est un domaine où l'expertise en architecture de sécurité, combinée à la compréhension des spécificités agentiques, devient un avantage compétitif réel.

L'observabilité comme prérequis

Dans un système agentique distribué, comprendre ce qui s'est passé après un incident n'est pas trivial. Un agent A peut avoir délégué une tâche à un agent B, qui a utilisé un outil MCP C, qui a appelé une API D, avant de retourner un résultat qui a influencé une décision de l'agent A. Reconstituer cette chaîne causale pour un débogage ou un audit nécessite une infrastructure d'observabilité pensée pour la complexité agentique.

L'extension d'OpenTelemetry aux traces agentiques est un chantier actif dans la communauté. Chez SFEIR, nous travaillons avec nos clients à instrumenter leurs systèmes agentiques dès leur conception, en capturant non seulement les métriques techniques classiques, mais aussi la sémantique des raisonnements et des décisions des agents.

L'impact organisationnel : quand les protocoles redéfinissent les rôles

Il serait réducteur de traiter MCP, A2A et l'Agentic Mesh comme de simples questions d'ingénierie. Ces protocoles, en rendant possible une collaboration fluide entre agents autonomes, créent les conditions d'une transformation profonde des organisations et des métiers.

Comme le souligne le rapport Tech Trends 2026 de SFEIR, "nous vivons une rupture opérationnelle". Le passage du copilote à l'agent ne fait pas que changer les outils — il reconfigure les chaînes de valeur. Dans le développement logiciel, l'exemple de Claude Code est emblématique : les équipes techniques ne passent plus l'essentiel de leur temps à rédiger du code syntaxique, mais à définir des intentions, à superviser des exécutions et à valider des sorties. La productivité n'est plus incrémentale ; elle est systémique.

Cette transformation touche bien au-delà du développement. Imaginez un Agentic Mesh pour la gestion de la relation client : un agent de première ligne traite les demandes entrantes, délègue automatiquement les cas complexes à des agents spécialisés (facturation, support technique, conformité), orchestre les retours vers le client, et escalade vers un humain uniquement quand la situation le requiert. Les protocoles MCP et A2A sont les rouages invisibles qui rendent ce ballet possible.

Pour les DSI et les architectes d'entreprise, cela signifie repenser le SI non plus comme un ensemble d'applications intégrées, mais comme un réseau d'agents collaboratifs dont les protocoles d'interopérabilité sont aussi critiques que les protocoles réseau l'étaient dans les années 90. Investir aujourd'hui dans la maîtrise de MCP et A2A, c'est construire les fondations du SI de demain.

La perspective SFEIR : accompagner la transition vers l'interopérabilité agentique

Chez SFEIR, nous avons fait le choix d'investir massivement dans la compréhension pratique de ces protocoles, au-delà des annonces marketing et des démos impressionnantes. Nos équipes de Staff Engineers et d'Architectes IA travaillent avec des clients de secteurs variés pour construire des systèmes agentiques robustes, interopérables et gouvernés.

Notre approche se structure autour de trois axes :

• L'audit architectural : nous aidons nos clients à cartographier leurs systèmes agentiques existants et émergents, à identifier les silos d'interopérabilité et à définir une feuille de route vers une architecture Agentic Mesh cohérente. Cela commence souvent par une question simple mais structurante : quels sont vos agents aujourd'hui, et comment communiquent-ils réellement entre eux ?
• La mise en œuvre pragmatique : nous construisons avec nos clients des serveurs MCP pour leurs outils métier critiques, nous accompagnons l'adoption d'A2A pour les cas d'usage de collaboration inter-agents à fort enjeu, et nous posons les bases d'une gouvernance agentique (registre d'agents, politiques d'accès, traçabilité).
• La montée en compétences : la transformation agentique ne se fera pas sans les équipes. Nos programmes de formation et nos missions d'embedded expertise visent à faire monter en compétences les développeurs, les architectes et les product managers sur les spécificités du développement agentique — de la conception des Agent Cards à la gestion des prompts adversariaux.

Ce qui nous frappe, dans nos missions actuelles, c'est la vitesse à laquelle les questions d'interopérabilité remontent dans les priorités de nos clients. Il y a dix-huit mois, les discussions portaient sur les premiers RAG et les premiers chatbots. Aujourd'hui, les DSI nous parlent d'orchestration multi-agents, de gouvernance de réseaux agentiques, de sécurité des flux inter-agents. La maturité des organisations progresse rapidement, et les enjeux d'interopérabilité sont au cœur de cette montée en maturité.

Conclusion : choisir ses standards, c'est choisir son avenir

La guerre des protocoles est réelle, mais elle n'est pas nécessairement destructrice. Comme souvent dans l'histoire de l'informatique, la concurrence entre approches finit par accoucher de standards solides — et l'émergence parallèle de MCP et A2A, avec leurs périmètres complémentaires, ressemble davantage à une division du travail qu'à un affrontement.

Ce qui est en jeu, fondamentalement, c'est la capacité de l'industrie à construire des systèmes agentiques à l'échelle de l'entreprise : des systèmes qui ne soient pas des POC brillants mais fragiles, qui résistent à la réalité du SI complexe, qui se gouvernent et s'auditent, qui survivent à la rotation des équipes et à l'évolution des outils.

MCP donne aux agents les mains pour agir sur le monde. A2A leur donne la voix pour collaborer entre eux. L'Agentic Mesh leur donne le théâtre où cette collaboration peut s'épanouir à l'échelle. Ensemble, ces trois éléments constituent le socle technique de ce que le rapport Tech Trends 2026 appelle la "rupture opérationnelle" de l'IA agentique.

Pour les équipes engineering, le message est clair : le moment d'investir dans la maîtrise de ces protocoles, c'est maintenant. Non pas parce que tout est stabilisé — les spécifications évoluent encore, les implémentations mûrissent, les meilleures pratiques se construisent — mais précisément parce que se former et expérimenter pendant la phase de construction des standards, c'est se positionner pour en être les maîtres demain, plutôt que d'en subir les contraintes après coup.

L'avenir de l'interopérabilité agentique s'écrit aujourd'hui. Et il s'écrit en protocoles ouverts.