Construire le moteur de son produit digital avec Supabase
Vous voulez construire un produit digital : un espace membre, des contenus, peut-être un paiement. Et le réflexe naturel, c'est d'ouvrir l'outil tout de suite et de créer des tables au fil de l'eau. Trois semaines plus tard, votre base ressemble à un grenier : des colonnes en double, des liens flous entre les données, et aucune idée claire de qui a le droit de lire quoi. Le problème n'était pas l'outil, c'était l'absence de plan.
Cette masterclass vous donne la méthode pour modéliser le backend de votre produit avant d'écrire une ligne de code : quatre décisions, dans l'ordre, avant de toucher à l'outil. À la clé : un modèle clair, relationnel et sécurisé, prêt à traduire dans Supabase.
Ce que cet exercice ne peut pas casser
Tout se passe sur le papier. Vous ne créez aucun compte, vous ne touchez à aucune base, vous n'écrivez aucun code. Au pire, vous jetez la feuille et vous recommencez. Se tromper de modèle sur une feuille coûte cinq minutes ; s'en apercevoir dans une base en production coûte des semaines.
Ce que vous saurez faire à la fin
- Lister les tables de votre produit à partir d'une seule question : qu'est-ce qu'il doit retenir entre deux visites ?
- Exprimer chaque relation entre vos données en une phrase claire, avant tout vocabulaire technique.
- Écrire en français qui peut lire et qui peut écrire chaque table, et sortir les médias lourds des tables.
- Niveau membre· le prompt prêt à coller qui déroule les quatre décisions d'un coup et vous rend un modèle de backend prêt à traduire dans Supabase.
- Niveau Pro· je modélise votre backend avec vous, décision par décision, jusqu'à la liste des points à trancher avant de coder.
L'ordre compte : on décide ce qui est retenu avant de le lier, on le lie avant de le protéger.
Quatre décisions, dans l'ordre
Un backend n'est pas d'abord un sujet de code, c'est une suite de décisions. Quatre exactement, et l'ordre n'est pas négociable : on ne peut pas lier des tables qu'on n'a pas encore nommées, ni protéger des données dont on ne sait pas à qui elles appartiennent. Prises dans l'ordre, ces quatre décisions transforment une idée de produit en un plan que n'importe quel outil saura exécuter. Sautées, elles se rappellent à vous plus tard, au pire moment.
1Les tables : ce que le produit doit retenirdoute : « par où commencer ? »
Par une seule question : qu'est-ce que votre produit doit retenir entre deux visites ? Vos membres, vos contenus, les achats, la progression de chacun. Chaque réponse devient une table, avec un nom au pluriel et en minuscules. À la main : listez ces choses sur une feuille, puis donnez à chaque table ses colonnes essentielles, sans sur-ingénierie. Une colonne dont vous ne savez pas à quoi elle servira n'a rien à faire dans le modèle.
2Les relations : chaque lien en une phrasedoute : « comment lier tout ça sans jargon ? »
Une relation, c'est le lien entre deux tables. Avant tout vocabulaire technique, chaque lien doit s'exprimer en une phrase claire : un achat appartient à un membre, une vidéo porte sur un module. À la main : tracez des flèches entre vos tables et écrivez la phrase sur chaque flèche. Si vous n'arrivez pas à formuler la phrase, c'est que le lien n'est pas clair dans votre tête, et l'outil ne le clarifiera pas à votre place.
3Les règles d'accès : qui lit, qui écritdoute : « la sécurité, ce n'est pas pour plus tard ? »
Non, et c'est tout l'intérêt de la modéliser ici. Pour chaque table, écrivez en français qui peut lire et qui peut écrire : un utilisateur ne voit que ses propres données, une action est limitée à une fois. Ces phrases deviendront plus tard des policies, les règles de sécurité que la base applique elle-même, ligne par ligne. La mise en oeuvre est détaillée dans Protéger les données de ses clients à la racine avec Supabase ; ici, vous prenez la décision.
4Les fichiers : les médias lourds vivent à partdoute : « et mes vidéos, mes PDF ? »
Une image, un PDF, une vidéo ne vivent pas dans une table. Ce sont des médias lourds : ils vont dans un stockage de fichiers dédié, et la table ne garde que le lien qui pointe vers eux. À la main : repassez sur votre feuille et entourez tout ce qui est un fichier lourd. Pour chacun, notez la table qui portera son lien. Votre modèle reste léger, vos fichiers restent servis correctement.
À vous de jouer : votre modèle sur une feuille
Prenez une feuille et votre idée de produit. Déroulez les quatre décisions, dans l'ordre, sans ouvrir l'outil.
Le résultat, en 30 secondes
À partir de votre seule matière (votre description de produit, vos notes, votre cahier des charges), le prompt vous rend le modèle complet : le produit résumé en une phrase, les tables et leurs colonnes, chaque relation écrite en clair, les règles d'accès table par table, le sort des fichiers lourds, et la liste des points à trancher avant de coder.
Tables : membres, contenus, achats, progressions. Relation : un achat appartient à un membre et porte sur un contenu. Règle d'accès : un membre ne lit que ses propres achats et sa propre progression ; seul l'administrateur écrit dans contenus. Fichiers : les vidéos vivent dans le stockage, la table contenus garde leur lien. À vérifier avant de coder : que se passe-t-il quand un membre est supprimé ?
Le prompt prêt à coller
# RÔLE Vous êtes un architecte de produits digitaux, spécialiste de la modélisation de bases de données pour des consultants solos. Vous traduisez l'idée d'un produit en un modèle de backend clair, relationnel et sécurisé. Vous ne vous appuyez QUE sur ce que je vous donne. Tout ce qui manque, vous me le demandez et vous ne l'inventez jamais. Si une information est ambiguë, vous me posez la question plutôt que de combler par du générique. # CONTEXTE Je suis un consultant solo (coach, formateur, expert) qui veut construire un produit digital avec espace membre, contenus, et peut-être paiement. Je veux modéliser mon backend avant d'ouvrir Supabase, pour ne pas me jeter dans le code sans plan. Ma matière (si j'en ai) : [collez ici votre description de produit, vos fonctionnalités, vos notes. Sinon, laissez vide et demandez-moi de passer en mode interview.]
Le prompt déroule les quatre décisions d'un coup et vous rend votre modèle de backend complet, prêt à traduire dans Supabase. Pas encore de matière ? Il passe en mode interview et vous questionne décision par décision. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Vous modélisez un espace membre avec des fiches PDF à télécharger. Dans votre modèle, où vivent les PDF ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
En une phrase, à un confrère qui veut ouvrir Supabase ce soir sans plan : pourquoi prendre les quatre décisions sur une feuille avant de toucher à l'outil ? Si vous savez le dire simplement, c'est à vous.
Ce que vous savez faire maintenant
- Décider ce que votre produit retient dans des tables, et ce qui n'y vit pas.
- Exprimer les relations et les règles d'accès en français avant toute ligne de code.
- Arriver dans Supabase avec un plan complet, au lieu de créer des tables au fil de l'eau.
Quatre décisions, dans l'ordre, avant de toucher à l'outil.
Continuez seul
Votre modèle est posé. La traduction concrète, table par table et policy par policy :
Construire la base de données de son produit avec Supabase →Faites-le avec moi
Je modélise votre backend avec vous : les tables, les relations, les règles d'accès, le tri des fichiers, jusqu'à la liste des points à trancher. Vous entrez dans Supabase avec un plan, pas avec une intuition.