Roadmap MCP 2026 : Streamable HTTP, agent-to-agent, Registry et enterprise — Ce qui change et quand

Le 9 mars 2026, David Soria Parra, Lead Maintainer du MCP, a publié la roadmap officielle du protocole. Quatre priorités structurent le développement : l’évolution du transport Streamable HTTP pour le scaling horizontal, la communication agent-to-agent prévue au Q3 2026, l’authentification enterprise OAuth 2.1 au Q2, et le MCP Registry au Q4 — le futur « npm des agents IA ». Ce n’est pas une liste de fonctionnalités avec des dates de livraison : c’est une feuille de route stratégique pilotée par les Working Groups sous la gouvernance de la Linux Foundation. Cet article décrypte chaque priorité, son impact pratique pour les entreprises et ce que cela signifie pour votre stratégie IA dès maintenant.

D’où vient la roadmap MCP 2026 — processus, acteurs, gouvernance

La roadmap MCP 2026 n’est pas un document marketing. C’est le résultat de mois de travail des Core Maintainers, informé par l’expérience de production, les retours de la communauté et les points de friction récurrents dans les déploiements à grande échelle.

David Soria Parra et les Core Maintainers

David Soria Parra, Lead Maintainer du MCP, a publié la roadmap officielle le 9 mars 2026 sur le blog du protocole. Le document est explicite sur sa nature : les idées présentées ne sont pas des engagements. Certaines seront résolues différemment. D’autres ne se matérialiseront pas. C’est une déclaration de priorités stratégiques, pas un calendrier de releases. La dernière version formelle de la spécification date de novembre 2025 — aucune nouvelle version n’a été publiée depuis, mais le projet n’est pas resté immobile. Les Working Groups, les Spec Enhancement Proposals (SEPs) et le processus de gouvernance formalisé ont considérablement structuré le développement.

Working Groups, SEPs et le modèle open-source sous Linux Foundation

Le MCP opère désormais sous la gouvernance de l’Agentic AI Foundation (AAIF) au sein de la Linux Foundation. Les SEPs qui s’alignent sur les quatre priorités de la roadmap reçoivent un examen accéléré et ont les meilleures chances d’acceptation. Les SEPs en dehors de ces priorités ne sont pas automatiquement rejetés, mais les contributeurs doivent s’attendre à des délais plus longs et un seuil de justification plus élevé. La capacité des maintainers est finie — ils la dirigent vers ces priorités en premier. Pour une analyse de l’impact économique de ce modèle de gouvernance, notre article sur la macro-économie du MCP détaille les effets de réseau.

Priorité 1 — Transport et Scalability : Streamable HTTP 2.0

Le Streamable HTTP a permis au MCP de passer des processus locaux aux services distants en production. Mais le déploiement à grande échelle a révélé des lacunes structurelles que cette priorité vise à combler.

Le problème : sessions stateful vs load balancers

Le MCP supporte des sessions stateful. En production, les sessions stateful se battent avec les load balancers : le scaling horizontal nécessite des contournements, et il n’existe pas de moyen standard pour un registre ou un crawler de découvrir les capacités d’un serveur sans s’y connecter. Ces limitations freinent les déploiements enterprise à grande échelle.

La solution : stateless scaling + MCP Server Cards

Le travail se divise en deux parties. D’abord, faire évoluer le transport et le modèle de session pour que les serveurs puissent scaler horizontalement sans maintenir d’état, avec des mécanismes explicites de gestion de sessions. Ensuite, créer un format de métadonnées standard — les MCP Server Cards — servi via une URL .well-known, pour que les capacités d’un serveur soient découvrables sans connexion active. Point important : aucun nouveau transport officiel n’est prévu ce cycle. C’est une décision délibérée de stabiliser Streamable HTTP plutôt que de fragmenter l’écosystème avec des alternatives concurrentes.

Impact pratique pour les entreprises

Pour les entreprises qui déploient des serveurs MCP en production, cette évolution signifie des architectures plus simples : pas besoin de session stickiness sur les load balancers, des redémarrages de serveur transparents pour les clients connectés, et une découverte automatisée des serveurs via les Server Cards. Les SDK TypeScript (v1.27.1) et Python (v1.26) intègrent déjà les premiers éléments de cette évolution.

Priorité 2 — Agent-to-Agent (Q3 2026) : les agents qui parlent aux agents

La coordination agent-to-agent via MCP est l’une des évolutions les plus attendues. Elle permet de créer des architectures multi-agents où un agent orchestrateur délègue des tâches à des sous-agents spécialisés.

Architectures hiérarchiques : orchestrateur + sous-agents spécialisés

La vision est claire : un agent appelle un autre agent comme s’il était un serveur d’outils. L’agent orchestrateur identifie la tâche, la décompose en sous-tâches, et délègue chacune à un agent spécialisé via le protocole MCP. L’agent de recherche analyse les données, l’agent de rédaction produit le contenu, l’agent de validation vérifie la conformité — le tout coordonné par l’orchestrateur. C’est exactement ce que font déjà des frameworks comme LangGraph et CrewAI au niveau applicatif, mais le MCP le standardise au niveau protocole.

