google, tech

Rédaction de l’adresse IP dans GTM server-side : ce que fait la méthode de Google, où elle fuit, comment la vérifier

Par Laurent Fidahoussen, le 12 novembre 2026

On présente souvent le server-side tagging comme l’option respectueuse de la vie privée : le navigateur parle à votre serveur, et votre serveur décide de ce qui part vers Google Ads, Floodlight, Meta et les autres. C’est vrai seulement si votre serveur décide réellement quelque chose. La requête qui arrive dans un conteneur Google Tag Manager server-side (sGTM) vient de la connexion du visiteur : le serveur connaît donc son adresse IP, et les tags que vous déclenchez ensuite peuvent la transmettre.

Google vient de publier une courte page d’aide qui décrit comment masquer cette IP dans le conteneur serveur, avant qu’aucun tag ne la voie. Ce guide explique ce que ces étapes font vraiment, ce qu’elles apportent, les cinq endroits par lesquels l’IP peut encore sortir, comment configurer tag par tag, comment vérifier dans Preview et quoi mesurer ensuite. Quand je tire une conclusion du mécanisme plutôt que de la formulation de Google, je le dis explicitement.

En bref

Pourquoi l’IP est dans votre conteneur serveur

Quand un navigateur envoie un hit à votre endpoint sGTM, la requête HTTP vient de la connexion du visiteur : le serveur sait d’où elle arrive, comme n’importe quel serveur web. Un client du conteneur (typiquement le client GA4) transforme cette requête en événement, c’est-à-dire un ensemble de champs que les tags lisent. L’un de ces champs est ip_override, que la liste des données d’événement courantes de Google décrit comme « l’adresse IP de l’utilisateur au format IPv4 ou IPv6 ». Les tags basés sur les templates Google lisent ce champ et le transmettent à leurs propres endpoints.

Image utile : l’événement est un colis, chaque tag est un coursier. Ce qu’il y a dans le colis au moment où les coursiers passent est ce qui est livré. Rédiger l’IP, c’est changer le contenu du colis avant leur arrivée.

Where IP redaction happens in a server-side GTM container The browser request reaches the sGTM client, which builds event data containing ip_override with the full IP. An Augment event transformation replaces it with a truncated IP before tags read it. Google Ads and Floodlight then send the truncated IP. GA4 already applies partial redaction. A vendor tag reading its own field or the request is not covered. Browser 198.51.100.42 Server-side GTM container Client builds the event Event data ip_override = .42 Transformation Augment event What tags read ip_override = .0 Tags fire after transformations Google Ads receives 198.51.100.0 Floodlight receives 198.51.100.0 GA4 partial redaction by default Vendor reading its own field not covered: full IP
Figure 1. La transformation modifie l’événement avant que les tags ne le lisent. Un tag qui prend l’IP ailleurs n’est pas couvert.

Ce que fait la méthode de Google

1. Une variable qui tronque l’IP

Vous créez une variable de template personnalisée avec deux lignes de JavaScript en sandbox :

const getAnonymizedIpAddress = require('getAnonymizedIpAddress');
return getAnonymizedIpAddress();

La référence de l’API sGTM décrit précisément ce que renvoie cette fonction :

EntréeRègleExempleAdresses partageant le résultat
IPv4Dernier octet mis à 0198.51.100.42 → 198.51.100.0256 (un bloc /24)
IPv680 derniers bits à 0, 48 premiers conservés2001:db8:cafe:1234:5678:90ab:cdef:1234 → 2001:db8:cafe::280 (un bloc /48)
Invalide ou non résolueRenvoie ::« toujours sûr à utiliser comme ip_override »–

La dernière colonne est de l’arithmétique, pas une déclaration de Google. Le template exige la permission user_ip. En clair : on garde le nom de la rue et on efface le numéro de la maison.

2. Une transformation qui remplace le champ

