Google Tag Gateway (GTG) : Guide Complet
Google Tag Gateway expliqué : first-party serving via Cloudflare, Akamai ou Fastly, différence réelle avec le server-side GTM, mise en place et le point de vigilance RGPD sur le consentement.
Dans ce guide
Google Tag Gateway for advertisers (GTG) est passé en disponibilité générale le 5 mai 2025, avec Cloudflare comme partenaire de lancement. C'est une brique récente, encore mal comprise, souvent confondue avec le server-side Google Tag Manager alors que les deux répondent à des besoins différents. Voici ce qu'elle fait réellement, ce qu'elle ne fait pas, et un point de vigilance RGPD que Google ne met pas en avant lui-même.
Ce que GTG change concrètement
GTG route le chargement des scripts Google (Google Tag, tag Google Ads, Floodlight/Campaign Manager 360) et l'envoi des événements de mesure via l'infrastructure de votre propre site, plutôt que directement depuis les serveurs de Google. En pratique, les requêtes réseau semblent sortir de votre domaine au lieu de googletagmanager.com ou google-analytics.com. Le script continue de s'exécuter dans le navigateur exactement comme avant, aucune modification du code de tag existant sur vos pages n'est nécessaire, c'est purement un changement d'origine réseau apparente.
Les hébergeurs partenaires, et l'option manuelle
Plusieurs infrastructures proposent une activation en quelques clics :
Cloudflare, partenaire de lancement, intégration directe depuis le dashboard Cloudflare.
Akamai, ajouté comme partenaire le 29 janvier 2026, avec détection automatique de zone.
Fastly, avec son "Ad Tag Gateway" lancé le 8 avril 2026.
Google Cloud via un Global external Application Load Balancer.
En dehors de ces intégrations "un clic", une configuration manuelle reste possible sur tout CDN, load balancer ou serveur web configurable (Apache, Nginx, LiteSpeed, AWS CloudFront...), ou en s'appuyant sur un conteneur server-side GTM déjà en place, une configuration que Google documente sous le nom de "dependency serving".
GTG n'est pas du server-side GTM, et c'est une vraie limite
La confusion est fréquente, mais les deux mécanismes ne se substituent pas l'un à l'autre :
GTG ne touche que l'écosystème Google (GA4, Google Ads, Floodlight). Les cookies continuent d'être posés en JavaScript côté navigateur, donc l'Intelligent Tracking Prevention de Safari continue de s'appliquer sur ces cookies exactement comme avant : GTG améliore la fiabilité de la remontée réseau (moins de blocage par les ad blockers et certains filtrages), il ne rend pas vos cookies invisibles à ITP. Ce n'est pas un tag server-side à proprement parler.
Un vrai conteneur server-side GTM va plus loin : les cookies peuvent être posés via des en-têtes HTTP, donc hors de portée d'ITP, les événements peuvent partir en server-to-server vers n'importe quelle plateforme (Meta, TikTok, Pinterest...) et pas seulement Google, et vous gardez la main sur la transformation et l'enrichissement des données dans vos propres tags clients.
Limite claire à retenir avant de vendre GTG comme une solution server-side à un client : impossible d'y exécuter un tag tiers personnalisé ou de faire de la transformation de données arbitraire, GTG reste cantonné à l'écosystème Google.
Installer GTG avec Cloudflare, pas à pas
Deux points d'entrée possibles, au choix :
Depuis Google (Google Ads, Google Analytics, Campaign Manager 360 ou Google Tag Manager) : ouvrir l'écran "Google tag gateway" dans les paramètres du tag Google, cliquer sur "Sign into Cloudflare" pour connecter le compte, puis dans le panneau "Choose website domains" sélectionner le ou les domaines à activer, "Done" puis "Complete setup".
Depuis Cloudflare : ouvrir la page Google Tag Gateway du dashboard Cloudflare, sélectionner le domaine, activer, renseigner l'ID du tag Google ou du conteneur GTM concerné, choisir un chemin de mesure ("measurement path") pas déjà utilisé par ailleurs sur le site, puis sauvegarder.
Deux prérequis documentés à vérifier avant d'activer : avoir déjà un tag Google actif sur le site (GTG ne crée rien, il relaie l'existant), et si le site utilise le Consent Mode, désactiver l'installation automatisée du script pour retagger manuellement, l'intégration Cloudflare en un clic ne gérant l'insertion automatique que pour un nouveau tag, pas un script déjà présent sur la page.
Les chiffres annoncés, à prendre pour ce qu'ils sont
Google communique un uplift de signaux de 11 % chez les annonceurs ayant configuré GTG, chiffre repris lors du passage en disponibilité générale. Fastly, de son côté, annonce 14 % d'uplift de signal pour sa propre intégration. Ce sont des chiffres communiqués par Google et par un partenaire d'infrastructure qui a un intérêt commercial direct à vendre son offre GTG, pas des mesures indépendantes. Je n'ai trouvé aucune étude tierce, non liée à Google ou à un CDN partenaire, publiant une mesure chiffrée de l'impact réel sur le taux de conversions observées. Ça ne veut pas dire que le gain n'existe pas, ça veut dire qu'il faut le vérifier sur votre propre compte plutôt que de le prendre pour acquis.
Le point de vigilance RGPD que les CMP documentent
Plusieurs éditeurs de CMP (Cookiefirst, Pandectes, UniConsent) documentent un problème technique précis, pas une accusation vague : quand GTG est activé via l'injection automatique côté CDN en un clic, le script Google peut se charger et déclencher un événement avant même que votre CMP n'ait eu le temps de poser ses valeurs de consentement par défaut. Ces éditeurs appellent ça un "late consent signal". Dans les régions à opt-in comme l'UE, un traceur non essentiel ne doit s'activer qu'après consentement explicite, donc un tag qui se déclenche avant que le CMP n'ait pu répondre est un vrai point d'attention RGPD, pas un détail théorique.
Google ne communique pas publiquement sur ce point à ma connaissance, cette analyse vient des éditeurs de CMP eux-mêmes, à traiter comme un signal de vigilance documenté plutôt que comme une position officielle de Google. Leur recommandation converge : activer le Consent Mode avancé plutôt que de considérer GTG comme un simple gain de performance à activer sans y repenser, ou centraliser les tags dans un conteneur GTM unique où l'ordre de chargement reste sous votre contrôle plutôt que délégué à une injection automatique côté CDN.
Une implémentation plus complexe à discuter ?
Discuter de votre trackingUn projet similaire à cadrer ? Parlons-en.
Freelance web trackingArticles liés
Pour aller plus loin sur votre projet
Tracking server-side
Tracking server-side
Fiabilisez vos conversions et reprenez le contrôle sur les données envoyées à GA4, Meta et Google Ads.
Voir l'expertiseQuestions fréquemment posées
Google Tag Gateway remplace-t-il le server-side Google Tag Manager ?
Non. GTG ne route que les tags Google (GA4, Google Ads, Floodlight) via votre domaine, sans transformer vos cookies en cookies server-side ni permettre l'envoi vers des plateformes tierces (Meta, TikTok...). Un vrai conteneur server-side GTM reste nécessaire pour ces cas d'usage.
GTG protège-t-il contre l'Intelligent Tracking Prevention (ITP) de Safari ?
Pas directement. Les cookies continuent d'être posés en JavaScript côté navigateur avec GTG, donc ITP continue de s'appliquer normalement. GTG améliore surtout la résilience réseau face aux ad blockers et certains filtrages, ce n'est pas un contournement d'ITP.
Quels hébergeurs proposent une activation de GTG en un clic ?
Cloudflare (partenaire de lancement), Akamai (depuis janvier 2026), Fastly via son Ad Tag Gateway (depuis avril 2026), et Google Cloud via un Load Balancer. Une configuration manuelle reste possible sur tout autre CDN ou serveur web configurable.
Le déploiement automatique de GTG pose-t-il un problème de consentement ?
Plusieurs éditeurs de CMP documentent un risque de 'late consent signal' : le script Google peut se charger avant que la CMP ait posé ses valeurs de consentement par défaut lors d'une activation en un clic côté CDN. La recommandation documentée est d'activer le Consent Mode avancé plutôt que de traiter GTG comme un simple gain de performance sans vérification.