Résidence des données UE pour les outils marketing : ce que votre DPO demande vraiment

J'ai revu beaucoup de questionnaires de sécurité qui s'ouvrent sur la même case à cocher : « Les données client sont-elles hébergées dans l'UE ? Oui / Non. » Le fournisseur coche Oui. Le DPO signe la revue. Six mois plus tard, le même DPO remarque que chaque événement de clic transite par un Meta Pixel hébergé aux US et une instance HubSpot domiciliée en Californie, qui se déclenchent tous les deux dans le navigateur de l'utilisateur avant que l'edge UE d'Elido ne voie jamais la requête.

La case à cocher était honnête. La réponse était aussi incomplète. « Hébergé UE » sur la page d'accueil d'un fournisseur décrit où se trouvent les serveurs propres de la plateforme. Elle ne dit rien sur ce que fait la couche marketing attachée à cette plateforme avec les données, ni où elles vont, ni quelle base légale couvre le transfert. Ce sont les questions qu'un DPO qui a lu l'article 3 du RGPD et Schrems II pose vraiment.

Ce billet est la version marketeur-rencontre-DPO de cette conversation. Où commence et s'arrête la résidence des données UE quand vous faites tourner du tracking de liens et du forwarding de conversion ? Qu'est-ce qui change légalement quand vous passez des pixels côté client aux API de conversion côté serveur ? Et que devrait vraiment dire la checklist d'achats ?

Le billet compagnon - RGPD pour les raccourcisseurs d'URL - couvre les obligations au niveau article en entier. Je le référencerai là où c'est pertinent plutôt que de répéter.

TL;DR#

• « Hébergé UE » couvre le plan de données de votre fournisseur. Cela ne couvre pas les scripts marketing côté client qui se déclenchent dans les navigateurs de vos utilisateurs avant que la redirection ne se produise.
• Schrems II et les articles 44-49 du RGPD imposent de vraies exigences sur les données qui circulent vers les plateformes publicitaires et d'analytique hébergées aux US. Le forwarding de conversion côté serveur déplace le transfert vers la couche serveur-à-serveur mais n'élimine pas l'obligation de transfert.
• L'article 28(2) exige une liste écrite de sous-traitants. Cinq sous-traitants avec des régions nommées est auditable ; quarante avec des entrées vagues est une responsabilité.
• La checklist d'achats qui suit clôt la plupart des questions du DPO en un seul appel de découverte.

La pile juridique en langage clair#

Quatre morceaux de droit font la majeure partie du travail ici. Vous pouvez les citer sans un diplôme de droit ; les numéros d'article sont courts.

Article 3 du RGPD - portée territoriale. L'article 3(2) applique le RGPD à tout traitement de données de sujets UE par un responsable du traitement ou sous-traitant établi hors UE, quand le traitement se rapporte à l'offre de biens ou services aux sujets UE ou au suivi de leur comportement. « Suivre leur comportement » est du tracking de clics. Un fournisseur d'analytique hébergé aux US sans entité UE traite des données personnelles de sujets UE chaque fois que votre lien déclenche son pixel. L'article 3 dit que le RGPD s'applique à ce fournisseur quelle que soit son implantation. La question de résidence concerne où vont les données après que l'obligation de traitement s'est déjà attachée.

Article 28 du RGPD - obligations du sous-traitant. L'article 28 régit le contrat entre le responsable du traitement et chaque sous-traitant dans la chaîne. Votre plateforme de raccourcissement de liens, votre outil d'analytique, votre fournisseur d'email - chacun doit signer un DPA qui couvre les huit obligations (a) à (h). Un fournisseur qui ne fournit pas de DPA pré-signé vous demande d'absorber son risque de conformité. Le sous-paragraphe (2) exige spécifiquement que le sous-traitant obtienne l'autorisation du responsable du traitement avant d'engager des sous-traitants, et impose des obligations équivalentes à ces sous-traitants par contrat.

Articles 44-49 du RGPD - transferts vers pays tiers. Le chapitre V du RGPD interdit de transférer des données personnelles vers un pays tiers sauf si l'un des mécanismes listés s'applique : une décision d'adéquation, les Clauses Contractuelles Types, les Règles d'Entreprise Contraignantes, ou les dérogations de l'article 49. Pour les transferts vers les plateformes hébergées aux US, le mécanisme par défaut depuis l'adoption du DPF UE-US en 2023 est les CCT complétées par la certification DPF - ou le Data Privacy Framework UE-US lui-même là où le destinataire US est certifié. Aucun des deux mécanismes n'élimine l'exigence de transfert ; ils décrivent comment la satisfaire.

