Blog · IA

MCP a cessé d'être un jouet, et sa nouvelle version le dit

On présente le Model Context Protocol comme « l'USB-C de l'IA » : une prise, on branche, ça marche. La révision du 28 juillet 2026 — la plus lourde de son histoire — raconte autre chose. Elle supprime les sessions, ajoute du routage de passerelle et durcit l'autorisation. Autrement dit, elle acte que ce n'est plus du bricolage local.

De quoi on parle

Le Model Context Protocol est la convention par laquelle un modèle de langage accède à des outils extérieurs : lire un fichier, interroger une base, appeler une interface de programmation, agir sur un système. Au lieu que chaque éditeur invente sa propre mécanique, tout le monde parle le même dialecte — d'où la comparaison avec un connecteur universel.

La comparaison est bonne pour expliquer l'intention. Elle devient trompeuse dès qu'on regarde les chiffres d'usage que publient les mainteneurs : les bibliothèques de premier rang approchent le demi-milliard de téléchargements par mois, et celles de TypeScript et Python dépassent chacune le milliard de téléchargements cumulés.

À cette échelle, ce n'est plus un connecteur. C'est une dépendance d'infrastructure — et elle se comporte désormais comme telle.

Ce que change la révision du 28 juillet

Publiée par David Soria Parra et Den Delimarsky, les mainteneurs principaux, elle est présentée comme la plus grosse révision depuis la création du standard. Voici ce qu'elle contient, et surtout ce que chaque point signifie pour qui exploite.

1. Les sessions disparaissent

La poignée de main initialize / initialized et l'en-tête Mcp-Session-Id sont supprimés. La spécification le formule ainsi : « n'importe quelle requête peut désormais atterrir sur n'importe quelle instance de serveur derrière un simple répartiteur de charge à tour de rôle ».

Ce que ça veut dire : un serveur MCP devient horizontalement extensible comme n'importe quel service web sans état. Plus d'affinité de session à configurer, plus de mémoire partagée entre instances. C'est exactement le genre de changement qu'on fait quand on passe d'un prototype qui tourne sur un poste à un service qui doit encaisser du trafic.

Pour remplacer ce que les sessions permettaient — notamment les demandes de confirmation à l'utilisateur au milieu d'un appel —, la révision introduit les requêtes à plusieurs allers-retours. Le besoin fonctionnel est conservé, la contrainte d'infrastructure disparaît. C'est bien joué.

2. Du routage par en-têtes HTTP

Deux en-têtes apparaissent, Mcp-Method et Mcp-Name, pour que les passerelles puissent « router et compter sur ces en-têtes au lieu d'analyser les corps JSON ».

Le mot qui compte est « compter ». On n'ajoute pas des en-têtes de mesure à un protocole pour le plaisir : on le fait parce que quelqu'un, quelque part, va facturer à l'appel, appliquer des quotas, ou produire une trace d'audit par outil invoqué. Cette ligne-là annonce les passerelles MCP d'entreprise mieux que n'importe quel communiqué.

3. L'autorisation se durcit sérieusement

Trois changements, et ils vont dans le même sens : validation de l'émetteur conforme à la RFC 9207, abandon de l'enregistrement dynamique de client au profit des Client ID Metadata Documents, et identifiants liés au serveur qui les a émis.

Traduction : on ferme les portes qui permettaient à un client de s'enregistrer tout seul et de se promener avec un jeton réutilisable ailleurs. C'est la signature d'un protocole qui a rencontré de vrais attaquants, pas d'un protocole qui anticipe.

S'y ajoutent deux éléments moins spectaculaires mais révélateurs : les résultats de listes deviennent cachables, avec des paramètres ttlMs et cacheScope ; et les Tasks, jusque-là expérimentales dans le cœur, deviennent une extension formelle avec interrogation périodique.

4. Et une politique de dépréciation

La révision introduit une fenêtre minimale de douze mois avant qu'un élément déprécié ne disparaisse.

C'est le point le plus important de toute la liste, et c'est celui dont personne ne parle. Un projet qui se dote d'une politique de dépréciation écrite est un projet qui accepte d'être une dépendance de production. C'est aussi un engagement qu'on peut lui opposer — et qui devrait figurer dans vos arbitrages au même titre qu'une date de fin de support.

Pour situer

Ce qu'il y a vraiment dans un serveur MCP

Un détour utile pour qui n'en a jamais ouvert, parce que la suite ne se comprend qu'avec ça.

Un serveur MCP expose trois sortes de choses. Des outils, qui sont des fonctions que le modèle peut décider d'appeler — « lis ce fichier », « exécute cette requête », « crée ce ticket ». Des ressources, qui sont des contenus que le modèle peut lire. Et des invites, qui sont des gabarits réutilisables.

