Schrems II et les pixels de suivi : où le DPF vous laisse en 2026

En juillet 2020, la CJUE a rendu Schrems II (C-311/18). Privacy Shield, qui avait été le mécanisme par défaut pour les transferts de données UE-USA depuis 2016, était invalidé. Du jour au lendemain, chaque équipe marketing faisant tourner un Meta Pixel ou un Google Tag était soit en train de transférer des données sans mécanisme juridique valide, soit en train de se précipiter pour exécuter des Clauses Contractuelles Types, soit en train de s'appuyer sur l'interprétation optimiste que le RGPD ne s'étendait d'une manière ou d'une autre pas à un extrait JavaScript dans le navigateur d'un utilisateur.

Trois années d'orientations sur les mesures supplémentaires, de modèles d'analyse d'impact sur les transferts et d'actions d'application des autorités de contrôle ont suivi. Puis, en juillet 2023, la Commission européenne a adopté la décision d'adéquation EU-US Data Privacy Framework, restaurant l'adéquation pour les entreprises américaines certifiées DPF. Meta, Google, Salesforce et HubSpot sont tous sur la liste.

La question pour les équipes marketing et conformité en 2026 n'est pas « le DPF existe-t-il » - il existe. La question est ce qu'il couvre réellement, où se situe le risque résiduel, et à quoi ressemble en pratique une architecture de transfert qui tient face à un éventuel défi du DPF.

TL;DR#

• Privacy Shield (2016) a été invalidé par Schrems II en juillet 2020. Les CCT plus mesures supplémentaires ont couvert la brèche de 2020 à 2023.
• L'EU-US Data Privacy Framework (juillet 2023) est la décision d'adéquation actuelle. Les transferts des entreprises certifiées DPF bénéficient de l'adéquation sans nécessiter de CCT ou d'AIT.
• Les pixels côté client vers des fournisseurs certifiés DPF sont juridiquement défendables en 2026, à condition que l'entité réceptrice soit certifiée, que la personne concernée ait été informée et que le consentement ePrivacy soit en place là où requis.
• Le DPF fait l'objet d'un défi juridique anticipé. Le suivi en mode dual - côté client sous couverture DPF, transmission côté serveur depuis l'infrastructure UE comme repli structurel - est l'architecture qui survit à un troisième jugement Schrems.

Ce que Schrems II a vraiment dit#

Le jugement vaut la peine d'être lu directement plutôt que via un résumé. Le raisonnement opératoire se trouve dans les paragraphes 180–202. La conclusion centrale n'est pas que les transferts de données vers les États-Unis sont illégaux en soi. C'est que la loi de surveillance américaine - spécifiquement FISA 702 et l'Executive Order 12333 - donne aux agences de renseignement américaines accès aux données personnelles des sujets UE d'une manière qui n'offre aucun recours effectif à ces sujets au titre des Articles 77–79 du RGPD.

L'Article 44 du RGPD interdit les transferts vers des pays tiers à moins qu'un des mécanismes du Chapitre V ne s'applique. Privacy Shield était une décision d'adéquation au titre de l'Article 45. La conclusion de la Cour selon laquelle Privacy Shield était invalide a donc retiré la base d'adéquation à chaque transfert s'y appuyant.

Les Clauses Contractuelles Types n'ont pas été invalidées - mais la Cour a jugé dans le même arrêt que les CCT ne sont pas automatiquement suffisantes pour les transferts vers les États-Unis. Le responsable du traitement ou le sous-traitant utilisant les CCT doit vérifier, au cas par cas, si le système juridique du pays de destination empêcherait les protections au niveau CCT de fonctionner en pratique. Cette exigence est l'analyse d'impact sur les transferts : une évaluation documentée de la loi de surveillance américaine et de son effet sur les données transférées.

