Server-side tracking et RGPD : faut-il toujours un consentement ?

Qu’est-ce que le tracking server-side ?

Avec un suivi classique, tout se passe dans le navigateur. Votre page charge des scripts de Google, Meta et d’autres fournisseurs, et chacun envoie les données directement du navigateur du visiteur vers les serveurs de son éditeur.

Avec le tracking server-side (ou « suivi côté serveur »), le navigateur envoie d’abord les données à un seul endroit : un serveur que vous contrôlez, généralement sur un sous-domaine de votre site, comme mesure.exemple.fr. Ce serveur reçoit la requête, la transforme en événements et décide quoi transmettre à quel fournisseur. L’exemple le plus connu est Google Tag Manager server-side : un « conteneur serveur » hébergé sur Google Cloud ou chez un hébergeur spécialisé, à côté du conteneur web habituel dans le navigateur. Les usages courants : GA4 via un conteneur serveur et l’API Conversions de Meta, qui permet à votre serveur d’envoyer directement les conversions à Meta.

Le point essentiel : dans la plupart des configurations, le navigateur du visiteur exécute toujours un script et envoie toujours les données. Seule leur première destination change.

Le server-side exige-t-il un consentement ?

Deux corps de règles s’appliquent, comme pour tout traceur (voir Cookies et RGPD : les règles de la CNIL) :

1. L’article 82 de la loi Informatique et Libertés, qui transpose l’article 5(3) de la directive « ePrivacy » : toute lecture ou écriture d’informations sur le terminal de l’utilisateur exige son consentement, sauf si elle a pour seule finalité de permettre la communication électronique ou si elle est strictement nécessaire à un service qu’il a expressément demandé.
2. Le RGPD : tout traitement de données personnelles exige une base légale, une information des personnes et des garanties.

Passer par un serveur ne fait pas sortir de l’article 82. La règle porte sur ce qui se passe sur le terminal, pas sur la destination des données. La CNIL rappelle qu’elle s’applique quelle que soit la technologie (cookies, local storage, fingerprinting, identifiants) et que les données soient personnelles ou non, ce que la Cour de justice a confirmé dans l’arrêt Planet49 (2019). Dans ses lignes directrices 2/2023 sur le champ technique de l’article 5(3), le Comité européen de la protection des données (CEPD) précise que :

• un site qui utilise du JavaScript pour faire envoyer des informations par le navigateur accède à ces informations, ce qui relève de la règle ;
• ajouter des identifiants dans des URL ou des pixels de suivi revient à demander au terminal de renvoyer cet identifiant, ce qui constitue aussi un accès ;
• collecter un identifiant unique, comme une adresse e-mail hachée, via du code exécuté dans le navigateur relève également de la règle ;
• même un suivi fondé uniquement sur l’adresse IP peut en relever, sauf si vous pouvez garantir que l’adresse ne provient pas du terminal du visiteur.

Un dispositif server-side fait précisément cela : la balise Google du navigateur envoie des événements à votre serveur, et le conteneur serveur peut déposer un cookie sur votre domaine pour reconnaître le visiteur. Un cookie « first-party » déposé via un conteneur serveur exige donc un consentement pour la publicité ou une mesure d’audience non exemptée, exactement comme s’il était déposé par un script.

Les exemptions restent possibles, mais elles dépendent de la finalité, pas de la technique. La CNIL exempte la mesure d’audience strictement limitée au compte exclusif de l’éditeur, produisant des statistiques anonymes, sans recoupement ni transmission à des tiers. Un conteneur serveur qui alimente GA4 ou des plateformes publicitaires ne remplit pas ces conditions ; voir Google Analytics et RGPD.

Le RGPD s’applique aussi sur le serveur

Une fois les données arrivées sur votre serveur, le RGPD s’applique à tout ce que vous en faites : les transmettre à Google ou Meta, les enrichir avec des données de commande ou de CRM, constituer des audiences. Il faut une base légale par finalité, et selon les lignes directrices du CEPD sur le consentement, lorsque celui-ci est la base légale, il doit être obtenu avant le début du traitement.

Pour la publicité et le profilage, cette base est en pratique le consentement. Dans l’arrêt Meta Platforms c. Bundeskartellamt (C-252/21, 4 juillet 2023), la Cour de justice a jugé que la publicité personnalisée ne peut pas justifier, au titre de l’intérêt légitime, le traitement des données des utilisateurs par Meta sans leur consentement. Un site qui transmet les données de ses visiteurs à une plateforme publicitaire pour le ciblage ou la mesure des conversions aura du mal à invoquer l’intérêt légitime là où la plateforme elle-même ne le peut pas.

Ce que le server-side change vraiment

Le server-side ne dispense pas du consentement, mais il peut rendre votre suivi plus respectueux de la vie privée et plus facile à maîtriser :

• Contrôle sur ce que reçoivent les fournisseurs. Google indique que vous seul avez accès aux données du conteneur serveur tant que vous ne choisissez pas de les transmettre. Vous pouvez supprimer des champs, raccourcir des URL ou écarter des événements avant qu’ils ne quittent votre serveur.
• Adresses IP et identifiants. Vous pouvez ne pas transmettre l’adresse IP complète, ou remplacer les identifiants avant l’envoi. C’est conforme au principe de minimisation des données (article 5(1)(c) du RGPD).
• Moins de requêtes tierces dans le navigateur. Moins de scripts de fournisseurs sur la page, c’est moins de sociétés qui peuvent lire directement des données sur le terminal du visiteur.
• Transferts hors de l’Union européenne. Si votre serveur est hébergé dans l’UE et filtre les données avant de les transmettre, moins de données personnelles parviennent à des fournisseurs situés hors d’Europe. La CNIL décrit un tel « proxy » pour la mesure d’audience, à des conditions strictes : aucune transmission de l’adresse IP, remplacement de l’identifiant, suppression du référent et des paramètres d’URL, aucun identifiant permettant un suivi entre sites, et un hébergement qui exclut les transferts hors de l’UE. La CNIL présente ce dispositif comme une réponse à la question des transferts, pas comme une dispense de consentement.

