La nouvelle spécification MCP du 28-07-2026 supprime toute exigence d'état de session, permettant à chaque requête de transporter toutes les données dont elle a besoin. Le passage à un protocole sans état (stateless) signifie que les développeurs peuvent lancer une instance unique par appel, l'exécuter sur des nœuds serverless ou edge, et abandonner la tuyauterie complexe de routage persistant (sticky routing) et de stockage partagé qui constituait un casse-tête en matière de déploiement.

Des handshakes aux appels autonomes

Jusqu'à présent, le Model Context Protocol (MCP) imposait un handshake qui générait un ID de session. Les serveurs devaient mémoriser cet ID pendant toute la durée de la connexion, ce qui, en pratique, signifiait maintenir des processus en vie, répliquer l'état sur un cluster Redis ou configurer des équilibreurs de charge pour un routage « persistant ». Le résultat était une pile complexe et gourmande en ressources qui pénalisait la mise à l'échelle et rendait la croissance horizontale coûteuse.

La nouvelle spécification rend chaque requête autonome. Chaque charge utile (payload) inclut la version du protocole et l'identité de l'appelant, de sorte que le serveur peut traiter la requête comme une transaction ponctuelle. Pas de magasin de session, pas de processus à longue durée de vie, pas de règles de routage spéciales.

Pourquoi l'absence d'état est cruciale pour le déploiement

  • Prêt pour le serverless et l'edge – Une requête transporte tout ce dont elle a besoin, une fonction peut donc démarrer, répondre et s'arrêter sans état de préchauffage (warm-up). Les fournisseurs facturant à l'invocation deviennent ainsi viables pour les charges de travail MCP.
  • Équilibrage de charge simplifié – Les équilibreurs de charge L4/L7 standards peuvent distribuer le trafic uniformément ; il n'est plus nécessaire de lier un client à un backend particulier.
  • Réduction de la charge opérationnelle – Les équipes peuvent supprimer les clusters Redis ou le code personnalisé de réplication de session, réduisant à la fois les coûts et la surface de défaillance.

Pour les organisations qui utilisent déjà MCP derrière un équilibreur de charge, ce changement élimine le besoin de règles de « sticky routing » qui imposent souvent une distribution inégale du trafic. Les économies sont particulièrement marquées pour les services à haut débit qui traitent des millions d'appels par jour.

Améliorations des performances et de la sécurité

La spécification ajoute des améliorations concrètes qui renforcent le protocole au-delà de son aspect stateless :

  • Mise en cache basée sur le TTL – Les listes d'outils (tools) et d'invites (prompts) incluent désormais un champ "time-to-live", permettant aux clients de mettre les résultats en cache localement et d'éviter des allers-retours inutiles.
  • Routage piloté par les en-têtes – De nouveaux en-têtes HTTP exposent les informations de routage précocement, permettant aux passerelles de transférer le trafic sans analyser l'intégralité du corps JSON, gagnant ainsi quelques millisecondes de latence.
  • Renforcement OAuth/OIDC – Les jetons d'identité sont soumis à des contrôles OAuth et OpenID Connect plus stricts, réduisant l'exposition aux attaques par rejeu et au vol de jetons.
  • Cadre d'extension formel – Les tâches et les applications appartiennent désormais à un modèle d'extension défini, ce qui facilitera le déploiement de futures fonctionnalités pour les mainteneurs de SDK.

Impact sur les développeurs

L'écosystème des SDK reflète déjà ce changement : les bibliothèques TypeScript, Python, Go et C# émettent le nouveau format de requête. Le nombre total de téléchargements de ces SDK approche le demi-milliard par mois, soit quatre fois plus qu'au début de l'année, ce qui indique l'ampleur de l'adoption de MCP.

Les développeurs doivent ajuster tout code qui supposait une session persistante. Généralement, cela signifie déplacer les données spécifiques à la session dans la charge utile de la requête ou dans un magasin externe consulté à chaque appel. La période de migration est de douze mois, ce qui laisse aux équipes le temps de refactoriser, tester et déployer le nouveau modèle.

Contrepoint : Complexité de la migration

L'absence d'état n'est pas une solution miracle. Les applications qui reposaient auparavant sur un état côté serveur pour des éléments tels que l'historique de conversation progressif doivent désormais gérer cet état côté client ou via une couche de persistance séparée.

À surveiller

  • Indicateurs d'adoption – Surveillez l'adoption des versions des SDK ; un ralentissement pourrait signaler des frictions lors de la migration.
  • Support des plateformes edge – À mesure que davantage de fournisseurs annoncent des environnements d'exécution compatibles avec MCP, le véritable avantage économique du serverless deviendra plus clair.
  • Rapports d'incidents de sécurité – Le flux OAuth/OIDC renforcé devrait réduire les attaques sur l'identité, mais toute faille testera la robustesse des nouvelles protections.

L'essentiel : En rendant MCP sans état, la spécification aligne le protocole sur les modèles cloud-native modernes, réduisant drastiquement la charge opérationnelle liée à la gestion des sessions tout en ouvrant la porte à des modèles de déploiement moins coûteux et plus élastiques. Le compromis réside dans une brève période de refactorisation du code et une empreinte de requête plus volumineuse, mais le bénéfice à long terme est un protocole qui s'adapte aussi facilement que l'infrastructure sur laquelle il s'exécute.