Construire la base de données de votre produit avec Supabase
Votre produit digital doit retenir des choses : qui sont vos clients, ce qu'ils ont acheté, où chacun en est. Cela s'appelle une base de données, et c'est précisément là que la plupart des coachs, formateurs et créateurs décrochent : ça sent le serveur, le jargon, le territoire réservé aux développeurs. Alors on bricole avec des tableurs, ou pire, on monte une base qui fonctionne mais qui laisse les données de tout le monde lisibles par tout le monde.
Cette masterclass vous donne la méthode en trois temps : poser le contenant, modéliser ce que votre produit doit retenir, activer la sécurité ligne par ligne. À la clé : la base de données complète de votre produit, prête en une après-midi avec Supabase, sans serveur à gérer.
Ce que cet exercice ne peut pas casser
L'exercice se fait sur une feuille, pour vous seul : vous ne touchez à aucune base existante, vous ne cassez rien. Et même ensuite, le SQL généré s'exécute dans votre propre projet Supabase, vide au départ : au pire, vous supprimez le projet et vous recommencez.
Ce que vous saurez faire à la fin
- Modéliser sur une feuille ce que votre produit doit retenir : une table par chose, les colonnes, les relations.
- Faire générer le SQL complet de votre base, lisible et commenté, prêt à coller dans le SQL Editor de Supabase.
- Activer la sécurité ligne par ligne (RLS) sur chaque table et vérifier vous-même qu'elle tient.
- Niveau membre· le prompt prêt à coller qui transforme votre schéma sur feuille en SQL complet, sécurité ligne par ligne comprise.
- Niveau Pro· je construis et sécurise votre base avec vous, table par table, jusqu'au test final.
Trois temps de construction, plus le test que vous faites vous-même à la fin.
Trois temps, puis la preuve
Une base de données n'est pas d'abord un sujet de développeur, c'est un sujet de mémoire : qu'est-ce que votre produit doit retenir, et qui a le droit de le lire ? La méthode tient en trois temps, plus une vérification que vous faites vous-même. Vous restez l'architecte de ce qui est retenu ; l'IA, elle, écrit le SQL.
1Poser le contenant : votre projet Supabasedoute : « encore un serveur à gérer ? »
Supabase héberge pour vous une base PostgreSQL, le standard des bases de données, sans serveur à installer ni à maintenir. Vous créez un projet et vous obtenez d'un coup le contenant : la base elle-même, l'authentification de vos utilisateurs, et le SQL Editor, l'éditeur dans lequel vous collerez le SQL généré. C'est tout ce dont la suite a besoin.
2Modéliser ce que votre produit doit retenirdoute : « je ne suis pas développeur, par où commencer ? »
Oubliez la technique et posez la seule vraie question : qu'est-ce que mon produit doit garder en mémoire ? Chaque chose à retenir devient une table : un nom, des colonnes, le type de chaque colonne, un identifiant en UUID (un identifiant unique, impossible à confondre avec un autre). Pour chaque table, une phrase : pourquoi elle existe. Puis les relations, en clair avant tout SQL : qui pointe vers qui. Un achat pointe vers le client qui l'a fait.
3Activer la sécurité ligne par ligne (RLS)doute : « et si un client lisait les données des autres ? »
C'est le temps que beaucoup sautent, et c'est le plus important. La RLS, la sécurité ligne par ligne, se décide table par table : vous l'activez sur chacune, avec au moins une politique simple : chaque utilisateur ne lit et ne modifie que ses propres lignes. La règle ne souffre aucune exception : aucune table laissée ouverte. Si une table ne peut pas être protégée ainsi, vous devez savoir pourquoi, pas l'ignorer.
4Vérifier vous-même que la sécurité tientdoute : « comment en être sûr sans être expert ? »
Pas besoin d'audit : un test que vous faites à la main, dans Supabase. Connectez-vous : vous voyez vos données. Déconnectez-vous : vous ne voyez plus rien. Cette liste de vérification clôt la méthode : tant qu'elle ne passe pas, la base n'est pas finie. Et si une étape vous bloque, recollez l'erreur exacte au prompt : il vous dit quoi corriger.
À vous de jouer : votre schéma sur feuille
Prenez une feuille. Ce schéma est exactement la matière que vous collerez ensuite dans le prompt, alors soignez les noms.
Le résultat, en 30 secondes
À partir de votre schéma sur feuille (ou d'un simple mode interview si vous partez de zéro), le prompt rend cinq blocs : le modèle en clair, les relations, le SQL des tables prêt à coller dans le SQL Editor, le SQL de la sécurité table par table, et votre liste de vérification.
Table achats : garde la trace de qui a acheté quoi, et quand. Colonnes : identifiant (UUID), client, produit, date. Relation : chaque achat pointe vers un client. Sécurité : RLS activée, politique « chaque utilisateur ne voit que ses propres achats ». En bas : trois points à tester vous-même, dont celui-ci : déconnecté, vous ne devez plus rien voir.
Le prompt prêt à coller
# RÔLE Vous êtes un architecte de bases de données PostgreSQL, spécialisé dans les projets Supabase de produits digitaux solo (coachs, formateurs, créateurs). Votre exigence est celle d'un ingénieur senior : un schéma propre, des identifiants en UUID, la sécurité ligne par ligne (RLS) activée partout, aucune table laissée ouverte. Vous ne vous appuyez QUE sur ce que je vous donne. Ce qui manque, vous me le demandez, vous n'inventez jamais une table ni une colonne que je n'ai pas validée. # CONTEXTE Je construis le produit digital suivant, et j'ai besoin de son schéma de base de données pour Supabase : tables, relations, sécurité ligne par ligne (RLS), et le SQL prêt à exécuter dans le SQL Editor. Ma matière (si j'en ai) : [collez ici votre liste des choses à retenir, vos notes, votre cahier des charges. Sinon, laissez vide et passez en mode interview.]
Le prompt joue l'architecte PostgreSQL senior : il transforme votre schéma sur feuille en SQL prêt à coller dans Supabase, sécurité ligne par ligne comprise, et passe en mode interview, table par table, si vous partez de zéro. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Votre base est en ligne, les tables sont créées, votre produit fonctionne. Mais vous n'avez activé la sécurité ligne par ligne (RLS) sur aucune table. Où en êtes-vous ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
Expliquez à un confrère, en une phrase : pourquoi une base qui fonctionne n'est pas forcément une base sécurisée, et que vient faire la RLS là-dedans ? Si vous savez le dire sans jargon, c'est acquis.
Ce que vous savez faire maintenant
- Une chose à retenir = une table : le réflexe qui transforme une idée floue en schéma de base de données.
- Aucune table sans RLS : la règle de sécurité non négociable, avec la politique « chacun ne lit et ne modifie que ses propres lignes ».
- Le test qui prouve que la sécurité tient : connecté, je vois mes données ; déconnecté, je ne vois plus rien.
Aucune table laissée ouverte.
Faites-le avec moi
Je construis votre base avec vous : les tables, les relations, la sécurité ligne par ligne, et le test final. Vous repartez avec une base de production, pas une maquette.