Votre conteneur GTM server-side vous a coûté environ 150 € ce mois-ci, et deux nouvelles récentes viennent de fissurer la promesse sur laquelle vous l’aviez déployé. D’abord, les ad blockers coupent désormais les sous-domaines sgtm. par leur nom. Ensuite, Google a rebranché des signaux navigateur dans le tagging server-side, le rendant moins isolé qu’annoncé. La question tombe donc naturellement : et si Cloudflare Zaraz, gratuit et exécuté à l’edge, réglait ces deux problèmes autrement qu’un GTM server-side classique ? C’est le match que cet article arbitre, chiffres et cas d’usage à l’appui, pour que vous sachiez lequel choisir sans vous tromper.
Pourquoi la question se pose maintenant (et pas l’an dernier)
Le server-side tagging n’est plus un sujet de niche. Son adoption a explosé (plusieurs sources 2026 parlent d’une hausse de plus de 400 % depuis 2023), et avec elle deux prises de conscience désagréables.
La première, c’est le coût. Un conteneur sGTM classique sur Cloud Run, dimensionné pour ne jamais tomber en rade au pic, tourne facilement autour de 120 à 200 € par mois une fois les instances toujours actives comptées. J’ai détaillé ce chiffrage dans combien coûte vraiment le GTM server-side : ce n’est pas ruineux, mais ce n’est pas gratuit non plus, surtout pour un petit site.
La seconde, c’est que le sGTM classique prend l’eau sur deux points que je viens de couvrir sur ce blog. Les ad blockers ne se contentent plus de bloquer googletagmanager.com, ils ciblent maintenant les sous-domaines sgtm. par leur nom. Et Google a discrètement recouplé le tagging server-side au navigateur via des signaux parallèles, ce qui abîme l’argument d’isolation. Zaraz répond à ces deux points par une architecture radicalement différente. Voyons comment.
Comment marche Cloudflare Zaraz (l’approche edge)
Zaraz part d’un principe simple : le JavaScript des vendeurs (GA4, Meta, TikTok) ne devrait pas s’exécuter dans le navigateur de vos visiteurs. Au lieu de charger dix scripts tiers côté client, Zaraz envoie une seule requête légère, et toute la logique des outils tourne sur le réseau edge de Cloudflare, dans des Workers, au plus près de l’utilisateur.
Techniquement, chaque intégration est un Managed Component (une spécification open source), un petit module qui reçoit l’événement et parle directement à l’API du vendeur depuis l’edge. Résultat : aucun code vendeur n’atterrit chez le visiteur, et les requêtes partent de votre domaine, servi par le même proxy Cloudflare que votre site.
Trois conséquences concrètes découlent de ce design. Côté performance, vous retirez du poids du navigateur, ce qui aide directement vos Core Web Vitals. Côté Safari et ITP, comme les cookies sont posés en HTTP depuis l’edge sur votre propre domaine, ils échappent au plafond des sept jours imposé aux cookies posés en JavaScript. Côté consentement enfin, le Google Consent Mode v2 est géré nativement, sans bricolage de template.
Un exemple concret pour ancrer tout ça : sur un site e-commerce que je servais déjà via Cloudflare, basculer GA4 et Meta sur Zaraz a retiré près de 90 Ko de JavaScript tiers du chargement initial. Le navigateur ne téléchargeait plus les scripts vendeurs, il envoyait un seul appel à l’edge. Sur mobile en 4G, ce genre d’allègement se voit directement dans le LCP, et donc dans ce que Google mesure pour votre référencement.
Le prix de cette élégance, c’est une dépendance : votre DNS doit être proxifié chez Cloudflare (le fameux nuage orange). Si votre site n’est pas déjà derrière Cloudflare, Zaraz n’est pas une option plug-and-play, c’est une décision d’infrastructure.
Comment marche un GTM server-side classique
Le sGTM classique, lui, déplace votre conteneur GTM sur un serveur que vous contrôlez : un conteneur Node.js hébergé sur Cloud Run, ou chez un hébergeur managé comme Stape, Addingwell ou Taggrs. Les événements du site partent vers ce conteneur, qui les nettoie, les enrichit et les redistribue aux plateformes.
Nuance importante, souvent oubliée : dans la plupart des setups, un conteneur web tourne toujours dans le navigateur pour capter les événements avant de les envoyer au serveur. Le sGTM n’efface pas totalement le client-side, il déplace la partie sensible. C’est ce détail que Google a exploité en rebranchant des signaux navigateur.
En échange, vous héritez d’un écosystème mature. La galerie de templates communautaires est immense, et les intégrations CAPI (Meta, TikTok, Pinterest, Snapchat, LinkedIn, X, Microsoft) y sont profondes et paramétrables au détail près : déduplication, EMQ, hachage des données, fenêtres de conversion. Si votre sujet du moment est la qualité du matching, par exemple la Meta CAPI et sa déduplication EMQ, le sGTM classique reste le terrain de jeu le plus riche. Pour bien démarrer, mon guide de migration server-side et le comparatif des hébergeurs Stape vs Addingwell vs Taggrs posent les bases.
Zaraz vs GTM server-side : le tableau de décision
Voici les deux approches face à face sur les critères qui décident vraiment.
| Critère | Cloudflare Zaraz | GTM server-side classique |
|---|---|---|
| Coût de départ | Gratuit jusqu’à environ 1 M d’events/mois inclus | Environ 120 à 200 €/mois (Cloud Run) ou 20 à 200 €/mois (hébergeur managé) |
| Facturation au volume | À l’usage au-delà du palier (quelques dollars par million, à vérifier sur la grille officielle) | Coût qui grimpe avec le trafic et les instances |
| JS vendeur dans le navigateur | Aucun (exécution 100 % edge) | Un conteneur client tourne encore côté navigateur |
| Catalogue d’intégrations | Managed Components, catalogue plus restreint | Galerie de templates communautaires très large |
| Profondeur CAPI | Correcte, moins fine sur le paramétrage | Très fine (dédup, EMQ, hachage, fenêtres) |
| Safari / ITP | Cookies posés en HTTP depuis l’edge, hors plafond 7 jours | First-party, mais exposé au recouplage navigateur récent |
| Consent Mode v2 | Natif | Via template, à configurer soi-même |
| Complexité de mise en place | Faible si déjà sur Cloudflare | Moyenne à élevée (conteneur, DNS, monitoring) |
| Dépendance structurante | DNS proxifié chez Cloudflare obligatoire | Un hébergeur ou une facture cloud à gérer |
Le tableau dit l’essentiel : Zaraz gagne sur le coût, la simplicité et la performance, le sGTM classique gagne sur la profondeur et le contrôle.
Qui devrait choisir quoi
Si vous gérez un petit ou moyen site déjà servi par Cloudflare, avec un budget serré et des besoins de tracking standards (GA4, une ou deux plateformes publicitaires, du consentement propre), Zaraz est probablement le meilleur rapport résultat/effort de 2026. Vous gagnez la performance et l’échappatoire aux ad blockers presque gratuitement.
Si vous êtes un annonceur avec un budget média conséquent, plusieurs CAPI à alimenter et une exigence forte sur la qualité du matching, restez sur un sGTM classique (Cloud Run ou hébergeur managé). Le surcoût mensuel est négligeable face à ce que vaut un point d’EMQ gagné sur vos campagnes.
Attention à ne pas confondre Zaraz avec le Google Tag Gateway, le mode first-party officiel de Google. Le Gateway sert vos tags Google depuis votre domaine mais garde l’exécution côté navigateur, là où Zaraz sort carrément le JS vendeur du client. J’ai comparé le Gateway au sGTM dans Google Tag Gateway vs server-side GTM : Zaraz est une troisième voie, tierce et edge, pas un synonyme du Gateway.
Peut-on faire les deux (ou migrer de l’un à l’autre) ?
Oui, et c’est parfois la bonne réponse. Rien n’empêche de faire tourner Zaraz pour l’analytics et le consentement, tout en gardant un sGTM pour les CAPI les plus exigeantes. Vous cumulez alors la performance edge sur le gros du volume et la finesse du conteneur là où elle compte.
Concrètement, la bascule se teste sans rien casser. Vous pouvez lancer Zaraz en parallèle de votre setup existant sur une fraction du trafic, comparer les volumes remontés dans GA4 et dans le gestionnaire d’événements Meta, puis basculer une fois l’écart mesuré et accepté. C’est la seule façon sérieuse de migrer un tracking en production : jamais à l’aveugle, toujours avec un double comptage temporaire pour valider que vous ne perdez pas de conversions au passage.
Migrer entièrement de sGTM vers Zaraz se fait, mais mesurez ce que vous perdez : la galerie de templates communautaires, certaines transformations serveur avancées, et la liberté d’un conteneur que vous scriptez comme vous voulez. Ce que vous gagnez en échange est réel : un navigateur allégé, de meilleurs Core Web Vitals, et une facture qui fond. À vous de peser les deux plateaux honnêtement plutôt que de suivre le mot “gratuit”.
Verdict et checklist de décision
Zaraz n’est pas “mieux” que le sGTM dans l’absolu, il résout un problème différent avec des contreparties différentes. Pour trancher en cinq minutes, passez ces huit points en revue :
- Votre site est-il déjà servi par Cloudflare ? Si non, Zaraz devient un chantier d’infra.
- Votre volume mensuel d’events dépasse-t-il le palier gratuit ? Chiffrez le coût réel des deux côtés.
- Combien de CAPI devez-vous alimenter, et à quel niveau de finesse (EMQ, dédup) ?
- La performance et les Core Web Vitals sont-ils un enjeu SEO chez vous ?
- Avez-vous besoin de transformations serveur avancées qu’un template Zaraz ne couvre pas ?
- Vos audiences sont-elles fortement sur Safari, donc exposées à ITP ?
- Qui maintiendra le setup dans six mois, et avec quelles compétences ?
- Un modèle hybride (Zaraz + sGTM) ne serait-il pas la vraie réponse ?
Si vous cochez surtout les premiers points, testez Zaraz dès maintenant, avant le pic Q4. Si vous cochez surtout les CAPI et le contrôle, gardez votre sGTM et optimisez-le. Dans le doute, la fenêtre d’avant Black Friday est le bon moment pour trancher, pas celui pour improviser en plein pic.