Les Recommandations EDPB 01/2020 sur les mesures supplémentaires ont opérationnalisé cette exigence. Elles fixent un processus en six étapes et un catalogue de mesures supplémentaires - techniques (chiffrement, pseudonymisation), contractuelles et organisationnelles - que les responsables du traitement devraient évaluer lorsqu'ils s'appuient sur les CCT pour des transferts américains. Pour les pixels marketing standard, la plupart de ces mesures techniques étaient pratiquement impossibles : vous ne pouvez pas chiffrer de manière significative une charge utile dont le but est de permettre à Meta d'attribuer une conversion à une impression publicitaire.

C'est l'architecture avec laquelle les équipes marketing ont vécu de juillet 2020 à juillet 2023. Des CCT ont été signées. Des AIT ont été tentées. Des autorités de protection en Autriche, France et Italie ont trouvé que des implémentations spécifiques - Google Analytics en tête - n'étaient pas conformes malgré les CCT, parce que les mesures supplémentaires étaient insuffisantes.

Ce qui a changé avec le Data Privacy Framework#

L'EU-US Data Privacy Framework (Décision (UE) 2023/1795, effective le 10 juillet 2023) est une décision d'adéquation au titre de l'Article 45 du RGPD. Sa prémisse juridique est que le cadre juridique américain - tel qu'amendé par l'Executive Order 14086 du président Biden et les règles subséquentes établissant la Data Protection Review Court - fournit un niveau de protection essentiellement équivalent à celui garanti dans l'UE.

À des fins pratiques, le DPF signifie ceci : les transferts vers des entreprises américaines certifiées DPF bénéficient de l'adéquation. Vous n'avez pas besoin de CCT. Vous n'avez pas besoin d'AIT. Vous devez vérifier que l'entité réceptrice est sur la liste des participants DPF, qui est consultable publiquement et mise à jour en quasi temps réel.

Meta Platforms, Inc. est certifié DPF. Google LLC est certifié DPF. Salesforce, Inc. est certifié DPF. HubSpot, Inc. est certifié DPF. Pour ces fournisseurs, les transferts de données personnelles UE en lien avec la publicité et l'analytique sont couverts par l'adéquation à compter de juillet 2023, à condition qu'ils reçoivent les données dans leur capacité certifiée DPF.

Deux clarifications comptent. Premièrement, la certification DPF est volontaire. Toutes les entreprises américaines qui traitent des données UE ne se sont pas auto-certifiées. La liste des participants est la source faisant autorité ; ne présumez pas la certification. Deuxièmement, la certification DPF couvre des activités spécifiques. Une entreprise certifiée DPF peut traiter les données de votre pixel sous la portée certifiée ou sous une base juridique différente selon le type de données et la finalité. Pour l'attribution marketing standard via pixel, la portée DPF la couvre.

Ce que cela signifie pour les pixels marketing en pratique#

Avec la couverture DPF en place, la posture juridique pour les pixels marketing côté client vers des fournisseurs certifiés ressemble à ceci.

Le Meta Pixel côté client, lorsqu'il se déclenche vers Meta Platforms Inc. (certifié DPF), est un transfert vers une destination adéquate. Le mécanisme de transfert est la décision d'adéquation DPF, pas les CCT. Votre entrée de RoPA Article 30 pour le Meta Pixel documente la base de transfert comme « décision d'adéquation (DPF) » plutôt que « CCT ». L'AIT qui aurait été requise sous le chemin CCT n'est pas requise.

La même analyse s'applique à Google Tag Manager et GA4 se déclenchant vers Google LLC, au pixel de suivi HubSpot se déclenchant vers HubSpot Inc., et aux événements d'attribution Salesforce Marketing Cloud se déclenchant vers Salesforce Inc.

Cependant, l'adéquation est une couche d'un tableau de conformité multi-couches. Trois exigences supplémentaires doivent être en place avant que cette posture ne tienne.

