MCP en entreprise : 7 contrôles avant de connecter un serveur à vos outils

Un serveur MCP peut donner à un assistant IA une capacité très concrète : lire un ticket, chercher un document, créer un brouillon ou appeler une API.

Cette capacité est utile précisément parce qu’elle franchit une frontière. L’assistant ne se contente plus de produire du texte. Il découvre des outils, reçoit leurs résultats et peut parfois déclencher une action dans un système réel.

Le risque n’est donc pas « MCP » en soi. Le risque est de connecter trop vite un serveur dont vous n’avez pas vérifié la provenance, les outils exposés, les données accessibles, l’identité utilisée et les sorties réseau.

La spécification MCP 2026-07-28, désormais publiée comme version finale, renforce justement les contrôles d’autorisation et le fonctionnement sans session implicite. Son guide officiel de sécurité documente notamment le confused deputy, le token passthrough, le SSRF et le détournement de handles d’état.

À la fin de cet article, vous saurez produire une fiche de connexion en 45 minutes, lancer un test limité ou refuser le raccordement avec une raison vérifiable.

Schéma original BâtisseurIA, créé pour cet article en 2026. Crédit : BâtisseurIA / Aymane Abdennour. Licence : CC BY 4.0. Il s’agit d’une grille de décision opérationnelle, pas d’une certification de serveur MCP.

MCP ajoute une frontière d’outils, pas une permission générale

Le Model Context Protocol standardise une manière pour un hôte IA de découvrir et d’appeler des ressources, des prompts et des outils fournis par un serveur. Cette standardisation facilite l’intégration. Elle ne rend pas automatiquement chaque serveur digne de confiance.

Un serveur peut exposer une fonction de lecture et une fonction d’écriture. Il peut appeler un service tiers. Il peut accepter des paramètres qui ressemblent à une simple URL, mais qui deviennent dangereux si le serveur ou le client ne limite pas les destinations possibles. Il peut aussi renvoyer une sortie qui sera réinjectée dans le contexte du modèle.

La première question n’est donc pas « ce serveur est-il compatible avec mon assistant ? ». C’est :

Quelle capacité précise est-ce que j’autorise, sur quelles données, avec quelle identité et quelle sortie de secours ?

Cette question évite deux erreurs symétriques : traiter MCP comme un simple connecteur sans risque, ou refuser tout protocole sans apprendre à réduire son périmètre.

Les 7 contrôles à remplir avant le pilote

1. Le besoin : une seule tâche, une seule preuve

Écrivez le résultat attendu en une phrase observable : « retrouver les tickets ouverts d’un client et préparer une synthèse », pas « donner accès au support ».

Ajoutez trois éléments :

• le déclencheur, par exemple une demande explicite d’un membre de l’équipe ;
• la preuve de réussite, par exemple une synthèse qui cite les tickets consultés ;
• l’action interdite, par exemple modifier le statut ou envoyer un message.

Si vous ne pouvez pas distinguer lecture, préparation et écriture, le pilote est trop large. Commencez par une action en lecture seule. Le guide BâtisseurIA sur le choix entre assistant, workflow et agent aide à faire cette séparation avant de choisir un niveau d’autonomie.

2. La provenance : qui maintient ce serveur ?

Un dépôt public, une entrée de registre ou une recommandation dans une communauté ne constitue pas à lui seul une preuve de sécurité. Notez :

• le dépôt ou l’éditeur exact ;
• la version et la date de publication ;
• les dépendances et le mode d’installation ;
• les permissions demandées au premier lancement ;
• la procédure de mise à jour et de révocation ;
• la personne qui accepte de le maintenir côté organisation.

Évitez le « dernier commit » comme indicateur unique. Un serveur très actif peut changer ses outils ou ses permissions plus vite que votre revue. À l’inverse, un serveur stable mais abandonné peut contenir une dépendance vulnérable.

Pour un premier pilote, préférez une version épinglée, un environnement isolé et une liste de fichiers ou de commandes autorisés. Gardez la possibilité de supprimer les identifiants sans réinstaller toute la chaîne.

3. Les outils : que peut-il réellement faire ?

