> ## Content Index
> Fetch the complete content index at: https://www.sfeir.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# Gouverner les serveurs MCP en entreprise : qui peut connecter quoi ?
- URL: https://www.sfeir.dev/ia/gouvernance-serveurs-mcp-entreprise/
- Published: 2026-11-10T13:46:40.000Z
- Updated: 2026-11-10T13:46:40.000Z
- Description: Allowlist, propriétaire, revue, un serveur par périmètre, vérification en CI : un cadre de gouvernance des serveurs MCP pour l'entreprise.
- Author: Baptiste PIRAULT
- Tags: IA, MCP, Agent IA, Agentic

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#gouverner-les-serveurs-mcp-en-entreprise--qui-peut-connecter-quoi-)

Un serveur [MCP](https://www.sfeir.dev/ia/concevoir-des-tools-mcp-pour-un-agent-ia/), 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 ?](https://www.sfeir.dev/data/la-jungle-des-protocoles-ia-comment-sy-retrouver-et-preparer-lavenir/).

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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#le-probl%C3%A8me--ladoption-va-plus-vite-que-le-contr%C3%B4le)

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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#sept-r%C3%A8gles-de-gouvernance)

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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#1-distinguer-auto-h%C3%A9berg%C3%A9-et-h%C3%A9berg%C3%A9-par-l%C3%A9diteur)

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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#2-r%C3%A9voquer-nest-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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#3-un-serveur-par-p%C3%A9rim%C3%A8tre-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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#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é

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#5-le-d%C3%A9p%C3%B4t-git-comme-source-de-v%C3%A9rit%C3%A9)

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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#6-exclure-les-fonctionnalit%C3%A9s-d%C3%A9pr%C3%A9ci%C3%A9es)

Depuis la révision `2026-07-28`, la spécification MCP a un [cycle de vie formel](https://modelcontextprotocol.io/community/feature-lifecycle?ref=sfeir.dev) : 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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#7-v%C3%A9rifier-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](https://github.com/batou9150/mcp-posture?ref=sfeir.dev), 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 ?

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#et-les-services-manag%C3%A9s-)

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 ?](https://www.sfeir.dev/agent-harness-pourquoi-lavenir-de-lia-secrit-desormais-autour-du-modele-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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#par-o%C3%B9-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

[](https://github.com/batou9150/writing-workspace/blob/main/blog/drafts/7%5FMCP%2C%20gouverner%20les%20serveurs%20en%20entreprise%20%28FR%29.md?ref=sfeir.dev#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.

[La jungle des protocoles IA, comment s’y retrouver et préparer l’avenir ?2026\. L’ère du “Web Agentique” est là : l’IA ne se contente plus de répondre, elle agit. Le défi majeur est désormais la collaboration entre ces agents hétérogènes. La solution ? Découvrez comment le binôme MCP (accès aux outils) et A2A (orchestration) structure le futur de votre SI.![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/icon/plume-point-f6c49107-723b-41c5-925d-bbe9e4233dbc.png)sfeir.dev - Le média incontournable pour les passionnés de tech et d'intelligence artificielleFlorent Legras![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/thumbnail/guerre_protocols-1-128687b4-19f0-4252-9df8-50b20f9dab8f.jpg)](https://www.sfeir.dev/data/la-jungle-des-protocoles-ia-comment-sy-retrouver-et-preparer-lavenir/)

[Agent harness : pourquoi l’avenir de l’IA s’écrit désormais autour du modèle, et non plus dedans ?En 2026, choisir un LLM sans penser à son harness, c’est acheter un moteur sans voiture. La vraie compétition agentique ne se joue plus dans les poids du modèle, elle se joue dans les cinq couches d’infrastructure qui l’entourent. Décryptage technique.![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/icon/plume-point-febec8ba-ce11-433f-998f-0a02d311b438.png)sfeir.dev - Le média incontournable pour les passionnés de tech et d'intelligence artificielleCharlotte Ryssen (Coumont)![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/thumbnail/Gemini_Generated_Image_kq9naxkq9naxkq9n-1-33ad7782-598c-4c65-be65-010a199221bf.png)](https://www.sfeir.dev/agent-harness-pourquoi-lavenir-de-lia-secrit-desormais-autour-du-modele-et-non-plus-dedans/)