Votre conteneur GTM Server-Side est configuré. Les tags se déclenchent, les événements circulent, et le serveur de prévisualisation affiche des coches vertes. La question suivante est pratique : où faire tourner tout cela en production ?
Si vous avez suivi le provisionnement automatique de Google, votre conteneur a atterri sur Cloud Run dans US Central (Iowa). C’est suffisant pour les tests. En production, il faut réfléchir à la région, la fiabilité, les coûts, et si Google Cloud est vraiment la bonne plateforme pour votre organisation.
Ce guide passe en revue les quatre principales options d’hébergement : optimiser Cloud Run, déployer sur AWS, déployer sur Azure, et utiliser un fournisseur managé. Chacune présente des compromis clairs qui dépendent de votre infrastructure, de votre volume de trafic et du niveau d’exploitation que vous êtes prêt à gérer.
Cloud Run : le choix par défaut, optimisé pour la production
Cloud Run exécute l’image Docker officielle du serveur de tagging Google (gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable) sous forme de conteneur serverless entièrement managé. Il gère automatiquement le scaling, le réseau et le SSL.
Pour la plupart des organisations déjà sur GCP, c’est le point de départ logique. L’intégration avec GTM est native, la documentation est exhaustive, et la charge opérationnelle est minimale par rapport à la gestion manuelle de conteneurs.
La configuration production qui fait la différence
Le provisionnement automatique crée vos services avec des paramètres par défaut qui ne sont pas adaptés à la production. Trois changements sont nécessaires :
CPU toujours alloué. Par défaut, Cloud Run réduit le CPU entre les requêtes. Pour un serveur de tagging qui doit parser les hits entrants et compiler les requêtes sortantes rapidement, cela provoque une latence incohérente et des timeouts occasionnels. Activez --no-cpu-throttling pour maintenir le CPU disponible en permanence.
Minimum 2 instances. Les cold starts sur un serveur de tagging signifient des données perdues. Si une instance doit démarrer de zéro pendant qu’un événement page view d’un utilisateur attend, cette requête peut expirer avant que le conteneur soit prêt. Deux instances toujours actives éliminent ce risque et offrent une redondance de base.
Désactiver le logging détaillé de Cloud Logging. C’est le piège de coûts qui attrape tout le monde. Cloud Run journalise chaque requête entrante par défaut à 0,50 $ par Gio ingéré. Pour un site à trafic moyen, cela représente 100 à 220 $/mois rien qu’en logging, parfois plus que vos coûts de calcul. Désactivez le logging au niveau des requêtes et appuyez-vous sur le logging d’erreurs et votre propre monitoring à la place.
Google estime que chaque instance gère environ 20 requêtes par seconde pour des configurations GA4 typiques. Avec 2 à 10 instances, cela couvre 35 à 350 requêtes par seconde. Un point de départ raisonnable pour un site moyen est 2 instances minimum, 5-6 maximum.
Domaines personnalisés : deux approches avec des compromis différents
Le mapping de domaine direct sur Cloud Run fonctionne bien pour les déploiements mono-région. Vous créez un enregistrement CNAME, Google provisionne un certificat SSL (comptez jusqu’à 24 heures), et c’est opérationnel. Simple, sans coût supplémentaire.
Un External Application Load Balancer est le meilleur choix si vous avez besoin d’un déploiement multi-région, d’une protection DDoS via Cloud Armor, ou d’une IP anycast globale. Le load balancer ajoute environ 18 $/mois minimum plus des frais de traitement par Go, mais il débloque des fonctionnalités de fiabilité de niveau entreprise.
Pour le multi-région, déployez des services Cloud Run dans chaque région cible (par exemple europe-west1 et us-east1), créez un Serverless Network Endpoint Group par région, et ajoutez-les à un seul backend service global derrière le load balancer. Les utilisateurs sont automatiquement routés vers la région la plus proche.
Ce que cela coûte réellement
| Niveau de trafic | Requêtes quotidiennes | Instances (min/max) | Coût mensuel |
|---|---|---|---|
| Gratuit/Test | <1K | 0 / 1 | 0 $ (offre gratuite) |
| Faible | 10K-100K | 1-2 / 3 | 45-135 $ |
| Moyen | 100K-1M | 2 / 5-6 | 90-270 $ |
| Élevé | 1M-10M | 3 / 10+ | 135-450 $+ |
Ce sont les coûts de calcul uniquement. Ajoutez Cloud Logging (si vous ne l’avez pas désactivé), l’egress réseau (0,12 $/Go) et le load balancer (18 $+/mois) pour obtenir votre coût réel. Les données terrain de Measurelab montrent 30 £/mois pour un site à 7K événements/mois et environ 402 £/mois (~500 $) pour un site traitant 200M événements/mois.
AWS : plus de contrôle, plus de composants
Si votre organisation tourne sur AWS et ne souhaite pas maintenir un compte GCP séparé juste pour GTM, AWS est une alternative viable. L’argumentaire pour le tracking server-side ne change pas selon votre fournisseur cloud. La même image Docker se déploie sur les services de conteneurs AWS. Mais la mise en place de l’infrastructure est sensiblement plus complexe.
ECS Fargate est l’option principale
AWS ECS Fargate exécute l’image du serveur de tagging sous forme de conteneurs managés sans gérer d’instances EC2. L’architecture nécessite plusieurs composants que Cloud Run gère automatiquement :
- Un VPC avec des sous-réseaux publics et privés
- Un Application Load Balancer pour la terminaison HTTPS
- Des NAT Gateway(s) pour l’accès internet sortant
- Route 53 pour la gestion DNS
Lari Haataja a publié un projet open-source AWS CDK qui automatise toute cette stack d’infrastructure, ce qui fait gagner un temps considérable sur la mise en place.
Le calcul brut est moins cher que Cloud Run. Une tâche Fargate équivalente (1 vCPU, 0,5 Go, toujours active) coûte environ 31 $/mois contre ~49 $ pour Cloud Run. Mais les coûts d’infrastructure érodent rapidement cet avantage :
| Composant | Coût mensuel |
|---|---|
| Tâche Fargate (1 vCPU, 0,5 Go) | ~31 $ |
| Application Load Balancer | ~16 $ |
| NAT Gateway (par gateway) | ~32 $ + frais de données |
| Total minimum | ~79 $+ |
Pour les petits déploiements, le coût total sur AWS dépasse souvent Cloud Run malgré un calcul moins cher. La page Guidance d’AWS estime environ 1 180,70 $/mois pour traiter 1M d’enregistrements/jour, bien que cela inclue un provisionnement d’infrastructure plus généreux.
Là où AWS l’emporte : un contrôle réseau granulaire, le support ARM/Graviton2 (20 % moins cher que x86) et les Savings Plans offrant jusqu’à 52 % de réduction sur des engagements de 3 ans. Pour les organisations traitant de gros volumes sur une infrastructure AWS existante, l’équation économique bascule en faveur d’AWS à grande échelle.
App Runner : plus simple mais plus cher
AWS App Runner est l’équivalent le plus proche de Cloud Run. Entièrement managé avec auto-scaling et HTTPS par défaut. Vous pointez vers l’image Docker et ça tourne. Mais App Runner coûte 1,5 à 2 fois plus que Fargate pour les workloads continus. Pour un serveur de tagging qui doit être toujours actif, cette prime s’accumule.
Lambda ne fonctionne pas
L’image du serveur de tagging GTM exécute un serveur HTTP Node.js persistant. Le modèle de fonctions de Lambda, conçu pour des invocations de courte durée, est architecturalement incompatible. N’essayez pas de le faire fonctionner.
Azure : la mise en place la plus fluide hors Google
Si vous êtes déjà dans l’écosystème Azure, vous avez deux bonnes options. Simo Ahava, la voix la plus reconnue de la communauté GTM, a qualifié la mise en place d’Azure App Service de “la plus fluide et la plus rapide” parmi les trois principaux fournisseurs cloud.
App Service
Deux instances App Service (une pour le serveur de tagging, une pour la prévisualisation) se déploient avec la configuration de conteneur Docker en utilisant les mêmes variables d’environnement que Cloud Run. Les certificats SSL managés par Azure fonctionnent avec les sous-domaines mappés par CNAME, bien que le SSL sur un domaine apex nécessite une configuration supplémentaire.
Tarification par niveau :
| Niveau | Coût mensuel | Idéal pour |
|---|---|---|
| B1 (Basic) | ~13 $ | Test/développement |
| S1 (Standard) | ~69 $ | Production |
| P1V3 (Premium) | ~124 $ | Workloads avec auto-scaling |
Le niveau production S1 à ~69 $/mois pour une seule instance est compétitif avec Cloud Run, et le processus de mise en place est véritablement plus simple si Azure est déjà votre plateforme cloud.
Container Apps
Azure Container Apps offre une expérience similaire à Cloud Run avec une tarification à la consommation et un auto-scaling basé sur le trafic HTTP. Si vous préférez le modèle de conteneur serverless plutôt que de gérer des plans App Service, Container Apps est le meilleur choix.
Functions ne fonctionne pas
Même raison que Lambda : Azure Functions est conçu pour des workloads event-driven de courte durée. Le serveur HTTP persistant de l’image GTM n’est pas compatible.
Hébergement managé : échanger le contrôle contre la simplicité
Les fournisseurs managés hébergent l’infrastructure GTM Server-Side pour vous. Vous renoncez au contrôle de l’infrastructure et gagnez en rapidité de mise en place, monitoring et certifications de conformité que vous devriez autrement gérer vous-même.
Stape.io
Stape domine le marché de l’hébergement managé et est souvent moins cher que Cloud Run en auto-hébergé. Leur modèle de tarification compte uniquement les requêtes entrantes, pas les transferts sortants vers GA4, Meta et les autres fournisseurs. Pour une configuration typique qui transfère chaque hit vers 3-4 endpoints, c’est une différence significative.
| Plan | Coût mensuel | Requêtes incluses |
|---|---|---|
| Gratuit | 0 $ | 10K |
| Pro | 20 $ | 500K |
| Business | 40 $+ | 2M+ |
| Enterprise | Sur mesure | Sur mesure |
Au-delà de l’hébergement, Stape inclut des fonctionnalités que vous devriez construire ou acheter séparément :
- Cookie Keeper : Étend la durée de vie des cookies contre les restrictions Safari ITP à 90 jours ou 13 mois
- Custom Loader : Renomme le script GTM pour résister à la détection par les bloqueurs de publicités
- CDN global : Routage multi-région inclus, aucune configuration de load balancer nécessaire
- Tableau de bord de monitoring : Volume de requêtes, taux d’erreurs et performance des tags
- Certifications : Conformité SOC2, HIPAA et ISO 27001
Pour les organisations sans équipes DevOps ou infrastructure cloud dédiées, Stape élimine entièrement la charge opérationnelle.
Addingwell
Addingwell, récemment acquis par la plateforme de gestion du consentement Didomi, se positionne comme l’option managée premium. À partir d’environ 90 EUR/mois, c’est plus cher que Stape mais inclut un SLA de disponibilité à 99,99 %, un monitoring en temps réel de la santé des tags et une approche EU-first pour la résidence des données.
L’acquisition par Didomi mérite d’être notée pour les organisations qui souhaitent regrouper leur gestion du consentement et leur hébergement server-side chez un seul fournisseur. Reste à voir si cette intégration apporte une valeur pratique au-delà de la synergie marketing.
TAGGRS
TAGGRS démarre à 19 EUR/mois avec un focus sur le marché européen. Certifié ISO 27001 avec résidence des données dans l’UE, c’est une option solide pour les organisations basées dans l’UE à la recherche d’un fournisseur managé économique.
Cloudflare Zaraz
Zaraz adopte une approche fondamentalement différente. Au lieu d’exécuter un conteneur serveur séparé, il traite le tracking au niveau du CDN edge de Cloudflare. Vos tags s’exécutent au point de présence Cloudflare le plus proche, pas dans un conteneur centralisé.
Il offre un impact quasi nul sur la latence de chargement de page, une couverture gratuite jusqu’à 1 million d’événements mensuels, et aucune infrastructure à gérer. Mais Zaraz n’est pas GTM Server-Side. C’est le propre système de gestion des tags de Cloudflare. Si vous êtes engagé dans l’écosystème GTM et sa Community Template Gallery, Zaraz ne sera pas un remplacement direct. Mais si votre objectif principal est de sortir le tracking du thread principal et d’améliorer la performance des pages, cela vaut la peine d’être évalué.
Choisir la bonne option
La décision repose sur trois facteurs : votre infrastructure cloud existante, votre capacité opérationnelle et votre budget.
| Facteur | Cloud Run | AWS Fargate | Azure App Service | Stape | Addingwell |
|---|---|---|---|---|---|
| Complexité de mise en place | Moyenne | Élevée | Faible-Moyenne | Très faible | Faible |
| Coût mensuel (moyen) | 90-270 $ | 100-300 $+ | 70-200 $ | 20-100 $ | 90 EUR+ |
| Contrôle infrastructure | Total | Total | Total | Aucun | Limité |
| Multi-région | Config load balancer | Complexe | Paires de régions | Inclus | Inclus |
| Monitoring | À construire | À construire | À construire | Inclus | Inclus |
| Intégration GTM | Native | Manuelle | Manuelle | Native | Native |
Si vous êtes déjà sur GCP : Cloud Run est le choix évident. Intégration GTM native, documentation exhaustive, et le chemin le plus simple du provisionnement automatique vers la production.
Si vous êtes sur AWS avec une infrastructure existante significative : ECS Fargate est pertinent à grande échelle, surtout avec les Savings Plans. Pour les implémentations plus modestes, les coûts d’infrastructure font basculer l’équation vers Cloud Run ou un fournisseur managé.
Si vous êtes sur Azure : App Service offre le chemin le plus rapide vers la production. La mise en place est véritablement simple, et le niveau S1 à ~69 $/mois est compétitif.
Si vous n’avez pas d’expertise en infrastructure cloud : Commencez avec Stape. Le plan Pro à 20 $/mois couvre la plupart des sites de petite à moyenne taille, inclut des fonctionnalités que vous mettriez des semaines à construire vous-même, et permet à votre équipe de se concentrer sur la configuration des tags plutôt que sur l’orchestration de conteneurs.
Si vous avez besoin de résidence des données dans l’UE et de certifications de conformité : Stape (ISO 27001, SOC2) et TAGGRS (ISO 27001) offrent cela clé en main. L’auto-hébergement atteint le même résultat mais vous impose de gérer la documentation IAM et conformité vous-même.
La décision d’hébergement n’est pas définitive. L’image du conteneur GTM Server-Side est la même image Docker quel que soit l’endroit où elle tourne. Migrer d’une plateforme à une autre signifie redéployer le même conteneur avec les mêmes variables d’environnement et mettre à jour vos enregistrements DNS. Choisissez l’option qui correspond à vos contraintes actuelles, en sachant que changer plus tard est une affaire d’heures, pas de semaines.