GTM Server-Side : Cloud Run ou Stape, que choisir ?

Héberger son conteneur GTM server-side : coût réel, propriété des données, charge d’exploitation

Un conteneur GTM server-side, c’est un conteneur Docker qui reçoit des requêtes HTTP, applique la configuration de votre conteneur et route les événements vers GA4, Google Ads, Meta ou BigQuery. Ce que vous choisissez en réalité, ce n’est pas un outil : c’est l’infrastructure qui exécute ce conteneur, et le projet cloud dans lequel les données transitent.

Stape vend cette exécution en abonnement, facturée à la requête. Google la vend à la seconde de CPU, sur Cloud Run. Le conteneur que vous configurez dans Tag Manager reste identique dans les deux cas. Ce qui change : qui possède le projet, qui voit les logs, qui porte la charge d’exploitation, et ce qui se passe le jour où le trafic double sans prévenir.

Je compare ici les deux montages sur ce qui décide vraiment : coût réel, contrôle des données, limites techniques. Avec les chiffres publics et ce que j’ai pu vérifier moi-même.

À quoi sert un conteneur GTM Server-Side ?

Réponse courte : il déplace le traitement des balises du navigateur vers un serveur que vous contrôlez, et il sert les scripts de mesure depuis un domaine first-party.

Découvrez égalementComment gouverner efficacement un conteneur GTM ?

Concrètement, votre page n’appelle plus directement les plateformes. Elle envoie un ou plusieurs hits à une URL de collecte — par exemple metrics.votresite.com — qui pointe vers le conteneur. Celui-ci reçoit la requête, l’interprète avec un client (GA4, Data Client, client personnalisé), applique vos transformations, puis déclenche les balises sortantes.

Ce que le conteneur apporte :

• Moins de JavaScript tiers exécuté dans la page.
• Un point de passage unique où normaliser, minimiser ou bloquer des champs.
• Des cookies posés côté serveur (HttpOnly), à condition de servir depuis un sous-domaine du site. Google le documente noir sur blanc : sur l’URL run.app par défaut, l’accès aux cookies serveur est nul, vous ne pouvez poser que des cookies JavaScript.
• Des logs d’exécution exploitables : quels hits sont arrivés, quelles balises ont tiré, avec quels paramètres.

Ce qu’il n’apporte pas :

• Il ne remplace pas le consentement. Un hit envoyé sans consentement reste un hit sans consentement, même s’il part d’un serveur.
• Il ne rend pas les cookies immortels. Le first-party context améliore leur durée de vie, il ne neutralise pas les politiques navigateur.
• Il ne corrige pas un plan de taggage faux. Il déplace le problème.

Le cadrage de ce que le conteneur a le droit de transmettre est un chantier à part entière : j’ai détaillé la méthode dans comment contrôler les données avec le Server-Side GTM. Et un hit mal déclenché côté web reste mal déclenché côté serveur — fiabiliser vos déclencheurs GTM reste la première brique avant d’ajouter une couche d’infrastructure.

Sur le gain de performance côté navigateur, j’ai déjà mesuré l’effet réel des balises dans Google Tag Manager ralentit-il votre site ?. Le server-side déplace une partie du coût, il ne le supprime pas.

Découvrez égalementComment fiabiliser vos déclencheurs GTM ?

Le détail technique qui compte pour la suite : l’image officielle est gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable, et Google documente explicitement qu’elle peut tourner ailleurs que chez lui, via Docker. Le serveur de preview et le serveur de production utilisent la même image, avec des variables d’environnement différentes. Je l’ai tirée et lancée ici pour vérifier : c’est bien une application Node.js (24.22.1) qui expose --container_config, --run_as_preview_server, --preview_server_url, --port. Elle refuse de démarrer sans une chaîne de configuration GTM valide.

Autrement dit : l’hébergement est une commodité. C’est précisément ce qui rend la comparaison légitime.

Que fait Stape à votre place ?

Stape exécute votre conteneur sur son infrastructure et vous facture au volume de requêtes entrantes, par conteneur.