La méthode de Google utilise une transformation Augment event qui fixe ip_override à la valeur tronquée. La page d’aide est explicite sur le moment : la rédaction a lieu « avant qu’aucun tag individuel n’accède aux données ». Vous restreignez ensuite la transformation aux tags qui doivent recevoir l’IP tronquée, via les Matching Conditions ou les Affected Tags.

Les transformations en un tableau

TypeCe que ça faitRisque documenté par GooglePour l’IP
Allow parametersSeuls les paramètres listés atteignent les tags. « Les paramètres d’événement non définis explicitement sont supprimés. »Supprime tout ce qui n’est pas listé, « même les valeurs requises par les tags Google ».Non
Augment eventModifie la valeur de paramètres existants ou en ajoute.« Les tags peuvent ne pas fonctionner comme prévu quand les paramètres qu’ils utilisent sont modifiés. »Oui : méthode de Google
Exclude parametersRetire des paramètres précis avant que les tags les lisent.Peut empêcher un tag de fonctionner si le paramètre est requis.Possible, mais l’IP est supprimée au lieu d’être tronquée : tester le tag d’abord

L’ordre d’évaluation par défaut est Allow, puis Augment, puis Exclude, modifiable par une valeur de priorité. Par défaut, une transformation s’applique à tous les tags et n’a aucune condition.

Ce que ça apporte

Ce que ça ne fait pas

Où ça casse : cinq fuites

Fuite 1 : les vendeurs qui ne lisent pas ip_override

Google le dit sur la même page : tous les vendeurs tiers n’utilisent pas le champ ip_override. Certains lisent l’IP dans un en-tête personnalisé ou un paramètre propre. Pour ces tags, votre transformation modifie un champ qu’ils ne regardent jamais, et l’IP complète sort. La réponse de Google : une transformation Augment event de plus, sur le champ exact de ce vendeur.

Fuite 2 : les templates qui lisent la requête eux-mêmes

L’API sGTM expose aussi getRemoteAddress(), qui lit l’IP d’origine dans la requête (en-têtes Forwarded et X-Forwarded-For, ou adresse distante). Hypothèse, pas la formulation de Google : une transformation modifie les données d’événement, donc un template qui appelle directement getRemoteAddress() ne serait pas affecté. Vérifiez les permissions du template : celui qui demande un accès read_request à ces en-têtes mérite un examen.

Fuite 3 : un matching affaibli

Certains vendeurs utilisent l’IP pour reconnaître la personne derrière une conversion. La documentation de l’API Conversions de Meta indique qu’envoyer à la fois client_ip_address et client_user_agent « peut aider à améliorer le matching des événements », et préfère l’IPv6 quand elle est disponible. Une IP tronquée porte moins de signal : moins d’événements appariés, donc potentiellement moins de conversions attribuées et moins de données pour l’enchère automatisée. Ce n’est pas une fuite de données mais de performance, à mesurer.

Fuite 4 : un périmètre trop large

La documentation des transformations dit que « par défaut, la transformation s’applique à tous les tags » et prévient que des tags peuvent mal fonctionner si les paramètres qu’ils utilisent sont modifiés. Laisser le périmètre sur « tous » par réflexe, c’est ainsi qu’un correctif de confidentialité devient un incident de mesure.

Fuite 5 : les logs d’infrastructure

Le conteneur n’est pas le seul endroit où la requête est enregistrée. Sur Cloud Run, le guide de Google indique que par défaut « les informations sur chaque requête » sont journalisées, et recommande de désactiver ce logging pour maîtriser les coûts. L’enregistrement de requête de Cloud Logging contient un champ remoteIp : « l’adresse IP (IPv4 ou IPv6) du client qui a émis la requête HTTP ». Une transformation ne fait rien sur ces logs : logging et rétention se décident au niveau infrastructure, avec le même soin.

Quels tags ont besoin de quoi : arbre de décision

