10 tables indispensables pour un SaaS :le plan de la base

Les 10 tables indispensables pour un SaaS font tourner 90 % des applications métier : organisations, utilisateurs, membres d'organisation, votre entité principale, catégories, relations, journal d'activité, fichiers, notifications et paramètres. Vous ne réinventez pas la base de données : vous clonez cette structure, vous renommez deux ou trois choses, et vous livrez. Voici le plan complet, la façon dont les tables s'articulent, et le prompt à copier-coller qui pousse l'IA à toutes les construire correctement.

Une table, ce n'est rien de plus effrayant qu'un tableur structuré : chaque ligne est une chose (une tâche, un contact, une facture), chaque colonne une information sur cette chose. Si c'est nouveau pour vous, commencez par les bases de données expliquées aux fondateurs non techniques et revenez ensuite. Le propos de cet article est plus simple : vous n'avez pas besoin de comprendre les bases de données pour en concevoir une. Il suffit de savoir quelles tables créer — et ce sont presque toujours les mêmes d'un SaaS à l'autre.

Les 10 tables indispensables pour un SaaS

Une mauvaise conception de base de données casse votre application dès qu'elle grandit. Une bonne conception, et votre application fonctionne, tout simplement. Voici la fondation :

Remarquez à quel point peu de tout cela est propre à votre idée. 90 % de votre base de données est identique à celle de toute autre application métier ; 10 % est votre logique métier unique. Commencez par les 90 %, construisez les 10 %, livrez votre produit.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Comment les tables s'articulent

Pensez à un immeuble d'habitation. Les organisations sont le registre de l'immeuble — la liste des locataires. Les utilisateurs sont les habitants. Les membres d'organisation sont l'annuaire des appartements, qui dit que Jean habite au 5 et Sarah au 12. À partir de là, l'enchaînement est logique : une organisation possède de nombreuses entités principales (tâches, contacts, factures), chacune peut avoir des fichiers joints, chaque action génère une entrée dans le journal d'activité, et les événements importants créent des notifications.

Un exemple concret — un CRM simple a besoin de : organisations (vos clients), utilisateurs (les personnes qui se connectent), membres d'organisation (Jean travaille dans une entreprise, Sarah dans une autre), contacts (les enregistrements du CRM), tags de contacts (prospect chaud, prospect froid, client), un journal d'activité (chaque interaction), des fichiers (documents rattachés aux contacts), des notifications (alertes quand un contact passe à l'action) et des paramètres (préférences par organisation). C'est tout. Neuf tables. Un CRM complet.

C'est aussi pourquoi concevoir les tables avant de construire les écrans fonctionne si bien — tout l'argument du développement database-first. Les écrans changent chaque semaine. Cette structure ne bouge presque pas.

Les tables dont vous n'avez pas besoin au lancement

Aussi important que les dix que vous construisez : celles que vous laissez de côté. Ajoutez-les plus tard, quand vous en aurez vraiment besoin :

• Facturation et abonnements — à ajouter quand vous êtes prêt à faire payer
• Équipes — à ajouter quand les organisations grossissent
• Intégrations — à ajouter quand vous vous connectez à d'autres outils
• Rapports — à ajouter quand les utilisateurs ont besoin d'analytique
• Webhooks — à ajouter quand vous construisez une API
• Journaux d'audit — à ajouter pour les exigences de conformité et de sécurité

La règle : commencez petit, ajoutez des tables au fur et à mesure des besoins. La base de données n'est qu'une couche d'un ensemble plus vaste — les 18 systèmes dont tout SaaS a besoin cartographie le reste — mais les tables sont le point de départ, car tout le reste repose dessus.

Le prompt à copier-coller qui construit les 10 tables

Vous n'écrivez pas ce SQL vous-même. Vous donnez à l'IA le plan et les exigences de qualité dans un seul prompt :

Crée ces tables de base de données pour un [type de votre application] multi-tenant :

FONDATION : 1. organizations (id, name, slug, settings, tier, is_active, created_at, updated_at) · 2. users (gérés par Supabase Auth) · 3. organization_members (organization_id, user_id, role)

FONCTIONNALITÉ CENTRALE : 4. [votre entité principale] avec organization_id, vos champs spécifiques, des colonnes d'audit

SUPPORT : 5. categories (pour organiser [votre entité principale]) · 6. files (pièces jointes) · 7. activity_log (suivi de toutes les actions) · 8. notifications (alertes utilisateur) · 9. settings (préférences)

Exigences : chaque table doit avoir organization_id (sauf users) · ajoute des index sur toutes les clés étrangères · active la Row-Level Security · utilise des suppressions logiques (colonne deleted_at) · ajoute des colonnes d'audit (created_at, created_by, updated_at, updated_by)

Montre-moi la migration SQL complète.

L'IA générera les tables, correctement reliées, multi-tenant, prêtes pour la production. Le bloc d'exigences n'est pas une décoration facultative — organization_id sur chaque table et la Row-Level Security sont ce qui empêche le client A de voir un jour les données du client B.

Le minimum pour livrer

Avant de commencer à construire des fonctionnalités, vérifiez que vous avez : une table d'organisations, des utilisateurs (Supabase s'en charge), des membres d'organisation, votre entité principale, au moins un moyen d'organiser les éléments, un journal d'activité et des notifications. Avec ces 7 tables minimales, vous pouvez construire et livrer. Ajoutez le reste en grandissant.

La plupart des fondateurs passent des semaines à se tourmenter sur la conception de leur base de données comme si leur application était un flocon de neige unique. Ce n'est pas le cas — et c'est la bonne nouvelle. La fondation est un problème résolu. Clonez-la, personnalisez les 10 %, et consacrez votre énergie à la partie que vous seul pouvez construire.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Ai-je vraiment besoin des 10 tables avant de lancer ?

Non — 7 constituent le minimum : organisations, utilisateurs, membres d'organisation, votre entité principale, un moyen d'organiser les éléments (catégories ou tags), un journal d'activité et des notifications. Les fichiers, les relations et les paramètres peuvent arriver avec les fonctionnalités qui en ont besoin. La facturation, les équipes, les intégrations, les rapports et les webhooks viennent encore plus tard.

Que signifie « multi-tenant » et pourquoi est-ce important ?

Multi-tenant signifie que de nombreux clients partagent une seule application, chacun ne voyant que ses propres données. C'est pourquoi la table des organisations vient en premier et pourquoi chaque table porte un organization_id. Combiné à la Row-Level Security, cela garantit que les enregistrements de chaque client restent dans ses propres murs — comme des appartements dans un même immeuble.

L'IA peut-elle vraiment concevoir ma base de données à ma place ?

Oui — si vous lui donnez le plan. Collez le prompt ci-dessus avec votre entité principale renseignée et l'IA produit la migration SQL complète : tables, clés étrangères, index et Row-Level Security. Ce que l'IA ne peut pas faire, c'est décider quelle est votre entité principale. C'est une décision de produit, pas une décision technique.

Quelle est l'« entité principale » de mon application ?

La seule chose que gère votre application. Gestionnaire de tâches → tâches. CRM → contacts. Facturation → factures. Réservation → rendez-vous. E-commerce → produits. Si vous ne pouvez pas la nommer en un mot, c'est que vous n'avez pas encore défini votre produit assez précisément — réglez cela avant de toucher à la base de données.