Adresse IP Google Ads : ce que le 3 août change pour votre sGTM

Votre serveur sGTM transmet déjà l’adresse IP de vos visiteurs à Google Ads. Ça, ce n’est pas nouveau. Ce qui est nouveau, c’est que depuis le 3 août 2026, cette adresse IP n’est plus seulement un détail technique de routage : elle sert désormais à la mesure et à la personnalisation publicitaire pour les utilisateurs de l’EEE, du Royaume-Uni et de la Suisse. Et cette bascule d’usage fait entrer l’adresse IP dans le périmètre du consentement Google Ads, sans qu’aucune alerte ne s’affiche dans vos interfaces. Le paradoxe, c’est que la migration server-side, vendue comme un gain de contrôle, est précisément l’architecture qui vous expose le plus. On va voir pourquoi, comment le tester en cinq minutes, et quoi corriger selon votre setup.

Un cadrage avant de commencer : cet article décrit ce que fait Google et ce que la technique permet ou pas. La qualification juridique de votre situation (êtes-vous en conformité, faut-il couper, sur quelle base légale) relève de votre DPO et de votre conseil. Je donne les faits et la mécanique, pas un avis juridique.

Ce qui a changé le 3 août, et ce qui n’a pas changé

Le point le plus mal compris de toute cette histoire tient en une phrase : l’adresse IP n’a pas changé, c’est sa finalité qui change. Google recevait déjà l’IP de vos visiteurs à chaque requête, parce que c’est physiquement nécessaire pour qu’un serveur réponde à un navigateur. Ce que Google annonce, c’est un nouvel usage de cette même donnée.

Voici la bascule, finalité par finalité :

Les trois premières lignes relèvent d’usages dits nécessaires, qui ne déclenchent pas d’obligation de consentement. Les deux dernières, si. C’est toute la différence : identifier un appareil à partir de son IP pour lui servir de la publicité personnalisée, ce n’est plus du routage, c’est du traitement soumis à consentement dans l’EEE, au Royaume-Uni et en Suisse. Google elle-même formule l’entrée en vigueur comme le 3 août « ou peu après », donc considérez cette date comme le début d’une fenêtre, pas d’un interrupteur unique.

Feature 3 du TCF : le vrai point de bascule pour le consentement Google Ads

Pour légitimer ce nouvel usage dans l’écosystème européen, Google s’enregistre sous la Feature 3 du Transparency and Consent Framework de l’IAB Europe. Son libellé exact : « Identifier les appareils à partir d’informations transmises automatiquement ». En clair, la Feature 3 couvre le fait de construire un identifiant à partir de ce qu’un appareil envoie tout seul en se connectant, adresse IP et user-agent en tête. C’est exactement ce que Google va faire de votre IP.

Pourquoi ça compte pour vous concrètement : si votre CMP (la plateforme qui gère votre bannière de consentement) n’expose pas la Feature 3 dans sa chaîne TCF, alors le signal de consentement que vous transmettez à Google est incomplet. Vous croyez recueillir un consentement publicitaire complet, mais il manque la brique qui couvre précisément l’usage de l’IP. Et rien, nulle part, ne vous le signale.

Ce sujet est le prolongement direct du basculement de juin sur les signaux ad_user_data et ad_personalization. Si vous ne l’avez pas encore lu, mon guide sur le Consent Mode v2 dans GA4 pose les bases de ces deux signaux : la Feature 3 vient s’empiler par-dessus, sur un identifiant supplémentaire (l’IP) que ces signaux ne suffisent pas à couvrir à eux seuls.

Ce qu’il faut vérifier côté CMP, en une ligne : votre plateforme est-elle certifiée Google et à jour du TCF 2.3, et déclare-t-elle bien la Feature 3 dans la string de consentement ? Si la réponse est non ou « je ne sais pas », c’est votre premier chantier.

Le test en 5 minutes : votre setup transmet-il l’IP sans consentement ?

Assez de théorie. Voici comment savoir si, chez vous, l’IP part vers Google alors que l’utilisateur n’a pas donné son consentement publicitaire. Le test dépend de votre architecture.

Côté web (gtag ou GTM classique). Ouvrez les outils développeur de votre navigateur, onglet réseau, filtrez sur google-analytics.com et googlesyndication.com. Refusez la bannière de consentement, puis rechargez. Inspectez les requêtes de collecte : regardez les paramètres gcs (l’état du Consent Mode) et surtout ad_user_data et ad_personalization. Si ces signaux sont en « denied » mais qu’une requête part quand même vers un endpoint publicitaire, votre IP y est, par construction, puisque toute requête HTTP porte l’IP source.