Schrems II - CJUE C-311/18. L'arrêt Schrems II a invalidé le Privacy Shield en juillet 2020 et établi que les transferts basés sur CCT nécessitent une Évaluation d'Impact des Transferts évaluant si le droit de surveillance du pays de destination priverait les sujets UE de voies de recours effectives. La charge TIA est réelle et continue. Le Data Privacy Framework UE-US, adopté via décision d'adéquation de la Commission en 2023, fournit un mécanisme actuel pour les destinataires US certifiés DPF, mais il fait l'objet de contentieux en cours - NOYB a signalé l'intention de contester, et les recommandations sur les mesures supplémentaires du CEPD (01/2020) restent des orientations pertinentes pour les équipes qui veulent un régime de transfert robuste au prochain arrêt Schrems. Les acheteurs des secteurs régulés contractent de plus en plus pour un traitement UE-seulement comme couverture structurelle contre le changement de régime juridique.

Là où l'analytique marketing fuit typiquement la résidence UE#

L'écart entre « notre raccourcisseur est hébergé UE » et « nos données restent dans l'UE » s'ouvre à la couche marketing côté client. Six points de fuite courants.

Meta Pixel (côté client). L'implémentation standard du pixel déclenche une requête GET du navigateur de l'utilisateur vers connect.facebook.net, un point CDN servi par l'infrastructure US de Meta. Cette requête contient l'URL complète - y compris vos paramètres UTM - plus l'IP de l'utilisateur, les identifiants cookies et l'empreinte du navigateur. Elle quitte le territoire UE dans le navigateur de l'utilisateur avant que votre serveur ne traite le clic. Meta est constituée en Irlande pour les besoins UE et revendique une base légale pour le transfert sous CCT. Cette revendication fait l'objet de deux décisions DPA substantielles (la décision DPA irlandais Facebook Ireland de 2022, et l'ordonnance d'exécution des CCT de 2023). Le pixel lui-même envoie toujours des données aux serveurs US ; la base légale est contestée.

Google Tag / GA4 (côté client). Le snippet gtag.js se déclenche depuis le navigateur de l'utilisateur vers google-analytics.com et analytics.google.com, qui résolvent tous deux vers des serveurs Google basés aux US sauf si vous avez configuré le routage UE de Google Analytics 4 avec data_collection_endpoint pointé sur region1.google-analytics.com. Même avec l'endpoint UE, Google documente qu'une partie du traitement se produit dans l'infrastructure US. L'implémentation par défaut est sans ambiguïté : côté navigateur, hébergée aux US.

CRM Salesforce. La résidence des données de Salesforce Marketing Cloud dépend du pod sur lequel se trouve votre tenant. Les clients UE sur des pods UE traitent les données d'attribution d'événements de clic dans l'UE - si vous avez configuré cela explicitement. Le pod US par défaut est hébergé aux US. La plupart des équipes que je vois en SMB-à-mid-market n'ont pas fait cette configuration ; elles ont une instance Salesforce qui a été provisionnée par un admin basé aux US sur un pod US et qui route les données CRM de sujets UE à travers l'Atlantique depuis lors.

HubSpot. Les pixels de tracking d'email de HubSpot sont servis depuis l'infrastructure HubSpot aux US. La résidence des données UE est disponible comme add-on pour les clients Enterprise ; ce n'est pas le défaut. Le pixel de tracking qui se déclenche quand un contact ouvre un email marketing envoie, dans la configuration par défaut, l'identifiant d'un sujet UE (l'adresse email, encodée dans l'URL du pixel) à un endpoint US.

Tracking d'ouverture d'email tiers. Au-delà de HubSpot - Mailchimp, Brevo, Customer.io, ActiveCampaign - le même schéma s'applique. Les URL de pixels de tracking sont hébergées sur le CDN du fournisseur ; la plupart des CDN défaut sur des PoP US pour le trafic d'origine ; le pixel se déclenchant depuis le client email d'un utilisateur UE route vers l'infrastructure US. Des options région UE existent sur certains plans ; ce ne sont pas les défauts.

