Le Consent Mode v2 a cessé d'être facultatif le 06-03-2024. Depuis cette date, le trafic de l'UE et de l'EEE vers les produits publicitaires de Google doit transmettre deux nouveaux signaux — ad_user_data et ad_personalization — aux côtés des originaux ad_storage et analytics_storage. Ce changement n'a pas été impulsé par le RGPD mais par le Digital Markets Act (Règlement (UE) 2022/1925), et plus précisément par l'Art. 5(2) du DMA, qui interdit aux contrôleurs d'accès désignés de combiner ou d'utiliser de manière croisée des données à caractère personnel entre services sans consentement explicite.
Pour un réducteur d'URL, cela croise le plan de données de redirection de manière complexe. Un lien court est ce sur quoi l'utilisateur a cliqué ; l'état du consentement sur la page de destination décide si le clic peut être attribué. Ces deux événements se produisent sur des domaines différents, dans des compartiments de cookies différents, souvent dans des sessions différentes. L'écart entre eux est là où réside désormais la majeure partie de la perte d'attribution.
Cet article est l'analyse d'un conseiller juridique en conformité sur ce qui a changé, ce que les quatre signaux signifient réellement pour un service de redirection, où la récupération côté serveur est légale selon les directives actuelles de l'EDPB, et où elle ne l'est pas. La majeure partie du travail d'ingénierie pour le suivi côté serveur via redirections est conforme au RGPD ; une partie ne l'est pas au regard du DMA.
Le DMA, en un paragraphe#
Le Digital Markets Act est devenu applicable le 07-03-2024. Il désigne des « gatekeepers » (contrôleurs d'accès) — Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft, Booking — et leur impose des obligations ex ante. L'Art. 5(2) du DMA est celui qui importe pour le suivi : un contrôleur d'accès ne doit pas traiter les données à caractère personnel des utilisateurs finaux de services tiers pour la publicité en ligne, ni combiner les données à caractère personnel entre ses services, sans consentement.
Le Consent Mode v2 est le mécanisme de conformité de Google pour l'Art. 5(2). Les deux nouveaux signaux — ad_user_data et ad_personalization — permettent au contrôleur d'accès d'observer si l'éditeur a obtenu un consentement de niveau Art. 5(2) avant que la télémétrie du clic ne soit utilisée pour la publicité ou la personnalisation. Sans ces signaux réglés sur granted, les produits publicitaires de Google se rabattent sur des conversions agrégées ou modélisées sans attribution par utilisateur.
Le DMA ne remplace pas le RGPD. Il s'y ajoute. Un responsable de traitement a toujours besoin d'une base légale Art. 6 selon le RGPD ; le Consent Mode v2 ajoute une deuxième porte qui se ferme pour les données publicitaires acheminées par les contrôleurs d'accès, même lorsque la porte du RGPD est ouverte.
Les quatre signaux, en termes simples#
Le Consent Mode v2 transmet quatre signaux booléens. Chacun peut être granted (accordé) ou denied (refusé). Des valeurs par défaut peuvent être définies par région.
ad_storage — le signal original de la v1. Contrôle si des cookies ou d'autres types de stockage sont écrits pour la publicité. Lorsque réglé sur denied, les balises Google se déclenchent sans identifiants ; la mesure des conversions se dégrade en agrégats modélisés sans cookies. La redirection décide quels UTM et identifiants de clic arrivent sur la page, et ceux-ci deviennent les clés auxquelles le consentement s'attache. La documentation de consentement de la tag-platform est la référence canonique pour ce que chaque signal fait en aval.
ad_user_data — nouveau dans la v2. Contrôle si des données utilisateur peuvent être envoyées à Google pour la publicité. C'est le signal Art. 5(2) du DMA. Lorsque réglé sur denied, la balise ne peut pas transmettre de données utilisateur — y compris les identifiants hachés, l'IP, le user-agent — à Google Ads. Le marquage côté serveur ne contourne pas cela ; le signal voyage avec l'événement.
ad_personalization — également nouveau. Contrôle si les données transmises peuvent être utilisées pour la publicité personnalisée, y compris le remarketing. Une configuration courante est ad_user_data=granted plus ad_personalization=denied, ce qui permet l'attribution mais bloque le remarketing.
analytics_storage — contrôle si le stockage est écrit pour l'analyse. La balise GA4 respecte cela ; lorsque réglé sur denied, GA4 fonctionne sans cookies et utilise la modélisation du mode de consentement pour reconstruire l'attribution au niveau agrégé. La modélisation nécessite un volume de trafic minimum et une période d'apprentissage de 7 jours.
Aucun des quatre signaux n'est décidé au niveau du réducteur. Le réducteur émet le clic ; la page de destination lit les signaux ; la balise sur la page de destination décide quoi en faire. Le travail du réducteur est de fournir un état propre — UTM préservés, identifiant de clic préservé, redirection rapide — afin que la bannière puisse être résolue avant le déclenchement de la balise.
Ce qui ne va pas sur le plan de données de redirection#
Trois modes de défaillance apparaissent sur chaque réducteur qui prend le chemin de la redirection au sérieux.
L'identifiant de clic survit mais le signal de consentement ne survit pas. Un clic publicitaire Meta frappe s.elido.me/abc123?fbclid=… et redirige vers https://customer.example/landing?fbclid=…. Le fbclid est préservé. La page se charge, la bannière apparaît, l'utilisateur refuse. Meta CAPI a déjà reçu un clic indexé sur ce fbclid — mais l'utilisateur a maintenant refusé l'utilisation publicitaire. Le réducteur n'a rien fait de mal ; le responsable du traitement a un problème de dédoublonnage CAPI à résoudre sur son point de terminaison.
Le réducteur ajoute des identifiants que la page de destination ne comprend pas. Certains réducteurs (le bitly_session de Bitly, le _branch_match_id de Rebrandly) ajoutent des paramètres spécifiques au fournisseur qui nécessitent d'être supprimés ou de faire l'objet d'un traitement spécial en cas de refus de consentement. Elido transmet uniquement les UTM et l'identifiant de clic propre au client.
L'état du consentement de la page de destination est inconnaissable du point de vue de la redirection. Le réducteur ne peut pas voir une bannière qui n'a pas encore été chargée. Les décisions de repli côté serveur ne peuvent pas être conditionnées par un état de consentement qui n'existe pas encore. Le seul défaut honnête : ne déclencher aucun événement côté serveur à des fins publicitaires au moment de la redirection ; laisser la bannière se résoudre, puis laisser la page ou son proxy se déclencher avec l'état du consentement joint.
Les fournisseurs qui déclenchent des événements Measurement Protocol ou CAPI directement depuis l'edge parient que l'utilisateur donnera son consentement. Sous l'Art. 5(2) du DMA, ce pari ne leur appartient pas. Les Directives 02/2023 de l'EDPB sur le champ d'application technique de l'Article 5(3) ePrivacy ont souligné ce point concernant l'injection d'identifiants avant consentement : c'est un traitement, il nécessite une base, et l'absence de bannière n'est pas une base.
Atténuations côté serveur qui sont légales#
Les mesures d'atténuation ci-dessous sont celles qui tiennent la route à la fois sous le RGPD et le DMA. Elles partagent un fil conducteur : l'état du consentement doit être observé avant que toute donnée ne soit transmise à un contrôleur d'accès ou utilisée pour la publicité.
Measurement Protocol avec l'état du consentement joint. Le Measurement Protocol de GA4 accepte les mêmes paramètres de consent que le client gtag. Le modèle : la page de destination résout la bannière, envoie l'état du consentement au serveur de premier niveau (first-party) du client, et ce serveur transmet une requête mp/collect à GA4 avec consent.ad_user_data et consent.ad_personalization définis. Côté serveur, mais en aval de la résolution du consentement. Le redirecteur d'Elido (traité dans suivi côté serveur GA4 via redirections) applique l'état du consentement à la charge utile sortante.
Conversion API avec chaînes de consentement. Meta CAPI accepte data_processing_options et opt_out ; la Conversions API de LinkedIn accepte enlli ; l'Events API de TikTok accepte limited_data_use. Toutes signalent l'état du consentement à la plateforme. Le modèle est identique : la page de destination se résout, envoie au serveur first-party, le serveur first-party se déclenche avec l'état du consentement joint.
Reporting côté serveur agrégé. Lorsque l'état du consentement refuse l'utilisation publicitaire ou analytique, un reporting côté serveur véritablement agrégé et dépourvu d'identifiants par utilisateur est généralement acceptable sous l'Art. 5(2) du DMA et sous l'Art. 6 du RGPD sur la base de l'intérêt légitime. Les Directives 04/2023 de l'EDPB sur l'anonymisation rappellent que les données pseudonymisées ne sont pas anonymes et qu'une k-anonymat faible permet toujours une ré-identification. Une pratique prudente consiste à publier les comptes au niveau de l'espace de travail avec un seuil ≥10.
Résolution de l'identifiant de premier niveau sur la page de destination. L'approche la plus résiliente consiste à identifier l'utilisateur via un signal Art. 6(1)(b) du RGPD — il s'est connecté, il a rempli un formulaire, il a cliqué sur un lien d'e-mail confirmé — et à effectuer l'attribution de manière rétroactive. Cela ne dépend pas du tout de ad_storage ou ad_user_data. L'article sur l'attribution des clics après Safari ITP couvre ce modèle ; c'est aussi la bonne réponse pour le monde post-DMA.
Atténuations côté serveur qui ne sont pas légales#
Trois modèles apparaissent dans les arguments de vente des fournisseurs d'outils et ne devraient pas.
Déclenchement d'événements CAPI depuis l'edge avant que le consentement de la page de destination ne soit résolu. C'est le mode de défaillance décrit ci-dessus. Il n'y a pas d'état de consentement à joindre ; déclencher l'événement implique que le responsable du traitement a obtenu le consentement, ce qui n'est pas le cas. Certains fournisseurs décrivent cela comme une « attribution déterministe » ; sous l'Art. 5(2) du DMA, il s'agit d'une opération de combinaison de données que l'utilisateur n'a pas autorisée.
Hacher l'IP et traiter le hachage comme anonyme. L'EDPB est clair depuis l'Avis 4/2007 sur le concept de données à caractère personnel et a réitéré dans les Directives 04/2023 que les identifiants hachés restent des données à caractère personnel lorsque le hachage est réversible par quiconque a accès à la population. Les hachages d'IP sont facilement réversibles à grande échelle ; le hachage ne change pas le caractère juridique du traitement.
Synchronisation d'identifiants côté serveur avec les contrôleurs d'accès. Transmettre l'événement de clic à Google ou Meta avec un e-mail haché ou un numéro de téléphone haché, et compter sur le contrôleur d'accès pour le faire correspondre à son propre graphique d'identifiants, est l'opération que l'Art. 5(2) du DMA restreint spécifiquement. La mise en correspondance est une combinaison de données inter-services par le contrôleur d'accès. Le consentement pour cela doit être explicite et au niveau de l'utilisateur. La présence du hachage ne rend pas l'opération licite ; l'absence de consentement la rend illicite.
Contexte récent de la CJUE et de l'EDPB#
Deux récentes décisions de régulateurs précisent la situation.
L'arrêt de la CJUE dans l'Affaire C-621/22 (Royal Lichtervelde, 2024) a réitéré l'analyse de co-responsabilité issue de Wirtschaftsakademie (C-210/16) et Fashion ID (C-40/17). Lorsqu'un éditeur intègre une balise tierce et que cette balise transmet des données utilisateur au tiers, l'éditeur et le tiers sont responsables conjoints pour ce traitement. L'Art. 26 du RGPD exige un accord transparent entre eux. Pour un client Consent Mode v2, l'accord Art. 26 avec Google doit être en place et l'état du consentement doit circuler honnête. Simuler ad_user_data=granted pour récupérer l'attribution engage la responsabilité de co-traitance des deux parties.
Les Directives 03/2024 de l'EDPB sur les signaux de consentement dans les contextes publicitaires (projet de consultation, version finale attendue au T3 2026) traitent explicitement du Consent Mode v2. Le projet soutient que le signal ad_user_data est, selon l'Art. 7(4) du RGPD, conditionnel à un consentement librement donné, et que les bannières regroupant ad_storage avec ad_user_data sans contrôles granulaires échouent au test du consentement libre de l'Art. 7. La plupart des bannières actuelles les regroupent. La refonte incombe au client ; le réducteur expose un état propre, il ne conçoit pas la bannière.
Pour la question plus large de l'impact des transferts — consentement accordé, mais les données quittent toujours l'UE — l'article sur Schrems II et les pixels de suivi couvre l'aspect TIA. Le DMA ne résout pas ce problème ; il ajoute une autre contrainte.
Ce qu'Elido fait (et ne fait pas) à la couche de redirection#
Elido est le sous-traitant ; le responsable du traitement décide de la posture de consentement et gère la bannière. Le plan de données de redirection fait le minimum :
- Préserve les UTM et l'identifiant de clic propre au client. Les identifiants publicitaires spécifiques aux fournisseurs (
fbclid,gclid,msclkid,ttclid) sont transmis par défaut car ils constituent la surface d'attribution du responsable du traitement ; une option de désactivation par espace de travail est disponible. - Ne déclenche aucun événement publicitaire côté serveur au moment de la redirection. L'événement de clic interne écrit dans ClickHouse a l'IP tronquée à /24 ou /48 et contient uniquement des champs d'appareil analysés, conformément à la minimisation des données du RGPD. Il n'est partagé avec aucun tiers.
- Prend en charge la transmission des conversions côté serveur respectueuse du consentement vers GA4, Meta CAPI, LinkedIn, TikTok et Reddit, conditionnée par l'état du consentement fourni par la page de destination. Le redirecteur se trouve dans
/features/conversion-tracking; la configuration est dans le guide de documentation sur le suivi des conversions. - Nécessite une charge utile
consentde la page de destination lorsque la transmission respectueuse du consentement est activée ; en l'absence de charge utile, l'événement est abandonné et non déclenché silencieusement avec des valeurs par défaut.
Le tableau de bord analytique sur /features/analytics affiche la répartition de l'état du consentement par campagne — accordé, refusé, non défini — afin que l'équipe marketing puisse voir quelle proportion d'attribution est perdue à cause des refus.
Ce qu'Elido ne fait pas : implémenter la bannière, décider du consentement à l'avance, ou honorer un consentement accordé pour des utilisateurs qui ne l'ont pas réellement donné. Ces décisions incombent au responsable du traitement, là où le RGPD et le DMA les placent tous deux.
La question de l'approvisionnement#
Pour un responsable de traitement évaluant un réducteur sous l'Art. 5(2) du DMA, trois questions.
Le réducteur transmet-il des données de clic à un service tiers de publicité ou d'analyse au moment de la redirection, indépendamment de l'état du consentement de la page de destination ? Si oui, c'est une exposition à l'Art. 5(2) du DMA à laquelle il faut mettre fin.
Le réducteur prend-il en charge la transmission de l'état du consentement vers ses points de terminaison de conversion côté serveur ? Si non, le responsable du traitement aura besoin d'un proxy de marquage côté serveur séparé (conteneur serveur GTM, Stape, Snowplow) entre la page de destination et les API des contrôleurs d'accès.
La couche analytique du réducteur partage-t-elle des données agrégées avec des tiers ? Certains outils orientés marketing publient des « benchmarks du secteur » qui s'avèrent être des données de clics clients avec des sous-graphiques identifiables par la forme du trafic — quelle est l'analyse de co-responsabilité sous Wirtschaftsakademie et Fashion ID ?
Un réducteur qui reste flou sur l'un de ces points ajoute une surface de risque DMA que le responsable du traitement devra défendre en cas d'audit.
Où cela nous mène#
Le Consent Mode v2 n'est pas une initiative marketing. C'est un mécanisme de conformité pour l'Art. 5(2) du DMA qui est diffusé via la tag-platform de Google. Les quatre signaux sont honnêtes sur le consentement obtenu ; les mesures d'atténuation côté serveur fonctionnent lorsque l'état du consentement voyage avec l'événement ; la perte d'attribution dans un monde de consentement refusé est réelle mais moins importante qu'il n'y paraît une fois que la résolution des identifiants first-party est en place. Le réducteur fournit un état propre à travers la redirection et expose une transmission respectueuse du consentement que le responsable du traitement connecte à sa bannière.
Les directives de l'EDPB attendues pour le T3 2026 vont relever le niveau d'exigence. Concevoir uniquement pour le niveau actuel est un manque de clairvoyance ; concevoir pour ce que l'Art. 5(2) vise — un consentement explicite, granulaire et librement donné pour la combinaison de données inter-services — est la position qui survivra à la prochaine vague de mise en application.
Lectures complémentaires#
- Le RGPD pour les réducteurs d'URL : ce que votre DPO veut réellement voir — la pierre angulaire de la catégorie conformité.
- Attribution des clics après Safari ITP — l'histoire parallèle de la perte d'attribution côté navigateur.
- L'attribution sans cookies expliquée — les modèles d'identifiants first-party qui survivent au refus de consentement.
- Suivi côté serveur GA4 via redirections — la structure Measurement Protocol sur laquelle repose la transmission du consentement.
- Schrems II et pixels de suivi — ce qu'il advient des données consenties après avoir traversé l'Atlantique.
- Surface produit :
/features/analyticspour la vue de répartition de l'état du consentement. - Guide opérationnel : le guide de documentation sur le suivi des conversions pour la configuration du redirecteur respectueux du consentement.