8 min de lecture - Migration MCP sans session : explicitez l’état et sécurisez les reprises

Le 1er septembre 2026, AWS a publié un nouveau guide d’architecture consacré au Model Context Protocol sans session. Le billet traduit la révision MCP 2026-07-28 en décisions de déploiement : retirer l’affinité de routage et les magasins de session lorsque les anciens clients ont disparu, permettre à chaque instance de répondre et rendre les outils sûrs en cas de nouvelle tentative.

Le conseil est utile, mais l’expression « sans état » peut pousser à un mauvais raccourci. Une équipe risque de voir l’infrastructure qu’elle peut supprimer avant d’identifier ce que l’ancienne session transportait. La publication officielle de MCP est précise : MCP a supprimé les sessions au niveau du protocole. Il n’a pas retiré l’état des processus métier, des validations ni des traitements longs.

Pour une startup ou une PME qui exploite ses serveurs MCP, la question devient « Chaque requête peut-elle atteindre une autre instance sans perdre son contexte, répéter une action ou franchir la frontière d’un locataire ? » Les économies d’infrastructure viennent après cette preuve.

Un protocole sans session pour un travail qui garde un état

La révision 2026-07-28 retire l’échange initialize et initialized, ainsi que l’en-tête Mcp-Session-Id. Chaque requête transporte la version du protocole et les capacités du client. Les serveurs exposent une méthode server/discover, même si le client n’est pas obligé de l’appeler avant une requête d’outil. Le journal des changements de la spécification précise aussi que les listes ne varient plus selon la connexion.

Ces changements séparent la continuité du transport de celle de l’application. Un devis peut garder un identifiant de brouillon, un dossier d’assistance son numéro et un export son identifiant de traitement. Le serveur crée une référence explicite que le client ou le modèle renvoie comme argument d’outil.

Un modèle peut répéter, modifier ou substituer cet identifiant. Chaque outil doit donc le résoudre dans le contexte de l’utilisateur, du locataire et des autorisations en cours. Une référence reste une entrée non fiable, jamais une preuve de propriété.

Notre guide sur les permissions MCP et l’accès sûr aux outils traite la confiance accordée au serveur. La migration ajoute un contrôle précis : tout état auparavant lié implicitement à une session doit recevoir un propriétaire et une règle de validation explicites.

Inventoriez ce que la session masquait

Suivez d’abord un processus réel sur plusieurs appels et notez les informations que les appels suivants supposent connues. Distinguez les dossiers métier durables des données de reprise courtes, car ils n’ont pas les mêmes règles de conservation et d’accès.

Ce tableau est un support Exceev, pas une structure imposée par MCP. Si l’équipe ne sait pas où une information résidera, elle ne doit pas retirer l’ancien parcours.

N’insérez pas un dossier complet dans un jeton pour éviter une base de données. Les jetons peuvent atteindre les modèles, clients, journaux et traces. Utilisez une référence opaque pour le durable. Pour une reprise courte, la spécification emploie requestState ; AWS demande de traiter ce jeton comme non fiable et de protéger son intégrité par HMAC ou chiffrement authentifié.

Faites cohabiter deux générations du protocole

Mettre à jour un SDK ne prouve pas que le trafic emploie la nouvelle révision. Le guide officiel de migration du SDK TypeScript indique que les clients et serveurs v2 assemblés directement conservent par défaut le comportement réseau de 2025. L’utilisation de 2026-07-28 demande une activation explicite.

Le mode automatique sonde server/discover, puis revient à l’ancien protocole s’il reconnaît un pair ancien. Une erreur d’authentification, une panne serveur ou un délai HTTP reste une panne, jamais une preuve de version.

Prévoyez une période à deux générations. Journalisez la version par requête et séparez trafic moderne, trafic ancien, échecs de négociation et refus d’authentification. Testez les couples nouveaux et anciens ainsi que leur passage par la passerelle de production.

Conservez l’affinité et le magasin tant qu’un client pris en charge en dépend, comme le recommande AWS. Fondez leur retrait sur le trafic observé et les engagements d’assistance. Une date seule ne suffit pas.

Concevez les reprises autour de l’effet métier

Le changement de transport modifie aussi la reprise. AWS explique qu’une réponse interrompue peut conduire le client à renvoyer un appel. Les outils d’écriture doivent donc être idempotents. Rejouer une lecture cause rarement un problème ; rejouer create_invoice, send_message ou approve_order peut produire un second effet.

