Sécuriser une app Lovable avant vos premiers clients : le guide

Avant d’accueillir de vrais clients, une app Lovable demande quatre vérifications : une règle d’accès sur chaque table de la base de données, aucune clé secrète dans le navigateur, une sauvegarde que vous avez déjà restaurée une fois, et la conscience que, sur Lovable Cloud, vos essais touchent depuis le 23 octobre 2026 la même base que vos clients. Les contrôles intégrés de Lovable aident, mais sa propre documentation précise qu’ils ne peuvent pas garantir une sécurité complète. La plupart des vérifications de ce guide se font sans savoir coder.

Pourquoi une app Lovable demande une vérification avant le lancement ?

Une app Lovable est une application web qui stocke ses données dans Supabase, une base de données Postgres hébergée, soit dans votre propre projet Supabase, soit dans Lovable Cloud, qui repose sur la même technologie (documentation Lovable). Le navigateur de vos visiteurs parle directement à cette base, avec une clé publique que n’importe qui peut lire dans le code de la page. Ce qui décide de ce que cette clé permet, ce sont les règles d’accès de la base, appelées RLS (Row Level Security, la sécurité au niveau des lignes). Elles disent, ligne par ligne, qui a le droit de lire ou de modifier.

Ce qui protège vos données dans une app Lovable

1. NavigateurLe visiteur lit la clé publique
2. Clé publiqueOuvre l’accès à l’API de la base
3. Règles RLSDécident ligne par ligne
4. Tables SupabaseVos données clients

Supabase le dit ainsi : une fois le RLS activé, aucune donnée n’est accessible par l’API avec une clé publique tant que vous n’avez pas créé de règles (documentation Supabase). La documentation de Lovable pour les projets reliés à Supabase va dans le même sens : des règles RLS manquantes sont la façon la plus courante d’exposer les données d’une app (documentation Lovable).

Le risque n’est pas théorique. En mars 2025, un chercheur a analysé 1 645 projets Lovable et en a trouvé 170 avec des règles d’accès insuffisantes, soit environ 10,3 % (déclaration de Matt Palmer). Cette faille a reçu l’identifiant CVE-2025-48757. Lovable conteste cette qualification : selon la fiche, chaque client de la plateforme est responsable de la protection des données de son application (fiche CVE). Que l’on parle de faille de la plateforme ou d’oubli du créateur, le résultat pour vos clients est le même.

Projets Lovable analysés et projets aux règles d’accès insuffisantes

• Projets analysés1 645 projets
• Règles d’accès insuffisantes170 projets

05001 0001 5002 000projets

Étape 1 : une règle d’accès sur chaque table

Ouvrez votre projet Supabase, section Advisors, puis Security Advisor. Cet outil signale les problèmes de sécurité de la base. Trois alertes comptent en priorité (documentation Supabase) :

• Table publiquement accessible (niveau erreur) : une table du schéma public n’a pas de RLS.
• Règle d’accès sans restriction (niveau avertissement) : une règle existe, mais elle laisse tout passer.
• Règle fondée sur des données modifiables par l’utilisateur (niveau erreur) : la règle se base sur un champ que l’utilisateur peut changer lui-même.

Vous pouvez aussi vérifier à la main dans le SQL Editor. Cette requête doit renvoyer true sur chaque ligne :

select tablename, rowsecurity from pg_tables where schemaname = 'public';

Listez ensuite les règles elles-mêmes :

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies where schemaname = 'public';

Une règle dont la condition vaut simplement true laisse passer tout le monde. Sur une table privée, la condition doit relier la ligne à l’utilisateur, par exemple auth.uid() = user_id. Une table avec RLS activé mais sans aucune règle est fermée à l’app : c’est sûr, mais vérifiez que l’app n’en a pas besoin.

Deux pièges reviennent souvent :

• Les vues. Supabase indique que les vues contournent le RLS par défaut, car elles sont en général créées avec l’utilisateur postgres. Avec Postgres 15 ou plus, l’option security_invoker = true les soumet aux règles des tables. Demandez à un développeur de la vérifier.
• Les rôles rangés dans user_metadata. Ce champ peut être modifié par l’utilisateur connecté lui-même. La documentation recommande raw_app_meta_data (ou une table de rôles protégée par RLS) pour tout ce qui concerne les droits.

