Le Règlement Général sur la Protection des Données (RGPD) a rendu indispensable la protection de la vie privée des utilisateurs. Conformément au RGPD, vous devez supprimer toute information personnellement identifiable avant de transférer des données utilisateurs vers un outil appartenant à une entreprise américaine. Cette mesure est devenue nécessaire suite à l'invalidation du Privacy Shield.
Dans cet article, nous vous expliquons comment supprimer automatiquement les données utilisateurs grâce au power-up Stape Anonymizer, et comment les supprimer manuellement via le GTM web et serveur. Il s'agit d'un complément à l'article publié sur notre blog, qui explique pourquoi il est nécessaire d'utiliser un serveur proxy pour utiliser Google Analytics de manière conforme au RGPD.
Plusieurs incidents ont eu lieu dans des pays de l'UE (Italie, France, Autriche et Danemark) : des particuliers ont saisi les autorités locales de protection des données pour vérifier si l'utilisation de Google Analytics sur un site web était conforme au RGPD. La réponse a été unanime : l'utilisation de Google Analytics n'est pas conforme au RGPD. Bien que cet outil analytique soit souvent indispensable pour bien optimiser campagne Google Ads, la réponse des autorités a été unanime : l'utilisation standard de Google Analytics n'est pas conforme au RGPD.
La raison principale est que les entreprises américaines (dont Google) ne fournissent pas de mesures de sécurité suffisantes pour protéger les données personnelles des utilisateurs européens. C'est pourquoi le partage de données personnellement identifiables avec des entreprises américaines est contraire au RGPD. Vous trouverez de plus amples informations à ce sujet dans notre article de blog précédent.
La bonne nouvelle, c'est qu'il existe une solution pour utiliser Google Analytics tout en restant conforme au tracking côté serveur et au RGPD. La CNIL (autorité française de protection des données) a indiqué que pour utiliser GA de manière conforme au RGPD, deux éléments doivent être mis en place : un serveur proxy hébergé dans l'UE et la pseudonymisation des données utilisateurs avant l'export.
Le serveur proxy garantit qu'il n'y a pas de contact direct entre le site web et l'outil d'analyse américain. La manière la plus simple d'implémenter un tel serveur proxy est d'utiliser le conteneur server Google Tag Manager. Les serveurs proxy doivent répondre à plusieurs critères. Le point essentiel : l'entreprise qui vous fournit le serveur proxy doit être immatriculée dans l'UE, et les serveurs hébergeant votre conteneur sGTM doivent être physiquement situés dans l'UE. Pour ces deux raisons, vous ne pouvez pas utiliser Google Cloud (GCP) pour votre sGTM — pour la même raison que Google Analytics : Google est une entreprise américaine.
Autre bonne nouvelle : Stape a la solution. Nous proposons un produit spécifique – Stape Europe – qui répond à toutes les exigences requises pour un serveur proxy conforme à l'UE. Stape Europe est immatriculée dans l'UE (Estonie) et utilise le serveur cloud européen fourni par Scaleway pour héberger votre conteneur sGTM.
Dans cet article, je souhaite me concentrer sur le deuxième volet de la réglementation : la pseudonymisation des données utilisateurs. Chez Stape, nous développons une série de fonctionnalités qui vous aideront à supprimer automatiquement les données utilisateurs. Je vais donc diviser cet article en deux parties :
La liste des données utilisateurs à pseudonymiser est assez vague. Elle comprend notamment :
Pour l'instant, nous concevons le power-up Stape Anonymizer uniquement pour GA4. Il sera toutefois adapté et rendu disponible avec la fonctionnalité d'anonymisation d'UA dans les prochaines mises à jour.
Il est essentiel de comprendre que la liste des paramètres envoyés par GA4 peut évoluer. Nous veillerons à maintenir cet article à jour, mais assurez-vous de tester l'anonymisation des données utilisateurs avant de la déployer en production.
À mesure que l'intelligence artificielle et l'automatisation progressent, il pourrait bientôt être possible de s'appuyer sur des solutions avancées comme un Google Analytics MCP pour auditer et gérer intelligemment ces paramètres de confidentialité de manière programmatique. D'ici là, une configuration et des tests manuels rigoureux demeurent indispensables.
Le meilleur outil que j'ai trouvé pour suivre et identifier les paramètres GA4 est celui-ci.
Le processus de pseudonymisation des données utilisateurs s'effectue au sein des tags GA4 dans les conteneurs GTM web et serveur. Si vous n'avez pas encore configuré le tracking GA4 côté serveur, suivez notre guide de configuration de GA4 côté serveur.
Nous n'avons pas de directives strictes sur les données à supprimer obligatoirement. C'est à vous de décider du niveau de sécurité que vous souhaitez pour votre entreprise. Vous pouvez, par exemple, supprimer l'adresse IP de l'utilisateur ou simplement masquer les derniers chiffres. Une autre question importante concerne les paramètres comme le pays, la langue, le navigateur, etc. Pris individuellement, chaque paramètre ne permet pas d'identifier suffisamment un utilisateur — mais un ensemble de paramètres peut le permettre.
En revanche, il ne fait aucun doute que des paramètres comme le client ID ou les paramètres d'URL doivent être supprimés. Chacun de ces paramètres, pris isolément, peut conduire à l'identification d'un utilisateur en raison de l'identifiant unique qu'il contient dans Google.
Imaginez que vous ayez besoin d'analyser le trafic mobile vs. desktop, ou les conversions selon les navigateurs. Devez-vous supprimer toutes les données pouvant être utilisées pour le fingerprinting et l'identification, ou seulement certaines ? Pouvez-vous conserver les données de navigateur et d'appareil si vous supprimez tous les autres paramètres ?
Discutez de ces questions avec vos juristes ou votre DPO pour vous protéger au mieux en cas de contrôle d'un régulateur. De mon côté, je considère qu'il est préférable de supprimer tous les identifiants utilisateurs pouvant être utilisés pour le fingerprinting et la ré-identification, afin de sécuriser au maximum votre entreprise.
Cet article ne prétend pas être une instruction officielle. Il s'agit simplement d'un retour d'expérience sur la suppression ou la pseudonymisation des données, et sur la façon dont Stape le fait automatiquement. Vous pouvez choisir de ne pas utiliser notre power-up d'anonymisation et d'anonymiser manuellement chaque paramètre.
Nous avons récemment lancé un power-up Anonymizer, disponible pour tous les utilisateurs Stape. Son objectif principal est de supprimer ou d'anonymiser les données utilisateurs dans Google Analytics 4.
Pour activer l'Anonymizer, ouvrez le conteneur sGTM dans Stape, cliquez sur power-up et ouvrez l'Anonymizer.