L’inventaire ne doit pas reprendre seulement les noms des outils. Pour chacun, décrivez :

Élément	Question à poser
Lecture	Quelles données sont retournées ?
Écriture	Quelle modification est possible ?
Destination	Quel service reçoit la requête ?
Paramètres	Les entrées sont-elles bornées et validées ?
Effet	L’action est-elle réversible ?
Preuve	Quel identifiant ou journal confirme l’appel ?

Traitez comme sensibles les outils qui envoient un message, modifient une fiche, lancent une commande, téléchargent une URL ou manipulent un fichier. Un intitulé rassurant ne réduit pas l’effet réel : update_record mérite la même attention que send_email.

Le guide officiel sur les bonnes pratiques de sécurité MCP rappelle aussi qu’une sortie d’outil peut devenir une entrée pour un autre appel. Contrôlez donc les résultats, pas seulement les paramètres initiaux.

4. Les données : quel minimum pour réussir ?

Faites une carte courte : source, type de donnée, sens de circulation, durée de conservation et personne autorisée à relire la trace.

Un assistant qui doit retrouver un numéro de ticket n’a peut-être pas besoin de tout le CRM, des pièces jointes, des données RH et de l’historique complet des clients. Réduisez le périmètre à la collection, au champ ou au dossier nécessaire.

Ne confondez pas masquage dans l’interface et réduction réelle. Une donnée peut être cachée au modèle mais conservée dans un log, un cache ou un service tiers. Demandez où sont écrits les appels, combien de temps ils restent disponibles et qui peut les exporter.

Pour un premier test, utilisez des données synthétiques ou un sous-ensemble nettoyé. Le guide BâtisseurIA avant de brancher une IA à vos données propose une fiche complémentaire pour documenter les données autorisées, les preuves fournisseur et les critères de sortie.

5. L’identité : un serveur n’est pas un utilisateur

L’identité qui appelle le serveur doit être explicite. Évitez un compte partagé « assistant », un jeton administrateur ou un secret placé dans une variable que tous les processus peuvent lire.

Attribuez au pilote :

• un propriétaire humain ;
• un compte ou une application dédiée ;
• des permissions minimales ;
• une durée de vie et une procédure de rotation ;
• une distinction entre l’identité du client MCP, celle du serveur et celle du service en aval.

La documentation d’autorisation MCP 2026-07-28 impose un point important : le serveur doit vérifier que les jetons reçus lui sont destinés. Il ne doit pas accepter un jeton émis pour un autre service, puis le transmettre tel quel à une API en aval.

C’est le problème du token passthrough. Le serveur devient alors un intermédiaire qui transporte une preuve d’autorisation qu’il n’a pas contrôlée. Pour éviter cette confusion, le serveur doit valider le jeton entrant et utiliser une autorisation distincte pour appeler son propre service en aval.

La même documentation rappelle l’intérêt du paramètre resource, défini par la RFC 8707, afin de lier un jeton à sa ressource cible. Si votre fournisseur ne sait pas expliquer cette séparation, mettez le raccordement en pause.

6. Le réseau : quelles destinations sont possibles ?

Un outil qui récupère une URL fournie par le modèle peut être détourné par une instruction hostile ou une donnée malveillante. Il peut alors tenter d’atteindre une adresse interne, un endpoint d’administration ou un service de métadonnées cloud.

Le guide de sécurité MCP décrit ce risque de SSRF et recommande des protections adaptées à l’environnement. En pratique, votre fiche doit répondre à ces questions :

• le serveur est-il local ou distant ?
• le trafic sortant passe-t-il par une liste d’autorisation ?
• les adresses privées, de bouclage et de métadonnées sont-elles bloquées lorsque cela est pertinent ?
• les URL de découverte OAuth sont-elles validées et limitées ?
• le transport distant utilise-t-il HTTPS et une validation de certificat normale ?

N’écrivez pas seulement « réseau sécurisé ». Écrivez la frontière : « le pilote peut joindre l’API support sur deux domaines connus ; toute autre destination est refusée et journalisée ».

7. L’arrêt : comment reprendre la main ?

Un pilote sans arrêt documenté n’est pas un pilote, c’est une mise en production discrète.

