--- title: "Supabase est-il conforme au RGPD ? Où sont vos données" description: "Supabase garde base, Auth et Storage dans la région choisie. CDN de Storage, Edge Functions, logs et support travaillent ailleurs. Lovable Cloud aussi." url: "https://madsalt.tech/fr/blog/is-supabase-gdpr-compliant/" author: "Denys Zaichenko" author_url: "https://madsalt.tech/fr/about/" language: "fr" published: 2026-11-04 --- # Supabase est-il conforme au RGPD ? Où sont vos données En bref Supabase permet de bâtir des applications conformes au RGPD et propose un accord de sous-traitance (Data Processing Agreement, DPA), mais il ne rend pas votre application conforme. La région choisie héberge la base Postgres, Auth, les fichiers Storage et les sauvegardes. Quatre éléments fonctionnent en dehors : le cache du CDN de Storage, les Edge Functions si vous ne les épinglez pas, les logs de la plateforme et l'accès du support. Si vous avez besoin de l'UE, choisissez Irlande, Paris, Francfort ou Stockholm, pas l'option générale "Europe", qui peut aussi tomber à Londres ou à Zurich. Une région ne se change pas ensuite : déménager signifie un nouveau projet et une migration. Lovable Cloud fonctionne de la même façon et choisit la région la plus proche de vous si vous n'en choisissez pas. Je suis Denys, ingénieur full-stack et IA, et la plupart des applications que je construis ou répare tournent sur Supabase. Les clients européens posent deux questions avant toute autre : Supabase est-il conforme au RGPD, et où se trouvent les données ? Cet article répond aux deux à partir des documents de Supabase et de Lovable, lus le 29 octobre 2026, avec les commandes que j'utilise pour vérifier un projet. ## Supabase est-il conforme au RGPD ? Le [guide RGPD](https://supabase.com/docs/guides/security/gdpr-compliance) de Supabase le présente comme une responsabilité partagée : Supabase sécurise l'infrastructure, et vous êtes responsable du traitement des données de votre application, des parcours de consentement et des contrôles d'accès. Au sens du RGPD, Supabase est votre sous-traitant pour les données que vous stockez, et son [Data Processing Addendum](https://supabase.com/legal/customer-resources/data-processing-addendum) est le contrat qui le dit. Le même document désigne Supabase comme responsable de traitement pour une catégorie : les données d'usage qu'il collecte pour faire fonctionner la plateforme. Deux points de ce DPA comptent en pratique : - **Région.** Quand vous demandez à Supabase de traiter des données dans une région, il les stocke et les traite principalement là, sauf si la loi, vos propres instructions ou le service demandé exigent autre chose. - **Sous-traitants ultérieurs.** Vous autorisez à l'avance la [liste des sous-traitants ultérieurs](https://supabase.com/legal/customer-resources/subprocessor-list) de Supabase, qui prévient 30 jours avant tout changement. Vous pouvez vous abonner à ces changements sur la même page. La liste comprend AWS et Cloudflare pour l'hébergement, et des prestataires pour le support, la surveillance des erreurs et les messages aux utilisateurs du compte. ## Où Supabase stocke-t-il vos données ? La [FAQ sur la résidence des données](https://supabase.com/legal/privacy-resources/data-residency-and-transfers-faq) et la [page des régions](https://supabase.com/regions) les répartissent ainsi : | Élément de votre projet | Où il est traité | | --------------------------------------- | ----------------------------------------------------------------------------------------------- | | Base Postgres et ses sauvegardes | La région AWS que vous avez choisie | | Auth (utilisateurs, sessions) | La région que vous avez choisie | | Fichiers Storage à l'origine | La région que vous avez choisie | | Cache du CDN de Storage | Dans le monde entier, en cache chez Cloudflare | | Edge Functions | Au edge le plus proche de l'appelant, sauf si vous les épinglez à une région | | Logs et télémétrie de la plateforme | Hors de votre région ; les logs sont stockés dans des centres de données de l'UE | | Accès du support | Une équipe de support mondiale, sur votre demande ou lors d'un incident de sécurité, journalisé | | Vos données de compte et de facturation | Les systèmes centraux de Supabase ; Supabase en est ici le responsable de traitement | ![Où chaque élément d'un projet Supabase est traité. Région = la région AWS choisie à la création du projet. Base, Auth, sauvegardes: Postgres, Auth → votre région; Fichiers Storage: fichier → votre région → cache CDN, mondial; Edge Functions, non épinglées: appel de fonction → edge le plus proche; Logs de la plateforme: logs, télémétrie → centres de données UE.](https://madsalt.tech/charts/fr/is-supabase-gdpr-compliant.svg) *Figure 1. FAQ Supabase sur la résidence des données et page des régions, lues le 29 octobre 2026.* La FAQ répond directement à la question franche : Supabase ne garantit pas que vos données ne quittent jamais la région. Votre base et vos sauvegardes restent ; les quatre catégories en bas du tableau peuvent la quitter. ## Quelles régions Supabase sont dans l'UE ? Quatre régions précises sont dans l'UE : West EU (Ireland) `eu-west-1`, West EU (Paris) `eu-west-3`, Central EU (Frankfurt) `eu-central-1` et North EU (Stockholm) `eu-north-1`. Londres `eu-west-2` et Zurich `eu-central-2` sont en Europe et bénéficient de décisions d'adéquation RGPD, mais ne sont pas des États membres de l'UE. Cette distinction compte à la création du projet. L'option générale "Europe" laisse Supabase choisir une région européenne disponible selon la capacité, et le [guide des régions](https://supabase.com/docs/guides/platform/regions) avertit que ce peut être Londres ou Zurich. Si votre contrat ou votre client dit "les données restent dans l'UE", choisissez une région précise de l'UE. Un détail de plus si vous comptez sur des Edge Functions régionales : la page des régions indique qu'épingler une fonction à une région n'est pas possible en Ohio ni à Stockholm. ## Comment vérifier la région de votre projet ? Dans le tableau de bord, la région apparaît dans les réglages du projet. Depuis un terminal, la CLI Supabase liste chaque projet auquel vous avez accès avec sa région : ```bash supabase projects list supabase projects list -o json # each project has a "region" field, e.g. "eu-west-1" ``` Je l'ai exécuté sur mon propre compte avec la CLI 2.109.1 : chaque projet est revenu avec son code de région AWS, un coup d'œil suffit donc pour voir si un projet se trouve hors de l'UE. **Peut-on la changer ?** Non. La [note de dépannage](https://supabase.com/docs/guides/troubleshooting/change-project-region-eWJo5Z) de Supabase indique qu'un projet est lié à sa région au niveau de l'infrastructure. Déménager signifie créer un nouveau projet dans la région cible et y migrer, puis mettre à jour l'URL de l'API et les clés dans l'application et copier à la main les secrets des connexions tierces. Un transfert de projet vers une autre organisation ne change pas non plus la région. ## Lovable Cloud est-il conforme au RGPD ? Une application Lovable Cloud fait tourner son backend sur le même modèle, les mêmes questions se posent donc, avec les réglages de Lovable devant. D'après la [documentation du backend](https://docs.lovable.dev/features/cloud), la [documentation de la base](https://docs.lovable.dev/features/database) et la [page du DPA](https://lovable.dev/data-processing-agreement) de Lovable : - **La région est Americas, Europe ou Asia Pacific**, choisie à l'activation du backend. Un défaut d'espace de travail fixé par un admin l'emporte (offres Business et Enterprise). Sinon Lovable utilise votre propre réglage "where project data is stored" et, à défaut, la région la plus proche de vous. - **Vous ne la verrez peut-être jamais.** Avec Enable Cloud sur "Always allow", Lovable crée le backend dans cette région sans demander. Seul "Ask each time" montre d'abord la région. - **Elle ne peut pas être changée.** Lovable dit clairement que la région d'un projet ne peut pas être changée et qu'un projet existant ne peut pas être déplacé. - **Vérifiez-la** sous More → Database → Manage → Settings, dans la ligne Database location, par exemple "Europe (Frankfurt)". - **Le site lui-même est servi dans le monde entier**, quelle que soit la région ; la région ne couvre que le backend. - **Les requêtes d'IA sont à part.** Garder les requêtes aux modèles d'IA dans l'UE est un réglage nommé EU inference, sur les espaces Enterprise. - **Le DPA est inclus dans les offres Business et Enterprise.** Donc si vous avez activé le backend depuis l'extérieur de l'Europe, sans réglage de votre part, le backend peut se trouver dans une autre région, et avec "Always allow" Lovable ne demande rien. Vérifiez la ligne Database location avant l'inscription de votre premier vrai utilisateur. ## Ce que la région ne résout pas Le guide de Supabase le dit lui-même : choisir une région est un contrôle de localisation des données et ne rend pas à lui seul une application conforme au RGPD. Les failles que je trouve le plus souvent sont dans l'application, pas dans la plateforme : 1. **Des données personnelles lisibles par tous.** Une table avec la RLS désactivée, ou une politique qui autorise toutes les lignes, sert noms et e-mails à quiconque a la clé publique. Le [contrôle de sécurité Supabase](https://madsalt.tech/fr/tools/supabase-security-check/) gratuit signale les tables sans RLS, les politiques qui autorisent toutes les lignes et les colonnes d'apparence sensible lisibles par des visiteurs anonymes. 2. **Des comptes créés avec l'adresse d'un autre.** Avec la confirmation par e-mail désactivée, n'importe qui peut s'inscrire avec une adresse qui n'est pas la sienne. 3. **Des fichiers dans des buckets publics.** Un [bucket public](https://madsalt.tech/fr/notes/supabase-public-bucket/) sert chaque fichier à quiconque a son URL, et le CDN le met en cache dans le monde entier. 4. **Des sous-traitants que vous avez ajoutés vous-même.** Chaque service d'e-mail, de SMS, d'IA ou d'analytique que vos Edge Functions appellent est votre sous-traitant, pas celui de Supabase, et exige son propre contrat. 5. **Suppression et conservation.** Une demande d'effacement échoue si des clés étrangères empêchent de supprimer un utilisateur qui a écrit du contenu, et des logs qui gardent des adresses indéfiniment posent un problème de conservation. Je traite les deux derniers, et quatre autres, dans la section RGPD de ma [checklist de sécurité pour applications Lovable](https://madsalt.tech/fr/blog/lovable-app-security-checklist/). Pour ce que Supabase certifie au-delà du RGPD, voir [Supabase est-il sûr ?](https://madsalt.tech/fr/blog/is-supabase-secure/). Cet article n'est pas un conseil juridique ; votre délégué à la protection des données ou votre avocat décide de ce dont votre traitement a besoin. Vous ne savez pas où se trouvent les données de votre application ? Je vérifie volontiers avec vous la région et les règles d'accès. Sans démarchage. [Me contacter](https://madsalt.tech/fr/#contact)