MCP passe au sans état : la nouvelle spécification vise l'entreprise

Le 28 juillet 2026, les mainteneurs du Model Context Protocol ont publié la révision `2026-07-28` de la spécification. Elle supprime le mécanisme qui structurait le protocole depuis ses débuts : la session. Un serveur MCP distant n'a plus rien à retenir entre deux requêtes, et n'importe quelle requête peut désormais tomber sur n'importe quelle instance de serveur.

C'est très technique, et c'est pourtant la nouvelle qui compte le plus pour quiconque envisage de brancher un agent IA sur ses propres outils. Voici ce que dit la spécification, ce qu'est MCP pour ceux qui n'ont jamais eu à s'y intéresser, et ce que le passage au sans état débloque concrètement.

MCP, c'est quoi ?

La documentation officielle propose une image simple, et c'est la bonne : MCP est un port USB-C pour les applications d'IA. Avant l'USB-C, chaque appareil avait son connecteur propriétaire. Avant MCP, chaque assistant devait se voir écrire un connecteur spécifique vers chaque logiciel. Avec un standard partagé, on écrit le connecteur une fois et tous les assistants compatibles savent s'en servir.

Techniquement, le protocole définit trois rôles :

• L'hôte MCP : l'application d'IA que vous utilisez, par exemple Claude Code, Claude Desktop ou Visual Studio Code. C'est elle qui coordonne le tout.
• Le client MCP : un composant interne à l'hôte, qui maintient une connexion avec un serveur. L'hôte en crée un par serveur auquel il se connecte.
• Le serveur MCP : un programme qui fournit du contexte et des actions. Il peut tourner sur votre machine ou à distance.

Un serveur expose trois choses : des outils (des fonctions exécutables, par exemple interroger une base de données), des ressources (des données de contexte, par exemple le contenu d'un fichier) et des prompts (des gabarits d'interaction réutilisables).

Pour un exemple réel, le groupe de pilotage du projet maintient un petit dépôt d'implémentations de référence. On y trouve notamment un serveur Filesystem, décrit comme offrant des « opérations de fichiers sécurisées avec des contrôles d'accès configurables », un serveur Git pour lire et manipuler des dépôts, et un serveur Fetch pour récupérer du contenu web. Ce sont des exemples pédagogiques, pas des produits de production : les mainteneurs le précisent explicitement. Côté distant, la documentation cite le serveur MCP de Sentry, hébergé par Sentry et joignable par HTTP.

« Un serveur MCP n'est pas une IA. C'est une prise normalisée qui décrit à une IA ce qu'elle a le droit de faire, et comment. »

Ce que contient la spécification du 28 juillet 2026

Le billet d'annonce résume le changement central en une phrase : MCP passe d'un protocole bidirectionnel avec état à un protocole requête / réponse sans état. Le reste découle de ce choix.

Trois précisions qui échappent souvent aux reprises. D'abord, les tâches longues quittent le cœur expérimental du protocole pour devenir une extension officielle, aux côtés de MCP Apps et de l'autorisation gérée par l'entreprise. Ensuite, l'autorisation est durcie sur trois points : validation de l'émetteur selon la RFC 9207, déclaration du type d'application à l'enregistrement, et interdiction de réutiliser des identifiants clients d'un serveur d'autorisation à l'autre. Enfin, trois fonctionnalités historiques passent en déprécié : Roots, Sampling et Logging. Elles continuent de fonctionner, mais les nouvelles implémentations ne devraient plus les adopter.

Pourquoi le sans état change tout à l'échelle d'une entreprise

Un serveur avec état est un cauchemar à mettre à l'échelle, et la raison est mécanique. Si le client reçoit un identifiant de session à l'ouverture, alors toutes ses requêtes suivantes doivent revenir vers la même instance, celle qui détient cet état en mémoire. Il faut donc des sessions collantes au niveau du répartiteur de charge, ou un magasin de sessions partagé entre toutes les instances. Ajoutez la découverte des outils qui variait d'une connexion à l'autre, la passerelle qui devait ouvrir le corps JSON pour savoir ce qu'elle acheminait, et une coupure réseau qui perdait tout le contexte : cela fait beaucoup d'infrastructure pour brancher un assistant sur un CRM.