Côté serveur (sGTM). C’est là que ça se corse, parce que l’inspection réseau du navigateur ne voit rien : la transmission se fait de serveur à serveur, hors de portée des DevTools. Il faut inspecter le conteneur serveur lui-même. Passez votre conteneur en mode preview, déclenchez un événement avec consentement refusé, et regardez la requête sortante vers Google : le tag GA4 côté serveur renseigne par défaut l’IP réelle du client. Vérifiez la présence du champ ip_override et la valeur qu’il porte.

Le point clé à retenir : par défaut, un serveur sGTM voit la vraie IP client (celle du navigateur qui a tapé votre proxy) et la fait suivre à Google. Ce n’est pas un bug, c’est le comportement documenté. Donc si vous n’avez rien configuré de spécifique, la réponse à « est-ce que mon setup transmet l’IP sans couverture de consentement » est très probablement oui.

Trois architectures, trois correctifs

Le correctif dépend entièrement de par où passent vos données. Voici les trois cas, du plus simple au plus exposé.

gtag ou GTM web classique

C’est le cas le plus simple à traiter, parce que tout se joue dans le navigateur. Si votre Consent Mode v2 est correctement câblé et que vos tags Google respectent l’état « denied », les requêtes publicitaires ne partent pas tant que le consentement n’est pas accordé, et donc l’IP ne part pas non plus pour cet usage. Le travail se résume à auditer votre Consent Mode : vérifier que ad_user_data et ad_personalization passent bien à « denied » par défaut, et que votre CMP couvre la Feature 3. Rien de neuf dans la plomberie, tout dans la configuration du consentement.

Google Tag Gateway (mode first-party)

Le Tag Gateway réécrit le nom de domaine de vos requêtes pour les faire passer en first-party, mais il ne change pas la logique de consentement : les signaux Consent Mode restent maîtres. Le piège est ailleurs. Comme je l’expliquais dans mon comparatif Google Tag Gateway vs sGTM, le Tag Gateway est un proxy léger : il transmet, il ne transforme pas. Donc l’IP client traverse le proxy et arrive chez Google comme avant. La couverture repose entièrement sur la qualité de vos signaux de consentement en amont, exactement comme en gtag classique. Auditez le Consent Mode, ne comptez pas sur le proxy pour filtrer quoi que ce soit.

sGTM, le cas le plus exposé

C’est ici que se concentre le risque, pour trois raisons cumulées. D’abord, ip_override : le tag GA4 côté serveur transmet l’IP réelle du client par défaut, et beaucoup de tags publicitaires font de même. Ensuite, les transformations et variables custom : un conteneur serveur un peu travaillé peut réinjecter l’IP dans des champs que vous ne surveillez pas. Enfin, les réglages spécifiques par région : sans configuration explicite pour l’EEE, votre serveur traite un visiteur berlinois exactement comme un visiteur new-yorkais.

Le correctif concret consiste à ne pas transmettre l’IP client vers les endpoints publicitaires Google tant que le consentement publicitaire n’est pas accordé, ce qui passe le plus souvent par une gestion conditionnelle de ip_override en fonction du signal de consentement reçu du client. Si vous n’êtes pas encore en server-side et que vous découvrez ces notions, mon guide GTM Server-Side pose l’architecture d’ensemble avant d’entrer dans ces réglages fins.

Un mot sur les hébergeurs, parce que la question revient toujours : le traitement de l’IP dépend en partie de votre hébergeur sGTM et des réglages qu’il expose. Certains proposent des options de gestion de l’IP plus fines que d’autres. J’ai comparé les principaux dans Stape vs Addingwell vs Taggrs : vérifiez ce que le vôtre permet côté transmission d’IP avant de conclure que vous êtes couvert.

Le piège : l’anonymisation IP de GA4 ne couvre pas Google Ads

Voici l’erreur que je vois le plus souvent, et elle est vicieuse parce qu’elle donne un faux sentiment de sécurité. « J’ai activé l’anonymisation IP dans GA4, donc je suis tranquille. » Non.

L’anonymisation IP de GA4 agit sur le chemin de données GA4 : elle tronque l’IP avant stockage et usage côté Analytics. Mais le flux GA4 vers Google Ads, et surtout les tags Google Ads eux-mêmes (le tag de conversion, le remarketing), empruntent un chemin distinct. Google Ads reçoit sa propre requête, avec sa propre IP, indépendamment de ce que fait GA4 de la sienne. Anonymiser l’IP côté GA4 ne retire pas l’IP de la requête que le navigateur, ou votre serveur, envoie aux serveurs publicitaires de Google.