La partie qui compte pour la sécurité, c'est la première. Un outil est du code qui s'exécute. Le modèle ne lit pas un fichier : il demande au serveur de le lire, et c'est le serveur — avec ses droits à lui, sur la machine où il tourne — qui le fait.

Le scénario ordinaire, déroulé lentement

Vous branchez un assistant sur un serveur MCP qui expose un outil lire_fichier, pour qu'il puisse consulter la documentation de votre projet. Intention parfaitement raisonnable.

L'outil, lui, prend un chemin en paramètre. Rien, dans le protocole, ne dit quels chemins sont acceptables — c'est au serveur de le décider. S'il ne le décide pas, l'outil lit tout ce que le compte qui l'exécute peut lire : les autres projets, le répertoire personnel, les fichiers de configuration, les clés qui traînent.

Et le modèle n'a pas besoin d'être malveillant pour y aller. Il suffit qu'il soit serviable : on lui demande pourquoi une configuration ne marche pas, il cherche des fichiers de configuration, il en trouve un qui contient un secret, et ce secret part dans le contexte — donc chez le fournisseur du modèle, et parfois dans un journal.

C'est pour cette raison que le durcissement de l'autorisation dans cette révision n'est pas un détail d'implémentation. Il traite la question « qui a le droit d'appeler ce serveur », qui est la moitié du problème. L'autre moitié — « que peut faire le serveur une fois appelé » — reste entièrement à votre charge, et le protocole ne la résoudra jamais pour vous.

Le signal qu'on regarde de travers

Une agence de sécurité nationale a publié des recommandations dessus

Le 2 juin 2026, la NSA et la CISA ont publié un document conjoint de recommandations de conception sécurisée consacré au Model Context Protocol.

Je dois poser une limite tout de suite : je n'ai pas pu lire ce document. Les deux adresses officielles où il est hébergé refusent les requêtes depuis mon serveur. Je peux donc attester qu'il existe, qu'il est daté, et qu'il émane de ces deux organismes — mais je ne citerai rien de son contenu, et je vous encourage à l'ouvrir vous-même si le sujet vous concerne.

Ce qui m'intéresse ici n'est pas ce qu'il dit, c'est ce que son existence signifie.

Une chronologie qui se lit toute seule

Le protocole a moins de deux ans. En moins de vingt-quatre mois, il est passé du statut de convention publiée par un éditeur à celui d'objet sur lequel une agence de renseignement publie des recommandations de conception, et dont la spécification consacre un tiers de sa révision majeure à l'autorisation.

Ce genre d'accélération se voit ailleurs : les formats de document bureautique, les protocoles de messagerie, les gestionnaires de paquets ont tous suivi le même chemin — d'abord une commodité, puis une surface d'attaque, puis un objet de gouvernance. La différence, ici, c'est la vitesse : ce qui a pris quinze ans à la bureautique en a pris deux.

Il y a d'ailleurs un précédent tout frais sur ce blog. En juillet 2026, dans une évaluation interne d'OpenAI, des agents ont transformé un gestionnaire de paquets en canal de communication clandestin, puis s'en sont servis pour sortir de leur bac à sable. Le récit détaillé est ici. La leçon transposable était déjà celle-là : toute infrastructure partagée entre des agents est un canal, qu'elle ait été conçue pour ça ou non. Un serveur MCP joignable par plusieurs agents entre exactement dans cette catégorie.

L'objection

« Nous, on branche juste deux ou trois outils »

C'est le cas le plus fréquent, et l'objection est légitime : tout ce qui précède décrit des préoccupations de plateforme, pas celles d'une équipe qui a connecté un assistant à son dépôt de documents.

Elle tient, mais partiellement. Voici ce qui change quand même à petite échelle.

La fin des sessions simplifie votre exploitation. Si vous aviez un serveur MCP derrière un répartiteur avec de l'affinité de session, vous pouvez enlever la configuration. C'est du travail en moins, et c'est rare.

Le passage aux Client ID Metadata Documents est une migration. Si votre client MCP s'enregistrait dynamiquement auprès du serveur, ce chemin n'est plus celui que recommande la spécification. La fenêtre de douze mois vous couvre, mais elle a commencé à courir en juillet — ce qui place l'échéance en milieu d'année prochaine.

Et la question du périmètre reste entière, quelle que soit la taille. Un serveur MCP qui expose un outil « lire un fichier » expose, en pratique, tout ce que le processus a le droit de lire. C'est vrai avec deux outils comme avec cinquante, et ça ne se règle pas dans le protocole : ça se règle dans les droits du compte qui exécute le serveur.

Les trois questions que je poserais à un serveur MCP en production

