Utiliser MCP pour laisser Claude et Cursor gérer ta base de données (en local)

Le Model Context Protocol d'Anthropic est discrètement devenu le standard de connexion des assistants AI aux outils externes. Cursor le supporte. Claude Desktop le supporte. Windsurf le supporte. Codex le supporte. Si tu utilises un assistant AI de code sérieux en 2026, tu utilises MCP, que tu le saches ou non.

Et l'une des choses les plus utiles que tu puisses faire avec MCP, c'est connecter ton assistant AI à ta base de données. Tu demandes « montre-moi tous les utilisateurs inscrits cette semaine » en langage courant, l'AI écrit la requête, la requête s'exécute sur ta vraie base de données, et tu récupères les résultats directement dans le chat. Pas besoin de copier-coller des définitions de schéma. Pas de SQL manuel. Pas besoin de basculer sur un outil de base de données séparé pour lancer la requête et faire une capture d'écran du résultat.

C'est franchement génial quand ça marche.

Mais il y a un piège, et c'est le genre de piège qui fait que les gens soucieux de sécurité ferment l'onglet et reviennent au manuel. La plupart des serveurs MCP de base de données — le MCP Postgres officiel, les MCP SQLite communautaires, les divers services « connecte ta base de données à ChatGPT » — fonctionnent en laissant le client AI se connecter directement à ta base de données. Ça veut dire que tes identifiants de base de données et tes résultats de requête transitent par l'infrastructure du fournisseur AI. Pour un fichier SQLite local avec lequel tu prototypes, c'est très bien. Pour une base de données Postgres de production avec de vraies données utilisateurs, c'est rédhibitoire pour la plupart des équipes.

Je développe Basevolt, une app desktop local-first pour travailler avec des bases de données, et l'une des fonctionnalités que j'ai récemment shippées est un serveur MCP intégré. L'idée est simple : ton assistant AI (Claude, Cursor, Windsurf) se connecte à BaseVolt qui tourne sur ta machine, et BaseVolt se connecte à ta base de données. L'AI ne voit jamais tes identifiants de base de données. La connexion à ta base de données reste locale. La seule chose qui quitte ta machine, ce sont les résultats de requête dont l'AI a besoin pour répondre à ta question — et même ça va directement au fournisseur AI, pas par un relais cloud intermédiaire.

Ce post est un guide pratique pour configurer tout ça, plus un regard plus approfondi sur pourquoi l'approche locale compte et comment elle se compare aux alternatives.

Le problème des MCP de base de données

Laisse-moi être précis sur le problème, parce que « sécurité » est trop vague pour être utile.

Quand tu configures un serveur MCP de base de données dans Claude Desktop ou Cursor, tu le pointes généralement vers un processus serveur qui se connecte à ta base de données. Le serveur officiel @modelcontextprotocol/server-postgres, par exemple, prend une chaîne de connexion Postgres et expose ta base de données au client AI comme un ensemble d'outils MCP — exécuter une requête, lister les tables, décrire le schéma, etc.

Voici ce qui se passe réellement quand tu demandes à Claude « montre-moi les 10 dernières commandes » :

Claude décide d'appeler l'outil query avec une chaîne SQL.
Claude Desktop envoie cet appel d'outil au processus serveur MCP qui tourne sur ta machine.
Le processus serveur MCP exécute la requête sur ta base de données Postgres.
Les résultats reviennent au serveur MCP.
Le serveur MCP renvoie les résultats à Claude Desktop.
Claude Desktop envoie les résultats à l'API d'Anthropic pour que Claude puisse les lire et répondre.

Les étapes 1 à 5 sont locales. L'étape 6 ne l'est pas. Les résultats de la requête — tes vraies données de commandes, noms de clients, montants en dollars, tout ça — sont envoyés aux serveurs d'Anthropic dans le contexte de la conversation. C'est comme ça que Claude peut les lire et répondre. C'est fondamental dans le fonctionnement de MCP : l'AI a besoin de voir les résultats pour les utiliser.

Alors, est-ce un problème ? Ça dépend. Si tu interroges une base de données de développement locale avec des fausses données, non. Si tu interroges une base de données de production avec de vraies données personnelles d'utilisateurs, oui — tu envoies ces données à un tiers, potentiellement en violation de tes accords de traitement des données, potentiellement en violation de tes engagements RGPD, HIPAA ou SOC 2.

Mais les résultats de requête qui partent vers le fournisseur AI, ce n'est même pas le pire. Le pire, ce sont les identifiants.

Avec un serveur MCP de base de données direct, le processus serveur MCP a besoin de tes identifiants de base de données pour se connecter. Ces identifiants vivent dans ton fichier de config MCP — généralement claude_desktop_config.json ou .cursor/mcp.json. Ils sont sur ton disque, ce qui est très bien. Mais le processus serveur MCP lui-même est un truc qui tourne en continu et qui a une connexion ouverte vers ta base de données. Si ce processus est compromis, ou si le client AI est trompé et exécute un appel d'outil malveillant, ta base de données est exposée.

