MCP passe au sans état : ce que la nouvelle spec change pour les équipes d’agents IA

Rédaction YuSMP Group Équipe éditoriale, YuSMP Group

L’essentiel

Qu’est-ce que la spécification 2026-07-28 change concrètement ?

Le Model Context Protocol est le standard ouvert qui relie les modèles d’IA aux outils, données et systèmes externes : la couche qu’un agent utilise pour interroger une base de données, appeler une API ou lire un document. Il s’est imposé très vite : ses responsables font état de près de 400 millions de téléchargements de SDK par mois, soit environ quatre fois plus en un an, les SDK TypeScript et Python dépassant chacun le milliard de téléchargements cumulés, et plus de 950 serveurs MCP référencés dans le seul annuaire de connecteurs de Claude. À cette échelle, une version qui refond le cœur du standard n’a rien d’anecdotique.

La version 2026-07-28 regroupe plusieurs changements : un cœur de protocole sans état, des « Multi Round-Trip Requests » qui remplacent les appels initiés par le serveur nécessitant un flux ouvert, un routage par en-têtes, des résultats de liste cachables, un modèle d’autorisation aligné sur OAuth et un cadre d’extensions versionné qui sort MCP Apps et Tasks du cœur. Les SDK de niveau 1 – TypeScript, Python, Go et C# – l’implémentent déjà, un SDK Rust étant en bêta. Sur le fond, les mainteneurs du protocole décrivent eux-mêmes ce virage comme la suppression de « beaucoup de choses qui faisaient MCP » tel qu’on le connaissait : c’est à la fois la promesse et l’avertissement.

Pourquoi le sans état est-il le vrai sujet ?

Le changement principal, c’est l’abandon des sessions au niveau du protocole. L’ancien modèle ouvrait une poignée de main initialize/initialized puis faisait transiter chaque message suivant par un Mcp-Session-Id : un client et une instance de serveur précise devaient rester liés pendant toute la conversation. Dans le nouveau modèle, chaque requête se décrit elle-même : elle transporte dans ses métadonnées sa version de protocole, l’identité du client et ses capacités, et peut donc être traitée isolément, sans mémoire de ce qui précède.

Cela paraît théorique tant qu’on ne l’exploite pas en production. Un serveur MCP distant qui exigeait des sessions persistantes, un stockage de sessions partagé et une inspection approfondie des paquets à la passerelle peut désormais se placer derrière un simple répartiteur round-robin, router le trafic sur un en-tête Mcp-Method et laisser les clients mettre tools/list en cache aussi longtemps que le ttlMs du serveur l’autorise. Le sans état, c’est la propriété même qui permet aux services web classiques de s’étendre horizontalement sur une flotte d’instances – et elle ouvre la voie à l’exécution de serveurs MCP sur des plateformes serverless et edge. Pour un back-end d’agents qui se déploie en milliers d’appels d’outils, c’est la différence entre un service sur mesure, difficile à exploiter, et un service que votre équipe cloud et DevOps sait déjà faire tourner.

Comment l’autorisation gagne-t-elle en maturité ?

Le second changement décisif pour qui livre à de vrais clients concerne l’autorisation. La spécification 2026-07-28 aligne MCP sur OAuth 2.0 et OIDC de production : les serveurs agissent comme serveurs de ressources OAuth 2.1, la validation de l’émetteur selon RFC 9207 devient obligatoire, et les identifiants client sont liés à l’autorité qui les a émis, pour qu’ils ne puissent pas être rejoués contre un autre serveur. Le Dynamic Client Registration est déprécié au profit des Client ID Metadata Documents, et un nouveau paramètre application_type évite que les clients CLI et desktop soient rejetés à cause de redirections vers localhost.

Concrètement, un serveur MCP peut désormais se brancher sur le fournisseur d’identité déjà en place dans l’entreprise – Microsoft Entra, Okta et consorts – sans la colle sur mesure qu’exigeaient les premiers déploiements. C’est précisément la case que les acheteurs réglementés cochent en premier. Une équipe FinTech ou e-santé ne peut pas ouvrir les systèmes internes à un agent tant que les accès ne sont pas auditables et rattachés à l’identité de l’entreprise : un modèle d’autorisation qui parle le langage existant de l’entreprise lève donc un véritable verrou avant d’approcher des données sensibles.

Qu’est-ce que cela change pour les équipes en France et en Europe ?

