Spécification MCP du 28 juillet 2026 : ce qui casse (et ce qui devient plus simple) pour votre CRM sur mesure

Si votre CRM ou ERP sur mesure expose déjà des outils à des assistants IA via le Model Context Protocol (MCP) — ou si c'est prévu dans votre roadmap — la spécification publiée le 28 juillet 2026 sur blog.modelcontextprotocol.io mérite un audit technique. C'est, selon les mainteneurs du protocole, le changement le plus important depuis l'ajout de l'authorization. Voici précisément ce qui change, vérifié sur la source officielle.

Fin de la session persistante : le cœur du protocole devient stateless

Le handshake initialize/initialized et l'en-tête Mcp-Session-Id disparaissent. Chaque requête porte désormais elle-même l'identité du client, la version du protocole et ses capacités dans un champ _meta. Conséquence directe pour l'infrastructure : votre serveur MCP n'a plus besoin de stockage de session partagé ni de connexions persistantes, et peut être distribué derrière un simple répartiteur de charge round-robin, sans sticky sessions.

Le point tricky : si un de vos outils MCP gère un processus en plusieurs étapes (un assistant qui construit une commande CRM pas à pas, par exemple), vous ne pouvez plus compter sur une session serveur pour porter cet état. La spécification impose de faire émettre un "handle" explicite par l'outil et de le faire porter par le modèle lui-même d'un appel à l'autre, en argument. L'état ne vit plus dans la couche transport, il vit dans les arguments de l'outil — c'est un changement d'architecture, pas un simple correctif.

Multi Round-Trip Requests : fini les connexions ouvertes pour une confirmation utilisateur

Avant cette version, un outil qui devait demander une confirmation ou une information manquante à l'utilisateur (elicitation, sampling) devait maintenir un flux bidirectionnel ouvert. Désormais, le serveur répond simplement resultType: "input_required" avec les informations attendues, et le client relance l'appel avec les réponses dans inputResponses.

Pour un CRM métier, c'est directement pertinent : un outil qui demande "confirmez-vous la suppression de ces 40 contacts ?" avant d'agir n'a plus besoin d'un flux ouvert — ce qui règle un vrai problème de production, les proxies et pare-feux d'entreprise qui coupent les connexions inactives et cassaient ce genre d'interaction.

Routage obligatoire par en-têtes HTTP

Les en-têtes Mcp-Method et Mcp-Name, auparavant optionnels, deviennent obligatoires sur toute requête HTTP streamable. Concrètement, votre passerelle API ou WAF peut désormais router, appliquer du rate limiting et prendre des décisions d'autorisation directement sur les en-têtes, sans parser le corps JSON de chaque requête — un vrai point de configuration à mettre à jour côté infrastructure, pas seulement côté code applicatif.

Résultats de liste "cacheables" : ttlMs et cacheScope

Les réponses de tools/list, prompts/list, resources/list et resources/read embarquent désormais des champs ttlMs et cacheScope, plus un ordre déterministe garanti. Si un assistant IA interroge régulièrement le catalogue d'outils de votre CRM, renseigner ces champs côté serveur réduit directement le trafic de re-fetch répété — une optimisation concrète à implémenter, pas une simple recommandation théorique.

Durcissement de l'autorisation : le Dynamic Client Registration en sursis

• →Les serveurs d'autorisation doivent désormais renvoyer le paramètre iss (RFC 9207), que les clients doivent valider avant d'échanger un code d'autorisation
• →Le paramètre application_type doit être précisé lors du Dynamic Client Registration, notamment pour les applications desktop/CLI, pour éviter un rejet des redirections localhost
• →Les identifiants client sont désormais liés à l'autorité qui les a émis — plus de réutilisation d'un serveur d'autorisation à l'autre
• →Le Dynamic Client Registration (DCR) est formellement déprécié au profit des Client ID Metadata Documents (CIMD), avec une fenêtre de transition annoncée d'au moins 12 mois

Si l'inscription OAuth de votre CRM aux serveurs MCP tiers repose sur le DCR, le protocole reste fonctionnel pendant cette fenêtre — mais la migration vers CIMD se planifie maintenant, pas à l'approche de l'échéance.

Ce qui est officiellement déprécié à anticiper dans votre roadmap

• →Les fonctionnalités Roots, Sampling et Logging sont dépréciées, avec une fenêtre de transition de 12 mois
• →Le transport HTTP+SSE est officiellement déprécié au profit du HTTP/JSON-RPC standard
• →Les SDK TypeScript, Python, Go et C# sont mis à jour vers la version 2026-07-28 ; le SDK Rust reste en bêta

Auditer une implémentation MCP existante ou cadrer son intégration à un CRM ou ERP sur mesure demande de trancher ces points d'architecture avant d'écrire du code d'intégration côté client IA. Si vous voulez qu'on fasse cet audit technique avec vous, contactez-nous directement — réponse sous 24h.