Et puis il y a la variante du relais cloud. Certains services MCP de base de données ne tournent pas du tout en local. Tu leur donnes tes identifiants de base de données, ils se connectent à ta base de données depuis leur infrastructure cloud, et le client AI parle à leur service cloud via le réseau. Maintenant tes identifiants et tes données sont sur le serveur de quelqu'un d'autre, et tu leur fais confiance pour gérer les deux. C'est somehow à la fois plus populaire et plus évidemment problématique.

Le problème de fond : la plupart des configurations MCP de base de données te demandent de faire confiance à trop de parties avec trop d'accès. Le fournisseur AI voit tes données. Le processus serveur MCP a tes identifiants. Le service de relais cloud a les deux. Pour un protocole censé rendre les assistants AI plus utiles, le cas d'usage base de données a un problème de confiance.

Ce que MCP est réellement (primer rapide)

Avant d'aller plus loin, laisse-moi expliquer ce qu'est MCP pour les gens qui ne s'y sont pas plongés. Si tu sais déjà, saute cette section.

MCP — le Model Context Protocol — est un protocole qui permet aux assistants AI d'appeler des outils externes. Il est basé sur JSON-RPC, ce qui veut dire que c'est une façon standardisée pour un client AI (comme Claude Desktop) de parler à un processus serveur qui expose des fonctionnalités utiles.

L'architecture est simple :

Le client AI (Claude Desktop, Cursor, Windsurf) est la chose avec laquelle tu discutes. Il tourne sur ta machine.
Le serveur MCP est un processus séparé qui expose des « outils » et des « ressources » que l'AI peut appeler. Il tourne aussi sur ta machine, généralement comme un processus local lancé par le client AI.
Le protocole est le langage qu'ils utilisent pour se parler. Le client AI envoie des appels d'outils, le serveur MCP les exécute et renvoie les résultats.

Quand tu as une conversation avec Claude et que Claude décide qu'il a besoin d'interroger ta base de données, il appelle un outil MCP. Le client AI transmet cet appel au serveur MCP. Le serveur MCP fait le travail et renvoie le résultat. Claude lit le résultat et continue la conversation.

La chose clé à comprendre : le client AI décide quand appeler les outils MCP. Tu ne les invoques pas manuellement. Tu parles normalement, et l'AI déduit qu'il doit appeler un outil pour répondre à ta question. C'est ce qui donne à MCP son côté magique — tu dis « montre-moi toutes les tables » et l'AI le fait, parce qu'il sait qu'il y a un outil list_tables disponible.

Voici à quoi ressemble une config MCP minimale dans Claude Desktop :

{
  "mcpServers": {
    "my-database": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sqlite"],
      "env": {
        "DB_PATH": "/path/to/your/database.db"
      }
    }
  }
}

Ça dit à Claude Desktop : « au démarrage, lance cette commande pour spawn un processus serveur MCP. Expose ses outils sous le nom my-database. » Quand tu poses une question à Claude sur ta base de données, il peut appeler les outils que ce serveur expose.

Le protocole lui-même est ouvert et bien documenté. Anthropic a publié la spec, et il existe des SDK en TypeScript et Python. N'importe qui peut écrire un serveur MCP. C'est pourquoi il y en a déjà des centaines — pour GitHub, pour Slack, pour des systèmes de fichiers, pour des bases de données, pour fondamentalement tout ce avec quoi tu voudrais qu'une AI interagisse.

Le problème, ce n'est pas le protocole. Le protocole est très bien. Le problème, c'est la façon dont les serveurs MCP de base de données sont généralement déployés, et c'est de ça que parle le reste de ce post.

Les trois façons de connecter l'AI à ta base de données

Il y a trois patterns architecturaux que les gens utilisent pour connecter les assistants AI aux bases de données. Ils se ressemblent de l'extérieur — tu poses une question, tu obtiens une réponse — mais ils diffèrent significativement sur la destination de tes données et qui a accès à quoi.

Option 1 : Serveur MCP de base de données direct

C'est l'approche la plus courante. Tu lances un processus serveur MCP en local qui se connecte directement à ta base de données. Le serveur MCP Postgres officiel fonctionne comme ça. La plupart des serveurs MCP SQLite communautaires aussi.

Le flux ressemble à ça :

You → AI Client (Claude Desktop) → MCP Server (local process) → Your Database

Comment ça marche : Tu configures le serveur MCP avec ta chaîne de connexion ou ton chemin de fichier de base de données. Le processus serveur maintient une connexion à ta base de données. Quand l'AI appelle un outil, le serveur exécute la requête et renvoie les résultats.

