Les transferts de données RGPD sont le seul risque de conformité que l'architecture peut éliminer

La plupart des risques RGPD sont procéduraux : une mention que vous pouvez réécrire, une durée de conservation que vous pouvez raccourcir, un parcours de consentement que vous pouvez corriger. Les transferts internationaux de données sont différents. Ils dépendent d'un instrument juridique que vous ne contrôlez pas et que vous ne pouvez pas corriger, et cet instrument a été invalidé deux fois en une décennie. La seule solution durable est architecturale : ne jamais transférer les données en premier lieu.

Le mécanisme de transfert ne cesse de s'effondrer

Le chapitre V du RGPD interdit l'envoi de données personnelles vers un pays n'offrant pas un niveau de protection adéquat, sauf à disposer d'un mécanisme de transfert valide. Pour les flux UE-États-Unis, ce mécanisme a son cimetière. La CJUE a invalidé le Safe Harbour en 2015 (Schrems I) et le Privacy Shield en 2020 (Schrems II), dans les deux cas parce que le droit américain de la surveillance ne laissait aux citoyens européens aucun recours réel.

L'instrument actuel est le cadre de protection des données UE-États-Unis (DPF), adopté en 2023. Le 3 septembre 2025, le Tribunal de l'Union européenne a rejeté le premier recours formé contre lui, dans l'affaire Latombe v Commission (affaire T-553/23), confirmant la décision d'adéquation de la Commission.

Ce n'est pas la fin de l'histoire. Latombe a formé un pourvoi devant la Cour de justice le 31 octobre 2025, et noyb — l'organisation de Max Schrems — a fait savoir qu'elle prépare un recours plus large contre le DPF sur les mêmes fondements liés à la surveillance qui ont coulé les deux cadres précédents. La juridiction qui a enterré le Safe Harbour et le Privacy Shield va y regarder de nouveau.

Pourquoi cela touche spécifiquement l'analytique

L'analytique est la façon la plus courante pour un petit site européen de finir par opérer un transfert vers les États-Unis sans s'en rendre compte. Le navigateur envoie un événement ; un fournisseur d'analytique dont le siège est aux États-Unis reçoit l'adresse IP du visiteur et ses données comportementales sur une infrastructure américaine. C'est un transfert de données personnelles, et il hérite du statut juridique du DPF à un jour donné.

Les régulateurs traitaient déjà cela comme illicite avant l'existence du DPF. À la suite des plaintes coordonnées de noyb, la DSB autrichienne a jugé en 2022 que les transferts UE-États-Unis via Google Analytics enfreignaient le chapitre V, et les autorités de protection des données de France, d'Italie, du Danemark, de Finlande, de Suède et de Norvège ont suivi avec le même raisonnement. L'adresse IP atteignant des serveurs américains suffisait.

Si la CJUE invalide le DPF, ces décisions redeviennent le modèle, du jour au lendemain, pour tout outil qui achemine encore des données de visiteurs européens vers les États-Unis.

Éliminer le risque par l'architecture

Vous ne pouvez pas rendre le DPF plus stable. Vous pouvez construire un flux de données qui n'a, dès le départ, aucune exposition au chapitre V. Deux propriétés y suffisent :

Traiter à la périphérie, dans la région. La Data Localization Suite de Cloudflare permet à un Worker de confiner le traitement et les journaux aux centres de données européens, de sorte que la requête ne quitte jamais la région où elle a été émise. La décision sur le lieu de traitement des données devient une configuration d'infrastructure, et non un instrument juridique dont vous espérez qu'il survivra au pourvoi.

Ne jamais conserver les entrées identifiantes. L'IP et le User-Agent bruts qui font d'une requête une « donnée personnelle » n'existent en mémoire que le temps de calculer un hash de visiteur quotidien, puis ils sont supprimés :

visitor_hash = SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

Ce qui est stocké, c'est le hash, pas les entrées. Comme le sel change chaque jour et reste secret, le hash ne peut être inversé pour remonter à un individu ni mis en correspondance d'un jour à l'autre. Il n'y a pas de profil, et rien d'identifiant ne franchit jamais de frontière parce que rien d'identifiant n'est jamais conservé.

Vous pouvez vérifier la géographie du flux directement sur le fil. Une balise de page vue est une simple requête vers un point de terminaison de première partie que vous contrôlez :

POST /collect HTTP/2
Host: api.monoid.website
Content-Type: application/json

{"site_id":"...","path":"/pricing","referrer":"..."}

Si api.monoid.website pointe vers des nœuds périphériques européens et que le Worker épingle son stockage dans l'UE, il n'y a aucun sous-traitant américain dans le chemin, aucune décision d'adéquation sur laquelle s'appuyer, et aucun transfert à déclarer. Le pays du visiteur reste connu — dérivé de la géolocalisation de la périphérie elle-même, et non de l'envoi de l'IP à un tiers.

La posture de conformité que cela produit

Un transfert que vous n'opérez jamais est un transfert que vous n'avez jamais à défendre. Il n'y a pas de DPF à citer dans votre registre des traitements, pas de clauses contractuelles types à maintenir, pas d'analyse d'impact sur les transferts à refaire quand le fondement juridique change, et pas de sous-traitant dans un pays tiers à déclarer au titre des règles de transparence que les régulateurs auditent en 2026.

Toute autre tâche de conformité analytique est quelque chose que vous continuez de faire. Éliminer le transfert est quelque chose que vous faites une fois, dans l'architecture, puis dont vous cessez de vous préoccuper — quelle que soit la décision de la CJUE sur le pourvoi.

Sources

• Cour de justice de l'UE — Communiqué de presse : le Tribunal rejette le recours Latombe (affaire T-553/23)
• IAPP — Le Tribunal de l'UE rejette le recours Latombe et confirme le cadre de protection des données UE-États-Unis
• noyb — DSB autrichienne : les transferts de données UE-États-Unis vers Google Analytics sont illégaux
• noyb — D'autres autorités de protection des données européennes ordonnent l'arrêt de Google Analytics
• Cloudflare — Data Localization Suite