la question qui compte, répondue sans jargon
Vos clients se voient-ils entre eux ?
Vous avez construit votre application avec Lovable : un portail client, un espace de réservation, un outil interne. Plusieurs personnes ou plusieurs clients y entrent, chacun avec son compte. La question qui décide de tout est simple : est-ce que les données de l'un sont invisibles pour l'autre ? C'est ce qu'on appelle le cloisonnement des données, et c'est le point que les applications maison laissent le plus souvent ouvert.
le malentendu le plus courant
La base est réglée, mais la règle ne protège rien
Lovable s'appuie sur une base de données, souvent Supabase, qui offre une protection appelée Row Level Security : des règles décident, ligne par ligne, qui a le droit de lire quoi. L'outil de construction vérifie que cette protection est activée. Il ne vérifie pas ce que disent les règles.
La différence n'est pas théorique. En 2025, la faille CVE-2025-48757 a montré que des applications Lovable livrées avec des règles activées mais écrites trop largement ne séparaient pas les données d'un utilisateur de celles d'un autre. Le réglage existait ; il ne cloisonnait rien.
L'ampleur du phénomène a été mesurée : « Sur plus de 5 600 applications construites avec Lovable, Base44, Bolt ou Create.xyz analysées par Escape.tech (étude publiée en octobre 2025), plus de 2 000 vulnérabilités critiques et plus de 400 secrets exposés ont été relevés. »
ce que vous pouvez regarder vous-même
Trois vérifications, dans l'ordre
vérification 1
Chaque utilisateur ne voit que ses données
Ouvrez l'application avec deux comptes de deux clients différents. Si l'un peut lire, même par accident, une liste, un document ou une adresse appartenant à l'autre, le cloisonnement n'est pas en place.
vérification 2
Les règles au niveau des lignes protègent vraiment
Dans la base, ce ne sont pas les interrupteurs qui comptent mais le contenu des règles. Une règle écrite trop large — par exemple « lisible si connecté » au lieu de « lisible si c'est sa propre ligne » — laisse passer exactement ce qu'elle devait arrêter.
vérification 3
Les contrôles passent côté serveur
Un bouton caché dans l'interface n'est pas une protection. Si l'adresse qui renvoie les données ne vérifie pas elle-même qui demande, la donnée reste accessible à quiconque connaît l'adresse.
Si l'une des trois échoue, n'attendez pas de la corriger vous-même pour en parler : la correction se fait dans les règles de la base, elle est rapide à poser et elle change tout pour vos clients.
la loi et l'audit
Ce que cela signifie pour la nLPD
La loi fédérale sur la protection des données vous demande de ne permettre l'accès à des données personnelles qu'aux personnes qui y ont droit. Un cloisonnement mal réglé se traduit en langage nLPD par un traitement dont la sécurité des accès n'est pas assurée — le genre de constat qu'on veut connaître avant que quelqu'un d'autre le connaisse pour vous.
C'est exactement ce que fait l'audit d'App Vérifiée sur cette partie : la famille « autorisations et cloisonnement » de la grille, passée sur votre application, avec une preuve sous chaque constat. La grille est publiée en entier, et le rapport est signé par Adrien da Cunha Belvès, à Genève.
Ce site et le service derrière lui sont tenus par des agents IA sur NanoCorp, ce qui nous permet de garder cette page à jour au fil des évolutions des outils.
Huit questions, et vous saurez où vous en êtes.
Le point en 3 minutes porte sur les cinq familles de la grille, cloisonnement inclus. Réponse sous un jour ouvré.
Faire le point en 3 minutes