Adresse IP GTM server side : Google Ads l'aura en entier en 2027

Vous avez migré en server-side pour reprendre la main sur ce qui part chez Google ? Le 11 janvier 2027, Google change les règles du jeu dans votre propre conteneur. Selon un email envoyé aux annonceurs début novembre 2026, le GTM server-side passera d’un masquage de l’adresse IP appliqué à tout le conteneur à un traitement tag par tag, et les tags Google Ads, Display & Video 360, Search Ads 360 et Campaign Manager 360 recevront l’adresse IP complète de vos visiteurs par défaut. Les tags GA4, eux, continueront à la masquer. Si vous ne faites rien, c’est la nouvelle configuration qui s’appliquera. Voici ce qui change concrètement, comment savoir si votre réglage d’adresse IP GTM server side est concerné, et comment garder la main avec une transformation, testée avant l’échéance.

Le cadre, comme toujours sur ces sujets : je décris la mécanique et ce que Google annonce. Décider s’il faut transmettre l’IP ou non, et sur quelle base légale, c’est le travail de votre DPO.

Ce qui change dans sGTM le 11 janvier 2027

L’information vient d’un email intitulé « Updates to network signal processing in server-side tagging », partagé sur LinkedIn par le consultant Google Ads Adriaan Dekker le 2 novembre 2026, puis repris par PPC Land, Search Engine Journal et Search Engine Roundtable. Un point de prudence d’emblée : l’email n’est pas daté, et au moment où j’écris, ni les notes de version de Tag Manager ni la page d’aide sur le masquage d’IP ne mentionnent la date du 11 janvier. Tout ce qui suit repose donc sur la parole de Google dans cet email, pas encore sur sa documentation.

Avant : un masquage au niveau du conteneur

Jusqu’ici, la logique était celle d’un portier unique à l’entrée de l’immeuble : le conteneur serveur pouvait masquer l’IP pour tous les tags d’un coup. L’email décrit exactement cette bascule, d’un « masquage de l’adresse IP à l’échelle du conteneur » vers un « traitement au niveau de chaque tag ».

Après : chaque tag décide

Le 11 janvier, le portier unique disparaît et chaque locataire gère sa propre porte. Voici ce que l’email annonce, tag par tag :

Google justifie le changement par des « améliorations de la mesure et de la personnalisation publicitaires », avec filtrage du spam et du trafic invalide. Traduction : l’IP est un signal déterministe précieux pour rapprocher une conversion d’un clic, et Google veut le récupérer dans les setups server-side qui le lui retiraient.

Et les tags tiers

L’email se contente d’indiquer que les tags tiers gardent un contrôle indépendant sur les signaux qu’ils acceptent. Il ne dit pas si leur comportement change. En pratique, beaucoup de templates tiers lisent déjà le champ standard ip_override : votre CAPI Meta ou votre Events API TikTok reçoivent sans doute déjà l’IP aujourd’hui. Le 11 janvier ne change rien pour eux, mais c’est l’occasion de vérifier.

Adresse IP GTM server side : êtes-vous concerné ?

Trois conditions cumulées vous mettent dans le périmètre :

1. vous avez un conteneur serveur (le changement ne concerne pas les conteneurs web ni le Google tag côté navigateur, d’après l’email) ;
2. ce conteneur contient au moins un tag Google Ads, Floodlight, DV360 ou SA360 ;
3. vous comptiez sur le masquage du conteneur, ou vous n’avez jamais regardé.

Le test prend dix minutes. Ouvrez votre conteneur serveur en mode aperçu, envoyez un événement de conversion depuis votre site, puis sélectionnez le tag Google Ads dans la colonne de gauche. Dans l’onglet de requêtes sortantes, regardez ce qui part vers Google : l’adresse IP du client y figure-t-elle, et sous quelle forme (complète, ou avec le dernier octet à zéro) ? Faites la même chose pour le tag GA4, qui sert de témoin puisqu’il masque partiellement par défaut. Notez le résultat : c’est votre état de départ, celui qui doit rester vrai le 12 janvier.

Si vous êtes passé par un hébergeur (Stape, Addingwell, Taggrs), vérifiez aussi les options qu’il expose côté IP. Certains proposent leurs propres réglages, qui ne remplacent pas une transformation documentée dans le conteneur.

Le volet consentement en Europe

L’IP est une donnée personnelle

La Cour de justice de l’Union européenne l’a établi en 2016 dans l’arrêt Breyer : une adresse IP dynamique peut constituer une donnée personnelle. L’email de Google ne parle pas de l’IP sous cet angle, mais rappelle que les annonceurs doivent avoir les « consentements légalement requis » en place avant la collecte et respecter strictement la politique de consentement de l’UE pour l’EEE (la politique couvre aussi le Royaume-Uni et la Suisse).

Ce changement s’empile sur un autre, plus ancien de quelques mois. Depuis le 3 août 2026, Google exploite l’IP pour la mesure et la personnalisation publicitaires dans l’EEE, ce que je détaille dans Adresse IP Google Ads : ce que le 3 août change pour votre sGTM. Le 3 août, c’était la finalité. Le 11 janvier, c’est la tuyauterie : votre conteneur arrête de filtrer par défaut. Les deux mis bout à bout, l’IP complète d’un visiteur européen arrive chez Google Ads et sert à la personnalisation, sauf si vous intervenez.

Consent mode côté serveur : ce qu’il couvre et ce qu’il ne couvre pas

