MCP Nouvelle Version Signal : Le protocole des outils Agent commence à combler les lacunes de production

MCP Nouvelle Version Signal : Le protocole des outils Agent commence à combler les lacunes de production

La chose la plus importante dans la nouvelle version de MCP n’est pas “d’avoir quelques capacités supplémentaires”, mais qu’elle commence à répondre aux anciennes questions dans l’environnement de production : comment étendre, comment router, comment authentifier, comment exécuter des tâches longues, comment migrer en toute sécurité.

Si l’on se concentre uniquement sur le spectacle, MCP 2026-07-28 ressemble à une mise à jour de version de protocole : ajout de core sans état, de requêtes multi-tours, de routage basé sur les en-têtes, de résultats de liste pouvant être mis en cache, de renforcement de l’autorisation, d’un cadre d’extensions, ainsi qu’un nouveau SDK.

Mais si vous êtes en train de développer un Agent, des outils internes, un accès SaaS, ou si vous vous préparez à déployer le serveur MCP dans un environnement commercial réel, le signal libéré par cette mise à jour est plus direct : MCP commence à combler les lacunes de production.

Au cours de l’année passée, MCP est rapidement devenu l’un des standards de facto pour connecter des agents AI et des données. Les problèmes ont également été révélés : les démos sont faciles, la production est difficile. Connecter un outil local et exécuter un appel n’est pas difficile ; le défi réside dans la haute concurrence, l’évolutivité, l’observabilité, la capacité à fonctionner avec un système d’identité d’entreprise, à gérer des tâches longues de manière stable, tout en évitant de faire s’effondrer les systèmes existants lors d’une mise à jour de protocole.

Cette nouvelle version vise précisément à résoudre ces problèmes d’infrastructure.

Premier changement : passage d’une connexion avec état à un core sans état

Le changement le plus frappant dans la nouvelle version est que MCP passe à un état sans état au niveau du protocole. Le blog officiel le dit clairement : MCP passe d’un protocole à état bidirectionnel à un protocole sans état de type requête/réponse.

Cela peut sembler être un détail technique pour les ingénieurs backend, mais c’est crucial pour l’écosystème des outils Agent.

Les connexions avec état conviennent à une expérience précoce : le client se connecte au serveur, il y a des allers-retours, ce qui est facile à comprendre pour les développeurs. Mais cela entraîne également des problèmes typiques de production : que faire si la connexion est interrompue, comment faire le répartition de charge, comment partager les sessions entre plusieurs instances, comment déployer sans serveur et en périphérie, comment router via la passerelle.

Le sens du core sans état est de rendre chaque requête aussi auto-descriptive que possible. La requête contient la version du protocole, l’identité du client, les informations de capacité ; si le client souhaite connaître à l’avance les capacités du serveur, il peut appeler le nouveau serveur/discover, mais ce n’est pas une poignée de main obligatoire.

Le résultat est que le serveur MCP peut fonctionner plus naturellement sur une infrastructure HTTP ordinaire. Les requêtes peuvent être dirigées vers n’importe quelle instance derrière un équilibre de charge, sans dépendre fortement des sessions collantes ou du stockage de session partagé. Pour le déploiement en entreprise, cette étape est très réaliste.

Deuxième changement : le routage et le cache commencent à ressembler à une infrastructure

La nouvelle version introduit le routage basé sur les en-têtes : le nom de la méthode et le nom de l’outil peuvent être transmis via des en-têtes HTTP tels que Mcp-Method, Mcp-Name, permettant à la passerelle de router, d’authentifier et de contrôler les politiques directement sur la base des en-têtes.

Cela résout un autre problème de production : lorsque le serveur MCP, les outils et les équipes se multiplient, il ne peut pas y avoir toutes les requêtes qui arrivent sous forme d’un seul JSON, puis que la couche d’application les décompose lentement. La passerelle, la couche de sécurité et la couche d’audit doivent savoir plus tôt “quelle méthode, quel outil, qui appelle”.

Les résultats de liste pouvant être mis en cache sont également cruciaux. Si les résultats de liste d’outils et de ressources sont stables dans l’ordre et portent des indications de cache, le client peut mettre en cache le répertoire des outils, ce qui permet également de rendre le cache des prompts en amont plus stable.

Ce n’est pas pour économiser quelques requêtes réseau, mais pour rendre le contexte de l’Agent plus prévisible. Si l’ordre du répertoire des outils change à chaque fois, le cache des prompts peut devenir invalide, et le contexte vu par le modèle peut également fluctuer. La nouvelle version intègre ces détails dans le protocole, marquant une transition de “fonctionnel” à “utilisation à grande échelle”.

Troisième changement : l’autorisation passe d’un accès de jouet à une identité d’entreprise

Un des plus grands problèmes de MCP à ses débuts était que les frontières d’autorisation n’étaient pas assez claires. Une fois que l’Agent peut se connecter à l’outil, le véritable risque n’est pas “peut-il appeler”, mais “qui lui permet d’appeler, que peut-il appeler, l’appel peut-il être révoqué, est-ce conforme au système d’identité d’entreprise”.

Cette nouvelle version met l’accent sur le renforcement de l’autorisation, y compris l’alignement sur le déploiement OAuth 2.0 / OIDC, la validation de l’émetteur, et le passage de l’enregistrement dynamique des clients vers des documents de métadonnées clients. Les explications du côté de Claude mentionnent également que le serveur MCP peut se connecter à des systèmes d’identité d’entreprise comme Entra, Okta, plutôt que de s’appuyer sur des solutions temporaires.

Cela montre que MCP reconnaît un fait : si le protocole des outils Agent veut entrer dans l’entreprise, il ne peut pas rester au stade de la clé API et de l’autorisation personnelle. Il doit s’intégrer aux IAM, SSO, audit et gouvernance des permissions existants.

