Lovable : une étude trouve des données personnelles accessibles sans connexion sur des milliers d'applications
La société de sécurité allemande Crissy Field a analysé 159 041 projets créés avec Lovable. Sur 24 664 sites qui renvoyaient des données Supabase dès le chargement, 7 403 laissaient lire des tables contenant des adresses e-mail, parfois des numéros de passeport ou des données de paiement.
La promesse du « vibe coding » se heurte à une question très concrète : qui protège les données ? La société de sécurité allemande Crissy Field a examiné 159 041 projets créés avec Lovable, la plateforme suédoise qui transforme une description en langage courant en application web. Résultat : sur des milliers de sites, des informations personnelles, parfois très sensibles, étaient lisibles sans aucune connexion. L’enquête, menée avec le quotidien économique allemand Handelsblatt (article du 2 novembre 2026), est détaillée dans un rapport publié par Crissy Field avec des chiffres actualisés.
Ce que l’étude a mesuré
Crissy Field s’est concentrée sur Supabase, le service de base de données qu’elle estime le plus utilisé par les projets Lovable. Les bases propres à Lovable, lancées fin 2025, n’ont pas été examinées.
| Étape | Nombre |
|---|---|
| Projets Lovable identifiés dans Common Crawl (déc. 2025 à sept. 2026) | 159 041 |
| Projets utilisant Supabase | 34 545 |
| Sites envoyant des enregistrements Supabase dès le chargement, sans connexion | 24 664 |
| Sites où des tables contenant des adresses e-mail étaient lisibles | 7 403 (30 %), sur 10 560 tables |
Le premier chiffre n’est pas en soi une faille : une application peut afficher publiquement certaines données. Le problème apparaît à l’étape suivante. Avec de simples requêtes en lecture seule, avec la même clé d’API que celle utilisée par le site, les chercheurs ont pu lire d’autres tables. Crissy Field ne publie pas sa méthode d’accès, pour ne pas faciliter de nouvelles intrusions, et n’a téléchargé que des extraits des bases.
Des passeports aux messages privés
Les exemples cités par le rapport sont sérieux :
- un forum allemand exposait plus de 80 000 profils (nom, e-mail, date de naissance) et plus de 200 000 messages de discussion ;
- des organisateurs d’événements et des restaurants laissaient lire des dizaines de milliers d’enregistrements de ventes, avec téléphones, adresses postales, informations de paiement et codes de billets ;
- un gestionnaire immobilier exposait des résumés, générés par IA, d’e-mails internes sur ses locataires et partenaires ;
- un prestataire exposait plus de 1 000 enregistrements avec numéros de passeport, dates d’expiration et nationalités ;
- ailleurs : contrats, factures, albums photo, conversations WhatsApp internes, et 280 000 e-mails envoyés aux clients d’un fournisseur.
Crissy Field dit ne pas savoir si ces données ont été exploitées, mais rappelle qu’elles peuvent servir à l’hameçonnage, à la fraude aux billets ou à l’usurpation d’identité.
Les limites du chiffre de 30 %
Le rapport est prudent sur sa propre statistique. Une adresse e-mail peut être un contact public ou une donnée de test ; à l’inverse, des fiches personnelles sans e-mail échappent au comptage. Les 30 % ne portent que sur les 24 664 sites examinés de près, et l’échantillon tiré de Common Crawl n’est pas représentatif de l’ensemble des applications Lovable. Ce n’est donc pas un taux de fuite confirmé.
Qui est responsable ?
Crissy Field pointe un décalage : Lovable met en avant qu’aucune compétence technique n’est nécessaire, alors que ses conditions d’utilisation laissent aux clients la responsabilité de leurs applications et de leurs données. Selon India Today, qui cite Handelsblatt, Lovable a répondu que le problème n’était pas propre à sa plateforme et touchait tout le secteur. Nous n’avons pas trouvé de déclaration publique de l’entreprise à ce stade.
Les chercheurs reconnaissent que des erreurs de droits d’accès existent aussi dans des applications écrites à la main. Mais avec Lovable, les intégrations de base de données suivent des schémas récurrents : une approche qui fonctionne contre une application peut être répétée contre beaucoup d’autres. Et des utilisateurs sans bagage technique ont plus de mal à repérer ces erreurs. Leur conseil : faire vérifier les droits d’accès, les interfaces et la séparation entre comptes avant de manipuler de vraies données de clients, et recommencer après chaque changement important.
Notre lecture
Le problème n’est pas propre à l’IA : une base mal configurée reste une base mal configurée, qu’elle ait été branchée par un humain ou par un agent. Mais les outils de génération d’applications multiplient le nombre de projets mis en ligne par des personnes qui ne savent pas qu’une base sans règles d’accès correctement posées peut être lue bien au-delà de ce que l’application affiche. L’étude ne prouve ni une fuite massive ni une exploitation, et son échantillon n’est pas représentatif ; elle montre en revanche que « sans code » ne veut pas dire « sans sécurité ». Pour ces plateformes, l’enjeu est désormais de rendre la configuration sûre par défaut et de bloquer la mise en ligne quand des données sensibles restent ouvertes, plutôt que de renvoyer la responsabilité aux clients. Si vous avez publié une application de ce type, testez-la déconnecté et faites vérifier ses règles d’accès avant d’y stocker des données réelles.
Sources
- Crissy Field — Lovable: Many Apps Built on the Platform Expose Sensitive Data (rapport de recherche) Source primaire
- India Today — AI app-maker Lovable apps expose personal details, researchers find thousands of cases (3 novembre 2026) Source secondaire
Une source primaire émane directement de l'entreprise, du laboratoire ou de l'organisme concerné. Une source secondaire rapporte l'information sans en être l'auteur : nous la signalons comme telle. Une erreur ? Consultez notre politique de correction.