Consentement ePrivacy. La Directive ePrivacy 2002/58/CE, Article 5(3), exige le consentement avant tout stockage ou accès non essentiel sur l'équipement terminal de l'utilisateur. Les pixels marketing sont non essentiels. Les bandeaux de consentement doivent être spécifiques au pixel en question, librement donnés et révocables. Le fait que la destination de transfert soit DPF-adéquate n'affecte pas l'exigence de consentement ePrivacy. Ce sont des instruments juridiques distincts.

Transparence envers les personnes concernées. L'Article 13 du RGPD exige que le responsable du traitement informe les personnes concernées, au moment de la collecte, des destinataires de leurs données et de tout transfert vers des pays tiers. Le DPF ne change pas cette obligation de transparence. Si votre avis de confidentialité dit « nous utilisons Meta Pixel » et « les transferts vers les États-Unis sont couverts par l'adéquation », c'est suffisant. S'il ne mentionne pas du tout le transfert américain, la décision d'adéquation ne soigne pas l'écart Article 13.

DPA Article 28 avec le fournisseur. Le fournisseur de pixel reste un sous-traitant au titre de l'Article 28 du RGPD. Le DPF couvre le mécanisme de transfert ; il ne se substitue pas au DPA. Les conditions standard de traitement de données de Meta, Google et HubSpot sont les instruments Article 28 pour la relation pixel. Assurez-vous qu'ils sont exécutés.

Les risques restants#

Le DPF n'est pas un règlement permanent. C'est une décision d'adéquation qui peut être contestée devant la CJUE par toute juridiction d'État membre, le Parlement européen, ou toute autorité de contrôle nationale. Max Schrems et NOYB ont publiquement signalé leur intention de contester le DPF - un potentiel Schrems III. La théorie juridique pour ce défi est similaire à Schrems II : que l'EO 14086 et la Data Protection Review Court ne fournissent pas, en substance, de recours équivalents à ceux disponibles au titre du droit UE.

Les autorités de contrôle n'ont pas attendu un arrêt CJUE. La DSB autrichienne a jugé sur une implémentation Google Analytics aussi récemment qu'en 2022 - avant que le DPF ne soit en vigueur - que le transfert était illégal parce que les CCT et mesures supplémentaires en place étaient insuffisantes. La CNIL française et le Garante italien ont émis des conclusions similaires. Ces décisions étaient sous le régime pré-DPF, mais elles établissent un pattern de contrôle : les APD sont prêtes à examiner les mécaniques techniques des transferts basés sur pixel, pas seulement la paperasse contractuelle. Une future décision sous un défi post-DPF examinerait probablement si l'ordre juridique établi par l'EO 14086 limite réellement l'accès FISA 702 aux données stockées d'entreprises certifiées.

La préoccupation spécifique avec les pixels de suivi va au-delà du mécanisme juridique. Un pixel côté client fait plus que transférer des données à une entreprise certifiée. Il exécute du JavaScript dans le navigateur de l'utilisateur, définit des cookies propriétaires et tiers dans le contexte du domaine du pixel, et envoie des données directement depuis le navigateur. Les données qui quittent le navigateur sont hors de votre contrôle - vous ne pouvez pas appliquer le hachage d'identifiants avant qu'elles ne partent, vous ne pouvez pas limiter quels champs sont remplis, et vous ne pouvez pas vérifier ce que le pixel envoie réellement à l'exécution sans une inspection réseau. L'adéquation DPF couvre la destination ; elle ne traite pas de ce que le pixel collecte avant le transfert.

Cette combinaison - défi juridique potentiel du DPF, contrôle des mécaniques par les autorités de contrôle plutôt que de la seule paperasse, et limites structurelles sur ce qu'un responsable du traitement peut vérifier sur le comportement du pixel côté client - est pourquoi une stratégie mono-piste côté client reste architecturalement fragile.

La posture pratique : suivi en mode dual#

L'architecture qui tient sous DPF et sous une invalidation potentielle du DPF est en mode dual.

Le premier mode est les pixels côté client vers des fournisseurs certifiés DPF, opérant sous l'adéquation actuelle avec consentement ePrivacy en place. Cela fournit le signal d'attribution le plus large aussi longtemps que le DPF tient. Pour la plupart des équipes marketing, c'est le mode qui remplit vos tableaux de bord d'attribution aujourd'hui.

