Claude MCP en entreprise : valider et sécuriser les serveurs

TL;DR

Claude MCP relie Claude à vos outils via des serveurs locaux stdio ou des serveurs distants HTTP. En entreprise, chaque serveur MCP est du code qui touche à vos données. Validez les serveurs centralement, imposez-les via managed-mcp.json ou allowedMcpServers avec allowManagedMcpServersOnly, filtrez par URL ou commande plutôt que par nom, exigez OAuth avec des scopes étroits et journalisez les appels.

Qu’est-ce que Claude MCP, et quelle différence entre serveur local et distant ?

Le Model Context Protocol (MCP) est un protocole ouvert qui permet à Claude d’appeler des outils et de lire des données dans d’autres systèmes. Un serveur local tourne comme sous-processus sur le poste de l’utilisateur et communique via stdio. Un serveur distant tourne ailleurs et se joint en Streamable HTTP. Les deux agissent réellement, donc les deux exigent une validation.

Anthropic a présenté MCP le 25 novembre 2024, comme standard pour connecter les assistants d’IA aux systèmes où vivent les données. Le 9 décembre 2025, Anthropic a confié MCP à l’Agentic AI Foundation, hébergée par la Linux Foundation. Anthropic comptait alors plus de 10 000 serveurs MCP publics actifs, plus de 97 millions de téléchargements SDK par mois en Python et TypeScript, et plus de 75 connecteurs dans l’annuaire de Claude. Avec 10 000 serveurs publics, vos développeurs trouveront un serveur pour presque tout. C’est précisément le problème de gouvernance.

La spécification des transports actuelle (révision 2026-07-28) définit deux transports standard :

	Serveur local (stdio)	Serveur distant (Streamable HTTP)
Où il tourne	Sous-processus sur le portable	Votre hôte, le cloud d’un éditeur ou derrière un tunnel
Qui peut le joindre	Seul le client qui l’a lancé	Quiconque atteint l’URL, d’où l’authentification
Identifiants	Depuis l’environnement, selon la spécification	Autorisation fondée sur OAuth 2.1
Risque principal	Exécution de code arbitraire avec les droits de l’utilisateur	Tokens trop larges, données envoyées à un tiers
Clé de liste d’autorisation dans Claude Code	serverCommand	serverUrl

La spécification MCP est explicite : les outils représentent une exécution de code arbitraire, et les descriptions de comportement des outils doivent être considérées comme non fiables, sauf si elles viennent d’un serveur de confiance. Gardez cette phrase en tête avant de valider un serveur communautaire.

Dans l’univers Claude, MCP apparaît à deux endroits. Claude Code lit les serveurs dans des fichiers de configuration. Les applications Claude (claude.ai, Desktop, Cowork) utilisent des connecteurs, c’est-à-dire des serveurs MCP distants ajoutés par URL. Sur les plans Team et Enterprise, seul un Owner ajoute un connecteur personnalisé pour l’organisation, puis chaque membre s’y connecte avec son propre compte.

Comment Claude Code configure-t-il les serveurs MCP ?

Claude Code connaît trois portées. Local est la valeur par défaut et reste privée à un projet sur un poste. Project écrit .mcp.json dans le dépôt pour que l’équipe partage les mêmes serveurs. User s’applique à tous les projets d’un utilisateur. L’organisation ajoute une quatrième couche au-dessus, via la configuration gérée.

La référence MCP de Claude Code indique où vit chaque portée :

Portée	Se charge dans	Partagée avec l’équipe	Stockée dans
Local (par défaut)	Projet courant uniquement	Non	~/.claude.json
Project	Projet courant uniquement	Oui, via le contrôle de version	.mcp.json à la racine du projet
User	Tous vos projets	Non	~/.claude.json

Ajouter des serveurs en ligne de commande :

claude mcp add --transport http tickets --scope project https://mcp.internal.example.com/mcp
claude mcp add --transport stdio pgread --scope project -- npx -y @example/postgres-mcp@1.4.2
claude mcp list

