Le 21 mai 2026, les mainteneurs du Model Context Protocol ont gele une release candidate qui rebat les cartes de la mecanique interne du standard le plus adopte pour connecter les agents IA au reste du monde. La version finale, datee du 28 juillet 2026, fait passer MCP en stateless : plus de session collante entre un client et un serveur. Derriere ce mot technique se cache un vrai tournant d'industrialisation pour tous ceux qui deploient des agents en production.
Petit rappel pour situer. MCP, ne chez Anthropic fin 2024, est devenu en dix-huit mois le connecteur universel entre les modeles d'IA et les outils externes : bases de donnees, API, fichiers, services SaaS. OpenAI, Google et la plupart des editeurs l'ont adopte. Autant dire que la moindre evolution de sa plomberie concerne tout l'ecosysteme.
Le stateless, ou la fin des sessions collantes
Jusqu'ici, un serveur MCP distant gardait un etat en memoire. Le client ouvrait une session via une poignee de main initialize / initialized, puis restait epingle a une instance precise du serveur grace a un en-tete Mcp-Session-Id. En clair : il fallait des load balancers a sessions collantes et un magasin de sessions partage pour gerer les pannes.
La release candidate supprime cette poignee de main et l'en-tete de session. Desormais, les informations du client et ses capacites voyagent dans un champ _meta sur chaque requete, qui devient autonome. Deux nouveaux en-tetes, Mcp-Method et Mcp-Name, permettent a l'infrastructure de router le trafic sans meme inspecter le corps du message.
Le benefice est tres concret pour les equipes ops. Un serveur MCP qui exigeait des sessions collantes peut maintenant tourner derriere un simple load balancer en round-robin. Les serveurs annoncent une duree de vie (TTL) pour la liste de leurs outils, ce qui autorise un cache cote client et evite de tout recharger a chaque appel. Et surtout, un redemarrage de serveur ne deconnecte plus les clients, puisqu'il n'y a plus d'etat de session a perdre.
Tasks, MCP Apps, Extensions : le protocole se modularise
Le passage au stateless oblige a repenser les operations longues. C'est le role de l'extension Tasks, qui quitte le statut experimental pour devenir une extension officielle. Un serveur peut repondre a un appel d'outil par un task handle ; le client pilote ensuite le travail avec tasks/get, tasks/update et tasks/cancel. La methode tasks/list, elle, disparait. Fini de garder une connexion ouverte pendant qu'un agent mouline : il lance le job et revient verifier le resultat plus tard.
MCP Apps (proposition SEP-1865) est sans doute la nouveaute la plus visible. Un serveur peut desormais livrer des interfaces HTML interactives, rendues par l'hote dans une iframe en bac a sable. Les outils declarent leurs gabarits d'interface a l'avance, ce qui permet a l'hote de les pre-charger, de les mettre en cache et de les passer en revue cote securite avant toute execution. Tout transite par le meme canal JSON-RPC audite que les appels d'outils classiques.
Enfin, le cadre Extensions (SEP-2133) regle un probleme de fond : faire evoluer le protocole sans gonfler son coeur. Les extensions s'identifient en reverse-DNS, se negocient via des cartes de capacites, vivent dans des depots ext-* avec leurs propres mainteneurs et se versionnent independamment. Le coeur reste mince, les ajouts vivent a cote.
Securite durcie et politique de depreciation
Cette release ne se contente pas de reorganiser la plomberie. Six propositions alignent l'autorisation MCP sur les deploiements OAuth 2.0 et OpenID Connect du monde reel. Les clients doivent par exemple valider le parametre iss (conformement a la RFC 9207), declarer leur application_type OpenID Connect lors de l'enregistrement dynamique, et lier leurs identifiants a l'issuer du serveur d'autorisation emetteur. Autant de garde-fous contre les attaques par confusion de serveur.
Autre signal de maturite : une vraie politique de depreciation (SEP-2577). Les fonctionnalites suivent desormais un cycle Active puis Deprecie puis Retire, avec au moins douze mois entre l'annonce d'une depreciation et son retrait possible. Trois mecanismes sont deja marques comme deprecies : Roots, Sampling et Logging. Pour quiconque construit sur MCP, c'est la garantie de ne plus se reveiller un matin avec une integration cassee du jour au lendemain.
Cote calendrier, les mainteneurs ont verrouille la release candidate le 21 mai pour ouvrir une fenetre de validation de dix semaines, jusqu'au 28 juillet. Les SDK dits Tier 1 sont attendus avec le support complet dans ce delai.
Mon analyse : MCP entre dans l'age industriel
Ce qui me frappe dans cette version, c'est qu'elle ne cherche pas a ajouter du spectaculaire. Elle s'attaque a la scalabilite et a la gouvernance, exactement les deux sujets qui separent un protocole de hackathon d'un standard d'entreprise. Le stateless, c'est ce qui permet de passer d'un serveur MCP qui tourne sur le poste d'un developpeur a une flotte de serveurs derriere un load balancer, exploitee par une equipe ops normale.
Je le vois comme le moment ou MCP cesse d'etre une curiosite de l'ecosysteme agents pour devenir une brique d'infrastructure. La politique de depreciation a douze mois et le durcissement OAuth envoient un message clair aux DSI : on peut construire dessus sans craindre l'instabilite chronique des standards trop jeunes.
Le revers existe : cette release introduit des changements de rupture. La poignee de main disparait, tasks/list aussi, et trois mecanismes passent en deprecie. Les equipes qui ont deja des integrations MCP en production vont devoir migrer, tester et suivre la fenetre de validation de pres. Mais c'est le prix d'un protocole qui grandit, et mieux vaut une rupture documentee avec douze mois de preavis qu'un standard qui derive en silence.
J'ai detaille chaque SEP, les nouveaux en-tetes et la checklist de migration dans mon analyse complete sur TECH ACTU : le lien est en commentaire.
