Le Google Tag Gateway charge les scripts Google depuis ton propre domaine au lieu des serveurs de Google. Tes balises passent de tiers à first-party et redeviennent difficiles à bloquer. C'est officiel, c'est gratuit, et c'est disponible aujourd'hui. Mais sur les deux sites que j'ai audités, un seul récupérait vraiment ses conversions : l'autre affichait un statut vert et ne renvoyait aucune donnée. Voici comment l'activer, et surtout comment vérifier que le tien fait son travail.

C'est un des chantiers que je traite en freelance Google Tag Manager, et celui qui rapporte le plus vite quand il est bien fait.

Ce qui change exactement

Avant, ton conteneur se chargeait depuis googletagmanager.com. Après, il se charge depuis tondomaine.com/metrics/?id=GTM-XXXX.

Imagine un videur à l'entrée. Ton script arrivait en uniforme d'une société extérieure : facile à refouler. Maintenant il porte le tien.

  • Le tag ne change pas de fonction, il change d'adresse d'expédition.
  • Ce n'est pas un contournement gris : Google le documente officiellement, avec deux voies d'implémentation, un CDN ou un serveur de tagging.
  • La règle : un script servi depuis ton domaine cesse d'être une cible facile pour les bloqueurs et les restrictions navigateur.

Il est déjà disponible

C'est la question qui revient le plus souvent en français, et elle part d'une fausse prémisse. Le gateway n'est pas à venir : l'intégration Cloudflare en un clic fonctionne, la documentation Google est en ligne et maintenue, et des sites français tournent dessus.

Où en sont les intégrations, vérifié en août 2026 :

  • Cloudflare : en un clic, la voie la plus simple et la plus répandue.
  • Google Cloud : disponibilité générale depuis le 1er juin 2026. Attention, il faut le load balancer applicatif externe global : le classique n'est pas supporté.
  • Akamai et Fastly : livrés, intégrés dans l'interface Google depuis mai 2026, mais encore étiquetés beta dans la documentation.
  • Amazon CloudFront : supporté depuis juin 2026, avec un parcours guidé dans Tag Assistant.
  • Webflow et Duda : gateway actif par défaut sur les tags posés via l'intégration native. Trois réserves : incompatible avec une pose en code personnalisé, republication du site nécessaire si l'identifiant était déjà en place, et indisponible si tu exportes ton site pour l'héberger ailleurs.

Shopify, Wix, Squarespace et WordPress ont l'intégration Google tag, mais je n'ai trouvé aucune activation par défaut du gateway chez eux à ce jour.

Le coût

La fonctionnalité est gratuite. Ce qui peut coûter, c'est l'infrastructure qui la porte.

  • Sur Cloudflare : gratuit, tu utilises le plan que tu as déjà. Coût marginal nul.
  • Sur un autre CDN : gratuit côté gateway, variable selon ton CDN et ton volume.
  • Avec un serveur de tagging : gratuit côté gateway, tu paies le serveur cloud.

Est-ce que ça vaut le coup pour toi

Une seule question compte : est-ce que tu perds des conversions aujourd'hui ?

  • Tu es concerné si une part notable de ton trafic est sur Safari ou iOS, si ton audience est technophile donc équipée de bloqueurs, ou si l'écart entre tes conversions plateforme et tes ventes réelles se creuse sans explication.
  • Tu peux attendre si ton tracking a des problèmes plus en amont : événements mal déclarés, consentement bancal, doublons. Le gateway transporte mieux une mesure juste, il ne répare pas une mesure fausse.
  • En e-commerce, l'effet est immédiat : des transactions qui n'étaient plus attribuées le redeviennent.
  • En leadgen, l'effet est indirect mais souvent plus rentable : un signal plus complet nourrit mieux les enchères automatiques, donc le CPA se stabilise avant même que le volume bouge.

Sur les chiffres qui circulent, je suis franc. Google communique une moyenne de +14 % de conversions, et désormais « jusqu'à 7 % de CPA en moins ». Les deux viennent de la partie qui vend la fonctionnalité, donc des arguments commerciaux, pas une espérance de résultat. Les études de cas publiées, un assureur autour de 15 à 30 % de conversions récupérées, une marque cosmétique autour de 22 %, sont des cas sélectionnés : elles prouvent qu'un tel résultat est possible, jamais qu'il est probable chez toi. Personne ne publie les déploiements qui n'ont rien changé.

Le seul chiffre qui vaut quelque chose est celui que tu mesures sur ton compte, avant et après.

Quelle voie choisir

Situe-toi en trois questions.

  • Aucun tag installé ? Pose le Google tag et un CDN, le gateway s'active dans la foulée. Rien à défaire, c'est le scénario le plus simple.
  • Un tag client-side classique ? Tout dépend de ton CDN. Sur Cloudflare, intégration en un clic. Sur un autre CDN, implémentation manuelle mais documentée. Sans CDN, tu choisis entre passer sur un CDN gratuit ou monter un serveur de tagging.
  • Déjà un serveur de tagging ? Tu n'installes rien, tu fais passer ton service de tiers à first-party. C'est le chemin le plus court vers le meilleur résultat.

