GTM server-side : Google Ads récupère l'IP de vos visiteurs le 11 janvier
Google arrête de tronquer l'adresse IP pour ses balises publicitaires en server-side. Ce que la mesure y regagne, et pourquoi votre politique de confidentialité risque d'être fausse au réveil.
Le titre de l’e-mail que Google envoie en ce moment aux annonceurs donne envie de l’archiver sans l’ouvrir : « Modifications apportées au traitement des signaux réseau dans le taggage côté serveur ». Si vous avez un conteneur GTM server-side, ouvrez-le quand même.
Le 11 janvier 2027, un lundi, cinq jours après l’ouverture des soldes d’hiver, ces conteneurs arrêteront de tronquer l’adresse IP des visiteurs pour quatre produits publicitaires de Google : Google Ads, Floodlight dans Campaign Manager 360, Display & Video 360 et Search Ads 360. GA4 garde le masquage. Meta, TikTok et les autres décident pour eux-mêmes, comme avant.
C’est activé par défaut.
Pour se désinscrire, l’e-mail renvoie à un article du centre d’aide, sans titre ni lien. Je l’ai cherché ce soir. Rien, et rien non plus dans les notes de version de Tag Manager. Le meilleur résumé disponible pour l’instant est celui de PPC Land ; j’ajouterai le lien officiel quand la page existera.
Un petit retour en arrière, parce que c’est là que l’annonce devient intéressante.
Quand la balise de conversion Google Ads tourne dans le navigateur, Google voit l’IP du visiteur sans rien demander. C’est le navigateur qui ouvre la connexion vers ses serveurs. Passez la même balise côté serveur et c’est votre conteneur qui appelle Google : l’IP du visiteur voyage alors dans les données de l’événement (le champ ip_override, pour ceux qui ouvrent l’aperçu), et jusqu’ici elle arrivait chez Google amputée de sa fin.
Les migrations server-side se vendent sur deux arguments, des cookies qui tiennent plus de sept jours sur Safari et la main sur ce qui sort du site (j’en parlais ici). Le signal que Google y perdait, on en parlait peu. Moi compris.
Chez Meta, le problème n’a jamais existé. Son API de conversion exige l’IP et le user agent pour les événements web, les deux comptent dans la qualité de correspondance, et un conteneur bien configuré les transmet. TikTok et Pinterest les prennent aussi. La seule grande régie qui sortait perdante du server-side, c’était Google, à cause de ses propres réglages.
Il corrige ça en janvier.
Pour quoi faire ? L’e-mail parle de mesure, de personnalisation et de filtrage du trafic invalide. Le reste relève de la spéculation de ma part. Une IP isolée ne dit pas grand-chose, derrière l’adresse d’un opérateur mobile il peut y avoir des milliers d’abonnés. Croisée avec le modèle d’appareil, le navigateur et l’horodatage, elle devient en revanche un bon indice pour rattacher un achat à un clic quand le gclid s’est perdu en route. Ce qui arrive souvent quand le parcours change de domaine.
Le cas d’école, ce sont deux sites qui ne se font aucun lien : une marque découverte sur l’un et achetée sur l’autre, ou un tunnel de réservation hébergé chez un prestataire. Le paramètre inter-domaines de Google ne survit pas à ce genre de trajet, et l’achat arrive chez Google Ads sans clic auquel se rattacher. Si le même conteneur serveur reçoit les deux visites, Google aura en janvier la même adresse complète des deux côtés, à quelques minutes d’écart, avec le même navigateur. Pour un algorithme de rapprochement, ça pèse.
Toutes les régies n’en tireront pas la même chose. Pour Google Ads, je m’attends à un effet sur les conversions orphelines et sur la part modélisée. Floodlight y gagne là où le gclid n’a jamais existé, entre une bannière vue et un achat trois jours plus tard. DV360, lui, se sert d’abord de l’IP pour écarter le trafic invalide, celui des centres de données et des proxys. GA4 ne verra rien passer, puisque l’adresse y reste tronquée : si vous comptiez sur janvier pour recoller vos sessions entre deux domaines dans GA4, il faudra faire sans.
Je n’en attends pas de miracle non plus. iCloud Private Relay remplace l’adresse d’une partie des utilisateurs d’iPhone, et toute une famille sort par la même box. Un indice de plus, donc, que Google sait croiser avec beaucoup d’autres.
Changez de chaise et relisez l’annonce comme le ferait votre DPO.
Depuis l’arrêt Breyer de la Cour de justice de l’UE, en 2016, une IP, même dynamique, est une donnée personnelle. J’ai vu des conteneurs serveur justifiés en partie par la confidentialité : le serveur filtre, Google reçoit moins. Au 11 janvier, ce sera faux pour ses quatre régies publicitaires, alors que personne n’aura touché à votre configuration. Une politique de confidentialité qui annonce une IP anonymisée chez Google mentira ce matin-là.
L’e-mail rappelle que le consentement doit être recueilli avant la collecte et renvoie à la politique de Google pour les utilisateurs de l’UE. Sur le Consent Mode, rien.
Ça me gêne pour une raison précise. Depuis le 28 juillet 2025, les balises Floodlight d’un conteneur serveur envoient des requêtes même quand le visiteur a refusé la publicité. Porteront-elles l’IP complète à partir de janvier ? Personne ne le sait encore, et je préfère ne pas parier.
Chez mes clients, en attendant, je vais poser une transformation qui exclut ip_override des balises publicitaires quand ad_user_data est refusé. C’est le signal du Consent Mode v2 qui couvre l’envoi de données utilisateur à Google. L’intérêt est double : la règle se résume en une phrase dans la politique de confidentialité, et elle se contrôle dans l’aperçu.
Reste la paperasse. Le registre des traitements doit mentionner l’IP complète parmi ce qui part chez Google, la politique et le bandeau ne doivent plus promettre l’inverse, et les conditions de protection des données acceptées dans Google Ads méritent une relecture. Je ne suis pas juriste. Si vous avez un DPO, transférez-lui l’e-mail cette semaine plutôt que le 10 janvier au soir.
Pour les conteneurs dont je m’occupe, le plan tient en quatre gestes : inventaire des balises par régie, décision avec chaque client entre IP complète et désinscription pour Google Ads et Floodlight, transformation, puis contrôle des requêtes sortantes dans l’aperçu, avant et après le 11 janvier. Tant que la page d’aide n’est pas publiée, je ne me fie qu’à ce que je vois partir.
Ce sujet a une particularité : il concerne à la fois la personne qui configure le tracking et celle qui rédige les textes de consentement, et ces deux-là travaillent rarement ensemble. Je fais les deux. Si vous voulez qu’on regarde votre conteneur et vos mentions avant janvier, réservez un créneau.
À bientôt.