Serveur MCP : pourquoi isoler l'accès avant de brancher l'IA sur vos données
Connecter une IA à vos outils internes via un serveur MCP mal cadré peut exposer tout votre système. La sécurisation coûte moins cher que la fuite.
Un assistant IA branché sur vos outils, sans garde-fou
Une PME veut gagner du temps : brancher un assistant IA sur son CRM, sa base de commandes ou son ERP pour répondre aux questions des équipes sans qu'elles ouvrent dix onglets. Un développeur, interne ou prestataire, met en place un serveur MCP en quelques jours. Ça fonctionne, la démo impressionne, tout le monde passe à autre chose.
Ce qui n'a pas été vérifié, c'est ce que ce serveur peut réellement faire. Un serveur MCP est un pont : il expose à l'IA une liste d'actions possibles — lire une fiche client, chercher une commande, consulter un solde. Si ce pont est construit avec un compte disposant de tous les droits, l'IA hérite de tous les droits. Elle ne le sait pas, elle exécute simplement ce qu'on lui a rendu accessible, y compris quand une requête mal formulée, ou une tentative délibérée de contournement glissée dans une question anodine, la pousse à sortir des cas d'usage prévus.
Le risque n'est pas théorique parce que l'IA serait malveillante. Il vient du fait que la plupart des intégrations sont pensées pour marcher, pas pour résister. On code l'accès aux données avant de coder les limites de cet accès. Résultat : un outil censé faire gagner du temps devient une porte ouverte sur des informations qui n'auraient jamais dû transiter par une conversation, salaires, contrats, coordonnées bancaires, historiques médicaux selon le secteur.
Ce constat ne doit pas faire renoncer à connecter l'IA aux systèmes internes. Il doit faire changer l'ordre des opérations : cadrer l'accès avant d'ouvrir le canal, pas après un incident.
Ce qu'il faut faire avant de connecter un serveur MCP à vos données
- Créer un compte de service dédié pour le serveur MCP, avec des droits limités aux tables et fonctions strictement nécessaires — jamais le compte administrateur, jamais un accès en écriture par défaut.
- Établir une liste explicite des actions autorisées (lecture seule sur telle catégorie de données, aucune requête libre sur l'ensemble de la base) plutôt qu'un accès ouvert que l'on restreindra « plus tard ».
- Journaliser chaque appel : qui a demandé quoi, à quel moment, avec quelle réponse. Sans journal, une anomalie passe inaperçue jusqu'à ce qu'elle devienne un problème.
- Faire tester le périmètre par quelqu'un qui n'a pas conçu l'outil : lui demander volontairement de faire sortir une donnée hors du cadre prévu, avant la mise en production, pas après.
- Revoir les droits à chaque nouvel outil branché sur le serveur. Un périmètre qui s'étend sans validation explicite finit toujours plus large que prévu.
Ces cinq points ne demandent pas une refonte technique majeure. Ils demandent qu'une personne responsable du projet se pose la question avant que le serveur ne parle à un système de production, et qu'elle documente la réponse.
Ce que vous devez surveiller pour savoir si l'isolation tient
Une fois le serveur en production, la vérification ne s'arrête pas au lancement. Trois signaux méritent un contrôle régulier : le volume de données consultées par requête doit rester cohérent avec l'usage prévu — une hausse soudaine mérite d'être expliquée, pas ignorée. Le journal d'accès doit être relu, même sommairement, à intervalle défini, pas seulement consulté en cas d'incident supposé. Enfin, chaque ajout de fonctionnalité au serveur MCP doit passer par la même question qu'au démarrage : quel accès minimal cette fonction exige-t-elle réellement, et qui l'a validé.
Le coût de ces vérifications se compte en heures de travail réparties dans le temps. Le coût d'une fuite se compte en confiance perdue, en obligations de notification, et souvent en temps passé à reconstituer ce qui a été exposé faute d'avoir journalisé correctement. La comparaison n'a pas besoin d'un chiffre précis pour être tranchée : un accès mal cadré coûte toujours plus cher à réparer qu'à prévenir.
Cadrer votre intégration IA avant qu'elle touche vos données sensibles
ArkonLabs conçoit des intégrations IA avec un périmètre d'accès défini dès le départ, mesuré et ajusté dans le temps, pas ouvert par défaut. Si un projet d'assistant connecté à vos outils internes est en réflexion, la question du périmètre se pose avant l'écriture du code — parlons-en sur www.arkon-labs.com.