Tutoriel
CNIL et GA4 : 7 étapes de proxification pour être conforme
La CNIL recommande un proxy server-side entre le navigateur et Google. Voici les 7 étapes techniques de pseudonymisation à implémenter.
Google Analytics 4 
GTM Server-Side 
Consent Mode v2 Dans ce tutoriel
Pourquoi la CNIL exige un proxy server-side
En 2022, la CNIL a jugé que l’utilisation de Google Analytics sans mesures de protection supplémentaires constituait un transfert illégal de données personnelles vers les États-Unis. Même avec l’adoption du Data Privacy Framework en 2023, la CNIL maintient ses recommandations de pseudonymisation server-side comme meilleure pratique.
Le principe est clair : interposer un serveur proxy entre le navigateur de l’utilisateur et les serveurs de Google. Ce proxy, que vous contrôlez, transforme les données avant de les transmettre à GA4 pour supprimer ou pseudonymiser tout ce qui pourrait permettre à Google d’identifier un individu.
La CNIL a défini sept étapes précises de pseudonymisation. Chacune correspond à un type de donnée spécifique, et toutes doivent être implémentées dans votre conteneur GTM Server-Side.
Étapes 1 et 2 : IP et identifiant utilisateur
La première étape est la réduction de l’adresse IP. Avant toute transmission à Google, votre proxy doit supprimer les derniers octets de l’adresse IP de l’utilisateur. En pratique, cela signifie tronquer les deux derniers octets pour IPv4 (passer de 192.168.1.42 à 192.168.0.0) et appliquer une réduction équivalente pour IPv6. GA4 applique déjà une anonymisation IP, mais la CNIL exige que cette opération soit faite sur votre serveur, avant que Google ne recoive quoi que ce soit.
La deuxième étape est la pseudonymisation de l’identifiant utilisateur. Le cookie _ga contient un client_id qui identifie de manière unique un navigateur. Votre proxy doit remplacer ce client_id par un hash irréversible généré côté serveur. Le hash doit intégrer un sel (salt) qui change périodiquement pour empêcher toute réidentification. Concrètement, dans GTM Server-Side, vous créez une variable qui lit le client_id entrant, applique un HMAC-SHA256 avec un sel, et écrase la valeur originale avant transmission.
Étapes 3 et 4 : referrer et page_location
La troisième étape concerne la suppression du referrer externe. Le referrer HTTP indique la page précédente visitée par l’utilisateur. Si cette page est externe à votre site, elle constitue une donnée de navigation personnelle. Votre proxy doit supprimer le referrer quand il pointe vers un domaine tiers, et ne conserver que les referrers internes pour le suivi de la navigation sur votre propre site.
La quatrième étape porte sur le nettoyage du paramètre page_location. Les URLs transmises à GA4 peuvent contenir des paramètres sensibles : paramètres UTM (qui révèlent les sources marketing), query strings avec des identifiants, des emails ou des tokens. Votre proxy doit nettoyer systématiquement ces paramètres. Conservez le chemin de la page (/produits/chaussures) mais supprimez les query strings avant transmission.
Étapes 5 et 6 : User-Agent et identifiants cross-site
La cinquième étape est le retraitement du User-Agent. La chaîne User-Agent du navigateur contient des informations détaillées sur le système d’exploitation, la version du navigateur, et parfois le modèle d’appareil. Ces informations, combinées entre elles, constituent un fingerprint potentiel. Votre proxy doit réduire le User-Agent à ses composants les plus génériques : famille de navigateur et système d’exploitation, sans version précise ni détails d’appareil.
La sixième étape interdit la transmission d’identifiants cross-site. Votre proxy ne doit transmettre aucune donnée permettant à Google de suivre un utilisateur entre plusieurs sites. Cela inclut les cookies tiers, les identifiants publicitaires (gclid, dclid), et tout paramètre de suivi inter-domaines. Si vous utilisez le cross-domain tracking de GA4, le paramètre _gl doit être intercepte et gère exclusivement côté serveur.
Étape 7 : données sensibles résiduelles
La septième étape est un filet de sécurité. Elle impose la suppression de toute autre donnée susceptible de permettre une identification : adresses email non hashées, numéros de téléphone, identifiants CRM transmis accidentellement dans les paramètres d’événements.
En pratique, cette étape nécessite un audit regex sur tous les paramètres sortants pour détecter et supprimer les patterns d’email, de téléphone et d’identifiants personnels.
L’ensemble de ces transformations se configure dans GTM Server-Side via des variables et des transformations appliquées au client GA4 et au tag GA4. Des plateformes comme Addingwell ou Stape proposent des templates préconfigurés qui implémentent ces sept étapes. La mise en place reste technique et nécessite une gestion rigoureuse du consentement en amont pour être pleinement conforme.
