Application web
GTM Server DV
Notre propre tracking server-side pour six domaines
Comment Digital Vantage a sorti le tagging du navigateur pour le placer sur son propre serveur — first-party, résistant aux bloqueurs de publicité et piloté depuis un seul endroit pour tous les domaines
Infrastructure interne de Digital Vantage : un conteneur Google Tag Manager server-side auto-hébergé, qui tague le trafic de six domaines dans trois pays depuis un seul endroit. Il n’y a ni client ni interface — le cas met en avant une compétence DevOps et analytique : un tracking qui résiste aux bloqueurs de publicité, avec Consent Mode et notre propre monitoring, qui détecte une panne en cinq minutes au lieu d’un jour. Une réalisation de référence, en production.
6 domaines / 3 pays / 1 conteneur
Échelle du dispositif
- Client
- GTM Server DV
- Année
- 2026
- Stack technique
- GTM Server-Side · Docker Compose · Coolify + Traefik
- Durée
- 38 commits, mars–juin 2026
- Localisation
- Pologne (domaines PL / EU / CH)
01Contexte
Défi
Le tracking classique (gtag.js plus fbevents.js) présente trois faiblesses connues : les bloqueurs de publicité suppriment les scripts tiers, l’ITP de Safari efface les cookies tiers au bout de sept jours, et chaque script supplémentaire se paie en Core Web Vitals. Nous avons donc déplacé le tagging sur notre propre serveur — un seul script léger servi depuis un domaine first-party et un point de contrôle unique sur les tags de six domaines à la fois.
Le vrai défi est arrivé après le déploiement. Le 7 mai 2026, le tracking est tombé sur les six domaines : Google a modifié le tag de l’image du conteneur, et avec lui est arrivée une exigence de configuration que les conteneurs ne remplissaient pas ; /gtag/destination s’est alors mis à renvoyer des 400. La panne a duré plus d’un jour sans que personne ne la remarque — un monitoring existait, mais il vérifiait si le conteneur était en vie (toujours 200) et non si le tag acceptait réellement un événement ; de toute façon, il n’avait jamais fonctionné, car il lisait sa liste d’hôtes dans un fichier qui n’en contenait pas. C’est un humain qui a découvert la panne, à la main, dans la console du navigateur.
02Solution
Approche
Chaque décision répond à quelque chose qui a échoué. Le health check interroge désormais deux endpoints par hôte — « le conteneur est en vie » ET « GA4 accepte réellement un événement » — car c’est la seconde catégorie de panne qui était passée inaperçue. La configuration (hôtes, measurement IDs) est lue directement depuis un README unique, pour qu’elle ne puisse plus diverger comme auparavant.
L’image est épinglée à un SHA précis plutôt qu’à un tag mobile que Google modifie sans préavis — et comme un épinglage est une dette, un cron hebdomadaire détecte ce changement avant qu’il n’atteigne la production. Les alertes ont un cycle de vie dans GitHub Issues : le premier échec ouvre une issue et envoie un ping sur Discord, les suivants ajoutent seulement un commentaire, le rétablissement la referme — car douze pings identiques en une heure apprennent à une équipe à les ignorer. Toute la couche de monitoring représente ~1 027 lignes de bash, avec 84 tests en CI, car un script de monitoring non vérifié, c’est exactement le même problème qui recommence.
03Preuve
Résultats
6 domaines / 3 pays / 1 conteneur
Échelle du dispositif
>24 h → <5 min
Délai de détection d’une panne de tracking (MTTD)
10/10
Sondes saines en production
32 / 40
Événements applicatifs connus du conteneur
84 / 84
Tests bash en CI
Le délai de détection est passé de plus d’un jour à moins de cinq minutes : la vérification synthétique lance 10 sondes toutes les 5 minutes et envoie un ping sur Discord dès le premier échec. Mesuré le 16 juillet 2026 — 10 sondes saines sur 10, toutes en 200. Six domaines dans trois pays tournent sur un seul conteneur doté de 512 Mo de RAM et d’un demi-cœur, sur un VPS existant, sans coût supplémentaire par rapport à un environnement d’exécution cloud managé.
Nous lisons cela comme un résultat d’ingénierie et le présentons comme tel. Nous ne revendiquons pas « 99,9 % de disponibilité » — il n’existe ici aucun historique d’exécution permettant de le calculer. Un temps moyen de détection inférieur à cinq minutes est correct par construction, mais il ne repose que sur une seule panne antérieure au déploiement, et non sur une série de détections postérieures. C’est précisément cette honnêteté — mesurer ce qui a été mesuré — que ce projet doit démontrer.
GTM server-side auto-hébergé pour 6 domaines, avec un monitoring qui a ramené la détection des pannes de tracking de plus d’un jour à 5 minutes.
Stack technique
- GTM Server-Side
- Docker Compose
- Coolify + Traefik
- Cloudflare
- GitHub Actions
- Bash
- GA4
- Consent Mode v2
- Next.js
VOS DONNÉES
Vous perdez des conversions à cause du blocage dans le navigateur ?
Je déplace le tracking sur votre propre serveur — first-party, résistant aux bloqueurs de publicité, piloté depuis un seul endroit.