Le raccourcisseur lui-même comme transit. Là où un raccourcisseur n'est pas hébergé UE, la requête de redirection passe par une infrastructure non-UE. L'événement de clic est journalisé hors EEE. C'est la couche de résidence que la case « raccourcisseur hébergé UE » est censée adresser - et c'est la plus petite des six fuites, parce que la redirection est typiquement un événement de 2-5ms et le log de clics est la seule donnée persistante que le raccourcisseur crée.

L'exposition typique pour une équipe marketing mid-market faisant tourner des outils standards : trois à cinq des scénarios ci-dessus actifs simultanément, sans Évaluation d'Impact des Transferts en place pour aucun d'eux, et une entrée Article 30 Registre des Activités de Traitement qui nomme « Google Analytics, Meta Pixel » sans documenter quel mécanisme couvre le transfert.

Le correctif côté serveur : ce qui change légalement, ce qui ne change pas#

Le forwarding de conversion côté serveur - où l'edge UE du raccourcisseur forwarde les événements de clic et de conversion à l'API côté serveur de la plateforme publicitaire plutôt que de laisser le navigateur de l'utilisateur déclencher le pixel - est le correctif partiel. Voici ce qui change et ce que cela laisse inchangé.

Ce qui change : le navigateur de l'utilisateur n'envoie plus de données à l'endpoint US directement. Le chemin de requête est :

1. L'utilisateur clique sur le lien court
2. L'edge UE d'Elido (la région UE) reçoit la requête, journalise l'événement de clic localement
3. L'edge UE d'Elido forwarde le signal de conversion serveur-à-serveur vers Meta CAPI / GA4 Measurement Protocol
4. La plateforme publicitaire reçoit l'événement sur son serveur US

L'API Meta Conversions est l'implémentation canonique de ce pattern pour Meta. GA4 Measurement Protocol est l'équivalent Google. Le navigateur de l'utilisateur ne touche que l'edge UE d'Elido ; il ne contacte jamais directement un endpoint d'analytique US.

Ce qui ne change pas : les données sont toujours transférées à un sous-traitant hébergé US. L'edge UE d'Elido origine ce transfert. L'obligation de transfert sous les articles 44-49 s'applique toujours - vous avez toujours besoin des CCT ou de la couverture DPF pour la jambe Meta ou Google de la chaîne. Ce qui change, c'est le contrôle pratique du responsable du traitement sur ce transfert : il se produit sur un serveur que vous opérez, en utilisant des identifiants que vous gérez, avec le hachage d'identifiant que vous appliquez (SHA-256 sur les adresses email, comme Meta CAPI l'exige), plutôt que dans un script de navigateur que vous avez une capacité limitée à auditer ou contrôler.

C'est une amélioration matérielle du point de vue de la minimisation des données et de la sécurité. Ce n'est pas une exemption complète du régime de transfert. Votre DPO doit être clair sur cette distinction avant de signer la revue d'achat.

La conséquence juridique du forwarding côté serveur : votre entrée Article 30 RoPA pour « Meta CAPI » documente maintenant un transfert serveur-à-serveur sous votre contrôle, avec des identifiants hachés avant de quitter l'infrastructure UE. C'est une entrée substantiellement plus propre que « Meta Pixel - côté client, origine navigateur, base de transfert à déterminer ». Ce n'est pas zéro-transfert ; c'est un transfert documenté et contrôlé.

Article 28(2) : pourquoi le compte de sous-traitants compte#

L'article 28(2) exige que le sous-traitant obtienne l'autorisation préalable du responsable du traitement avant d'engager des sous-traitants, soit spécifique (par fournisseur) soit générale (basée sur notification avec droit d'opposition). Chaque contrat SaaS sérieux utilise l'autorisation préalable générale avec une fenêtre de préavis de 30 jours. Le responsable du traitement signe le DPA ; le DPA inclut une liste de sous-traitants ; les ajouts à la liste déclenchent une notification et une fenêtre d'objection de 30 jours.

La liste de sous-traitants est l'artefact que votre DPO va vraiment lire. Ce qu'inclut une liste utilisable :

• Nom du sous-traitant
• Lieu du traitement de données (région hyperscaler, pas juste pays)
• Rôle dans la chaîne de traitement
• Catégories de données personnelles partagées
• Base légale pour tout transfert vers pays tiers
• Date d'ajout
• Canal de notification pour les futurs ajouts