Le .mcp.json obtenu est le fichier que vous relisez en pull request. Les secrets restent dehors grâce à l’expansion ${VAR} :

{
  "mcpServers": {
    "tickets": {
      "type": "http",
      "url": "https://mcp.internal.example.com/mcp",
      "headers": { "Authorization": "Bearer ${TICKETS_MCP_TOKEN}" }
    },
    "pgread": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/postgres-mcp@1.4.2"],
      "env": { "DATABASE_URL": "${PGREAD_URL}" }
    }
  }
}

Trois comportements à connaître pour une revue de sécurité :

1. En session interactive, Claude Code demande une approbation avant d’utiliser les serveurs de portée project issus de .mcp.json. Avec claude -p, l’Agent SDK et les sessions cloud, il ne peut pas afficher cette demande et charge ces serveurs sans rien demander. Un job CI qui récupère une branche non fiable lance donc ce que contient son .mcp.json.
2. Dans url et headers d’un serveur distant, les variables d’identifiants comme ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN et AWS_BEARER_TOKEN_BEDROCK sont lues comme vides. Un .mcp.json malveillant ne peut pas envoyer votre token Bedrock à son propre serveur.
3. Claude Code avertit au-delà de 10 000 tokens de sortie MCP et plafonne la sortie à 25 000 tokens par défaut (MAX_MCP_OUTPUT_TOKENS relève le plafond). Une grosse sortie d’outil coûte des tokens et c’est aussi le canal par lequel un texte injecté atteint le modèle.

Un détail pour l’exploitation dans l’UE : Claude Code ne charge les connecteurs claude.ai que si l’utilisateur est connecté avec un abonnement claude.ai. Avec Bedrock ou Google Cloud actif, ils ne sont pas récupérés. Si vous faites tourner Claude Code sur Bedrock dans une région UE, comme dans notre guide Claude Code sur Bedrock et le RGPD, chaque serveur MCP provient de vos propres fichiers.

Comment imposer une politique MCP à toute l’entreprise ?

Par la configuration gérée, pas par une page wiki. Claude Code propose un jeu fixe de serveurs via managed-mcp.json, des serveurs fournis à tous via managedMcpServers et un filtrage via allowedMcpServers et deniedMcpServers. Pour une liste d’autorisation stricte, ajoutez allowManagedMcpServersOnly: true, sinon les utilisateurs peuvent l’élargir dans leurs propres paramètres.

La page sur le MCP géré décrit ces modèles. Ceux que nous voyons en pratique :

Modèle	Effet	Configuration
Désactiver MCP	Seuls les serveurs intégrés se chargent	managed-mcp.json avec "mcpServers": {}
Déploiement fixe	Tout le monde reçoit les mêmes serveurs, rien d’autre	managed-mcp.json avec vos serveurs
Catalogue validé	Les utilisateurs choisissent dans une liste validée	allowedMcpServers plus allowManagedMcpServersOnly: true
Liste de refus seule	Bloquer les serveurs connus comme dangereux	deniedMcpServers

