Sécurité MCP : faut-il donner à Claude ou Cursor un accès direct à votre base de données ?

Commençons par un scénario devenu courant en 2026. Vous utilisez Claude ou Cursor pour écrire votre app. Quelqu'un (peut-être moi, dans un article précédent) suggère de connecter l'IA à votre base de données via MCP pour qu'elle puisse répondre à des questions sur vos vraies données, configurer des vues, même gérer le schéma. C'est réellement utile — je l'utilise tous les jours. Mais avant de brancher un assistant IA sur une base de production, il y a une question à laquelle vous devriez répondre délibérément plutôt que par défaut :

Qu'est-ce que vous accordez exactement, et à qui ?

La réponse honnête, c'est que « l'accès MCP à une base de données » n'est pas une seule chose. C'est un spectre qui va de « l'exploration en lecture seule, inoffensive, d'une base de dev » à « des identifiants de production transitant par l'infrastructure d'un tiers ». La posture de sécurité de votre configuration dépend de trois variables, et vous devriez pouvoir nommer les trois avant de connecter quoi que ce soit.

Variable 1 : où vit réellement la connexion de l'IA ?

C'est la décision la plus importante, et celle que la plupart des gens ratent parce que les options se ressemblent de l'extérieur.

Connexion directe (identifiants dans la config MCP). La configuration la plus courante : vous faites tourner un processus serveur MCP qui se connecte directement à votre base avec une chaîne de connexion stockée dans votre fichier de config — claude_desktop_config.json ou .cursor/mcp.json. Quand l'IA appelle un outil, le serveur exécute la requête. La connexion est locale, mais vos identifiants reposent dans un fichier de config en clair, et le processus serveur MCP lui-même garde une connexion ouverte et privilégiée à votre base tant qu'il tourne. Si ce processus est compromis — ou si l'IA est piégée dans un appel d'outil destructeur — il n'y a rien entre l'IA et vos données.

Relais cloud (identifiants sur leur serveur). Certains services « connectez votre base à ChatGPT/Claude » ne tournent pas du tout en local. Vous leur confiez vos informations de connexion via un dashboard web, ils se connectent à votre base depuis leur infrastructure, et votre client IA parle à leur service cloud. Maintenant, vos identifiants et vos données sont sur le serveur de quelqu'un d'autre. C'est le pire des deux mondes et le plus difficile à justifier.

App locale avec serveur MCP géré (les identifiants ne quittent jamais votre machine). La configuration autour de laquelle j'ai construit Basevolt : une app de bureau détient vos connexions de base, et elle expose un serveur MCP sur localhost auquel votre client IA se connecte. L'IA ne voit jamais vos identifiants — elle parle à l'app locale, et l'app parle à la base. Le problème du fichier d'identifiants disparaît, et vous obtenez une couche où l'accès peut réellement être contrôlé.

La règle empirique : l'IA ne devrait jamais détenir vos identifiants de base, et vos identifiants ne devraient jamais quitter votre machine. Si l'une ou l'autre est vraie dans votre configuration, vous êtes à l'extrémité risquée du spectre.

Variable 2 : que peut réellement faire l'IA ?

« Accès MCP à une base de données » peut vouloir dire n'importe quoi, de « exécuter des SELECT » à « supprimer des tables ». Le périmètre de ce que l'IA peut faire est une décision de sécurité que vous prenez, que vous le réalisiez ou non. La question à poser : quelle est la pire chose que cette configuration pourrait faire, et ai-je un contrôle qui l'arrête ?

Les contrôles, par ordre approximatif d'importance :

Mode lecture seule. Si le serveur MCP le supporte, c'est le contrôle le plus précieux. L'IA peut interroger et décrire le schéma mais ne peut pas écrire, modifier ou supprimer. Pour les bases de production, c'est la différence entre « l'IA analyste » et « l'IA avec une arme chargée ». Si vous connectez un assistant à quoi que ce soit avec de vraies données, commencez en lecture seule.

Ciblage de sources de données ou tables spécifiques. Vous avez probablement plus d'une base connectée — une de production et une de brouillon, ou plusieurs projets. Pouvoir choisir celles que l'IA peut toucher signifie qu'une erreur à un endroit n'atteint pas tout.

Pas d'exécution SQL directe. Certaines configurations MCP exposent des opérations structurées plutôt que du SQL brut — « créer une vue », « définir un type de champ », « lister les tables » — plutôt que « exécuter cette chaîne de requête arbitraire ». C'est une amélioration de sécurité significative : l'IA peut faire des choses utiles sans pouvoir exécuter tout ce qu'elle imagine.

