En mai 2025, plus de 170 applications faites avec Lovable laissaient lire leur base à n'importe qui : utilisateurs, paiements, clés. Aucune n'affichait d'erreur. Voici le test que vous pouvez faire seul en dix minutes, ce que chaque résultat veut dire, et l'ordre dans lequel réparer.
Publié le
La plupart des applications générées par IA reposent sur la même architecture : une interface dans le navigateur, une base de données hébergée, le plus souvent Supabase, et une clé qui relie les deux. Cette clé est visible par n’importe qui, c’est prévu ainsi. Elle ne protège rien, et elle n’est pas censée le faire.
Ce qui protège, ce sont les règles écrites sur chaque table de la base : qui a le droit de lire quelle ligne, qui a le droit d’en écrire. On les appelle règles d’accès par ligne, ou RLS. Quand elles existent et qu’elles sont justes, un visiteur ne voit que ce qui le concerne. Quand elles manquent sur une table, la clé visible suffit à tout lire, et parfois à tout écrire.
Les outils de génération laissent souvent ces règles désactivées, ou en écrivent une qui autorise tout, parce que c’est ce qui fait marcher la démonstration du premier coup. Le produit fonctionne, les tests passent, et la table des utilisateurs est lisible depuis n’importe quel ordinateur. C’est ce qui a été documenté en mai 2025 sur plus de 170 applications, et rien dans l’interface ne le montrait.
Il existe une seconde clé, celle d’administration, qui ignore toutes les règles. Elle est faite pour tourner sur un serveur, jamais dans le code envoyé au navigateur ni dans un dépôt de code public. Sur le dernier produit que nous avons repris, elle se trouvait dans un script, dans un dépôt public depuis des mois.
Aucun des trois ne demande d’écrire du code. Comptez dix minutes.
Premier geste : la clé d’administration. Ouvrez votre application dans le navigateur, faites un clic droit, « Inspecter », puis l’onglet « Sources ». Cherchez, avec le raccourci de recherche, les mots service_role, sk_live et sk-. Aucun ne doit apparaître. Faites la même recherche dans votre dépôt de code, s’il y en a un. Si l’un apparaît, la clé est à faire tourner aujourd’hui, avant tout le reste.
Deuxième geste : les règles par table. Dans le tableau de bord de votre base, ouvrez la liste des tables. Chacune porte une mention indiquant si les règles d’accès sont activées, et combien de règles existent. Une table sans règle activée est lisible par tous. Une table avec une seule règle dont le contenu est « vrai » ou « tout le monde » aussi.
Troisième geste : la lecture en visiteur. Ouvrez votre application dans une fenêtre de navigation privée, sans vous connecter. Onglet « Réseau » de l’inspecteur, rechargez, et regardez les requêtes qui partent vers votre base. Si l’une d’elles ramène des données qui ne devraient pas être publiques, une liste d’utilisateurs, des commandes, des adresses, la porte est ouverte. Vous venez de faire ce que ferait n’importe qui.
Le test vous dépasse, ou le résultat vous inquiète ? C’est le premier poste de l’audit. Décrivez votre produit, nous regardons et nous vous rendons la liste par écrit.
Décrire mon projetTrouver quelque chose n’est pas une catastrophe. C’est une information, et elle se trie en trois cas qui n’ont ni le même délai ni le même coût.
Une clé d’administration exposée. Le plus grave et le plus rapide à traiter : la faire tourner dans le tableau de bord, puis retirer toute référence du code envoyé au navigateur et des dépôts. Une heure, si l’on sait où elle est utilisée côté serveur. Selon l’âge du projet, faire tourner cette clé peut aussi changer la clé visible, et donc obliger à livrer à nouveau l’interface : à vérifier avant d’appuyer sur le bouton, pas après.
Des règles absentes ou trop larges. Le cas le plus fréquent. Il ne se règle pas en cochant une case : activer les règles sans les écrire fait disparaître les données de l’application, en silence, parce que plus personne n’a le droit de rien lire. Il faut décrire, table par table, qui lit quoi et qui écrit quoi, puis l’écrire et le tester. Une demi-journée à une journée, selon le nombre de tables et la clarté de ce que fait le produit.
Une logique qui n’a rien à faire dans le navigateur. Un prix calculé côté interface, un contrôle « est administrateur » vérifié dans la page, un paiement dont le montant part du navigateur. Aucune règle de base ne corrige ça : le code qui décide est du mauvais côté. C’est une brique à refaire, et c’est le seul des trois cas qui relève d’une reprise plutôt que d’une correction.
À qui appartiennent les accès
Avant de confier quoi que ce soit à qui que ce soit, listez les comptes : la base, l’hébergement de l’interface, le dépôt de code, le nom de domaine, le paiement. Chacun doit être à votre nom, et vous devez pouvoir en révoquer l’accès en un clic. Un prestataire, nous compris, reçoit un accès en lecture, et vous le retirez à la fin.
Ne collez jamais la clé d’administration dans un prompt, ni dans un ticket de support, ni dans un message. Une fois écrite quelque part, considérez-la comme lue.
N’activez pas les règles d’accès sur la production sans les avoir écrites et testées ailleurs. L’application continuera d’afficher des pages, vides. Personne ne verra d’erreur, et vous chercherez un bug qui n’en est pas un.
Ne vous arrêtez pas au verdict d’un scan automatique. Il dit si une porte est ouverte. Il ne dit pas ce qu’il y a derrière, ni ce que fermer la porte va casser dans votre application. La seconde question est celle qui coûte.
Ne repoussez pas parce que « personne ne connaît l’adresse ». Les dépôts publics sont parcourus en continu par des programmes qui cherchent exactement ces clés. La question n’est pas de savoir si quelqu’un regardera, mais quand il l’a déjà fait.
Décrivez ce que vous avez vu. Nous vous disons par écrit ce qui se ferme tout de suite, ce qui attend, et ce que ça coûte.