Le 13 octobre 2026, Google a publié sa mise à jour mensuelle Demand Gen avec un chiffre qui a fait le tour de LinkedIn : selon une analyse interne, les annonceurs qui renforcent leurs données avec le Google Tag Gateway verraient en moyenne plus de 20 % de conversions en plus sur leurs campagnes Demand Gen.
Depuis, j'ai eu la même question plusieurs fois chez mes clients : « Est-ce que le Tag Gateway, c'est le nouveau server-side ? Est-ce qu'on doit l'activer ? »
La réponse courte : le Tag Gateway est un vrai progrès pour les sites qui n'ont rien. Mais il ne règle pas les mêmes problèmes qu'un GTM server-side, et si vous en avez déjà un, il ne vous apportera pas grand-chose. Voici pourquoi.
Le Google Tag Gateway, c'est quoi ?
Le Google Tag Gateway est un proxy géré par Google pour vos balises Google. Au lieu d'être chargés depuis googletagmanager.com, vos scripts Google sont servis depuis un chemin de votre propre domaine (par exemple votresite.com/metrics), et les données GA4 et Google Ads repartent par ce même chemin.
L'outil a d'abord été lancé en 2024 sous le nom de « first-party mode », puis renommé Google Tag Gateway for advertisers en 2025. Il se met en place de deux façons :
- Via votre CDN ou votre load balancer : Cloudflare, Akamai, Fastly, Google Cloud (disponible en version finale depuis le 1er juin 2026) et Amazon CloudFront.
- Dans un conteneur GTM server-side existant, qui joue alors le rôle de passerelle sur votre sous-domaine.
Sur un site déjà derrière Cloudflare, l'activation prend quelques minutes. C'est ce qui le rend si attractif.
Ce que le Tag Gateway corrige vraiment
La plupart des bloqueurs de publicité fonctionnent avec des listes de domaines connus. googletagmanager.com et google-analytics.com sont sur toutes les listes. En faisant passer les requêtes par votre domaine, le Tag Gateway contourne ce blocage par nom de domaine.
C'est un vrai gain de données mesurées. Mais il faut regarder les chiffres de près :
- Google a d'abord communiqué sur +11 % de signaux, puis +14 % de conversions observées en moyenne, puis plus de 20 % sur Demand Gen. Ces chiffres viennent d'analyses internes de Google, sur des périodes courtes, sans détail sur l'échantillon.
- Les mesures indépendantes présentées par les spécialistes du tracking tournent plutôt autour de 4 à 7 % de données récupérées.
Les deux ne sont pas forcément contradictoires : le gain dépend de la part de vos visiteurs qui utilisent un bloqueur basé sur les noms de domaine, et de ce que vous aviez déjà en place.
Et surtout, une précision importante : +20 % de conversions mesurées, ce n'est pas +20 % de ventes. Les ventes existaient déjà. On les voit juste mieux. Ce qui reste intéressant, parce que mieux mesurer, c'est envoyer de meilleurs signaux à l'algorithme.
Ce que le Tag Gateway ne fait pas
Les cookies restent écrits par le navigateur
Avec le Tag Gateway, c'est toujours le JavaScript exécuté dans le navigateur qui écrit les cookies. Sur Safari, ces cookies restent donc plafonnés à 7 jours (voire 24 heures après un clic publicitaire) par l'ITP d'Apple. Le domaine qui sert le script ne change rien à cette règle.
Un GTM server-side bien configuré écrit au contraire ses cookies via les en-têtes HTTP du serveur, ce qui permet de conserver l'identifiant du visiteur beaucoup plus longtemps. Pour un parcours d'achat de plus d'une semaine, la différence est énorme.
Les bloqueurs les plus avancés ne sont pas dupes
Le Tag Gateway change le domaine, mais pas la signature des requêtes. Une requête GA4 garde son chemin /g/collect et ses paramètres habituels. Les bloqueurs comme uBlock Origin ou Ghostery filtrent aussi sur ces motifs, quel que soit le domaine.
Il ne concerne que Google
GA4, Google Ads, Floodlight. C'est tout. Votre pixel Meta, votre TikTok, votre Klaviyo ou votre Pinterest continuent de partir du navigateur, avec les mêmes pertes qu'avant. Pour Meta, la Conversion API reste indispensable.
Il ne permet ni d'enrichir, ni de filtrer
C'est toujours le navigateur qui envoie l'événement, tel quel. Pas de marge ajoutée côté serveur, pas de données CRM, pas de nettoyage des données personnelles avant l'envoi. Tout ce qui fait la valeur d'un server-side reste hors de portée.
Safari 27 bloque désormais au niveau du réseau
Avec Safari 27, Apple ne se contente plus de bloquer des scripts : il coupe certaines connexions en vérifiant l'adresse IP de destination. Un chemin first-party côté navigateur ne protège donc pas contre tout. Plus vos données dépendent du navigateur, plus elles dépendent des décisions d'Apple.
Les 5 idées reçues que j'entends le plus
« Ça remplace le server-side »
Faux. Le Gateway change le chemin de la requête, mais c'est toujours le navigateur qui envoie l'événement. Pas d'enrichissement, pas de filtrage des données, pas de CAPI Meta.
« C'est +20 % de ventes »
Faux. C'est +20 % de conversions mesurées, selon une analyse interne Google dont on ne connaît ni le secteur ni l'échantillon, et uniquement sur Demand Gen.
« Si j'ai déjà du server-side, ça m'apporte encore quelque chose »
Pas vraiment. Un GTM server-side complet, avec un loader personnalisé et des endpoints sur votre sous-domaine, contourne déjà mieux les bloqueurs que le Gateway. Le vrai risque, c'est d'avoir deux chemins qui envoient la même chose. (Je l'ai déjà vu.)
« En first-party, plus besoin de consentement »
Faux. First-party ne veut pas dire exempté. Les balises Google chargées via le Gateway respectent le Consent Mode exactement comme avant, et votre CMP reste le seul juge.
« Donc ça ne sert à rien »
Faux aussi. Pour un site sans server-side, c'est un vrai gain, simple à mettre en place si vous êtes déjà chez un CDN partenaire comme Cloudflare.
Tag Gateway ou GTM server-side : le comparatif
| Critère | Google Tag Gateway | GTM server-side |
|---|---|---|
| Ce qui change | Le domaine d'où les scripts sont chargés | L'endroit où les événements sont traités |
| Écriture des cookies | JavaScript (navigateur) | En-têtes HTTP (serveur) |
| Impact ITP Safari | Aucun changement | Cookies conservés bien plus longtemps |
| Bloqueurs de publicité | Blocage par domaine contourné uniquement | Contournement beaucoup plus large |
| Plateformes couvertes | Google uniquement | Google, Meta, TikTok, Pinterest, Snapchat… |
| Enrichissement et filtrage | Non | Oui (marge, CRM, données personnelles) |
| Mise en place | Simple | Plus technique, hébergement nécessaire |
Mon avis : pour qui, et quand ?
Le Tag Gateway a du sens si vous n'avez aucun server-side, que vos campagnes sont essentiellement sur Google, que votre site est déjà derrière Cloudflare ou un autre CDN compatible, et que vous cherchez un gain rapide sans projet technique.
Le GTM server-side reste la bonne réponse si vous investissez sur plusieurs plateformes (Google et Meta au minimum), si vos clients mettent plus d'une semaine à acheter, si une part importante de votre trafic vient de Safari, ou si vous voulez piloter vos campagnes à la marge plutôt qu'au chiffre d'affaires.
Si vous avez déjà un GTM server-side, ne cumulez pas les deux sans y réfléchir. Votre conteneur serveur sert déjà les scripts depuis votre domaine. Ajouter le Gateway par-dessus, c'est ajouter un deuxième chemin, et donc un risque de doublons ou de conflits. Si votre hébergeur server-side propose d'activer le Gateway directement dans le conteneur, c'est la seule configuration que j'envisagerais.
Le sujet, au fond, ce n'est pas l'outil. C'est de savoir où en est votre collecte aujourd'hui, et ce que vous perdez réellement.
Comment savoir ce que vous perdez
Avant de choisir, faites un état des lieux simple :
- Comparez vos commandes back-office avec les achats remontés dans GA4, Google Ads et Meta sur 28 jours.
- Regardez la part de Safari et des navigateurs avec bloqueur dans votre trafic.
- Vérifiez si vos balises Google sont déjà servies depuis votre domaine (dans l'onglet Réseau de votre navigateur).
C'est exactement ce que je regarde en début d'audit tracking. Si vous avez un doute sur votre setup actuel, vous pouvez prendre 20 minutes avec moi pour faire le point.