Différence avec A2A de Google

L’agent-to-agent MCP et le protocole A2A de Google ne sont pas redondants. Le MCP agent-to-agent crée une hiérarchie : un agent client appelle un agent serveur. L’A2A crée un réseau pair-à-pair : des agents se découvrent mutuellement via des Agent Cards et collaborent de manière décentralisée. Google ADK v2.0 a déjà introduit une Task API structurée pour la délégation agent-to-agent. Les deux protocoles convergent vers une complémentarité de fait, comme nous l’avons analysé dans notre article sur les agents IA autonomes en marketing.

Cas d’usage : audit de sécurité multi-agents, pipeline marketing orchestré

En cybersécurité, un agent orchestrateur pourrait coordonner un agent de scan réseau, un agent d’analyse de vulnérabilités et un agent de reporting pour produire un audit complet sans intervention humaine. En marketing, la pipeline que nous opérons chez HDVMA — recherche → rédaction → optimisation → publication → distribution — pourrait être décomposée en agents spécialisés qui se coordonnent via MCP, chacun expert dans sa tâche.

Priorité 3 — Enterprise Readiness : SSO, audit trails, gateways

Les entreprises déploient le MCP à grande échelle et se heurtent à des lacunes prévisibles. La roadmap les adresse directement avec trois axes de travail.

OAuth 2.1 avec PKCE (Q2 2026) — le déblocage pour les secteurs régulés

L’authentification enterprise est la fonctionnalité la plus attendue. OAuth 2.1 avec PKCE pour les agents browser-based et l’intégration SAML/OIDC avec les fournisseurs d’identité enterprise (Okta, Azure AD) débloquent les déploiements dans les secteurs régulés — santé, finance, juridique — qui exigent une authentification de grade enterprise. Le SDK TypeScript v1.27.1 a déjà ajouté des tests de conformité d’authentification et le backport de la découverte OAuth, signalant que l’implémentation avance concrètement.

Gateway patterns et propagation d’autorisation

La roadmap identifie trois questions ouvertes pour les gateways : que se passe-t-il avec l’état de session quand une gateway est intercalée ? Que peut inspecter la gateway (arguments d’appels d’outils, contenu) ? Comment propager l’autorisation à travers la chaîne ? Sans réponse au niveau de la spécification, chaque entreprise invente ses propres comportements de gateway, créant de la fragmentation et des hypothèses de sécurité qui ne tiennent pas quand les composants sont échangés. Ces questions concernent directement les architectures décrites dans notre guide sur la sécurité MCP.

Configuration portability : configurer une fois, déployer partout

La portabilité de configuration vise un objectif pragmatique : configurer un serveur MCP une fois et que cette configuration fonctionne sur tous les clients MCP. Aujourd’hui, chaque application hôte (Claude Desktop, Cursor, VS Code) maintient son propre registre de serveurs connus avec des formats de configuration différents. La standardisation de ce format éliminera une friction majeure dans les déploiements multi-outils.

Priorité 4 — Governance et Contributor Ladder

Le modèle de gouvernance du MCP doit évoluer pour ne plus dépendre d’un petit nombre d’individus. La roadmap prévoit deux évolutions structurelles.

Le chemin de community participant à core maintainer

Le Contributor Ladder SEP définira la progression depuis participant communautaire vers contributeur Working Group, puis facilitateur, lead maintainer et core maintainer, avec des critères explicites de nomination et d’évaluation à chaque étape. Ce modèle, inspiré des meilleures pratiques des projets Linux Foundation comme Kubernetes, garantit la pérennité du projet au-delà de ses fondateurs initiaux.

Délégation aux Working Groups — la fin du bottleneck

Aujourd’hui, chaque SEP nécessite un examen complet des Core Maintainers, quel que soit le domaine. C’est un goulot d’étranglement. Le modèle de délégation permettra aux Working Groups ayant fait leurs preuves d’accepter des SEPs dans leur domaine sans attendre un cycle de review complète. Les Core Maintainers conservent la supervision stratégique, les Working Groups gagnent en autonomie. Chaque Working Group et Interest Group maintiendra publiquement une charte trimestrielle : périmètre, livrables actifs, critères de succès et conditions de retrait.

MCP Registry (Q4 2026) et ce que cela signifie pour votre stratégie IA

Le MCP Registry, prévu pour le Q4 2026, représente le « npm des agents IA » : un répertoire vérifié de serveurs MCP avec audits de sécurité, statistiques d’utilisation et engagements SLA.

Ce Registry changera fondamentalement la manière dont les entreprises évaluent et déploient les serveurs MCP. Au lieu de naviguer dans des répertoires communautaires non vérifiés, les équipes enterprise pourront évaluer les serveurs contre des critères de sécurité standardisés avant le déploiement. Les serveurs vérifiés porteront un badge de conformité, les statistiques d’utilisation permettront de distinguer les serveurs matures des projets abandonnés, et les SLA garantiront un niveau de service pour les déploiements critiques.