Avantages : Configuration simple. Un processus, un fichier de config. Fonctionne bien pour les bases de données locales. Les serveurs officiels sont open source et auditables.

Inconvénients : Tes identifiants de base de données vivent dans le processus serveur MCP. Les résultats de requête reviennent au client AI puis au fournisseur AI. Si tu te connectes à une base de données de production, tu confies tes données au fournisseur AI. Il n'y a pas de couche de contrôle d'accès entre l'AI et ta base de données — si l'AI décide de lancer DROP TABLE users, le serveur MCP l'exécutera sans broncher (bien que certains serveurs aient des modes read-only).

Quand l'utiliser : Bases de données de développement locales, fichiers SQLite avec des données non sensibles, bases de données jetables que tu ne crains pas de perdre. Ne l'utilise pas pour la production.

Option 2 : MCP avec relais cloud

Certains services offrent un serveur MCP hébergé. Tu leur donnes tes identifiants de base de données, ils se connectent à ta base de données depuis leur cloud, et ton client AI parle à leur service via le réseau.

Le flux :

You → AI Client → Cloud Relay Service → Your Database

Comment ça marche : Tu crées un compte, tu ajoutes tes détails de connexion de base de données à leur dashboard web, et ils te donnent une URL d'endpoint MCP à mettre dans ta config client. Le client AI envoie les appels d'outils à leur cloud, leur cloud exécute les requêtes, les résultats reviennent par le même chemin.

Avantages : Pas de processus local à gérer. Fonctionne depuis n'importe quelle machine. Le service de relais peut ajouter des fonctionnalités comme le logging de requêtes, le rate limiting, des audit trails.

Inconvénients : Tes identifiants de base de données sont stockés sur le serveur de quelqu'un d'autre. Tes résultats de requête transitent par leur infrastructure. Tu as ajouté un tiers à la chaîne de confiance. Si leur service a une indisponibilité, tu perds l'accès à ta base de données depuis tes outils AI. S'ils subissent une faille, tes identifiants de base de données sont dans le rayon d'impact.

Quand l'utiliser : Honnêtement, j'ai du mal à le recommander pour des bases de données. Les compromis de sécurité sont difficiles à justifier. Peut-être pour une base de données analytics en read-only où les données sont déjà à peu près publiques, mais même là, pourquoi ajouter un intermédiaire ?

Option 3 : Serveur MCP local via une app desktop (BaseVolt)

C'est l'approche autour de laquelle j'ai construit BaseVolt. Au lieu de lancer un processus serveur MCP nu qui se connecte directement à ta base de données, tu lances une app desktop qui gère tes connexions de base de données et expose un serveur MCP comme l'une de ses fonctionnalités.

Le flux :

You → AI Client (Claude Desktop) → BaseVolt (local process) → Your Database

Comment ça marche : BaseVolt est une app desktop qui se connecte à tes bases de données — fichiers SQLite, Postgres, MySQL, Cloudflare D1. Elle gère les connexions, traite les identifiants et fournit une UI pour parcourir et modifier tes données. Elle fait aussi tourner un serveur MCP sur localhost. Ton client AI se connecte à ce serveur MCP. Quand l'AI appelle un outil, BaseVolt l'exécute sur ta base de données et renvoie les résultats.

Avantages : Tes identifiants de base de données restent dans BaseVolt, pas dans un fichier de config ou sur un serveur cloud. La connexion à ta base de données est locale. Pas de relais cloud. Tu obtiens une couche de contrôle d'accès — BaseVolt peut restreindre ce que le serveur MCP a le droit de faire (read-only, tables spécifiques, etc.). En plus, tu obtiens une UI complète d'espace de travail de base de données à côté de l'intégration MCP.

Inconvénients : Tu dois installer et lancer une app desktop. C'est une chose de plus sur ta machine. (Mais si tu utilises déjà un outil de base de données, ce n'est pas une chose supplémentaire — c'est un remplacement.)

Quand l'utiliser : Quand tu travailles avec des bases de données qui comptent — données de production, données clients, tout ce où tu ne veux pas que tes identifiants et tes résultats transitent par une infrastructure aléatoire. Ce qui, honnêtement, devrait être la plupart du temps.

Configurer le serveur MCP de BaseVolt (étape par étape)

Passons à la pratique. Voici comment configurer le serveur MCP local dans BaseVolt et le connecter à Claude Desktop, Cursor et Windsurf.

Étape 1 : Installer BaseVolt et connecter ta base de données

Télécharge BaseVolt sur basevolt.app. C'est disponible sur macOS et Windows. Installe-le comme n'importe quelle autre app desktop.

Quand tu ouvres BaseVolt pour la première fois, il te demandera d'ajouter une source de données. Tu as plusieurs options :

