Aller au contenu

Le média des artisans du web mercredi 19 août 2026

IA pour le web

MCP se stabilise : ce que change la spécification du 28 juillet

Cœur sans état, MCP Apps, extension Tasks, politique de dépréciation : la spécification du 28 juillet fait passer le Model Context Protocol du prototype à l'infrastructure.

MCP se stabilise : ce que la spec du 28 juillet change pour les devs qui l'utilisent

Le Model Context Protocol (MCP) a quitté le statut de curiosité de laboratoire. La spécification datée du 28 juillet 2026 stabilise ses fondations, et les registres publics recensent désormais plus de 9 000 serveurs. Pour les équipes qui branchent des agents sur des outils réels, cette version marque le passage d’un protocole expérimental à une dépendance d’infrastructure.

Ce que contient la spécification 2026-07-28

NouveautéEffet pratique
Cœur sans étatHébergement derrière du HTTP standard et mise à l’échelle horizontale simplifiés
MCP AppsExposition d’applications complètes, et non plus seulement d’outils isolés
Extension TasksPrise en charge cadrée des traitements longs et asynchrones
Politique de dépréciationCadre explicite d’évolution du protocole, sans rupture non annoncée

De stdio à HTTP, et de la clé d’API à OAuth 2.1

La bascule de fond de MCP Hier Transport stdio (local) Clé d’API en dur Aujourd’hui HTTP hébergé (sans état) OAuth 2.1
Le mouvement structurant : du transport local avec clé d’API vers du HTTP hébergé authentifié par OAuth 2.1.

Le transport stdio, commode pour prototyper en local, cède la place au HTTP hébergé. Dans le même mouvement, les clés d’API statiques sont remplacées par OAuth 2.1, désormais requis pour les serveurs distants. La mise en place est plus lourde, mais la cohérence est difficile à contester : un serveur MCP distant expose des outils qui écrivent dans des systèmes réels — bases de données, CMS, outils de mesure. Ce niveau d’accès ne se protège pas avec une chaîne de caractères en dur.

Conséquences pour les équipes qui l’utilisent déjà

Les serveurs prototypés en stdio avec une clé d’API continueront de fonctionner, mais la trajectoire du protocole est explicite : HTTP sans état et OAuth. Aucune migration n’est imposée à court terme ; en revanche, tout nouveau serveur écrit aujourd’hui gagne à adopter cette cible directement, sous peine d’une réécriture ultérieure.

Point d’attention : la politique de dépréciation introduite par cette spécification est la nouveauté la plus structurante pour la maintenance. C’est elle qui permet d’engager des développements sur MCP sans risquer une rupture silencieuse à la version suivante.

Ce qu’il faut retenir

La spécification du 28 juillet n’apporte pas de fonctionnalité spectaculaire. Elle apporte ce qui manquait pour construire dessus : un cœur sans état, une authentification standard et un cadre d’évolution annoncé. C’est le vocabulaire d’une brique d’infrastructure, plus celui d’un prototype.

Je fais tourner des routines éditoriales pilotées par MCP en production depuis plus d’un an. Le passage à OAuth 2.1 a coûté une demi-journée de configuration par serveur, et c’est la meilleure demi-journée que j’aie investie sur ce sujet : les clés d’API en dur étaient la seule partie de la chaîne dont je n’aurais pas voulu parler en audit. — Simon Janvier

Pour aller plus loin

La spécification complète est publiée sur le site officiel du Model Context Protocol.

À lire aussi sur Mail Studio

En vidéo

Partager LinkedIn Bluesky Hacker News E-mail

À lire aussi