Notre guide backend conforme RGPD et souverain UE pose le cadre juridique complet : RGPD, CLOUD Act, et pourquoi cocher une région d'hébergement ne suffit jamais seul. Cet article prolonge sa section sur l'arbitrage PME avec la charge opérationnelle réelle de chaque option, plutôt que de rejouer la théorie juridique. Si votre question porte sur les backends Rust auto-hébergeables entre eux, sh0.dev, TrailBase, Aurabase, notre comparatif dédié Aurabase face aux BaaS Rust-natifs traite cet angle architectural distinct. Celui-ci reste centré sur la décision RGPD pour une PME, indépendamment du langage du backend.
L'essentiel
- Deux options respectent le RGPD sur le papier, auto-hébergement en UE et BaaS souverain UE : ce qui les différencie est la charge opérationnelle transférée, pas la conformité elle-même.
- L'auto-hébergement exige une équipe capable de patcher, sauvegarder, superviser et documenter Postgres en continu. Cette charge ne disparaît jamais : elle change simplement de mains chez un fournisseur externe.
- Un BaaS américain avec option région UE ne résout que la moitié du problème : la nationalité de la société qui l'exploite reste soumise au CLOUD Act, indépendamment de la région choisie.
- Le CTO d'une PME arbitre en général entre build interne, Supabase Cloud, AWS Amplify et une solution souveraine UE : le bon choix dépend surtout de la capacité d'équipe disponible.
- Aurabase couvre les deux modèles : BaaS managé souverain UE (Hetzner, Allemagne et Finlande) ou auto-hébergement via Kubernetes (k3d en local) et Helm, sous licence MIT.
Ce qui distingue vraiment les deux options
Un backend auto-hébergé dans un datacenter européen et un BaaS souverain UE peuvent tous deux cocher les mêmes cases RGPD : localisation UE, société exploitante de droit européen, DPA disponible (côté fournisseur) ou registre interne à jour (côté auto-hébergement). Le RGPD n'a pas de préférence architecturale entre les deux. Ce qui change réellement, c'est qui absorbe la charge opérationnelle au quotidien : patch de sécurité, sauvegarde testée, astreinte, supervision continue.
Le cadre légal complet, RGPD et CLOUD Act, est détaillé dans notre guide backend conforme RGPD et souverain UE. Ce que ce guide ne développe pas en profondeur, c'est le coût opérationnel réel de chaque option pour une équipe qui n'a pas forcément de SRE dédié. C'est l'angle de cet article.
Auto-hébergement : ce qu’une PME doit réellement assumer
Auto-héberger un backend Postgres transfère la responsabilité opérationnelle complète à votre équipe, pas seulement le serveur. Concrètement, quatre tâches reviennent en boucle : appliquer les correctifs de sécurité Postgres dès leur publication, et tester une restauration de sauvegarde régulièrement, pas seulement la programmer. Il faut aussi superviser la disponibilité en continu, ou accepter un délai de réaction plus long, et faire tourner les secrets et clés d'accès selon un calendrier documenté.
Ces tâches ne disparaissent jamais, même en auto-hébergement. Vous restez aussi votre propre sous-traitant technique vis-à-vis de votre hébergeur (Hetzner, OVH, Scaleway ou autre). Un DPA doit exister avec lui, et votre registre des traitements (Art. 30 RGPD) doit documenter cette chaîne. Une PME sans équipe infrastructure dédiée sous-estime souvent ce dernier point.
BaaS souverain UE : ce qui est transféré, ce qui reste à vous
Un BaaS souverain UE transfère le patching, l'infrastructure de sauvegarde et la supervision de disponibilité au fournisseur, sous couvert d'un DPA daté et vérifiable (Art. 28 RGPD). C'est la charge opérationnelle décrite au point précédent qui change de mains, pas la responsabilité juridique.
Le responsable de traitement reste vous, quel que soit le fournisseur choisi (Art. 24 RGPD). Base légale du traitement, minimisation des données collectées, notification de violation à l'autorité de contrôle sous 72 heures (Art. 33 RGPD) : ces décisions restent de votre ressort. Un BaaS souverain UE raccourcit le temps nécessaire pour produire une preuve de conformité à un DPO ou un client. Il ne supprime pas votre obligation d'en avoir une.
Le troisième choix qu’on oublie souvent : un BaaS américain, région UE
Beaucoup d'équipes comparent seulement deux options alors qu'une troisième pèse dans leur arbitrage réel : un hyperscaler ou un BaaS de droit américain, configuré sur une région européenne. AWS Amplify avec une région eu-west-1, ou un service équivalent, réduit la latence et répond à des critères de résidence des données. Mais cela ne change pas la nationalité de la société qui l'exploite.
Une société de droit américain reste soumise au CLOUD Act, indépendamment de la région choisie par ses clients. Ce point est développé en détail dans notre guide backend conforme RGPD et souverain UE et dans notre article dédié pourquoi le CLOUD Act change le choix de votre BaaS. Il compte dans l'arbitrage d'une PME, même quand cette option paraît la plus simple à court terme.
Auto-hébergement, BaaS américain en région UE, BaaS souverain UE : comparaison
Voici les trois options réellement disponibles pour une PME aujourd'hui, comparées sur les critères qui pèsent le plus dans une décision d'architecture, pas seulement sur la case région cochée.
| Critère | Auto-hébergement UE | BaaS américain, région UE | BaaS souverain UE |
|---|---|---|---|
| Conformité RGPD sur le papier | Oui, si documentée en interne | Oui, si documentée | Oui, si documentée |
| Exposition CLOUD Act | Nulle (pas de société tierce US) | Réelle (société mère américaine) | Nulle (société mère UE) |
| Charge de patching et d’astreinte | Intégrale, portée en interne | Transférée au fournisseur | Transférée au fournisseur |
| Preuve de conformité disponible | Registre interne à maintenir soi-même | DPA fournisseur, cadre US | DPA fournisseur, daté et vérifiable |
| Équipe infrastructure requise | SRE/ops dédié recommandé | Développeur seul, généralement suffisant | Développeur seul, généralement suffisant |
| Vélocité de mise en production | Plus lente, infrastructure à monter | Rapide | Rapide |
Le coût que l’auto-hébergement ne met jamais sur la facture
Le vrai coût de l'auto-hébergement ne se lit pas sur la facture du serveur. Il se lit dans le temps d'ingénieur détourné du produit, et dans l'exposition juridique directe en cas d'incident.
Une PME en auto-hébergement devient à la fois responsable de traitement et son propre sous-traitant technique. Un correctif Postgres manqué ou une sauvegarde jamais testée devient directement imputable au responsable de traitement lui-même (Art. 83 RGPD), sans chaîne contractuelle de DPA à opposer pour documenter la diligence. Chez un fournisseur BaaS souverain UE, la même défaillance reste une exposition réelle. Mais elle s'inscrit dans un contrat daté qu'un DPO ou un auditeur peut vérifier en quelques minutes, plutôt que dans un historique interne à reconstituer.
Quand l’auto-hébergement reste le bon choix
L'auto-hébergement reste pertinent pour une ETI ou un grand compte qui dispose déjà d'une équipe SRE/ops et d'une astreinte fonctionnelle. Il l'est aussi pour un secteur où la souveraineté ne tolère aucune chaîne de sous-traitance externe : secteur public, défense, certains établissements de santé. Le contrôle direct du serveur physique y prime sur la vélocité de mise en production.
Une entreprise qui a déjà investi dans une infrastructure Kubernetes ou Postgres en interne, avec les compétences pour la maintenir, amortit ce choix plus facilement qu'une PME qui partirait de zéro.
Quand un BaaS souverain UE est le bon choix
Un BaaS souverain UE est le bon choix pour une PME sans équipe infrastructure dédiée, qui doit prouver sa conformité rapidement à un client ou à un DPO. Elle préfère alors consacrer son temps d'ingénieur au produit plutôt qu'au patching Postgres. C'est aussi le choix pertinent pour une équipe qui priorise la vélocité de mise en production sur le contrôle total de la pile.
Vous dépendez d'un fournisseur pour la disponibilité, et votre marge de négociation contractuelle dépend de sa taille et de sa maturité. Vérifiez sa checklist de conformité avant de signer, pas seulement sa promesse commerciale.
Aurabase : les deux modèles sous le même cœur Postgres
Aurabase ne fige pas ce choix dans un seul sens. La plateforme existe en BaaS managé souverain UE, infrastructure de production vérifiée en Allemagne (Nuremberg, Falkenstein) et en Finlande (Helsinki) via Hetzner, exploitée par Aurabase SAS, société de droit français. Elle existe aussi en auto-hébergement : le dépôt fournit un cluster Kubernetes local (k3d) lancé via ./start.sh, et un chart Helm complet pour Kubernetes, le tout sous licence MIT.
Le même moteur PostgreSQL 16, les mêmes policies RLS et le même SDK s'appliquent des deux côtés : migrer d'un modèle vers l'autre ne demande pas de réécrire votre schéma. Pour une comparaison de ce mode auto-hébergé face à d'autres backends Rust-natifs mono-binaires (sh0.dev, TrailBase), notre article Auto-hébergement souverain : Aurabase face aux BaaS Rust-natifs creuse cet angle architectural en détail. Celui-ci reste centré sur la décision RGPD.
Checklist rapide avant de trancher
Quatre questions opérationnelles à vous poser avant de choisir, en complément de la checklist de vérification fournisseur de notre guide RGPD.
| 01 | Avez-vous une astreinte capable de patcher un CVE Postgres critique un week-end ? |
|---|---|
| 02 | Votre dernière restauration de sauvegarde a-t-elle été testée, pas seulement programmée ? |
| 03 | Pouvez-vous produire un DPA à jour pour chaque sous-traitant technique que vous utilisez vous-même ? |
| 04 | Un DPO ou un client peut-il obtenir une preuve de conformité en moins d’une semaine ? |
Pour la checklist complète de vérification d'un fournisseur, questions juridiques incluses, voir notre checklist de conformité RGPD pour un BaaS. Pour la posture de sécurité technique associée, voir la page Sécurité Aurabase.