76 jours d'exposition chez Lovable : ce que le vibe coding coûte vraiment en cas de fuite

Un cas précis d'agence lourdement sanctionnée spécifiquement pour une fuite liée au vibe coding circule ces dernières semaines, sans qu'on ait pu en retrouver une source vérifiable — ce n'est pas ce que cet article raconte. En revanche, un incident bien réel et très largement documenté s'est produit en 2026 chez Lovable, l'un des outils de génération d'applications par IA les plus utilisés : pendant plus de deux mois, du code source, des identifiants de base de données et des historiques de conversation IA de projets tiers sont restés accessibles à n'importe quel compte gratuit. De quoi rendre le scénario redouté tout à fait plausible pour qui livre un projet construit de cette façon.

Ce qui s'est réellement passé chez Lovable

Selon le compte-rendu publié par Lovable elle-même, une régression introduite dans son backend en février 2026 a réactivé par erreur l'accès public aux historiques de chat et au code source de projets marqués comme publics — annulant des protections mises en place entre mars et novembre 2025. La fenêtre d'exposition a couru du 3 février au 20 avril 2026, soit environ 76 jours. Des rapports avaient pourtant été déposés sur le programme de bug bounty HackerOne dès le 22 février, mais ont été classés sans escalade en raison d'une documentation interne obsolète chez le prestataire de triage. C'est la publication publique d'un chercheur en sécurité, le 20 avril, qui a forcé la correction : cinq appels API depuis un compte gratuit suffisaient à récupérer le code source complet, les identifiants de base de données en dur, et l'intégralité de l'historique de conversation IA d'un autre utilisateur — une faille classique de type BOLA (Broken Object Level Authorization), où le serveur ne vérifie pas que l'objet demandé appartient bien à celui qui le demande.

La gestion de la crise n'a pas aidé : Lovable a d'abord nié toute fuite, présenté l'exposition comme volontaire, puis reporté une partie de la responsabilité sur HackerOne, avant de reconnaître son erreur sous la pression publique. Le correctif technique, une fois la faille rendue publique, a pris deux heures. Ont suivi : le passage de tous les projets publics en privé (hors modèles officiels), un audit des projets potentiellement consultés pendant la fenêtre d'exposition, la restructuration du processus de triage HackerOne, et la notification des utilisateurs concernés.

Un cas isolé, ou un problème structurel ?

Deux études indépendantes publiées en 2026 suggèrent que Lovable n'est pas un cas isolé. Le cabinet de sécurité Wiz a analysé un ensemble d'applications vibe-codées et estime qu'une organisation sur cinq utilisant ce type de plateforme s'expose, sans le savoir, à un risque de sécurité concret — via quatre erreurs de configuration qui reviennent sans cesse : une authentification gérée entièrement côté client (mots de passe en dur visibles dans le JavaScript, session gérée par un simple indicateur dans le stockage local du navigateur), des clés d'API tierces codées en dur dans le code client (y compris des clés OpenAI), des politiques de sécurité au niveau des lignes de base de données absentes ou trop permissives — un cas documenté a vu un jeu d'entreprise vibe-codé exposer l'intégralité des données personnelles et des adresses IP de ses utilisateurs — et des outils internes déployés publiquement sans la moindre authentification, repérables par simple recherche du nom de la plateforme.

En mai 2026, le cabinet RedAccess a publié un rapport ("Shadow Builders") après avoir scanné plus de 380 000 applications publiquement accessibles construites sur des plateformes de vibe coding (Lovable, Base44, Replit, Netlify). Environ 5 000 relevaient d'un usage professionnel identifiable, et plus de 2 000 exposaient des données sensibles — corporate, opérationnelles ou personnelles — sur le web ouvert, déployées sans le moindre contrôle d'accès et accordant parfois un accès administrateur par défaut à quiconque atteignait l'URL.

Qui porte la responsabilité juridique si ça arrive chez vous

C'est le point qui rend ce type d'incident concret pour une agence ou un développeur, pas seulement pour l'éditeur de l'outil. Sous le RGPD, celui qui développe et héberge une application pour le compte d'un client agit comme sous-traitant au sens de l'article 28 — avec des obligations de sécurité qui lui sont propres, indépendamment du client. Le manquement à ces obligations expose à une amende administrative pouvant atteindre 10 millions d'euros ou 2% du chiffre d'affaires annuel mondial. Ce n'est pas une clause théorique : la CNIL a prononcé le 11 décembre 2025 une sanction d'un million d'euros contre Mobius Solutions Ltd, ancien sous-traitant de Deezer pour des campagnes publicitaires personnalisées, pour avoir conservé les données de plus de 46 millions d'utilisateurs après la fin du contrat et les avoir réutilisées sans instruction du client — un dossier sans rapport avec le vibe coding, mais qui démontre que la CNIL sanctionne bien les prestataires directement, pas uniquement l'entreprise cliente qui porte la marque.

Comment s'en prémunir concrètement

• Ne jamais valider une authentification uniquement côté client — la vérification des droits d'accès doit se faire côté serveur, sur chaque appel, sans exception.
• Auditer le code généré pour repérer toute clé d'API ou identifiant en dur avant chaque mise en production, y compris dans un projet livré rapidement.
• Vérifier explicitement les politiques d'accès aux données (Row-Level Security ou équivalent) plutôt que de faire confiance à la configuration par défaut d'une plateforme low-code ou IA.
• Repérer et fermer tout outil interne ou d'administration accessible publiquement, même sans lien partagé volontairement.
• Avant de choisir un outil de génération d'applications par IA pour un projet client, vérifier son historique d'incidents de sécurité — comme celui-ci, la plupart sont documentés publiquement.

L'accélération que permet l'IA sur un projet ne change rien à cette réalité : le code livré à un vrai client, avec de vraies données d'utilisateurs, reste sous la responsabilité de qui le construit et le maintient. Un outil qui génère vite un résultat qui a l'air de fonctionner ne dispense jamais de la revue de sécurité qui, seule, permet de savoir ce que ce code fait vraiment une fois exposé sur internet.

Source : Our response to the April 2026 incident — Lovable (compte-rendu officiel)

Source : Lovable Data Leak: BOLA Vulnerability and App Security Risks — Halborn

Source : Wiz Research Finds Risks in 20% of Vibe-Coded Apps — Wiz Blog

Source : What 2,000 Exposed Vibe-Coded Apps Reveal — The Hacker News

Source : Violation de données : sanction d'un million d'euros à l'encontre de Mobius Solutions Ltd — CNIL