Google Tag Gateway vs Server-side GTM : lequel des deux est vraiment nécessaire à votre installation ?
Mariusz Brucki | 13 mai 2026 | Dernière mise à jour: Google Tag Gateway a débarqué en 2024 et a immédiatement divisé les opinions. Certaines équipes l'ont considéré comme la fin de la conversation sur le suivi côté serveur. D'autres l'ont considéré comme une solution de contournement légère.
Ni l'un ni l'autre n'est exact.
En réalité, les deux outils s'attaquent à des problèmes différents, à des niveaux différents de votre installation. GTG modifie l'endroit où les scripts sont chargés. Le GTM côté serveur modifie l'endroit où les données sont traitées et où les cookies sont écrits. Il ne s'agit pas de la même chose, et les confondre conduit à des configurations qui semblent complètes sur le papier, mais qui laissent ouvertes de réelles lacunes en matière de suivi.
Dans cet article, vous découvrirez ce que Google Tag Gateway change dans votre configuration et ce qu'il ne change pas, comment le GTM côté serveur gère différemment le traitement des événements, la durée de vie des cookies et la couverture multiplateforme, une comparaison directe des deux outils sur 7 dimensions, et un cadre clair pour décider quelle configuration (ou quelle combinaison) correspond à votre pile de suivi.
Qu'est-ce que Google Tag Gateway ?
Google Tag Gateway est un proxy géré par Google pour tes balises Google. Au lieu de se charger à partir de googletagmanager.com, tes scripts Google se chargent à partir d'un chemin sur ton propre domaine, quelque chose comme yoursite.com/metrics. La collecte des données GA4 passe du point final de collecte de Google à ce même chemin.
Le domaine est à toi. Google gère l'infrastructure qui se cache derrière. Ton CDN ou ton équilibreur de charge (Cloudflare, Fastly, Akamai, Google Cloud) transmet ce chemin à Google. L'installation consiste principalement en un changement de configuration du CDN et une mise à jour du conteneur.
Il existe également une deuxième façon d'exécuter GTG : en l'activant à l'intérieur d'un conteneur GTM côté serveur existant. Dans ce cas, GTG s'exécute là où ton conteneur s'exécute, généralement un sous-domaine comme data.yoursite.com.
Il y a une contrainte difficile qui mérite d'être mentionnée d'emblée : GTG couvre uniquement les produits Google. GA4, Google Ads, Floodlight et Google Tag sont donc inclus. Si tu utilises Meta, TikTok, Klaviyo, ou quoi que ce soit d'autre en dehors de cet écosystème, GTG ne concerne pas ces événements.
Que corrige le GTG ?
La plupart des bloqueurs de publicité fonctionnent en bloquant les requêtes vers des noms d'hôtes tiers connus. googletagmanager.com figure sur toutes les principales listes de blocage. GTG contourne ce problème en acheminant ces demandes via votre domaine, qui ne figure sur aucune liste.
C'est une réelle amélioration. Les données agrégées dans le monde réel situent l'augmentation à environ 4-6% pour les données Google qui seraient autrement abandonnées au niveau du script(voir les données de comparaison de Niek Schlepers).
Deux choses que GTG ne règle pas
1. Le problème du chemin
Tout d'abord, GTG ne résout pas le problème du chemin d'accès. GTG change le domaine et te permet de choisir un préfixe de chemin d'accès personnalisé, mais les modèles de points de terminaison connus restent dans l'URL. Une demande de collecte de données GA4 aboutit toujours à /g/collect derrière ton préfixe, quelque chose comme yoursite.com/metrics/g/collect?v=2&tid=G-12345678 . Les bloqueurs de publicité comme Ghostery et uBlock Origin ne se contentent pas de correspondre aux noms d'hôte. Ils filtrent également sur les signatures de chemin connues, et /g/collect est un modèle bien documenté dans la plupart des grandes listes de blocage, quel que soit le domaine qui le sert. Les bloqueurs sophistiqués capturent toujours ces demandes, ce qui limite les possibilités de récupération de GTG.
2. Durée de vie des cookies
Les cookies sont toujours définis par le JavaScript qui s'exécute dans le navigateur. Lorsque ton conteneur GTM se déclenche côté client, il écrit des cookies via document.cookie. La prévention intelligente du suivi de Safari limite ces cookies à 7 jours. Peu importe le domaine qui a servi le script. L'origine des cookies est l'environnement JavaScript du navigateur. GTG ne change pas cette couche.
Pour tout parcours d'attribution de plus d'une semaine, ou pour tout visiteur revenant pour convertir après 7 jours dans Safari, le plafond de 7 jours s'applique toujours. Comme avant. Le chargement des scripts s'est amélioré ; le problème des cookies n'a pas bougé.
Qu'est-ce que le GTM côté serveur ?
Le GTM côté serveur retire entièrement le traitement des événements du navigateur et le place sur un serveur que vous contrôlez.
Ton navigateur envoie un événement à ton serveur. Le serveur le reçoit, le traite et le transmet à chaque plateforme par le biais d'appels API de serveur à serveur. Si tu utilises le script de suivi amélioré avec ton conteneur de serveur, les bloqueurs de publicité n'ont aucune visibilité sur ces appels. Il n'y a rien qui s'exécute dans le navigateur et qui puisse être bloqué.
Comment le GTM côté serveur fonctionne-t-il différemment ?
La situation des cookies change de manière significative. Ton serveur écrit des cookies à l'aide des en-têtes de réponse HTTP Set-Cookie. La limite de 7 jours de l'ITP vise les cookies écrits par JavaScript. Les cookies définis par le biais d'en-têtes provenant d'une première partie échappent à cette restriction. Un serveur-side correctement configuré peut écrire des cookies de première partie qui durent 365 jours ou plus.
Pour les sites où les clients mettent des semaines à se décider, cette différence dans la durée de vie des cookies est la différence entre une attribution précise et une attribution incomplète de par sa conception.
La couverture est une autre lacune que le GTM server-side comble. Le même conteneur peut acheminer des événements vers GA4, Google Ads Enhanced Conversions, Meta Conversions API, TikTok Events API et la plupart des autres plateformes qui proposent une API côté serveur. Si les campagnes cross-canal perdent du signal et que cela commence à se voir dans tes performances de reciblage(voici comment récupérer la perte de données), un seul pipeline d'événements vers toutes les plateformes est l'endroit où se trouve la solution structurelle.
Le compromis ? GTM nécessite un hébergement, une configuration et une connaissance de GTM pour fonctionner correctement. Il ne s'agit pas d'un changement rapide.
Google Tag Gateway vs Server-Side GTM : une comparaison directe
| Passerelle Google Tag | GTM côté serveur | |
| Quels changements | Où les scripts sont chargés | Où se déroule le traitement des événements |
| Paramétrage des cookies | JavaScript (navigateur) | En-têtes HTTP (serveur) |
| Impact du PTI | Pas de changement | Les cookies peuvent durer plus de 365 jours (avec une configuration de stockage adéquate). |
| Contournement des bloqueurs de publicité | Au niveau du nom d'hôte uniquement (les chemins connus comme /g/collect restent exposés) | Appels complets de serveur à serveur |
| Couverture de la plate-forme | Produits Google uniquement | Toute plate-forme dotée d'une API serveur |
| Complexité de la mise en place | Faible | Moyen à élevé |
| Augmentation typique des données | 4-6%* | 14-20%* |
*Vérifier les données et la comparaison dans GTG ou GTM côté serveur ? Le dilemme du côté serveur par Niek Schlepers
Il y a aussi une distinction technique qui mérite d'être comprise si tu t'intéresses au comportement same-site vs same-origin. L'installation du CDN de GTG nécessite un chemin sur ton domaine racine (yoursite.com/metrics), qui est de même origine que ton site. Un déploiement sGTM typique fonctionne sur un sous-domaine comme data.yoursite.com. C'est le même site, mais pas la même origine. Tu peux aussi déployer sGTM derrière un chemin de domaine racine, mais cela nécessite un proxy inverse devant ton conteneur. Certains navigateurs et certains bloqueurs traitent différemment les sous-domaines et les chemins d'accès au domaine racine, de sorte que l'emplacement de tes points d'accès est un choix architectural, et non cosmétique.
Quelle configuration convient le mieux à votre cas d'utilisation ?
GTG est le bon choix si :
- Votre pile ne comprend que des produits Google (GA4, Google Ads, Floodlight).
- La plupart de vos utilisateurs utilisent Chrome
- Les cycles de conversion sont inférieurs à 7 jours
- Vous souhaitez une amélioration à faible coût avec une configuration minimale.
sGTM est le bon choix si :
- Vous effectuez un suivi sur plusieurs plateformes (Meta, TikTok, Klaviyo, Google).
- Vos clients mettent plus de 7 jours à se convertir
- Vous avez besoin de cookies qui persistent au-delà de la limite ITP de Safari
- Vous voulez que le consentement soit appliqué côté serveur et que les informations nominatives soient contrôlées avant que les données ne quittent votre infrastructure.
- Vous voulez comprendre toute l'étendue de ce que le suivi côté serveur récupère
En voici un exemple.
Tu effectues un suivi sur plusieurs plates-formes. Une configuration côté serveur Meta dépend de sGTM, pas de GTG. TikTok, Klaviyo et tout ce qui se trouve en dehors de l'écosystème de Google en dépendent également.
Tes clients mettent du temps à se convertir. Les voyages de plusieurs semaines dans Safari ont besoin de cookies qui survivent au-delà du 7e jour. GTG n'offre pas cela.
Tu veux voir ce que tu perds réellement. Le tableau complet de ce que le suivi côté serveur récupère est difficile à apprécier tant que tu n'as pas exécuté les deux configurations et que tu ne les as pas comparées.
Tu as besoin d'un contrôle des données qui aille au-delà de la récupération des données. sGTM te permet de décider ce qui est transmis à chaque plateforme, d'appliquer la logique de consentement côté serveur et de dépouiller les IIP avant que les données ne quittent ton infrastructure.
La plupart des équipes qui prennent le suivi des conversions au sérieux finissent par atteindre le GTM côté serveur. Le GTM peut être une première étape utile. Mais il ne résout pas la question de l'infrastructure.
GTG et Server-Side peuvent-ils fonctionner ensemble ?
Techniquement, Google Tag Gateway et GTM server-side fonctionnent à des niveaux différents, ils n'entrent donc pas toujours en conflit. Cependant, nous ne recommandons généralement pas d'utiliser les deux ensemble. Dans la pratique, le fait de combiner GTG avec ton installation côté serveur peut interférer avec la configuration existante de ton serveur. Et comme le risque n'est pas toujours prévisible, notre conseil est de choisir une approche plutôt que de les superposer.
Si tu utilises déjà le GTM server-side avec TAGGRS, tu n'as pas besoin de GTG pour la distribution des scripts. Le Enhanced Tracking Script s'occupe déjà de ce travail, en servant les scripts de tags Google depuis ton propre domaine et en gérant la persistance des cookies côté serveur. Le GTG résoudrait un problème que tu as déjà résolu, avec une complexité accrue et des conflits potentiels en cours de route.
Tu veux évaluer quelle configuration correspond à tes besoins ? Vérifie le tableau comparatif ci-dessus.
GTG et sGTM : quelle est la place de TAGGRS ?
Le GTM côté serveur a besoin d'un serveur pour fonctionner. Pour la plupart des équipes, le besoin réel n'est pas la gestion de l'infrastructure. Il s'agit de la performance, de la fiabilité et de la configuration correcte des consentements sans temps dédié à DevOps.
TAGGRS fournit une infrastructure sGTM hébergée avec des connecteurs intégrés pour les principales plateformes publicitaires, l'intégration du mode de consentement et les contrôles de confidentialité. Êtes-vous prêt à dépasser la couche GTG et voulez-vous comprendre à quoi ressemble la récupération des données pour votre configuration spécifique ?
FAQ
Ai-je besoin de Google Tag Gateway ?
Si tu utilises GA4 et Google Ads sans aucun suivi côté serveur, GTG est une amélioration pratique qui vaut la peine d'être mise en place. Il récupère les données perdues à cause du blocage basé sur le nom d'hôte avec très peu de frais généraux d'implémentation. Si tu utilises déjà sGTM, le gain incrémental de GTG est plus faible. Tes événements se déplacent déjà de serveur à serveur. GTG aide principalement la couche de chargement des scripts, que ton installation sGTM peut déjà gérer en fonction de la façon dont ton conteneur est configuré.
Google Tag Gateway corrige-t-il l'ITP de Safari ?
Non. GTG ne modifie pas la manière dont les cookies sont écrits. L'ITP s'applique aux cookies écrits par JavaScript, quel que soit le domaine qui a servi le script.
Quelle est la différence entre Google Tag Gateway et le balisage côté serveur ?
Google Tag Gateway change l'endroit où tes scripts Google se chargent. Ton propre domaine au lieu du domaine de Google. Les scripts s'exécutent toujours dans le navigateur, les cookies sont toujours écrits par JavaScript et l'ITP s'applique toujours. Les bloqueurs de publicité sophistiqués qui s'appuient sur des modèles de chemin plutôt que sur de simples noms d'hôte peuvent toujours détecter et bloquer les requêtes.
Le marquage côté serveur déplace le traitement des événements du navigateur vers un serveur. Les cookies sont écrits via les en-têtes HTTP, ce qui les place hors de portée de l'ITP. Les événements atteignent les plateformes via des appels API de serveur à serveur que les bloqueurs de publicité ne peuvent pas toucher. Et contrairement à GTG, sGTM fonctionne sur toutes les plates-formes dotées d'une API server-side, et pas seulement sur celle de Google.
Ils opèrent à des niveaux différents. GTG améliore la diffusion des scripts pour les balises Google ; sGTM gère le pipeline d'événements, la durée de vie des cookies et l'acheminement des signaux multiplateformes. Pour les configurations où les deux problèmes sont importants, ils fonctionnent ensemble.
Ai-je besoin de GTM côté serveur si j'utilise déjà Google Tag Gateway ?
GTG améliore la livraison de scripts pour les balises Google. Si vous utilisez des plateformes non Google, si vous avez besoin de cookies qui durent plus de 7 jours, ou si vous souhaitez un contournement complet des bloqueurs de publicité pour toutes les plateformes, sGTM comble ces lacunes.