Decision tree: how to cover each tag For each tag: if it is a GA4 server tag, partial redaction is already applied. Otherwise, if it reads ip_override, add it to the main transformation scope. If it reads another event field, add a dedicated Augment event transformation on that field. If it reads the request with getRemoteAddress, review or replace the template. For each server tag GA4 server tag? yes Already partial no action needed no Where does it read the IP? ip_override another event field the request itself Add to the main transformation scope Google Ads, Floodlight, many vendors Dedicated Augment event on that exact field scoped to that tag only Review the template (getRemoteAddress) transformation likely ineffective
Figure 2. Une question par tag : où lit-il l’IP ? La réponse détermine le correctif.

Mise en place, pas à pas

  1. Inventaire. Listez chaque tag du conteneur serveur et notez où il lit l’IP : documentation du vendeur, code du template et ses permissions, ou la requête vue dans Tag Assistant. C’est l’étape que la plupart des équipes sautent, et celle qui évite les trous.
  2. Créer la variable. Variables → Nouvelle → variable de template personnalisée avec les deux lignes ci-dessus, permission user_ip accordée.
  3. Créer la transformation. Transformations → Nouvelle → Augment event. Champ : ip_override. Valeur : la variable.
  4. La cadrer. Affected tags : Google Ads, Floodlight et les tags tiers qui lisent ip_override, pas « tous les tags » par défaut.
  5. Traiter les cas à part. Pour chaque tag qui lit l’IP dans un autre champ, une transformation Augment event de plus sur ce champ exact, avec la même variable, limitée à ce tag. Pour les templates qui lisent la requête, voir la fuite 2.
  6. Vérifier, puis publier. Preview, déclenchez vos tags, ouvrez chaque requête sortante et lisez l’IP. Publiez, et notez la date de mise en ligne là où votre équipe reporting la trouvera.
  7. Fermer le côté infrastructure. Décidez du logging des requêtes Cloud Run et de la rétention des logs (fuite 5).

Vérifier dans Preview

Preview sGTM a cinq onglets (Request, Tags, Variables, Event Data, Console). Deux comptent ici :

Ce que vous lisezVerdict
IPv4 finissant par .0Rédigée
IPv6 finissant par :: après les trois premiers groupesRédigée
:: seulIP non résolue, rien n’est envoyé
Adresse complèteNon couverte : retour à l’arbre de décision pour ce tag

Les tags hors périmètre doivent se comporter exactement comme avant. Si un tag a cessé de se déclencher, regardez l’onglet Console : la transformation a probablement modifié un champ dont il dépend.

À quoi s’attendre ensuite

Le jour même (conformité) : chaque requête sortante dans le périmètre porte une IP tronquée, aucun tag du périmètre n’a d’IP complète, aucun tag n’a cessé de se déclencher.

Après deux semaines pleines (performance) : chez Meta, comparer l’Event Match Quality et les conversions attribuées avant/après ; chez Google Ads et Floodlight, comparer les conversions à dépense égale. Lisez des semaines entières, jamais le lendemain : un lundi ne se compare pas à un samedi.

Pour fixer les idées : 100 conversions avant, 97 après au même budget, c’est un petit écart, et vous gardez le réglage. Une chute nette sur une seule plateforme désigne ce tag, pas tout le dispositif : regardez à quoi ce vendeur utilise l’IP et décidez pour ce tag seul, raison écrite. Le résultat attendu est modeste et concret : une fuite de donnée personnelle en moins, une preuve à montrer, et un coût mesuré plutôt que supposé.

FAQ

Checklist

Sources

Pour aller plus loin, lisez la version complète de l’article (en anglais) : IP Address Redaction in Server-Side GTM: What Google’s Method Does, Where It Leaks, and How to Verify It.

Besoin d’aide sur ce sujet ? Consent Mode v2 et CMP.

Vous doutez de votre tracking ?

Réserver un appel Ou commencez par l’audit analytics gratuit →