MCP juillet 2026 : audit logs, SSO et tournant enterprise PME

Le Model Context Protocol (MCP) est passé en deux ans du statut de standard expérimental à celui d’infrastructure critique pour les agents IA. Avec plus de 10 000 serveurs publics actifs, 97 millions de téléchargements SDK mensuels et une adoption par 28 % des Fortune 500, MCP est devenu le standard de facto pour connecter les agents IA aux outils d’entreprise.

Mais cette croissance rapide a créé un décalage : l’écosystème est vaste, mais les fonctionnalités enterprise (audit, authentification SSO, gateway centralisée) sont encore immatures. La spécification de juillet 2026, prévue pour le 28 juillet, vise à combler ces gaps. Pour les PME françaises, c’est le moment de se préparer.

Les 4 piliers de la spec enterprise

1. Audit logs natifs

Aujourd’hui, si un agent MCP exécute une action via un serveur (requête SQL, appel API, modification de fichier), la traçabilité dépend de chaque serveur individuellement. Certains loguent tout, d’autres rien. La nouvelle spec introduit un format d’audit log standardisé au niveau du protocole.

Pour les PME, c’est un changement critique :

• Conformité AI Act : l’article 14 impose une traçabilité des actions automatisées. Des audit logs MCP natifs simplifient la conformité. Notre checklist AI Act détaille les obligations.
• Debugging : quand un agent fait une erreur, le log permet de remonter la chaîne d’actions exacte — quel serveur, quelle requête, quelle réponse.
• Facturation : les logs permettent d’attribuer la consommation de chaque agent à un projet ou un département.

2. Authentification SSO intégrée

MCP utilise actuellement OAuth 2.1 pour l’authentification entre clients et serveurs. La spec de juillet ajoute une couche SSO (Single Sign-On) compatible avec les systèmes d’identité d’entreprise (Azure AD, Okta, Google Workspace).

Concrètement, un employé authentifié dans le SSO de l’entreprise n’aura pas besoin de s’authentifier séparément auprès de chaque serveur MCP. Les permissions seront héritées du profil SSO, avec des contrôles granulaires par rôle.

Pour les PME qui utilisent Microsoft 365 ou Google Workspace, l’intégration SSO signifie moins de friction pour les utilisateurs et un contrôle d’accès centralisé. Notre article sur Claude pour Microsoft 365 couvre l’intégration actuelle.

3. Gateway et routing centralisé

Aujourd’hui, chaque agent se connecte directement à chaque serveur MCP. Dans une PME avec 5 agents et 10 serveurs, cela fait 50 connexions potentielles à gérer. La spec de juillet introduit le concept de MCP Gateway : un point d’entrée centralisé qui route les requêtes vers les serveurs appropriés.

Le gateway permet :

• Rate limiting : limiter le nombre de requêtes par agent et par serveur.
• Filtrage : bloquer certaines actions sensibles au niveau du gateway, avant qu’elles n’atteignent le serveur.
• Monitoring : centraliser les métriques de performance et d’usage.
• Failover : basculer automatiquement vers un serveur de secours en cas de panne.

Les MCP Tunnels existants complètent cette architecture pour les connexions au réseau privé.

4. Portabilité de configuration

La fragmentation actuelle de l’écosystème MCP (chaque client a son propre format de configuration) complique les déploiements enterprise. La spec de juillet définit un format de configuration portable : une même définition de serveur peut être déployée dans Claude Code, ChatGPT, Cursor, VS Code ou tout autre client compatible.

Pour les PME multi-outils, c’est la fin du « write once, configure everywhere » : une seule configuration à maintenir, déployée partout.

Impact sur l’écosystème existant

Rétrocompatibilité assurée

Les serveurs MCP existants continueront de fonctionner avec la nouvelle spec. Les nouvelles fonctionnalités (audit, SSO, gateway) sont optionnelles et s’activent progressivement. Les PME qui ont déjà déployé des serveurs MCP en production n’auront pas à tout refaire.

