Si vous faites reposer quoi que ce soit sur MCP aujourd'hui, c'est le changement à préparer dès maintenant, et non une fois la spécification figée. Le SDK Python a atteint le stade bêta sous la forme mcp 2.0.0b1, et le SDK TypeScript sous des noms de paquets entièrement nouveaux (dépôt du SDK Python, dépôt du SDK TypeScript). Nous exploitons nous-mêmes un serveur MCP en production doté d'une large surface d'outils : cette migration figure donc sur notre propre feuille de route. Voici ce qui change concrètement, ce qui se casse au passage, et dans quel ordre mener le travail avant l'échéance.
Ce que « sans état » signifie vraiment pour MCP v2
MCP v2 abandonne cette hypothèse. MCP a été introduit par Anthropic comme un protocole doté d'un état et orienté session, une forme qui convenait bien à un client de bureau isolé, mais qui vieillit mal dès que l'on souhaite passer à l'échelle horizontalement. La version candidate officielle de la spécification décrit ce basculement vers le sans-état comme « le type de changement fondamental qui exigeait une rupture nette » (blog MCP). Les sessions, le routage persistant et les magasins de sessions partagés cessent d'être des éléments porteurs (guide de préparation). En clair, une requête porte tout ce dont le serveur a besoin, et le serveur ne conserve rien entre deux appels. Voilà l'essentiel, et chaque décision en aval en découle.
C'est la suite du fil que nous avions engagé à la sortie de l'alpha, à relire dans notre première analyse du changement de protocole du 28 juillet. Avec la bêta, la planification devient un travail inscrit à l'agenda.
Les versions vers lesquelles vous migrez réellement
Du côté de Python, PyPI héberge désormais mcp 2.0.0b1 comme préversion facultative, tandis que la branche stable v1 se situe en 1.28.x (PyPI mcp). Le dépôt précise que v2 constitue « une refonte majeure du SDK », à la fois pour prendre en charge la spécification du 28 juillet 2026 et pour corriger des problèmes d'architecture anciens, la version stable v2 étant visée pour le 27 juillet 2026 (dépôt du SDK Python).
Côté TypeScript, un piège mérite d'être signalé clairement. v2 ne paraît pas comme une nouvelle version de @modelcontextprotocol/sdk. Sur npm, il paraît sous la forme de deux paquets entièrement nouveaux, @modelcontextprotocol/server et @modelcontextprotocol/client, tous deux en 2.0.0-beta.1, tandis que l'ancien paquet demeure en v1 (dépôt du SDK TypeScript). Si votre plan de mise à jour se résume à « relever le numéro de version », vous manquerez entièrement la migration. Il s'agit d'un changement de nom de paquet, pas d'un simple saut de version. Les analyseurs de dépendances qui ne surveillent que @modelcontextprotocol/sdk vous déclareront à jour, alors que vous accusez en réalité une version majeure de retard. Qui évalue l'effort que justifie le changement d'une dépendance gagnera à lire ce point en regard de notre réflexion sur le coût d'opportunité de la puissance de calcul.
Ce qui casse, en pratique
La démonstration la plus nette passe par un test de répartiteur de charge : pointez un client v1 doté d'un état vers un proxy inverse qui répartit les requêtes à tour de rôle entre deux instances de serveur ; le client ouvre une session sur l'instance A, puis sa requête de suivi atterrit sur l'instance B, qui ignore tout de cette session (analyse du sans-session). En version 1, on masquait ce défaut par un routage persistant. En version 2, le problème disparaît, faute de session à laisser en rade, mais seulement une fois retiré le code qui en attendait une.
Concrètement, prévoyez d'intervenir sur quatre points : la configuration du transport, où l'on abandonne l'hypothèse d'une session SSE persistante ; tout magasin de sessions côté serveur ; les règles de routage persistant dans votre répartiteur de charge ou votre passerelle ; et la logique de reconnexion du client, qui présupposait un canal permanent. S'y ajoute une dimension de sécurité : selon une analyse, la nouvelle spécification ouvre trois nouvelles surfaces d'attaque, la fenêtre de validation étant ouverte depuis le 21 mai (Backslash Security). L'absence d'état déplace les décisions de confiance vers chaque requête, de sorte que l'autorisation par requête compte plus qu'auparavant. Si vous n'avez pas passé en revue votre surface d'outils depuis un moment, associez cette migration à un véritable audit de vos outils et compétences ainsi qu'à la liste de contrôle de durcissement de la chaîne d'approvisionnement.
Comment cadencer la migration avant le 28 juillet
Un ordre de travail cohérent tient en quatre temps. Recensez d'abord chaque endroit où votre pile suppose une session MCP persistante, car cet inventaire est le vrai livrable du mois. Épinglez ensuite la bêta de façon explicite dans une branche (mcp==2.0.0b1 pour Python ; les nouveaux paquets @modelcontextprotocol/server et /client pour TypeScript) et montez un serveur prototype, sans toucher à la production. Vérifiez en troisième lieu, à l'aide du test de répartiteur décrit plus haut, que vos requêtes survivent à une répartition entre plusieurs instances. Déplacez enfin l'autorisation par requête dans le chemin de la requête.
À quoi ressemble cet inventaire, au juste ? Parcourez votre code et votre infrastructure à la recherche de quelques signes révélateurs : toute référence à un identifiant de session stocké ou réutilisé, tout point d'accès SSE ouvert par votre transport MCP, toute règle de répartiteur qui rattache un client à un serveur, et toute hypothèse selon laquelle deux appels d'outils consécutifs touchent le même processus. Chaque occurrence devient une ligne de votre plan de migration. La plupart des équipes s'étonnent de constater à quel point cela vit dans la configuration de l'infrastructure plutôt que dans le code applicatif, car c'est dans le répartiteur de charge et la passerelle que s'accumulent discrètement les hypothèses liées à l'état, et c'est précisément pourquoi un inventaire vaut mieux qu'une réécriture à l'aveugle.
Comme il s'agit de préversions facultatives, les responsables de la spécification indiquent explicitement que les interfaces peuvent encore bouger avant la disponibilité générale (données de version libraries.io). Considérez la bêta comme une répétition générale. Les signes de maturité sont encourageants, car l'écosystème vit ce moment comme celui où MCP « gagne en maturité », avec un vrai travail de conformité et de gouvernance neutre (AAIF), mais la rigueur d'une répétition reste de mise. Gardez une solution de repli en v1 jusqu'à la sortie des SDK stables, de la même manière qu'une posture indépendante du modèle vous protège si une dépendance unique venait à déraper.
Le gain, une fois le travail accompli
Il faut le dire clairement : cette migration se rembourse. Un serveur doté d'un état devient un fardeau sous charge, car il réclame un routage persistant, un magasin de sessions partagé et une gestion minutieuse des reconnexions, et chacun de ces éléments peut défaillir de son côté. Un serveur sans état supprime toute cette catégorie de problèmes. Vous pouvez descendre à zéro puis remonter, remplacer des instances pendant un déploiement sans vider les sessions, et placer un simple répartiteur à tour de rôle devant votre parc de serveurs. Pour qui exploite des charges d'agents à grande échelle, cette simplicité d'exploitation est le vrai gain, bien au-delà de la seule conformité à la spécification.
Chez Context Studios, nous traitons la disponibilité comme un axe de conception de premier plan, au même titre que la capacité et le coût, et un transport sans état est justement le type de changement qui améliore les trois à la fois. Moins de pièces mobiles, c'est moins de modes de défaillance, et moins de modes de défaillance, c'est une pile d'agents à laquelle vous pouvez réellement vous fier en production. Le coût de la migration est réel, mais c'est un coût ponctuel qui réduit un risque d'exploitation récurrent, et c'est le meilleur marché qu'une équipe puisse conclure.
Pourquoi le calendrier n'est pas négociable
La spécification et les SDK stables sont espacés d'un jour à peine : la spécification le 28 juillet 2026, la version stable Python v2 visée pour le 27 juillet 2026 (dépôt du SDK Python). Dès que les SDK de premier rang livrent la prise en charge, l'adoption se renforce d'elle-même, et les serveurs qui continuent de présumer des sessions dotées d'un état se retrouvent de plus en plus à contre-courant (documentation officielle de MCP). Le dépôt officiel de la spécification reste la source de référence à surveiller à l'approche de la date (dépôt de la spécification MCP).
Ce sont, au bout du compte, les équipes qui ont fait leur inventaire en juillet, prototypé contre la bêta et basculé la semaine de la sortie des SDK stables qui prendront de l'avance, et non celles qui découvriront le changement de nom de paquet en août.
Questions fréquentes
MCP v2 est-il disponible dès maintenant ?
Oui, sous forme de préversions bêta. Le SDK Python est mcp 2.0.0b1 sur PyPI et le SDK TypeScript est en 2.0.0-beta.1 sous de nouveaux noms de paquets. Les deux sont facultatifs ; la version stable v2 est visée pour le 27 juillet 2026 (dépôt du SDK Python).
Quel est le plus grand changement de MCP v2 ? Le protocole devient sans état : les requêtes se suffisent à elles-mêmes et n'importe quelle instance de serveur peut traiter n'importe quelle requête, ce qui remplace le modèle persistant et rattaché à une session de la version 1 (blog MCP).
Dois-je migrer mon serveur MCP moi-même ? À terme, oui, car tout serveur doté d'un état devra migrer. Vous n'avez pas à le faire aujourd'hui, mais les semaines qui précèdent le 28 juillet 2026 sont le bon moment pour recenser les hypothèses de session et prototyper (Backslash Security).
Pourquoi le nom du paquet TypeScript a-t-il changé ?
v2 paraît sous @modelcontextprotocol/server et @modelcontextprotocol/client plutôt que comme une nouvelle version du paquet v1 @modelcontextprotocol/sdk, si bien qu'un simple saut de version ne vous met pas à jour (dépôt du SDK TypeScript).
En résumé
La migration sans état de MCP v2 fait partie de ces rares changements de rupture qui simplifient votre infrastructure une fois menés à terme : plus de sessions persistantes, plus de magasins de sessions partagés, chaque instance répondant à chaque requête. Mais ce « plus simple ensuite » ne se produit que si vous réalisez l'inventaire avant l'entrée en vigueur de la spécification, le 28 juillet 2026. Cartographiez vos hypothèses de session, prototypez contre la bêta et gardez une solution de repli en v1 jusqu'à la sortie des SDK stables.
Si vous souhaitez un second regard sur votre plan de migration MCP, ou un serveur prêt pour la production conforme à la spécification du 28 juillet 2026, c'est précisément notre métier.
Sources
- Model Context Protocol – version candidate du 28 juillet 2026 : https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate
- Dépôt officiel du SDK Python : https://github.com/modelcontextprotocol/python-sdk
- Dépôt officiel du SDK TypeScript : https://github.com/modelcontextprotocol/typescript-sdk
- PyPI – paquet mcp : https://pypi.org/project/mcp/
- Dépôt officiel de la spécification MCP : https://github.com/modelcontextprotocol/modelcontextprotocol
- Documentation officielle de MCP : https://modelcontextprotocol.io
- Backslash Security – nouvelles surfaces d'attaque de la spécification MCP : https://www.backslash.security/blog/new-mcp-spec-opens-new-attack-surfaces
- Préparer les prochaines mises à jour de MCP : https://www.linkedin.com/pulse/preparing-upcoming-updates-model-context-protocol-mcp-amit-singh-zziye
- Agentic AI Foundation – MCP gagne en maturité : https://aaif.io/blog/mcp-is-growing-up
- libraries.io – données de version de mcp : https://libraries.io/pypi/mcp