À partir du 11 janvier 2027, les sites qui utilisent Google Tag Manager côté serveur, le « GTM server side », transmettront par défaut l’adresse IP complète de leurs visiteurs aux outils publicitaires de Google. Cette adresse, le numéro qui identifie la connexion internet d’un visiteur, est le plus souvent une donnée personnelle en droit européen. Le propriétaire du site pourra toujours la masquer s’il le configure lui-même. Google l’annonce dans une notice envoyée par e-mail à ses clients et rendue publique le 2 novembre 2026.
La notice s’intitule « Updates to network signal processing in server-side tagging », soit « Mises à jour du traitement des signaux réseau dans le taggage côté serveur » (notre traduction). Elle ne porte aucune date.
Adriaan Dekker, consultant Google Ads indépendant installé à Rotterdam, l’a publiée sur LinkedIn le 2 novembre. Sur son blog, il la présente comme une annonce de service obligatoire envoyée le même jour aux utilisateurs de Tag Manager. Trois sites spécialisés l’ont reprise : PPC Land le 2 novembre, Search Engine Journal le 3 et Search Engine Roundtable le 4.
Un conteneur installé sur le serveur de l’annonceur
Google Tag Manager sert à installer sur un site les balises de mesure d’audience et de publicité : Google Analytics, Google Ads ou des outils d’autres fournisseurs. Une balise est un petit code qui envoie des données à l’un de ces outils. Dans la version classique, le conteneur qui regroupe ces balises fonctionne dans le navigateur du visiteur et envoie lui-même les données aux outils. Dans la version côté serveur, le navigateur envoie les données à un conteneur hébergé par l’annonceur, qui les redistribue ensuite.
La documentation de Google résume la différence : un conteneur serveur « ne s’exécute pas dans le navigateur de l’utilisateur ni sur son téléphone », il « s’exécute sur un serveur que vous contrôlez ». Seul son propriétaire a accès aux données tant qu’il ne choisit pas de les transmettre. C’est donc sur ce serveur que se décide le sort de l’adresse IP.
Les quatre changements de la notice
Selon la notice, les conteneurs serveur passeront d’un masquage de l’adresse IP réglé « pour l’ensemble du conteneur » à un traitement « balise par balise » (notre traduction). Elle en détaille quatre effets.
Les balises qui envoient des données à Google Ads, Display & Video 360, Search Ads 360 et Campaign Manager 360 « accepteront désormais l’adresse IP complète ». Google Ads est la régie publicitaire de Google. Les trois autres appartiennent à la Google Marketing Platform, sa suite d’outils pour acheter de l’espace publicitaire, gérer les campagnes sur les moteurs de recherche et les mesurer.
Les balises Google Analytics, elles, « continueront d’appliquer le masquage de l’adresse IP ». Celles d’autres fournisseurs garderont leur propre contrôle sur les signaux qu’elles acceptent. Dernier effet : les transformations, une fonction du conteneur serveur qui modifie les données avant qu’une balise les lise, pourront masquer ces signaux avant tout accès.
Google justifie le changement par des « améliorations de la mesure et de la personnalisation des annonces ». La notice ajoute que la mise à jour intègre des « technologies renforçant la confidentialité ». La mise à jour filtrerait aussi le spam et le trafic invalide (robots, faux clics) et améliorerait les performances des campagnes.
La notice rappelle aussi les obligations de l’annonceur, car le changement implique le traitement de signaux réseau comme l’adresse IP. Avant toute collecte, l’annonceur doit s’assurer que les visiteurs sont informés et que « les consentements requis par la loi » sont en place. Dans l’Espace économique européen, il doit « respecter strictement » les règles de Google sur le consentement des utilisateurs dans l’Union européenne.
La méthode de masquage publiée par Google
Pour couper l’envoi de l’adresse complète, la notice renvoie à des « instructions détaillées de désactivation » (notre traduction), dans un article d’aide qu’elle ne nomme pas. L’article qui traite le sujet, « IP address redaction for server-side tagging », n’existe qu’en anglais et ne mentionne pas la date du 11 janvier.
L’article décrit un réglage en deux parties. D’abord, une variable personnalisée, un petit bloc de code, appelle la fonction getAnonymizedIpAddress, qui masque l’adresse. Ensuite, une transformation remplace par cette adresse masquée le champ ip_override, qui porte l’adresse IP de chaque événement mesuré. L’administrateur choisit enfin les balises concernées et vérifie le résultat en mode aperçu, l’outil de test de Tag Manager, avant de publier.
La référence technique de Google, sa documentation pour développeurs, détaille le calcul. Sur une adresse IPv4, le format historique en quatre nombres, la fonction remplace le dernier par un zéro : 198.51.100.42 devient 198.51.100.0. Sur une adresse IPv6, le format plus récent, elle garde les 48 premiers bits sur 128 et met les 80 autres à zéro. L’article d’aide appelle le résultat une adresse IP « partiellement masquée ».
La fonction est absente de la copie de cette page conservée le 12 octobre 2026 par l’Internet Archive, un service d’archivage du web. La page en ligne la décrit et affiche une mise à jour au 30 octobre.
Selon l’article d’aide, certaines balises d’autres fournisseurs lisent l’adresse IP ailleurs que dans ip_override. Elles la prennent par exemple dans un en-tête, une donnée technique jointe à chaque envoi, ou dans un paramètre d’événement. L’article prévoit alors une transformation qui vise le champ utilisé par la balise. Il rappelle que les balises serveur de Google Analytics appliquent déjà un masquage partiel par défaut.
Une donnée personnelle en droit européen
En droit européen, une adresse IP est le plus souvent une donnée personnelle, soit une information liée à une personne identifiable. La CNIL, l’autorité française de protection des données, la cite parmi ces données dans sa définition du terme.
La Cour de justice de l’Union européenne a tranché le cas des adresses IP dynamiques, qui changent à chaque connexion, le 19 octobre 2016 dans l’arrêt Breyer (affaire C-582/14). Pour l’exploitant d’un site, une telle adresse est une donnée personnelle à une condition : qu’il dispose de moyens légaux de faire identifier le visiteur. Cette identification passe par les informations que détient le fournisseur d’accès du visiteur.
Les règles de Google sur le consentement des utilisateurs dans l’Union européenne couvrent l’Espace économique européen, le Royaume-Uni et la Suisse. Elles imposent un consentement légalement valable pour les cookies, là où la loi l’exige. Un consentement est aussi requis pour collecter, partager et utiliser des données personnelles afin de personnaliser les annonces.
L’annonceur doit conserver la trace de ces consentements et identifier chaque intervenant susceptible de collecter, de recevoir ou d’utiliser ces données. En cas de manquement, Google se réserve le droit de limiter ou de suspendre l’usage de son produit, ou de résilier le contrat.
Les points laissés dans l’ombre
Google ne nomme aucune des technologies de confidentialité qu’il invoque et ne publie aucun chiffre sur les gains de performance promis. Le 5 novembre, les notes de version de Tag Manager, la page qui liste les nouveautés de l’outil, ne mentionnaient pas le changement. Leur dernière entrée datait du 12 octobre.
Search Engine Journal relève d’autres manques. La notice n’explique pas comment se règle aujourd’hui le masquage pour l’ensemble du conteneur. Elle ne dit pas comment le changement s’articule avec le mode Consentement. Ce mécanisme transmet à Google le choix du visiteur sur les cookies, pour que les balises s’y adaptent.
La notice ne dit rien non plus des données envoyées sans consentement depuis juillet 2025 par les balises Floodlight des conteneurs serveur, ni du lieu et de la durée de conservation des adresses complètes. Floodlight est l’outil de Campaign Manager 360 qui compte les conversions, comme les achats.
PPC Land note que les « signaux réseau » ne sont pas définis : l’adresse IP est le seul exemple donné.
Un changement de même sens se prépare côté Google Analytics. Selon une page d’aide sur la mise à jour des contrôles de données, les adresses IP que la balise Google et le SDK collectent automatiquement seront chiffrées et transmises au compte Google Ads associé. Le SDK est le kit de développement de Google pour les applications. Google dit qu’il communiquera les dates exactes plus tard dans l’année.
Notre analyse
Le changement porte sur un réglage par défaut. Jusqu’ici, une seule règle de masquage pouvait valoir pour tout le conteneur. Dès le 11 janvier, les balises publicitaires de Google recevront l’adresse complète, sauf si le propriétaire du conteneur les en empêche lui-même.
Les en empêcher demande d’installer une transformation dans le conteneur. Un seul article d’aide, en anglais, décrit la méthode. Elle repose sur une fonction qui ne figurait pas dans la référence technique de Google le 12 octobre.
Le changement touche les sites qui font passer leurs balises Google Ads ou Floodlight par un conteneur serveur, y compris ceux qui reçoivent des visiteurs européens. La notice laisse à l’annonceur la responsabilité juridique : informer les visiteurs, recueillir leur consentement là où la loi l’exige, suivre les règles de Google pour l’Union européenne. Elle ne dit pas si l’adresse complète partira aussi quand le visiteur a refusé les cookies publicitaires. Pour un site européen, c’est la question qui compte le plus.
Google Ads a déjà activé d’autres fonctions par défaut cet automne. En octobre, deux sont apparues : l’ajout automatique des promotions de l’annonceur à ses annonces, en place depuis le 12 octobre, et l’ajout des vidéos en ligne de l’annonceur aux nouvelles campagnes Performance Max, signalé le 23 octobre. Performance Max désigne des campagnes Google Ads largement automatisées. L’annonceur doit désactiver ces fonctions lui-même.
Le changement des conteneurs serveur n’est passé que par un e-mail aux clients, sans billet de blog ni note de version. Même discrétion pour le filtrage des recherches de marque par Performance Max, ajouté sans annonce à une page d’aide et repéré le 2 novembre.
Reste à voir si Google inscrira le changement dans ses notes de version et datera son article d’aide avant le 11 janvier. Deux questions demeurent sans réponse : ce que devient l’adresse IP des visiteurs qui refusent leur consentement, et la date du chiffrement des adresses IP côté Google Analytics.
Sources
- Notice Google « Updates to network signal processing in server-side tagging », reproduite par Adriaan Dekker, LinkedIn, 2 novembre 2026
- IP address redaction for server-side tagging, Aide Tag Manager (Google), consultée le 5 novembre 2026
- API de taggage côté serveur (getAnonymizedIpAddress), Google for Developers, mise à jour du 30 octobre 2026
- Règles relatives au consentement de l’utilisateur dans l’Union européenne, Google, consultées le 5 novembre 2026
- Modifications apportées aux paramètres de traitement des données Google Analytics, Aide Google Analytics, consultée le 5 novembre 2026
- Arrêt dans l’affaire C-582/14 Patrick Breyer/Bundesrepublik Deutschland, communiqué de presse n° 112/16, Cour de justice de l’Union européenne, 19 octobre 2016
- Google Ad Tags In Server-Side GTM To Get Full IP Addresses, Search Engine Journal, 3 novembre 2026
- Google ad tags gain full visitor IP addresses in server-side GTM in 2027, PPC Land, 2 novembre 2026
Image d’en-tête : schéma MACCUS, données de la notice Google « Updates to network signal processing in server-side tagging » (novembre 2026)
