Le Model Context Protocol a franchi une étape majeure en matière d'infrastructure : sa révision du 2026-07-28 fait évoluer le protocole vers un noyau sans état. Pour les équipes créant des systèmes d’agents, des serveurs d’outils, des intégrations IDE ou des couches d’orchestration multimodèles, il ne s’agit pas d’une mise à jour de spécifications cosmétiques. Cela modifie les hypothèses concernant les sessions, l'initialisation, la mise à l'échelle, la compatibilité et la gouvernance.

La version candidate de MCP a décrit la spécification du 28 juillet comme ajoutant un noyau de protocole sans état, un cadre d'extensions, des tâches, des applications MCP, un renforcement des autorisations et une politique de dépréciation formelle. Le blog officiel de MCP a également averti que la version contenait des modifications importantes. GitHub, qui exploite l'une des implémentations de serveur MCP les plus visibles, a déclaré avant la version finale que son serveur MCP prenait déjà en charge la nouvelle spécification et a décrit le protocole comme « devenant sans état » le 28 juillet.

La signification pratique est simple : MCP se présente moins comme une couche d'intégration locale lourde en sessions que comme un protocole à l'échelle Internet pour l'accès aux outils à distance. C’est important car les systèmes d’agents ne se limitent plus aux outils de développement de bureau. Ils s'exécutent de plus en plus au sein de services cloud, de systèmes CI, de workflows de support client, de systèmes de suivi des problèmes et de plates-formes d'automatisation d'entreprise.

Ce qui a changé dans MCP

Le principal changement est le passage à un noyau de protocole sans état. Le journal des modifications de GitHub indique que le nouveau noyau supprime les sessions et s'initialise, dans le but de faciliter la mise à l'échelle des déploiements MCP à distance. Il s’agit d’un changement architectural important. Les protocoles avec état peuvent bien fonctionner pour les outils locaux et les environnements contrôlés, mais ils compliquent la mise à l'échelle horizontale, l'exécution sans serveur, le basculement, le déploiement en périphérie et l'équilibrage de charge.

Un cœur sans état donne aux développeurs plus de liberté pour exécuter des serveurs MCP derrière une infrastructure Web ordinaire. Les requêtes peuvent être distribuées entre les instances sans conserver une session de longue durée sur un backend spécifique. Pour les grandes organisations, cela peut réduire la complexité opérationnelle. Pour les petites équipes, cela peut faciliter le déploiement des serveurs MCP hébergés à l'aide d'un calcul géré plutôt que d'une infrastructure personnalisée à long terme.

La version plus large du 28/07/2026 introduit également un cadre d'extensions et des tâches, selon les documents de la version candidate. Ces ajouts suggèrent que MCP devient plus modulaire et plus explicite sur les travaux à plus long terme. Les applications MCP et le renforcement des autorisations vont dans la même direction : le protocole évolue depuis le début de l'écosystème vers une couche plus formelle pour l'interaction agent-outil.

Le coût de cette maturation est le travail de compatibilité. Le blog MCP a caractérisé la version comme une version comportant des modifications importantes, et les documents TypeScript et SDK C# publiés autour de la révision se concentrent sur la prise en charge de la migration et les concepts sans état. Toute équipe exploitant un serveur MCP, intégrant MCP dans une extension IDE ou acheminant les appels d'agent via l'infrastructure interne doit traiter la révision comme un événement d'ingénierie plutôt que comme une mise à jour des normes en arrière-plan.

Pourquoi MCP sans état est important pour les développeurs et les opérateurs

Les outils d'agent ont un problème de mise à l'échelle qui semble différent de la mise à l'échelle des API ordinaires. Une seule demande d'utilisateur peut déclencher de nombreux appels d'outils, changements de modèle, tentatives, lectures de fichiers, requêtes de recherche et étapes d'approbation. Lorsque le protocole de l'outil suppose des sessions durables, les opérateurs de production doivent préserver l'état dans ces interactions ou créer des solutions de contournement autour du protocole.

En supprimant les sessions du noyau, MCP s'adapte mieux aux environnements dans lesquels les charges de travail des agents sont en rafale, distribuées et asynchrones. Les fonctions sans serveur, les travailleurs de périphérie, les déploiements Kubernetes et les systèmes multirégionaux bénéficient tous du fait que les demandes peuvent être traitées de manière indépendante. Cela n’élimine pas l’état des applications d’agent ; il déplace l'état dans les bases de données d'application, les files d'attente de tâches, les systèmes d'identité ou les couches de flux de travail explicites plutôt que de l'intégrer dans le cœur du protocole.

Pour les développeurs, le changement devrait à terme rendre les serveurs d'outils distants plus faciles à utiliser. Pour les équipes de plateforme, cela peut simplifier l’observabilité et la planification des capacités. Au lieu de déboguer un comportement d'affinité de session opaque, les opérateurs peuvent se concentrer sur les traces au niveau des requêtes, la latence des appels d'outils, les décisions d'autorisation et les modèles d'erreurs.