Au-delà du jargon de la spécification, la version 2026-07-28 marque une étape de maturité : MCP passe du statut de protocole local astucieux à celui d’infrastructure distribuée que l’on déploie comme n’importe quel autre service. Pour les équipes qui intègrent des agents à un produit existant – un travail qui se joue dans l’intégration de l’IA générative, pas dans le simple remplacement d’une API –, cela réduit deux coûts à la fois. Le cœur sans état diminue la charge opérationnelle de l’outillage d’agents à grande échelle, et le modèle OAuth réduit les frictions de sécurité et de conformité au moment de connecter cet outillage aux systèmes réels.

Mais lisez honnêtement la note de compatibilité, car c’est là que les migrations dérapent. La révision 2026-07-28 est la plus importante qu’ait connue MCP, et les serveurs de la nouvelle génération peuvent ne pas dialoguer avec les anciens clients si aucun des deux côtés n’implémente de repli ou de traduction délibéré. Roots, Sampling et Logging sont dépréciés – avec une période de prise en charge d’au moins 12 mois – et l’ancien transport HTTP+SSE est en voie de disparition. Si vos agents dépendent de l’un d’eux, ou si vous faites cohabiter plusieurs versions de clients et de serveurs, une mise à jour naïve cassera des choses sans bruit. La bonne approche : une migration par étapes qui maintient les deux générations du protocole en bordure jusqu’à ce que tout ait migré.

Il y a aussi une lecture stratégique pour les équipes qui doivent choisir où miser. MCP est piloté autour du protocole né chez Anthropic, mais c’est désormais un standard ouvert et multi-fournisseurs, et des initiatives concurrentes de protocoles d’agents rôdent. Une spécification qui rend MCP réellement déployable – sans état, cachable, nativement OAuth – est une tentative de rester la référence par défaut. Pour la plupart des équipes, la réponse pragmatique n’est pas de désigner un gagnant, mais de garder la couche d’appel d’outils abstraite, afin d’adopter le nouveau MCP dès maintenant sans se retrouver piégé si le paysage des standards bouge encore.

Que faire concrètement ce trimestre ?

Traitez le sujet comme une migration d’infrastructure avec un plan de retour arrière, pas comme une montée de version du jour au lendemain. Voici la version opérationnelle.

1. Recensez votre surface MCP. Listez chaque serveur et client MCP que vous exploitez, internes comme tiers, et notez la génération de protocole que chacun prend en charge aujourd’hui.
2. Passez à un SDK de niveau 1. Mettez à jour vers les versions des SDK TypeScript, Python, Go ou C# compatibles 2026-07-28, et figez les versions pour que chaque mise à jour soit délibérée.
3. Maintenez les deux générations en bordure. Placez une couche de compatibilité ou de traduction au niveau de la passerelle pour que nouveaux serveurs et anciens clients cohabitent jusqu’à la migration complète – ne basculez pas en espérant que tout tienne.
4. Raccordez l’autorisation à votre IdP. Configurez les serveurs MCP comme serveurs de ressources OAuth 2.1 face à Entra, Okta ou votre fournisseur existant, et validez les émetteurs selon RFC 9207.
5. Testez en charge le chemin sans état. Vérifiez que les requêtes sont correctement routées derrière un répartiteur standard, assurez-vous que votre mise en cache ttlMs est sans risque pour vos données et contrôlez que les fonctions dépréciées dont vous dépendez fonctionnent toujours pendant la période de prise en charge.
6. Désignez un responsable. L’infrastructure des agents évolue désormais aussi vite que les modèles. Nommez quelqu’un pour suivre la spécification, les versions des SDK et le calendrier des dépréciations, plutôt que de découvrir une rupture en production.

Rien de tout cela ne constitue un conseil juridique, et l’effort réel dépend de la part de votre stack qui parle déjà MCP. Mais le signal stratégique est clair : la couche d’outillage sous les agents IA devient une infrastructure standard et évolutive – et l’avantage ira aux équipes qui la traitent comme telle, en concevant pour le déploiement et l’identité plutôt qu’en courant après chaque nouvelle capacité.

Questions fréquentes

Sources

Model Context Protocol — The 2026-07-28 Specification, 28 July 2026 (primary source)
The Register — Model Context Protocol prepares to break with its stateful past, 23 July 2026
Anthropic — MCP 2026-07-28 spec: stateless core, coming to Claude, July 2026