MCP a été conçu pour un humain devant son ordinateur portable. La feuille de route 2026 consiste à le retirer
By Surya Pratap
24 août 2026
12 min de lecture
IA et technologie
24 août 2026
12 min de lecture
Quatre hypothèses, quatre remplacementsHover to exploreLa feuille de route du Model Context Protocol a été mise à jour le 22 août 2026, et le troisième axe prioritaire contient la phrase la plus éclairante écrite cette année sur l'infrastructure des agents :
L'autorisation MCP suppose une personne devant un navigateur au moment du consentement.
Relisez les quatre autres axes après celui-là et ils cessent de ressembler à une liste de fonctionnalités. C'est un seul chantier sur cinq fronts : le protocole a été conçu pour quelqu'un assis devant un ordinateur portable, et la production ne cesse de découvrir qu'il n'y a personne.
Ce recadrage mérite une après-midi d'attention, car chaque point de la feuille de route correspond à un problème que vous réglez déjà à la main, en général mal, et en général sans avoir remarqué que vous preniez une décision.
La feuille de route le dit explicitement : il s'agit d'un document de priorisation, pas d'un calendrier de livraison. Les SEP — Specification Enhancement Proposals — qui relèvent de ces axes « bénéficient d'une revue accélérée et ont les meilleures chances d'être acceptées ». Tout le reste attend.
Les cinq axes, et l'hypothèse humaine que chacun supprime
Axes prioritaires de la feuille de route 2026
stdio devenant du HTTP parlé sur stdin/stdout.tools/call que tout le monde interpréterait pareil. Ni l'un ni l'autre n'a tenu.Les quatre premiers relèvent de l'architecture. Le cinquième porte sur la façon dont les quatre autres vous parviennent, ce qui compte plus qu'il n'y paraît : c'est la différence entre un changement de spécification qui arrive dans votre SDK en quelques semaines et un qui met des mois.
Avant la feuille de route, il y a eu une version. La spécification 2026-07-28 a rendu le cœur du protocole sans état, et c'est le changement le plus susceptible de toucher un système que vous exploitez aujourd'hui.
Concrètement, elle a supprimé la poignée de main initialize/initialized et l'en-tête Mcp-Session-Id. Chaque requête porte désormais sa propre version de protocole, son identité client et ses capacités dans _meta. La conséquence, selon la formulation de la spécification elle-même, est que n'importe quelle requête peut atterrir sur n'importe quelle instance de serveur derrière un simple répartiteur de charge round-robin, sans stockage partagé.
Pourquoi la suppression d'une poignée de main devrait intéresser un fondateur
Les sessions avec état se battent contre les répartiteurs de charge. Si vous avez déployé un serveur MCP distant sur plus d'une instance, vous avez soit épinglé les sessions, soit partagé l'état via Redis, soit fait tourner discrètement une seule machine en croisant les doigts. Ces trois solutions contournent une hypothèse que le protocole vient de supprimer. Si vous avez construit l'un de ces contournements, c'est désormais du poids mort plutôt qu'une complexité nécessaire, et il vaut mieux le supprimer délibérément que le traîner dans votre prochain projet.
Trois autres nouveautés de la même version passent facilement inaperçues et servent immédiatement :
resultType: "input_required", le client rejoue l'appel initial avec les réponses dans inputResponses. Validation humaine, sans que la connexion soit ce qui porte l'état.Mcp-Method et Mcp-Name, si bien que passerelles, limiteurs de débit et WAF peuvent router et mesurer sur les en-têtes au lieu de décortiquer du JSON. Si vous avez déjà voulu des limites de débit par outil en périphérie, voilà le point d'accroche qui manquait.ttlMs et cacheScope sur les résultats de liste et les lectures de ressources. Petit champ, grosse facture : c'est la différence entre recharger le catalogue d'outils à chaque session et le recharger quand il change.De tout ce que contient la feuille de route, c'est le point qu'un fondateur ressent en premier, et celui qu'on classe le plus volontiers parmi les commodités.
La feuille de route pose que les serveurs « ont besoin de plus d'options pour guider les clients à travers de grands ensembles d'outils », et que les clients devraient « découvrir les outils et ressources d'un serveur au fur et à mesure de leurs besoins plutôt que d'ingérer le catalogue complet d'emblée ».
Voici pourquoi c'est une ligne sur votre facture. Aujourd'hui, le catalogue d'outils entre dans la fenêtre de contexte au début de la session. Tous les outils. Toutes les descriptions. Tous les schémas de paramètres. À chaque tâche. Branchez quatre ou cinq serveurs MCP un peu sérieux et vous dépensez des milliers de jetons avant que le modèle ait lu la première phrase de l'utilisateur, puis vous repayez à la tâche suivante, et à celle d'après.
C'est le même défaut qu'un AGENTS.md trop exhaustif, entré par une autre porte : du contenu chargé sans condition, que la tâche en ait besoin ou non. Le remède est le même dans les deux cas — rendre le chargement conditionnel — et un seul des deux a un groupe de travail qui construit le mécanisme à votre place.
Deux conséquences. Tant que la découverte progressive n'existe pas, le nombre de serveurs MCP que vous branchez est une décision de coût en direct, pas une décision de capacité, et le bon réglage par défaut consiste en moins de serveurs aux jeux d'outils plus étroits. Et quand elle existera, les serveurs qui en profiteront seront ceux dont les outils auront été organisés en quelque chose qu'un client peut parcourir — un choix de conception que vous pouvez faire dès maintenant, dans la façon dont vous regroupez et nommez vos outils, avant que le moindre mécanisme ne soit livré.
La feuille de route note aussi que la découverte progressive a une « interaction définie avec les travaux sur le cache », autrement dit que découverte et cache par TTL sont conçus pour fonctionner ensemble plutôt que de se percuter. C'est le genre de détail qui décide si une fonctionnalité est utilisable la première année ou la troisième.
Le troisième axe prioritaire est celui qui nomme le problème à voix haute. La description que la feuille de route donne de l'état actuel :
Les serveurs MCP existants s'appuient sur des clés d'API collées et des jetons de rafraîchissement à longue durée de vie.
C'est une description exacte de presque tous les systèmes d'agents en production aujourd'hui, y compris beaucoup qui se décriraient comme sécurisés. Les travaux priorisés en réponse :
Ce qui est en cours de normalisation, et ce que cela remplace
Groupe de travail Identité des agents, en cours de formation sur cette période
Le volet délégation mérite qu'on insiste, car c'est celui qui correspond à une véritable erreur d'architecture. Quand un agent lance un sous-agent aujourd'hui, ce dernier tourne presque toujours avec les identifiants du parent, parce que les restreindre exige une mécanique que personne n'a construite. Autrement dit, le rayon d'impact de l'étape la moins fiable de votre chaîne devient le rayon d'impact de toute la chaîne. C'est le mécanisme, pas une hypothèse, et c'est la conclusion à laquelle nous étions arrivés par l'autre bout dans Les agents IA ont besoin de systèmes de permissions, pas de meilleurs prompts.
Une mise en garde, la même que pour la consolidation des protocoles évoquée la semaine dernière : l'identité répond à qui appelle. Elle ne répond pas à si ce qui est demandé est une bonne idée. Un agent parfaitement authentifié qui a lu une instruction malveillante sur une page web passera son appel malveillant avec des identifiants impeccables. Tout ce que dit le guide de sécurité des agents sur le traitement du contenu visible par le modèle comme non fiable survit intact.
Une feuille de route n'est pas une date de livraison. Le document le dit lui-même : « une réflexion en cours plutôt que des engagements fermes », sur un horizon de six à douze mois. Deux des cinq axes ont encore des groupes de travail en cours de formation.
La bonne question n'est donc pas « qu'est-ce que j'attends ». C'est « qu'est-ce que cela m'apprend sur l'endroit où placer les coutures ».
tools/call est en cours de refonte parce que content et structuredContent ont produit des implémentations divergentes. N'investissez pas dans un traitement astucieux d'une forme inscrite sur la liste des changements.La carte du milieu porte tout le poids. Chaque point des quatre premiers axes correspond à un problème qu'une équipe qui livre aujourd'hui règle de façon informelle. La valeur de la feuille de route pour un fondateur, c'est qu'elle indique lesquelles de vos solutions informelles sont temporaires par conception — et ce sont exactement celles qui méritent une interface plutôt que d'être disséminées dans le code.
Concrètement, pour une équipe qui construit un produit à base d'agents ce trimestre : si la gestion des identifiants, celle des tâches longues et la constitution du catalogue d'outils vivent chacune à un seul endroit, avec une surface réduite, vous adopterez les standards quand ils arriveront dans votre SDK et ce sera un non-événement. Si elles sont étalées sur les points d'appel, vous ne les adopterez pas, et vous appellerez cela un arbitrage de priorités.
Trois points à énoncer clairement, car une feuille de route bien écrite crée une légère illusion de couverture.
Elle ne rend pas les agents fiables. Tout ce qui figure ici relève du transport, de l'identité et de la découverte. Rien ne touche à la question de savoir si le modèle a choisi le bon outil, correctement lu le résultat, ou aurait dû s'arrêter. Cela reste un problème d'évaluation, et il reste le vôtre.
Elle ne raccourcit pas votre chaîne de dépendances. Un cœur sans état et un transport unifié rendent plus facile le branchement de serveurs supplémentaires. Facile n'est pas gratuit : chaque serveur branché est un coût de contexte, un mode de défaillance et une frontière de confiance. Un protocole meilleur en connexions n'est pas un argument pour multiplier les connexions.
Elle n'arrive pas selon un calendrier planifiable. Deux groupes de travail se forment encore. Les tâches restent une extension en route vers « son inclusion à terme dans le protocole central ». Planifier raisonnablement, c'est traiter chaque point comme susceptible d'arriver dans votre SDK l'an prochain, et construire comme s'il pouvait ne pas arriver.
La feuille de route MCP mise à jour le 22 août est un meilleur document stratégique que ce que la plupart des entreprises écrivent sur elles-mêmes, parce qu'elle nomme sa propre hypothèse erronée en langage clair au lieu de présenter le correctif comme une innovation. Le protocole a été conçu pour une personne avec un navigateur, sur un portable, attendant deux secondes la réponse d'une poignée d'outils. Ces quatre propositions sont aujourd'hui fausses en production, et la feuille de route est le travail de les défaire.
Pour un fondateur, le contenu utile n'est pas la liste de fonctionnalités. C'est la confirmation que quatre des choses que vous contournez aujourd'hui — des identifiants pour des utilisateurs absents, du travail qui survit à une requête, des catalogues trop gros pour être chargés, et un transport qui se comporte autrement sur un portable que dans un cluster — sont temporaires par conception, prises en charge par des gens identifiés, et méritent une interface dès maintenant.
Construisez la version grossière. Gardez la couture. Supprimez les contournements qui ont déjà un standard.
Sources : Model Context Protocol — feuille de route, mise à jour le 2026-08-22 · La spécification 2026-07-28, blog MCP · SEP-2575, MCP sans état · SEP-2549, TTL pour les résultats de liste · SEP-2663, extension Tâches · Groupes de travail et d'intérêt
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
