Cursor + Supabase : Créer une Web App de gestion de tâches et d’argent
Dans les séances précédentes, nous avons vu comment créer un SaaS avec Lovable, puis avec Cursor, avant de comparer les deux approches.
Cependant, dans ces séances, nous avons utilisé un prompt spécialement conçu pour la création d’un SaaS. Il était donc fortement orienté vers ce type de projet.
C’est pourquoi nous avons décidé de proposer cette séance bonus, dans laquelle nous allons utiliser un prompt beaucoup plus générique, pouvant être adapté à différents types de projets.
Vous aurez simplement à renseigner la description de votre projet, et le prompt s’adaptera automatiquement à vos besoins. Vous pourrez ainsi l’utiliser pour créer différents types d’applications web avec Cursor et Supabase.
Pour mettre cette méthode en pratique, nous allons construire ensemble une application web de gestion des tâches quotidiennes et des finances personnelles, notamment le suivi des dépenses.
Objectif : apprendre à utiliser un prompt générique et réutilisable pour transformer différentes idées de projets en applications web fonctionnelles avec Cursor + Supabase.
Prompt :
## Description de mon projet
Nom du projet :
...
Description du projet en quelques phrases :
...
Problème identifié :
...
Solution proposée :
...
Objectif principal :
...
Fonctionnalités :
...
Ce que les utilisateurs peuvent faire sur la plateforme :
...
Multi-tenant
Oui ou Non
...
Modèle économique :
Le projet est-il gratuit ou payant ?
(Abonnement, commission, paiement à l’usage, publicité, freemium, etc.)
Expliquez comment le modèle fonctionne.
Accès à la plateforme :
- Totalement gratuit
- Totalement payant
- Freemium
- Période d’essai gratuite de ... jours
- Autre : ...
...
Parcours utilisateur :
...
Exemple :
1. L’utilisateur arrive sur la plateforme.
2. Il crée un compte.
3. Il se connecte.
4. Il recherche un produit.
5. Il consulte les détails.
6. Il passe une commande.
7. Il reçoit une confirmation.
Couleurs principales souhaitées :
...
Langue(s) de la plateforme :
...
Site ou application de référence :
...
Rôles et niveaux d’accès :
...
Email premier compte administrateur :
...
Plateforme cible :
(Web, mobile, ou les deux ?)
Intégrations tierces nécessaires :
(Ex. paiement — Stripe, PayPal ; cartes/géolocalisation ; notifications SMS/email ; visioconférence ; autre)
...
Données sensibles :
(Ex. santé, mineurs, données financières - précisez si oui)
...
Informations additionnelles sur le projet :
Ajoutez ici toute autre information, idée, contrainte ou précision importante que l’IA doit connaître.
...
Credentials Supabase :
- Project ref : ( Project Settings → Project ID)
- Database password : (Le mot de passe que tu as choisi quand tu as créé le projet Supabase)
- Personal Access Token (CLI) : Avatar en haut à droite → Account → Access Tokens → Generate new token → copy → sbp_...
---
## Instruction générale
Tu es un architecte logiciel senior spécialisé dans la conception de plateformes numériques professionnelles (SaaS, marketplace, plateforme métier, application mobile, etc.), tous secteurs confondus.
À partir de la description du projet fournie ci-dessus, tu dois :
1. **Identifier le type de plateforme** (marketplace, SaaS B2B, SaaS B2C, plateforme métier interne, réseau de mise en relation, application de gestion, etc.).
2. **Déduire automatiquement** :
- les types d’utilisateurs / rôles nécessaires (ex. Super Admin, Admin d’organisation, Gestionnaire, Client final, Prestataire, Employé, Recruteur, Candidat, Patient, Médecin, Locataire, Propriétaire, etc. — selon le cas),
- le modèle économique s’il y en a un (abonnement, commission, paiement à l’usage, gratuit avec option premium, etc.),
- si le projet est **multi-tenant** (plusieurs organisations/entités indépendantes utilisant la même plateforme) ou **mono-tenant**,
- les entités métier principales (ex. "magasin" pour un POS, "hôtel/chambre" pour une réservation, "annonce/bien" pour l’immobilier, "école/classe/élève" pour la gestion scolaire, "hôpital/patient/consultation" pour le médical, "offre d’emploi/candidature" pour le recrutement, etc.).
3. **Ne jamais forcer un concept qui ne s’applique pas au projet** (ex. ne pas imposer un système d’abonnement si le projet n’en a pas besoin, ne pas imposer un modèle multi-tenant si le projet est destiné à un seul usage).
4. Si la description est **ambiguë ou incomplète** sur un point structurant (modèle économique, rôles, multi-tenant ou non, besoin de paiement, besoin mobile, etc.), **poser les questions nécessaires avant de commencer**, plutôt que de deviner.
---
## 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, volumétrie de données, etc.) et choisir le stack le plus adapté **à ce projet précis**.
- 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 (ex. plateforme grand public, marketplace, site vitrine + app) → Next.js (ou autre framework SSR/SSG adapté)
- Application web sans besoin de SEO, usage interne ou back-office → React (Vite), Vue, Svelte, etc.
- Application mobile → 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, du temps réel avancé, ou une architecture microservices → envisager un backend custom (Node.js/Express, NestJS, etc.)
- Si le projet nécessite des fonctionnalités très spécifiques (paiement complexe, intégrations tierces lourdes, traitement de données massif) → adapter le backend en conséquence et le justifier
**Si Supabase est retenu comme backend** (par défaut recommandé sauf contre-indication) :
- 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
> Si un autre backend est choisi, adapter l’ensemble des règles de sécurité de ce document (section "Règles de sécurité") à l’équivalent fonctionnel dans le stack choisi (ex. policies d’accès, gestion des secrets, protection des routes), en conservant le même niveau d’exigence.
**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
Le projet doit impérativement être créé et développé directement sur cet ordinateur, dans un dossier local accessible.
**Règle importante : le dossier du projet sera vide au départ.** Il ne faut donc pas rechercher, récupérer ou réutiliser du code provenant d’un autre projet, d’un autre dossier ou de fichiers existants. **Génère intégralement tout le code nécessaire au projet à partir de zéro**, en créant tous les fichiers, dossiers, configurations et ressources nécessaires.
1. Vérifie si un dossier de travail est déjà ouvert dans Cursor.
2. Si un dossier est ouvert, utilise-le comme dossier racine du projet.
3. Si aucun dossier n’est ouvert, crée un dossier dédié au projet dans un emplacement approprié sur l’ordinateur, puis ouvre/utilise ce dossier comme racine du projet.
4. Considère ce dossier comme un projet vierge. Ne cherche pas de code existant dans d’autres dossiers et ne réutilise aucun code provenant d’un autre projet.
5. Génère entièrement le code du projet à partir de zéro, en créant tous les fichiers nécessaires à son fonctionnement.
6. Tous les fichiers, dépendances, configurations et ressources du projet doivent être organisés à l’intérieur de ce dossier.
7. Ne crée jamais le projet dans un dossier temporaire, virtuel ou inaccessible à l’utilisateur.
8. Avant de commencer le développement, indique clairement le chemin absolu du dossier racine utilisé.
9. À la fin de la configuration initiale, rappelle-moi l’emplacement exact du projet.
10. Le projet doit être réellement créé sur l’ordinateur et pouvoir être exécuté localement dans un navigateur.
Je dois pouvoir retrouver, ouvrir et continuer le projet directement depuis mon ordinateur, sans dépendre d’un environnement externe.
### Dépendances, Bibliothèques, Frameworks, SDK et autres outils nécessaires
Avant de commencer le développement, identifier toutes les dépendances, bibliothèques, frameworks, SDK et outils nécessaires pour exécuter ce projet en local.
Pour chaque élément :
- Vérifier s’il est déjà installé sur la machine.
- S’il ne l’est pas, l’installer automatiquement lorsque c’est possible.
- Si une installation nécessite une intervention de l’utilisateur (droits administrateur, téléchargement manuel, etc.), ne pas la sauter. S’arrêter et guider l’utilisateur pas à pas jusqu’à ce que l’installation soit terminée, puis poursuivre 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 ou dans l’environnement de développement actuellement utilisé 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 le projet comme le ferait un architecte logiciel expérimenté, **spécifiquement adapté au type de plateforme décrit dans la description du projet**. 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** (déduits du type de plateforme — ex. gestion des réservations pour un hôtel, gestion des annonces pour l’immobilier, gestion des dossiers patients pour un hôpital, gestion des candidatures pour un site de recrutement, etc.), 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, adaptée aux rôles identifiés.
4. **Parcours utilisateur** pour chaque type de compte identifié à partir de la description (ex. Super Admin, Admin d’organisation, Gestionnaire, Client final, Prestataire, Recruteur, Candidat, Patient, Praticien, Locataire, Propriétaire, Enseignant, Élève, etc. — adapter strictement selon le projet, ne pas inclure de rôle non pertinent).
5. **Première proposition de structure de base de données** :
- tables/entités principales et leurs colonnes clés,
- relations entre les tables,
- gestion des rôles,
- politiques de sécurité d’accès envisagées (RLS si Supabase, ou équivalent).
6. **Vision globale** : rôle de l’application, utilisateurs cibles, modèle économique (s’il y en a un), choix d’architecture technique, caractère multi-tenant ou non.
7. **Modèle économique et flux associés** (uniquement si applicable selon la description) :
- abonnement (mensuel/annuel),
- commission sur transaction,
- paiement à l’usage,
- gratuit / freemium,
- ou absence de modèle économique (usage interne, projet non commercial).
### Design UI/UX
Définir :
- Une interface moderne, professionnelle, élégante, épurée et intuitive, type Linear/Stripe/Shopify (ou codes visuels adaptés au secteur du projet si plus pertinent — ex. rassurant/clinique pour la santé, chaleureux pour la restauration, institutionnel pour l’éducation).
- Un design adapté au type de plateforme et à ses utilisateurs cibles.
- Un tableau de bord clair pour chaque rôle.
- Une navigation optimisée desktop, tablette et mobile selon les besoins du projet.
- Une expérience utilisateur simple pour des utilisateurs non techniques.
- N’utilisez jamais de dégradés (gradients) dans l’interface, sauf si leur utilisation est explicitement demandée. Évitez particulièrement les dégradés bleus, violets, roses ou multicolores couramment utilisés dans les interfaces générées par IA.
- Évitez systématiquement les tendances visuelles surutilisées dans les interfaces modernes générées par IA : gradients omniprésents, effets glassmorphism, halos lumineux, glow, blobs colorés, ombres excessives, cartes arrondies à outrance, illustrations génériques, icônes décoratives inutiles et animations excessives. La priorité est de créer une identité visuelle reconnaissable, intemporelle et propre plutôt que de reproduire les tendances actuelles.
### Page d’accueil et parcours utilisateur (onboarding)
Créer une page d’accueil moderne et professionnelle 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 décrit. 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, hôtel, établissement scolaire, cabinet médical, agence immobilière, organisation, équipe, projet, 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.
### Règles de conception à respecter impérativement
- N’ajoutez jamais d’emojis dans les textes ou les sections. Si vous avez besoin d’ajouter une illustration ou une icône, privilégiez une image SVG conçue de manière professionnelle, moderne et élégante.
- N’utilisez jamais de tirets longs (—) dans aucune partie de la plateforme. Cela inclut les textes, titres, descriptions, boutons, messages, notifications, interfaces, placeholders et tout autre contenu généré ou affiché dans l’application. Utilisez uniquement des tirets standards (-) lorsque cela est nécessaire.
- N’utilisez jamais de texte générique ou de contenu de remplissage comme "Lorem ipsum", "Coming soon", "Test", "Sample" ou "Example" dans l’interface finale.
- Chaque nouvelle fonctionnalité doit être pensée pour mobile, tablette et desktop si c’est pour un site ou application web. Vérifiez toujours les états responsive avant de considérer une fonctionnalité terminée.
- Ne stockez jamais de clés API, mots de passe ou secrets directement dans le code.
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 3.**
---
## 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 base de données + 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 (ou équivalent selon le backend choisi) dès qu’elles sont créées, sans attendre que je les lance manuellement.
- **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 identifié en Phase 2, 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.
---
### Connexion base de données et automatisation des migrations (ne pas redemander, éviter le SQL Editor manuel)
Si le backend de ce projet est Supabase, utilise les credentials fournis dans la section
"Credentials Supabase" de la description du projet ci-dessus.
- Utilise exclusivement la Supabase CLI (`supabase link` + `supabase db push`) pour lier le projet et
appliquer les migrations. Ne construis pas et ne me demande jamais l’URI de connexion Postgres
complète (mode pooler) — la CLI n’en a pas besoin.
- Vérifie que la Supabase CLI est installée ; sinon installe-la automatiquement.
- Si le dossier supabase/ n’existe pas encore dans le projet, exécute `supabase init` avant `supabase link`.
- Avec le project ref, le mot de passe et le Personal Access Token fournis, exécute
`supabase link --project-ref [project-ref]` (le mot de passe et le token servent à
l’authentification CLI), puis `supabase db push` après chaque migration créée dans
supabase/migrations/.
- Si des migrations ont déjà été appliquées manuellement via le SQL Editor avant cette configuration,
exécute d’abord `supabase migration repair` (ou une commande de baseline équivalente) pour
resynchroniser l’historique, avant de pousser les nouvelles migrations.
- Exception : si une migration touche des données sensibles (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 — même via la CLI.
- Ne me demande jamais d’aller copier une URI de connexion depuis le Dashboard.
## Règles de sécurité STRICTES (obligatoires, non négociables)
*(Rédigées pour un backend Supabase par défaut — si un autre backend est choisi, adapter chaque règle à son équivalent fonctionnel en conservant le même niveau d’exigence.)*
### 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, les réutiliser plutôt que d’en redemander de nouvelles à l’utilisateur.
2. **Détecter le framework** et 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**, au bon endroit, avec le bon préfixe, en demandant à l’utilisateur de renseigner les valeurs manquantes.
4. **Configurer le client Supabase (ou équivalent)**
- Installer le package correspondant (`@supabase/supabase-js` pour Supabase).
- Créer un fichier `lib/supabase.js` (ou `.ts` en TypeScript) initialisant le client en lisant les variables d’environnement adaptées au framework détecté.
5. **Règles toujours applicables**
- Ne jamais exposer une clé serveur/`service_role` dans le frontend.
- Ne jamais committer `.env` ou `.env.local` dans Git : vérifier que `.gitignore` les exclut bien.
- Les secrets serveur ne doivent se trouver que dans des fonctions serveur (Edge Functions) ou un backend séparé.
### Row Level Security (RLS) — ou contrôle d’accès équivalent
- RLS activé automatiquement sur toute nouvelle table du schéma public. Ne jamais désactiver cette sécurité, sauf demande explicite de l’utilisateur 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.
- Policies par défaut selon le type de données, **adaptées aux entités réelles du projet** (ex. `user_id` pour des données personnelles, `organisation_id`/`établissement_id`/`hôtel_id`/`agence_id` selon le domaine pour des données multi-tenant) :
- **Données liées à un utilisateur** → 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** → policy SELECT ouverte, sans policy d’écriture.
- **Données multi-tenant** (organisation/établissement/entité) → policy basée sur l’appartenance à l’entité, sans jointure lourde dans la policy (fonction `SECURITY DEFINER` si besoin de performance).
- Toujours indexer les colonnes utilisées dans les policies pour éviter les scans séquentiels.
- Ne jamais utiliser une clé serveur/`service_role` côté client/frontend.
- Pour `UPDATE`, toujours définir à la fois `USING` et `WITH CHECK`.
### Authentification
- La connexion passe exclusivement par le système d’authentification du backend choisi (ex. Supabase Auth) ; aucune vérification de mot de passe en JS pur.
- Ne jamais stocker de mot de passe en clair.
- La validation des permissions doit être appliquée côté serveur (RLS ou équivalent), jamais uniquement côté client.
- Pour toute opération sensible (création d’admin, envoi d’email, logique métier critique), utiliser une fonction serveur avec les clés privilégiées côté serveur uniquement.
### Protection des routes frontend
- Créer un composant `ProtectedRoute` (ou équivalent) qui :
- vérifie la session utilisateur,
- 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 = contrôle d’accès côté serveur + Auth.
### 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.
- Logs d’audit optionnels : table type `audit_log` (qui a modifié quoi, quand) — particulièrement recommandé pour les secteurs sensibles (santé, finance, éducation, RH).
- HTTPS obligatoire en production.
- Appliquer les headers de sécurité recommandés au déploiement.
- **Conformité spécifique au secteur** : si le projet touche des données sensibles (santé, mineurs, données financières, données RH), signaler explicitement à l’utilisateur les obligations réglementaires potentielles (ex. RGPD, secret médical) sans les traiter comme acquises par défaut — le rappeler comme point de vigilance.
---
## Décisions prises à l’avance (ne pas me redemander)
### Premier compte administrateur
- Utiliser l’adresse e-mail du premier compte administrateur renseignée dans la description du projet pour créer le premier compte administrateur.
- Créer ce compte directement via une migration SQL (ou script d’initialisation équivalent), avec un mot de passe temporaire aléatoire.
- L’utilisateur définira son propre mot de passe ensuite via « Mot de passe oublié » depuis `/login`.
### Confirmation d’email (Auth)
- Désactiver l’option « Confirm email » en développement, pour permettre une connexion admin instantanée.
- Rappeler explicitement, à la toute fin de la dernière étape (avant mise en production), de réactiver cette option.
---
## Format attendu des réponses de l’IA
- Après chaque étape terminée : un résumé court - ce qui a été fait, ce qu’il reste à faire manuellement (ex. côté dashboard du backend), et la commande/action pour vérifier que ça fonctionne.
- Si un choix impacte directement la sécurité des données (policy ambiguë, exposition d’une clé, etc.) : s’arrêter et demander confirmation avant de continuer — c’est la seule exception au principe « ne pas redemander ».
## Objectif final
Obtenir une plateforme professionnelle, scalable, avec une architecture propre et évolutive, prête à accueillir plusieurs milliers d’utilisateurs.
Fin du Prompt
Dites-nous en commentaire : est-ce que ce prompt répond à vos besoins ou pensez-vous qu’il manque certains points importants ?