Autrement dit : deux chemins de données, deux traitements de l’IP. Régler l’un ne règle pas l’autre. C’est précisément parce que ces deux chemins sont distincts que le sujet de cet article n’est pas un doublon du Consent Mode v2 : là, on parlait du flux GA4 vers Ads gouverné par ad_storage ; ici, on parle d’un identifiant, l’IP, transmis y compris hors GA4.

Ce que vous perdez si vous coupez, et comment le chiffrer

Couper la transmission de l’IP pour les visiteurs non consentants a un coût, et il faut le regarder en face plutôt que de décider à l’aveugle. L’IP participe au matching (rapprocher une conversion d’un clic), à la qualité des enhanced conversions, et à la modélisation. Moins de signal déterministe, c’est mécaniquement moins de conversions attribuées et un Smart Bidding un peu moins nourri sur le segment EEE non consentant.

Le réflexe à éviter, c’est de reprendre un pourcentage tout fait lu sur un blog. Votre perte réelle dépend de votre part de trafic EEE, de votre taux de consentement, et de la richesse de vos autres signaux first-party. Voici comment la chiffrer sur vos propres données plutôt que d’inventer un chiffre :

1. Isolez votre segment EEE non consentant (part du trafic, part des conversions modélisées aujourd’hui).
2. Mesurez la dépendance actuelle de votre matching à l’IP : comparez vos taux de correspondance de conversions avant et après si vous testez la coupure sur une fenêtre courte.
3. Rapportez la perte de conversions attribuées au volume total : une perte de 30 % sur un segment qui pèse 10 % de vos conversions, ce n’est pas la même décision qu’une perte de 30 % sur un segment qui en pèse la moitié.

Et surtout, ne raisonnez pas comme si l’IP était votre seul levier. Renforcer vos signaux first-party compense une partie de la perte : les enhanced conversions en server-side rehaussent le matching avec des données que vous collectez sous consentement propre, et Google Ads Data Manager ouvre des connexions first-party qui ne dépendent pas de l’IP. La bonne question n’est pas « est-ce que je perds du signal », c’est « où je vais rechercher ce signal ailleurs, proprement ».

À remettre dans son contexte, sans confondre les sujets

Ce revirement n’arrive pas de nulle part. Google avait promis un futur sans identifiants déterministes, puis a fait marche arrière : la fin du Privacy Sandbox laisse un vide, et l’IP est un signal déterministe commode pour le combler. Vu comme ça, exploiter l’IP est moins une surprise qu’une conséquence logique du recul sur le cookieless.

Attention en revanche à ne pas mélanger deux sujets qui vont en sens inverse. Safari masque l’IP réelle via iCloud Private Relay, comme je le détaille dans Safari 27 et votre tracking : côté navigateur Apple, vous voyez moins d’IP exploitables. Google, de son côté, décide d’en exploiter davantage. Les deux mouvements coexistent et ne se compensent pas : sur Safari, Google aura moins de matière ; ailleurs, il en aura plus. Ne tirez pas de conclusion globale d’un seul des deux.

Checklist de sortie

Avant de refermer le sujet, le minimum à valider :

• Votre CMP est certifiée Google, à jour du TCF 2.3, et déclare la Feature 3.
• ad_user_data et ad_personalization sont bien à « denied » par défaut, et pilotés par le consentement réel.
• Vous avez fait le test réseau (web) ou le test preview serveur (sGTM) pour vérifier ce qui part sans consentement.
• En sGTM, la transmission de ip_override vers les endpoints publicitaires est conditionnée au consentement, avec un réglage spécifique EEE.
• Vous avez chiffré votre perte potentielle sur vos propres données, et identifié les signaux first-party de compensation.
• L’arbitrage final (couper, sur quelle base, avec quelle documentation) est validé par votre DPO.

Pour aller plus loin sur l’hygiène de configuration en amont, mon audit GA4 des 11 erreurs de configuration balaie les réglages qui, mal posés, amplifient ce genre de problème.

Dernier rappel, parce qu’il est important : rien de ce qui précède n’est un avis juridique. Je décris ce que Google fait, ce que la technique permet, et comment le vérifier chez vous. La décision de couper ou non, et sa justification au regard du RGPD, appartient à votre DPO et à votre juriste. Mon rôle s’arrête à vous donner une image claire de ce que votre setup transmet réellement, pour que cette décision se prenne les yeux ouverts.