Le second mode est la transmission de conversion côté serveur depuis l'infrastructure UE. Lorsqu'un utilisateur clique sur un lien, le edge en région UE d'Elido reçoit le clic, le journalise dans l'infrastructure d'analytique UE, et transmet le signal de conversion serveur à serveur à l'API de conversion de la plateforme publicitaire - Meta CAPI, GA4 Measurement Protocol, ou équivalent. Le navigateur de l'utilisateur ne contacte pas l'endpoint américain. Les données quittant l'infrastructure UE ont été hachées (SHA-256 sur les adresses email et numéros de téléphone, comme Meta CAPI l'exige), et le transfert provient d'une infrastructure sous votre contrôle plutôt que de code tournant dans le navigateur de l'utilisateur.

Si le DPF est invalidé, le pixel côté client devient un mécanisme de transfert non conforme jusqu'à ce qu'un cadre de remplacement soit en place. Le chemin côté serveur, tournant via les CCT avec des mesures supplémentaires appliquées - chiffré en transit, identifiant haché avant le départ, étroitement délimité au signal d'attribution - est le repli que votre équipe juridique peut défendre avec une AIT cohérente. Parce que le chemin côté serveur traite les données dans l'infrastructure UE d'abord, le transfert peut être documenté comme responsable du traitement vers sous-traitant plutôt que comme transfert direct navigateur vers endpoint américain.

Là où disponible, préférez l'endpoint UE du fournisseur. GA4 avec data_collection_endpoint pointé vers region1.google-analytics.com garde plus du traitement dans l'infrastructure UE de Google, même si une partie du traitement se produit toujours dans l'infrastructure américaine selon la propre documentation de Google. Meta CAPI n'offre pas actuellement d'endpoint en région UE ; le transfert serveur à serveur est lié aux États-Unis quoi qu'il en soit. La mesure supplémentaire est le hachage d'identifiants, pas la géographie de l'endpoint.

Pour les mécaniques complètes du chemin de transmission côté serveur et de son intégration avec l'attribution de clic de lien court, l'attribution sans cookies expliquée couvre l'architecture technique. Pour le tableau plus large de la résidence UE - où commence et s'arrête « hébergé UE » dans une pile d'outils marketing - la résidence des données UE pour le marketing est l'article compagnon.

Consentement des sous-traitants sous DPF#

Chaque fournisseur de pixel certifié DPF reste un sous-traitant au titre de l'Article 28 du RGPD. La décision d'adéquation DPF couvre le mécanisme de transfert ; elle ne dit rien des obligations de sous-traitance qui s'appliquent en parallèle.

Cela signifie que le responsable du traitement a besoin d'un Data Processing Agreement en place avec chaque fournisseur de pixel, couvrant les obligations Article 28(3)(a)-(h). Les conditions standard de données publicitaires de Meta, l'addendum de traitement de données de Google et le DPA de HubSpot sont les instruments ici. Ils sont pré-signés et incorporés par référence lorsque vous acceptez les conditions de service du fournisseur ; la question est de savoir si vous avez documenté cet accord dans vos registres de conformité.

La liste des sous-traitants que votre DPO demandera couvre ces fournisseurs. Chaque fournisseur de pixel devient un sous-traitant dans la chaîne d'attribution entre votre plateforme de suivi de liens et la plateforme publicitaire. La liste publique de sous-traitants d'Elido nomme ses cinq fournisseurs ; les fournisseurs de pixel sont des sous-traitants au niveau du responsable du traitement, pas au niveau Elido. Votre RoPA Article 30 devrait les énumérer séparément.