Définissez avant le premier appel :

1. le bouton ou la commande qui désactive le serveur ;
2. la personne qui peut révoquer l’identité ;
3. la procédure de retour au traitement manuel ;
4. les preuves à conserver après un appel douteux ;
5. le seuil qui arrête le test.

Exemples de seuils : une écriture hors du périmètre autorisé, un appel vers une destination inconnue, une absence de trace, un taux d’erreur qui empêche la vérification humaine ou une sortie qui contient une donnée non prévue.

Testez la sortie de secours volontairement. Faites échouer une autorisation, bloquez le service en aval et vérifiez que l’équipe sait identifier les demandes en attente. Le runbook BâtisseurIA de reprise d’une automatisation IA peut servir de trame pour cette répétition.

Une fiche de connexion en 45 minutes

Utilisez ce déroulé simple :

0 à 10 minutes · cadrer. Écrivez la tâche, le résultat, l’action interdite et la preuve attendue.

10 à 20 minutes · inventorier. Listez serveur, version, outils, données, identités, dépendances et destinations réseau.

20 à 30 minutes · réduire. Passez tous les outils en lecture seule quand c’est possible, remplacez les données réelles par un jeu de test, bornez les domaines et épinglez la version.

30 à 40 minutes · éprouver. Testez un cas normal, un paramètre invalide, une donnée hostile, une permission insuffisante et un service indisponible.

40 à 45 minutes · décider. Choisissez une seule sortie : tester en environnement isolé, réduire le périmètre, isoler derrière une approbation humaine ou refuser avec la raison et la condition de réexamen.

Cette séquence ne remplace pas une revue de sécurité ou une analyse juridique. Elle empêche toutefois une décision floue de se cacher derrière le mot « intégration ».

Les erreurs qui rendent le contrôle inutile

Installer avant d’inventorier

L’installation peut déjà exécuter du code, écrire des fichiers ou demander des secrets. Lisez le mode d’installation, préparez un environnement isolé et ne fournissez aucune donnée réelle au premier lancement.

Donner l’accès complet pour gagner du temps

Un accès large accélère la démonstration, mais il rend l’erreur difficile à attribuer et à contenir. Commencez par une tâche qui prouve la valeur avec le moins d’outils possible.

Confondre approbation visuelle et autorisation technique

Une fenêtre qui demande « autoriser » n’explique pas toujours quels outils, données et destinations sont couverts. L’approbation doit correspondre à un périmètre lisible et contrôlable côté serveur.

Copier un jeton entre plusieurs services

Un même secret utilisé pour l’hôte, le serveur MCP et l’API finale brouille les responsabilités. Il augmente aussi le rayon d’explosion d’une fuite. Séparez les audiences et les rotations.

Ne rien mesurer parce que le pilote est court

Même un test de deux jours doit laisser une preuve : appels, outils utilisés, erreurs, refus, données touchées et décisions humaines. Sans cette trace, vous ne saurez pas si le système est utile ou simplement chanceux.

La décision finale tient en quatre lignes

Avant de connecter un serveur MCP, vous devez pouvoir répondre sans jargon :

• Besoin : quelle tâche précise gagne quelque chose ?
• Frontière : quelles données, quels outils et quelles destinations sont autorisés ?
• Identité : quel compte appelle quoi, avec quelle audience et quelle rotation ?
• Arrêt : qui désactive, reprend la main et conserve la preuve ?

Si une ligne reste vide, ne branchez pas le serveur au système réel. Préparez un test isolé ou revenez à une intégration plus simple. La maturité ne se mesure pas au nombre d’outils visibles dans l’assistant, mais à la précision de la frontière que l’équipe sait défendre.

Sources et date de vérification

Sources consultées le 23 septembre 2026 :

• Model Context Protocol · version 2026-07-28 et annonce de release
• MCP · Security Best Practices
• MCP · Authorization Security Considerations
• RFC 8707 · Resource Indicators for OAuth 2.0
• OWASP · MCP Security Cheat Sheet

Cet article explique une méthode de cadrage. Il ne constitue ni une certification d’un serveur, ni un avis juridique ou une revue de sécurité complète.