GTM server-side soi-même sur Cloud Run : le vrai coût sur 12 mois

Héberger soi-même un conteneur GTM server-side sur Google Cloud Run est à la portée d'une équipe qui sait déployer une image Docker : Google publie l'image officielle, et la facture d'infrastructure se mesure — nous ne la chiffrons pas à votre place, parce qu'elle dépend entièrement de votre configuration. Le coût réel est ailleurs : les montées de version du conteneur, la surveillance, l'astreinte quand un tag casse la veille d'un reporting, et la dépendance à la personne qui a tout monté. Le DIY (le faire soi-même) gagne quand vous avez une équipe data interne, un volume élevé et un besoin de contrôle total sur la donnée. Il perd partout ailleurs.

Cette page fait partie de nos comparatifs de solutions server-side. Elle ne compare pas deux produits : elle compare un produit à une décision d'organisation.

Combien coûte vraiment un sGTM sur Cloud Run ?

Le sGTM (server-side Google Tag Manager : le conteneur de tags exécuté sur un serveur, pas dans le navigateur) tourne sur une image publiée par Google. Sur Cloud Run, vous payez la machine : temps de calcul, mémoire, réseau sortant, logs.

Nous ne publions pas de montant mensuel pour cette voie. Les ordres de grandeur qui circulent sur ce sujet ne sont rattachés à aucune configuration documentée, et nous n'avons pas mesuré cette facture nous-mêmes : mettre un chiffre ici serait vous vendre une précision que nous n'avons pas.

Ce qui est sourcé, en revanche : un nouveau compte Google Cloud démarre avec 300 $ de crédits utilisables sur 90 jours (documentation Google Cloud, vérifiée le 12/08/2026). C'est exactement ce qu'il faut pour faire tourner votre propre conteneur et relever votre propre facture, plutôt que de recopier celle de quelqu'un d'autre.

Trois variables la font bouger fortement, et elles dépendent de votre configuration, pas de la nôtre :

• Le nombre d'instances minimum. À zéro, la facture descend mais les premières requêtes après une période creuse subissent un démarrage à froid. À une ou plus, la latence est stable et la facture monte, y compris la nuit.
• Le volume de requêtes serveur, qui n'est pas votre nombre d'events : un event peut déclencher plusieurs appels sortants (GA4, une API de conversions, un pixel).
• Les logs. Leur rétention se facture, et un conteneur bavard coûte plus cher qu'un conteneur silencieux.

Conclusion honnête : sur la ligne « infrastructure », le DIY est généralement le moins cher, parce que vous payez la machine et rien d'autre. Le débat ne se joue pas là. Pour poser vos propres hypothèses de volume face aux grilles publiées des hébergeurs, passez par notre calculateur de coût sGTM — la colonne auto-hébergement y est vide, pour la raison ci-dessus.

Quels sont les coûts cachés du DIY ?

Ce sont les postes qui n'apparaissent sur aucune facture, et que personne ne provisionne au moment de la décision.

Le dernier poste mérite son propre paragraphe, parce que c'est celui qui coûte le plus cher quand il se réalise.

Que se passe-t-il quand la personne qui a tout monté s'en va ?

Le concurrent réel d'une solution de tracking server-side n'est pas toujours un autre produit. C'est souvent un profil interne motivé — stagiaire, alternant, développeur curieux — qui monte l'installation en quelques jours et la fait tourner très correctement. Tant qu'il est là, ça marche, et c'est imbattable en coût.

Le problème arrive à son départ. Ce qui reste alors, dans la plupart des cas : un projet Google Cloud dont personne ne connaît le périmètre de facturation, un conteneur dont personne ne sait s'il est à jour, un sous-domaine dont personne n'a le certificat en calendrier, et des tags dont personne n'a le plan écrit. La première panne après le départ ne se répare pas — elle se ré-audite entièrement.

Deux garde-fous, à mettre en place avant que la question se pose, quelle que soit l'option retenue : un plan de taggage écrit et versionné, et une vérification automatique après chaque mise en production. C'est exactement ce que documente notre page produit sur le tracking server-side, et ce que traite notre page sur le tracking cassé après une refonte — le scénario où le conteneur va parfaitement bien pendant que la donnée est fausse.

Quand le DIY est-il le bon choix ?

Quatre situations où faire soi-même est objectivement la bonne décision :

