CNIL et GA4 : les 7 etapes de proxification pour etre conforme
La CNIL recommande un proxy server-side entre le navigateur et Google. Voici les 7 etapes techniques de pseudonymisation a implementer.
Pourquoi la CNIL exige un proxy server-side
En 2022, la CNIL a juge que l’utilisation de Google Analytics sans mesures de protection supplementaires constituait un transfert illegal de donnees personnelles vers les Etats-Unis. Meme 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 controlez, transforme les donnees avant de les transmettre a GA4 pour supprimer ou pseudonymiser tout ce qui pourrait permettre a Google d’identifier un individu.
La CNIL a defini sept etapes precises de pseudonymisation. Chacune correspond a un type de donnee specifique, et toutes doivent etre implementees dans votre conteneur GTM Server-Side.
Etapes 1 et 2 : IP et identifiant utilisateur
La premiere etape est la reduction de l’adresse IP. Avant toute transmission a 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 a 192.168.0.0) et appliquer une reduction equivalente pour IPv6. GA4 applique deja une anonymisation IP, mais la CNIL exige que cette operation soit faite sur votre serveur, avant que Google ne recoive quoi que ce soit.
La deuxieme etape est la pseudonymisation de l’identifiant utilisateur. Le cookie _ga contient un client_id qui identifie de maniere unique un navigateur. Votre proxy doit remplacer ce client_id par un hash irreversible genere cote serveur. Le hash doit integrer un sel (salt) qui change periodiquement pour empecher toute reidentification. Concretement, dans GTM Server-Side, vous creez une variable qui lit le client_id entrant, applique un HMAC-SHA256 avec un sel, et ecrase la valeur originale avant transmission.
Etapes 3 et 4 : referrer et page_location
La troisieme etape concerne la suppression du referrer externe. Le referrer HTTP indique la page precedente visitee par l’utilisateur. Si cette page est externe a votre site, elle constitue une donnee 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 quatrieme etape porte sur le nettoyage du parametre page_location. Les URLs transmises a GA4 peuvent contenir des parametres sensibles : parametres UTM (qui revelent les sources marketing), query strings avec des identifiants, des emails ou des tokens. Votre proxy doit nettoyer systematiquement ces parametres. Conservez le chemin de la page (/produits/chaussures) mais supprimez les query strings avant transmission.
Etapes 5 et 6 : User-Agent et identifiants cross-site
La cinquieme etape est le retraitement du User-Agent. La chaine User-Agent du navigateur contient des informations detaillees sur le systeme d’exploitation, la version du navigateur, et parfois le modele d’appareil. Ces informations, combinees entre elles, constituent un fingerprint potentiel. Votre proxy doit reduire le User-Agent a ses composants les plus generiques : famille de navigateur et systeme d’exploitation, sans version precise ni details d’appareil.
La sixieme etape interdit la transmission d’identifiants cross-site. Votre proxy ne doit transmettre aucune donnee permettant a Google de suivre un utilisateur entre plusieurs sites. Cela inclut les cookies tiers, les identifiants publicitaires (gclid, dclid), et tout parametre de suivi inter-domaines. Si vous utilisez le cross-domain tracking de GA4, le parametre _gl doit etre intercepte et gere exclusivement cote serveur.
Etape 7 : donnees sensibles residuelles
La septieme etape est un filet de securite. Elle impose la suppression de toute autre donnee susceptible de permettre une identification : adresses email non hashees, numeros de telephone, identifiants CRM transmis accidentellement dans les parametres d’evenements.
En pratique, cette etape necessite un audit regex sur tous les parametres sortants pour detecter et supprimer les patterns d’email, de telephone et d’identifiants personnels.
L’ensemble de ces transformations se configure dans GTM Server-Side via des variables et des transformations appliquees au client GA4 et au tag GA4. Des plateformes comme Addingwell ou Stape proposent des templates preconfigures qui implementent ces sept etapes. La mise en place reste technique et necessite une gestion rigoureuse du consentement en amont pour etre pleinement conforme.