Gouverner les serveurs MCP en entreprise : qui peut connecter quoi ?

Un serveur MCP, c'est du code arbitraire avec un accès réseau et une invitation permanente dans le contexte de l'agent. Un développeur en ajoute un en une commande. Et le mode d'échec est silencieux : un serveur qui exfiltre le contenu d'un dépôt se comporte exactement comme un serveur qui fonctionne. Après avoir déployé des serveurs MCP et accompagné des équipes dans leur adoption, voici le cadre de gouvernance que je recommande. Il tient en une liste, une poignée de règles, et une vérification automatisée. Pour situer MCP parmi les autres protocoles agentiques (A2A, ACP...), voir La jungle des protocoles IA, comment s'y retrouver et préparer l'avenir ?.

Le problème : l'adoption va plus vite que le contrôle

Les assistants de code (Claude Code, Gemini CLI, Codex, Copilot) rendent l'ajout d'un serveur MCP trivial. Les catalogues publics en recensent des milliers. Sans règle explicite, chaque poste de développeur finit avec sa propre collection de serveurs :

Risque de fuite : un serveur tiers reçoit du code source, des tickets, des données clients.
Risque d'action : un serveur avec des droits d'écriture peut modifier, supprimer, publier.
Risque de dérive : un serveur peut changer ses tools après avoir été approuvé (rug pull).
Coût caché : chaque serveur connecté ajoute ses définitions de tools au contexte de chaque requête.

Une allowlist, pas un registre maison

Inutile d'inventer un outil. La plupart des organisations ont déjà une discipline pour les dépendances ou les technologies interdites. Une allowlist MCP est la même discipline appliquée à un autre objet. Pour chaque entrée :

Une raison. "On l'utilise" n'en est pas une. Qui le publie, à quoi il accède, ce qu'il envoie à l'extérieur.
Un propriétaire et une date de revue. Une allowlist que personne ne revisite devient un tampon automatique.
Le poids mesuré en tokens, pour que le coût puisse peser dans la décision.

Et une règle de fonctionnement : le silence ne vaut jamais acceptation. Un serveur absent de la liste n'est pas autorisé.

Sept règles de gouvernance

1. Distinguer auto-hébergé et hébergé par l'éditeur

Vous pouvez inspecter, auditer et journaliser un serveur que vous hébergez. Vous ne pouvez pas inspecter l'endpoint d'un éditeur, et son modèle de tenancy peut être partagé entre ses clients. Les deux ne méritent pas le même niveau de confiance ni le même processus d'approbation.

2. Révoquer n'est pas retirer

Retirer un serveur de la liste ne révoque pas les tokens OAuth déjà émis pour lui. Décidez de la durée de vie des identifiants au moment de l'approbation, et prévoyez la procédure de révocation effective.

3. Un serveur par périmètre de permission

Séparer la lecture de l'écriture garde un audit lisible et évite l'escalade de privilèges via un serveur unique trop large. Un serveur jira-read et un serveur jira-write valent mieux qu'un jira qui fait tout. De même, les appels machine (comptes de service) restent en lecture seule par défaut.

4. Annoter chaque tool

La spécification MCP prévoit readOnlyHint, destructiveHint, idempotentHint et openWorldHint. Sans ces annotations, ni l'agent ni l'hôte ne peuvent juger si un appel est sûr en autonomie. Exigez-les pour tout serveur interne, et vérifiez-les pour les serveurs tiers.

5. Le dépôt Git comme source de vérité

Spécifications des tools et des agents versionnées dans Git, poussées par la CI. Le registre (quel qu'il soit) est une projection du dépôt, jamais l'inverse. Cela donne l'historique, la revue de code et la traçabilité gratuitement.

6. Exclure les fonctionnalités dépréciées

Depuis la révision 2026-07-28, la spécification MCP a un cycle de vie formel : chaque fonctionnalité est Active, Deprecated ou Removed, avec au moins douze mois entre les deux derniers états et un registre public. "Ne pas construire sur des fonctionnalités en fin de vie" devient une règle vérifiable avec une date de migration. Roots, Sampling et Logging sont entrés dans cette fenêtre.

7. Vérifier en continu, pas une fois

Un serveur approuvé en janvier peut avoir changé ses tools en mars, ou dégradé sa configuration OAuth. Automatisez la vérification :

Posture de sécurité des serveurs distants (OAuth, TLS, métadonnées) dans la CI.
Épinglage des tools : enregistrer la liste approuvée et alerter sur tout ajout, suppression ou modification.

J'ai développé mcp-posture, un scanner open source qui couvre ces deux points et s'intègre en GitHub Action :

- uses: batou9150/mcp-posture@v1.1.1
  with:
    targets-file: mcp-servers.txt   # la liste des serveurs autorisés
    fail-on: high

Et les services managés ?

Les plateformes cloud commencent à proposer cette gouvernance en service. Sur Google Cloud, Agent Registry offre un catalogue d'agents et de serveurs MCP, des permissions IAM natives, des liaisons avec les fournisseurs d'authentification et une observabilité par serveur, y compris la consommation de tokens. Agent Gateway ajoute l'application des politiques au niveau du trafic. Au moment où j'écris, ces services sont encore en preview : vérifiez leur statut et leur tarification avant de vous engager.

Cette gouvernance fait partie de tout ce qui se construit désormais autour du modèle plutôt que dedans, comme l'explique Agent harness : pourquoi l'avenir de l'IA s'écrit désormais autour du modèle, et non plus dedans ?.

Si votre plateforme le propose, adoptez-le et concentrez vos efforts sur les conventions plutôt que sur la reconstruction d'un plan de contrôle. Les règles ci-dessus restent valables dans tous les cas : un registre managé ne décide pas à votre place de la raison d'admettre un serveur.

Par où commencer

Semaine 1 : inventorier les serveurs réellement configurés sur les postes (fichiers .mcp.json, configurations Claude, VS Code, Cursor).
Semaine 2 : créer l'allowlist dans un dépôt Git, avec raison, propriétaire, date de revue pour chaque entrée.
Semaine 3 : brancher une vérification automatique en CI sur la liste.
Ensuite : revue trimestrielle, et retrait systématique de ce qui n'a plus de propriétaire.

Conclusion

Gouverner les serveurs MCP ne demande pas de nouvel outil, mais une discipline existante appliquée à un nouvel objet : une liste versionnée, une raison et un propriétaire par entrée, et une vérification continue. Le coût de mise en place est de quelques jours. Le coût de ne pas le faire est un serveur non audité qui lit votre code source en silence.