
Laissez Cursor gérer votre projet Supabase
Passer de l'éditeur au dashboard pour vérifier les tables, les logs et les migrations casse votre concentration.
Comment ça se connecte
Cette configuration s'adresse aux développeurs qui construisent sur Supabase et retournent sans cesse au dashboard pour vérifier tables, logs et migrations. Le serveur MCP Supabase permet à Cursor ou Claude Code de lister les tables, d'exécuter du SQL, de lire les logs et de rédiger des migrations, et GitHub conserve ces migrations dans une branche relue. Vous posez vos questions sur la base de données depuis l'éditeur au lieu de cliquer dans le dashboard.
Mise en place
1Ajouter le serveur MCP Supabase
Dans Cursor, ouvrez Settings > MCP et ajoutez le serveur distant de Supabase sur https://mcp.supabase.com/mcp, ou lancez claude mcp add avec la même URL dans Claude Code. Connectez-vous à Supabase dans la fenêtre de navigateur qui s'ouvre et choisissez votre organisation. Vérifiez que des outils comme list_tables et execute_sql apparaissent.
Astuce: La première fois, connectez un projet de développement, pas la production.
2Commencer en lecture seule
Ajoutez read_only=true et project_ref=your-project-ref comme paramètres de requête à l'URL du serveur. Le mode lecture seule exécute le SQL avec un utilisateur Postgres en lecture seule, et le project ref empêche l'agent de toucher à d'autres projets. Demandez à l'agent de lister les tables pour confirmer le périmètre.
Astuce: Vous trouverez le project ref dans l'URL du projet ou sous Project Settings.
3Poser vos questions dans le contexte
Demandez à l'agent de décrire une table, d'expliquer une requête lente, de vérifier les logs d'erreurs ou de rédiger une migration pour une nouvelle colonne. Il exécute des requêtes de lecture et renvoie le SQL qu'il prévoit pour toute modification. Lisez le SQL avant d'appliquer quoi que ce soit.
Astuce: Demandez la vérification des advisors pour repérer les politiques RLS et les index manquants.
4Committer les migrations
Enregistrez les nouvelles migrations sous forme de fichiers dans supabase/migrations et demandez à l'agent de les committer sur une nouvelle branche via le serveur MCP GitHub ou votre git local. Ouvrez une pull request pour que quelqu'un relise le SQL avant qu'il n'atteigne la production. Appliquez les migrations via votre processus de déploiement habituel.
Astuce: Tenez l'agent à l'écart des écritures en production ; laissez la CI ou la CLI Supabase appliquer les migrations.
Ensuite, demandez
Bon à savoir
Ce qu'il vous faut
- Un compte Supabase et un projet de développement
- Cursor ou Claude Code
- Un dépôt GitHub avec un dossier supabase/migrations
- La CLI Supabase si vous appliquez les migrations en local
Limites
- Le mode lecture seule bloque les écritures : l'agent ne peut donc pas tester une migration sur la base pour vous.
- Le contenu des tables peut contenir du texte d'injection de prompt ; vérifiez ce que fait l'agent après avoir lu des données utilisateur.
- L'agent ne voit que le projet ciblé, pas vos autres environnements.
Restez en sécurité
- Gardez le mode lecture seule pour les projets de production.
- Limitez d'abord le serveur à un projet de développement.