1. Vous exploitez déjà du Cloud Run en production. CI/CD, monitoring, alerting et astreinte existent pour d'autres services. Le sGTM devient un service de plus, pas une compétence nouvelle.
2. Votre volume est très élevé. Au-delà de plusieurs dizaines de millions de requêtes par mois, les grilles managées deviennent le poste dominant, alors que le coût de la machine reste à peu près linéaire.
3. Vous avez une contrainte forte de contrôle. Région d'exécution imposée, réseau privé, logs bruts conservés chez vous, aucun tiers dans le chemin de la donnée. Ce sont des exigences légitimes qu'un hébergeur mutualisé ne satisfait pas toujours.
4. Vous avez besoin de code propriétaire dans le conteneur. Transformations métier, appels internes, enrichissements maison.

Si vous cochez au moins deux de ces cases, arrêtez la comparaison ici : montez-le vous-même.

Quand le DIY vous coûte-t-il plus cher qu'un service managé ?

1. Vous gérez des sites pour des clients. Dix clients, c'est dix conteneurs, dix domaines, dix historiques de version. La charge de maintenance se multiplie, pas votre savoir-faire. C'est le cas traité par notre page pour les agences.
2. Personne n'est d'astreinte. Une équipe marketing découvre la panne dans la courbe de conversions du lundi, pas dans une alerte du vendredi.
3. Votre site change souvent. Refonte, nouveau thème, nouveau tunnel : le conteneur continue de tourner pendant que les déclencheurs côté navigateur ne trouvent plus rien. Cloud Run n'a aucun moyen de le savoir.
4. Vous n'avez pas de plan de taggage écrit. Sans référentiel, il n'existe aucun moyen de dire si la donnée qui sort est juste. L'hébergement n'est alors pas votre problème.

Formulé autrement : Cloud Run héberge des tags, il ne juge pas ce qu'on lui envoie. Un conteneur impeccablement hébergé transmet des events faux avec la même régularité que des events justes.

Combien coûte 12 mois de DIY face à une solution managée ?

Scénario : un seul site, environ 5 millions de requêtes serveur par mois. Tous les prix concurrents sont vérifiés le 12/08/2026 et sont publics.

Un détail qui se voit rarement : chez Stape, le total annuel publié (1 000 $) est très légèrement au-dessus de douze mensualités (996 $), malgré le badge « −20 % » affiché sur le sélecteur annuel. Nous reprenons le total imprimé sur la page, pas le pourcentage.

Quatre précautions de lecture, sans lesquelles ce tableau ment :

• Les unités ne sont pas les mêmes. Stape et Addingwell facturent des requêtes serveur ; OnTracks facture des events envoyés. Le tableau compare des ordres de grandeur pour un même site, pas des équivalences strictes.
• Les périmètres ne sont pas les mêmes. Stape et Addingwell hébergent votre conteneur. Le setup fee OnTracks couvre la génération du plan de taggage, le déploiement du conteneur GTM et la vérification complète ; l'abonnement couvre la veille et la réparation. En DIY, ces trois postes existent aussi — ils sont simplement payés en heures internes.
• Stape facture par conteneur, soit un abonnement par site. Addingwell facture le conteneur supplémentaire 30 € et le domaine supplémentaire 10 € par mois.
• La colonne DIY est incomplète par construction. Ajoutez-y votre coût horaire chargé multiplié par les heures réellement consommées. C'est la seule variable qui décide, et c'est la seule que nous ne pouvons pas remplir à votre place.

La grille complète des paliers et des remises est sur notre page tarifs. Pour tester d'autres volumes et d'autres hypothèses de temps interne, le calculateur de coût sGTM fait l'arithmétique.

Comment chiffrer votre propre cas en une heure

1. Relevez votre volume réel de requêtes serveur sur un mois, pas votre nombre de sessions.
2. Estimez les heures. Mise en place, puis maintenance mensuelle, puis un incident par trimestre. Multipliez par votre coût horaire chargé.
3. Posez le point de rupture. À quel nombre de sites, ou à quel départ de collaborateur, votre installation devient-elle ingérable ? Si la réponse est « au deuxième site » ou « quand cette personne part », la décision est déjà prise.

Si vous hésitez entre deux hébergeurs managés plutôt qu'entre DIY et managé, la suite est dans notre comparatif Stape et notre comparatif Addingwell.