MCP 2026-07-28 : ce qui change pour brancher des agents IA sur votre SI

Publiée le 28 juillet 2026, la spécification MCP 2026-07-28 est la révision la plus structurante du Model Context Protocol depuis sa création : protocole sans état, requêtes multi-allers-retours, en-têtes de routage, autorisation durcie. Voici ce qui change concrètement pour connecter des agents IA à votre ERP, votre CRM ou votre ticketing, avec une architecture type, les règles de sécurité et une checklist de migration.

MCP en 2026 : le rappel express

Le Model Context Protocol standardise la façon dont une application d’IA (l’hôte : IDE, assistant, agent) se connecte à des serveurs qui exposent des outils, des ressources et des prompts. Vous écrivez un serveur MCP pour votre CRM, et tout client compatible peut l’utiliser.

• 25 novembre 2024 : Anthropic publie MCP en open source.
• 9 décembre 2025 : MCP est confié à l’Agentic AI Foundation, un fonds de la Linux Foundation cofondé par Anthropic, Block et OpenAI. Le protocole n’appartient plus à un seul éditeur.
• 28 juillet 2026 : publication de la spécification 2026-07-28. Selon l’annonce officielle, les SDK de Tier 1 approchent le demi-milliard de téléchargements par mois.

Les 7 changements de la spécification MCP 2026-07-28

1. Un cœur sans état

C’est le changement majeur (SEP-2575 et SEP-2567). La poignée de main initialize et l’en-tête Mcp-Session-Id disparaissent. Chaque requête transporte dans _meta sa version de protocole et les capacités du client. Une nouvelle méthode server/discover, obligatoire côté serveur, permet au client de connaître à l’avance les versions et capacités supportées.

Conséquence : une requête peut atterrir sur n’importe quelle instance derrière un répartiteur de charge. Si un outil a besoin d’un état entre deux appels (panier, transaction), le serveur crée un identifiant explicite (un « handle ») que le modèle repasse en argument.

2. Les Multi Round-Trip Requests

Avant, un serveur qui avait besoin d’une information en cours d’appel envoyait lui-même une requête au client sur un flux ouvert. Désormais (SEP-2322), il répond avec un résultat intermédiaire, et le client rejoue la requête d’origine avec les réponses :

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirmation": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Créer l'avoir de 1 240 € pour le client C-0042 ?",
          "requestedSchema": {
            "type": "object",
            "properties": { "confirme": { "type": "boolean" } },
            "required": ["confirme"]
          }
        }
      }
    },
    "requestState": "eyJhdm9pciI6IkMtMDA0MiJ9"
  }
}

Le client pose la question à l’utilisateur, puis renvoie le même tools/call (nouvel id) avec inputResponses et requestState. Pour un SI, c’est une excellente nouvelle : la confirmation humaine d’une action sensible devient un mécanisme standard du protocole.

3. Le routage par en-têtes

Sur le transport Streamable HTTP, chaque POST porte Mcp-Method et, pour tools/call, resources/read et prompts/get, Mcp-Name (nom de l’outil, du prompt ou URI de la ressource) (SEP-2243). Un paramètre d’outil peut être recopié dans un en-tête Mcp-Param-{nom} via x-mcp-header, jamais pour des données sensibles. Le serveur doit rejeter toute requête dont les en-têtes ne correspondent pas au corps (HeaderMismatch, code -32020) : une passerelle qui route sur l’en-tête ne peut pas être trompée par un corps différent.

4. Des résultats de liste cachables

Les réponses à tools/list, prompts/list, resources/list, resources/read et resources/templates/list incluent désormais ttlMs (fraîcheur en millisecondes) et cacheScope (public ou private) (SEP-2549), et les outils devraient être renvoyés dans un ordre déterministe, ce qui améliore aussi le cache de prompt des modèles. Si la liste d’outils dépend des droits de l’appelant, c’est private.

5. Une autorisation durcie

• RFC 9207 (SEP-2468) : les serveurs d’autorisation devraient renvoyer le paramètre iss, et le client doit le valider avant d’échanger le code. Cela bloque les attaques par confusion de serveurs d’autorisation (« mix-up »), que PKCE seul n’empêche pas.
• application_type obligatoire lors de l’enregistrement dynamique (SEP-837), pour les applications de bureau et CLI.
• Identifiants liés à l’émetteur (SEP-2352) : jamais réutilisés auprès d’un autre serveur d’autorisation.
• Dynamic Client Registration dépréciée au profit des Client ID Metadata Documents (CIMD), tout en restant disponible pour la compatibilité.

