Tagging et tracking côté serveur : pourquoi le consentement RGPD s'applique toujours

Les gestionnaires de balises passent côté serveur. Le conteneur serveur de Google Tag Manager, Tealium EventStream, Adobe Event Forwarding, Segment et des services hébergés comme Stape vous permettent tous d'envoyer les événements vers un serveur que vous contrôlez et de les transmettre depuis celui-ci, soit sur un sous-domaine comme data.example.com, soit sur un chemin de votre domaine principal comme example.com/metrics. Rien de tout cela ne modifie ce qu'exigent le RGPD et les règles ePrivacy : un consentement avant tout cookie d'analyse d'audience ou de publicité, et une base légale pour chaque donnée personnelle envoyée à une plateforme publicitaire ou d'analyse d'audience.

Ce qui change, c'est le chemin que doit suivre le consentement. La bannière s'exécute toujours dans le navigateur, mais la décision d'envoyer des données à un fournisseur se prend désormais sur votre serveur : le choix du visiteur doit donc accompagner chaque événement.

Tagging et tracking côté serveur : pourquoi le consentement RGPD s'applique toujours

Deux façons d'exécuter des balises sur votre propre domaine

	Sous-domaine	Chemin sur votre domaine principal
Exemple	data.example.com	example.com/metrics
Mise en place	Un enregistrement DNS fait pointer le sous-domaine vers votre serveur de tagging	Votre CDN ou votre reverse proxy route le chemin vers votre serveur de tagging
Ce que cela change	Les requêtes et les cookies sont first-party	Les requêtes sont de même origine : les scripts des balises et les événements se chargent comme le reste de votre site
Consentement toujours requis	Oui	Oui

Safari limite la durée de vie des cookies déposés par un sous-domaine qui pointe vers une adresse IP différente de celle de votre site principal, ce qui explique en partie pourquoi de plus en plus de configurations utilisent un chemin sur le domaine principal. Pour le consentement, ce choix ne change rien : dans les deux cas, les balises et les cookies sont les vôtres, et la responsabilité aussi.

Pourquoi le tagging côté serveur ne supprime pas le consentement

Quatre idées reçues reviennent souvent, et aucune ne tient.

• « Les cookies serveur ne sont pas des cookies. » Un cookie déposé par votre serveur est toujours stocké sur le terminal du visiteur. Les règles ePrivacy couvrent le stockage et la lecture d'informations sur un terminal, quel que soit ce qui les dépose.
• « First-party veut dire exempté. » Il n'existe aucune exemption pour les cookies first-party. Un cookie first-party utilisé pour l'analyse d'audience ou la publicité nécessite un consentement, exactement comme un cookie tiers. Le Digital Omnibus de l'UE pourrait à l'avenir exempter une partie de la mesure first-party, mais il ne s'agit encore que d'un texte de négociation, pas d'une loi.
• « Le navigateur ne communique jamais avec le fournisseur, donc tout va bien. » Le RGPD s'applique aux données personnelles que vous transmettez, comme les adresses IP, les e-mails hachés et les détails de commande, qu'elles partent du navigateur ou de votre serveur.
• « Les bloqueurs de publicité ne le voient pas, donc ça ne compte pas. » Cacher des requêtes aux bloqueurs ne change rien à l'obligation légale. C'est toujours le choix du visiteur dans votre bannière qui détermine ce que vous pouvez collecter.

Le tagging côté serveur reste utile. C'est vous qui décidez de ce qui sort de votre infrastructure : vous pouvez supprimer les adresses IP, raccourcir les user agents et retirer les champs dont un fournisseur n'a pas besoin avant la transmission, ce qui va dans le sens de la minimisation des données prévue par le RGPD. Il lui faut simplement le même signal de consentement que les balises du navigateur, transmis d'une autre manière.

Où les configurations côté serveur laissent fuir des données

Le serveur transmet les événements sans vérifier le consentement

Un conteneur serveur ou un pipeline d'événements transmet ce qu'il reçoit. Les balises Google lisent Google Consent Mode et adaptent ce qu'elles envoient, mais la plupart des autres connecteurs, comme la Meta Conversions API, la TikTok Events API, LinkedIn et l'OpenAI Conversions API utilisée pour les ChatGPT Ads, ne vérifient pas le consentement d'eux-mêmes. Laissés avec leurs réglages par défaut, ils envoient tous les événements, y compris ceux des visiteurs qui ont refusé.

Les scripts servis depuis votre domaine s'exécutent avant la bannière

Lorsque votre gestionnaire de balises ou votre CDN sert les scripts des balises depuis votre domaine et les ajoute à vos pages, il se peut que vous ne maîtrisiez plus leur ordre de chargement. S'ils s'exécutent avant que votre CMP n'ait défini le consentement, ils peuvent déposer des cookies et envoyer des données avant que le visiteur n'ait vu la bannière. C'est ce qu'on appelle un signal de consentement tardif. La configuration CDN en un clic de Google Tag Gateway en est un exemple courant.

Les contrôles fondés sur les domaines ne fonctionnent plus

Les bloqueurs de scripts et les audits de balises simples reconnaissent les traceurs à leurs domaines. Dès que tout se charge depuis votre propre domaine, ils ne peuvent plus distinguer un traceur de votre propre code : vérifiez donc le consentement à partir des requêtes que votre site envoie réellement.