Registre officiel renforcé

Le registre MCP officiel sera enrichi avec des métadonnées de conformité : chaque serveur listé indiquera son niveau de support des fonctionnalités enterprise (audit, SSO, gateway). Les PME pourront filtrer les serveurs par niveau de maturité enterprise.

Sécurité : le chantier prioritaire

Avec 10 000+ serveurs publics et 1 800 serveurs exposés identifiés, la sécurité est le gap le plus critique. La spec de juillet introduit :

• Signature de serveur : vérification cryptographique de l’identité du serveur.
• Sandboxing normalisé : définition claire de ce qu’un serveur peut et ne peut pas faire.
• Alertes de vulnérabilité : intégration dans les systèmes d’alertes CVE existants.

Ce que les PME doivent faire maintenant

Actions immédiates (avant juillet 2026)

1. Inventoriez vos serveurs MCP : listez tous les serveurs utilisés, leur niveau de sécurité et leur source (officiel, communautaire, interne).
2. Activez les logs : même sans la spec, configurez le logging côté client pour chaque connexion MCP. Cela facilitera la migration vers les audit logs natifs.
3. Préparez le SSO : si votre entreprise utilise Azure AD ou Okta, vérifiez que votre provider peut exposer des tokens OAuth 2.1 compatibles MCP.

Actions à planifier (juillet-septembre 2026)

4. Testez la spec RC : dès que la Release Candidate est disponible, testez-la dans un environnement de staging. Les premiers adopteurs enterprise auront un avantage sur la conformité AI Act.
5. Évaluez un gateway : si vous utilisez plus de 5 serveurs MCP, un gateway centralisé simplifiera la gestion. Les premières implémentations open-source devraient apparaître en août-septembre.
6. Mettez à jour vos serveurs internes : si vous avez développé des serveurs MCP custom, planifiez leur mise à niveau pour supporter les audit logs et la signature.

MCP vs alternatives : pourquoi rester sur MCP

L’adoption massive de MCP (97M downloads/mois, 28 % des Fortune 500) crée un effet de réseau difficile à concurrencer. Le protocole A2A de Google reste une alternative pour l’inter-opérabilité entre agents, mais MCP domine pour la connexion agent-outil.

La spec de juillet renforce cette position en comblant les gaps enterprise qui étaient le principal argument contre MCP en production. Pour les PME, miser sur MCP est un choix de plus en plus sûr.

FAQ

La spec MCP stateless de juillet change-t-elle la donne pour les PME ?

La spec MCP stateless (Release Candidate) coexiste avec la spec enterprise de juillet. Le mode stateless simplifie le déploiement de serveurs MCP dans des environnements serverless (Lambda, Cloud Functions), tandis que les fonctionnalités enterprise s’appliquent aux deux modes (stateful et stateless). Les PME qui déploient en serverless bénéficient des deux avancées.

Les serveurs MCP du registre Anthropic supporteront-ils tous la nouvelle spec ?

Pas immédiatement. Le registre officiel listera le niveau de support de chaque serveur (audit, SSO, gateway) via des badges de conformité. Les serveurs officiels Anthropic seront les premiers à supporter la spec complète. Les serveurs communautaires suivront progressivement. Les 13 000+ serveurs du registre incluront une timeline de migration.

Comment le gateway MCP se compare-t-il à un API gateway classique (Kong, Traefik) ?

Le MCP Gateway est spécifique au protocole MCP : il comprend la sémantique des tool calls, des prompts et des resources, pas seulement les requêtes HTTP. Un API gateway classique peut router le trafic réseau, mais il ne peut pas appliquer des règles métier sur le contenu des appels MCP (ex. : bloquer un outil spécifique, limiter les paramètres autorisés). Les deux sont complémentaires : un API gateway gère le réseau, un MCP gateway gère la logique protocolaire.