Côté Lovable, une analyse rapide (Quick scan) se lance automatiquement à l’ouverture de la fenêtre de publication. Elle contrôle notamment les règles d’accès de la base. L’analyse approfondie (Deep scan), qui relit le code, ne se lance pas toute seule : vous la démarrez depuis la vue Sécurité. Lovable précise que ces outils aident à repérer les problèmes courants, mais ne peuvent pas garantir une sécurité complète, et conseille une revue professionnelle pour les apps qui traitent des données sensibles (documentation Lovable).

Étape 2 : le test des deux comptes

Des règles actives ne suffisent pas si elles laissent tout passer. Ce test se fait sans coder :

1. Créez deux comptes avec deux adresses de test, A et B.
2. Connecté en A, créez une donnée de chaque type important : un profil, une commande, un document.
3. Notez l’adresse de chaque page de détail : elle contient souvent un identifiant.
4. Dans une fenêtre de navigation privée, connectez-vous en B et cherchez les données de A (listes, recherche, exports), puis collez les adresses notées.
5. Refaites l’essai sans être connecté du tout.

Si B voit quoi que ce soit de A, arrêtez tout le reste : c’est la priorité absolue.

Étape 3 : aucune clé secrète dans le navigateur

Tout ce que le navigateur télécharge peut être lu par n’importe quel visiteur. Supabase distingue deux familles de clés (documentation Supabase) :

• la clé publique (sb_publishable_…) peut être exposée dans une page web ou une app ;
• la clé secrète (sb_secret_…) contourne le RLS et ne doit jamais se trouver dans un navigateur, une app distribuée ou un dépôt de code.

Les anciennes clés anon (équivalent de la publique) et service_role (équivalent de la secrète) restent valables tant que vous ne les désactivez pas, mais Supabase indique qu’il va les déprécier d’ici la fin de 2026. Si votre projet est ancien, c’est le moment de vérifier lesquelles il utilise.

Pour chercher une clé secrète, ouvrez votre app dans Chrome, appuyez sur F12, puis sur Ctrl+Maj+F (Cmd+Option+F sur Mac) pour chercher dans tous les fichiers chargés. Cherchez sb_secret_, service_role, sk_live_ (Stripe) et sk-proj- (OpenAI). Côté code, une variable dont le nom commence par VITE_ est envoyée au navigateur par construction : aucune clé secrète ne doit porter ce préfixe.

Lovable fournit un espace Secrets pour ranger les clés sensibles, et indique que ses apps placent en général les appels d’API dans du code côté serveur, pour que les identifiants restent hors du navigateur (documentation Lovable). Si vous trouvez une clé secrète, la retirer du code ne suffit pas : elle reste dans l’historique GitHub. Créez-en une nouvelle chez le fournisseur, rangez-la dans les secrets, redéployez, puis désactivez l’ancienne.

Les fichiers privés (factures, pièces d’identité) demandent le même soin. Supabase indique que les espaces de fichiers (les « buckets ») sont privés par défaut, mais qu’un bucket public permet à toute personne qui possède l’adresse du fichier d’y accéder (documentation Supabase). Ouvrez l’adresse d’un document privé dans une fenêtre de navigation privée : il ne doit pas s’afficher.

Étape 4 : une sauvegarde que vous avez déjà restaurée

Les règles de sauvegarde dépendent de l’endroit où vit votre base.

Les sauvegardes selon l’endroit où vit votre base

Où est la base	Sauvegardes automatiques	Ce qui n’est pas couvert
Lovable Cloud	Une par jour, conservées environ 14 jours	Les fichiers du Storage
Supabase, offre Pro	Quotidiennes, 7 jours (PITR en option)	Les fichiers du Storage
Supabase, offre Team	Quotidiennes, 14 jours (PITR en option)	Les fichiers du Storage
Supabase, offre gratuite	Non précisées : exportez vous-même	Tout ce que vous n’exportez pas