Mon avis, et il est tranché : si tu es sur Cloudflare et que tu hésites, prends l'intégration en un clic aujourd'hui. Le serveur de tagging est un meilleur outil, mais c'est un projet. Un bénéfice réel vaut mieux qu'un chantier parfait qui attend.

Activer via Cloudflare

Quelques clics, sans toucher au code : la réécriture des balises a lieu au niveau du edge.

Un point contre-intuitif d'abord. Google précise que le code source de ta page affichera la bonne URL first-party même si tes fichiers d'origine pointent encore vers googletagmanager.com. Ne t'inquiète pas si ton HTML source n'a pas bougé : ce qui compte est ce que le visiteur reçoit.

L'inverse, lui, est un vrai mode d'échec. Si la page livrée au visiteur référence encore googletagmanager.com, la réécriture ne s'est pas déclenchée. C'est documenté en communauté, notamment avec des snippets en protocole relatif (//www.googletagmanager.com/...). Dans ce cas, va vérifier la configuration de la zone.

Activer par re-tag manuel

Tu remplaces la source de chaque script Google par ton chemin de mesure. La syntaxe officielle utilise un chemin relatif, sans nom de fichier :

  • Pour Google Tag Manager : j.src='/metrics/?id='+i+dl;
  • Pour gtag : <script async src="/metrics/?id=G-XXXXXXX">

Trois détails qui évitent de perdre du temps :

  • Évite /metrics/gtm.js?id=.... Ça fonctionne, mais ça conserve des motifs (/gtm.js, .js?id=GTM-) que les règles de blocage reconnaissent. Tu perds une partie du bénéfice pour rien.
  • Laisse l'iframe <noscript> telle quelle. Elle n'est pas servie par le gateway, son impact est négligeable.
  • Ne retouche pas tes tags un par un. Le conteneur servi par ton chemin de mesure embarque déjà ce chemin : tes tags dépendants, conversion Google Ads comme GA4, suivent automatiquement.

Activer via un serveur de tagging

Si tu as déjà un serveur de tagging, tu passes ton service de tiers à first-party. C'est plus lourd, et tu gagnes le contrôle complet des données avant envoi : modification, enrichissement, anonymisation, et des cookies gérés côté serveur dont la durée de vie ne dépend plus des restrictions navigateur.

Le piège : actif ne veut pas dire transporté

On arrive au cœur du sujet.

Les scripts et les hits de mesure sont deux axes indépendants. Un gateway peut servir tes scripts en first-party sans router la moindre donnée. Tu vois un statut vert, tes balises chargent, et tes conversions partent quand même en direct vers Google. Donc restent bloquables.

Charger le script, c'est faire entrer le livreur. Envoyer les hits, c'est le laisser repartir avec ta commande. Un gateway qui fait le premier sans le second t'a fait installer une porte pour rien.

Sur les deux sites audités en juillet :

  • Un compte client : scripts en first-party et hits Google Ads en first-party. Le signal de conversion survit au blocage. C'est le cas nominal.
  • Mon propre site : scripts en first-party, aucun hit. Gateway actif, bénéfice nul.

Oui, mon propre site. J'ai découvert le problème en construisant l'outil d'audit.

Depuis, je l'ai corrigé, et le nouvel audit montre exactement ce que ça change : mes hits de conversion Google Ads partent maintenant de mon propre domaine, et ils survivent au blocage. Une chose n'a pas bougé pour autant, et elle est instructive : mes hits GA4 continuent de partir en direct vers Google. C'est cohérent avec la documentation, qui dit qu'« une partie » des requêtes passera par ton domaine. Le gateway n'est pas un interrupteur, c'est une configuration destination par destination.

Et la première fois que j'ai fait tourner cet audit, je me suis planté. Je cherchais les scripts par motif d'URL, en filtrant sur gtm.js. Résultat : dix-neuf chargements first-party comptés comme zéro, un diagnostic « scripts non fonctionnels » totalement faux, et une recommandation de re-tag qui n'avait aucune raison d'être. La raison est intéressante : le gateway sert ses scripts sous des chemins aléatoires, du type /metrics/OvgO--ioXpMMINbFsRy..., précisément pour échapper aux règles de blocage par motif. Aucune recherche par nom de fichier ne les voit.

Le piège que personne ne mentionne : ta géolocalisation

Celui-là, je ne l'ai vu écrit nulle part avant de tomber sur la documentation.

Quand tes requêtes passent par ton CDN, Google ne reçoit plus l'adresse IP de ton visiteur, il reçoit celle du CDN. Sans configuration supplémentaire, tes rapports affichent une géographie fausse, et les valeurs par défaut du consent mode, qui dépendent du pays, partent de travers.

  • Sur Cloudflare, les en-têtes de géolocalisation sont transmis automatiquement. Rien à faire.
  • Sur CloudFront et Azure Front Door, c'est manuel : sans cette étape, tu remplaces un problème de blocage par un problème de données.

Deux autres limites à connaître avant de router du trafic :

  • Sur Akamai, un seul Google tag est supporté. Plusieurs tags exposent le gateway à de l'injection de script et peuvent le casser. Le remède documenté est de tout consolider dans un seul conteneur.
  • Le gateway ne transporte que les cookies Google. Les cookies non-Google qui passeraient par là sont abandonnés.
  • Le setup Cloudflare manuel demande un plan Enterprise. Sans Enterprise, passe par l'intégration dans l'interface.

Lire le panneau Google sans paniquer

Le gateway affiche un statut dans l'administration de ton compte. Trois valeurs, et la troisième inquiète pour rien.

  • Propriétaire (ou first-party) : le gateway est actif sur ce domaine. Ça ne dit rien des hits.
  • Pas commencé : rien n'est activé.
  • Incomplet : au moins un domaine détecté n'est pas couvert. Souvent cosmétique. Le cas typique : Google détecte ton domaine nu en plus du www, alors que le domaine nu redirige en permanence vers le www et ne sert jamais une page. Vérifie la redirection avant de lancer un chantier.

Deux faux signaux à connaître :

  • gtg_health=1 n'est pas un échec. Une requête vers googletagmanager.com avec ce paramètre est la sonde de santé du gateway. Elle part même quand tout fonctionne.
  • Toutes les requêtes ne routent pas par design. La documentation officielle dit qu'« une partie » des requêtes de mesure passera par ton domaine. Quelques requêtes en direct ne signifient pas que c'est cassé. Zéro requête first-party, là, oui.

La vérification en cinq minutes

  1. Ouvre l'onglet Réseau de ton navigateur sur une page de conversion.
  2. Filtre par type de ressource « Script », pas par nom de fichier, tu viens de voir pourquoi.
  3. Regarde d'où partent les requêtes de mesure, celles qui contiennent collect ou conversion : ton domaine, ou un domaine Google ?

Si les scripts sont chez toi mais que toutes les requêtes de mesure partent chez Google, ton gateway charge sans transporter. En général, les destinations ne sont pas correctement déclarées dans le panneau.

Deux détails pour lire correctement ce que tu vois :

  • Deux formes d'URL coexistent et les deux sont valides. Le re-tag manuel produit /<chemin>/?id=XXX, la réécriture Cloudflare produit plutôt /<chemin>/gtag/js?id=XXX. Voir la seconde alors que tu croyais avoir fait la première n'est pas une erreur : c'est le edge qui a pris la main.
  • Le chemin de mesure par défaut n'est pas /metrics. Google en génère un de quatre caractères alphanumériques, du genre /a7x2. Si tu cherches /metrics et ne trouves rien, cherche plutôt une suite de quatre caractères sans signification.

Et le consentement

Le gateway ne change rien à tes obligations.

  • Consent Mode avancé : aucune configuration supplémentaire.
  • Consent Mode basique : restreindre la transmission des données publicitaires, ce qui revient au blocage de balise.

Il transporte mieux les données que tu as le droit de collecter. Il ne t'autorise pas à en collecter davantage.

Ce que je ne peux pas te promettre

Aucun taux de récupération chiffré face aux bloqueurs n'est vérifiable à ce jour. Les chiffres qui circulent sont soit des cas isolés, soit des ordres de grandeur sans méthodologie publiée. J'ai cherché, je n'ai rien trouvé qui tienne.

Il reste aussi deux angles morts qu'aucune inspection du navigateur ne couvre :

  • Voir une requête partir de ton domaine ne prouve pas que Google l'a ingérée. La confirmation se fait côté plateforme, dans le rapport temps réel de GA4 ou dans le panneau du gateway.
  • La configuration exacte de ta zone CDN reste invisible depuis la page. Si la réécriture ne se déclenche pas, la cause est là.

Verdict

  • Active-le maintenant si tu es sur Cloudflare : le coût est nul et l'intégration prend quelques clics.
  • Vérifie les hits, pas les scripts. Un statut vert et des balises qui chargent ne prouvent rien. Le seul test qui compte est de savoir d'où partent tes requêtes de mesure.
  • Mesure sur ton propre compte : une baseline sur une période propre, l'activation, puis une comparaison sur des volumes comparables. Et re-vérifie après chaque changement, c'est une fonctionnalité qui bouge vite.

Si tu veux savoir ce que ton tracking perd réellement aujourd'hui, avant de toucher à quoi que ce soit, c'est exactement le genre de diagnostic que je fais dans un audit de compte.