Guide · Sécurité
Sécurité d'une application Lovable : les vérifications avant de mettre en ligne
Par Marie Van Haecke ·
Dans une application Lovable, ce qui protège vraiment vos données, ce sont les règles d'accès de chaque table de la base (la « sécurité au niveau des lignes »). La clé publique de la base est visible dans le navigateur par conception : si une table n'a pas de règle, n'importe qui peut la lire. Avant de publier, vérifiez chaque table, rangez les clés dans les Secrets, testez avec un second compte et lancez l'analyse de sécurité de Lovable.
Pourquoi c'est le point le plus important
Une application Lovable parle directement à sa base de données depuis le navigateur. C'est ce qui la rend rapide à construire. Cela veut aussi dire que la protection des données ne repose pas sur le fait de « cacher » la base, mais sur des règles écrites dans la base elle-même, qui disent qui a le droit de lire ou de modifier chaque ligne.
Sécurité au niveau des lignes (RLS) : des règles attachées à chaque table, qui décident ligne par ligne qui peut lire, créer, modifier ou supprimer. Exemple : « un technicien ne voit que les interventions qui lui sont attribuées ».
Les sept vérifications
Chaque table a des règles d'accès activées
Dans l'onglet base de données de Lovable Cloud (ou dans Supabase), vérifiez qu'aucune table ne reste sans règle. Une table sans règle est une table publique.
Aucune règle ne laisse tout passer
Une règle écrite « vrai pour tout le monde » revient à ne pas en avoir. Chaque règle doit s'appuyer sur l'identité de la personne connectée ou sur son rôle.
Les rôles sont stockés à part
Le rôle d'une personne (administrateur, manager, membre) ne doit pas pouvoir être modifié par cette personne. Rangez-le dans une table dédiée, en lecture seule pour les utilisateurs.
Les clés d'API sont dans les Secrets
Clés Stripe, Resend, Make, CRM : aucune ne doit apparaître dans le code de la page. Lovable détecte les clés collées dans la discussion et propose de les ranger dans les Secrets.
Les fonctions serveur vérifient qui appelle
Une fonction qui envoie un email ou modifie des données doit contrôler que l'appelant est connecté et autorisé, sinon n'importe qui peut la déclencher.
Les fichiers sont privés quand ils doivent l'être
Photos d'intervention, pièces d'identité, factures : l'espace de stockage doit être privé, avec des liens d'accès temporaires.
Un second compte ne voit pas les données du premier
Créez deux comptes de test, remplissez-en un, connectez-vous avec l'autre. C'est le test le plus simple et le plus révélateur.
Ce que Lovable vérifie pour vous
| Analyse | Quand | Ce qu'elle contrôle |
|---|---|---|
| Analyse rapide | Automatiquement à chaque publication | Règles d'accès de la base, dépendances vulnérables connues, exposition des serveurs MCP |
| Analyse approfondie | À la demande | Contrôle d'accès, points d'entrée non protégés, injections, clés exposées, paiement, authentification, données personnelles exposées |
| Revue conversationnelle | À la demande, dans la discussion | Évaluation détaillée de l'application et recommandations |
Les administrateurs d'un espace peuvent aussi bloquer la publication en cas de problème critique. Activez cette option dès qu'un projet manipule des données clients.
Source : documentation Lovable, « Security », consultée le 30 septembre 2026.
Ce que les analyses ne remplacent pas
Une analyse automatique repère les erreurs connues. Elle ne sait pas que, dans votre entreprise, un commercial ne doit pas voir les marges, ou qu'un client ne doit voir que ses propres devis. Ces règles métier se décident avec vous, puis se vérifient à la main. Lovable le rappelle : la conformité de l'application à ses exigences de sécurité reste de votre responsabilité.
Questions fréquentes
Une application Lovable est-elle sécurisée par défaut ?
Lovable fournit les briques et des analyses automatiques, mais la sécurité dépend des règles d'accès définies pour chaque table. Elles doivent être vérifiées avant toute mise en ligne avec de vraies données.
La clé visible dans le code de mon application est-elle un problème ?
La clé publique de la base est conçue pour être visible. Elle ne donne accès qu'à ce que les règles d'accès autorisent. Les autres clés (paiement, emails, CRM) doivent rester dans les Secrets.
Comment tester la sécurité sans être développeur ?
Créez deux comptes, remplissez l'un, connectez-vous avec l'autre et vérifiez ce que vous voyez. Puis lancez l'analyse approfondie de Lovable et lisez ce qu'elle signale.
Votre application Lovable manipule des données clients et vous voulez un regard extérieur avant de l'ouvrir ? L'audit vérifie chaque table et chaque accès.
Marie Van Haecke · 20 ans à concevoir des produits tech et à coacher des équipes produit. Fondatrice de Grabloop, Lovable Certified Expert 2026 (App builder et Website builder).