Sur Lovable Cloud, Lovable sauvegarde la base chaque jour et conserve environ 14 jours de sauvegardes. Vous les trouvez dans More, Database, Manage, Backups. Trois précisions de la documentation comptent : restaurer ramène la base à ce point, structure et données, et tout ce qui a été créé ensuite est perdu ; une restauration ne peut pas être annulée ; le code de l’app peut ne plus correspondre à la base restaurée si la structure a changé entre-temps (documentation Lovable). Vous pouvez aussi exporter la base (More, Database, Manage, Settings), pour les bases jusqu’à 15 Go, une fois toutes les 24 heures. Sauvegardes et exports ne couvrent que la base : les fichiers se téléchargent à part.

Si vous avez branché votre propre projet Supabase, la sauvegarde ne vient pas de Lovable : Lovable précise que vous gérez les sauvegardes dans Supabase. Supabase conserve les sauvegardes quotidiennes 7 jours sur l’offre Pro, 14 jours sur Team et jusqu’à 30 jours sur Enterprise, avec une restauration à un instant précis (PITR) en option. Pour l’offre gratuite, la documentation recommande d’exporter régulièrement vos données avec la commande supabase db dump et de garder des copies hors de Supabase. Ses sauvegardes n’incluent pas les fichiers stockés via l’API Storage, et le projet est inaccessible pendant une restauration (documentation Supabase).

Faites un vrai test, une fois avant vos premiers clients payants :

1. Restaurez une sauvegarde à côté de la production, jamais par-dessus. Chez Supabase, la restauration vers un nouveau projet est réservée aux offres payantes.
2. Attention aux tâches planifiées : selon Supabase, les tâches pg_cron et pg_net démarrent dès la fin de la restauration, sans moyen de les suspendre. Une copie ne doit pas envoyer de vrais e-mails (documentation Supabase).
3. Comparez le nombre de lignes des tables principales avec la production, puis connectez-vous avec un compte de test.
4. Notez la durée et les obstacles dans une procédure d’une page.

Étape 5 : ne pas confondre test et production

C’est le point qui a changé le plus récemment. Lovable a retiré sa séparation entre base de test et base de production (Test et Live) le 23 octobre 2026. Chaque projet sur le backend intégré tourne désormais sur une seule base, et Lovable précise que rien n’a été supprimé le 23 octobre ni mis hors ligne (documentation Lovable).

La fin de Test et Live sur Lovable

1. 14 sept. 2026PrévenusLes propriétaires concernés reçoivent un e-mail.
2. 23 oct. 2026Une seule baseTest et Live sont retirés, les bases Test sont détachées.
3. 1er déc. 2026SuppressionLes bases Test sont supprimées et ne sont plus récupérables.

Ce que cela change pour vous, en pratique :

• Les brouillons (« drafts ») ne donnent pas de seconde base : ils utilisent la même base que l’app publiée. Si vous modifiez ou supprimez un enregistrement existant, il change aussi pour l’app publiée (documentation Lovable).
• La publication copie la structure (schéma, règles RLS, fonctions), mais pas les données. Lovable demande de ne pas compter sur elle pour migrer des données.
• Selon Lovable, les bases Test sont supprimées définitivement le 1er décembre 2026. Si des données utiles s’y trouvaient encore, récupérez-les avant cette date : une demande de restauration reste possible jusque-là.

Tant que vous restez sur la base intégrée, faites vos essais avec des comptes de test, jamais avec des comptes clients, et exportez la base avant chaque évolution importante. Pour une vraie séparation, il faut une seconde base : un projet Supabase à vous pour la production, un autre pour les tests. Lovable précise qu’il ne déplace pas un projet du backend intégré vers votre propre Supabase en une seule étape : il faut exporter la base, déplacer les fichiers, puis reconfigurer l’authentification, les secrets et les services externes. C’est un travail pour un développeur.

Sur un projet relié à Supabase, Lovable enregistre les changements de structure dans le dossier supabase/migrations/ du dépôt. Regardez s’il existe : c’est l’historique qui permet de recréer la base à l’identique pour un test.

Dans quel ordre faire ces vérifications ?

Avant votre premier client payant

• RLS sur chaque tableSecurity Advisor sans erreur, aucune règle qui vaut simplement true.
• Test des deux comptesB ne voit rien de A, ni un visiteur sans compte.
• Aucune clé secrète visibleRecherche dans le navigateur, puis clés remplacées si besoin.
• Fichiers privés fermésLe lien d’un document privé ne s’ouvre pas sans connexion.
• Sauvegarde restauréeUn test à côté de la production, daté et écrit.
• Base de test ou essais prudentsComptes de test seulement, export avant chaque grosse évolution.

