Checklist conformité RGPD pour choisir un backend as a service
Cocher une case « région Europe » ne suffit pas à rendre un backend conforme au RGPD. La conformité dépend d'un ensemble précis de critères techniques et contractuels. Où vivent réellement les données ? Quelle est la nationalité de la société qui les héberge ? Que dit le contrat de sous-traitance ? Comment les données de chaque client sont-elles isolées ? Les droits des personnes concernées sont-ils réellement actionnables, ou seulement promis ?
Cette checklist détaille dix critères à vérifier avant de signer avec un backend as a service (BaaS), avec la question précise à poser à chaque fournisseur pour chacun.
Le critère le plus souvent oublié est la nationalité du fournisseur, distincte de la localisation de ses serveurs. Une société mère américaine reste soumise au CLOUD Act même si ses données tournent sur des serveurs en France ou en Allemagne. Notre guide complet sur le RGPD et la souveraineté UE détaille cette distinction juridique en profondeur ; cette checklist se concentre sur les points opérationnels à vérifier pendant une évaluation fournisseur.
- Une case « région UE » cochée ne couvre qu'une partie du risque : la nationalité de la société qui héberge vos données compte tout autant face au CLOUD Act.
- Le DPA (article 28 RGPD) est obligatoire dès qu'un fournisseur traite des données pour votre compte, quelle que soit la taille de votre entreprise.
- L'isolation entre clients n'est pas un détail d'implémentation : une table partagée avec tenant_id n'offre pas les mêmes garanties qu'une base dédiée par projet.
- Une certification « en feuille de route » n'est pas une certification obtenue : exigez le rapport d'audit signé, pas une promesse marketing.
- Les droits d'accès, d'effacement et de portabilité doivent être exerçables en self-service : un fournisseur qui répond par script SQL sur mesure ralentit votre propre conformité.
- Auto-héberger élimine le sous-traitant mais transfère toute la charge opérationnelle de sécurité et de notification de violation à votre équipe.
Localisation des données et nationalité du fournisseur
Deux faits distincts déterminent votre exposition légale : où sont stockées les données, et quelle est la nationalité juridique de la société qui les héberge. Le RGPD encadre le premier point. Le CLOUD Act américain encadre le second.
Ce texte autorise les autorités fédérales américaines à réclamer des données à toute société de droit américain, y compris ses filiales. Cela vaut même quand ces données sont hébergées sur des serveurs physiquement situés en Europe. Un badge « hébergé en UE » sur un site marketing ne dit rien de la nationalité de la maison mère.
La question à poser à tout fournisseur : votre société mère est-elle immatriculée hors UE, même si vos serveurs sont en Europe ?
Le DPA : ce que l'article 28 du RGPD exige
Le RGPD impose un contrat écrit entre vous, responsable de traitement, et votre fournisseur, sous-traitant : c'est l'article 28. Sans ce document, vous n'êtes pas en conformité, quel que soit le sérieux technique du fournisseur par ailleurs.
Un DPA valide précise l'objet et la durée du traitement, les catégories de données et de personnes concernées, et la liste des sous-traitants. Il détaille aussi les mesures de sécurité appliquées et les obligations d'assistance en cas de demande d'un utilisateur. Enfin, il fixe le sort des données à la fin du contrat : suppression ou restitution.
Aurabase publie un DPA signable directement depuis le Studio, construit sur les clauses contractuelles types adoptées par la Commission européenne (décision 2021/914). Notre article dédié au DPA d'un backend as a service détaille clause par clause ce qu'il faut vérifier avant de signer.
La liste des sous-traitants doit être publique et notifiée
L'article 28 RGPD exige aussi que votre sous-traitant liste ses propres sous-traitants : hébergeur, passerelle de paiement, service d'email transactionnel. Tout changement doit vous être notifié, avec un droit d'opposition.
Exigez cette liste par écrit et vérifiez que chaque sous-traitant critique, l'hébergeur en particulier, est lui aussi basé en UE. Faute de quoi la chaîne de sous-traitance recrée l'exposition CLOUD Act que vous cherchiez à éviter en changeant de fournisseur principal.
Isolation entre clients : mutualisée, ou dédiée ?
L'isolation entre vos données et celles des autres clients d'un même fournisseur détermine l'ampleur d'une fuite en cas de bug. Trois architectures existent, avec des garanties très différentes.
Le modèle le plus répandu, une grande table partagée avec une colonne tenant_id, est aussi le plus fragile. Une policy RLS mal écrite, ou une requête sans clause de filtrage, peut exposer plusieurs clients à la fois. Une base par projet, avec son propre rôle de connexion, élimine cette classe de bug : la frontière est posée au niveau de la connexion, pas d'une clause WHERE qu'un développeur pourrait oublier.
search_path injecté depuis le JWT au niveau du gateway. Entre deux organisations, l'isolation devient physique : cluster Postgres dédié, namespace Kubernetes séparé. Détail complet sur la page Sécurité.Sécurité technique : chiffrement, audits, bug bounty
Le RGPD impose des « mesures techniques et organisationnelles appropriées » (article 32), sans lister de standard précis. Dans la pratique, trois éléments concrets à vérifier : le chiffrement en transit et au repos, l'existence d'un programme d'audit indépendant, et un canal de signalement de vulnérabilité documenté.
Aurabase chiffre les échanges en TLS 1.3 et les données au repos en AES-256, avec une option BYOK (clés gérées par vous via AWS KMS ou HashiCorp Vault) sur le plan Enterprise. Le programme de bug bounty public, hébergé sur huntr.dev/aurabase, verse de 200 € à 10 000 € selon la sévérité de la faille trouvée. La politique de disclosure coordonnée court sur 90 jours. Un fournisseur sans canal de signalement documenté n'a, par définition, aucun audit indépendant en cours.
Droits des personnes concernées : self-service ou script manuel ?
Les articles 15, 17 et 20 du RGPD garantissent à vos utilisateurs finaux un droit d'accès, d'effacement et de portabilité de leurs données. La question à poser à votre BaaS : ces droits sont-ils exerçables en self-service, ou nécessitent-ils un script SQL sur mesure à chaque demande ?
C'est vous, responsable de traitement, qui restez légalement tenu de répondre sous 30 jours, même si l'infrastructure sous-jacente est opaque. Un fournisseur qui exige un script manuel à chaque demande ralentit votre propre délai de réponse. Chez Aurabase, l'export et la suppression sont accessibles depuis Studio → Settings → Privacy, ou via privacy@aurabase.cloud pour les cas plus complexes.
Notification de violation : délai légal contre engagement contractuel
Le RGPD impose au responsable de traitement, vous, de notifier une violation à son autorité de contrôle sous 72 heures après en avoir eu connaissance (article 33). Ce délai ne démarre que lorsque vous êtes informé par votre fournisseur.
L'engagement contractuel de notification du fournisseur compte donc autant que le délai légal lui-même. Demandez le délai contractuel maximum qu'il s'engage à respecter pour vous notifier un incident, et ce que cette notification doit inclure : nature de la violation, catégories et volume approximatif de données concernées. Ce chiffre doit être écrit noir sur blanc dans le DPA, pas seulement évoqué à l'oral en avant-vente.
Certifications : obtenue, ou feuille de route ?
Une certification annoncée sur un site marketing n'est pas la même chose qu'une certification obtenue. Beaucoup de fournisseurs BaaS communiquent une « feuille de route de conformité » (SOC 2, ISO 27001) sans avoir engagé l'audit tiers correspondant.
Sur ce point précis, la transparence compte davantage que l'annonce elle-même. La page Sécurité d'Aurabase indique explicitement qu'aucune certification tierce n'est engagée à ce jour, et publie sa feuille de route sur un Trust Center dédié plutôt que d'afficher un badge non mérité. Exigez systématiquement le rapport d'audit signé, pas juste le nom de la norme visée, avant de considérer une certification comme acquise chez n'importe quel fournisseur.
Auto-hébergement : la conformité totale a un coût opérationnel
Auto-héberger son propre Postgres élimine la question du sous-traitant, mais ne règle pas automatiquement la conformité RGPD. La responsabilité de la sécurité, des sauvegardes chiffrées, des correctifs et de la réponse aux violations vous revient intégralement.
Pour une équipe sans SRE dédié à la sécurité Postgres, un BaaS souverain UE avec DPA signé transfère une partie de cette charge opérationnelle à un tiers audité, sans sacrifier la juridiction. Notre comparatif auto-hébergement vs BaaS souverain UE chiffre ce compromis pour une petite équipe.
Les dix critères et la question à poser
Une version condensée, utile en réunion d'évaluation fournisseur ou pour construire votre propre grille d'audit.
FAQ : conformité RGPD et choix d'un BaaS
Prochaine étape
Aucun de ces dix critères ne suffit isolément à garantir la conformité RGPD d'un backend as a service. C'est leur combinaison, vérifiée point par point plutôt que déduite d'un badge marketing, qui construit une évaluation fournisseur sérieuse.
Pour la nuance juridique complète entre région d'hébergement et nationalité du fournisseur, direction notre guide RGPD et souveraineté UE. Pour le détail des mesures de sécurité techniques évoquées aux critères 4 et 5, la page Sécurité d'Aurabase reste la référence à jour.