C’est un vrai service, pas un simple revendeur d’instance. Voici l’offre publique consultée le 8 novembre 2026, prix mensuels, tarif annuel entre parenthèses quand il diffère :

Ce que l’abonnement achète au-delà de l’hébergement :

• Des power-ups qui n’existent pas nativement dans GTM : Custom Loader (renommage des chemins de scripts), Cookie Keeper, Anonymizer, Bot Detection, Enricher, Data Store.
• Une infrastructure multi-zone à partir du plan Business.
• Des logs de 3 à 10 jours selon le plan, exportables vers S3 ou GCS seulement à partir du plan Enterprise.
• Un support 24/7 par email et chat.

Découvrez égalementComment contrôler les données avec le Server-Side GTM ?

La contrepartie est dans la définition même du compteur. Stape compte toute requête entrante, y compris les chargements de gtm.js, gtag.js et analytics.js, et les hits du mode preview. Leur propre règle d’estimation : nombre de pages vues × 10. Un plan Business couvre donc environ 500 000 pages vues par mois, pas 5 millions de visites. Et quand le quota est atteint, le conteneur cesse de servir jusqu’au prochain cycle, sauf si l’auto-upgrade est activé.

Ce dernier point n’est pas un détail tarifaire. C’est un mode de défaillance. Vous pouvez perdre la collecte parce qu’un pic de trafic, un bot ou une session de debug a consommé le quota.

Pourquoi héberger sur Cloud Run plutôt que chez Stape ?

Parce que vous achetez du contrôle, pas des fonctionnalités. Cinq différences structurelles, dans l’ordre où elles pèsent en production et en audit.

Le projet cloud vous appartient

Sur Cloud Run, le service tourne dans votre projet GCP — ou dans celui du client, ce qui est souvent la bonne réponse en agence. Vous gardez la main sur l’IAM, les rôles, les comptes de service, la facturation et le périmètre des données. Une solution packagée ajoute un sous-traitant dans le chemin de la donnée : ce n’est pas rédhibitoire, Stape propose un DPA et un hébergement européen, mais c’est une ligne de plus à documenter dans votre registre de traitement et à faire accepter par un client prudent.

Quand un RSSI demande où passent les données, qui y accède et combien de temps elles sont conservées, la réponse est plus simple quand le projet est chez lui et que les logs sont dans son Cloud Logging.

La facture suit la compute, pas le nombre de requêtes

Cloud Run facture la seconde de CPU et de mémoire, arrondie à 100 ms. Il n’existe pas de quota de requêtes qui coupe le service. Le seul plafond est le --max-instances que vous fixez, et il plafonne le coût, pas la disponibilité : Cloud Run n’alloue pas d’instances inutiles, il monte jusqu’au maximum si le trafic l’exige.

Conséquence pratique : une opération marketing qui multiplie le trafic par cinq ne change pas votre ligne budgétaire du mois de 300 %. Elle change votre facture à la marge, et vous la voyez dans Cloud Billing.

Les logs restent chez vous

Chaque requête traitée par le conteneur produit une entrée dans Cloud Logging. Vous filtrez, vous alertez, vous exportez vers BigQuery ou Cloud Storage avec vos propres règles de rétention, sans changer de plan. Chez Stape, l’export de logs vers S3 ou GCS est une fonctionnalité du plan Enterprise, et la rétention va de 3 à 10 jours selon le plan.

Pour un audit de taggage — savoir si un hit est bien parti le 12 mars à 14 h 32 — la différence n’est pas cosmétique. Ces logs finissent la plupart du temps dans BigQuery, où les réflexes de réduction des coûts BigQuery de GA4 s’appliquent aussi.

L’écosystème autour du service est déjà là

Un conteneur de tagging en production n’est jamais seul. Sur Cloud Run, vous branchez sans friction :