Les trois premières lignes concernent les données de vos clients : traitez-les avant tout lancement. Les sauvegardes viennent ensuite, car une perte de données sans sauvegarde ne se rattrape pas. La séparation du test et de la production peut se préparer ensuite, avec un développeur.

Mon avis de CTO

J’ai lancé BabyCheck en 14 jours : je ne vais pas vous dire que les outils rapides sont un problème. Lovable est un bon moyen de valider une idée, et c’est avec Next.js, Supabase et Flutter que Techvisor construit des MVP et des SaaS. Le travail commence quand de vrais utilisateurs arrivent : un écran qui marche ne dit rien de ce que la base laisse passer. J’ai cofondé Welco en 2019 et j’en suis le CTO : l’application compte plus de 150 000 inscrits, et à cette échelle les données de chaque utilisateur sont la première chose à protéger. Je fais donc toujours le même ordre : d’abord les règles d’accès et les clés, ensuite les sauvegardes, enfin la séparation du test et de la production. Un contrôle intégré à l’outil est un bon premier filtre, pas un avis indépendant.

Questions fréquentes

Le scan de sécurité de Lovable suffit-il ?

Non, pas à lui seul. Lovable indique que ses analyses aident à repérer les problèmes courants mais ne peuvent pas garantir une sécurité complète, et que vous restez responsable des exigences de sécurité de votre app. Lancez-les, traitez ce qu’elles signalent, puis faites aussi le test des deux comptes.

Mon app utilise Lovable Cloud : les mêmes vérifications s’appliquent-elles ?

Oui. Lovable Cloud repose sur la technologie de Supabase, donc les règles d’accès, les secrets et les fonctions se vérifient de la même façon. Ce qui change, c’est la sauvegarde : elle est assurée par Lovable (une par jour, environ 14 jours de conservation) au lieu de Supabase.

Dois-je quitter Lovable pour sécuriser mon app ?

Non. Lovable synchronise le projet avec un dépôt GitHub, et des hébergeurs comme Vercel ou Netlify peuvent déployer l’app depuis ce dépôt (documentation Lovable). On peut aussi continuer à faire évoluer l’app dans Lovable en protégeant ce qui compte côté base de données. Déplacer la base vers votre propre Supabase est un chantier à part, à faire avec un développeur.

Combien coûte un regard extérieur sur mon app ?

Chez Techvisor, le diagnostic express coûte 1 200 € HT pour environ 3 jours ouvrés, et l’audit complet avec feuille de route chiffrée 2 400 € HT pour environ 5 jours ouvrés. Ces durées sont des estimations. Les accès sont en lecture seule et retirés à la fin.

Quand faut-il faire ces vérifications ?

Avant le premier client qui laisse des données personnelles ou paie, puis après chaque évolution qui touche la base. Contrôlez aussi vos clés avant la fin de 2026 si votre projet utilise encore les anciennes clés anon et service_role.

Prochaine étape

Pour dérouler ces contrôles dans l’ordre sur votre app, le playbook « Reprendre une app créée avec Lovable, Bolt ou Replit » détaille chaque étape : comment vérifier, à quoi ressemble un bon résultat, et ce qui demande un développeur. La page reprise d’application résume les points de vigilance de Lovable.

Si vous préférez un regard extérieur sur votre base et votre code, l’audit d’application donne un feu vert, orange ou rouge par point, avec des exemples tirés de votre app et un plan. Pour voir si cela correspond à votre situation, réservez un échange de 15 minutes. Cet échange est gratuit et sans engagement.

Sources

• Lovable, Sécurité, Lovable Cloud, Intégration Supabase, Sauvegardes et exports de la base, Fin des environnements Test et Live, Brouillons, Hébergement hors de Lovable (documentation en anglais, consultée le 13 novembre 2026)
• Supabase, Row Level Security, Advisors, clés d’API, sauvegardes, restauration vers un nouveau projet, buckets de Storage (documentation en anglais, consultée le 13 novembre 2026)
• CVE, fiche CVE-2025-48757 (Lovable conteste la qualification de faille)
• Matt Palmer, déclaration sur la CVE-2025-48757 (source des 1 645 projets analysés et des 170 projets concernés)