Hostname filter, souveraineté des données et sGTM : construire une architecture GA4 privacy-first en 2026
Le filtre hostname de GA4 est sorti en juin 2026. Beaucoup d’analysts l’ont coché sur leur liste de tâches, puis sont passés à autre chose. C’est une erreur. Ce n’est pas un gadget d’hygiène de données — c’est la première pièce visible d’un puzzle plus large qui touche à la conformité RGPD, à l’architecture server-side, et à une confusion conceptuelle qui coûte cher : confondre résidence des données et souveraineté des données.
Le filtre hostname, enfin — mais avec une limite structurelle
Google vient de déployer une fonctionnalité très demandée : GA4 inclut désormais un filtre hostname natif pour bloquer le trafic provenant de domaines non autorisés avant qu’il n’atteigne tes rapports. Concrètement, chaque événement envoyé à GA4 porte un hostname — le domaine dont il provient. Le nouveau filtre te permet d’exclure les événements dont le hostname correspond à une valeur que tu spécifies.
Le setup est simple. Dans la console GA4 : Admin > Data collection and modification > Data filters > Create Filter, puis sélectionne « Web hostname traffic ». Tu nommes le filtre, entres les hostnames à bloquer, et tu choisis entre Testing ou Active. Commence toujours par le mode Testing. Les filtres de données GA4 sont destructifs : une fois actif, tout événement capturé est définitivement supprimé. En mode Testing, les événements correspondants sont simplement marqués avec une dimension « Test data filter name », ce qui te permet de vérifier ce qui serait supprimé avant de valider.
Maintenant, la vraie limite. Contrairement à Universal Analytics qui permettait de créer un filtre « Include » pour facilement créer une liste blanche de tes domaines réels, le filtre hostname GA4 actuel est strictement un filtre d’exclusion. Un mode « Include » serait en développement, mais n’est pas disponible aujourd’hui. Résultat : la limitation « exclude only » signifie que tu dois continuellement ajouter de nouveaux domaines spam au lieu de maintenir une liste blanche propre.
La parade côté GTM reste valide en attendant. Tu peux configurer ton tag GA4 dans GTM pour ne se déclencher que lorsque le « Page Hostname » correspond à ton domaine spécifique. En créant un déclencheur qui vérifie la variable intégrée « Page Hostname », tu t’assures que même si un spammeur vole ton Measurement ID, il ne peut pas déclencher ton tag s’il n’est pas réellement sur ton site.
Résidence vs souveraineté : la confusion qui expose juridiquement
C’est ici que ça se complique. Et c’est ici que la plupart des équipes se plantent.
En résumé : la résidence des données concerne l’endroit où la donnée vit physiquement, tandis que la souveraineté concerne qui a l’autorité légale pour y accéder et la gouverner, indépendamment de l’endroit où elle est stockée. La résidence te dit où ta donnée vit physiquement ; la souveraineté te dit quelles lois la gouvernent ; la localisation te dit ce qu’elle est autorisée à faire.
Exemple concret. Une entreprise qui utilise Microsoft Azure en région UK pour stocker ses données à Londres bénéficie d’une résidence UK. Mais parce qu’Azure est opéré par une société dont le siège est aux États-Unis, elle tombe sous la juridiction américaine. En vertu du CLOUD Act, les autorités américaines peuvent contraindre l’accès aux données — même si elles sont physiquement stockées au Royaume-Uni. Le même raisonnement s’applique à Google Cloud.
Tu as déployé ton conteneur sGTM en eu-west1. Tu as lu que la localisation en Europe était importante pour le RGPD. Tu as fait le travail. Et maintenant tu as classé ça sous « conformité gérée ». Cinq autorités européennes de protection des données — Autriche, France, Italie, Pays-Bas et Danemark — ont déclaré les configurations GA4 standard non conformes au RGPD. La localisation du serveur n’était le facteur décisif dans aucune de ces décisions. C’est là où la donnée est ultimement stockée et qui la contrôle qui a compté.
sGTM : un pare-feu technique, pas une absolution juridique
Le server-side GTM résout des défis techniques, pas des défis de conformité. La dépendance à l’infrastructure Google, le risque de transferts vers des pays tiers, et la possibilité de responsabilité conjointe en font une solution juridiquement fragile sous le droit européen.
Ce qu’il fait bien, en revanche, est réel. Dans des marchés clés comme l’Allemagne et la France, les bloqueurs de publicité combinés à Safari ITP bloquent les tags GTM côté client sur plus de 40% des sessions. Le tracking server-side déployé sur un sous-domaine first-party est effectivement invisible pour ces bloqueurs, car les requêtes semblent provenir de ton propre domaine.
L’architecture de référence en 2026 : la stack se compose de trois couches clairement séparées — la couche web (navigateur avec GTM web ou un snippet tracker), le endpoint first-party (reverse proxy sur ton propre sous-domaine plus le conteneur serveur), et la couche de sortie (liens serveur-à-serveur vers GA4 Measurement Protocol, Meta Conversions API, ou Matomo interne).
Pour ceux qui veulent aller plus loin sur la souveraineté, quiconque veut une souveraineté maximale des données, une localisation EU et une configurabilité complète fait tourner le tag server lui-même : comme un conteneur Docker sur son propre hébergement, dans une instance Cloud Run en région EU.
Prompt pour auditer ton architecture en 5 minutes
Voici un prompt directement applicable dans Claude ou ChatGPT pour générer un audit rapide de conformité de ta configuration actuelle :
Tu es un consultant senior en Digital Analytics spécialisé RGPD.
Voici mon architecture de collecte actuelle :
- CMP : [nom de ta CMP]
- GTM : [web-side uniquement / server-side sur Cloud Run eu-west1 / sGTM via Stape]
- GA4 : [région de stockage des données / data stream URL]
- Consent Mode v2 : [activé / non activé / basic mode / advanced mode]
- Hostname filter GA4 : [configuré / non configuré]
Identifie les 3 risques de non-conformité prioritaires selon la doctrine CNIL 2025-2026,
en distinguant : risque de résidence des données vs risque de souveraineté.
Pour chaque risque, propose une action corrective concrète avec la priorité (critique / modéré / faible).
Format : tableau markdown.
Ce que la CNIL surveille réellement en 2026
En juillet 2025, la CNIL a remplacé son programme de certification formel par un modèle d’auto-évaluation. La liste publique des outils validés par la CNIL a été retirée au 1er janvier 2026. Sous le nouveau régime, les fournisseurs doivent évaluer eux-mêmes leur conformité selon les critères publiés par la CNIL. Google Analytics n’a jamais figuré sur cette liste.
Le RGPD, le CCPA et les dispositions de l’EU AI Act sur les données exigent un tracking conditionné au consentement avec des signaux de consentement auditables. Les plateformes de gestion du consentement côté client sont de plus en plus contestées dans les procédures réglementaires ; les journaux de consentement côté serveur fournissent des pistes d’audit plus solides.
Consent Mode V2 nécessite une configuration GTM spécialisée pour transmettre des signaux de consentement granulaires à Google Ads — et 73% des implémentations GA4 présentent déjà des erreurs de configuration silencieuses. Ce chiffre est brutal. Il signifie que la majorité des setups qui se croient conformes ne le sont pas.
Le filtre hostname n’est pas une fin. C’est un signal que GA4 commence enfin à traiter la donnée comme quelque chose qui mérite d’être contrôlé à la source. La vraie question n’est pas « est-ce que j’ai activé le filtre ? » mais « est-ce que je sais exactement où va chaque événement après qu’il quitte mon conteneur serveur, et sous quelle juridiction il tombe ? » Si tu n’as pas la réponse immédiatement, c’est là que commence le vrai travail.
Catégories