Une nuance : l'Article 28(2) du RGPD exige que le sous-traitant obtienne l'autorisation du responsable du traitement avant d'engager des sous-traitants ultérieurs. Pour la relation pixel, vous êtes le responsable du traitement engageant Meta ou Google directement - c'est une relation responsable du traitement à sous-traitant, pas une relation de sous-traitant chaîné à travers Elido. Le DPA Article 28 est entre vous et le fournisseur de pixel. La jambe de transmission côté serveur - où le edge d'Elido transmet les événements à Meta CAPI pour votre compte - est une relation de sous-traitant : Elido est le sous-traitant, Meta CAPI est le sous-traitant ultérieur, et l'obligation DPA passe par le DPA standard d'Elido.

Cette distinction compte pour votre RoPA. Une équipe de conformité DPA examinant vos registres veut voir deux entrées distinctes : une pour la relation sous-traitant Elido (couvrant les événements de clic au niveau du lien), et une pour chaque relation fournisseur de pixel (couvrant les données d'attribution côté navigateur). Les confondre produit une entrée RoPA qui n'est précise dans aucune direction.

Pour les obligations de sous-traitance RGPD au niveau de l'article en intégralité, RGPD pour les raccourcisseurs d'URL est l'article cornerstone dans ce cluster.

La checklist d'approvisionnement du DPO pour les fournisseurs de pixel#

Cinq questions à poser à chaque fournisseur de pixel de suivi à l'approvisionnement. Elles sont écrites pour un examen ère DPF ; ajustez la question sur le mécanisme de transfert si le statut DPF a changé au moment où vous lisez ceci.

1. Votre entreprise est-elle actuellement listée sur la liste des participants DPF, et quelles activités votre certification couvre-t-elle ?

La liste est à dataprivacyframework.gov. Demandez la portée de certification spécifique, pas un « oui, nous sommes certifiés » général. La certification est délimitée par activité ; un fournisseur peut être certifié DPF pour les données de ressources humaines mais pas pour les données d'attribution de clic commercial.

2. Où les données que j'envoie via le pixel sont-elles réellement stockées, et y a-t-il un endpoint en région UE que je peux utiliser ?

Le DPF couvre le transfert vers un destinataire américain certifié. Si un endpoint en région UE est disponible, l'utiliser réduit l'exposition au transfert et peut affecter l'analyse AIT si le DPF est plus tard contesté. Documentez la réponse dans votre entrée de RoPA.

3. Quel est votre Data Processing Agreement standard, et couvre-t-il explicitement les obligations Article 28(3)(a)-(h) ?

Les DPA pré-signés incorporés par référence dans les conditions de service conviennent ; vous devez savoir que le DPA existe et où le trouver. Le DPA régit la relation sous-traitant indépendamment du mécanisme de transfert.

4. Comment gérez-vous les demandes de droits des personnes concernées - spécifiquement la suppression au titre de l'Article 17 - pour les données collectées par pixel ?

Pour les pixels côté client, la suppression est typiquement gérée par les contrôles de confidentialité de la plateforme (Privacy Centre de Meta, My Ad Centre de Google). Documentez le processus pour que vous puissiez répondre à une demande de personne concernée sans improviser.

5. Si le DPF est invalidé, quel mécanisme de transfert de repli proposerez-vous, et selon quel calendrier ?

Cette question teste si le fournisseur a un plan de contingence. Sous la transition Privacy Shield vers CCT (2020-2021), certains fournisseurs ont été lents à mettre à jour leurs accords. Un fournisseur qui a déjà documenté les CCT comme repli d'invalidation DPF - avec des mesures supplémentaires spécifiées - a fait ce travail. Un fournisseur qui dit « nous mettrons à jour notre DPA si nécessaire » ne l'a pas fait.

Pour l'implémentation spécifique à Elido : la transmission de conversion côté serveur est disponible aujourd'hui, avec hachage d'identifiants SHA-256 avant que toute donnée ne quitte l'infrastructure UE. La configuration est par espace de travail et documentée dans le DPA standard à /legal/dpa. Si votre tolérance au risque DPF est faible, le chemin côté serveur est disponible comme mécanisme de transmission principal, pas seulement comme repli.