La liste est aussi un signal sur la façon dont le fournisseur pense à la résidence. Un fournisseur avec cinq sous-traitants dont vous pouvez nommer les régions en une phrase a conçu pour cela. Un fournisseur avec quarante sous-traitants dont les entrées se lisent « diverses régions globales » non.

La liste de sous-traitants d'Elido couvre cinq fournisseurs - couvrant le compute et l'infrastructure UE, l'email UE, les paiements et le CDN - publiée sur /legal/subprocessors. Ce nombre est petit par intention. Chaque sous-traitant ajoute à la surface du programme de confidentialité du responsable du traitement ; chaque ajout de sous-traitant déclenche un cycle de notification et une fenêtre d'objection potentielle. Un fournisseur qui peut faire tourner un raccourcisseur de qualité production sur cinq sous-traitants a fait des choix explicites sur les dépendances tierces qui sont justifiées.

Comparez cela à une plateforme d'analytique marketing avec 35-40 sous-traitants. La liste est auditable en principe ; en pratique, le responsable confidentialité du responsable du traitement revoit quarante DPA et quarante Évaluations d'Impact des Transferts, dont certaines manqueront. Le nombre de cinq fournisseurs n'est pas une revendication marketing. C'est un choix opérationnel avec de vraies conséquences pour votre charge de conformité.

La checklist d'achats du marketeur#

Huit questions. Réponses écrites. Si un fournisseur peut fournir cela lors du premier appel de découverte, le cycle d'achat raccourcit de plusieurs semaines. S'il ne peut pas, cela vous dit quelque chose.

