MCP v2 Alpha : préparer le virage du 28 juillet
Le Model Context Protocol cesse d’être seulement un confort d’intégration. Il devient une brique d’infrastructure. Le candidat de spécification prévu pour le 28 juillet 2026 rend ce passage tangible : requêtes sans état, extensions mieux cadrées, autorisation durcie et ruptures de SDK qu’il vaut mieux organiser avant qu’elles ne touchent la production.
Model Context Protocol s’est imposé parce qu’il donne aux applications d’IA une façon commune d’accéder aux outils, aux données et aux services. Le 21 mai 2026, le sujet a changé d’échelle. Les mainteneurs du protocole ont publié le candidat 2026-07-28 avec un cœur de protocole sans état, Extensions, Tasks, les Apps associées, un durcissement de l’autorisation, JSON Schema 2020-12 pour les outils et une règle formelle d’obsolescence (Model Context Protocol blog).
Pour les équipes techniques, la vraie question n’est donc pas de savoir si ce standard gagne en popularité. Elle consiste à vérifier si l’implémentation supportera la prochaine frontière du protocole. Un flux d’agent qui dépend de sessions persistantes, d’une mémoire implicite côté serveur, d’hypothèses OAuth trop larges ou de mises à niveau SDK non bornées reçoit ici un signal d’alerte. À l’inverse, une pile qui dispose déjà de versions figées, de tests de répartition de charge, de jetons limités et de traces lisibles peut profiter de ce changement pour simplifier son exploitation.
Nous avons déjà traité l’écosystème du protocole en 2026 et les effets sur la communication multi-agents. Le sujet ici est plus précis : que faut-il valider avant que la date du 28 juillet ne devienne la cible pratique de tout l’écosystème ?
La préversion v2 sert à valider, pas à partir en production
Cette préversion donne aux mainteneurs de SDK et aux opérateurs de serveurs le temps d’éprouver les changements incompatibles avant la date de spécification du 28 juillet 2026.
Le candidat officiel indique que la spécification finale est prévue le 28 juillet 2026 et que la version contient des changements incompatibles (Model Context Protocol blog). Le calendrier du SDK Python précise davantage la fenêtre : v2.0.0a1 a été publié le 11 juin 2026, la bêta est visée pour le 30 juin 2026 et la v2 stable pour le 27 juillet 2026 (GitHub release).
MCP v2 Alpha doit donc rester dans une voie d’essai. Les métadonnées PyPI expliquent que les préversions sont publiées sous la forme 2.0.0aN, que chaque alpha peut contenir des ruptures, et que v1.x reste la branche stable recommandée pour la production (PyPI JSON). Pour la gestion des dépendances, cette phrase suffit à changer la pratique. Une contrainte non bornée sur mcp ne cassera pas nécessairement immédiatement, puisque les gestionnaires n’installent pas une préversion sans demande explicite. Mais un essai v2 devrait toujours passer par une version exacte et une branche séparée.
La méthode la plus sûre reste sobre : garder une contrainte de production du type mcp>=1.27,<2, puis créer une branche de migration qui pointe vers l’alpha exacte. Le README.v2 du SDK formule le même principe côté installation : les préversions doivent être choisies explicitement, tandis qu’une installation non bornée reste sur v1.x (README.v2).
Pour une entreprise qui construit des outils d’agents pour ses clients, cette discipline appartient à la même famille que le routage de modèles, l’observabilité et la gouvernance des mises en production. Context Studios l’intègre à son travail d’AI Agent Development, car la panne vient rarement du modèle seul. Elle vient plus souvent d’un connecteur, d’un droit ou d’une hypothèse d’exécution qui a changé sans chemin de migration contrôlé.
Le mode sans état change l’exploitation des serveurs
Le basculement architectural majeur concerne le routage sans état : une requête du protocole ne devrait plus dépendre d’une session protocolaire ni d’un serveur précis.
Le RC officiel décrit un passage d’un transport lié aux sessions vers une infrastructure HTTP plus ordinaire : les serveurs distants ne devraient plus exiger de sessions persistantes, de magasin de session partagé ni de routage par inspection profonde au niveau de la passerelle (Model Context Protocol blog). MCP Playground résume le nouveau modèle plus directement : pas de poignée de main initialize, pas d’attachement par Mcp-Session-Id, et des requêtes portant les en-têtes Mcp-Method et Mcp-Name pour permettre le routage sans lire le corps JSON-RPC (MCP Playground).
Cette nuance compte. L’Agentic AI Foundation explique que l’état devient visible par des identifiants, tandis que le trafic protocolaire devient plus simple à opérer derrière des répartiteurs de charge, des passerelles et des limites de débit (AAIF). Un serveur d’analyse de dépôt ne devrait donc pas supposer que « la même session connaît le dépôt ». Il doit émettre une référence, définir sa durée de vie, restreindre sa réutilisation et la rendre visible dans les traces.
Le risque ne se limite pas au code. Il touche l’infrastructure. Les tests de répartition doivent prouver que toute requête peut atteindre toute instance. Les passerelles doivent router sur les en-têtes, non sur l’analyse du corps. Les tests de redémarrage doivent montrer qu’un travail applicatif en cours survit à la disparition d’un processus serveur. Ce sont des contrôles classiques des systèmes distribués, mais ce protocole a permis de les différer pendant la phase prototype.
Notre présentation des services décrit cette approche : concevoir des systèmes IA autour de l’observabilité, de la gouvernance et de la discipline de mise en production, pas autour de démonstrations isolées. Cette préversion va dans le même sens en rendant visibles des hypothèses d’infrastructure qui restaient faciles à ignorer.
Extensions, Apps et Tasks clarifient le contrat optionnel
Le RC transforme des capacités optionnelles en extensions négociées, ce qui réduit les comportements sur mesure entre clients et serveurs.
Les mainteneurs placent Extensions, Apps et Tasks parmi les éléments centraux du candidat (Model Context Protocol blog). MCP.Directory résume la logique en cinq piliers : cœur sans état, exploitation par en-têtes et cache, Extensions/Apps/Tasks, durcissement de l’autorisation et JSON Schema 2020-12 (MCP.Directory).
MCP Apps compte parce que des interfaces rendues par le serveur peuvent faire partie de l’expérience outil, au lieu de vivre dans un canal parallèle. Tasks compte parce qu’un travail long ne devrait pas être maquillé en appel d’outil bloquant. Extensions compte parce qu’un client doit savoir sur quelle capacité il peut s’appuyer avant de l’invoquer.
Cela ne rend pas chaque extension sûre par nature. Cela rend le contrat plus vérifiable. Un serveur qui exécute des tâches devrait définir la propriété, l’annulation, la progression, la rétention et l’audit. Un serveur qui expose une surface applicative devrait clarifier l’isolation et le consentement. Un serveur qui annonce des extensions spécifiques devrait publier des notes de compatibilité et un comportement de repli.
Le guide de migration du SDK montre la même tendance au niveau de la bibliothèque. Il documente des changements incompatibles dans les retours du client HTTP streamable, l’interface dispatcher/serveur, le typage plus strict et le renommage de FastMCP (migration guide). Ces détails concernent Python, mais la leçon dépasse Python : le code qui utilisait ce protocole comme une simple couche de confort doit désormais traiter la frontière protocolaire comme un objet d’architecture.
Les équipes plateforme internes devraient gérer chaque intégration comme un produit maintenu : règle de version, mode de panne, note d’exploitation lisible. Ces extensions ne sont pas seulement de nouvelles capacités. Ce sont des engagements entre les clients, les serveurs et les personnes qui répondront aux incidents.
L’autorisation ne doit pas attendre
Le candidat du 28 juillet durcit les attentes d’autorisation au moment même où les serveurs compatibles touchent des outils et des données plus sensibles.
Le RC officiel indique que l’autorisation s’aligne davantage sur les déploiements OAuth et OpenID Connect (Model Context Protocol blog). Ce n’est pas un détail administratif. Un serveur relié au protocole se trouve souvent entre un client IA et des systèmes qui contiennent du code source, des tickets, des calendriers, des ressources cloud, des données clients ou des documents internes.
La chronologie des incidents liés au protocole mise à jour par AuthZed donne le contexte le moins confortable. Elle décrit des motifs récurrents : accès à des outils sensibles, séparation des locataires, serveurs malveillants, injection de prompt et limites d’autorisation trop faibles dans des systèmes reliés à ce standard (AuthZed). Même lorsque les cas précis se discutent, la conclusion de contrôle reste solide : ce standard crée une nouvelle interface, sans annuler les fondamentaux de sécurité.
GitHub, PyPI et les registres de paquets rendent l’alpha facile à récupérer. Cette facilité ne doit pas devenir un raccourci dans la chaîne d’approvisionnement. Il faut des versions verrouillées, des builds reproductibles, une revue des versions et un environnement de préproduction qui reflète les flux d’identité réels. Si un serveur compatible peut appeler une API destructrice, le plan de test doit inclure les permissions refusées et les identifiants révoqués, pas seulement l’appel réussi.
Le glossaire Model Context Protocol aide aussi les parties prenantes non spécialistes. Sans vocabulaire partagé sur clients, serveurs, outils, ressources, transports et autorisation, une migration proche de la production devient difficile à approuver proprement.
Liste de préparation avant le 28 juillet
Un bon plan de préparation vérifie la compatibilité protocolaire, les ruptures SDK, le routage, la sécurité et le retour arrière avant la date stable.
Commencez par l’inventaire. Listez chaque client, serveur, SDK, outil hébergé et connecteur interne. Classez chaque élément : production, préproduction, expérimentation ou inutilisé. Ajoutez la version du protocole, la version SDK, le transport, le modèle d’authentification et le responsable. Stacktree rappelle que la version finalisée actuelle reste 2025-11-25 pendant que le candidat 2026-07-28 est validé (Stacktree). Une période à versions mixtes est donc normale.
Ensuite, organisez la migration par cercles. Cercle 0 : serveur jetable épinglé sur l’alpha. Cercle 1 : flux de préproduction avec données non sensibles. Cercle 2 : chemin miroir proche de la production. Cercle 3 : production contrôlée après le SDK stable. Un poste de développeur ne suffit pas comme preuve.
Définissez aussi le retour arrière. Un bon plan nomme la version de retour, la rotation des secrets, l’invalidation des caches ou des identifiants, et les journaux qui prouvent que le retour a fonctionné. Il précise également quand ne pas avancer : serveur incapable de fonctionner sans sessions persistantes, propriété des tâches ambiguë, vérification d’émetteur OAuth incomplète.
Informez enfin les équipes produit et les clients. Un produit qui expose des serveurs compatibles hébergés doit publier une note de compatibilité avant la date cible. Si des agents internes dépendent de serveurs tiers, les responsables plateforme ou achats doivent savoir quels fournisseurs ont communiqué leur plan v2.
Le dernier point consiste à transformer cette migration en modèle de gouvernance réutilisable. Le prochain changement de protocole sera différent, mais les contrôles se ressembleront : versions figées, matrice de compatibilité, déploiement progressif, revue de sécurité, observabilité et retour arrière propre. Pour transformer des prototypes d’agents en systèmes de production, commencez par notre travail d’AI Agent Development ou apportez les questions d’architecture à Context Studios.
FAQ
La préversion v2 est-elle prête pour la production ?
Non. v1.x reste la ligne stable de production, tandis que v2.0.0a1 est une alpha volontaire avec des changements incompatibles attendus (PyPI JSON).
Quel est le changement principal du candidat du 28 juillet ?
Le protocole devient sans état au niveau protocolaire : plus de poignée de main, plus d’attachement de session, et un routage par en-têtes standard (official RC).
Que faut-il tester avant la v2 ?
Versions SDK exactes, répartition sans état, références d’état explicites, flux d’autorisation, annulation de tâches, journaux et retour de l’alpha vers v1.x (migration guide).
Le mode sans état empêche-t-il les agents de garder du contexte ?
Non. L’état applicatif reste possible, mais il doit passer par des identifiants ou références de tâche explicites, et non par des sessions cachées (AAIF).
Conclusion
Cette préversion est un excellent révélateur. Il montre quelles parties de l’infrastructure d’agents restent au stade prototype et lesquelles peuvent supporter la pression de la production. Les équipes gagnantes ne seront pas forcément celles qui migrent le plus vite, mais celles qui testent la frontière du protocole, verrouillent le chemin SDK, durcissent l’autorisation et donnent à chaque flux un retour arrière.
Si votre équipe construit des serveurs compatibles, des outils d’agents hébergés ou des workflows multi-agents, Context Studios peut transformer cette migration en plan d’architecture contrôlé plutôt qu’en surprise de calendrier. Commencez par notre AI Agent Development ou relisez notre analyse de l’écosystème du protocole avant la date de spécification du 28 juillet 2026.
Sources
- https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate
- https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.0.0a1
- https://pypi.org/pypi/mcp/2.0.0a1/json
- https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/README.v2.md
- https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/docs/migration.md
- https://aaif.io/blog/mcp-is-growing-up/
- https://mcp.directory/blog/mcp-2026-07-28-release-candidate
- https://stacktr.ee/blog/mcp-2026-spec-changes
- https://mcpplaygroundonline.com/blog/mcp-stateless-2026-release-candidate
- https://authzed.com/blog/timeline-mcp-breaches