Ce produit intègre des données GeoLite2 créées par MaxMind, disponibles sur https://www.maxmind.com
Sélectionnez les paramètres que vous souhaitez conserver tels quels, supprimer ou anonymiser. Une fois les paramètres configurés, mettez à jour l'URL du serveur de tagging pour Google Analytics 4. Si vous utilisiez précédemment l'URL https://sgtm.example.com, après activation de l'Anonymizer, l'URL mise à jour sera https://sgtm.example.com/anonymize. Nous faisons transiter vos requêtes vers sGTM via le chemin /anonymize et supprimons les données spécifiées.
Lorsque les requêtes GA transitent par l'URL du serveur de tagging incluant /anonymize, nous supprimons ou anonymisons automatiquement les paramètres sélectionnés.
Après avoir activé et configuré l'Anonymizer, assurez-vous d'avoir modifié l'URL de transport GA4/UA dans le tag de configuration GTM web pour qu'elle se termine par /anonymize.
Voici la liste complète des paramètres que l'Anonymizer peut supprimer ou anonymiser. Lors de sa conception, notre objectif était de donner à nos clients la possibilité de supprimer tous les paramètres susceptibles d'être considérés comme des données personnelles. Vous choisissez les paramètres à supprimer. Consultez votre DPO ou vos juristes pour déterminer lesquels doivent l'être.
Pour la plupart des paramètres, deux options vous seront proposées : laisser tel quel ou supprimer. Pour deux paramètres (IP et Client ID), vous verrez les options Anonymiser et Anonymiser strictement.
IP
Client ID (fonctionne uniquement si vous utilisez l'identification client gérée par JavaScript)
| Nom du paramètre | Description | Paramètre GA4 | Anonymisation |
|---|---|---|---|
| IP | Adresse IP de l'utilisateur | IP Address | Anonymiser — supprime le dernier octet. Anonymiser strictement — supprime les deux derniers octets. |
| Client ID | Google Analytics Client ID, cookies _ga, ga*, FPLC, FPID | cid, _ga, ga*, FPLC, FPID | Anonymiser — hash de IP+UserAgent + année+mois. Anonymiser strictement — hash de IP+UserAgent + horodatage, crc32_hash(IP+UA).timestamp |
| User ID | User ID, Google Developer ID, Firebase ID | uid, gdid, _fid | - |
| Session ID | Session ID, New Session ID | sid, _nsi | - |
| Paramètres d'URL | Supprimer les paramètres de requête de la Document Location | dl | - |
| Référent | Document Referrer Header, Document Referrer Parameter | referer header, dr | - |
| User Agent | En-tête Document User-Agent, en-têtes Sec-Ch-Ua, Sec-Ch-Ua-Platform, Sec-Ch-Ua-Mobile, paramètre User-Agent | user-agent header, sec-ch-ua header, sec-ch-ua-platform header, sec-ch-ua-mobile header, ua | - |
| Pays de l'utilisateur | ID géographique, pays actuel de l'utilisateur | geoid, _uc | - |
| Plugins navigateur | Java activé, version Flash | je, fl | - |
| Informations d'écran | Résolution d'écran du navigateur, taille de la fenêtre | sr, vp | - |
| Couleurs d'écran | Profondeur de couleur de l'écran | sd | - |
| Langue de l'utilisateur | Paramètre régional actif du navigateur | ul | - |
| User Agent Architecture | uaa | - | |
| User Agent Bitness | uab | - | |
| User Agent Full Version List | uafvl | - | |
| User Agent Mobile | uamb | - | |
| User Agent Model | uam | - | |
| User Agent Platform | uap | - | |
| User Agent Platform Version | uapv | - | |
| User Agent WOW64 | uaw | - |
| Campaign Medium | cm | - | |
| Campaign Source | cs | - | |
| Campaign Name | cn | - | |
| Campaign Content | cc | - | |
| Campaign ID | ci | - | |
| Campaign Term | ck | - | |
| Campaign Creative Format | ccf | - | |
| Campaign Marketing Tactic | cmt | - | |
| Google Ads ID | gclid | - | |
| Google Display Ads ID | dclid | - |
Les paramètres collectés par Google Analytics 4 évoluent régulièrement. Vérifiez donc vos requêtes GA4 pour vous assurer que toutes les données utilisateurs ont bien été supprimées.
Une fois les paramètres configurés dans l'Anonymizer et l'URL de transport GA4 mise à jour pour inclure /anonymize en fin d'URL, nous supprimerons ou anonymiserons les paramètres spécifiés.
Après avoir activé l'Anonymizer et mis à jour l'URL de transport GA4, utilisez les débogueurs web/sGTM, la console et le débogueur GA4 pour vérifier que tous les paramètres requis ont bien été supprimés.
Cette étape est relativement simple à mettre en œuvre, mais fait l'objet de débats. Google dispose d'une fonctionnalité native permettant de supprimer le dernier octet de l'adresse IP. En supprimant ce dernier octet, la probabilité que Google identifie un utilisateur est de 1 sur 256. Combinée à d'autres paramètres, l'IP peut toutefois permettre d'identifier précisément une personne.
Certains estiment que couper le dernier octet est suffisant. D'autres pensent qu'il faut supprimer l'IP de l'utilisateur dans sa totalité. Mon avis personnel est qu'il vaut mieux écraser complètement l'IP de l'utilisateur. On ne sait jamais comment Google pourrait réutiliser cette donnée.
« Il convient de noter que les identifiants en ligne, tels que les adresses IP ou les informations stockées dans les cookies, peuvent couramment être utilisés pour identifier un utilisateur, notamment lorsqu'ils sont combinés à d'autres types d'informations similaires. C'est ce qu'illustre le considérant 30 du RGPD, selon lequel l'attribution d'identifiants en ligne tels que des adresses IP et des identifiants de cookies à des personnes physiques ou à leurs appareils peut "laisser des traces qui, notamment lorsqu'elles sont combinées à des identifiants uniques et à d'autres informations reçues par les serveurs, peuvent être utilisées pour établir le profil des personnes physiques et les identifier." »
Pour supprimer l'IP de l'utilisateur, j'ai utilisé le tag GA4 serveur et défini un ip_override avec une IP aléatoire.

Google attribue un client ID unique à chaque paire navigateur/appareil et l'utilise pour identifier lorsqu'un même utilisateur revient sur votre site. Ce paramètre doit être supprimé ou pseudonymisé avant d'être envoyé à GA4.
« Pour garantir une pseudonymisation efficace, l'algorithme effectuant le remplacement doit assurer un niveau de collision suffisant (c'est-à-dire une probabilité suffisante que deux identifiants différents donnent un résultat identique après hachage) et inclure une composante temporelle variable (ajout d'une valeur aux données hachées qui évolue dans le temps, de sorte que le résultat du hachage ne soit pas toujours le même pour le même identifiant). »
Il existe de nombreuses approches pour anonymiser les client IDs – tout dépend de votre imagination et des outils à votre disposition. Assurez-vous simplement que le client ID reste unique et que vous avez intégré une composante temporelle variable.
Vous pouvez utiliser un hash du user agent, de l'IP, d'une variable aléatoire GTM, etc. Contrairement à l'adresse IP, nous n'avons pas trouvé de moyen de masquer le client ID côté serveur, nous l'avons donc fait côté client.


Une fois le Google Analytics Client ID anonymisé, vous souhaiterez peut-être écraser les cookies GA4 avec les nouvelles valeurs pour éviter que GA4 ne définisse des identifiants utilisateurs. Pour ce faire, j'ai utilisé le modèle de tag Cookie Monster pour le conteneur server GTM. Il vous suffit d'ajouter les noms et valeurs des cookies. Une fois cela fait, n'oubliez pas de vérifier dans la console les cookies que GA définit.

Une fois le client ID masqué, cela aura un impact significatif sur le reporting GA4. Comme le client ID sera unique à chaque session, GA ne sera plus en mesure de distinguer les nouveaux visiteurs des visiteurs récurrents, ni de faire fonctionner l'attribution multicanale et les événements comme session_start, first_visit, etc.
Le référent externe permet de déterminer comment un utilisateur est arrivé sur votre site — trafic organique, payant ou social, par exemple.
Pour le supprimer, réécrivez page_referrer.

Les paramètres d'URL servent principalement à identifier l'origine des campagnes publicitaires. Il peut s'agir de utm_source, utm_medium, de différents types de click IDs, etc. Par ailleurs, certaines plateformes insèrent automatiquement des données utilisateurs dans l'URL.
Pour supprimer les paramètres d'URL, vous devez réécrire l'URL de la page. Plusieurs variables disponibles dans la galerie de modèles GTM web peuvent vous y aider. J'ai utilisé Trim Query : il vous suffit de spécifier une liste de blocage ou d'autorisation de paramètres de requête, et il s'occupe du reste. C'est une étape d'autant plus importante si vous cherchez comment exporter des données Google Ads pour vos propres reportings : purger ces paramètres en amont garantit que vos exports de données ne contiendront aucune information personnelle identifiable, respectant ainsi les normes de confidentialité.

Ces données peuvent inclure le user agent, l'appareil, le navigateur, la résolution d'écran, la langue, le système d'exploitation, etc. Assurez-vous d'avoir masqué toutes les informations susceptibles d'être utilisées pour le fingerprinting.

Veillez à ne pas utiliser d'identifiants cross-sites tels qu'un user ID ou un CRM ID.
Ce point est un peu plus difficile à appréhender, mais je vous recommande de vérifier les requêtes que votre conteneur sGTM envoie à GA et de vous assurer qu'aucun paramètre susceptible d'être utilisé pour la ré-identification des utilisateurs n'y figure.
Plusieurs méthodes permettent de vérifier si toutes les données nécessaires ont été supprimées ou pseudonymisées.
Commencez par ouvrir le débogueur server GTM et examinez les requêtes GA4 sortantes. Testez différents scénarios : avec ou sans paramètres utilisateurs, avec des paramètres d'URL, avec différents types d'événements, de référents, etc.

La deuxième méthode consiste à utiliser le débogueur Google Analytics 4 pour observer les données traitées par GA4.

Google n'est pas la seule entreprise à collecter des données d'utilisateurs européens et à les transférer aux États-Unis en violation du RGPD. De nombreuses entreprises ont collecté des données personnelles sur des Européens pendant des années, et il semble que leurs pratiques vont désormais être encadrées de manière globale, en réponse à l'invalidation du Privacy Shield et à la décision selon laquelle le transfert de données d'utilisateurs européens vers les États-Unis est illégal au regard du RGPD.
Si vous êtes propriétaire d'un site web dans l'Union européenne, il est temps de commencer à revoir les données que vous partagez avec des entreprises américaines — sous peine de vous exposer à des sanctions de la part des autorités de régulation.
1. Comment utiliser un serveur proxy pour GA lorsqu'il est implémenté via gtag.js ?
Si vous utilisez gtag.js sur votre site web pour envoyer des événements vers votre conteneur serveur, ajoutez le paramètre transport_url à votre tag existant :
gtag('config', 'TARGET-ID', {
'transport_url': 'https://analytics.example.com',
'first_party_collection': true,
});Vous pouvez utiliser une URL d'anonymisation pour anonymiser les données utilisateurs dans GA lorsqu'il est implémenté via gtag.js. Par exemple, si vous utilisez l'Anonymizer Stape et que votre URL d'anonymisation est https://sgtm.site.com/anonymize, ajoutez simplement https://sgtm.site.com/anonymize comme URL de transport dans la configuration gtag.
Commentaires