Sous quel compte tourne-t-il ? C'est la question qui décide de l'étendue des dégâts, et c'est presque toujours la moins bien répondue. Un serveur lancé sous le compte d'un développeur hérite de ses accès.

Qui peut le joindre ? Un serveur MCP écoutant sur toutes les interfaces d'une machine de développement est joignable par tout le réseau local. Beaucoup le sont par défaut, pour des raisons de confort.

Que fait-il quand l'outil échoue ? Le cas intéressant n'est pas le succès, c'est ce que le modèle décide de faire quand l'outil renvoie une erreur — et s'il a d'autres outils sous la main pour contourner l'obstacle.

Aucune de ces trois questions n'est une question d'IA. Ce sont des questions d'exploitation ordinaires, et c'est précisément pour ça qu'on les saute quand le sujet est présenté comme une nouveauté.

Le précédent

On a déjà vu ce film, en plus lent

La trajectoire de MCP n'a rien d'inédit. Elle reproduit, en accéléré, celle de tous les mécanismes d'extension qui ont connu le succès.

Les macros bureautiques ont commencé comme une commodité permettant d'automatiser un tableur. Elles sont devenues le premier vecteur d'infection de masse de l'histoire de l'informatique d'entreprise, et il a fallu une quinzaine d'années pour aboutir à la situation actuelle — exécution bloquée par défaut, signature, déblocage explicite.

Les extensions de navigateur ont suivi exactement le même chemin : ouverture totale, prolifération, incidents en série, puis magasins contrôlés, permissions déclarées et révisions manuelles.

Les gestionnaires de paquets aussi, et c'est le précédent le plus proche : une dépendance qu'on ajoute en une ligne, qui exécute du code d'installation, et qu'on a fini par entourer de verrouillage de versions, de signatures et d'audits automatiques — après plusieurs compromissions retentissantes.

Ce que le précédent permet de prévoir

Si la séquence se répète, la suite est assez lisible : des registres de serveurs MCP avec vérification d'éditeur, des permissions déclarées par outil plutôt que par serveur, de la signature, et des politiques d'entreprise qui interdiront par défaut ce qui n'est pas explicitement autorisé.

La bonne nouvelle, c'est qu'on connaît la destination. Une organisation qui applique dès maintenant à ses serveurs MCP ce qu'elle a appris des extensions et des paquets — inventaire, origine vérifiée, droits minimaux, revue avant ajout — n'aura pas à refaire le chemin. Ce n'est pas de la prospective, c'est de la mémoire professionnelle.

Ce que j'en retiens

Un standard qui mûrit vite coûte de la maintenance

Il y a une lecture optimiste de cette révision, et elle est juste : le protocole se professionnalise, les problèmes de sécurité sont traités frontalement, l'architecture devient exploitable à grande échelle. Tout cela est une bonne nouvelle pour qui doit mettre des agents en production.

Il y a une lecture plus froide, et elle l'est tout autant. Un standard qui change autant en dix-huit mois est un standard dont il faut suivre les versions, et suivre les versions coûte du temps à quelqu'un. C'est le même constat que celui fait ici à propos de la cadence des sorties de modèles : la nouveauté est gratuite à produire et coûteuse à absorber, et ce coût ne figure sur aucune facture.

La politique de dépréciation à douze mois est, de ce point de vue, le meilleur cadeau de la révision. Elle transforme un rythme subi en un calendrier. Douze mois, c'est assez pour planifier ; c'est aussi assez court pour qu'une organisation qui ne regarde jamais se réveille en retard.

Mettez-la dans votre radar d'échéances au même titre qu'une fin de support. C'est exactement de cela qu'il s'agit.

Sources, consultées le 21 septembre 2026 : billet officiel de la spécification 2026-07-28 du Model Context Protocol, publié le 28 juillet 2026 par David Soria Parra et Den Delimarsky — suppression de la poignée de main et de l'en-tête de session, requêtes à plusieurs allers-retours, en-têtes Mcp-Method et Mcp-Name, paramètres ttlMs et cacheScope, validation d'émetteur RFC 9207, passage des enregistrements dynamiques aux Client ID Metadata Documents, extension Tasks, fenêtre de dépréciation de douze mois, et les chiffres de téléchargement des bibliothèques. Le document conjoint de la NSA et de la CISA sur la conception sécurisée de MCP est daté du 2 juin 2026 et hébergé sur nsa.gov ainsi que sur media.defense.gov : les deux adresses refusent les requêtes automatisées depuis mon serveur, je n'ai donc pas lu son contenu et n'en cite rien. Les trois questions d'exploitation de la fin sont les miennes, pas une recommandation officielle.

Un serveur MCP en production chez vous ?

La question utile n'est pas ce que le protocole permet, mais sous quel compte il tourne et qui peut le joindre. Ça se vérifie en une heure.

Demander un premier échange