Le 28 juillet, le Model Context Protocol a publié sa spec 2026-07-28. Cinquième révision depuis le lancement, et les mainteneurs la présentent comme la plus grosse à ce jour. Le changement phare : MCP a cessé d'être un protocole stateful pour devenir stateless.
Cette phrase ne parle à personne. Reprenons de plus loin.
Ce qu'est MCP, en une minute environ
MCP, c'est la prise standard entre les modèles d'IA et tout le reste.
Avant lui, chaque appli d'IA qui voulait lire votre Drive, interroger votre base de données ou ouvrir un ticket Jira devait écrire une intégration sur mesure pour chacun. Chaque modèle, chaque outil, à chaque fois. Ça ne passait pas à l'échelle.
MCP a réglé ça avec une seule forme. Vous construisez un serveur MCP pour votre service une bonne fois, et n'importe quel client MCP peut lui parler. Claude, Cursor, VS Code, ou ce qui sortira l'année prochaine. Anthropic l'a publié en novembre 2024, puis l'a confié à une fondation, et l'adoption est allée plus vite que presque tout le monde ne l'avait prévu. Anthropic annonce aujourd'hui environ 400 millions de téléchargements de SDK par mois, et plus de 950 serveurs rien que dans le répertoire de connecteurs de Claude.
Voyez ça comme l'USB-C des outils d'IA. Une seule prise au lieu d'un tiroir plein d'adaptateurs.
Ce qui a vraiment changé
L'ancien MCP avait de la mémoire. Le nouveau, non.
Sous l'ancien régime, se connecter à un serveur MCP distant commençait par un handshake. Le client dit bonjour. Le serveur répond bonjour et tend un session ID. À partir de là, chaque requête transporte cet ID, et le serveur se souvient de vous entre les appels.
Pratique, sur le papier. En production, un casse-tête.
Voici pourquoi. Admettons que votre serveur MCP tourne sur dix machines derrière un load balancer, ce à quoi ressemble n'importe quel déploiement réel. Votre handshake atterrit sur la machine trois. La machine trois fabrique votre session ID et se souvient de vous. Votre requête suivante est routée vers la machine sept, qui n'a jamais entendu parler de vous. Erreur, on recommence.
Les ingénieurs de Google ont raconté le déploiement de MCP sur leur propre infrastructure et ont dit s'être heurtés de plein fouet à exactement ça. Chaque contournement avait un coût. Épinglez chaque utilisateur à une seule machine et vous perdez le load balancing. Poussez l'état de session dans un Redis partagé et vous voilà à faire tourner une base de données pour un détail de protocole. Faites ouvrir le corps de chaque requête par votre gateway pour décider du routage, et vous le payez en latence. Et quand une machine redémarrait, tout le monde dessus perdait sa session.
La nouvelle spec supprime le problème au lieu de le gérer. Pas de handshake. Pas d'en-tête session ID. Chaque requête transporte ce que le serveur doit savoir : version du protocole, infos client, capacités. N'importe quelle machine peut répondre à n'importe quelle requête, et peu importe laquelle a répondu la fois d'avant.
Une précision s'impose. C'est du stateless au niveau du protocole, pas au niveau de l'application. Vous pouvez toujours bâtir des choses stateful par-dessus. HTTP est un protocole stateless, et tout le web tourne dessus sans le moindre souci.
Ce que ça vous rapporte
Si vous ne faites qu'utiliser des outils d'IA, vous n'avez rien à faire. Votre client s'en charge. Vous devriez remarquer des connexions distantes un peu plus rapides, parce qu'un aller-retour a disparu, et plus fiables, parce qu'un redémarrage de serveur ne vous éjecte plus en plein travail.
Si vous déployez des serveurs MCP, c'est la version que vous attendiez. Un simple round robin suffit. Pas de sticky sessions, pas de stockage de session partagé. Vous pouvez faire tourner vos serveurs sur Lambda, Cloudflare Workers, Cloud Run ou Vercel et les laisser descendre à zéro quand personne ne s'en sert. GitHub a dégainé le support très tôt et a purement supprimé sa couche de sessions Redis. Leur changelog le dit sans détour : les écritures en base à la connexion, terminé ; les lectures à chaque appel, terminé ; et personne n'y a rien perdu.
Si vous construisez des serveurs MCP, il y a du boulot. Combien ? Ça dépend entièrement de ce sur quoi vous avez bâti.
Le fond du sujet, pour ceux qui sont déjà dedans
Le cœur stateless arrive via deux propositions, SEP-2575 et SEP-2567. La première tue le handshake initialize et déplace la version du protocole, les infos client et les capacités dans _meta, sur chaque requête. La seconde retire complètement la notion de session et l'en-tête Mcp-Session-Id de Streamable HTTP, sans période de dépréciation. Rupture nette.
Si vous aviez besoin d'un état d'un appel à l'autre, c'est désormais à vous de le fabriquer. Un outil renvoie un handle explicite, le modèle vous le repasse comme un argument ordinaire, et votre véritable état vit dans Redis ou Postgres, indexé par ce handle. Effet de bord appréciable : comme le handle figure dans le transcript, il survit à un redémarrage du client, ce que les sessions n'ont jamais fait.
Tout ce qui reposait sur une connexion maintenue ouverte a dû être refait. Le sampling, l'elicitation et les roots dépendaient du serveur qui rappelait par un canal vivant. Ils sont remplacés par les Multi Round-Trip Requests. Le serveur renvoie un résultat marqué input_required avec un requestState opaque, le client récupère les réponses, puis rejoue le même appel avec les réponses jointes. N'importe quelle instance peut reprendre ce rejeu. Supabase, qui tourne en stateless, dit que c'est ce qui lui permet enfin de gérer les elicitations tout court.
Le reste de la version, c'est en gros les conséquences de cette décision :
- Chaque résultat porte maintenant un
resultType. Les serveurs sur d'anciennes specs sont traités commecomplete. - Chaque POST porte les en-têtes
Mcp-MethodetMcp-Name, pour que les gateways puissent router, limiter le débit et auditer sans parser le corps. - Les résultats de liste portent
ttlMsetcacheScope, empruntés tels quels à la sémantique de cache HTTP. Mettezpublicsur une liste propre à un client et vous avez livré une fuite de données, donc prudence. - L'endpoint GET et
resources/subscribedisparaissent, remplacés par un unique fluxsubscriptions/listenauquel vous souscrivez par type de notification. - La reprise sur incident disparaît. Pas de
Last-Event-ID, pas d'ID d'événement. Un flux coupé perd la requête en cours et vous la réémettez. La durabilité a migré vers l'extension Tasks, qui a elle aussi quitté le cœur et fonctionne maintenant par polling. - Les roots, le sampling et le logging sont dépréciés, tout comme l'ancien transport HTTP+SSE. Il existe enfin une vraie politique de dépréciation, avec une fenêtre minimale de douze mois, donc rien ne disparaît du jour au lendemain.
- L'auth se durcit. La validation de l'émetteur est désormais obligatoire, et les Client ID Metadata Documents commencent à remplacer l'enregistrement dynamique des clients.
Les quatre SDK Tier 1 ont livré le support le jour de la publication. TypeScript s'est scindé en paquets serveur et client séparés et fournit un codemod. Python a renommé FastMCP en MCPServer. Go n'a quasiment pas bougé.
La partie à ne surtout pas zapper
Le stateless ne supprime pas le travail. Il le déplace sur vos épaules.
Il n'y a plus de session à authentifier une seule fois, donc chaque requête doit être authentifiée. Les chercheurs en menaces d'Akamai ont pointé les conséquences évidentes : des champs _meta contrôlés par le client et dépourvus de signature, des secrets mappés par erreur dans des en-têtes et donc visibles par chaque proxy et chaque log sur le chemin, et la création de tâches à bas coût comme vecteur de déni de service. Leur résumé est juste. Les frontières de sécurité dépendent désormais entièrement de la façon dont chaque développeur les implémente. Ils vendent aussi des produits sur ce créneau, à pondérer en conséquence.
La migration, elle, est bien réelle. The Register n'a pas mâché ses mots sur les implémentations maison qui ont du pain sur la planche, et le mainteneur principal de MCP a dit tout haut qu'une bonne partie de ce qui faisait MCP a disparu. Il a raison. Si vous avez écrit votre propre transport, comptez une semaine et attendez-vous à des surprises. Les anciens clients et les nouveaux serveurs ne peuvent pas se parler sans un fallback délibéré d'un côté.
Et la critique la plus juste qui circule : si un serveur MCP distant ressemble maintenant à un service HTTP stateless ordinaire, à quoi sert MCP, au fond ? La réponse honnête, c'est que la valeur n'a jamais été le transport. C'est la découverte, les schémas d'outils et une histoire d'autorisation commune. Cette version arrête simplement de faire du transport le truc contre lequel vous vous battez.
Où j'atterris
Le cadrage sur lequel je reviens sans cesse, c'est que ça a pris dix-huit mois, pas une seule version. Streamable HTTP a rendu les serveurs stateless possibles dès mars 2025. Cette spec a fait du stateless le seul modèle. L'écart entre ces deux dates, c'est l'écart entre une chose techniquement supportée et une chose qui marche vraiment comme ça.
Une enquête d'éditeur situe à 41 % la part des organisations logicielles qui font tourner MCP en production, sous une forme ou une autre. Voilà pourquoi le protocole devait mûrir. Vous ne pouvez pas demander à autant d'équipes de faire tourner Redis pour un handshake.
Les problèmes intéressants de MCP ne sont plus des problèmes de transport. Ce sont l'autorisation, la mesure de l'usage et l'attribution. Déterminer qui a le droit d'appeler quoi, et qui paie.
Voilà à quoi ressemble un protocole quand il cesse d'être une démo.
Tiré de la spec MCP 2026-07-28 et de ses propositions SEP-2575 et SEP-2567, des retours d'ingénierie de Google et de GitHub sur son exploitation, des recherches en menaces d'Akamai relayées par SecurityWeek, des notes de version de Supabase et d'Anthropic, de la couverture de The Register, et de l'enquête d'un éditeur sur l'adoption en production. Instantané au 9 août 2026. Les specs bougent, donc vérifiez modelcontextprotocol.io avant de me citer sur le nom d'un en-tête.