MCP 2.0 stateless : ce que la spécification juillet 2026 change pour les PME

Le 21 mai 2026, l’équipe MCP a publié la release candidate de la plus grande révision du protocole depuis son lancement : MCP 2026-07-28 (source : blog MCP, mai 2026). Le changement majeur est la suppression des sessions au niveau du protocole. Pour les PME qui déploient des agents IA en production, c’est une simplification opérationnelle majeure — et une migration à planifier.

Ce qui change concrètement

Le protocole devient stateless

La spécification élimine le handshake initialize/initialized et les headers Mcp-Session-Id qui liaient un client à une instance serveur spécifique. Résultat : un serveur MCP distant qui nécessitait auparavant des sticky sessions, un session store partagé et une inspection profonde des paquets au gateway peut désormais tourner derrière un simple load balancer round-robin.

Pour une PME qui exploite des serveurs MCP en production, c’est un changement radical. Plus besoin de configurer l’affinité de session sur votre infrastructure, que ce soit Kubernetes, un PaaS ou un simple reverse proxy Nginx.

L’état passe dans les paramètres

Le protocole est stateless, mais les applications gardent leur état. Les serveurs émettent des identifiants depuis les appels d’outils, que les modèles repassent en paramètre dans les requêtes suivantes. L’état devient visible pour l’IA au lieu d’être caché dans les métadonnées de transport.

Nouveaux headers de routage

Les headers Mcp-Method et Mcp-Name permettent aux load balancers de router le trafic sans inspecter le corps de la requête. C’est un gain de performance et de sécurité pour les déploiements en production.

MCP Apps : des interfaces HTML dans vos agents

MCP Apps permet aux serveurs de livrer des interfaces HTML interactives rendues dans des iframes sandboxées. Les outils déclarent leurs templates d’interface à l’avance, permettant aux hôtes de les précharger, cacher et auditer avant exécution.

Pour une PME, cela signifie qu’un serveur MCP peut désormais afficher un formulaire, un graphique ou un dashboard directement dans l’interface de l’agent, sans développement frontend séparé.

Tasks : le travail long-running repensé

L’extension Tasks, initialement une fonctionnalité expérimentale du core, a été promue en extension indépendante. Les clients pilotent les tâches longues via tasks/get, tasks/update et tasks/cancel, alignés sur le modèle stateless.

C’est important pour les workflows PME qui nécessitent des opérations longues : génération de rapports, extraction de documents, analyse de données volumineuses.

Cache et observabilité

Deux améliorations opérationnelles majeures :

• Cache prédictif : les réponses list et resource-read portent désormais ttlMs et cacheScope, modelés sur HTTP Cache-Control. Les clients peuvent cacher les résultats sans deviner la durée de validité.
• Tracing distribué : la propagation W3C Trace Context est formellement documentée avec des noms de clés fixes, facilitant l’intégration dans les outils de monitoring existants.

Sécurité OAuth renforcée

L’alignement avec OAuth 2.0 et OpenID Connect est le titre côté entreprise de cette release. Pour les PME qui connectent leurs agents à des services authentifiés, les problèmes de sécurité MCP en production sont directement adressés par cette spécification.

Dépréciations : ce qui disparaît

Trois fonctionnalités sont dépréciées : Roots, Sampling et Logging. La spécification introduit un cycle de vie formel avec un minimum de 12 mois entre dépréciation et suppression. Si votre PME utilise Sampling pour faire appeler un LLM par un serveur MCP, il faudra migrer vers une architecture où c’est le client qui orchestre les appels.

Checklist de migration pour PME

1. Auditez vos serveurs MCP : listez ceux qui dépendent de sessions ou du handshake initialize.
2. Vérifiez vos SDK : attendez que votre SDK (Python, TypeScript) publie sa version compatible 2026-07-28.
3. Supprimez les sticky sessions : après migration, retirez l’affinité de session de vos load balancers.
4. Migrez Sampling : si vous utilisez Sampling, planifiez le passage à une orchestration client-side.
5. Testez le cache : implémentez ttlMs sur vos serveurs pour réduire la charge.
6. Activez le tracing W3C : connectez vos serveurs MCP à votre pipeline d’observabilité.

La fenêtre de validation de 10 semaines (jusqu’au 28 juillet 2026) est le moment idéal pour tester la migration dans un environnement de staging.

FAQ

Quand la spécification MCP stateless sera-t-elle finalisée ?

La release candidate a été verrouillée le 21 mai 2026, avec une fenêtre de validation de 10 semaines. La spécification finale est prévue pour le 28 juillet 2026.

Ma PME utilise des serveurs MCP avec sessions : dois-je migrer immédiatement ?

Non, pas immédiatement. La spécification précédente (2025-11-25) restera fonctionnelle le temps de la migration. Mais les SDK seront progressivement mis à jour vers la nouvelle spec, et les sessions seront dépréciées avec un délai minimum de 12 mois avant suppression.

Quels sont les avantages concrets du MCP stateless pour une PME ?

Trois avantages principaux : déploiement derrière un load balancer standard sans sticky sessions, réduction des coûts d’infrastructure (pas de session store partagé), et meilleure résilience car chaque requête peut être routée vers n’importe quelle instance serveur.