Attribuez une clé d’idempotence à chaque opération et enregistrez-la avec son résultat avant de renvoyer le succès. La même clé et les mêmes arguments doivent retourner le résultat enregistré. Si les arguments diffèrent, refusez la réutilisation au lieu de deviner.

Une trace suit l’exécution, un identifiant JSON-RPC associe réponse et requête, et la clé d’idempotence empêche le double effet métier. Leur unicité pendant un test ne les rend pas interchangeables.

Testez le cas où la cible accepte l’action sans que le client MCP reçoive la réponse. Coupez la connexion, renvoyez l’appel par une autre instance et inspectez les deux systèmes. Une simulation unitaire ne suffit pas.

Reconstruisez les preuves à l’échelle de la requête

Pour chaque appel, enregistrez la version, l’identité, le locataire, l’outil, le type de résultat, la clé métier et la trace. Excluez des journaux généraux les secrets, jetons complets et arguments sensibles.

Le nouveau transport Streamable HTTP impose les en-têtes MCP-Protocol-Version, Mcp-Method et, pour les opérations nommées, Mcp-Name. La spécification du transport exige aussi que l’en-tête de version corresponde à la version inscrite dans le corps de la requête. Ces champs alimentent routage et mesures sans analyser les arguments, mais ils ne prouvent pas l’action métier obtenue.

Reliez la trace au dossier durable de l’opération. Les équipes peuvent alors passer de « l’agent a appelé un outil » à « la commande a changé une fois sous cette identité ». Notre article sur la trace d’audit minimale d’un agent détaille les preuves utiles pour une action autonome.

Une répétition de migration pour une petite équipe

Choisissez un processus réversible ou isolé. Relevez le parcours de session, les versions de client, chaque magasin et règle de routage. Exposez ensuite un serveur à deux générations et mesurez la négociation réelle.

Placez l’état dans des dossiers explicites ou des jetons protégés. Alternez les instances, redémarrez-en une, puis testez une référence d’un autre locataire, une référence expirée et un requestState modifié. L’échec ne doit pas révéler l’existence du dossier.

Interrompez une écriture après son acceptation, rejouez-la ailleurs et vérifiez qu’un seul effet subsiste. Reliez les tentatives à la même opération sans exposer le jeton.

Désactivez l’affinité et supprimez le magasin de session lorsque le trafic ancien atteint la condition convenue. Surveillez erreurs, latence et doublons, puis gardez le retour arrière pendant la période d’observation.

Sources et limites

• La note de publication 2026-07-28 des mainteneurs MCP, consultée le 2 septembre 2026, établit la suppression des sessions du protocole, les changements d’initialisation et le modèle d’identifiant explicite.
• Le journal officiel de la spécification MCP, consulté le 2 septembre 2026, fournit la liste normative des changements concernant les sessions, la découverte et les échanges en plusieurs allers-retours.
• Le guide officiel de migration du SDK TypeScript, consulté le 2 septembre 2026, documente l’activation explicite, la négociation et les comportements d’échec de ce SDK. Les autres SDK peuvent différer.
• Le guide d’architecture AWS du 1er septembre, consulté le 2 septembre 2026, relie séparément la révision à l’architecture déployée, à la compatibilité, aux reprises et à l’exploitation.

La révision MCP date du 28 juillet ; le déclencheur actuel est l’analyse de déploiement publiée par AWS le 1er septembre. Les sources ne mesurent ni le coût, ni les performances, ni la fiabilité de la migration sur un échantillon représentatif de systèmes de PME. Un hébergeur MCP peut gérer différemment la compatibilité ou l’état applicatif. L’inventaire, les tests et les conditions de retrait proposés ici constituent la synthèse opérationnelle d’Exceev, pas une norme de migration MCP ou AWS. Vérifiez-les avec vos SDK, votre hébergement, vos obligations sur les données et votre processus de changement.

Retirez l’infrastructure lorsque les preuves existent

Un protocole sans session peut simplifier la mise à l’échelle et la reprise. Gardez l’état explicite, contrôlez chaque identifiant, sécurisez les reprises d’écriture et observez les versions en production. Retirez seulement l’infrastructure qu’aucun parcours pris en charge n’utilise.