Le Model Context Protocol (MCP) n’est plus une curiosité de labo. La spécification datée du 28 juillet 2026 vient de poser des fondations sérieuses, et l’écosystème a franchi la barre des 9 000 serveurs recensés dans les registres publics. Je fais tourner une flotte de routines pilotées par MCP au quotidien — voilà ce qui change concrètement.
Les nouveautés de la spec 2026-07-28
| Nouveauté | Ce que ça change |
|---|---|
| Cœur « stateless » | Sans état : plus simple à héberger derrière du HTTP standard et à scaler. |
| MCP Apps | Exposer de vraies applications, pas seulement des outils isolés. |
| Extension Tasks | Gérer proprement les traitements longs et asynchrones. |
| Politique de dépréciation | Un cadre clair pour faire évoluer le protocole sans tout casser. |
OAuth 2.1 et la bascule stdio → HTTP
Le mouvement de fond, c’est le passage du transport stdio (local, pratique pour bricoler) vers le HTTP hébergé, et des simples clés d’API vers OAuth 2.1, désormais imposé pour les serveurs distants. Plus de friction à la mise en place, mais la bonne direction : un serveur MCP distant qui expose des outils manipule des données réelles, il ne peut pas se contenter d’une clé en dur.
Ce que ça change pour un dev qui l’utilise
Si vous avez prototypé vos serveurs MCP en stdio avec une clé d’API, la trajectoire est claire : HTTP stateless + OAuth. Ce n’est pas urgent, mais chaque serveur que vous écrivez maintenant, autant le penser dans ce sens.
MCP passe de l’expérimentation à l’infrastructure. Le bon réflexe : arrêter de le traiter comme un gadget, commencer à l’architecturer comme une dépendance de prod.
Ce que j’en retiens
La spec du 28 juillet, ce n’est pas un feu d’artifice de fonctionnalités — c’est de la plomberie sérieuse : stateless, dépréciation cadrée, auth carrée. C’est précisément ce qui manquait pour bâtir dessus sans avoir peur que le sol se dérobe.
Pour aller plus loin
La spécification complète est publiée sur le site officiel du Model Context Protocol.