SQLite : Pointe-le vers un fichier .db ou .sqlite sur ta machine. BaseVolt le lit directement.
PostgreSQL : Entre ton host, port, nom de base de données, nom d'utilisateur et mot de passe. BaseVolt se connecte via le protocole wire Postgres standard.
MySQL : Même principe — host, port, identifiants.
Cloudflare D1 : Authentifie-toi avec ton compte Cloudflare et sélectionne une base de données D1. BaseVolt parle à l'API REST de D1.

Pour ce walkthrough, supposons que tu te connectes à une base de données Postgres locale. Entre tes détails de connexion, clique sur connect, et BaseVolt chargera ton schéma. Tu devrais voir tes tables, colonnes et relations dans la barre latérale.

Le plan gratuit te permet de connecter jusqu'à 2 sources de données, ce qui est largement suffisant pour essayer. Le plan Pro est à $99/an si tu en as besoin de plus.

Étape 2 : Activer le serveur MCP dans les paramètres de BaseVolt

Ouvre les paramètres de BaseVolt (icône d'engrenage en bas à gauche, ou Cmd+, sur macOS / Ctrl+, sur Windows). Va dans la section MCP.

Tu verras un toggle : « Enable MCP Server ». Active-le.

BaseVolt va démarrer un serveur MCP sur localhost. Par défaut, il choisit un port disponible et t'affiche l'URL — quelque chose comme http://localhost:3107/mcp. Note cette URL ; tu en auras besoin pour l'étape suivante.

Il y a quelques options ici qui méritent d'être mentionnées :

Mode read-only : Quand activé, le serveur MCP peut exécuter des requêtes SELECT et décrire des schémas, mais ne peut pas créer de tables, modifier des colonnes ni écrire de données. Pratique pour les bases de données de production où tu veux que l'AI analyse sans modifier.
Sources de données autorisées : Si tu as plusieurs bases de données connectées, tu peux choisir lesquelles sont exposées via MCP. Utile si tu as une base de données de production et une base de données de test et que tu ne veux que l'AI touche la base de test.
Port : Tu peux fixer le port si tu veux une config stable, ou laisser BaseVolt le choisir automatiquement.

Une fois le serveur MCP en route, tu verras un indicateur de statut dans BaseVolt montrant qu'il est actif et à l'écoute.

Étape 3 : Configurer ton client AI

Maintenant, tu dois dire à ton client AI où trouver le serveur MCP. La config est légèrement différente pour chaque outil, mais l'idée est la même : pointe-le vers l'URL localhost que BaseVolt t'a donnée.

Claude Desktop

Claude Desktop utilise un fichier de config appelé claude_desktop_config.json. L'emplacement dépend de ton OS :

macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Windows : %APPDATA%\Claude\claude_desktop_config.json

Ouvre-le (crée-le s'il n'existe pas) et ajoute une entrée BaseVolt à l'objet mcpServers :

{
  "mcpServers": {
    "basevolt": {
      "type": "url",
      "url": "http://localhost:3107/mcp"
    }
  }
}

Le type: "url" dit à Claude Desktop de se connecter à un serveur MCP en cours d'exécution via HTTP, plutôt que de spawn un nouveau processus. C'est le bon choix pour BaseVolt puisque BaseVolt gère son propre processus serveur.

Si tu es sur une ancienne version de Claude Desktop qui ne supporte pas le type url, tu peux utiliser la config basée sur commande à la place :

{
  "mcpServers": {
    "basevolt": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:3107/mcp"]
    }
  }
}

Ça utilise mcp-remote comme pont entre l'endpoint HTTP et le transport basé sur stdio de Claude Desktop. Les deux approches fonctionnent.

Sauvegarde le fichier et redémarre Claude Desktop. Au démarrage, il devrait se connecter au serveur MCP de BaseVolt. Tu peux vérifier ça en regardant les outils disponibles dans une nouvelle conversation — tu devrais voir les outils de base de données de BaseVolt listés.

Cursor

Cursor utilise un fichier .cursor/mcp.json à la racine de ton projet (ou ~/.cursor/mcp.json pour une config globale). Le format est similaire :

{
  "mcpServers": {
    "basevolt": {
      "url": "http://localhost:3107/mcp"
    }
  }
}

