Le 28 juillet 2026, le protocole qui connecte les assistants IA à vos outils internes a changé de nature. La spécification MCP 2026-07-28 (Model Context Protocol) passe du statut de protocole avec état — sessions, poignée de main, identifiant persistant — à un modèle stateless requête/réponse. Elle embarque au passage deux extensions officielles, un durcissement de l'authentification, et une liste de breaking changes que toute équipe ayant déployé un serveur MCP doit regarder de près.

Dix semaines de validation avant de casser la compatibilité

Le Model Context Protocol, poussé initialement par Anthropic puis adopté comme standard de facto par la quasi-totalité des éditeurs d'assistants IA, avait ouvert une fenêtre de validation de dix semaines (du 21 mai au 28 juillet 2026) avant de figer cette révision. L'objectif : laisser les mainteneurs de SDK et les éditeurs de clients tester la spec candidate contre de vraies charges de travail avant le verrouillage définitif.

Résultat, selon David Soria Parra, l'un des porteurs du protocole : « le protocole est maintenant stateless — pas de handshake, pas d'identifiant de session, n'importe quelle requête peut atteindre n'importe quelle instance de serveur ». Une bascule que l'équipe MCP elle-même qualifie de plus importante depuis l'introduction de l'autorisation dans le protocole.

Ce qui casse concrètement

Le changement central est la disparition des sessions au niveau protocolaire : plus de handshake initial, plus d'en-tête Mcp-Session-Id. N'importe quelle instance de serveur derrière une infrastructure HTTP classique peut désormais répondre à une requête, ce qui ouvre la voie à des déploiements sur des infrastructures serverless et en edge — un vrai gain d'exploitation pour qui hébergeait jusqu'ici des serveurs MCP à état, contraints de router chaque requête vers la même instance.

Mais ce gain a un prix immédiat pour les équipes existantes. La fonctionnalité Tasks, qui gérait les traitements longs, est entièrement reconstruite autour de handles plutôt que d'objets liés à une session. La méthode tasks/list est purement et simplement supprimée. Trois fonctionnalités historiques du cœur du protocole sont marquées comme dépréciées. Et six Specification Enhancement Proposals viennent positionner formellement les serveurs MCP comme des serveurs de ressources OAuth 2.1, ce qui touche directement la façon dont l'authentification est gérée côté serveur.

Autrement dit : si votre équipe a codé un serveur MCP en s'appuyant sur des sessions persistantes ou sur tasks/list, il faudra migrer avant de passer à cette version — pas de rétrocompatibilité silencieuse ici.

Les Extensions : MCP Apps et Tasks en première ligne

Deuxième pilier de cette révision : l'arrivée d'un véritable framework d'extensions. Les extensions sont identifiées via une notation reverse-DNS et négociées par des cartes de capacités (capability maps), un mécanisme qui rappelle la négociation de fonctionnalités côté navigateur web. Les deux premières extensions officielles à en bénéficier sont MCP Apps et Tasks.

MCP Apps permet à un serveur de livrer des interfaces HTML interactives que l'hôte (l'application qui embarque l'assistant IA) affiche dans un iframe sandboxé. Concrètement, un serveur MCP ne se contente plus de renvoyer du texte ou du JSON : il peut pousser un mini-formulaire, un tableau, un widget de configuration, directement rendu dans l'interface du client. Pour les éditeurs d'outils internes (support client, dashboards RH, ERP maison), c'est une porte d'entrée vers des intégrations IA nettement plus riches qu'un simple appel de fonction texte.

Tasks, de son côté, redéfinit la gestion des traitements longs dans un monde sans session : un serveur répond à un appel tools/call par un handle de tâche, que le client pilote ensuite via tasks/get, tasks/update et tasks/cancel. Ce modèle évite d'avoir à maintenir une connexion ouverte pendant qu'un traitement tourne en arrière-plan — utile typiquement pour une génération de rapport, un scraping, ou un job d'indexation déclenché par un agent IA.

L'authentification passe à l'échelle entreprise

Le troisième axe de cette révision concerne directement les organisations qui déploient plusieurs serveurs MCP en interne : l'extension Enterprise-Managed Authorization est désormais stable. Elle permet à une organisation de gérer l'autorisation de façon centralisée, et aux utilisateurs finaux d'accéder à l'ensemble des serveurs MCP connectés via une authentification unique.

Cette extension est d'ores et déjà adoptée par Anthropic, Microsoft et Okta, et un nombre croissant de serveurs MCP tiers l'intègrent. C'est un signal clair envoyé aux DSI et RSSI : le MCP quitte le stade du prototype bricolé par des développeurs pour devenir un protocole que l'on peut gouverner comme n'importe quel autre point d'accès SSO de l'entreprise — provisioning centralisé, révocation d'accès instantanée, audit des connexions.

Le protocole gagne aussi en gouvernance humaine : Clare Liguori a rejoint le groupe des mainteneurs principaux, et Den Delimarsky devient lead mainteneur. Une structuration qui traduit la maturité croissante du projet, désormais loin d'être une simple initiative isolée d'un éditeur.

Ce que ça change pour une équipe qui a déjà un serveur MCP en prod

Si vous avez déjà un serveur MCP exposé en interne ou côté client, cette révision mérite un vrai audit avant mise à jour. Trois points de vigilance concrets.

D'abord, vérifiez toute logique qui suppose une session persistante entre deux appels — elle ne survivra pas telle quelle au passage stateless. Ensuite, si vous utilisez tasks/list pour lister des traitements en cours, il faut migrer vers le nouveau modèle par handle avant de mettre à jour votre SDK. Enfin, si votre organisation gère plusieurs serveurs MCP pour différentes équipes, l'extension Enterprise-Managed Authorization mérite d'être évaluée maintenant : elle évite de finir avec autant de silos d'authentification que de serveurs déployés.

Mon avis

Ce qui me frappe dans cette révision, c'est qu'elle traite le MCP comme une infrastructure critique et non plus comme une commodité expérimentale. Passer au stateless pour permettre du edge et du serverless, c'est le même chemin qu'ont suivi HTTP puis les API REST il y a quinze ans : on sacrifie un peu de confort de développement pour gagner en scalabilité et en résilience opérationnelle.

Le vrai signal, à mes yeux, n'est pas technique mais organisationnel : quand Microsoft et Okta adoptent la même extension d'autorisation qu'Anthropic sur un protocole censé rester neutre vis-à-vis des éditeurs de modèles, cela confirme que le MCP est en train de devenir un standard d'infrastructure au même titre que OAuth ou SAML avant lui. Pour une PME qui commence tout juste à connecter ses assistants IA à ses données internes, c'est le bon moment pour se poser la question de la gouvernance des accès — avant d'avoir dix serveurs MCP disparates à corriger un par un.

MCP 2026-07-28 : la spec finale impose ses breaking changes aux devs