6. Un cadre d’extensions

Les capacités client et serveur gagnent un champ extensions. Les tâches longues quittent le cœur pour l’extension io.modelcontextprotocol/tasks (interrogation via tasks/get, nouvelle méthode tasks/update, SEP-2663). Selon l’annonce officielle, le cadre couvre aussi MCP Apps et l’Enterprise Managed Authorization. Les notifications de changement passent par un unique flux subscriptions/listen, auquel le client s’abonne par type de notification.

7. Dépréciations et SDK

Roots, Sampling et Logging sont dépréciés (SEP-2577) mais restent fonctionnels au moins douze mois : passez les répertoires en paramètres d’outil, appelez directement l’API du modèle, journalisez via stderr ou OpenTelemetry. Le transport HTTP+SSE est déprécié et la reprise des flux SSE (Last-Event-ID) supprimée : un flux coupé impose de relancer la requête.

Les quatre SDK de Tier 1 (TypeScript, Python, Go, C#) implémentaient la révision dès sa publication, Rust en bêta. Le tableau officiel des SDK classe aujourd’hui Rust en Tier 1 (100 % de réussite aux tests de conformité exigés), Java et Ruby en Tier 2, PHP, Kotlin et Swift en Tier 3. Pour une stack PHP, c’est à arbitrer : SDK de Tier 3, ou serveur MCP en TypeScript ou Go devant votre application Symfony ou Laravel.

Brancher des agents sur votre SI : l’architecture type

Voici l’architecture que nous recommandons pour exposer un SI à des agents autonomes :

• Hôte d’agent (IDE, assistant interne, agent de tickets) : modèle, outils autorisés, confirmations utilisateur.
• Passerelle MCP : point d’entrée unique, OAuth, filtrage par Mcp-Method / Mcp-Name, limitation de débit, journal d’audit.
• Serveurs MCP par domaine : ERP, CRM, ticketing, documentation.
• Fournisseur d’identité : jetons à portée minimale, émis pour chaque serveur MCP.
• Systèmes métier, via leurs API ou une réplique en lecture, jamais en écriture directe sur la base de production.

Un serveur MCP par domaine métier

Découper par domaine limite l’impact d’un serveur compromis, simplifie les portées OAuth et rend l’audit lisible. Évitez le serveur « fourre-tout » : le modèle choisit aussi moins bien parmi trop d’outils.

Exemple : exposer une base Postgres en lecture seule

La barrière doit être dans la base, pas dans le prompt. Sur une réplique :

CREATE ROLE mcp_lecture LOGIN;  -- mot de passe injecté depuis le coffre-fort
ALTER ROLE mcp_lecture SET default_transaction_read_only = on;
ALTER ROLE mcp_lecture SET statement_timeout = '5s';
GRANT CONNECT ON DATABASE crm TO mcp_lecture;
GRANT USAGE ON SCHEMA reporting TO mcp_lecture;
GRANT SELECT ON ALL TABLES IN SCHEMA reporting TO mcp_lecture;

default_transaction_read_only peut être modifié par la session : c’est une seconde barrière. La vraie protection, ce sont les droits limités à SELECT sur un schéma de vues qui masquent les colonnes sensibles.

Sécurité : les règles non négociables

Lecture seule par défaut et liste blanche

Lors de notre expérimentation EXP-01 du iones lab, une équipe de 8 développeurs a utilisé 5 serveurs MCP pendant 8 semaines : Redmine en lecture, Postgres en lecture seule, Playwright, documentation projet et Git. Un serveur MCP en écriture sur Redmine a été abandonné après 2 tickets modifiés par erreur. Depuis, notre règle est simple : lecture seule par défaut, écriture uniquement sur une liste blanche explicite.

Exemple de politique appliquée par la passerelle (format illustratif, à adapter à votre outil) :

serveurs:
  crm:
    outils_autorises: [client_rechercher, historique_contacts, note_creer]
    confirmation_humaine: [note_creer]      # via MRTR / confirmation de l'hôte
  ticketing:
    outils_autorises: [ticket_lire, tickets_similaires]
  base_reporting:
    outils_autorises: [requete_lecture]
par_defaut: refuser                         # tout outil non listé est bloqué
epinglage_descriptions: sha256              # alerte si une description d'outil change

La spécification va dans ce sens : pour les outils, il devrait toujours y avoir un humain dans la boucle capable de refuser un appel, et les annotations d’outil (comme readOnlyHint ou destructiveHint) doivent être considérées comme non fiables, sauf si elles viennent de serveurs de confiance.

OAuth : ce que la spécification impose

Les bonnes pratiques de sécurité MCP sont explicites :

• Pas de « token passthrough » : un serveur MCP n’accepte que des jetons émis pour lui et ne relaie jamais ceux du client vers une API en aval.
• Portées minimales : lecture d’abord, élévation à la demande, jamais * ou admin d’emblée.
• Handles d’état aléatoires, liés côté serveur à l’utilisateur authentifié : posséder un handle ne vaut pas authentification.
• Serveurs locaux : commande exacte affichée avant exécution, bac à sable, écoute sur localhost uniquement.

Prompt injection et tool poisoning

Un agent lit des contenus qu’il ne contrôle pas : tickets, e-mails, pages web. Une instruction cachée dans un ticket peut tenter de détourner l’agent : c’est la prompt injection, toujours en tête (LLM01) du Top 10 OWASP 2026 pour les applications LLM. Variante propre à MCP, le tool poisoning, décrit par Invariant Labs le 1er avril 2025 : des instructions malveillantes sont cachées dans la description d’un outil, invisible pour l’utilisateur mais lue par le modèle.

Contre-mesures :

• serveurs dont vous maîtrisez le code ou l’éditeur, uniquement ;
• épinglage des descriptions d’outils (empreinte), alerte en cas de changement ;
• contenu renvoyé par un outil traité comme une donnée, jamais comme une instruction ;
• séparation des flux : un agent qui lit des e-mails externes n’écrit pas dans l’ERP ;
• blocage côté passerelle de toute action non listée.

Dans notre expérimentation EXP-06 sur les agents autonomes, la liste blanche d’actions et le blocage de toute commande touchant la production ont intercepté 7 actions risquées, dont 2 suppressions de données de test. Ces garde-fous se transposent tels quels à des outils MCP.

Déploiement cloud-native : ce que le sans-état simplifie

Avant 2026-07-28, un serveur MCP HTTP avec sessions imposait l’affinité de session ou un stockage partagé. Désormais :

• Mise à l’échelle horizontale : des réplicas identiques derrière un répartiteur en round-robin, avec un autoscaling Kubernetes classique.
• Déploiements sans coupure : aucune session à migrer ; un flux interrompu est simplement relancé.
• Politiques réseau par en-tête, par exemple limiter les appels d’outils plus strictement que les lectures de liste :

map $http_mcp_method $mcp_cle_outils {
    default       "";
    "tools/call"  $binary_remote_addr;
}
limit_req_zone $mcp_cle_outils zone=mcp_outils:10m rate=5r/s;

server {
    location /mcp {
        limit_req zone=mcp_outils burst=10;
        proxy_buffering off;   # flux SSE
        proxy_pass http://serveurs_mcp;
    }
}

• Observabilité : propagation du contexte de trace OpenTelemetry (traceparent) dans _meta, de l’agent jusqu’au système métier.

C’est le chantier que nous menons côté infrastructure, DevOps et sécurité web : conteneurs, Kubernetes (AWS, OVHcloud), supervision Grafana, secrets.

Migrer depuis 2025-11-25 : la checklist

• [ ] Inventorier serveurs, clients, SDK et versions ; mettre à jour les SDK (changements cassants)
• [ ] Supprimer toute dépendance à Mcp-Session-Id ; remplacer l’état implicite par des handles liés à l’utilisateur
• [ ] Remplacer les requêtes initiées par le serveur par le schéma MRTR
• [ ] Ajouter ttlMs et cacheScope aux listes ; ordonner les outils de façon déterministe
• [ ] Valider iss, lier les identifiants à l’émetteur, prévoir CIMD
• [ ] Router et filtrer sur Mcp-Method / Mcp-Name dans la passerelle
• [ ] Remplacer Logging par OpenTelemetry et Sampling par un appel direct au modèle
• [ ] Tester la compatibilité avec les clients anciens, revoir liste blanche et portées OAuth

Questions fréquentes

MCP 2026-07-28 : le bon moment pour industrialiser vos connecteurs d’agents

La spécification 2026-07-28 fait de MCP un protocole d’infrastructure : sans état, routable, cachable, avec une autorisation alignée sur les bonnes pratiques OAuth. Le périmètre, la lecture seule, la liste blanche et la supervision restent votre responsabilité.

Vous voulez connecter des agents à votre ERP, votre CRM ou votre ticketing sans ouvrir de brèche ? Nous concevons et déployons des serveurs MCP et des agents autonomes avec leurs garde-fous, en direct ou en marque blanche pour les agences. Contactez-nous : réponse sous 48 à 72 h, sous NDA.