• Un load balancer global avec certificat managé et Cloud CDN.
• Cloud Armor pour filtrer le trafic hostile avant qu’il n’atteigne le conteneur.
• Secret Manager pour les clés d’API utilisées par vos balises.
• IAM et VPC Service Controls pour cloisonner l’accès.
• Terraform pour versionner le déploiement.

C’est rejouable, testable, versionnable dans un dépôt Git. Une plateforme packagée vous donne des cases à cocher ; elle ne vous donne pas la main sur le plan de contrôle.

L’image reste portable

Le jour où Cloud Run ne convient plus — contrainte de coût, migration vers un autre cloud, besoin d’un sidecar réseau, hébergement sur site — vous redéployez la même image Docker ailleurs. Google documente ce chemin : docker run avec CONTAINER_CONFIG et PREVIEW_SERVER_URL, sur n’importe quel hôte capable de servir du HTTPS.

# Serveur de tagging local, même image que sur Cloud Run
docker run -p 8080:8080 \
  -e CONTAINER_CONFIG='<chaîne fournie par GTM : Admin > Paramètres du conteneur>' \
  -e PREVIEW_SERVER_URL='https://preview.metrics.votresite.com' \
  gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

# Le conteneur expose un endpoint de santé
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080/healthy

Vous ne réécrivez pas votre conteneur GTM, vous le déplacez. C’est l’inverse d’un verrouillage de configuration. Attention tout de même : les templates et power-ups propres à un hébergeur, eux, ne se transportent pas.

Combien coûte vraiment un serveur Cloud Run ?

Google donne l’ordre de grandeur : environ 45 $ par serveur et par mois, pour une instance de 1 vCPU et 512 Mo de mémoire en CPU always allocated. La page d’aperçu parle de 30 à 50 $ par serveur après montée en charge.

Ce chiffre ne dit pas combien d’instances il faut. Google recommande au moins 3 instances minimum pour la redondance. Or les instances minimum sont facturées même à l’arrêt : ce sont des instances inactives que vous payez pour éviter les démarrages à froid.

Voici le calcul complet, avec les tarifs publics du 8 novembre 2026 (0,000018 $ par vCPU-seconde, 0,000002 $ par GiB-seconde, 240 000 vCPU-secondes et 450 000 GiB-secondes gratuits par mois, free tier déduit) :

Les trois premières lignes se lisent dans le guide Cloud Run, et se vérifient à la main : 3 × 730 h × 3 600 s × 0,000018 $ = 141,91 $ de CPU, plus 7,88 $ de mémoire. Le compte est vite fait, et il est plus élevé que le chiffre « 45 $ » lu un peu vite.

Mise en face avec l’offre Stape, à volume équivalent :

Conclusion inconfortable mais honnête : sous 500 000 pages vues par mois, Cloud Run coûte plus cher que Stape. Ce n’est pas un argument prix. C’est un argument de contrôle, et il faut l’assumer comme tel.

Trois réserves sur ce tableau :

• Il exclut le trafic réseau sortant, le load balancer et un éventuel déploiement multi-région, que Google signale comme facteurs de surcoût.
• Les prix Stape sont des tarifs publics : remises et plans custom existent.
• Le coût réel de Cloud Run inclut votre temps. Une mise à jour d’image, un incident, un pic à diagnostiquer : c’est vous.

Le déploiement lui-même tient en une commande, avec les trois leviers de coût visibles :

# Commande reprise de la documentation Google (guide Cloud Run, mai 2026).
# Je ne l'ai pas rejouée ici : gcloud n'est pas installé sur cette machine.
gcloud run deploy "server-side-tagging" \
  --region europe-west9 \
  --image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
  --platform managed \
  --ingress all \
  --min-instances 3 \
  --max-instances 10 \
  --timeout 60 \
  --allow-unauthenticated \
  --no-cpu-throttling \
  --update-env-vars PREVIEW_SERVER_URL="$(gcloud run services describe server-side-tagging-preview --region europe-west9 --format='value(status.url)')",CONTAINER_CONFIG="CONTAINER_CONFIG"