Révocation d'accès. La capacité de couper l'accès de l'IA instantanément — fermer l'app, déconnecter la base, éteindre le serveur — compte plus qu'on ne le croit. Avec une app locale, c'est un bouton ; avec un relais cloud, vous dépendez de leur panneau d'admin et de leur timing.

Variable 3 : où vont vos données quand l'IA les lit ?

Voici la partie que les gens oublient. Même dans une configuration entièrement locale, quand l'IA répond à une question sur vos données, les résultats de la requête sont envoyés au fournisseur IA — c'est ainsi que l'IA peut les lire et répondre. C'est fondamental au fonctionnement de ces outils ; le modèle doit voir les données pour en parler.

Donc la vraie question n'est pas « mes données quittent-elles ma machine ? » — avec tout assistant IA, les données dont vous parlez vont au modèle. La question est : quelles données demandez-vous, et avez-vous le droit de les y envoyer ? Si vous explorez une base de dev locale avec des données synthétiques, ce n'est pas un problème. Si vous connectez un assistant à une base de production avec des données personnelles de clients, vous envoyez ces données à l'infrastructure de modèles d'un tiers — ce qui peut être acceptable selon vos politiques, ou être un problème RGPD/contractuel. Sachez dans lequel vous êtes avant de connecter, pas après.

La configuration que je recommanderais réellement

Je vais vous donner une posture concrète, pas seulement des principes. C'est la configuration que je fais tourner pour mes propres projets :

Une app locale (ou un serveur MCP local) détient les connexions — jamais de relais cloud, jamais d'identifiants posés dans le fichier de config du client IA.
Les bases de production commencent en lecture seule. Si vous voulez que l'IA écrive, pointez-la d'abord vers une copie de staging ou de brouillon. L'histoire de « l'agent serviable qui renomme une colonne sur la mauvaise table » n'est pas hypothétique.
Limitez l'IA aux bases dont elle a besoin. Si le serveur MCP vous laisse choisir quelles sources de données il expose, exposez le minimum.
Supposez que tout ce dont vous parlez va au modèle. Donc ne demandez pas à l'assistant des données que vous ne devriez pas envoyer à un tiers. C'est la règle qui attrape les gens : l'architecture va bien, ce sont les données le problème.

Ce dernier point mérite d'être souligné, parce que c'est là que la plupart des discussions « sécurité MCP » se terminent discrètement : le protocole peut être local, les identifiants peuvent être sûrs, et vous pouvez quand même fuiter des données clients simplement en posant la bonne question. La sécurité de l'accès MCP à une base, c'est trois parts d'architecture et une part de jugement — et la part de jugement est la vôtre.

Les questions à poser avant de connecter

Si vous êtes sur le point de câbler l'accès MCP à une base, passez en revue ceci :

Où vivent les identifiants ? Si la réponse est « dans le fichier de config du client IA » ou « sur le serveur d'un relais », corrigez ça d'abord.
Quelle est la pire requête que l'IA pourrait exécuter ? Si la réponse est « tout supprimer », il vous faut le mode lecture seule ou une base limitée avant de continuer.
Quelles données vais-je demander ? Si une partie est des données clients, vérifiez ce que vos politiques disent de les envoyer à un fournisseur de modèles.
Comment je révoque l'accès ? Si ce n'est pas instantané et local, c'est une lacune.

Ces questions ne sont pas exotiques — ce sont celles que vous poseriez pour toute intégration qui peut toucher votre base. La différence avec MCP, c'est que la surface est plus grande : un assistant IA est plus capable, plus créatif et plus difficile à prédire qu'un cron. C'est exactement pour ça que ça vaut la peine d'être délibéré.

Où ça vous laisse

L'accès MCP à une base est l'une des choses les plus utiles de la vague d'outils IA — je l'utilise tous les jours, et j'ai écrit sur sa mise en place locale et sur la comparaison des options architecturales. Mais « utile » et « sûr » ne sont pas la même chose, et l'écart entre les deux est votre responsabilité.

La bonne nouvelle : la version sûre n'est pas plus dure que la version dangereuse. Un serveur MCP local avec des identifiants détenus par votre propre app, en lecture seule pour tout ce qui compte, limité aux bases dont il a besoin, et l'habitude de demander « serais-je à l'aise d'envoyer ces données à un modèle ? » avant chaque conversation — cette configuration vous apporte l'essentiel de la valeur avec presque aucun risque. La version dangereuse n'est pas celle avec un firewall mal configuré ; c'est celle où quelqu'un a branché une IA capable sur une base de production sans jamais poser ces questions.