--- type: Blog Post title: "MCP v2 bêta : la migration vers le sans-état commence" description: "MCP v2 bêta apporte une architecture sans état. Ce qui casse, quels paquets SDK épingler et comment migrer avant la spécification du 28 juillet 2026." resource: "https://www.contextstudios.ai/fr/blog/mcp-v2-beta-migration-sans-etat" tags: [MCP, migration, SDK, architecture, agents IA] language: fr timestamp: "2026-07-02T07:33:58.891Z" --- # MCP v2 bêta : la migration vers le sans-état commence
Les premières versions bêta de Model Context Protocol v2 sont sorties fin juin 2026, et elles portent le plus grand changement d'architecture que le protocole ait jamais connu : MCP passe de sessions persistantes, dotées d'un état, à un modèle sans état fondé sur la requête et la réponse. Chaque serveur existant devra migrer avant l'entrée en vigueur de la spécification du 28 juillet 2026.
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
Le changement central de MCP v2 tient à ceci : le protocole devient sans état au niveau du transport, chaque requête se suffit à elle-même, si bien que n'importe quelle instance de serveur peut répondre à n'importe quelle requête sans session partagée.
En version 1, un client ouvrait une session persistante et bidirectionnelle, souvent un canal SSE, et le serveur émettait un identifiant de session que les requêtes suivantes devaient réutiliser. Cette conception supposait qu'un client reste rattaché à un même processus serveur pendant toute la durée de l'échange. 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
MCP v2 bêta désigne des paquets précis : le SDK Python paraît sous la forme mcp 2.0.0b1 sur PyPI, et le SDK TypeScript sous deux nouveaux noms de paquets en 2.0.0-beta.1, distincts du paquet v1 qui reste sur sa branche 1.x.
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
Ce qui casse le plus souvent lors d'une migration vers MCP v2, c'est l'infrastructure bâtie autour de l'affinité de session : répartiteurs de charge à routage persistant, clients rattachés à un canal SSE, et tout code qui stockait un état par session sur le serveur.
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
Traitez MCP v2 comme une planification de migration, non comme un guide définitif : les SDK sont des préversions, leurs interfaces peuvent encore évoluer avant la version stable du 28 juillet 2026, et le bon réflexe consiste à planifier et à prototyper dès maintenant plutôt qu'à livrer contre la bêta.
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
L'absence d'état rend les serveurs MCP nettement plus faciles à mettre à l'échelle et à exploiter : chaque instance peut servir chaque requête, si bien que la mise à l'échelle horizontale, des déploiements plus simples et une reprise sur erreur moins coûteuse vous sont pour ainsi dire offertes une fois la migration achevée.
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
Le 28 juillet 2026 est une échéance ferme, car c'est la date à laquelle la spécification MCP devient définitive et où les SDK stables v2 doivent paraître ; c'est aussi le moment où l'adoption s'accélère dans l'écosystème et où les hypothèses de la version 1 commencent à dater.
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 1. Model Context Protocol – version candidate du 28 juillet 2026 : https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate 2. Dépôt officiel du SDK Python : https://github.com/modelcontextprotocol/python-sdk 3. Dépôt officiel du SDK TypeScript : https://github.com/modelcontextprotocol/typescript-sdk 4. PyPI – paquet mcp : https://pypi.org/project/mcp/ 5. Dépôt officiel de la spécification MCP : https://github.com/modelcontextprotocol/modelcontextprotocol 6. Documentation officielle de MCP : https://modelcontextprotocol.io 7. Backslash Security – nouvelles surfaces d'attaque de la spécification MCP : https://www.backslash.security/blog/new-mcp-spec-opens-new-attack-surfaces 8. Préparer les prochaines mises à jour de MCP : https://www.linkedin.com/pulse/preparing-upcoming-updates-model-context-protocol-mcp-amit-singh-zziye 9. Agentic AI Foundation – MCP gagne en maturité : https://aaif.io/blog/mcp-is-growing-up 10. libraries.io – données de version de mcp : https://libraries.io/pypi/mcp