Trois lignes décident de la facture : --min-instances (le plancher facturé en permanence), --max-instances (le plafond de sécurité, pas une réservation) et --no-cpu-throttling (CPU always allocated, indispensable pour un conteneur de tagging qui répond en quelques dizaines de millisecondes). Google précise aussi qu’il ne faut jamais allouer plus de 1 vCPU par instance : on scale en nombre d’instances, pas en puissance unitaire, sinon l’autoscaling régresse.

Qu’est-ce que vous perdez en quittant une solution packagée ?

Vous perdez l’exploitation déléguée, et il faut la chiffrer avant de migrer.

• Les mises à jour de l’image. Google publie des versions avec correctifs de sécurité et recommande de suivre au moins les versions majeures. Sur Cloud Run, cela veut dire redéployer une révision avec la même configuration.
• Les démarrages à froid. Avec --min-instances 0, vous gagnez de l’argent et vous perdez des hits au premier appel. En tagging, un hit perdu ne se rejoue pas.
• Les power-ups. Bot detection, Cookie Keeper, Anonymizer, Enricher, Data Store : rien de tout cela n’est dans GTM. Il faut les reconstruire avec des templates personnalisés, Cloud Armor, BigQuery ou des Cloud Functions. C’est faisable ; ce n’est pas gratuit.
• Le multi-région. Google documente un montage à base de load balancer et de NEG, région par région. C’est du travail d’infrastructure, pas une case à cocher.
• Le support. Vous êtes l’astreinte. Sur un conteneur qui reçoit tout votre tracking e-commerce, ça se décide à froid, pas le jour de la panne.
• Une contrainte à connaître : la concurrence par instance est de 80 requêtes par défaut, et monter à 1 000 est possible mais rarement pertinent pour ce type de conteneur.

Rien de tout cela ne remplace la gouvernance du conteneur lui-même : un service bien hébergé avec un conteneur mal tenu reste un problème de données. J’ai détaillé ce volet dans comment gouverner efficacement un conteneur GTM.

Cloud Run est-il le bon choix pour votre conteneur ?

Ça dépend de trois choses : qui peut opérer le service, ce que pèse le volume de requêtes, et ce qu’un auditeur exigera. Il n’y a pas de meilleur hébergeur dans l’absolu, il y a un bon montage par contexte.

Un point d’attention pour les agences : héberger les conteneurs de vos clients dans votre propre projet GCP vous met en position de sous-traitant, avec les mêmes obligations que celles que vous reprochez à une plateforme. Le bon réflexe est de provisionner le service dans le projet du client, avec un accès délégué. Vous opérez, il possède.

Les trois questions qui tranchent :

1. Avez-vous quelqu’un capable de déployer une révision, lire un log Cloud Run et réagir à une alerte à 22 h ? Si non, payer l’exploitation déléguée est rationnel.
2. Le volume de requêtes est-il le principal poste de coût ? Si oui, la facturation à la compute devient un avantage structurel, pas un détail.
3. Un tiers peut-il exiger la liste des sous-traitants et la localisation des données ? Si oui, le projet GCP chez vous simplifie la réponse.

Si vous répondez non aux trois, Stape reste un excellent choix et le débat n’a pas lieu d’être. Si vous répondez oui à une seule, le calcul change.

Le server-side GTM n’est pas un sujet d’outil, c’est un sujet de propriété de l’infrastructure de mesure. Tant que ce conteneur reçoit vos événements de conversion, il mérite le même niveau d’exigence qu’un pipeline de données : quelqu’un doit savoir où il tourne, qui peut le lire et ce qui se passe quand il tombe.

• Peut-on héberger un conteneur GTM server-side ailleurs que sur Google Cloud ?
  Oui. L’image Docker gtm-cloud-image est documentée pour tourner sur n’importe quel hôte capable de servir du HTTPS : un serveur classique, Kubernetes, un autre cloud. Cloud Run est la voie recommandée par Google, pas la seule.
