Si vous utilisez Google Tag Manager, on vous a sans doute déjà conseillé de déplacer vos balises vers un serveur que vous contrôlez. Le suivi côté serveur avec Google Tag Manager est la méthode la plus répandue pour y parvenir.
En cause : la perte de signal. Les bloqueurs de publicités et les restrictions des navigateurs arrêtent une partie des requêtes de suivi avant qu’elles n’atteignent vos outils d’analyse ou vos plateformes publicitaires. Résultat : vos rapports sous-estiment ce que produisent vos campagnes, ou perdent en fiabilité. Pour une vue d’ensemble, commencez par notre guide du suivi côté serveur. Ici, nous nous concentrons sur le volet Google Tag Manager.
En bref
- Google Tag Manager côté serveur (sGTM) ajoute un second conteneur, qui s’exécute sur un serveur de balisage et non dans le navigateur du visiteur.
- Le navigateur envoie un seul flux d’événements au serveur de balisage, et le conteneur de serveur décide de ce qu’il transmet à chaque outil que vous utilisez : Google Analytics et Google Ads, mais aussi des plateformes comme Meta.
- Configurer le conteneur est gratuit, mais pas le serveur : si vous l’hébergez vous-même sur Cloud Run, les chiffres de Google situent une configuration de production autour de 90 USD par mois.
- Le consentement reste de rigueur : déplacer vos balises vers le serveur ne change rien aux règles de collecte des données.
Au sommaire :
- Qu’est-ce que Google Tag Manager côté serveur (sGTM) ?
- Quelle est la différence entre GTM côté serveur et GTM côté client ?
- Comment fonctionne le suivi côté serveur avec Google Tag Manager
- Les avantages de GTM côté serveur
- Les limites à peser avant de se lancer
- Combien coûte GTM côté serveur ?
- Comment mettre en place le suivi côté serveur avec Google Tag Manager
- Comment fonctionne le consentement dans GTM côté serveur
- GTM côté serveur ou passerelle de balises Google ?
- Par où commencer
- FAQ : Google Tag Manager côté serveur
Qu’est-ce que Google Tag Manager côté serveur (sGTM) ?
Google Tag Manager côté serveur (sGTM) est un conteneur Google Tag Manager qui s’exécute sur un serveur de balisage, et non dans le navigateur du visiteur. Le navigateur envoie les données d’événement à ce serveur, puis le conteneur de serveur décide de ce qu’il transmet à chaque fournisseur : Google Analytics 4 (GA4), Google Ads ou Meta.
Selon Google, un conteneur de serveur « ne s’exécute pas dans le navigateur de l’utilisateur ni sur son téléphone ». Créer le conteneur dans Google Tag Manager est gratuit. Faire tourner le serveur qui l’héberge ne l’est pas, et c’est là que se concentre l’essentiel de la planification.
Qu’est-ce que Google Tag Manager ?
Google Tag Manager est l’outil gratuit de Google pour gérer les balises de suivi de votre site, ces petits morceaux de code qui envoient des données vers des outils comme Google Analytics ou Meta. Vous installez un seul conteneur et pilotez toutes vos balises depuis un tableau de bord unique.
Quelle est la différence entre GTM côté serveur et GTM côté client ?
GTM côté client exécute chaque balise dans le navigateur du visiteur ; GTM côté serveur déplace l’essentiel de ce travail vers un serveur de balisage, placé entre votre site et vos fournisseurs.
| Ce qui change | GTM côté client (conteneur web) | GTM côté serveur (conteneur de serveur) |
|---|---|---|
| Où s’exécutent les balises | Dans le navigateur du visiteur | Sur un serveur de balisage |
| Ce que télécharge le navigateur | Un script par fournisseur | Une seule balise Google, un seul flux de données |
| Qui reçoit la requête en premier | Chaque fournisseur, directement | Le serveur de balisage, sur votre sous-domaine |
| Qui voit les données brutes avant les fournisseurs | Chaque fournisseur voit ce que collecte sa balise | Vous, et c’est vous qui choisissez ce qui part ensuite |
| Domaine des cookies | Souvent les domaines des fournisseurs | Votre propre domaine |
| Coût | Gratuit | Conteneur gratuit, hébergement payant |
| Comment s’applique le consentement | Les choix du bandeau pilotent les balises dans le navigateur | Les choix du bandeau accompagnent chaque événement jusqu’au serveur |
La plupart des configurations utilisent les deux conteneurs : le conteneur web reste sur votre site et envoie les événements au conteneur de serveur, qui se charge ensuite de la distribution. Pour revoir ce qui se passe côté navigateur, voici comment fonctionne le suivi des sites web.
Comment fonctionne le suivi côté serveur avec Google Tag Manager
Voici ce qui se passe lorsqu’un visiteur agit sur un site équipé de sGTM :
- Le visiteur agit. Il consulte une page, ajoute un article au panier ou achète.
- Le navigateur envoie une seule requête. La balise Google (ou votre conteneur web) transmet l’événement au serveur de balisage, et non à chaque fournisseur.
- Le serveur de balisage la reçoit. Il vit sur un sous-domaine de votre site, par exemple
data.yoursite.com. - Un client convertit la requête en données d’événement. Le client reconnaît la requête entrante et la déplie en un événement standard. Pour une page vue : le nom de l’événement (
page_view), l’URL et le titre de la page, la provenance du visiteur, un ID aléatoire attribué à son navigateur et ses choix de consentement. - Les balises serveur transmettent l’événement. Ce sont les déclencheurs qui décident des balises à exécuter, et chaque balise envoie les données vers sa destination : GA4, Google Ads, Meta, etc.
Le conteneur de serveur : clients, balises et déclencheurs
Si vous maîtrisez le conteneur web, vous maîtrisez déjà l’essentiel du conteneur de serveur. Google le confirme : les balises, les déclencheurs et les variables « fonctionnent exactement comme dans les autres types de conteneurs ».
La nouveauté, c’est le client (au sens de Tag Manager). Un client joue le rôle d’adaptateur : il reçoit la requête entrante, la transforme en un ou plusieurs événements, puis les transmet au conteneur. Les conteneurs de serveur intègrent déjà un client GA4 : les requêtes GA4 fonctionnent sans configuration supplémentaire.
Les avantages de GTM côté serveur
- Des pages plus légères. Moins de scripts de fournisseurs se chargent dans le navigateur, ce qui peut accélérer l’affichage.
- La maîtrise de ce que reçoivent les fournisseurs. Vous pouvez supprimer ou masquer des champs avant que les données ne quittent le serveur de balisage : chaque fournisseur n’obtient alors que ce dont il a besoin.
- Moins de requêtes perdues. Les bloqueurs et les restrictions des navigateurs arrêtent moins souvent les requêtes envoyées vers votre propre sous-domaine que celles destinées aux domaines de fournisseurs connus. L’ampleur du gain dépend de votre configuration : mesurez-la plutôt que de la supposer.
- Vos clés d’API restent hors du site. Les clés de services comme la Conversions API de Meta résident dans le conteneur de serveur : les visiteurs ne peuvent pas les lire dans le code de votre site.
L’objectif : des données plus fiables, que vous pouvez exploiter avec le consentement des visiteurs. La section consacrée au consentement explique pourquoi GTM côté serveur ne peut pas passer outre les choix d’un visiteur.
Les limites à peser avant de se lancer
- Le coût d’hébergement. Vous payez le serveur de balisage tous les mois, quel que soit votre trafic.
- L’installation et la maintenance. Quelqu’un doit configurer le DNS, surveiller le serveur et tenir les balises à jour.
- Une couverture fournisseurs incomplète. Tous vos outils ne disposent pas encore d’une balise côté serveur.
- Un débogage plus difficile. Le problème peut venir de l’un ou l’autre conteneur, ou de la liaison entre les deux.
- Le consentement reste de rigueur. Le balisage côté serveur ne supprime aucune obligation de recueillir le consentement.
À notre avis, l’effort se justifie pour les sites qui investissent sérieusement en publicité ou qui constatent des trous nets dans leurs statistiques. Un petit site avec quelques balises n’y gagnera sans doute pas assez pour couvrir la dépense.
Combien coûte GTM côté serveur ?
Le conteneur ne coûte rien. Ce que vous payez, c’est le serveur qui l’héberge, et le temps passé à l’installer puis à l’entretenir.
Les chiffres de Google donnent un point de repère utile. Pour une installation sur Cloud Run (le service qui permet d’exécuter des applications sur les serveurs de Google sans avoir à administrer ces serveurs), Google estime que « chaque serveur coûte environ 45 USD par mois » et recommande « au moins 2 instances pour réduire le risque de perte de données en cas de panne d’un serveur » (Google for Developers, mis à jour le 12 mai 2026). Une configuration de production revient donc à environ 90 USD par mois, avant toute montée en charge. Google table sur 2 à 10 serveurs, avec mise à l’échelle automatique, pour absorber 35 à 350 requêtes par seconde selon vos balises.
Comment mettre en place le suivi côté serveur avec Google Tag Manager
Quelle que soit la formule d’hébergement retenue, une implémentation de GTM côté serveur suit les mêmes sept étapes. Les guides de Google détaillent chacune d’elles ; en voici la vue d’ensemble.
- Créer un conteneur de serveur. Dans Google Tag Manager, créez un conteneur et choisissez « Serveur » comme plate-forme cible.
- Choisir l’hébergement du serveur de balisage. Google propose un provisionnement automatique sur Cloud Run directement depuis l’interface de Tag Manager, ou une installation manuelle dans Google Cloud ou ailleurs. Des prestataires spécialisés peuvent aussi exploiter le serveur à votre place. Le suivi côté serveur d’iubenda emprunte une voie plus simple : il fait passer vos balises par votre propre sous-domaine et vérifie le consentement avant de transmettre la moindre donnée, sans aucun conteneur de serveur à configurer.
- Associer un sous-domaine personnalisé. Faites pointer un sous-domaine comme
data.yoursite.comvers le serveur de balisage : les requêtes restent ainsi propriétaires (first-party), c’est-à-dire que le navigateur les rattache à votre site et non à un traqueur tiers. - Rediriger votre balise Google vers le serveur de balisage. Modifiez la balise Google ou le conteneur web pour que les événements partent vers votre sous-domaine plutôt que directement vers Google.
- Ajouter des clients et des balises serveur. Créez une balise par destination. Les balises GA4 et Google Ads sont fournies d’origine, et d’autres plateformes proposent des modèles dans la galerie de Tag Manager, comme la balise Conversions API officielle de Meta. Pour les outils sans modèle, un développeur peut créer une balise personnalisée.
- Tester en mode Aperçu et débogage. Le conteneur de serveur dispose de son propre mode Aperçu : vous y suivez chaque requête entrante et vérifiez quelles balises se déclenchent.
- Publier, puis surveiller. Comparez vos volumes d’événements à vos chiffres côté client pendant quelques semaines avant de désactiver quoi que ce soit.
Configurez le consentement avant l’étape 5. Chaque balise serveur que vous ajoutez doit respecter les choix du visiteur dès le premier jour. Voici comment faire.
Comment fonctionne le consentement dans GTM côté serveur
Déplacer vos balises vers le serveur change le trajet des données, pas les règles qui encadrent leur collecte.
Le signal de consentement accompagne chaque événement
Votre bandeau de consentement recueille les choix de chaque visiteur et les transmet à la balise Google, qui les joint ensuite à chaque requête envoyée au conteneur de serveur. Google le confirme : « il vous suffit de configurer Google Consent Mode dans le conteneur web », et les balises des produits Google installées sur le serveur « tiennent compte du consentement » et ajustent ce qu’elles envoient. Si ce n’est pas encore fait, commencez par Google Consent Mode.
Les balises non Google doivent vérifier le consentement elles-mêmes
Ce comportement ne vaut que pour les balises de Google. Dans le conteneur de serveur, les balises des autres fournisseurs ne respectent le consentement que si la personne qui gère le conteneur les y oblige — en général en demandant à chaque déclencheur de vérifier l’état du consentement que votre plateforme de gestion du consentement (CMP) transmet avec l’événement.
Les réglementations s’intéressent aussi à ce qui se passe sur l’appareil du visiteur. La directive ePrivacy de l’UE soumet en principe au consentement toute lecture ou tout stockage d’informations sur un appareil, quel que soit le sort réservé ensuite aux données. Un serveur de balisage n’y change rien : les exigences de consentement pour les cookies continuent de s’appliquer à votre installation.
Pour le cadre juridique complet, consultez : Le suivi côté serveur est-il conforme au RGPD ?
Votre check-list consentement pour sGTM :
- Un bandeau de consentement recueille les choix avant qu’une seule balise ne se déclenche.
- Vous avez configuré Google Consent Mode dans le conteneur web.
- L’état du consentement parvient au conteneur de serveur avec chaque événement.
- Chaque balise serveur non Google vérifie le consentement avant de se déclencher.
- Vous conservez une preuve des consentements, que vous pouvez produire en cas de contrôle.
GTM côté serveur ou passerelle de balises Google ?
La passerelle de balises Google pour les annonceurs permet de charger les scripts des balises Google depuis votre propre domaine, via votre réseau de diffusion de contenu (CDN), votre équilibreur de charge ou votre serveur web. C’est la plus légère des deux options, et on les confond souvent.
| Point de comparaison | Passerelle de balises Google | GTM côté serveur |
|---|---|---|
| Rôle | Sert les scripts de Google depuis votre domaine | Reçoit les événements et détermine ce qu’obtient chaque fournisseur |
| Lieu d’exécution | Votre CDN, votre équilibreur de charge ou votre serveur web | Un serveur de balisage |
| Effort de mise en place | Faible, avec une configuration guidée pour certains CDN | De modéré à élevé |
| Coût | Aucun serveur de balisage à gérer | Hébergement mensuel du serveur de balisage |
| Contrôle sur les données envoyées aux fournisseurs | Aucun : les données partent vers Google comme d’habitude | Total : vous pouvez modifier ou supprimer des champs |
| Compatible avec les fournisseurs non Google | Non | Oui, via des balises serveur |
Google recommande de combiner les deux pour obtenir « la configuration de balisage la plus durable ». En pratique, la passerelle convient aux annonceurs qui veulent surtout servir les balises Google en contexte propriétaire, sans grande configuration. GTM côté serveur s’adresse aux équipes qui veulent en plus maîtriser ce que reçoit chaque fournisseur.
Par où commencer
GTM côté serveur améliore la façon dont vos données parviennent aux fournisseurs ; le consentement, lui, détermine lesquelles vous pouvez exploiter. Pensez les deux ensemble : votre installation tiendra la route le jour où l’on vous demandera d’où viennent vos chiffres.
Soignez d’abord le volet consentement : tout le reste en dépend. C’est votre CMP qui donne naissance à l’état du consentement : elle recueille les choix de chaque visiteur et les met à la disposition de toutes les balises, dans le navigateur comme sur le serveur. Privacy Controls & Cookie Solution de iubenda prend en charge Google Consent Mode : les choix exprimés sur votre bandeau accompagnent chaque événement reçu par votre serveur de balisage.
Si gérer vous-même un serveur de balisage dépasse ce que votre équipe souhaite assumer, une solution managée peut l’héberger et l’entretenir à votre place.
Un suivi côté serveur pensé pour la conformité
Au lieu d’un conteneur de serveur GTM à exploiter et à maintenir, nous faisons passer vos événements par une passerelle propriétaire : rien de nouveau à héberger.
FAQ : Google Tag Manager côté serveur
Puis-je faire du balisage côté serveur dans Google Tag Manager ?
Oui. Il suffit de créer un conteneur de serveur à côté de votre conteneur web pour faire du balisage côté serveur dans Google Tag Manager. Ce conteneur s’exécute sur un serveur de balisage hébergé sur Google Cloud ou chez un prestataire spécialisé, et c’est à lui que votre conteneur web envoie les événements, plutôt qu’à chaque fournisseur.
Puis-je faire transiter les événements de la Meta Conversions API par GTM côté serveur ?
Oui, vous pouvez faire transiter les événements de la Meta Conversions API par GTM côté serveur. Meta maintient une balise Conversions API officielle pour les conteneurs de serveur dans la galerie de modèles de Tag Manager. Elle transmet les événements du serveur de balisage à Meta et ne doit se déclencher que si le visiteur a donné son consentement.
GTM côté serveur fonctionne-t-il avec GA4 ?
Oui, GTM côté serveur est prêt à l’emploi avec GA4. Les conteneurs de serveur embarquent un client GA4 qui reçoit les requêtes GA4 du navigateur, ainsi qu’une balise GA4 qui transmet les événements à Google Analytics. C’est d’ailleurs par GA4 que la plupart des équipes commencent.
Le conteneur web reste-t-il nécessaire avec GTM côté serveur ?
Dans la plupart des cas, oui. Le conteneur web — ou la balise Google — collecte les événements dans le navigateur et les envoie au serveur de balisage, qui se charge ensuite de les distribuer aux fournisseurs. Émettre les événements directement depuis un backend reste l’exception.
GTM côté serveur contourne-t-il les bloqueurs de publicités ?
Non, pas de façon fiable. Les bloqueurs arrêtent souvent moins de requêtes, parce que celles-ci partent vers votre propre sous-domaine, mais certains reconnaissent désormais les sous-domaines de suivi propriétaires, et Safari limite les cookies dans certaines configurations. Dans tous les cas, les choix de consentement du visiteur restent applicables.
Le suivi côté serveur est-il légal ?
Le suivi côté serveur est un mode d’acheminement des données, et aucune réglementation ne l’interdit. Ce qui compte, c’est la collecte : le Règlement général sur la protection des données (RGPD) et la directive ePrivacy de l’UE exigent en principe le consentement pour collecter des données sur l’appareil d’un visiteur, que celles-ci partent directement vers les fournisseurs ou transitent par un serveur de balisage.
Puis-je utiliser GTM côté serveur pour des applications mobiles ?
Oui. Google documente une configuration pour applications mobiles dans laquelle l’application envoie ses données de mesure à un conteneur de serveur, qui les transmet ensuite à vos fournisseurs comme il le ferait pour un site web.