MCP grandit : ce que les équipes de production doivent prévoir avec la nouvelle spécification
Comment la révision du protocole de contexte de modèle du 28-07-2026 modifie l’échelle, les tâches, l’autorisation et le cache, ainsi que la manière de migrer un serveur existant en étapes sûres.
Sources: **MCP Grows Up: Six Changes Production Teams Need to Plan For**
Une mise à jour plus importante qu’une simple version
D’après l’annonce de publication du projet, le Model Context Protocol a connu sa plus grande mise à jour depuis son lancement le 28 juillet 2026. La spécification supprime les sessions de protocole, formalise les extensions, ajoute un mécanisme de travail asynchrone durable, renforce les mécanismes d’autorisation et fournit aux implémentateurs une véritable politique de dépréciation. La version candidate avait été figée depuis le 21 mai, ce qui a donné aux mainteneurs des SDK, aux développeurs de clients et aux opérateurs de serveurs environ dix semaines pour tester la nouvelle conception.
Dans son ensemble, le document final propose un noyau sans état, des requêtes en plusieurs allers-retours, un routage par en-tête, des fonctionnalités de découverte et de liste pouvant être mémorisées en cache, un cadre d’extensions, des tâches, des applications MCP, des mécanismes d’autorisation plus stricts, ainsi qu’un processus fiable pour retirer progressivement certaines fonctionnalités.
« MCP sans état » est un bon titre, mais la liste des modifications est plus longue que cela. Plusieurs détails perturbateurs se cachent en dessous. Les résultats disposent désormais d’un champ resultType. Le flux HTTP GET a été supprimé. subscriptions/listen remplace les anciens styles de souscription. Les flux SSE perdent la possibilité de reprise grâce à Last-Event-ID. Les résultats de liste et de ressources doivent inclure des indications de cache. Les schémas d’outils peuvent utiliser l’ensemble des spécifications JSON Schema 2020-12. Enfin, une ressource manquante génère désormais le code JSON-RPC standard -32602 au lieu de -32002 auparavant.
Considérer cela comme une simple mise à jour de la dépendance et un redéploiement serait une erreur. Il s’agit d’une migration architecturale.
1. Un protocole sans état ne rend pas l’application sans état
Les versions antérieures établissaient le contexte grâce à une séquence d’échange initialize/initialized. Pour les serveurs HTTP distants, le serveur pouvait également fournir un Mcp-Session-Id que le client réutilisait dans les demandes ultérieures. Cela liait un client à une seule session de serveur, et les déploiements réels utilisaient fréquemment un routage « sticky » au niveau du balanceur de charge, un stockage de sessions partagé, ou les deux à la fois.
Dans la version 2026-07-28, cette séquence d’échange ainsi que la session protocolaire disparaissent. Chaque demande contient sa propre version du protocole, les capacités du client et, facultativement, son identité, dans le champ _meta. Les serveurs doivent implémenter la fonction server/discover, bien que les clients n’aient pas besoin de l’appeler avant chaque opération. Un client peut plutôt indiquer sa version préférée et réessayer en cas de retour d’erreur UnsupportedProtocolVersionError.
Par l’intermédiaire de Streamable HTTP, une requête en cours transporte des métadonnées comme ceci :
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
La même version, méthode et nom apparaissent également dans le corps JSON-RPC. Le corps reste la source d’autorité, et les serveurs doivent rejeter toute incohérence entre les en-têtes et le corps. Cela empêche un gateway d’approuver ou de router une opération tandis que le serveur exécute une autre.
« Stateless » ne signifie pas « ne rien stocker »
La spécification ne supprime pas l’état de l’application ; elle cesse simplement de le cacher. Lorsqu’un serveur a besoin de continuité d’une appel à l’autre, il doit créer un identifiant de domaine, par exemple workspace_id, browser_id, basket_id, analysis_run_id ou deployment_id. Le client ou le modèle fournit ensuite cet identifiant en tant qu’argument normal dans les appels ultérieurs :
create_workspace()
→ { "workspace_id": "ws_7f3..." }
add_file(workspace_id="ws_7f3...", ...)
→ ...
run_analysis(workspace_id="ws_7f3...")
→ ...
Cela est plus propre que l’état de transport caché, mais cela impose de nouvelles responsabilités à l’application. Elle doit gérer les vérifications de propriété, l’isolation des utilisateurs, l’expiration, les règles de conservation, l’autorisation ainsi que la protection contre les tentatives de devinette ou de répétition. Les workflows persistants peuvent encore avoir besoin d’une base de données ou d’un cache distribué, et les tâches à long terme nécessitent par définition un stockage durable. L’infrastructure peut être sans état tandis que le produit reste à état.
2. Où l’absence d’état est réellement avantageuse
Échelle horizontale simple
Lorsqu’une requête contient tout son propre contexte, le serveur peut être placé derrière un équilibreur de charge classique de type round-robin. Sur Kubernetes, une Deployment et un Service ordinaires suffisent généralement, sans annotations de fidélité de session ni StatefulSet spécifiquement conçus pour gérer les sessions MCP. Les avantages de l’auto-échellement sont particulièrement importants : un pod ne doit pas reconstruire les sessions de protocole avant d’accepter du trafic, et un pod remplacé lors d’une mise à jour progressive ne laisse pas les clients bloqués sur une session inutilisable.
Il existe cependant un bémol : si une application gère des objets tels que des handles ou des tâches, ces objets restent stockés dans un stockage externe durable afin de survivre à la perte d’un processus ou d’un pod.
Encadrement du routage et des politiques au niveau du gateway
Puisque Mcp-Method et Mcp-Name sont de simples en-têtes, un gateway peut router, mesurer et appliquer des politiques sans avoir à analyser le corps d’un JSON. Dans un service multi-locataires qui permet l’instauration de quotas distincts pour tools/list, les outils de recherche coûteux, les outils de déploiement et tout élément destructeur :
tools/list → high request allowance
tools/call + search → standard allowance
tools/call + deploy_prod → lower rate limit and stronger policy
resources/read → data-volume quota
Un gateway ne doit jamais non plus lire clientInfo comme preuve de l’identité de l’appelant. Ce champ est auto-déclaré et existe uniquement à des fins d’affichage, de débogage et d’enregistrement. L’identité du client doit être déterminée à partir d’un jeton validé ou d’une autre source fiable.
Cachage
Les réponses aux requêtes resources/read, resources/templates/list, resources/list, prompts/list, tools/list et server/discover comportent deux nouveaux champs : ttlMs et cacheScope. Le premier indique le degré de fraîcheur des données, et non l’intervalle de sondage. Le second précise si le résultat est public ou privé. Tout ce qui varie en fonction de l’utilisateur, du client, du périmètre ou des autorisations ne doit pas être traité comme des données publiques partagées, et les notifications de modification peuvent rendre invalide un résultat qui serait sinon encore à jour.
Le cache réduit les demandes répétées de catalogues d’outils et stabilise les entrées de prompts de modèles. Un champ de portée mal choisi ouvre également la voie à de nouveaux types de bugs liés à la correction et à la confidentialité.
Observabilité
Les documents de spécification décrivent la propagation du contexte de suivi W3C via les clés _meta traceparent, tracestate et baggage. Un hôte, un client MCP, une passerelle, un serveur et un service en aval partagent ainsi un moyen de relier les appels d’outils tout au long du chemin d’exécution. Le contexte de suivi facilite cette corrélation, mais il ne constitue ni mécanisme d’autorisation ni garantie d’intégrité ; les données sensibles, les tokens, les prompts bruts et les informations personnelles n’ont pas leur place dans le champ baggage.
3. Les extensions deviennent un concept de première classe
Chaque extension dispose désormais d’un identifiant, de règles de négociation, de responsables désignés, de son propre répertoire ainsi que de son propre cycle de publication. Les clients déclarent les extensions qu’ils gèrent dans les capacités envoyées avec chaque requête, tandis que les serveurs annoncent les leurs via server/discover. Une extension n’entre en vigueur que lorsque les deux parties la prennent en charge ; si l’autre partie ne la possède pas, l’implémentation doit revenir à un comportement de base ou répondre avec une erreur appropriée.
C’est une étape importante pour l’évolution du protocole, car les fonctionnalités n’ont plus besoin d’attendre une version complète du noyau. Cela permet également de créer une matrice de compatibilité. Un serveur ne peut pas supposer que tous les hôtes prennent en charge les tâches, les applications MCP, l’autorisation gérée par l’entreprise ou toute extension future, ce qui oblige le code de production à disposer de mécanismes de fallback explicites :
- Un outil qui prend en charge les tâches propose également une voie synchrone pour les clients qui ne publient pas de tâches, ou renvoie une erreur claire indiquant l’absence de prise en charge de cette fonctionnalité.
- Un outil basé sur une application MCP renvoie du contenu structuré ou textuel utile lorsque l’hôte ne peut pas afficher son interface.
- L’autorisation d’entreprise n’est utilisée que lorsque la politique de l’organisation le permet.
- Les champs spécifiques aux extensions ne sont jamais envoyés à un client qui ne les a pas négociés.
Les extensions assouplissent le couplage avec la spécification principale, ce qui augmente le risque de fragmentation de l’écosystème.
4. Les tâches rendent les outils à exécution prolongée durables
Les tâches quittent le noyau expérimental pour intégrer une extension officielle, io.modelcontextprotocol/tasks. Si le client indique qu’il prend en charge les tâches, le serveur peut répondre par une opération ordinaire en utilisant un identifiant de tâche à la place du résultat final. Le client utilise ensuite tasks/get pour lire l’état actuel, tasks/update pour fournir les données demandées et tasks/cancel pour demander l’annulation.
Une tâche passe par les états working, input_required, completed, failed et cancelled. Le serveur doit conserver une trace de la tâche avant de lui restituer son identifiant. L’annulation est basée sur une coopération, de sorte qu’une demande confirmée ne garantit pas que le travail en cours s’arrête immédiatement.
Les candidats naturels sont des ensembles de tests, des pipelines de construction, des générateurs de code, des déploiements cloud, des importations de données, du traitement de documents, des étapes attendant l’approbation humaine, des tâches par lots ainsi que des enveloppes simplifiées autour d’une API de tâches externe. Ce que l’on obtient réellement, ce n’est pas l’exécution asynchrone en tant que telle, mais la capacité de se remettre en marche : un client peut s’arrêter, redémarrer et continuer à effectuer des requêtes en utilisant le même identifiant de tâche.
Ce qu’un serveur de production doit ajouter
Les tâches nécessitent bien plus qu’un thread en arrière-plan :
- un répertoire de tâches durable
- une vérification d’autorisation chaque fois que
tasks/get,tasks/updateoutasks/cancelest appelé - l’isolation entre propriétaires et utilisateurs
- la validation des transitions de statut
- la conservation des résultats et des erreurs
- l’application des délais de validité et le nettoyage
- des limites sur le taux de requêtes
- la propagation des annulations
Considérez l’ID d’une tâche comme un identifiant de ressource, et non comme un secret. Le fait de détenir cet ID ne doit jamais suffire à autoriser quoi que ce soit.
5. Les demandes multi-allers-retours remplacent les requêtes initiées par le serveur
Un serveur sans état ne peut pas compter sur une connexion bidirectionnelle persistante pour poser des questions au client à volonté. Les demandes multi-allers-retours (MRTR) prennent alors le relais. Lorsqu’un serveur a besoin de confirmation, d’informations, d’échantillons ou d’autres données fournies par le client, il renvoie un InputRequiredResult. Le client collecte ces données et réessaie l’opération initiale en utilisant les inputResponses, ainsi que le requestState si celui-ci est fourni.
Prenons un outil destructeur comme exemple :
delete_resources(resource_ids=[...])
Plutôt que d’ouvrir une demande inverse sur un flux existant, le serveur répond :
input_required:
"Confirm deletion of 53 resources"
Le client reçoit une confirmation et réitère l’appel initial. La tentative de réessai est autonome, ce qui fonctionne quel que soit l’instance, mais cela signifie également que les serveurs doivent être conçus pour gérer les réessais.
Règles pour MRTR en production
- Ne réalisez aucune action irréversible tant que tous les éléments d’entrée requis ne sont pas disponibles.
- Rendez les tentatives de réessai idempotentes.
- Associez
requestStateà l’opération spécifique ainsi qu’au client qui l’a initiée. - Expiration des états de demande anciens.
- Rejetez les réponses faisant référence à des clés que le serveur n’a jamais demandées ou qu’il a déjà reçues.
- Fixez un plafond au nombre de tours autorisés afin d’éviter la formation de boucles.
- Autorisez à nouveau l’exécution de l’opération à chaque tentative de réessai.
- N’assumez jamais que le réessai se fera sur la même instance.
Lorsque le flux de travail est sensible, faites en sorte que requestState soit soit un identifiant aléatoire opaque avec les données réelles stockées sur le serveur, soit une valeur contenant un code d’authentification de message afin que toute modification soit détectée.
6. Les applications MCP modifient le produit, pas seulement le protocole
Les applications MCP permettent à un serveur de lier un outil à une interface HTML interactive. Les hôtes compatibles le rendent visible à l’intérieur d’un iframe isolé. L’application communique avec l’hôte via JSON-RPC en utilisant postMessage, et l’hôte contrôle quels fonctionnalités et outils l’application peut utiliser. Cela permet de créer des formulaires, des tableaux de bord, des dialogues de confirmation, des lecteurs de médias, des outils de configuration de déploiement, des écrans de tri et d’autres expériences difficiles à exprimer sous forme de texte.
Pour une startup, cela peut changer la logique économique du MVP : un flux de travail conversationnel interactif sans avoir à créer au préalable une interface d’application distincte ni une couche d’intégration. Cependant, l’ingénierie frontend ne disparaît pas pour autant. Les équipes restent responsables de la conception d’une interface accessible, de la gestion de l’état, de la configuration CSP, du code exécuté dans le sandbox, de la validation des entrées, de la négociation des capacités du hôte, du traitement sécurisé des appels d’outils, des tests de compatibilité entre différents clients, ainsi que d’une solution de secours pour les hôtes ne disposant pas de prise en charge des applications. Comme les applications constituent une extension optionnelle, la prise en charge par les hôtes varie, de sorte qu’un serveur doit renvoyer du contenu structuré et significatif même lorsque l’affichage n’est pas possible.
7. L’autorisation devient plus stricte et plus difficile
Conformément aux règles d’autorisation HTTP, un serveur MCP protégé agit en tant que serveur de ressources OAuth et le client MCP en tant que client OAuth. Cette version s’inspire de parties sélectionnées de OAuth 2.1 ainsi que de normes voisines. Les serveurs doivent publier des métadonnées de ressources protégées afin que les clients puissent les trouver, et les métadonnées des serveurs d’autorisation OAuth ainsi que celles d’OpenID Connect sont acceptées. Le PKCE est obligatoire, tout comme les indicateurs de ressource dans les demandes d’autorisation et de jeton, et les vérifications d’émetteur sont plus strictes. Les règles principales sont les suivantes :
- Les clients envoient un paramètre
resourceindiquant le serveur MCP cible. - Un serveur vérifie que le jeton qu’il reçoit a été émis pour son propre public cible.
- Les serveurs d’autorisation doivent inclure l’attribut
iss, et les clients vérifient l’émetteur lorsqu’il est présent avant d’échanger le code d’autorisation.
Authorization et jamais dans une chaîne de requête.S256.Les indicateurs de ressource restreignent le public cible d’un token. Ils ne doivent pas être décrits comme une liaison de token cryptographique.
L’identité d’entreprise est une question distincte
L’autorisation de base MCP couvre le flux OAuth standard délégué par l’utilisateur. La politique d’accès corporatif centralisée provient de l’extension optionnelle Enterprise-Managed Authorization, qui permet au fournisseur d’identité d’une organisation de gérer l’accès aux serveurs MCP, en prenant en charge l’intégration des nouveaux utilisateurs, le retrait des anciens, l’accès conditionnel et son application. Le client, le système d’autorisation du serveur ainsi que l’environnement d’identité de l’entreprise doivent tous le prendre en charge. Pour une analyse de sécurité, l’architecture est structurée comme suit :
Core authorization
OAuth flow
issuer validation
resource/audience validation
scopes and step-up
Protected Resource Metadata
Optional enterprise extension
corporate IdP policy
SSO
centralized approval and revocation
identity-assertion exchange
La spécification précise l’architecture sans rendre l’OAuth opérationnellement simple. La récupération des métadonnées du client soulève des problèmes de SSRF et de politique de confiance. Les jetons et les identifiants de renouvellement nécessitent un stockage sécurisé. Les déploiements avec plusieurs émetteurs exigent une inscription séparée ainsi qu’un suivi distinct des jetons. Les métadonnées, les URI de redirection, les scopes et les identifiants de ressources canoniques doivent tous rester cohérents.
8. Une véritable politique de dépréciation
Les fonctionnalités présentent désormais trois états : Actif, Déprécié et Supprimé. Une fonctionnalité essentielle reste généralement en état Déprécié pendant au moins douze mois avant de pouvoir être supprimée, et la dépréciation exige un plan de migration documenté ainsi qu’une entrée dans le registre central. La suppression peut avoir lieu après la date la plus précoce prévue. Un processus accéléré existe pour les risques de sécurité urgents, mais même dans ce cas, il faut généralement au moins 90 jours.
HTTP+SSE, le transport plus ancien, dispose de sa propre règle de transition et pourrait être supprimé plus tôt que les autres fonctionnalités récemment dépréciées. Toute organisation qui l’utilise encore devrait d’abord planifier le passage à Streamable HTTP. Notez également que la règle des douze mois concerne uniquement les fonctionnalités de protocole ; les API des SDK ont leurs propres politiques et calendriers de support qui peuvent différer.
Comment cela se manifeste dans les applications réelles
Outils internes d’entreprise
Imaginons une entreprise qui diffuse des connaissances internes, Jira, Confluence, des catalogues de services et des guides opérationnels via MCP. Avec le modèle ancien, un déploiement à distance pouvait dépendre de l’affinité des sessions afin qu’un même employé accède toujours à la même instance. Avec la date 2026-07-28, le niveau MCP peut être constitué d’un ensemble de conteneurs sans état derrière un service Kubernetes normal et un équilibreur de charge :
MCP host
↓
API gateway / authorization
↓
Stateless MCP Deployment
├─ Knowledge connector
├─ Jira connector
├─ Confluence connector
└─ Service catalog connector
↓
OpenTelemetry backend
L’autorisation quotidienne peut suivre le protocole OAuth de base, tandis que l’extension d’autorisation gérée par l’entreprise intervient lorsque des politiques centralisées d’IdP sont nécessaires. Le nombre de clients prenant réellement en charge cette extension constitue la principale contrainte.
SaaS multi-locataires
Imaginons qu’un fournisseur d’outils de développement vende MCP en tant qu’API payante à des centaines ou des milliers d’abonnés. Le fait d’être sans état permet un routage multi-zone simple, et le gateway peut mesurer l’utilisation selon Mcp-Method et Mcp-Name, en se basant sur les autorisations validées plutôt que sur les noms ou en-têtes envoyés par le client. Une implémentation solide partitionnerait les identifiants et les tâches par abonné, marquerait les catalogues spécifiques à chaque abonné avec cacheScope: "private", comparerait chaque en-tête avec le corps du message, limiterait l’utilisation des outils coûteux selon leurs propres plafonds, bloquerait les recherches de tâches entre abonnés et éviterait de stocker les décisions d’autorisation en mémoire locale du processus. Le routage conscient de la session a disparu ; l’isolation des abonnés reste votre responsabilité.
Assistants de codage IA
Un serveur de codage peut exposer run_tests, build_project, generate_patch ou deploy_preview en tant que tâches. Il renvoie immédiatement un ID de tâche, met le travail en file d’attente et permet à l’agent de continuer à lire du code ou à examiner un autre problème. Le client effectue des requêtes à l’intervalle suggéré par le serveur, et lorsque une étape destructrice nécessite une approbation, la tâche passe en état input_required et le client répond par tasks/update. L’avantage réside dans la résilience face aux redémarrages de l’éditeur et aux pertes de connexion réseau. Le prix à payer est un véritable système de tâches : une file d’attente fiable, des licences pour les travailleurs, des résultats stockés, la possibilité d’annuler, des espaces de travail isolés ainsi qu’une politique de conservation des données.
Santé et services financiers
Les indicateurs de ressources et les vérifications de public cible réduisent les chances qu’un jeton émis pour un serveur MCP soit réutilisé ailleurs, tandis que la validation de l’émetteur diminue les risques d’attaques de confusion OAuth. Le contexte de suivi W3C permet de suivre une demande tout au long du chemin MCP et des services qui le composent. Ensemble, ils fournissent aux équipes de sécurité et de conformité un ensemble de contrôles plus clair, bien qu’ils ne constituent pas une solution complète en matière de conformité. Vous avez toujours besoin d’une autorisation au sein de l’application, d’événements d’audit immuables, de règles de conservation et de suppression, d’une classification des données, d’un traitement du consentement, d’une gestion des clés, de journaux d’accès administratif, d’un processus d’incident et de données de suivi minimales. Le suivi aide au diagnostic ; il ne doit pas être le seul enregistrement d’audit.
Une startup native de l’IA
Imaginons une petite équipe qui développe un assistant d’infrastructure. Grâce aux MCP Apps, elle pourrait mettre en place un formulaire de plan de déploiement, un tableau de bord d’estimation des coûts, un dialogue d’approbation, un moniteur de déploiement et un mécanisme de réversion. L’hôte fournit le contexte conversationnel, le serveur fournit les outils et les ressources d’interface utilisateur, et l’application invoque ces outils via un pont contrôlé par l’hôte. Un produit de tableau de bord distinct pourrait d’abord sembler inutile, mais la conception API, l’autorisation, les tests d’interface, l’accessibilité, les règles CSP et les solutions de fallback en matière de compatibilité restent nécessaires.
Où la nouvelle spécification ajoute de la complexité
L’état a été déplacé, il n’a pas disparu. L’état de connexion devient un état de domaine explicite, ce qui représente une amélioration architecturale qui oblige à concevoir de manière délibérée les mécanismes de gestion, de stockage, d’expiration, de propriété et d’idempotence.
Mettre à jour le SDK et adopter le nouveau protocole sont deux projets distincts. Lorsque la version candidate était disponible, les mainteneurs du SDK ont conseillé aux équipes de séparer la mise à niveau de la version majeure du SDK de l’activation du nouveau protocole de communication, et ce conseil reste valable. Prenons par exemple le SDK TypeScript v2 : il divise le package unique en packages séparés pour le serveur et le client, est distribué uniquement en format ESM, fonctionne sous Node.js 20+, Bun et Deno, est validé à l’aide de bibliothèques compatibles avec Standard Schema, et inclut un codemod pour gérer les modifications typiques liées à la version v1. Python v2 représente également une refonte importante, notamment avec le changement de nom de FastMCP en MCPServer. TypeScript v1 continuera de recevoir des correctifs et des mises à jour de sécurité pendant au moins six mois après la sortie de v2, tandis que Python v1 continuera également d’obtenir des correctifs critiques et des mises à jour de sécurité. Une séquence de travail prudente :
- Mettre à jour le SDK tout en conservant le comportement des protocoles précédents là où c’est possible.
- Corriger les modifications apportées aux API au niveau de l’application.
- Ajouter un soutien pour des protocoles de deux époques différentes.
- Valider avec des clients et du trafic réels.
- Activer progressivement un comportement moderne sans état.
- Supprimer le support des versions anciennes uniquement après avoir observé l’adoption par les clients.
Les extensions fragmentent les fonctionnalités. Un outil ne peut pas supposer que les tâches ou les applications MCP existent partout, ce qui oblige les équipes de produit à disposer de matrices de compatibilité et d’interfaces utilisateur de secours.
Les tentatives de répétition deviennent un problème de correction. Les chemins de réessai proviennent désormais de la négociation de la version du protocole, des flux de réponse HTTP interrompus, de l’augmentation des droits d’autorisation, de la consultation des tâches et de la réconnexion des abonnements. Toute opération ayant des effets secondaires nécessite donc un plan d’idempotence bien défini.
OAuth offre une meilleure interopérabilité mais reste exigeant. La spécification cite OAuth 2.1 et les Documents de métadonnées d’identifiant de client en tant que versions préliminaires, ce qui oblige les implementateurs à suivre à la fois les modifications MCP et les normes de base.
Le cache pose des questions de confidentialité. Marquer une réponse dépendante d’une autorisation comme publique pourrait exposer le catalogue d’un utilisateur ou d’un locataire à un autre. Des paramètres par défaut conservateurs sont recommandés : utiliser un champ de portée privé sauf si le résultat est véritablement identique pour tous les utilisateurs.
Évaluation globale
MCP 2026-07-28 rapproche le protocole du fonctionnement du web moderne : des requêtes autonomes, des versions explicites, un routage HTTP standard, des sémantiques de cache réelles, un suivi distribué, une autorisation standard et des fonctionnalités optionnelles qui évoluent séparément. Le véritable avantage réside non pas dans l’absence d’état, mais dans l’absence d’état de protocole caché.
L’extension des capacités, le routage entre zones, la récupération en cas de panne, la définition des politiques de passerelle ainsi que l’observation du système deviennent tous considérablement plus faciles. Ce qui ressort en retour, c’est l’état de la session de travail utilisé pour masquer : les gestionnaires d’applications, l’idempotence, les tâches durables, les solutions de secours en cas d’extension, les métadonnées d’autorisation, la confidentialité des caches et les mécanismes de tentative répétée.
Si vous gérez un serveur de production existant, migrez par étapes et prenez en charge les deux versions. Traitez la mise à niveau du SDK et le protocole de communication comme des étapes distinctes, éliminez les hypothèses liées aux connexions, stockez les opérations à long terme dans des structures explicites, testez les mécanismes d’autorisation et de tentative de réexécution, et ne retirez le comportement obsolète qu’une fois que l’adoption réelle par les clients aura été mesurée. Pour un serveur entièrement nouveau, c’est plus simple : commencez avec des gestionnaires de requêtes sans état et un état explicite, utilisez HTTP Streamable ainsi que les mécanismes d’autorisation actuels, ajoutez OpenTelemetry, rendez le cache déterministe, et planifiez dès le premier jour la négociation des extensions.
Le protocole est désormais plus facile à mettre en œuvre, mais uniquement pour les équipes prêtes à définir clairement l’état de leur application, leurs limites de sécurité et leur comportement en cas de panne.
Lectures complémentaires
- Notes pratiques : MCP 2026 : Le protocole a mu – Voici ce que représente l’IA en production — Guide détaillé des notes pratiques : MCP 2026 : Le protocole a mu – Voici ce que représente l’IA en production : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes utilisant ce modèle.
- Dix serveurs MCP à installer en priorité pour les développeurs — Liste classée de serveurs MCP adaptés aux assistants de codage IA, allant de Context7 et GitHub à Postgres et des solutions de mémoire, avec des configurations d’installation et des conseils concernant les permissions.