Le support MCP de Cursor s'est renforcé au cours de l'année écoulée. Le champ url lui dit de se connecter à un serveur MCP distant (en l'occurrence, local). Sauvegarde le fichier, et Cursor prendra en compte la config au prochain reload — tu devras peut-être recharger la fenêtre ou redémarrer Cursor.

Tu peux vérifier la connexion dans les paramètres de Cursor, sous la section MCP. Tu devrais voir basevolt listé avec un indicateur de statut vert et les outils qu'il expose.

Si tu veux limiter le serveur MCP à un projet spécifique (pour qu'il ne se connecte que quand tu travailles sur ce projet), mets le fichier .cursor/mcp.json à la racine du projet. Si tu veux qu'il soit disponible partout, utilise la config globale.

Windsurf

Windsurf (anciennement l'éditeur de Codeium) utilise un fichier de config à ~/.codeium/windsurf/mcp_config.json. La structure reflète celle de Claude Desktop :

{
  "mcpServers": {
    "basevolt": {
      "serverUrl": "http://localhost:3107/mcp"
    }
  }
}

Note que le nom du champ est serverUrl dans Windsurf, pas url — ça m'a déjà piégé. Sauvegarde le fichier et redémarre Windsurf. Tu devrais voir le serveur MCP de BaseVolt apparaître dans le panneau de paramètres MCP de Windsurf avec ses outils listés.

Une chose à noter pour les trois clients : le numéro de port dans ces exemples (3107) n'est qu'un exemple. Utilise le port réel que BaseVolt t'affiche dans ses paramètres MCP. Si tu laisses BaseVolt choisir le port automatiquement, il pourrait changer entre les redémarrages — donc soit fixe le port dans les paramètres de BaseVolt, soit mets à jour ta config client quand il change.

Étape 4 : Commencer à poser des questions

Une fois que tout est connecté, ouvre une nouvelle conversation dans ton client AI et commence simplement à parler de ta base de données. L'AI découvrira automatiquement les outils MCP que BaseVolt expose et les appellera quand c'est pertinent.

Voici quelques choses à essayer :

« Montre-moi toutes les tables de la base de données. »

L'AI appellera l'outil list_tables, BaseVolt renverra les noms des tables, et l'AI te les listera. Simple, mais immédiatement utile si tu travailles avec une base de données que tu n'as pas conçue.

« C'est quoi le schéma de la table users ? »

L'AI appelle describe_table avec users, récupère les noms de colonnes, types et contraintes, et te les explique. Plus besoin de PRAGMA table_info(users) et de plisser les yeux sur le résultat.

« Montre-moi tous les utilisateurs inscrits cette semaine. »

L'AI trouve le bon SQL — quelque chose comme SELECT * FROM users WHERE created_at >= date('now', '-7 days') — appelle l'outil query, BaseVolt l'exécute, et l'AI te présente les résultats. Si ta table users a un nom de colonne de date différent, l'AI le saura grâce au schéma qu'il a déjà exploré.

« Crée une vue kanban sur la table orders groupée par statut. »

C'est là que ça devient intéressant. Le serveur MCP de BaseVolt n'expose pas que du SQL brut — il expose des opérations de plus haut niveau pour créer des vues, configurer des dashboards et gérer ton workspace. L'AI appelle un outil create_view avec le nom de la table, le type de vue et la configuration de grouping. BaseVolt crée la vue dans son UI, et tu peux la voir immédiatement dans l'app.

« Ajoute une colonne appelée last_login_at à la table users. »

L'AI écrit l'instruction ALTER TABLE et appelle l'outil execute. BaseVolt l'exécute. Ton schéma est mis à jour. Si tu as activé le mode read-only, ça sera bloqué — c'est exactement le but.

« Génère 50 lignes d'exemple dans la table orders pour des tests. »

L'AI peut générer des données d'exemple réalistes à partir de ton schéma — des noms aléatoires, des dates dans une plage, des statuts parmi les valeurs enum existantes. Utile quand tu prototypes et que tes tables sont vides.

La chose clé, c'est que tu n'as pas à penser aux outils. Tu parles, c'est tout. L'AI gère la traduction de « montre-moi les utilisateurs inscrits cette semaine » vers « appelle l'outil query avec cette chaîne SQL ». C'est ça, tout l'intérêt de MCP — il abstrait l'appel d'outils derrière le langage naturel.

Ce que tu peux vraiment faire avec l'AI + ta base de données

Laisse-moi être plus précis sur les capacités, parce que « interroger ta base de données avec l'AI » sous-estime ce qu'on peut faire. Voici ce que tu peux réellement accomplir via l'intégration MCP.

Interroger des données en langage courant

C'est l'évident. Tu poses des questions en français, l'AI les traduit en SQL, BaseVolt exécute le SQL, et tu obtiens des réponses. L'AI a accès à ton schéma complet, donc il connaît tes noms de tables, noms de colonnes, relations et types. Il écrit du SQL correct parce qu'il peut voir la structure de tes données.

Quelques exemples que j'utilise en pratique :

« Combien de commandes ont été passées le mois dernier, réparties par statut ? »
« Montre-moi les 10 meilleurs clients par valeur totale de commande. »
« Quels utilisateurs ont un abonnement qui expire dans les 30 prochains jours ? »
« Quelle est la valeur moyenne des commandes pour les utilisateurs inscrits via parrainage vs. organique ? »

L'AI gère les joins, les agrégations, les calculs de dates et le filtrage. Pour les requêtes complexes, il te montrera souvent le SQL qu'il s'apprête à exécuter avant de le lancer, ce qui est un bon sanity check.

Créer et modifier des tables

L'AI peut écrire et exécuter du DDL — CREATE TABLE, ALTER TABLE, CREATE INDEX. Si tu dis « j'ai besoin d'une table pour suivre des feature flags », l'AI concevra un schéma raisonnable et la créera :

CREATE TABLE feature_flags (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT NOT NULL UNIQUE,
  enabled BOOLEAN NOT NULL DEFAULT 0,
  description TEXT,
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Il choisit des types sensés, ajoute des contraintes et inclut des timestamps parce que c'est une bonne pratique. Tu peux affiner de façon conversationnelle : « ajoute une colonne pour le pourcentage d'utilisateurs qui devraient recevoir le flag » et il modifiera la table.

C'est là que l'exécution locale compte. L'AI écrit le SQL, mais BaseVolt l'exécute localement sur ta base de données. Le SQL lui-même va au fournisseur AI (dans le cadre de l'appel d'outil), mais tes identifiants de base de données, non. Et l'exécution se fait sur ta machine, pas dans un sandbox cloud.

Configurer des vues

BaseVolt supporte plusieurs types de vues sur tes tables : grid (la vue table par défaut), kanban (groupée par un champ de statut), gallery (basée sur des cartes, pratique pour des enregistrements avec des images) et calendar. Via l'intégration MCP, l'AI peut créer et configurer ces vues.

Tu peux dire :

« Crée une vue kanban sur la table tickets groupée par priorité. »
« Fais une vue gallery des produits montrant le nom, le prix et l'image. »
« Configure une vue calendar sur events en utilisant le champ start_date. »

L'AI appelle les outils de création de vues de BaseVolt avec les bons paramètres. La vue apparaît immédiatement dans l'UI de BaseVolt. Tu peux ensuite l'affiner : « ajoute un filtre pour ne montrer que les tickets ouverts » ou « groupe le kanban par statut au lieu de la priorité ».

C'est vraiment utile pour les non-développeurs qui doivent travailler avec une base de données mais ne veulent pas apprendre l'UI d'un outil de base de données. Ils décrivent juste ce qu'ils veulent voir et l'AI le configure.

Construire des dashboards

BaseVolt a une fonctionnalité de dashboard où tu peux combiner des graphiques, des métriques et des tables en une seule vue. L'AI peut les construire from scratch.

« Fais un dashboard avec le total des inscriptions ce mois-ci, le MRR, et un graphique en ligne des inscriptions sur les 30 derniers jours. »

L'AI va :

Interroger ta base de données pour les données pertinentes.
Créer des widgets de dashboard — un widget métrique pour le total des inscriptions, un widget métrique pour le MRR, un graphique en ligne pour la tendance des inscriptions.
Les disposer sur un dashboard.

Tu obtiens un dashboard fonctionnel dans BaseVolt sans rien configurer manuellement. Là encore, tu peux affiner : « fais afficher au graphique les 90 derniers jours à la place » ou « ajoute une répartition par source d'inscription ».

Explorer le schéma sans retenir les noms de tables

Si tu travailles avec une base de données que tu n'as pas conçue — une base de code héritée, un projet client, une app open-source que tu modifies — l'exploration du schéma est inestimable. Au lieu de lancer \dt dans psql et de scroller parmi les noms de tables, tu demandes simplement :

« Quelles tables y a-t-il dans cette base de données ? »
« Comment la table orders est-elle liée à la table customers ? »
« Y a-t-il une table qui stocke les préférences des utilisateurs ? »
« Quelles tables ont une clé étrangère vers la table users ? »

L'AI explore le schéma via les outils MCP et te l'explique en langage courant. C'est comme avoir un expert de base de données déjà familier avec ton schéma assis à côté de toi.

Générer des données d'exemple

Quand tu prototypes, tu as souvent besoin de données d'exemple. L'AI peut les générer :

« Insère 20 faux utilisateurs avec des noms réalistes, des emails et des dates d'inscription aléatoires sur le dernier mois. »

L'AI écrit des instructions INSERT avec des données générées et les exécute via BaseVolt. Il respecte ton schéma — types corrects, clés étrangères valides, valeurs raisonnables pour les colonnes enum. Ça m'économise probablement 15 minutes à chaque fois que je commence un nouveau prototype.

Pourquoi le local compte ici

Je veux m'attarder là-dessus parce que c'est toute la raison pour laquelle j'ai intégré le serveur MCP dans BaseVolt plutôt que de simplement shipper un serveur MCP de base de données autonome.

Les trois approches que j'ai décrites — MCP direct, relais cloud, local via app desktop — te permettent toutes de faire les mêmes choses. L'AI peut interroger tes données, créer des tables, configurer des vues. L'expérience utilisateur est quasi identique. La différence est entièrement dans l'endroit où vivent tes données et tes identifiants.

Avec un serveur MCP de base de données direct, tes identifiants de base de données sont dans un fichier de config et le processus serveur MCP. Tes résultats de requête transitent du serveur MCP vers le client AI puis vers le fournisseur AI. L'exposition des identifiants est limitée (processus local, fichier de config local), mais l'exposition des données est la même que dans toute interaction AI cloud.

Avec un relais cloud, tes identifiants sont sur les serveurs du service de relais. Tes données transitent par leur infrastructure. Tu as ajouté un tiers à la chaîne. C'est la pire option du point de vue de la confiance.

Avec le serveur MCP local de BaseVolt, tes identifiants de base de données vivent dans BaseVolt — chiffrés, gérés par l'app, jamais exposés au client AI ni au fournisseur AI. La connexion à ta base de données est maintenue par BaseVolt localement. Le client AI parle au serveur MCP de BaseVolt via localhost. La seule chose qui va vers le fournisseur AI, ce sont les résultats des appels d'outils — les résultats de requête dont l'AI a besoin pour répondre à ta question.

Cette dernière partie est inévitable. Si tu veux que l'AI te dise « tu as 47 utilisateurs inscrits cette semaine », l'AI a besoin de voir le résultat de requête qui dit 47. Les données dans ce résultat vont au fournisseur AI. Il n'y a pas moyen de contourner ça avec les architectures AI actuelles — le modèle a besoin du contexte pour raisonner dessus.

Mais voilà le truc : tu contrôles les données que l'AI voit. Tu peux utiliser le mode read-only. Tu peux n'exposer que certaines tables. Tu peux interroger avec des filtres qui excluent les colonnes sensibles. Le serveur MCP local te donne une couche de contrôle que les connexions directes à la base de données n'offrent pas.

Et les identifiants ne quittent jamais ta machine. Ça, c'est le point capital. Ton mot de passe Postgres, ta chaîne de connexion MySQL, ton token API Cloudflare — ils restent dans BaseVolt. Le client AI ne les voit jamais. Le fournisseur AI ne les voit jamais. Aucun relais cloud ne les voit.

Pour les équipes avec des exigences de sécurité — SOC 2, HIPAA, RGPD, politiques internes sur l'accès aux données par des tiers — c'est la différence entre « on peut utiliser ça » et « on ne peut pas utiliser ça ». L'approche locale n'élimine pas tous les risques (l'AI voit toujours les résultats de requête), mais elle élimine le risque d'exposition des identifiants, qui est celui qui te fait pirater.

Tableau comparatif

Voici une comparaison côte à côte des trois approches :

	MCP DB direct	MCP relais cloud	MCP local BaseVolt
Configuration	Éditer un fichier de config, installer un package serveur	Créer un compte, ajouter les identifiants au dashboard web, obtenir l'URL d'endpoint	Installer l'app desktop, connecter la base de données, activer MCP
Flux de données	Client AI → processus local → ta DB	Client AI → service cloud → ta DB	Client AI → BaseVolt (local) → ta DB
Exposition des identifiants	Fichier de config local + processus local	Serveurs du service cloud	App BaseVolt uniquement (local, chiffré)
Fonctionne hors ligne	Oui (pour les DB locales)	Non	Oui (pour les DB locales)
Création de vues/dashboards	Non (SQL brut uniquement)	Selon le service	Oui (kanban, gallery, dashboard, calendar)
Assistants AI supportés	Tout client compatible MCP	Tout client compatible MCP	Tout client compatible MCP
Couche de contrôle d'accès	Limitée (certains serveurs ont un mode read-only)	Selon le service	Oui (mode read-only, contrôle par source de données, restrictions au niveau table)
Coût	Gratuit (open source)	Généralement un abonnement	Plan gratuit (2 sources), Pro $99/an

Le tableau est clair : si tu as juste besoin de lancer des requêtes sur un fichier SQLite local et que la sécurité ne te préoccupe pas, l'approche MCP direct suffit. Si tu as besoin d'un accès à une base de données de production avec protection des identifiants et contrôle d'accès, l'approche par app desktop locale est la seule qui ait du sens.

Considérations de sécurité

Ce serait irresponsable d'écrire ce post sans être clair sur les compromis de sécurité, même avec l'approche locale. Voici ce à quoi tu devrais réfléchir.

L'AI voit toujours tes résultats de requête. C'est le compromis fondamental de l'utilisation de n'importe quel assistant AI avec tes données. Quand tu demandes « montre-moi tous les utilisateurs » et que l'AI appelle l'outil query, le result set — de vraies données utilisateurs — retourne au fournisseur AI dans le cadre de la conversation. L'AI a besoin de ces données pour répondre à ta question. Il n'y a pas moyen que l'AI raisonne sur tes données sans que l'AI ne voie tes données.

Ça signifie : ne demande pas à l'AI d'interroger des colonnes avec des données que tu ne veux pas envoyer au fournisseur AI. Si ta table users a une colonne password_hash, ne fais pas de SELECT *. Utilise le mode read-only et restreins les tables exposées si ça te préoccupe. Ou sois simplement attentif à ce que tu demandes.

Ne connecte pas de bases de données de production avec un accès en écriture si tu ne fais pas confiance à la configuration. L'AI peut exécuter du DDL et du DML. Si tu lui donnes un accès en écriture à une base de données de production, il peut dropper des tables, modifier des données, supprimer des enregistrements. La plupart du temps, l'AI fera ce que tu demandes et rien d'autre. Mais les modèles AI peuvent faire des erreurs, et le prompt injection est un vecteur d'attaque réel — si l'AI lit un prompt malveillant intégré dans tes données, il pourrait exécuter des requêtes non prévues.

Pour les bases de données de production, utilise le mode read-only. Le serveur MCP de BaseVolt le supporte — il restreint les outils exposés aux requêtes et à l'inspection de schéma, pas d'écriture. C'est le défaut sûr pour tout ce que tu ne peux pas te permettre de perdre.

Le serveur MCP de BaseVolt ne tourne que sur localhost. Il se bind sur 127.0.0.1, pas sur 0.0.0.0. Ça signifie qu'il n'est pas accessible depuis d'autres machines de ton réseau, seulement depuis les processus sur ta propre machine. Si tu es sur une machine partagée ou un réseau d'entreprise, ça compte. Personne d'autre ne peut se connecter à ton serveur MCP.

Tu peux restreindre ce que le serveur MCP peut faire. Au-delà du mode read-only, BaseVolt te permet de choisir quelles sources de données sont exposées via MCP. Si tu as une base de données de production et une base de données de développement connectées, tu peux n'exposer que la base de développement à l'AI. La base de production reste accessible dans l'UI de BaseVolt mais n'est pas joignable via MCP.

Tes identifiants sont stockés localement par BaseVolt. Ils sont chiffrés au repos. Ils ne sont jamais transmis au client AI ni au fournisseur AI. Ils ne sont jamais envoyés aux serveurs de BaseVolt (BaseVolt n'a pas de serveurs qui gèrent tes connexions de base de données — c'est une app desktop, tout est local). Si tu désinstalles BaseVolt, les identifiants sont supprimés.

Audite ce que l'AI fait. BaseVolt log les appels d'outils MCP, donc tu peux voir quelles requêtes l'AI a lancées. Si quelque chose paraît anormal — un DROP TABLE inattendu, une requête sélectionnant des colonnes sensibles — tu peux le repérer. C'est quelque chose que les serveurs MCP directs ne fournissent souvent pas, et c'est précieux pour la tranquillité d'esprit.

En résumé sur la sécurité : l'approche locale est significativement meilleure que les alternatives, mais ce n'est pas magique. Tu envoies toujours des résultats de requête à un fournisseur AI. Tu donnes toujours à un système AI la capacité d'exécuter du SQL. Sois réfléchi quant aux bases de données que tu connectes, au niveau d'accès que tu accordes et à ce que tu demandes à l'AI de faire.

En résumé

MCP est un protocole vraiment utile. La capacité de poser des questions à un assistant AI sur ta base de données et d'obtenir de vraies réponses — sans copier-coller des définitions de schéma ni lancer des requêtes manuellement — change ta façon de travailler avec les données. C'est le genre de fonctionnalité qui semble gadget jusqu'à ce que tu l'utilises pendant une semaine, et après tu n'imagines plus revenir en arrière.

Mais la façon dont la plupart des gens configurent leurs connexions MCP de base de données a un vrai problème : tes identifiants et tes données transitent par une infrastructure que tu ne contrôles pas. Pour du développement local, c'est acceptable. Pour tout ce qui compte, ça ne l'est pas.

L'approche du serveur MCP local — client AI vers BaseVolt vers ta base de données, le tout sur ta machine — te donne le confort du travail de base de données assisté par AI sans l'exposition des identifiants. Tu récupères l'interrogation, l'exploration de schéma, la création de vues, la construction de dashboards. Tu ne récupères pas les maux de tête de sécurité.

Si tu utilises déjà Claude Desktop, Cursor ou Windsurf et que tu travailles avec des bases de données, ça vaut le coup de le configurer. Ça prend environ cinq minutes, et une fois que ça tourne, tu l'utiliseras constamment.

Essayez-le sur basevolt.app — pas d'inscription, pas de carte bancaire. Le plan gratuit inclut 2 sources de données, ce qui suffit pour connecter ta base de données principale et une base de données de test. Installe-le, connecte ta base de données, active le serveur MCP, pointe ton client AI dessus, et commence à poser des questions.

Si tu rencontres des problèmes ou si tu as des questions sur la configuration, le site de démo montre le workflow complet sans rien installer.

...retrouvez-moi sur X.