Avec la révision du 28 juillet, chaque requête se décrit elle-même. Le billet officiel le formule ainsi : n'importe quelle requête peut atterrir sur n'importe quelle instance derrière un simple répartiteur en tourniquet. Trois conséquences directes.

• Le déploiement redevient ordinaire. Un serveur MCP se traite comme une API HTTP classique, y compris sur des plateformes sans serveur qui ne savent pas garder une connexion ouverte.
• La passerelle reprend la main. Les en-têtes `Mcp-Method` et `Mcp-Name` permettent à un pare-feu applicatif, un limiteur de débit ou une passerelle d'entreprise de router et d'autoriser sans inspecter le contenu.
• Le catalogue d'outils se met en cache. Les listes portent une durée de fraîcheur et une portée de cache. Les clients cessent de tout recharger à chaque reconnexion, ce qui stabilise aussi les caches de prompts en amont.

Les mainteneurs insistent sur un point souvent mal compris : supprimer la session du protocole n'oblige pas votre application à être sans état. Si un serveur doit transporter un état entre deux appels, il émet une poignée explicite depuis un outil, et le modèle la repasse en argument. D'après le billet officiel, cela fonctionne mieux qu'un état caché dans le transport, parce que le modèle voit la poignée et peut la faire circuler entre les outils.

L'enjeu dépasse les équipes qui écrivent des serveurs. Zapier expose ses milliers d'applications connectées via un serveur MCP, Make fait de même pour piloter ses scénarios depuis un assistant externe, et une plateforme d'agents d'entreprise comme Dust se branche sur n'importe quel outil par ce biais. Plus le protocole tient à l'échelle, plus ces intégrations deviennent des briques par défaut plutôt que des projets. Notre comparatif n8n vs Zapier revient sur ce que chacune propose côté agents.

La direction était connue depuis mai. David Soria Parra, co-créateur du protocole, avait annoncé la version candidate deux mois plus tôt.

Dans le billet du 28 juillet, il replace la sortie dans l'histoire du protocole.

Qui décide de MCP ? Anthropic, l'AAIF et la Linux Foundation

C'est la question que pose toute direction technique avant de bâtir sur un standard, et la réponse a changé fin 2025. Anthropic a présenté MCP le 25 novembre 2024, puis en a fait don en décembre 2025 à l'Agentic AI Foundation, un fonds dédié placé sous l'égide de la Linux Foundation et co-fondé avec Block et OpenAI, avec le soutien de Google, Microsoft, AWS, Cloudflare et Bloomberg. MCP en est un projet fondateur, aux côtés de goose (Block) et d'AGENTS.md (OpenAI).

Le partage des rôles est explicite dans la documentation officielle. Le conseil de la fondation tranche les questions d'investissement, de budget, de recrutement de membres et d'admission de nouveaux projets. Chaque projet, MCP compris, garde une autonomie complète sur sa direction technique et son fonctionnement quotidien. La Linux Foundation, précisent les mainteneurs, ne dicte pas la direction technique.

Reste la question de l'influence. Les décisions techniques reviennent formellement aux mainteneurs, et la charte de gouvernance pose que l'appartenance est attachée aux individus, pas aux entreprises : aucun siège n'est réservé à une société. Dans les faits, les deux mainteneurs principaux actuels, David Soria Parra et Den Delimarsky, travaillent l'un et l'autre chez Anthropic, comme le relève Ars Technica. Anthropic conserve donc une influence significative sur la trajectoire du protocole, même si OpenAI, Google, Microsoft et Amazon y contribuent également. Le billet du 28 juillet publie d'ailleurs les réactions de Google Cloud, Microsoft Foundry, AWS, Cloudflare, Netlify, Figma et Supabase.

La nouveauté la plus rassurante pour une DSI n'est pourtant pas technique. C'est la politique de cycle de vie adoptée avec cette révision. Une fonctionnalité dépréciée doit rester disponible au minimum douze mois avant d'être éligible au retrait, le décompte partant de la révision qui la marque comme dépréciée. Une exception étroite existe pour un risque de sécurité actif, entendu comme une vulnérabilité faisant l'objet d'un avis publié ou d'une exploitation documentée, sans correctif applicable en l'état. Même dans ce cas, la fenêtre raccourcie doit encore laisser au moins quatre-vingt-dix jours. Un registre public recense les fonctionnalités concernées et leur date de retrait au plus tôt.