Server-side, bannière cookies et Consent Mode

La configuration qui fonctionne est la même que sans conteneur serveur, avec une étape de plus :

1. Votre bannière cookies recueille le choix et bloque les balises de mesure d’audience et de marketing tant que le visiteur n’a pas consenti.
2. Google Consent Mode v2 transmet ce choix (voir Google Consent Mode v2 expliqué). Selon la documentation de Google, il suffit de configurer Consent Mode dans le conteneur web : la balise Google ajoute l’état du consentement à chaque requête envoyée au conteneur serveur.
3. Les balises Google du conteneur serveur suivent cet état. En mode de base, les balises Analytics sont entièrement bloquées et aucun cookie Analytics n’est déposé ni lu, dans le navigateur comme sur le serveur. En mode avancé, elles envoient à la place des mesures sans cookies. Sans consentement, les balises de conversion Google Ads ne lisent ni n’écrivent de cookies, et les requêtes de remarketing Google Ads et Floodlight sont bloquées.
4. Les balises des autres fournisseurs demandent votre attention. Google ne garantit ce comportement que pour ses propres balises. Une balise API Conversions de Meta, ou toute autre balise du conteneur serveur, ne doit se déclencher que si l’état du consentement le permet : configurez-le vous-même avec des déclencheurs ou des conditions.

Une bannière comme Cookie Confirm définit les valeurs par défaut de Consent Mode avant le chargement de toute balise Google et les met à jour après le choix du visiteur : l’état du consentement accompagne ainsi chaque requête vers le conteneur serveur.

L’API Conversions de Meta et le consentement

L’API Conversions relie votre serveur à Meta pour envoyer des événements du site, comme des achats ou des prospects, sans dépendre uniquement du pixel Meta dans le navigateur. Meta s’en sert pour mesurer et optimiser les publicités.

Il s’agit donc d’un traitement publicitaire. Les conditions des outils professionnels de Meta (Business Tools Terms) vous obligent à disposer de tous les droits nécessaires et d’une base légale pour les données partagées et, dans les pays qui exigent un consentement pour le stockage ou l’accès à des informations sur les terminaux (les conditions citent l’UE), à obtenir un consentement vérifiable des visiteurs. Selon ces conditions, vous êtes responsable de traitement pour ces données dans l’UE. En pratique :

• n’envoyez d’événements via l’API Conversions que pour les visiteurs qui ont accepté le marketing dans votre bannière ;
• n’utilisez pas l’API Conversions pour « récupérer » les conversions des visiteurs qui ont refusé ;
• mentionnez Meta et l’API Conversions dans votre politique de cookies et votre politique de confidentialité.

L’option « Limited Data Use » de Meta vise certaines lois américaines sur la vie privée. Ce n’est pas un mécanisme de consentement européen.

Erreurs fréquentes

• « C’est sans cookies, donc pas besoin de consentement. » L’article 82 vise bien plus que les cookies : scripts qui font envoyer des données par le navigateur, pixels de suivi, identifiants dans les URL et identifiants uniques en relèvent tous, selon le CEPD et la CNIL.
• « C’est first-party maintenant. » La règle ne distingue ni cookies propriétaires et tiers, ni cookies déposés par un script ou par un serveur. C’est la finalité qui compte.
• Envoyer des données avant le choix. Si votre conteneur serveur transmet des pages vues ou des conversions avant que le visiteur ait cliqué dans la bannière, vous traitez des données sans base légale.
• « Un e-mail haché est anonyme. » Une adresse e-mail hachée est une donnée pseudonymisée, que le RGPD traite toujours comme une donnée personnelle (considérant 26). Elle est hachée précisément pour qu’une plateforme comme Meta puisse la rattacher à une personne.
• Oublier les balises non Google. Consent Mode ne pilote que les balises Google. Toute autre balise du conteneur serveur a besoin de sa propre vérification du consentement.
• Ne pas mettre à jour la politique de cookies. Les visiteurs doivent savoir quels fournisseurs reçoivent leurs données, y compris lorsqu’elles transitent d’abord par votre serveur. Voir notre exemple de politique de cookies.

Sources

• CNIL : texte de la loi Informatique et Libertés (article 82)
• CNIL : lignes directrices « cookies et autres traceurs » (PDF)
• CNIL : mesurer la fréquentation de vos sites web et applications
• CNIL : mesure d’audience et transferts de données
• Directive 2002/58/CE « vie privée et communications électroniques » (version consolidée), article 5(3)
• Règlement général sur la protection des données (UE) 2016/679
• CEPD : lignes directrices 2/2023 sur le champ technique de l’article 5(3) de la directive ePrivacy (en anglais)
• CEPD : lignes directrices 05/2020 sur le consentement
• CJUE : affaire C-673/17, Planet49 (1er octobre 2019)
• CJUE : communiqué de presse 113/23, affaire C-252/21, Meta Platforms c. Bundeskartellamt (4 juillet 2023)
• Google : présentation du taggage côté serveur
• Google : mettre en œuvre le mode Consentement avec Tag Manager côté serveur
• Google : domaine personnalisé pour le taggage côté serveur
• Meta for Developers : API Conversions
• Meta for Developers : options de traitement des données pour les utilisateurs américains
• Meta : conditions des outils professionnels