Data residency EU : comment l'architecturer sans doubler la facture cloud

Un client nous a récemment présenté un devis de son fournisseur cloud : +73 % de coûts annuels pour migrer l'ensemble de l'infrastructure vers des régions EU et satisfaire les exigences de data residency. Le problème n'était pas la réglementation. C'était l'architecture.

Le malentendu fondamental

La data residency EU ne signifie pas « tout en Europe ». Elle signifie que les données personnelles et sensibles des citoyens de l'UE ne peuvent pas être traitées ou stockées de manière persistante hors des frontières de l'UE sans garanties adéquates (Schrems II, RGPD Art. 44-49).

La plupart des entreprises interprètent cette exigence comme : migrer chaque composant applicatif en EU. Résultat : une duplication complète du stack sur des régions EU, une latence dégradée pour les utilisateurs hors-EU, des coûts d'infrastructure doublés, et aucun avantage compétitif réel.

Ce qui doit vraiment être en EU (et ce qui n'a pas à l'être)

La première étape est une classification des données rigoureuse. Toutes les données ne sont pas équivalentes sous le RGPD.

| Catégorie | Exemple | Contrainte de résidence | |---|---|---| | Données personnelles identifiantes | Nom, email, numéro fiscal | Oui, stockage persistant EU | | Données pseudonymisées | UUID, token | Selon la réversibilité | | Données agrégées/anonymisées | Analytics agrégées | Non | | Métadonnées techniques | Logs infra sans PII | Non | | Données métier génériques | SKU produit, prix | Non |

Si votre base de données principale contient une table users avec des PII et une table products avec le catalogue, vous n'avez pas besoin de migrer toute la base en EU. Il faut séparer les deux domaines.

Patterns architecturaux concrets

1. Sharding de base de données par résidence

Le pattern le plus direct pour les applications multi-région est d'isoler le stockage des données personnelles dans un cluster EU dédié, en maintenant le reste sur des régions moins coûteuses et plus performantes.

# Exemple : deux chaînes de connexion dans la configuration applicative
databases:
  core_business:
    host: db-us-east-1.internal
    region: us-east-1
    contains_pii: false
  user_profiles:
    host: db-eu-west-1.internal
    region: eu-west-1
    contains_pii: true
    encryption_at_rest: AES-256
    backup_region: eu-central-1

L'application résout toujours les données utilisateur vers le cluster EU. Le reste tourne sur la région la plus économique. La complexité supplémentaire est réelle mais limitée : une abstraction de type repository pattern gère le routage.

2. Tokenisation des PII dans les pipelines de données

Pour les pipelines analytics, ML ou événements (Kafka, Kinesis), les PII ne doivent jamais entrer dans le flux brut. On tokenise en amont, on traite les tokens, les données réelles restent en EU.

# Pseudocode : tokenisation avant envoi vers un pipeline hors-EU
def emit_event(user_id: str, event: dict) -> None:
    token = tokenizer.get_or_create(user_id)  # appel au vault EU
    sanitized_event = {
        **event,
        "user_id": token,           # token opaque, non réversible sans vault EU
        "email": None,              # PII explicitement supprimé
        "ip_address": mask_ip(event.get("ip_address")),  # pseudonymisation
    }
    kafka_producer.send("events", sanitized_event)  # n'importe quelle région

Le vault de tokenisation réside en EU. Le reste du pipeline peut tourner n'importe où.

3. CDN et edge : attention aux logs

Beaucoup d'équipes ne pensent pas aux logs CDN (Cloudflare, Fastly, CloudFront) qui contiennent les IPs des utilisateurs — des PII au sens du RGPD. Si ces logs sont écrits sur S3 en us-east-1 sans configuration explicite, on viole la résidence.

Solution : activer le forwarding des logs vers un bucket EU et configurer une rétention courte (7-30 jours) pour les logs bruts. Les logs agrégés (métriques, percentiles) peuvent aller n'importe où.

# Terraform : bucket S3 EU pour les logs CDN
resource "aws_s3_bucket" "cdn_logs_eu" {
  bucket = "company-cdn-logs-eu"
  
  # Force la région EU
  provider = aws.eu-west-1
}

resource "aws_s3_bucket_lifecycle_configuration" "cdn_logs_eu" {
  bucket = aws_s3_bucket.cdn_logs_eu.id
  rule {
    id     = "expire-raw-logs"
    status = "Enabled"
    expiration { days = 14 }
  }
}

Combien peut-on réellement économiser

Revenons au client avec le +73 % : après la classification des données et l'application des patterns ci-dessus, le delta réel s'est établi à +18 % par rapport à la configuration d'origine. La majorité du workload continuait à tourner sur des régions US moins coûteuses. Seulement 15-20 % des données étaient réellement des PII nécessitant un stockage EU.

Les principaux coûts supplémentaires, par ordre d'importance :

Transfert de données inter-régions : minimisable avec un caching agressif et une conception réduisant les allers-retours EU↔US dans le chemin critique.
Double sauvegarde : uniquement pour les clusters EU, pas pour l'ensemble du stack.
Complexité opérationnelle : le coût caché. Monitoring, runbooks, on-call doivent couvrir plusieurs régions. On y répond par l'automatisation, pas par des effectifs supplémentaires.

Points opérationnels à retenir

Classifiez les données avant de toucher à l'infrastructure. Sans savoir ce qui est PII ou non, toute décision architecturale est une approximation.
Séparez les domaines de stockage. Une base de données monolithique mélangeant PII et données métier est le problème le plus courant — et le plus coûteux à corriger après coup.
Tokenisez aux frontières du système. Toute donnée traversant une boundary (API externe, pipeline, CDN) doit être débarrassée de ses PII avant de sortir du périmètre EU.
C'est un problème de design, pas un problème juridique. Le RGPD ne dicte pas comment construire les systèmes. Il précise ce qu'il faut protéger. L'architecture reste un choix technique.

---

Si vous envisagez une révision de votre infrastructure cloud avec des contraintes de résidence des données, l'équipe d'Evviva Group peut vous accompagner dans l'assessment et la conception architecturale.