La révision MCP du 28 juillet 2026 change un choix d’architecture : une requête doit pouvoir être traitée sans dépendre d’une session de protocole conservée sur une instance. Pour une équipe qui exploite des agents, la question devient très concrète : que se passe-t-il lorsqu’un serveur redémarre entre deux appels, ou lorsqu’une action doit être reprise après une coupure ?
Le Model Context Protocol relie les applications d’IA à des outils et des données. La nouvelle révision ne rend pas automatiquement un agent fiable ; elle modifie les responsabilités entre client, passerelle et serveur. Voici une méthode de migration pour les équipes produit et plateforme, fondée sur la spécification publiée et distinguée des fonctionnalités encore inscrites dans la feuille de route.
Que change MCP 2026-07-28 pour un serveur en production ?
MCP 2026-07-28 adopte un noyau de protocole sans état de session : les appels portent les informations nécessaires à leur traitement. Selon l’annonce des mainteneurs du 28 juillet, le dialogue initial initialize/initialized et l’en-tête de session disparaissent dans cette révision, tandis que server/discover permet au client de découvrir les capacités avant ses appels.
Considérons un service documentaire réparti sur plusieurs instances. Un appel de recherche arrive sur la première ; la lecture d’un résultat arrive sur la seconde. L’application doit retrouver le document à partir d’un identifiant explicite et de l’identité autorisée, sans dépendre d’un objet conservé uniquement dans la mémoire de la première instance. Cet exemple est un scénario d’architecture proposé ici, pas une mesure de performance du protocole.
La migration mérite donc un inventaire préalable. Relevez où sont stockés les curseurs de pagination, les références de fichiers, les autorisations temporaires et les opérations en attente. Une valeur utile au métier doit appartenir au contrat de l’outil ou à un stockage applicatif approprié. Un détail de transport ne devrait pas décider si une opération peut être poursuivie.
Sans session signifie-t-il sans état métier ?
Un serveur MCP sans session de protocole peut toujours gérer un état métier. La spécification MCP organise des échanges JSON-RPC entre clients et serveurs ; elle ne remplace ni une base de données ni les règles d’un processus métier.
Une demande de remboursement possède un statut, une version et un historique. Un agent peut recevoir un identifiant de demande, puis le transmettre à un outil de consultation ou de modification. Le serveur vérifie à chaque appel que l’utilisateur peut accéder à cette demande. La suppression d’une session de transport ne justifie jamais de supprimer cette vérification.
Notre recommandation est de documenter chaque identifiant échangé : qui peut le créer, qui peut le lire, quand il expire et comment il est invalidé. Traitez séparément les identifiants opaques et les secrets. Un identifiant difficile à deviner ne constitue pas, à lui seul, une autorisation. Cette distinction rejoint les contrôles décrits dans notre analyse sur la prévention des fuites de données par les agents IA.
Une requête explicite facilite le routage ; l’autorisation et l’état métier restent à vérifier par l’application.
Quels tests faut-il ajouter avant la bascule ?
Une migration MCP doit tester les défaillances et les reprises, en plus du succès d’un appel isolé. Le journal des changements précise notamment que la reprise des flux SSE par identifiant d’événement disparaît : un flux interrompu impose au client de réémettre la requête avec un nouvel identifiant.
La conséquence opérationnelle est importante pour les outils qui écrivent. Si une création de ticket réussit mais que sa réponse se perd, un nouvel appel ne doit pas créer un deuxième ticket par accident. L’identifiant JSON-RPC sert à suivre l’échange ; une clé d’idempotence métier, lorsqu’elle est nécessaire, répond à une autre question : cette opération a-t-elle déjà produit son effet ?
Construisez une petite campagne reproductible :
- Interrompre une lecture avant la réponse et vérifier une reprise sans fuite de contexte.
- Couper la connexion après une écriture, puis constater si l’effet existe déjà.
- Rejouer une demande avec une identité différente et vérifier son refus.
- Redémarrer l’instance entre deux étapes du même parcours métier.
- Expirer une autorisation pendant une opération longue et vérifier le comportement prévu.
Conservez les résultats attendus, les traces et les conditions du test. Un succès obtenu une seule fois dans une conversation ne suffit pas à démontrer la robustesse d’un parcours. Les mêmes exigences expliquent une partie des échecs des POC au passage en production.
Comment traiter les demandes d’information complémentaires ?
Le mécanisme Multi Round-Trip Requests, ou MRTR, permet au serveur de demander des informations supplémentaires dans le résultat d’un appel, puis au client de reprendre la demande. Le journal des changements décrit un résultat input_required, distinct d’un résultat complete, pour représenter cet état intermédiaire.
L’interface doit rendre cette différence compréhensible. « Il manque une pièce » ne signifie ni « opération terminée » ni « erreur définitive ». Pour un outil de préparation de contrat, le serveur peut demander un pays d’application ou une validation humaine avant de continuer. L’agent doit présenter cette demande, recueillir la réponse prévue et poursuivre le bon processus.
Dans le plan de recette, associez chaque demande complémentaire à son effet autorisé. Vérifiez qu’une réponse apportée à une ancienne demande ne valide pas une nouvelle opération. Prévoyez aussi l’abandon : l’utilisateur peut fermer la conversation, changer d’objectif ou refuser. Un parcours fiable sait conclure sans produire d’effet lorsque l’information ou l’accord requis n’arrive pas.
Que faut-il revoir dans la passerelle et les caches ?
La passerelle doit distinguer le routage, l’authentification et l’autorisation métier. La révision ajoute des en-têtes portant la méthode et le nom de l’outil ; ces informations aident l’infrastructure à diriger les appels, mais ne dispensent pas le serveur de contrôler les arguments et les droits sur la ressource demandée.
Pour une équipe plateforme, le premier livrable utile est une matrice simple : outil, données accessibles, effet possible, identité attendue et responsable du contrôle. Un outil de recherche et un outil de suppression ne doivent pas partager une politique permissive uniquement parce qu’ils passent par la même URL MCP.
Le cache mérite la même précision. Comparez les catalogues visibles par différents profils et vérifiez qu’un changement de droits prend effet dans le délai attendu. Mesurez les réponses réellement partagées entre utilisateurs. Ne déduisez pas d’une possibilité de cache que toute réponse peut être stockée dans un intermédiaire commun. Une revue de ces décisions peut s’inscrire dans la gouvernance des systèmes d’IA, au même titre que la journalisation et la supervision humaine.
Faut-il migrer immédiatement tous les clients ?
La compatibilité des clients réellement utilisés doit décider du rythme de migration. La feuille de route publiée le 22 août 2026 distingue les changements déjà livrés des travaux à venir, notamment autour de l’identité des agents, de la délégation et de la découverte progressive des outils. Une intention de feuille de route ne doit pas devenir une capacité promise au métier.
Inventoriez les versions prises en charge par chaque client, les SDK déployés et les extensions indispensables. Établissez ensuite une frontière de compatibilité explicite. Une transition peut maintenir temporairement deux chemins documentés ; elle ne doit pas mélanger silencieusement des attentes différentes sous un numéro de version supposé commun.
La décision de bascule devrait reposer sur des critères observables : lectures correctes, écritures sans doublon dans les scénarios de reprise, droits conservés, demandes complémentaires compréhensibles et retour arrière testé. Commencez par un outil limité dont l’effet est réversible. Élargissez lorsque les traces démontrent que le système respecte ces critères. L’intérêt de MCP est d’améliorer l’intégration ; la qualité de production dépend toujours du contrat métier que l’équipe construit autour.
Sources et périmètre
Cette analyse porte sur la révision publiée le 28 juillet 2026 et la feuille de route du 22 août, consultées le 11 septembre 2026. Les scénarios de test et critères de bascule ci-dessus sont des recommandations d’architecture, sans benchmark revendiqué.
