MCP en 2026 : un standard incontournable, une surface d'attaque en expansion
Le Model Context Protocol (MCP) s'est imposé comme le cadre standard pour encapsuler des ressources, bases de données, systèmes de fichiers, API métier, et les rendre accessibles aux grands modèles de langage (LLM) et aux agents IA. Adopté par l'ensemble des grands éditeurs de modèles et d'outils, il s'utilise aussi bien localement qu'à distance, et son écosystème a explosé : le registre public de serveurs MCP est passé d'environ 1 200 entrées début 2025 à plus de 9 000 mi-2026. Cette croissance a un revers : chaque serveur publié est une porte d'entrée potentielle vers des ressources d'entreprise.
Comme tout cadre flexible, MCP est exposé à des défaillances de cybersécurité qui découlent de choix de conception inadéquats. Ce n'est pas un défaut du standard lui-même : la flexibilité conduit souvent à des combinaisons de choix inappropriées, autrement dit, à des anti-patrons. Les chiffres le confirment : des travaux de recherche ont montré que 43 % des serveurs MCP évalués contenaient des failles d'injection de commandes.
Nous allons examiner l'anti-patron le plus répandu, l'accès non intentionnel aux ressources, et montrer comment le résoudre avec une solution éprouvée : déléguer la sécurité à votre infrastructure API existante.
L'anti-patron des accès non intentionnels aux ressources
MCP peut donner un accès direct à des ressources qui ne disposent pas de contrôles appropriés pour le canal d'accès que vous implémentez. Pour comprendre le risque, il faut distinguer deux modes de déploiement très différents.
Usage local : des privilèges hérités de l'utilisateur
En local, MCP encourage la communication entre client et serveur via les flux d'entrée-sortie standard (stdio). Le processus MCP s'exécute avec l'identité de l'utilisateur et hérite de ses privilèges : le périmètre d'exposition est celui du poste de travail, et il faudrait délibérément exposer des privilèges élevés pour créer un risque supplémentaire. Ce mode reste raisonnablement maîtrisable.
Serveurs distants : le vrai maillon faible
Le problème concerne les serveurs MCP accessibles à distance en HTTP streamable. Quand un serveur MCP accède à des ressources via leurs canaux de communication natifs, ces canaux manquent souvent de contrôles d'accès équivalents pour le cas d'usage MCP : votre base de données connaît des comptes système, votre stockage de fichiers connaît des utilisateurs système, mais MCP ouvre ces ressources à une population beaucoup plus large d'utilisateurs, de LLM et d'agents. Relier des privilèges utilisateur larges à un accès système restreint n'a rien de trivial : traiter toutes les préoccupations de sécurité nécessaires, authentification, autorisation fine, journalisation, protection contre l'injection de données et de commandes, demanderait souvent plus d'effort que l'implémentation MCP elle-même. C'est précisément là que naissent les chemins d'accès parallèles qui échappent à toute gouvernance.
Ce que la spécification MCP impose désormais : OAuth 2.1, PKCE et RFC 8707
Le standard a considérablement mûri sur le volet sécurité. Depuis la révision 2025-06-18, puis la version stable 2025-11-25 de la spécification, tout serveur MCP exposé sur le réseau doit s'appuyer sur OAuth 2.1 avec PKCE obligatoire, implémenter les métadonnées de ressource protégée (RFC 9728) pour la découverte du serveur d'autorisation, et les clients doivent utiliser les Resource Indicators (RFC 8707) pour lier chaque jeton à la ressource précise qu'il cible, ce qui neutralise le vol et la réutilisation de jetons entre serveurs.
Pourquoi l'authentification ne suffit pas
Ces exigences règlent l'authentification et la délivrance de jetons, mais elles ne disent rien de l'essentiel pour l'entreprise : qui a le droit de faire quoi, sur quelle ressource, dans quelles limites de débit, avec quelle traçabilité. L'autorisation fine, la gestion des quotas, la détection d'abus et l'audit restent entièrement à la charge de l'implémenteur. Réinventer cette couche pour chaque serveur MCP serait coûteux et fragile, or ce problème a déjà été résolu ailleurs.
Le modèle de délégation API : réutiliser une infrastructure éprouvée
Lorsque les architectures orientées API ont émergé, relier des ressources restreintes à des canaux utilisateurs plus larges était exactement le même problème fondamental. Les réponses existent depuis : passerelles API, gestion des identités, scopes OAuth, quotas, limitation de débit, télémétrie. Ces briques sont matures, outillées et centrales dans les transformations numériques. Plutôt que de réarchitecturer ces solutions pour MCP, réutilisons-les.
Quatre principes d'implémentation
Premièrement, si des couches API existent déjà devant vos ressources internes, réutilisez-les ; sinon, déployez une solution API d'abord. Deuxièmement, évaluez les exigences d'accès utilisateur de votre serveur MCP et configurez la couche API en conséquence, vos API existantes peuvent nécessiter des scopes plus granulaires pour distinguer un agent IA d'un client applicatif classique. Troisièmement, gardez le serveur MCP léger et concentré sur sa fonction première : traduire le protocole de requête entre le LLM ou l'agent et la ressource backend, en déléguant contrôle d'accès, gestion du trafic et télémétrie à la couche API. Quatrièmement, traitez votre serveur MCP comme un client API doté d'exigences d'accès spécifiques, avec ses propres identifiants et ses propres limites.
Cette approche maintient des canaux d'accès uniformes et cohérents, sans créer de chemins secondaires vers les ressources backend. C'est le cœur du modèle de délégation API MCP : le serveur MCP ne doit rien faire d'autre que relier le protocole MCP au protocole API.
Implémenter le pont MCP-API et arbitrer les compromis
Avec la couche API entre le serveur MCP et les ressources, il reste à relier MCP à votre API backend, et c'est la partie la plus simple. Les concepts d'architecture API se traduisent directement en concepts MCP : un point de terminaison devient un outil, un schéma OpenAPI devient la description de ses paramètres. Des solutions de référence existent pour générer dynamiquement des serveurs MCP à partir de spécifications OpenAPI, et les principales passerelles API du marché proposent désormais nativement l'exposition MCP de leurs API, avec les mêmes politiques de sécurité, de quota et d'audit que pour n'importe quel client.
Latence, complexité, dépendance : les compromis assumés
Le modèle de délégation n'est pas gratuit. La couche API supplémentaire ajoute de la latence sur chaque appel d'outil ; l'architecture gagne en complexité ; la disponibilité de la passerelle API devient un point de dépendance critique ; et l'infrastructure de gestion des API a un coût, en licences comme en exploitation. Pour la plupart des déploiements d'entreprise, ces compromis restent largement acceptables au regard des bénéfices : une gouvernance unique, des politiques cohérentes et une surface d'audit centralisée pour tous les accès des agents IA.
Plan d'action pour des déploiements MCP sécurisés et gouvernés
La démarche tient en quatre étapes. Auditez d'abord votre infrastructure API actuelle : couverture des ressources sensibles, granularité des scopes, capacités de limitation de débit et de journalisation. Si cette infrastructure n'existe pas, implémentez une architecture API avant tout déploiement MCP distant. Déployez ensuite des serveurs MCP réutilisables au-dessus de ces API, générés depuis vos spécifications OpenAPI ou exposés par votre passerelle, plutôt que des serveurs personnalisés qui réimplémentent chacun leur contrôle d'accès. Configurez enfin la couche API pour le cas d'usage agentique : scopes dédiés, quotas adaptés aux rafales d'appels d'outils, alertes sur les comportements anormaux.
Ce socle technique doit s'accompagner d'une gouvernance : inventaire des serveurs MCP autorisés, revue de sécurité avant toute mise en production et surveillance continue des appels d'outils, au même titre que n'importe quel trafic API. Les agents IA multiplient les interactions machine-machine ; sans visibilité centralisée, les dérives passent inaperçues.
En déléguant la sécurité et le contrôle d'accès à une infrastructure API éprouvée, vous obtenez des déploiements MCP uniformes, sécurisés et évolutifs, sans réinventer la roue, et sans transformer chaque nouveau serveur MCP en dette de sécurité.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
