Créer un SaaS de Gestion de Magasin Multi-Tenant de A à Z avec Cursor + Supabase (Comparaison avec Lovable)
Vous avez découvert la création d’un SaaS avec Lovable… mais qu’est-ce qui change lorsque vous utilisez un environnement de développement plus avancé comme Cursor ?
Dans cette séance, vous allez apprendre à créer un SaaS de gestion de magasin multi-tenant de A à Z avec Cursor et Supabase, tout en comparant cette approche avec celle basée sur Lovable.
Vous allez découvrir comment :
- Préparer votre environnement de développement (installation de Cursor, Node.js, Git et des autres dépendances nécessaires)
- Construire une application SaaS complète avec Cursor et l’intelligence artificielle
- Concevoir une architecture multi-tenant professionnelle
- Créer et connecter une base de données avec Supabase
- Développer les fonctionnalités essentielles d’un système de gestion de magasin
- Gérer les utilisateurs, les rôles et les accès
- Comprendre quelle approche choisir selon votre niveau et votre projet
Cette formation vous permettra de mieux comprendre les différentes façons de créer des applications modernes avec l’IA, que vous soyez débutant, développeur ou entrepreneur.
Objectif : maîtriser la création d’un SaaS complet avec Cursor + Supabase et choisir la meilleure approche entre développement assisté par IA et génération d’applications.
Prompt :
Je souhaite créer une solution numérique SaaS professionnelle :
Un système de gestion de magasin (POS – Point of Sale).
L’objectif est de développer une plateforme complète permettant aux propriétaires de commerces de gérer leurs activités quotidiennes depuis une seule interface, avec la possibilité de gérer un ou plusieurs magasins (multi-tenant / multi-stores).
Le modèle économique repose sur un abonnement (mensuel ou annuel) : chaque client doit souscrire à un plan pour accéder aux fonctionnalités de la plateforme. La solution est multi-tenant (un client peut gérer une ou plusieurs entités/espaces de travail selon le besoin métier).
En tant que **Super Administrateur**, je dois pouvoir :
- créer et gérer les comptes clients,
- créer leurs espaces de travail respectifs,
- gérer les abonnements et les accès,
- superviser l’ensemble de la plateforme,
- contrôler les rôles et permissions.
### Stack technique
Avant de commencer, analyser les besoins du projet (type d’application, complexité, contraintes de performance, échéance, présence ou non d’une équipe technique, besoins de SEO, temps réel, mobile, etc.) et choisir le stack le plus adapté.
- Justifier brièvement le choix effectué (2-3 phrases) avant de commencer l’implémentation, pour que l’utilisateur puisse valider ou ajuster.
- En cas de doute ou d’ambiguïté sur les besoins, poser les questions nécessaires à l’utilisateur plutôt que de choisir par défaut.
**Critères de choix du frontend**
- Application web classique / SEO important → Next.js (ou autre framework SSR/SSG adapté)
- Application web sans besoin de SEO, SPA rapide à développer → React (Vite), Vue, Svelte, etc.
- Application mobile → React Native, Flutter, ou équivalent
- Prototype rapide / MVP simple → privilégier la simplicité (ex. Vite + React) sauf si le projet a des besoins clairement identifiés justifiant plus lourd
**Critères de choix du backend**
- Si le projet nécessite une base relationnelle, de l’authentification, du stockage de fichiers et une API générée rapidement sans infrastructure lourde à gérer → privilégier une solution BaaS comme Supabase
- Si le projet nécessite une logique métier complexe côté serveur, des workflows spécifiques, ou une architecture microservices → envisager un backend custom (Node.js/Express, NestJS, etc.)
- **Base de données** : Supabase
- PostgreSQL
- Authentification sécurisée (Supabase Auth)
- Gestion des utilisateurs et des rôles
- Stockage de fichiers (Supabase Storage)
- API backend générée automatiquement
- Row Level Security (RLS) sur toutes les tables
**Une fois le stack choisi**
- Le documenter clairement (dans le README ou un fichier de configuration du projet) pour que les prochaines actions de l’IA restent cohérentes avec ce choix tout au long du projet.
- Ne plus changer de stack en cours de route sans validation explicite de l’utilisateur.
---
Phase 1 – Préparation de l’environnement de développement
Avant de commencer le développement, identifiez toutes les dépendances, bibliothèques, frameworks, SDK et outils nécessaires pour exécuter ce projet en local.
Pour chaque élément :
- Vérifiez s’il est déjà installé sur la machine.
- S’il ne l’est pas, installez-le automatiquement lorsque c’est possible.
- Si une installation nécessite une intervention de ma part (droits administrateur, téléchargement manuel, etc.), ne la sautez pas. Arrêtez-vous et guidez-moi pas à pas jusqu’à ce que l’installation soit terminée, puis poursuivez le processus.
Assurez-vous que l’environnement de développement est entièrement fonctionnel avant de passer à la phase suivante.
Tout au long du développement, vérifiez régulièrement que le projet peut être compilé et exécuté sans erreur.
À la fin de cette phase, et également à la fin du développement du projet, lancez automatiquement l’application dans un navigateur afin de vérifier que tout fonctionne correctement et d’effectuer les tests nécessaires.
---
## Phase 2 — Analyse et conception (obligatoire avant tout code)
Avant de générer la moindre ligne de code, analyse ce projet comme le ferait un architecte logiciel SaaS expérimenté. Fournis :
1. **Architecture générale du système** (schéma logique frontend / backend / base de données / auth).
2. **Liste complète des modules nécessaires**, et pour chacun :
- son objectif,
- ses fonctionnalités principales,
- ses sous-pages,
- les actions possibles pour l’utilisateur,
- les données à stocker.
3. **Structure des menus et onglets** de l’application.
4. **Parcours utilisateur** pour chaque type de compte (Super Admin, Admin client, utilisateur final, etc. — à adapter selon le projet).
5. **Première proposition de structure de base de données Supabase** :
- tables principales et leurs colonnes clés,
- relations entre les tables,
- gestion des rôles,
- politiques RLS envisagées.
6. **Vision globale** : rôle de l’application, utilisateurs cibles, modèle SaaS, choix d’architecture technique.
7. Design UI/UX
Définir :
Une interface moderne, professionnelle, élégant, épuré et intuitive, type Linear/Stripe/Shopify
Un design adapté aux logiciels SaaS actuels.
Un tableau de bord clair.
Une navigation optimisée desktop et tablette.
Une expérience utilisateur simple pour les commerçants non techniques.
8. Page d’accueil et parcours utilisateur
Créer une page d’accueil moderne, professionnelle et adaptée à la plateforme si nécessaire.
Le parcours utilisateur doit être conçu de manière modulaire et n’inclure que les étapes pertinentes selon le type d’application. Il peut notamment comprendre :
- La création d’un compte utilisateur, si une authentification est nécessaire.
- La création ou la configuration de l’entité principale de la plateforme (par exemple : entreprise, magasin, organisation, équipe, projet, établissement, etc.), si applicable.
- La sélection d’un plan d’abonnement, si la plateforme propose des offres payantes.
- Le paiement de l’abonnement ou des services, si un paiement est requis pour accéder à certaines fonctionnalités.
- Toute autre étape d’intégration (onboarding) nécessaire pour permettre à l’utilisateur de commencer à utiliser la plateforme dans les meilleures conditions.
Le système doit détecter automatiquement les fonctionnalités réellement nécessaires au projet et ne pas ajouter d’étapes inutiles.
**Attends ma validation sur cette conception avant de passer à la Phase 2.**
---
## Phase 3 — Plan de développement progressif
Développement **obligatoirement séquentiel** : ne génère jamais toute l’application en un seul bloc.
- Présente-moi d’abord la **liste complète des étapes prévues** (ex. Étape 1 : socle Supabase + auth, Étape 2 : module X, Étape 3 : module Y, Étape 4 : audit log, etc.) afin que j’aie une vue d’ensemble avant de commencer.
- Chaque étape doit rester concentrée sur une seule partie du projet.
- N’attends pas ma validation entre les décisions techniques mineures (nommage de tables, structure de dossiers, libellés) tant que les règles de sécurité ci-dessous sont respectées.
- Exécute automatiquement toutes les migrations SQL dès qu’elles sont créées, sans attendre que je les lance manuellement dans le SQL Editor.
Exception : si une migration touche des données sensibles (ex. suppression de colonnes/tables, modification de données existantes, changement de permissions, données personnelles), arrête-toi et demande-moi une confirmation explicite avant de l’exécuter.
- Le CRUD (ajout / modification / suppression) doit être dynamique et intuitif partout où c’est pertinent.
À chaque étape :
- explique ce que tu vas construire **avant** de modifier le projet,
- attends ma validation avant de passer à l’étape suivante,
- n’ajoute aucune fonctionnalité non demandée,
- maintiens une architecture propre et évolutive,
- écris un code structuré et maintenable.
---
Phase 4 – Guide d’utilisation et documentation
Une fois le développement du projet entièrement terminé et validé, fournissez une documentation complète expliquant le fonctionnement du système.
Cette documentation doit inclure au minimum :
- Une présentation générale du projet et de son objectif.
- L’architecture globale de l’application (frontend, backend, base de données, API, services externes, etc.).
- Le parcours complet de chaque type d’utilisateur (Administrateur, Gestionnaire, Employé, Client ou tout autre rôle présent dans le système), depuis la connexion jusqu’aux principales actions qu’il peut effectuer.
- Une explication détaillée de chaque fonctionnalité, avec son rôle et son mode d’utilisation.
- Les paramètres de configuration disponibles et leur impact.
- Les droits et permissions associés à chaque rôle utilisateur.
- Les API disponibles (si le projet en possède), avec leurs principaux endpoints et leur utilisation.
- Les bibliothèques, frameworks et technologies utilisés dans le projet.
- Les commandes nécessaires pour démarrer, arrêter, mettre à jour et maintenir le projet en local ou en production.
- Les procédures de sauvegarde, de restauration et de mise à jour du système.
Enfin, fournissez un guide de prise en main rapide permettant à un nouvel utilisateur de comprendre et d’utiliser efficacement le système sans assistance.
---
Phase 5 – Versionnement et déploiement sur GitHub
À la fin du développement du projet :
1. Initialise Git si ce n’est pas déjà fait.
2. Crée un fichier .gitignore adapté au projet.
3. Fais le premier commit avec un message clair.
4. Si le dépôt GitHub n’existe pas, crée-le automatiquement en utilisant GitHub CLI (gh) ou l’API GitHub.
5. Ajoute le dépôt distant (origin).
6. Pousse la branche principale (main) sur GitHub.
7. À chaque modification importante, fais un commit et un push automatiquement.
8. Si une étape échoue, explique pourquoi et indique exactement ce que je dois faire.
---
## Règles de sécurité STRICTES (obligatoires, non négociables)
### Secrets et variables d’environnement
1. Vérifier l’existant
- Vérifier si un fichier `.env` et/ou `.env.local` existe déjà à la racine du projet.
- S’il en existe un (ou les deux), l’utiliser tel quel : ne jamais l’écraser, le régénérer, le recréer ou en modifier le contenu sans confirmation explicite de l’utilisateur.
- Si les deux fichiers existent, `.env.local` est prioritaire sur `.env` (comportement standard des frameworks basés sur dotenv, dont Vite et Next.js).
- Si le fichier existant contient déjà des clés utiles (ex. `SUPABASE_URL`, `SUPABASE_ANON_KEY`), les réutiliser plutôt que d’en redemander de nouvelles à l’utilisateur.
2. Détecter le framework
- Identifier le framework utilisé dans le projet avant de créer le fichier .env
- En fonction du framework détecté, déterminer l’emplacement et le préfixe de variable corrects :
| Framework | Fichier | Variables |
|---|---|---|
| Next.js | `.env.local` | `NEXT_PUBLIC_SUPABASE_URL`, `NEXT_PUBLIC_SUPABASE_ANON_KEY` |
| Vite | `.env.local` (ou `.env`) | `VITE_SUPABASE_URL`, `VITE_SUPABASE_ANON_KEY` |
| Create React App | `.env` | `REACT_APP_SUPABASE_URL`, `REACT_APP_SUPABASE_ANON_KEY` |
3. Créer le fichier d’environnement si nécessaire
- Si aucun `.env` ni `.env.local` n’existe, en créer un au bon endroit, avec le bon préfixe, en demandant à l’utilisateur de renseigner les valeurs manquantes.
4. Configurer le client Supabase
- Installer le package `@supabase/supabase-js`.
- Créer un fichier `lib/supabase.js` (ou `.ts` si le projet est en TypeScript) qui initialise le client Supabase en lisant les variables d’environnement adaptées au framework détecté (`import.meta.env` pour Vite, `process.env` pour Next.js/CRA).
5. Règles de sécurité (toujours applicables)
- Ne jamais exposer la clé `service_role` dans le frontend.
- Ne jamais committer `.env` ou `.env.local` dans Git : vérifier que `.gitignore` les exclut bien, y compris quand ces fichiers contiennent déjà `SUPABASE_SERVICE_ROLE_KEY`.
- Les secrets serveur (`SUPABASE_SERVICE_ROLE_KEY`, etc.) ne doivent se trouver que dans :
- les Supabase Edge Functions,
- ou un backend serveur séparé (s’il existe).
### Row Level Security (RLS)
- RLS activé automatiquement sur toute nouvelle table du schéma public via un event trigger (`ensure_rls`). Ne jamais désactiver cette sécurité ni exécuter `ALTER TABLE ... DISABLE ROW LEVEL SECURITY`, sauf demande explicite de ma part pour une table de référence publique.
- Chaque `CREATE TABLE` doit être immédiatement suivi d’au moins une `CREATE POLICY` dans la même migration. Une table sans policy est inaccessible via l’API (résultats vides, sans erreur).
- Policies par défaut selon le type de données :
- **Données liées à un utilisateur** (`user_id`) → policy basée sur `auth.uid() = user_id`, définie séparément pour SELECT, INSERT, UPDATE, DELETE.
- **Données de référence publiques en lecture seule** → `CREATE POLICY ... FOR SELECT TO anon, authenticated USING (true)`, sans policy d’écriture.
- **Données multi-tenant** (équipe/organisation/client) → policy basée sur l’appartenance à l’entité, sans jointure lourde dans la policy (utiliser une fonction `SECURITY DEFINER` si besoin de performance).
- Toujours indexer les colonnes utilisées dans les policies (`user_id`, `team_id`, etc.) pour éviter les scans séquentiels.
- Ne jamais utiliser la clé `service_role` côté client/frontend : elle contourne RLS entièrement et ne doit servir que côté serveur.
- Pour `UPDATE`, toujours définir à la fois `USING` et `WITH CHECK`.
### Authentification
- La connexion passe exclusivement par Supabase Auth (`supabase.auth.signInWithPassword()` côté client) ; aucune vérification de mot de passe en JS pur.
- Ne jamais stocker de mot de passe en clair.
- La validation du JWT et les permissions doivent être appliquées par RLS côté Supabase.
- Pour toute opération sensible (création d’admin, envoi d’email, logique métier critique), utiliser une Supabase Edge Function avec la clé `service_role` côté serveur uniquement.
### Protection des routes frontend
- Créer un composant `ProtectedRoute` qui :
- vérifie la session Supabase,
- vérifie le rôle requis,
- redirige vers `/login` en cas d’échec.
- Ne jamais se fier uniquement au masquage UI : la sécurité réelle = RLS + Auth Supabase.
### Upload de fichiers
- Valider le type et la taille avant tout upload.
- Aucune exécution de fichier uploadé.
### Autres
- Protection XSS : échapper/sanitizer tout contenu riche.
- Rate limiting sur le login (via Supabase ou Edge Function).
- Logs d’audit optionnels : table `content_audit_log` (qui a modifié quoi, quand).
- HTTPS obligatoire en production.
- Appliquer les headers de sécurité recommandés au déploiement.
---
## Décisions prises à l’avance (ne pas me redemander)
### Premier compte administrateur
- Adresse email : ...
- Crée ce compte directement via une migration SQL, avec un mot de passe temporaire aléatoire.
- Je définirai mon propre mot de passe ensuite via « Mot de passe oublié » depuis `/login`.
### Confirmation d’email (Auth)
- Désactive l’option « Confirm email » dans Supabase (Authentication → Providers → Email) pour permettre une connexion admin instantanée en développement.
- Rappelle-moi explicitement, à la toute fin de la dernière étape (avant mise en production), de réactiver cette option.
---
## Format attendu de tes réponses
- Après chaque étape terminée : un résumé court — ce qui a été fait, ce qu’il me reste à faire manuellement (ex. côté dashboard Supabase), et la commande/action pour vérifier que ça fonctionne.
- Si un choix impacte directement la sécurité des données (policy RLS ambiguë, exposition d’une clé, etc.) : arrête-toi et demande-moi avant de continuer — c’est la seule exception au principe « ne pas me redemander ».
---
## Objectif final
Obtenir une plateforme SaaS professionnelle, scalable, avec une architecture propre et évolutive, prête à accueillir plusieurs milliers d’utilisateurs.
Fin du Prompt
Dites-nous en commentaire : préférez-vous créer vos applications avec Lovable ou avec Cursor ?