Pour les entreprises, la recommandation est d’anticiper ces évolutions sans les attendre. Implémentez votre propre audit logging structuré en sachant que le protocole le standardisera. Évitez les dépendances sur les secrets statiques et concevez vos flux d’authentification pour être remplaçables. Commencez à construire des architectures multi-agents en utilisant les frameworks existants (LangGraph, CrewAI) en sachant que le MCP les standardisera au niveau protocole. Notre stratégie SEO et GEO automatisée intègre déjà ces principes d’architecture modulaire. Pour évaluer où en est votre entreprise dans cette transition, notre Diagnostic IA personnalisé identifie les meilleurs points de départ. Et pour une vue d’ensemble des connecteurs et plugins déjà disponibles, consultez notre guide des Skills et connecteurs Claude en 2026.

Questions fréquentes sur la roadmap MCP 2026

Quelle est la roadmap officielle du MCP pour 2026 ?

La roadmap, publiée le 9 mars 2026 par David Soria Parra (Lead Maintainer), identifie quatre priorités : l’évolution du transport Streamable HTTP pour le scaling horizontal, la communication agent-to-agent (Q3 2026), l’Enterprise Readiness avec OAuth 2.1 (Q2 2026), et la maturation de la gouvernance. Le MCP Registry est attendu au Q4 2026. Ce sont des priorités stratégiques, pas des engagements calendaires fermes.

Quand la communication agent-to-agent MCP sera-t-elle disponible ?

La communication agent-to-agent est ciblée pour le Q3 2026 selon la roadmap officielle. Elle permettra à un agent d’appeler un autre agent comme s’il était un serveur d’outils, créant des architectures hiérarchiques où un orchestrateur délègue à des sous-agents spécialisés. Google ADK v2.0 a déjà introduit une Task API structurée pour la délégation, signalant que l’écosystème converge vers cette capacité.

Qu’est-ce que le MCP Streamable HTTP et pourquoi évolue-t-il ?

Le Streamable HTTP est le transport qui permet aux serveurs MCP de fonctionner comme des services distants plutôt que des processus locaux. Son déploiement à grande échelle a révélé des limitations : les sessions stateful s’opposent aux load balancers, le scaling horizontal nécessite des contournements. L’évolution vise un fonctionnement stateless compatible avec les architectures cloud modernes.

Qu’est-ce qu’un MCP Server Card et à quoi sert-il ?

Un MCP Server Card est un format de métadonnées standard, servi via une URL .well-known, qui décrit les capacités d’un serveur MCP sans nécessiter de connexion active. Cela permet aux registres, crawlers et navigateurs de découvrir automatiquement ce qu’un serveur peut faire, facilitant la découverte et le déploiement à grande échelle.

L’authentification OAuth 2.1 MCP est-elle prévue pour 2026 ?

Oui, c’est l’une des priorités les plus avancées. OAuth 2.1 avec PKCE pour les agents browser-based et l’intégration SAML/OIDC avec les fournisseurs d’identité enterprise (Okta, Azure AD) sont ciblés pour le Q2 2026. Le SDK TypeScript v1.27.1 intègre déjà des tests de conformité d’authentification, signalant une implémentation en cours.

Qu’est-ce que le MCP Registry prévu fin 2026 ?

Le MCP Registry sera un répertoire vérifié de serveurs MCP — le « npm des agents IA ». Il fournira des audits de sécurité, des statistiques d’utilisation et des engagements SLA. Les équipes enterprise pourront évaluer les serveurs contre des critères standardisés avant déploiement, remplaçant la navigation actuelle dans des répertoires communautaires non vérifiés.

Comment contribuer au développement du MCP via les Working Groups ?

Les contributions passent par les Working Groups thématiques (Transport, Governance, Enterprise). Le processus consiste à rejoindre un WG, discuter de votre proposition, obtenir le soutien du groupe, puis soumettre une SEP (Spec Enhancement Proposal). Les SEPs alignées sur les quatre priorités de la roadmap reçoivent un examen accéléré. Le Contributor Ladder SEP définira formellement le parcours de progression.

Le MCP va-t-il ajouter de nouveaux transports en 2026 ?

Non. La roadmap est explicite : aucun nouveau transport officiel n’est prévu ce cycle. C’est une décision délibérée de stabiliser Streamable HTTP plutôt que de fragmenter l’écosystème. Le focus est sur l’évolution du transport existant pour le scaling stateless, les load balancers et la découverte via Server Cards.

Quelle est la différence entre une extension MCP et le core spec ?

La plupart des besoins enterprise seront implémentés comme des extensions plutôt que des ajouts au protocole de base. Cette séparation est délibérée : ne pas alourdir le core spec garantit sa simplicité et sa stabilité, tandis que les extensions permettent aux Working Groups d’innover dans leur domaine sans attendre un cycle de release complet du protocole.

Comment anticiper les évolutions MCP pour préparer son infrastructure ?

Trois actions immédiates : implémentez votre propre audit logging structuré (le protocole le standardisera), évitez les secrets statiques au profit de flux OAuth remplaçables, et construisez vos architectures multi-agents avec des frameworks actuels (LangGraph, CrewAI) en sachant que le MCP les standardisera. Ne pas attendre les spécifications finales pour commencer à construire.

Diag IA gratuit
Nous contacter
Parler à Eric