Lovable et Supabase : le tutoriel complet

Pour construire une application fiable avec Lovable et Supabase, créez d'abord un projet Lovable modeste, connectez-le à un projet Supabase que vous possédez, puis créez vos tables par migrations avec leurs règles d'accès avant de brancher les écrans. Testez avec plusieurs comptes, et seulement ensuite publiez sur votre domaine.

Avant de commencer

• Un compte Lovable, un compte Supabase et un compte GitHub, avec la double authentification activée.
• Une page de cadrage : qui utilise l'application, avec quels droits, pour faire quoi. Sans elle, l'outil prendra ces décisions à votre place.
• Un budget d'outils d'environ CHF 50 par mois pendant la construction ; vérifiez les tarifs à jour.

Étape 1 : créer le projet Lovable

Commencez par un premier prompt volontairement modeste : une page d'accueil, le nom de l'application, un bouton « Se connecter ». Pas de base de données ni d'authentification à ce stade. Vous voulez un projet propre avant de demander quoi que ce soit d'important.

Collez ensuite dans la zone de connaissances du projet vos règles permanentes : les rôles, les règles métier essentielles, et les règles de sécurité non négociables, par exemple « RLS active sur toutes les tables » et « aucune clé secrète dans le code de l'interface ».

Étape 2 : construire l'interface avec des données fictives

Construisez vos écrans principaux un par un, avec des données fictives codées dans l'interface. Montrez le résultat à un futur utilisateur. Modifier un écran ne coûte presque rien ; modifier une table qui contient des données est délicat. On stabilise donc le parcours avant de créer la base.

Étape 3 : créer et connecter le projet Supabase

Dans Supabase, créez un projet avec un nom explicite et choisissez la région. Pour des données de clients suisses, la région de Zurich garde les données en Suisse. Rangez le mot de passe de la base dans un gestionnaire de mots de passe.

Dans Lovable, ouvrez l'intégration Supabase, autorisez l'accès à votre compte et choisissez ce projet. Si l'outil vous propose d'activer Lovable Cloud, refusez : votre backend est désormais le projet externe.

Étape 4 : créer les tables par migrations

Une migration est un fichier daté qui modifie la structure de la base. En mode Plan, demandez la création de deux ou trois tables à la fois, puis relisez le SQL proposé avec quatre questions :

1. Les noms et les types correspondent-ils à votre modèle de données ?
2. Les contraintes sont-elles là (champs obligatoires, longueurs, listes de valeurs) ?
3. Que se passe-t-il pour les lignes liées si l'on supprime une ligne parente ?
4. La RLS est-elle activée sur chaque nouvelle table ?

Si la réponse à la quatrième question est non, refusez le plan. Ne modifiez jamais la structure à la main dans le tableau de bord : votre historique de migrations ne correspondrait plus à la réalité.

Étape 5 : écrire les règles d'accès

Partez d'un tableau des droits : pour chaque rôle, ce qu'il peut lire, créer, modifier, supprimer. Demandez en mode Plan une règle par opération, avec la clause WITH CHECK sur les créations et modifications. Rangez les rôles dans une table dédiée, jamais dans le profil que l'utilisateur peut modifier.

Étape 6 : l'authentification

Dans Supabase, réglez l'adresse du site, limitez les redirections à vos adresses, gardez la confirmation de l'adresse électronique active et traduisez les modèles de courriels. Puis demandez à Lovable le parcours de connexion adapté : lien magique pour des utilisateurs occasionnels, mot de passe pour des utilisateurs réguliers, et pas d'inscription libre si l'application est sur invitation.

Étape 7 : brancher les écrans et tester

Reliez chaque écran aux vraies données, une tâche par écran. Puis testez avec au moins deux comptes par rôle :

• un utilisateur ne voit pas les données d'un autre, même en recopiant l'adresse d'une page ;
• une modification interdite est refusée et l'interface l'indique ;
• un visiteur non connecté n'accède à aucune donnée.

Lancez enfin le conseiller de sécurité de Supabase et traitez chaque alerte.

Étape 8 : GitHub, publication et domaine

Connectez GitHub pour garder une copie de votre code dans un dépôt privé. Publiez, testez sur l'adresse fournie, puis branchez votre domaine en recopiant exactement les enregistrements DNS indiqués par Lovable. N'oubliez pas de mettre à jour l'adresse du site et les redirections dans Supabase.

Les erreurs les plus fréquentes

Organiser son travail

Gardez un dossier de projet avec quatre sous-dossiers : cadrage (page de cadrage, modèle de données, journal des décisions), prompts (ceux qui ont bien marché), tests (matrice et résultats datés) et production (domaine, réglages, plan de reprise). Notez aussi votre solde de crédits au début et à la fin de chaque séance : vous verrez vite ce qui coûte cher.

Checklist avant la première publication

• La RLS est active sur toutes les tables, avec des règles par opération.
• La matrice de tests est entièrement réussie, y compris les cases de refus.
• Aucune clé secrète n'apparaît dans le code, dans GitHub ni dans le navigateur.
• Le conseiller de sécurité de Supabase et le scan de Lovable ne signalent aucune alerte critique.
• Les comptes de test ont des mots de passe forts ou ont été supprimés.
• La politique de confidentialité est publiée.

Questions fréquentes

Faut-il connaître le SQL ?

Non pour écrire, un peu pour relire. Savoir reconnaître une table, une contrainte et une règle d'accès suffit pour valider un plan.

Combien de temps faut-il compter ?

Pour une première application modeste, 25 à 30 heures réparties sur quatre à six semaines, cadrage et tests compris. Le prototype ne représente qu'une petite partie de ce temps.

Faut-il un projet Supabase par application ?

Oui. Une application, un projet Supabase et un projet Lovable, avec le même nom partout : vous vous y retrouverez, et les données de deux applications ne se mélangent jamais.

Peut-on revenir en arrière en cas d'erreur ?

L'historique de Lovable restaure le code, pas la base de données. Avant une migration importante, exportez la structure et les données critiques.