Il existe également un angle de gouvernance. À mesure que MCP devient plus courant dans les assistants de codage et les agents d'entreprise, les entreprises auront besoin de politiques concernant les outils que les agents peuvent appeler, les données auxquelles ils peuvent accéder et les utilisateurs ou services autorisés à les invoquer. Le durcissement des autorisations dans la nouvelle révision n’est donc pas fortuit.Cela reflète la réalité selon laquelle l'accès aux outils est désormais une limite de sécurité, et non plus seulement une commodité pour les développeurs.

Qui est concerné

Les groupes les plus directement concernés sont les responsables du serveur MCP, les utilisateurs du SDK, les équipes de plate-forme d'agents et les organisations exposant des outils internes aux agents IA. Si un serveur dépend du comportement de la session ou d'anciens flux d'initialisation, il devra être testé par rapport à la nouvelle spécification. Si une application prend en charge plusieurs versions de MCP, elle peut nécessiter une négociation de version, des couches de compatibilité ou un plan de migration par étapes.

Les fournisseurs d'IDE et d'outils de développement sont également concernés. MCP apparaît de plus en plus aux côtés des agents de codage, des agents personnalisés et des fonctionnalités de gestion de modèles. Un noyau de protocole sans état permet à ces produits d'appeler plus facilement des outils distants de manière fiable, mais seulement si leurs intégrations suivent le rythme des spécifications.

Les entreprises utilisant l'automatisation des agents doivent y prêter attention même si elles ne lisent jamais la spécification MCP. Ce changement peut affecter la fiabilité des agents qui se connectent aux référentiels, aux systèmes de tickets, aux bases de données, aux bases de connaissances internes ou aux outils de déploiement. Pendant les fenêtres de migration, les modes de défaillance probables ne sont pas seulement des pannes évidentes. Ils peuvent inclure des fonctionnalités d'outil manquantes, un comportement d'authentification modifié ou des agents empruntant des chemins différents car un serveur d'outils ne se comporte plus comme prévu.

Pour une passerelle API IA telle que Model Gate, la connexion est pratique. Une API d'IA unifiée se rapproche de plus en plus du routage des modèles, de la gestion des clés d'API, de l'analyse de l'utilisation et de la gouvernance des API d'équipe. À mesure que les systèmes d'agents ajoutent des appels d'outils MCP aux appels de modèle ordinaires, les couches de passerelle et d'observabilité devront tenir compte des deux côtés du flux de travail : quel modèle a été utilisé, quels outils ont été invoqués, combien ils coûtent, qui les a autorisés et où les échecs se sont produits.

Priorités de migration et questions ouvertes

La première priorité de migration est les tests de compatibilité. Les équipes doivent inventorier les clients et les serveurs MCP, identifier les dépendances sur les sessions ou initialiser le comportement, et tester par rapport aux SDK 2026-07-28 ou aux documents de conformité, le cas échéant. Les systèmes de production doivent organiser la mise à niveau, en particulier si les agents effectuent des actions ayant des effets secondaires, telles que la création de demandes d'extraction, la modification de problèmes, l'interrogation de données client ou l'exécution de workflows de déploiement.

La deuxième priorité est l'observabilité. L'infrastructure sans état peut être plus facile à faire évoluer, mais les systèmes d'agents distribués ont toujours besoin d'ID de corrélation, de capture de trace, de journaux de requêtes et d'événements de stratégie. Sans cela, les équipes peuvent troquer la complexité des sessions contre la complexité du débogage. Les analyses d'utilisation doivent faire la distinction entre les appels de modèle et les appels d'outils, en particulier lorsque les flux de travail des agents sont facturés, limités en débit ou audités par l'équipe.

La troisième priorité est l'examen des autorisations. Si la nouvelle spécification renforce la sémantique d'autorisation, les implémenteurs ne doivent pas simplement porter les anciennes hypothèses d'accès dans la nouvelle version. Ils doivent revérifier la portée des jetons, la délégation des utilisateurs, les comptes de service, les journaux d'audit et le comportement de refus. L'accès aux outils doit être limité par défaut au minimum de privilèges, en particulier pour les déploiements MCP à distance.

Certains détails méritent d'être vérifiés avant que les organisations ne prennent des décisions de conception irréversibles. Les recherches disponibles pour cet article comprenaient la version candidate, la page de spécifications, les documents de migration du SDK et la note de mise en œuvre de GitHub. Le libellé normatif final de la spécification du 28/07/2026 doit être révisé directement avant de citer les exigences exactes du protocole dans les normes internes ou la documentation client.

Même avec cette mise en garde, la direction est claire. MCP devient un protocole davantage orienté vers la production pour l’infrastructure d’agents. Le noyau sans état devrait faciliter la mise à l'échelle des déploiements à distance, mais il oblige également l'écosystème à nettoyer les hypothèses des implémentations antérieures. Pour les équipes constituées d'agents, c'est le genre de changement de protocole qui mérite un ticket de sprint, pas seulement un signet.