Pour les développeurs, à l’avenir, lors de l’écriture d’un serveur MCP, l’authentification ne doit plus être un middleware ajouté à la fin, mais faire partie de la conception du protocole et du produit.

Quatrième changement : les Apps et les Tasks sont intégrées dans le cadre d’extensions

La nouvelle version a également officiellement verrouillé le cadre d’extensions, les capacités des Apps MCP, des Tasks, etc. entrent dans un cadre d’extensions versionné.

C’est important, car la relation entre l’Agent et les outils ne se limite pas à “appeler une fonction, retourner un texte”. De nombreuses tâches réelles nécessitent une interface utilisateur, nécessitent une confirmation humaine, nécessitent de s’exécuter en arrière-plan pendant quelques minutes voire quelques heures, nécessitent une annulation, une nouvelle tentative, une récupération d’erreur et une vérification d’état.

Les Apps MCP visent une interface utilisateur interactive : l’Agent ne se contente pas de fournir des résultats en texte brut, il peut également intégrer une interface opérationnelle dans le flux de travail de l’utilisateur. Les Tasks visent des tâches longues : par exemple, générer des rapports, traiter des données en lot, exécuter des processus automatisés, qui ne conviennent pas à être intégrés dans une seule requête synchronisée.

L’importance des extensions versionnées est de permettre à ces capacités d’évoluer, plutôt que de polluer constamment le protocole de base. Le cœur reste petit et stable, les capacités complexes croissent par le biais de spécifications d’extensions, ce qui ressemble à ce qu’un protocole à long terme devrait être.

Que signifie cela pour les développeurs d’Agents

Premièrement, ne considérez plus le serveur MCP comme un petit script “exposant quelques fonctions au modèle”. Dans un environnement de production, il ressemble davantage à un service de frontière : connectant des données, des permissions, des audits, des files d’attente de tâches et des systèmes d’entreprise.

Deuxièmement, l’architecture de déploiement doit migrer vers un état sans état. Un serveur MCP pouvant être intégré dans un HTTP ordinaire, un équilibre de charge, un sans serveur, une périphérie sera plus facile à mettre à l’échelle que ceux qui dépendent de connexions longues et de sessions en mémoire.

Troisièmement, le modèle de permissions doit être en amont. Les appels d’outils nécessitent une identité utilisateur, une politique organisationnelle, un minimum de permissions et des enregistrements d’audit, plutôt qu’un token global qui domine tout.

Quatrièmement, les tâches longues doivent être exprimées à l’aide d’un modèle de tâches. L’Agent ne doit pas attendre que tous les travaux soient synchrones, en particulier pour des tâches telles que la génération de rapports, l’importation en masse, l’analyse de code, le traitement des données, qui nécessitent un cycle de vie, une annulation et un traitement des erreurs.

Cinquièmement, faites attention au rythme de migration du SDK. Le blog officiel mentionne que les SDK de niveau 1 tels que TypeScript, Python, Go, C# ont déjà suivi la nouvelle version, mais la migration de la version majeure elle-même peut comporter des changements incompatibles. Les systèmes de production ne doivent pas se contenter de regarder “la spécification a été publiée”, mais aussi la stratégie de compatibilité entre le SDK, le client et le serveur.

Le véritable signal : l’infrastructure des Agents commence à converger

Ce qui mérite d’être noté dans la nouvelle version de MCP, ce n’est pas qu’un paramètre a changé, mais que la direction de l’infrastructure des Agents commence à converger.

L’écosystème des Agents à ses débuts était rempli de démos “tant que ça fonctionne” : outils locaux, plugins de navigateur, autorisation d’utilisateur unique, connexions longues, état temporaire. Ils sont très adaptés pour valider des idées, mais pas pour supporter un travail au niveau organisationnel.

Maintenant, des termes comme sans état, routage d’en-tête, cache, OAuth/OIDC, extensions, Tasks, politique de dépréciation apparaissent de plus en plus, indiquant que les mainteneurs du protocole et les participants à l’écosystème ont déjà tourné leur attention vers la fiabilité, la gouvernance et le coût de migration.

C’est également la réalité à laquelle tous les protocoles d’outils AI devront faire face tôt ou tard : plus les capacités du modèle sont fortes, plus les appels d’outils sont dangereux ; plus l’Agent est capable, plus les permissions, l’état et l’audit ne peuvent être flous.

Conclusion

Ainsi, MCP 2026-07-28 n’est pas une mise à jour mineure ordinaire. C’est plutôt un signal de changement de phase : le protocole des outils Agent commence à passer de la démo des développeurs à l’infrastructure de production.

La prochaine étape, un véritable serveur MCP de valeur ne sera pas seulement “j’ai enveloppé l’API pour que le modèle l’appelle”. Il doit être déployé, étendu, authentifié, observé, mis en cache, mis à niveau et gouverné comme un service backend normal.

Pour les développeurs, c’est le bon moment pour revoir leur mise en œuvre de MCP : est-elle conviviale pour un état sans état ? Peut-elle fonctionner avec une identité d’entreprise ? La liste des outils est-elle stable ? Les tâches longues ont-elles un cycle de vie ? Y a-t-il une fenêtre de compatibilité lors des mises à niveau ?

Si ces questions n’ont pas encore de réponse, la nouvelle version de MCP a déjà indiqué la direction. Combler les lacunes est plus important que d’ajouter quelques outils supplémentaires.

Références : Blog du Modèle Contextuel “La spécification 2026-07-28”, Blog de Claude “MCP 2026-07-28 spec : core sans état, à venir vers Claude”.