Les cookies déposés par le serveur manquent dans la politique cookies

Les cookies déposés par votre serveur de tagging portent votre domaine et passent facilement inaperçus. Ils doivent pourtant figurer dans votre politique cookies et être couverts par la bannière. Un scan des cookies détecte aussi les cookies first-party.

Comment transmettre le consentement aux balises côté serveur

1. Chargez d'abord la CMP. Si vos balises se chargent depuis votre propre domaine, servez la bannière de la même manière pour qu'elle ne soit pas plus lente que les balises : UniConsent prend en charge un domaine CMP first-party.
2. Envoyez le choix avec chaque événement. Ajoutez l'état du consentement à chaque événement que le navigateur envoie à votre serveur : les valeurs Google Consent Mode pour Google, la chaîne IAB TCF pour les fournisseurs publicitaires qui la lisent, et des indicateurs par finalité ou par vendor pour tous les autres.
3. Vérifiez le consentement sur le serveur avant la transmission. Chaque connecteur de fournisseur ne se déclenche que si la finalité ou le vendor correspondant est autorisé.
4. Conservez une trace. Envoyez l'ID de consentement avec chaque événement pour pouvoir montrer sur quel choix repose chaque événement transmis.

Dans Google Tag Manager côté serveur, la configuration la plus courante, les balises Google transmettent elles-mêmes Consent Mode au conteneur serveur, si bien que Google Analytics et Google Ads respectent le choix du visiteur. Les autres balises du conteneur ne le font pas. Transmettez depuis le conteneur web la valeur de consentement dont vous avez besoin et ajoutez-la au déclencheur de chaque balise Meta, TikTok, LinkedIn ou OpenAI.

Comment UniConsent s'intègre à toute configuration côté serveur

UniConsent fonctionne avec le gestionnaire de balises que vous utilisez côté serveur, quel qu'il soit. Il recueille le choix du visiteur une seule fois et le met à disposition du client navigateur de votre gestionnaire de balises :

• via la Consent Ready API et la JavaScript API, ID de consentement compris ;
• sous forme de valeurs Google Consent Mode v2, réglées sur refusé pour les visiteurs de l'UE, de l'EEE, du Royaume-Uni et de Suisse avant l'exécution de toute balise Google ;
• sous forme de chaînes IAB TCF et GPP pour les fournisseurs publicitaires qui les lisent ;
• par finalité, catégorie et vendor dans la data layer, pour toutes les autres balises.

UniConsent est une CMP certifiée par Google et une CMP enregistrée auprès de l'IAB TCF. Elle propose des balises de consentement prêtes à l'emploi pour le Meta Pixel, le TikTok Pixel et Microsoft UET, ainsi que des vendors personnalisés pour les plateformes hors IAB TCF, comme OpenAI. Consent Logging conserve une trace de chaque choix. Pour les outils côté serveur de Google, consultez les guides de configuration pour GTM côté serveur et Google Tag Gateway.

Démarrez un essai gratuit ou vérifiez votre site dès maintenant avec le Consent Mode Checker gratuit.

Check-list du consentement pour le tagging côté serveur

• La CMP se charge avant toute balise, y compris les scripts servis depuis votre propre domaine.
• Chaque événement envoyé à votre serveur contient l'état du consentement du visiteur.
• Chaque connecteur de fournisseur sur le serveur ne se déclenche qu'avec le consentement correspondant.
• Les champs dont un fournisseur n'a pas besoin sont supprimés sur le serveur avant la transmission.
• Les cookies déposés par votre serveur figurent dans votre politique cookies.
• Un refus sur la bannière stoppe tout le trafic de votre serveur vers les plateformes publicitaires. Testez-le avant la mise en ligne.

FAQ

Le tagging côté serveur rend-il mon site conforme au RGPD ?

Non. Il vous donne davantage de contrôle sur les données que vous envoyez, ce qui aide, mais le consentement reste nécessaire pour les cookies de publicité et d'analyse d'audience, et pour le partage de données personnelles avec les plateformes publicitaires et d'analyse d'audience.

Ai-je besoin d'une bannière cookies si mes balises s'exécutent sur mon propre domaine ?

Oui, si vous utilisez des cookies ou des technologies similaires pour l'analyse d'audience ou la publicité et que vous avez des visiteurs dans l'UE, l'EEE ou au Royaume-Uni. Les cookies déposés depuis votre propre domaine restent des cookies.

Pour le consentement, vaut-il mieux un sous-domaine ou un chemin sur mon domaine principal ?

Ni l'un ni l'autre ne modifie les règles du consentement. Un chemin sur le domaine principal évite la limite de Safari sur les cookies des sous-domaines pointant vers une autre adresse IP, mais les scripts servis de cette façon peuvent se charger avant la bannière si vous ne maîtrisez pas l'ordre de chargement.

Mon serveur peut-il lire la chaîne IAB TCF ?

Oui. Envoyez la chaîne TC avec chaque événement. Votre serveur peut vérifier les finalités et les vendors avant la transmission, et les fournisseurs qui prennent en charge le TCF peuvent la lire eux-mêmes.

Google Tag Gateway contourne-t-il le consentement ?

Non. Les balises respectent toujours Google Consent Mode, à condition que votre CMP définisse le consentement avant leur exécution. UniConsent est conçu pour cela.