managed-mcp.json se place dans /Library/Application Support/ClaudeCode/ sur macOS, /etc/claude-code/ sur Linux et WSL, et C:\Program Files\ClaudeCode\ sur Windows. Tout utilisateur du poste peut le lire : ne mettez jamais de clé d’API dans ses blocs env. Un fichier de paramètres gérés pour le modèle du catalogue validé :

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.internal.example.com/*" },
    { "serverCommand": ["npx", "-y", "@example/postgres-mcp@1.4.2"] }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://*.untrusted.example.com/*" }
  ]
}

Les règles derrière ce fichier :

• Une correspondance dans la liste de refus bloque le serveur, et rien ne passe outre.
• serverCommand compare à l’identique, chaque argument dans l’ordre. Avec la version du paquet dans la commande, la liste d’autorisation valide une version et pas seulement un nom.
• Une entrée serverName n’est pas un contrôle de sécurité. N’importe qui peut appeler n’importe quel serveur github. La documentation d’Anthropic le dit en toutes lettres.
• managedMcpServers (serveurs distants uniquement, https:// uniquement, aucune commande) exige Claude Code v2.1.259 ou ultérieure.

Le piège des déploiements européens : définir CLAUDE_CODE_USE_BEDROCK ou un autre fournisseur tiers contourne les paramètres gérés côté serveur de la console claude.ai. Sur Bedrock, distribuez la liste d’autorisation via managed-settings.json, un profil MDM ou une passerelle Claude apps auto-hébergée. Pour Cowork sur un fournisseur tiers, Claude Desktop fournit et verrouille lui-même les serveurs MCP ; notre article sur Claude Cowork en entreprise et le RGPD couvre cette configuration.

Pour la supervision, activez OTEL_LOG_TOOL_DETAILS=1 avec l’export OpenTelemetry. Les événements d’outils portent alors le nom du serveur MCP et de l’outil, ce qui montre les serveurs réellement utilisés.

Quels risques de sécurité MCP comptent, et comment les réduire ?

Quatre risques dominent : l’injection de prompt via les sorties d’outils, les descriptions d’outils piégées ou modifiées en silence, les tokens trop larges ou relayés, et les serveurs locaux qui exécutent du code arbitraire. Chacun a un contrôle concret dans la spécification MCP ou dans l’administration de Claude. Aucun label d’annuaire ne les règle.

Risque	Ce qui se passe	Contrôle
Injection de prompt	Un serveur récupère du contenu externe et renvoie du texte contenant des instructions	Serveurs de confiance uniquement, approbation au cas par cas des outils d’écriture, outils inutiles bloqués
Empoisonnement d’outil	Une description cache des instructions ou change après validation	Descriptions traitées comme non fiables, versions épinglées, revue à chaque changement
Relais de token	Un serveur transmet un token qui ne lui était pas destiné	Spécification : les serveurs ne doivent pas accepter ces tokens
Scopes trop larges	Un token divulgué ouvre fichiers, base de données et administration	Scopes minimaux, élévation lors des appels privilégiés
Serveur local compromis	Une commande de démarrage exfiltre des clés	Bac à sable, liste exacte de commandes, pas de npx sans version

La checklist de revue des connecteurs d’Anthropic rejette les descriptions d’outils contenant des instructions cachées, obscurcies ou encodées, ou qui poussent Claude vers des outils que l’utilisateur n’a pas demandés. Reprenez cette liste pour votre revue interne. La page sur la vérification des connecteurs est sans détour : le label Verified n’est pas un audit de sécurité, et le développeur peut modifier ses outils après la revue.

Les bonnes pratiques de sécurité MCP imposent deux règles aux serveurs que vous construisez. Un serveur MCP ne doit accepter aucun token qui n’a pas été explicitement émis pour lui. Et les scopes démarrent au minimum, avec une élévation seulement au premier appel d’un outil privilégié, plutôt que des jokers comme files:* ou admin:*. La spécification d’autorisation exige les Resource Indicators (RFC 8707) pour lier un token à un seul serveur.

Dans Claude Code, les règles de permission forment une deuxième ligne : mcp__github__get_* n’autorise que les outils get_ d’un serveur, et "mcp__*" dans une règle de refus retire tous les outils MCP. Dans les applications Claude, un administrateur peut passer un outil de connecteur en Blocked.

Côté RGPD : un serveur MCP distant exploité par un éditeur reçoit tout ce que l’appel d’outil lui envoie, souvent des données personnelles. L’éditeur devient sous-traitant ou responsable de traitement distinct ; il lui faut un contrat de sous-traitance ou une autre base, et il entre dans votre registre des traitements comme n’importe quel SaaS. Les connecteurs personnalisés de claude.ai sont appelés depuis l’infrastructure d’Anthropic, donc le serveur doit être joignable depuis celle-ci. Pour les serveurs qui doivent rester dans votre réseau, les clients Enterprise peuvent demander les tunnels MCP : une research preview avec jusqu’à 10 tunnels actifs par organisation, où Cloudflare intervient comme sous-traitant ultérieur.

À quoi ressemble un processus de validation MCP qui tient ?

Faites passer les serveurs MCP par la même porte que tout logiciel qui accède aux données : une demande, une revue sécurité et protection des données, une configuration épinglée et imposée par liste d’autorisation, puis une nouvelle revue à chaque changement. Une validation n’existe vraiment que si la liste l’impose sur chaque poste.

1. Demande : l’équipe indique le serveur, le transport, l’URL ou la commande exacte, les outils nécessaires et les données concernées.
2. Revue : la sécurité lit les descriptions d’outils et le code source (pour stdio), le DPO qualifie le flux de données et vérifie le contrat avec l’éditeur.
3. Configuration : épingler la version, OAuth avec les scopes les plus étroits, outils d’écriture en ask.
4. Application : ajouter l’entrée serverUrl ou serverCommand aux paramètres gérés et la déployer.
5. Suivi et nouvelle revue : suivre l’usage via OpenTelemetry, revoir à chaque montée de version ou changement d’outil.

Étape	Responsable	Preuve conservée
Demande	Équipe demandeuse	Serveur, outils, catégories de données, finalité
Revue sécurité	Sécurité	Descriptions lues, code ou éditeur examiné, modèle d’authentification
Protection des données	DPO	Qualification de l’éditeur, contrat de sous-traitance, transferts, registre
Application	Équipe plateforme	Commit dans les paramètres gérés, version épinglée
Nouvelle revue	Plateforme et sécurité	Lecture du changelog à chaque mise à jour

Les serveurs qui ne lisent que de la documentation publique peuvent suivre une voie rapide. Ceux qui écrivent dans des données de production, RH ou clients passent toujours par la procédure complète.

Exploiter en interne ou externaliser ?

Exploiter MCP en interne est un travail de plateforme, pas une installation ponctuelle. Quelqu’un doit tenir l’inventaire des serveurs, mettre à jour les versions épinglées, faire tourner les secrets et lire les journaux. Pour quelques serveurs en lecture seule, l’équipe interne suffit. Pour des dizaines de serveurs avec droits d’écriture, c’est ce travail récurrent qui peut justifier un prestataire.

Les tâches récurrentes, à notre avis :

Tâche	Contenu	Rythme (notre estimation)
Inventaire des serveurs	Une liste des serveurs validés avec responsable, version, catégories de données	À chaque validation
Mises à jour	Monter les versions, revoir les outils modifiés, ajuster la liste d’autorisation	Contrôle hebdomadaire, immédiat en cas d’alerte
Rotation des secrets	Clients OAuth, en-têtes statiques, token de tunnel et clés TLS	Suivant votre politique, immédiatement après une fuite
Journalisation	Chaîne OpenTelemetry, alertes sur serveurs inconnus ou nouveaux outils	En continu
Déploiement des politiques	MDM ou paramètres gérés, information des utilisateurs quand un serveur est bloqué	À chaque changement

Notre estimation grossière pour une organisation d’ingénierie de taille moyenne : une fraction de poste d’ingénieur plateforme plus quelques heures de revue sécurité par nouveau serveur. C’est une estimation, pas une mesure.

Externaliser a du sens si vous n’avez pas d’équipe plateforme qui gère déjà le MDM et les secrets, ou si vous voulez qu’un tiers héberge des serveurs MCP distants avec un SLA. Cela en a peu si vous n’utilisez que deux ou trois connecteurs d’éditeurs : l’éditeur est déjà l’exploitant.

Ce qu’il faut exiger d’un prestataire pour MCP :

• Un SLA pour les serveurs MCP hébergés, y compris le délai de correction après une alerte de sécurité.
• Un contrat de sous-traitance RGPD qui cite explicitement les appels d’outils MCP comme traitement, et la liste des sous-traitants ultérieurs, y compris l’hébergeur et le fournisseur de tunnel.
• Un modèle d’accès avec des tokens par serveur, des scopes minimaux et aucun relais de token, où votre IdP reste la source d’identité.
• Des journaux exportables vers votre propre SIEM.
• Une sortie : définitions de serveurs, listes d’autorisation et inventaire vivent dans votre dépôt, pas seulement dans la console du prestataire.

Si vous exploitez aussi une passerelle pour le trafic vers les modèles, les mêmes questions se posent ; notre article sur la passerelle LiteLLM dans l’UE traite ce volet.

FAQ

Combien coûte Claude MCP ?

Le protocole est ouvert et sans licence. Les coûts viennent de l’exploitation des serveurs, des abonnements aux connecteurs hébergés et des tokens : la sortie d’un outil compte comme entrée du modèle. Claude Code plafonne par défaut la sortie MCP à 25 000 tokens et avertit au-delà de 10 000.

managed-mcp.json ou allowedMcpServers : lequel choisir ?

managed-mcp.json quand tout le monde doit recevoir exactement les mêmes serveurs et rien d’autre, car le fichier prend le contrôle exclusif. allowedMcpServers avec allowManagedMcpServersOnly: true quand les équipes choisissent dans un catalogue validé. Les deux sont imposés, le premier est plus strict.

Les connecteurs de l’annuaire Anthropic sont-ils audités ?

Non. Anthropic examine les connecteurs selon ses critères d’inscription, mais n’audite ni ne gère aucun serveur MCP. Le label Verified signifie une revue plus poussée de qualité et de compatibilité, pas une garantie. Le développeur peut changer ses outils après la revue.

Les connecteurs claude.ai fonctionnent-ils dans Claude Code sur Bedrock ?

Non. Claude Code ne récupère les connecteurs claude.ai qu’avec une connexion par abonnement claude.ai. Avec Bedrock, Google Cloud ou une clé d’API, ils ne sont pas chargés. Vous configurez alors les serveurs via .mcp.json, la portée user ou les fichiers gérés.

Peut-on bloquer un serveur par son nom ?

Oui, mais ce n’est pas un contrôle de sécurité. Le nom est une étiquette choisie par l’utilisateur, qui peut renommer n’importe quel serveur. Filtrez les serveurs distants par serverUrl et les serveurs stdio par la serverCommand exacte.

OAuth suffit-il à sécuriser un serveur MCP distant ?

OAuth rend les accès attribuables et révocables, ce que les clés statiques ne font pas. Il n’arrête ni l’injection de prompt ni un outil malveillant. Combinez OAuth avec des scopes minimaux, des tokens liés à un seul serveur, une liste d’outils revue et une approbation au cas par cas pour les actions d’écriture.

Sources

1. Documentation Claude Code : connecter des outils via MCP (1 octobre 2026)
2. Documentation Claude Code : contrôler l'accès MCP de l'organisation (1 octobre 2026)
3. Documentation Claude Code : sécurité (1 octobre 2026)
4. Documentation Claude Code : paramètres gérés côté serveur (1 octobre 2026)
5. Documentation Claude Code : permissions (1 octobre 2026)
6. Documentation Claude : ajouter un connecteur hors annuaire (1 octobre 2026)
7. Documentation Claude : vérification des connecteurs (1 octobre 2026)
8. Documentation Claude : tunnels MCP (1 octobre 2026)
9. Documentation Claude : checklist avant soumission d'un connecteur (1 octobre 2026)
10. Spécification MCP 2026-07-28 (1 octobre 2026)
11. Spécification MCP : transports (1 octobre 2026)
12. Spécification MCP : autorisation (1 octobre 2026)
13. MCP : bonnes pratiques de sécurité (1 octobre 2026)
14. Anthropic : Introducing the Model Context Protocol (1 octobre 2026)
15. Anthropic : don de MCP à l'Agentic AI Foundation (1 octobre 2026)