• Cloud Run est-il moins cher que Stape ?
  Non, pas sous 500 000 pages vues par mois avec 3 instances minimum. Cloud Run coûte un montant fixe, dominé par les instances toujours actives, alors que Stape suit le volume de requêtes. À très fort volume, l’écart se resserre, mais il ne s’inverse pas automatiquement.
• Faut-il vraiment 3 instances minimum ?
  Google recommande 3 instances pour la redondance. Avec une seule, un redéploiement ou une indisponibilité de zone peut faire perdre des hits. L’arbitrage se fait entre environ 45 $ et 145 $ par mois, à mettre en face du coût d’une journée de données manquantes.
• Le server-side GTM sur Cloud Run est-il conforme au RGPD ?
  L’hébergeur ne suffit pas à rendre un dispositif conforme. Ce qui compte : base légale, recueil du consentement, minimisation des champs, DPA signé et localisation. Cloud Run permet de choisir une région européenne et garde les logs dans votre projet, ce qui simplifie la démonstration. Ça ne remplace pas l’analyse juridique.
• Que se passe-t-il si je dépasse le quota Stape ?
  Sans auto-upgrade, le conteneur cesse de servir jusqu’au prochain cycle de facturation. Avec auto-upgrade, il passe au palier supérieur et la facturation suit. Dans les deux cas, c’est un comportement lié à l’abonnement, pas à une panne technique.

Sources

1. Google for Developers, « Server-side tagging », mis à jour le 6 novembre 2026 — https://developers.google.com/tag-platform/tag-manager/server-side/overview
2. Google for Developers, « Set up server-side tagging with Cloud Run », mis à jour le 12 mai 2026 — https://developers.google.com/tag-platform/tag-manager/server-side/cloud-run-setup-guide?provisioning=manual
3. Google for Developers, « Custom domain configuration », mis à jour le 27 juin 2025 — https://developers.google.com/tag-platform/tag-manager/server-side/custom-domain
4. Google for Developers, « Manual setup guide », consulté le 8 novembre 2026 — https://developers.google.com/tag-platform/tag-manager/server-side/manual-setup-guide
5. Google Cloud, « Cloud Run pricing », consulté le 8 novembre 2026 — https://cloud.google.com/run/pricing
6. Google Cloud, « Set minimum instances for services », consulté le 8 novembre 2026 — https://cloud.google.com/run/docs/configuring/min-instances
7. Google Cloud, « Maximum concurrent requests for services », consulté le 8 novembre 2026 — https://cloud.google.com/run/docs/about-concurrency
8. Stape, « Pricing and plans », consulté le 8 novembre 2026 — https://stape.io/price
9. Stape Helpdesk, « Plan tiers and limits », mis à jour le 1er septembre 2026 — https://stape.io/helpdesk/documentation/plan-tiers-and-limits
10. Stape Helpdesk, « What is a request », mis à jour le 12 octobre 2026 — https://stape.io/helpdesk/knowledgebase/what-is-a-request
11. Stape Helpdesk, « How do you calculate requests », mis à jour le 11 août 2026 — https://stape.io/helpdesk/knowledgebase/how-do-you-calculate-requests

À propos de l’auteur

Franck Scandolera est analytics engineer et data engineer. Il conçoit des pipelines de mesure et des architectures de collecte — GTM server-side, GA4, BigQuery — et automatise les traitements qui vont avec. Il forme des équipes marketing et data sur ces sujets.

Franck Scandolera

Dev d’applications métier · Data Engineer · Automatisation IA

Clients : Logis Hôtels, Yelloh Village, BazarChic, FFF, Texdecor…

Apps & agents IA : Node.js, Python, API, RAG, OpenAI, Mistral, Claude
Data Engineering : BigQuery, Snowflake, PostgreSQL, ClickHouse, dbt, Airflow, Dataform, Looker, Power BI, Metabase
Automatisation IA : n8n, Apps Script, scraping, API, LLM
Tracking & perf Web : GA4, GTM server, Matomo, Piano, Tealium, CAPI, Core Web Vitals