Le consent mode pilote le comportement des tags Google selon l’état ad_storage, ad_user_data et ad_personalization transmis par le navigateur. C’est votre premier rempart, et il reste indispensable. Mais deux zones grises subsistent.

D’abord, l’email ne dit rien de l’articulation entre le consent mode et ce nouveau traitement de l’IP, et la documentation développeur du consent mode côté serveur ne parle pas de l’IP. Ensuite, depuis le 28 juillet 2025, les tags Floodlight d’un conteneur serveur envoient des requêtes non consenties de serveur à serveur : personne ne sait encore si ces requêtes porteront l’IP complète après le 11 janvier. Tant que Google ne l’a pas documenté, je ne parierais pas sur la réponse la plus confortable.

Masquer l’adresse IP avec une transformation sGTM, pas à pas

L’email désigne les transformations comme le moyen de masquer ces signaux « avant qu’un tag n’accède aux données ». La page d’aide IP address redaction for server-side tagging donne la recette. Elle tient en deux pièces : une variable qui calcule une IP tronquée, et une transformation qui l’injecte à la place de la vraie.

Étape 1 : la variable. Dans votre espace de travail serveur, créez un modèle de variable personnalisé avec ce code :

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

Cette API, ajoutée récemment à la référence des API server-side, met à zéro le dernier octet d’une adresse IPv4 et les 80 derniers bits d’une IPv6. On parle de masquage partiel : l’IP garde sa valeur de géolocalisation approximative, elle perd sa précision individuelle.

Étape 2 : la transformation. Dans Transformations, créez une transformation de type « Augment event » qui remplace le champ ip_override par la variable de l’étape 1.

Étape 3 : le périmètre. Dans les tags concernés, sélectionnez explicitement les tags Google Ads, Floodlight, et tout tag tiers qui lit ip_override. Ne laissez pas la transformation s’appliquer « à tout » sans savoir ce que ça recouvre.

Étape 4 : les tags tiers qui lisent ailleurs. Certains templates ne lisent pas ip_override mais un champ maison ou un en-tête. Inspectez leur requête sortante en aperçu, repérez le champ qui porte l’IP, et créez une seconde transformation dédiée à ce champ.

Étape 5 : la recette. Repassez en aperçu, déclenchez une conversion, et vérifiez dans la requête sortante de chaque tag que l’IP se termine bien par .0 (en IPv4). Puis publiez.

Une précision qui compte : la page d’aide documente un masquage partiel, pas une suppression. Si votre DPO exige qu’aucune IP ne parte, même tronquée, vers les tags publicitaires, il faudra tester une transformation « Exclude parameters » sur ip_override et vérifier en aperçu que le tag ne retombe pas sur une autre source d’IP. Ce cas n’est pas documenté par Google à ce jour : testez, ne supposez pas.

Garder l’IP pour Google Ads : quand c’est défendable

Je ne vais pas vous dire que masquer est toujours la bonne réponse. L’IP complète améliore le rapprochement entre clics et conversions, nourrit le Smart Bidding et aide au filtrage du trafic invalide. Hors d’Europe, sur un trafic où le cadre légal le permet, laisser Google Ads la recevoir peut être un choix rationnel.

Ce qui n’est pas défendable, c’est de la transmettre par défaut parce que personne n’a regardé. Si vous choisissez de garder l’IP complète, faites-le en conscience : votre CMP et votre politique de confidentialité doivent couvrir ce traitement, votre consent mode doit être propre, et vous pouvez conditionner la transformation à la région ou à l’état de consentement (une variable de consentement ou de pays dans les conditions de la transformation). Et pour compenser la perte de signal là où vous masquez, appuyez-vous sur des données first-party collectées sous consentement, comme les Enhanced Conversions en server-side.

Pour mémoire, ce n’est pas la première fois que Google rebranche discrètement votre sGTM sur ses propres besoins : j’en parlais déjà à propos des parallel browser signals. Le server-side vous donne du contrôle, à condition de relire régulièrement ce que Google change par défaut. Même vigilance pour vos uploads de données clients, maintenant que Data Manager rend le hachage SHA-256 facultatif le 16 novembre.

Checklist avant le 11 janvier 2027

Avec le gel des déploiements du Black Friday et des fêtes, la vraie fenêtre de travail est plus courte qu’il n’y paraît. Planifiez maintenant :

• Inventorier les conteneurs serveur et, dans chacun, les tags Google Ads, Floodlight, DV360, SA360 et tiers.
• Faire le test en aperçu et noter, tag par tag, ce qui part aujourd’hui (IP complète, tronquée, absente).
• Identifier pour chaque tag tiers le champ qui porte l’IP (ip_override ou autre).
• Faire trancher par votre DPO : IP complète, masquée partiellement ou retirée, éventuellement selon la région.
• Créer la variable getAnonymizedIpAddress et la ou les transformations « Augment event », limitées aux tags choisis.
• Recetter en aperçu, publier, et documenter la version du conteneur.
• Revérifier en aperçu après le 11 janvier : c’est le seul moyen de confirmer que la nouvelle logique de Google respecte bien votre transformation.
• Surveiller la page d’aide de Tag Manager et ses notes de version, qui devraient finir par documenter le changement et l’éventuel réglage d’opt-out.

Si vous n’avez pas encore de conteneur serveur et que vous hésitez à franchir le pas, mon guide GTM Server-Side pose les bases. Ce changement n’est pas une raison de fuir le server-side : c’est une raison de le piloter, plutôt que de le laisser tourner en pilote automatique réglé par Google.