Vous avez construit une application avec Lovable, Bolt, Cursor ou Claude Code, et elle stocke des noms, des e-mails, des adresses, peut-être des documents de vos clients. Vous vous demandez si vous êtes en règle avec le RGPD. La réponse courte : l'outil que vous avez utilisé pour créer l'application ne vous rend ni conforme ni non conforme. C'est vous, l'entreprise, qui êtes responsable des données. Et c'est à vous de savoir où elles sont stockées, qui y a accès et sous quel contrat.
Pour une application vibe coding, trois points reviennent presque toujours : la région où la base de données a été créée, les contrats avec les plateformes (Lovable, Supabase, le fournisseur d'IA), et quelques réglages techniques que l'IA ne pose pas d'elle-même. Rien de tout cela n'est hors de portée d'un dirigeant, à condition de savoir où regarder.
Précision utile : je suis développeur, pas juriste. Cet article vous aide à faire l'inventaire technique. Pour l'analyse juridique de votre situation, votre DPO, votre avocat ou les ressources de la CNIL restent la référence.
Ce que le RGPD vous demande, à vous, pour une application vibe coding
Dans le vocabulaire du RGPD, votre entreprise est le responsable de traitement : c'est elle qui décide pourquoi et comment les données sont utilisées. Les plateformes qui hébergent ou traitent ces données pour vous (Supabase, Lovable, votre hébergeur, un fournisseur d'e-mails) sont des sous-traitants. La CNIL classe d'ailleurs explicitement les prestataires informatiques et les hébergeurs dans cette catégorie, dans son guide dédié aux sous-traitants.
Quelques obligations du règlement ont une traduction très concrète pour votre application :
- Un contrat avec chaque sous-traitant (article 28), qui encadre ce qu'il fait des données.
- Des mesures de sécurité adaptées (article 32) : contrôle des accès, chiffrement, capacité à restaurer les données.
- La notification des violations (article 33) : en cas de fuite, la CNIL doit être prévenue, si possible dans les 72 heures après que vous en avez pris connaissance, sauf si la violation ne présente pas de risque pour les personnes.
- L'encadrement des transferts hors de l'Union européenne (chapitre V), dès que des données partent vers un pays tiers.
Ce dernier point est celui qui surprend le plus avec les applications vibe coding, parce que l'outil a souvent fait des choix à votre place, sans que vous les voyiez.
Où sont vraiment vos données : Lovable, Supabase et les autres
Beaucoup d'applications générées par l'IA reposent sur Supabase, qui fournit la base de données, l'authentification et le stockage de fichiers. Supabase l'explique clairement dans sa page sur le RGPD : chaque projet est hébergé dans une région principale, choisie à la création, et la base, l'authentification et le stockage restent dans cette région.
Deux pièges sont signalés par Supabase lui-même :
- Le regroupement « Europe » ne veut pas dire « Union européenne ». Il inclut aussi Londres et Zurich. Ce sont des pays reconnus comme offrant une protection adéquate, mais ce ne sont pas des États membres. Si vous voulez rester strictement dans l'UE, Supabase recommande de choisir une région européenne précise, comme Francfort, Paris, l'Irlande ou Stockholm (voir la liste des régions).
- La région ne suffit pas. Supabase écrit noir sur blanc que choisir une région est un contrôle de localisation et ne rend pas votre application conforme à lui seul. Sauvegardes, journaux, exports vers d'autres systèmes, exécution des fonctions et sous-traitants de Supabase peuvent jouer sur l'endroit où passent les données.
Votre première vérification est donc simple : ouvrez le tableau de bord Supabase de votre projet et regardez la région. Si l'application a été créée vite, en acceptant les réglages par défaut, il arrive qu'elle soit hébergée aux États-Unis sans que personne l'ait décidé. Changer de région après coup demande en pratique de migrer le projet, ce qui se prépare.
Côté Lovable, distinguez deux choses : les données de votre application (celles de vos clients) et les données de votre compte Lovable (vos prompts, votre code, vos informations de compte). Elles ne sont pas forcément traitées au même endroit ni sous le même contrat. Vérifiez dans votre espace et dans la documentation de Lovable où se trouve la base de votre application et sous quelles conditions.
Enfin, si votre application appelle une API d'IA (pour résumer un document, répondre à un client, classer des demandes), les données envoyées dans ces requêtes partent chez ce fournisseur. Ce fournisseur devient lui aussi un sous-traitant à inventorier.
Les contrats à vérifier : DPA et sous-traitants
Le contrat de sous-traitance prévu par l'article 28 porte souvent un nom anglais : DPA, pour Data Processing Agreement. Les grandes plateformes en proposent un. Supabase indique mettre un DPA à disposition. Lovable publie aussi un DPA, qui précise les formules d'abonnement auxquelles il s'applique : vérifiez que la vôtre en fait partie.
Pour chaque service qui touche aux données de vos clients, notez :
- le nom du service et ce qu'il fait pour vous (base de données, e-mails, paiement, IA, analytics) ;
- si un DPA existe et s'il s'applique à votre abonnement ;
- où les données sont traitées, et la liste des sous-traitants du service (souvent publiée sur son site) ;
- en cas de transfert hors UE, sur quelle base il repose.
Sur ce dernier point, pour les États-Unis, il existe depuis le 10 juillet 2023 une décision d'adéquation de la Commission européenne, le Data Privacy Framework. Elle permet des transferts vers les entreprises américaines certifiées. Le Tribunal de l'Union européenne a rejeté un recours contre cette décision le 3 septembre 2025, dans l'affaire Latombe (synthèse du cabinet Hunton). Les commentateurs rappellent que ce cadre peut encore être contesté. C'est une raison de plus de privilégier, quand c'est possible, un hébergement de la base dans l'UE : vous dépendez moins de l'évolution de ce cadre.
Cet inventaire nourrit directement votre registre des traitements et votre politique de confidentialité. Très souvent, la politique de confidentialité d'une application vibe coding a été générée en même temps que le reste et ne correspond pas aux services réellement utilisés. C'est à reprendre.
Les points techniques que l'IA oublie souvent
Le RGPD demande une sécurité « appropriée ». Dans une application générée par l'IA, voici ce qui manque le plus souvent :
- Les règles d'accès à la base. Sur Supabase, ce sont les règles RLS qui empêchent un utilisateur de lire les données d'un autre. Mal configurées, elles exposent tout. Nous avons détaillé la vérification dans Application Lovable : comment vérifier la sécurité Supabase (RLS).
- Les clés et secrets dans le code. Une clé de service exposée côté navigateur donne un accès complet. Si c'est votre cas, suivez ce guide sur les clés API exposées.
- Les journaux trop bavards. L'IA ajoute volontiers des journaux pour déboguer, qui enregistrent parfois des e-mails, des adresses ou des contenus de formulaires. Ces journaux sont des données personnelles, stockées quelque part, souvent sans durée limite.
- La suppression réelle des données. Quand un client demande l'effacement de son compte, est-ce que ses fichiers, ses commandes et ses traces dans les outils tiers disparaissent aussi ? Il faut le vérifier, pas le supposer.
- Les durées de conservation. Rien n'est supprimé automatiquement si personne ne l'a prévu.
- Les sauvegardes. Elles contiennent les mêmes données personnelles que la base : leur emplacement et leur accès comptent aussi.
Faire ce tour une première fois prend du temps, surtout si vous ne savez pas lire le code. C'est typiquement le travail d'une journée senior : inventaire des services, vérification de la région, des règles d'accès et des secrets, liste des corrections à faire, que vous pouvez ensuite faire appliquer par l'IA. C'est le format de l'offre Copilote : une journée par mois avec un développeur senior, pour vérifier, corriger et vous laisser une feuille de route claire.
Questions fréquentes
Lovable ou Supabase sont-ils « conformes RGPD » ?
Une plateforme peut proposer un DPA, des régions européennes et des mesures de sécurité. Mais la conformité concerne votre traitement de données, pas l'outil. Supabase le dit lui-même : la sécurité est partagée, eux s'occupent de l'infrastructure, vous gérez les traitements, les consentements et les contrôles d'accès.
Ma base Supabase est aux États-Unis : est-ce interdit ?
Pas automatiquement. Un transfert hors UE doit reposer sur une base prévue par le RGPD, par exemple une décision d'adéquation ou des clauses contractuelles types. Vérifiez sur quoi repose le vôtre avec votre conseil. Si vous préférez éviter la question, une migration vers une région de l'UE est possible, mais elle se prépare.
Je n'ai que quelques dizaines d'utilisateurs : suis-je concerné ?
Le RGPD s'applique dès que vous traitez des données personnelles, quel que soit le nombre d'utilisateurs. Les obligations sont proportionnées aux risques, mais elles existent.
Puis-je envoyer les données de mes clients à une API d'IA ?
Seulement si c'est encadré : le fournisseur doit être inventorié comme sous-traitant, avec un contrat adapté, et vos clients doivent en être informés. Envoyez le strict nécessaire, pas la fiche client entière.
Si vous ne savez pas où sont stockées les données de votre application, ou si vous voulez un regard technique avant d'en parler à votre conseil, écrivez-moi. On fait l'inventaire ensemble, calmement, et vous repartez avec une liste claire de ce qui va et de ce qui est à corriger.