1. Quelle est la région d'hébergement spécifique pour les nouvelles données client, nommée au niveau de la région hyperscaler ? (Réponse attendue : une région UE nommée - par exemple « AWS eu-central-1 » ou une région de datacenter UE équivalente, pas seulement « l'UE » comme revendication non étayée.)
2. La région d'hébergement UE est-elle contractuellement engagée dans le contrat client standard, ou est-ce une pratique opérationnelle que le fournisseur peut changer sans préavis ? (Réponse attendue : contractuellement contraignant, spécifique au contrat standard, pas d'avenant sur mesure requis.)
3. Le contrat standard inclut-il un DPA pré-signé couvrant les obligations de l'article 28 (a) à (h) ? (Réponse attendue : oui, pré-signé, disponible avant la fin de l'appel commercial.)
4. Combien de sous-traitants y a-t-il dans la chaîne de traitement standard ? Le fournisseur peut-il les nommer tous avec leurs régions de traitement de données ? (Réponse attendue : la liste complète, nommée, avec régions, disponible publiquement à une URL que vous pouvez lier dans votre RoPA.)
5. Le fournisseur utilise-t-il le forwarding de conversion côté serveur vers les plateformes publicitaires, ou le tracking de conversion est-il côté client dans le navigateur de l'utilisateur ? (Réponse attendue pour un fournisseur orienté confidentialité : côté serveur, avec hachage d'identifiant avant que les données ne quittent l'infrastructure UE.)
6. Quel est le défaut de troncature d'IP pour le logging d'événement de clic ? (Réponse attendue : troncature /24 pour IPv4, /48 pour IPv6, avant persistance - c'est-à-dire l'IP complète n'est pas stockée.)
7. Quel est le SLA d'effacement des sujets de données, et est-il opérationnellement atteignable sur le store d'événements de clic ? (Réponse attendue : 30 jours ou moins, propagé au datastore analytique, confirmé par webhook ou certificat.)
8. Quelles attestations de conformité indépendantes le fournisseur détient-il, et quand le dernier audit a-t-il été clos ? (Réponse attendue : ISO 27001 à jour ; SOC 2 Type II complété ou en cours avec une date cible ; pour les charges proches santé, disponibilité du BAA sur le plan pertinent.)

Ces huit questions couvrent les principales préoccupations du DPO sans nécessiter une revue juridique au stade de la découverte. Le fournisseur qui répond aux huit par écrit le jour même est prêt pour les achats. Le fournisseur qui escalade au juridique avant de répondre à la question trois ne l'est pas.

Outillage chez Elido#

Les spécificités, pour référence.

Épingle de région au niveau workspace. Les nouveaux workspaces défaut sur la région UE. Les workspaces Business et Enterprise peuvent épingler sur US Est ou Asie-Pacifique par workspace. L'épingle est appliquée à la couche de routage - ce n'est pas une préférence de dashboard qui peut être surchargée par un changement de configuration sans avenant contractuel au niveau workspace. La page de confiance documente l'infrastructure.

DPA pré-signé. Le DPA Article 28 est inclus dans le contrat client standard. Aucune négociation sur mesure n'est requise pour les acheteurs UE qui ont besoin de la couverture Article 28 standard. Les contrats Enterprise avec des droits d'audit supplémentaires, des fenêtres d'approbation de sous-traitants ou des termes de rétention personnalisés sont négociés séparément. Le DPA standard est disponible sur /legal/dpa.

Liste de sous-traitants. Publiée sur /legal/subprocessors. Cinq fournisseurs. Les ajouts déclenchent une notification email préalable de 30 jours plus un flux RSS pour la surveillance basée sur l'outillage. Le droit d'opposition dans les 30 jours est contractuel, pas administratif.

Forwarding de conversion côté serveur. Les identifiants pour Meta CAPI, GA4 Measurement Protocol et Mixpanel sont enregistrés une fois au niveau workspace. Elido gère le hachage SHA-256 des identifiants avant le POST sortant, la déduplication via le champ event_id, et la logique de retry sur les erreurs amont transitoires. Le transfert est serveur-à-serveur depuis l'infrastructure UE ; le navigateur de l'utilisateur ne contacte pas la plateforme publicitaire directement.

ISO 27001. Certifié. SOC 2 Type II en cours, cible H2 2026. BAA disponibles sur le plan Business pour les déploiements proches santé.

Pour la posture de conformité complète, /solutions/compliance est le résumé à destination de l'équipe d'achat.

Ce que nous ne prétendons pas faire#

Cette section existe parce que « résidence des données UE » est une expression que les fournisseurs utilisent légèrement, et nous ne devrions pas.

Elido est la couche de liens. Un clic routé via l'edge UE d'Elido reste dans l'infrastructure UE à la couche Elido. L'événement de clic est journalisé dans notre entrepôt d'analytique dans la région UE. Le signal de conversion forwardé côté serveur vers Meta CAPI quitte l'infrastructure UE - ce transfert se produit en votre nom, sous votre responsabilité de responsable du traitement, et vous devez le documenter dans votre RoPA et le couvrir avec le mécanisme de transfert approprié.

Si votre organisation exige qu'absolument aucune donnée personnelle sur des sujets UE ne quitte l'EEE en aucune circonstance - y compris la jambe d'attribution de la plateforme publicitaire - la réponse n'est pas un raccourcisseur différent. La réponse est de ne pas envoyer d'événements de conversion aux plateformes publicitaires hébergées aux US du tout. C'est une décision business et marketing, pas une décision technologique.

Ce qu'Elido vous donne : une couche de liens qui traite les données de clic de sujets UE dans l'infrastructure UE par défaut, avec des sous-traitants documentés, un DPA pré-signé, la troncature d'IP, le forwarding de conversion côté serveur avec hachage d'identifiant, et un compte de sous-traitants assez petit pour être audité en un après-midi. Cela couvre l'obligation de résidence de la couche de liens proprement.

Votre plateforme d'email marketing, votre CRM, vos plateformes publicitaires et votre entrepôt d'analytique ont chacun leur propre posture de résidence. Elido n'est pas la réponse pour cela ; nous sommes la réponse pour la couche de redirection et d'attribution de clics, et nous n'allons pas surévaluer la portée.

Le cornerstone RGPD pour les raccourcisseurs d'URL couvre l'image complète des obligations de sous-traitant au niveau article, si vous voulez la rationale de conformité derrière l'une des décisions ci-dessus.

Lire le cluster conformité#

Ce billet est le cornerstone du track résidence du cluster conformité. Billets frères : RGPD pour les raccourcisseurs d'URL (obligations de sous-traitant article par article), et le futur billet Schrems II et pixels de tracking (les conséquences pratiques d'attribution couche navigateur). Pour les artefacts page de confiance et contrats : /trust, /legal/dpa, /legal/subprocessors. Pour le résumé à destination des solutions : /solutions/compliance.