Attention, ce n’est pas un simple détail technique
Le changement paraît minuscule. Une option de plus dans le Web Container Client de server-side Google Tag Manager.
En réalité, ce n’est pas juste une case de configuration. C’est un nouveau signal dans la stratégie de Google : servir les tags Google depuis une infrastructure first-party, avec des chemins plus propres, plus discrets, et plus difficiles à identifier par de simples règles d’URL.
Depuis cette mise à jour, le Web Container Client de SGTM peut associer un chemin personnalisé à chaque Tag ID ajouté dans la CDN allowlist. Concrètement, au lieu de charger un conteneur avec un format du type gtm.js?id=GTM-XXXXXX, on peut utiliser un chemin dédié. D’après les tests remontés par Simo Ahava, le format classique avec ?id=GTM-XXXXXX semble encore fonctionner même si un chemin personnalisé est configuré.
Ce qui change vraiment
Avant, quand on servait un conteneur GTM web via un serveur SGTM, on avait souvent une URL de ce type :
https://tracking.example.com/gtm.js?id=GTM-ABC123
Avec le nouveau Tag serving path, l’idée devient plutôt :
https://tracking.example.com/mon-chemin-personnaliseOu, dans une logique plus obfusquée :
Formez-vous à Google Tag Manager !
Apprenez grâce à nos formations Google Tag Manager une compétence précieuse pour tout professionnel du web. Cet outil permet de simplifier la gestion des balises, de gagner du temps, d'améliorer la précision des données et de personnaliser le suivi des événements. En maîtrisant GTM, vous pouvez optimiser vos campagnes marketing, améliorer les performances de votre site et prendre des décisions basées sur des données fiables et précises.
https://tracking.example.com/a8xk92Le Web Container Client de SGTM permet déjà depuis plusieurs années de proxyfier un conteneur GTM web : le serveur récupère la librairie côté Google, puis la sert au navigateur depuis un endpoint first-party, par exemple un sous-domaine appartenant au site.
La nouveauté est donc plus fine : on ne parle plus seulement de servir gtm.js depuis son propre domaine. On parle de masquer ou personnaliser le chemin de chargement.
Et ça change la lecture du sujet.
L’explication officielle : éviter les conflits de chemins
L’explication “propre” est simple : un chemin personnalisé permet d’éviter les conflits avec des chemins déjà utilisés par le site ou par l’infrastructure serveur.
Sur le papier, oui. C’est techniquement vrai. Dans les documentations Google Tag Gateway, Google insiste d’ailleurs sur la nécessité d’utiliser des chemins distincts : un chemin pour servir les scripts, un autre pour la collecte SGTM, par exemple /scripts et /metrics.
Même logique côté Akamai : le champ Serving Path doit commencer par /, utiliser un chemin court et surtout être unique, non utilisé ailleurs sur le site.
Mais soyons sérieux deux minutes.
Quand une entreprise a déjà configuré SGTM sur un sous-domaine dédié du type :
https://sgtm.example.com
ou sur un chemin same-origin du type :
https://www.example.com/metricsle risque de conflit existe, mais ce n’est pas le sujet le plus intéressant.
Le sujet intéressant, c’est que cette option retire un marqueur très visible dans l’URL : gtm.js?id=GTM-XXXXXX.
Le vrai sujet : Google renforce le first-party serving
Cette mise à jour s’inscrit dans une évolution beaucoup plus large : Google pousse ses tags vers des architectures first-party.
Google Tag Gateway permet déjà de charger le Google tag depuis l’infrastructure first-party du site, au lieu de le charger directement depuis un domaine Google. Dans un setup classique, la page demande le tag à un domaine Google ; avec Google Tag Gateway, le site charge le tag depuis son propre domaine et certaines requêtes de mesure passent aussi par ce domaine first-party.
Google recommande même une architecture combinée Google Tag Gateway avec CDN + SGTM : le CDN sert les scripts Google depuis le domaine first-party, tandis que SGTM gère la collecte, l’enrichissement et le contrôle des données.
Donc non, ce nouveau champ n’arrive pas de nulle part.
Il colle parfaitement à la trajectoire actuelle :
| Évolution | Ce que ça permet | Ce que ça implique |
|---|---|---|
| SGTM | Collecter et transformer les données côté serveur | Plus de contrôle, plus de coût, plus de maintenance |
| Web Container Client | Servir GTM depuis un endpoint SGTM | Moins de dépendance visible à googletagmanager.com |
| Google Tag Gateway | Servir les tags Google depuis le domaine first-party | Setup plus simple, très orienté Google |
| Tag serving path | Personnaliser le chemin de chargement du tag | Moins de signatures évidentes dans l’URL |
C’est une évolution technique. Mais c’est aussi une évolution politique du tag management.
Est-ce une manière de contourner les ad blockers ?
Je vais être prudent, mais pas naïf.
Les bloqueurs de publicité et de tracking utilisent notamment des listes de filtres. Ces règles peuvent bloquer des requêtes réseau, se baser sur des URL, des patterns, des caractéristiques HTML, ou une combinaison de signaux. Brave explique par exemple que les filter lists peuvent identifier des contenus à bloquer selon l’URL de chargement ou selon des caractéristiques du HTML.
Chrome documente aussi que les extensions de filtrage peuvent bloquer, rediriger ou modifier des requêtes réseau via des règles déclaratives, et rappelle qu’EasyList représente environ 35 000 règles réseau.
Donc oui : retirer googletagmanager.com, gtm.js, ?id=GTM-XXXXXX ou un chemin trop explicite peut réduire l’efficacité de règles simples basées sur l’URL.
Mais non : ce n’est pas une garantie magique.
Un chemin personnalisé ne rend pas un tracking invisible. Les bloqueurs peuvent évoluer. Ils peuvent analyser d’autres signaux : comportement du script, requêtes suivantes, endpoints appelés, signatures JavaScript, cookies, payloads, patterns de collecte.
C’est exactement le point soulevé dans les échanges sous le post de Simo Ahava : un chemin seul ne suffit pas toujours. Si gtm.js, le préfixe GTM- ou d’autres marqueurs restent visibles, certains bloqueurs peuvent encore détecter le setup.
Le bon usage : robustesse technique, pas camouflage sale
Je n’ai aucun problème avec le first-party serving quand il sert à faire les choses proprement.
Il y a de vrais cas d’usage légitimes :
- mieux contrôler l’infrastructure de collecte ;
- réduire la dépendance directe aux domaines tiers ;
- maîtriser les en-têtes, le cache, les routes, les CSP ;
- fiabiliser la collecte après consentement ;
- documenter clairement les flux entre site, CDN, SGTM, GA4, Google Ads ;
- éviter de multiplier des scripts tiers non gouvernés dans le navigateur.
Là, SGTM garde tout son intérêt. On reprend la main sur le tracking. On peut filtrer, enrichir, router, journaliser, exclure, transformer. C’est du tag management sérieux.
Le problème commence quand le sujet devient : “comment faire passer le tracking même quand l’utilisateur ou son outil essaie de le bloquer ?”
Là, on ne parle plus de qualité de donnée. On parle de contournement.
Et ça, ce n’est pas une victoire.
Ce que ça ne change pas côté consentement
Un chemin first-party ne transforme pas un tag publicitaire en traceur nécessaire.
Un script chargé depuis example.com peut rester un traceur soumis au consentement. La CNIL rappelle que les traceurs de mesure d’audience ne sont exemptés de consentement que sous conditions strictes : mesure limitée au site, compte exclusif de l’éditeur, statistiques anonymes, absence de suivi global, absence de recoupement avec d’autres traitements ou transmission à des tiers.
Donc si vous utilisez SGTM, Google Tag Gateway ou un Tag serving path personnalisé pour GA4, Google Ads, remarketing, conversions publicitaires ou activation marketing, la question consentement reste entière.
Le domaine ne fait pas la finalité.
Et le chemin d’URL ne blanchit pas le traitement.
Faut-il l’activer ?
Ma réponse : pas automatiquement.
Je l’utiliserais dans trois cas.
D’abord, si l’architecture est déjà first-party, bien documentée, avec une vraie gouvernance tracking. Dans ce cas, un chemin propre peut simplifier le routage, la maintenance et l’alignement avec une architecture CDN + SGTM.
Ensuite, si le site doit éviter des conflits réels de chemins entre Google Tag Gateway, SGTM, CDN, reverse proxy et routes applicatives. C’est le cas officiel, et il tient debout.
Enfin, si l’objectif est de réduire les dépendances visibles à des domaines tiers dans une logique de performance, de contrôle et de stabilité.
En revanche, je ne l’activerais pas “juste pour passer sous les radars”.
C’est le genre de décision qui finit mal : documentation absente, CMP contournée, équipe juridique pas au courant, tracking impossible à auditer, dette technique planquée sous un nom de chemin absurde.
Checklist avant mise en production
Avant de toucher au setup, je regarderais au minimum ces points :
| Point à vérifier | Pourquoi |
|---|---|
| Mapping Tag ID → chemin | Pour éviter les chemins fantômes impossibles à maintenir |
| Conflit avec les routes existantes | Pour ne pas casser une vraie page ou une route applicative |
| Consent Mode / CMP | Pour vérifier que le comportement respecte bien les choix utilisateur |
| Preview SGTM et Tag Assistant | Pour valider que les requêtes sont bien revendiquées par le bon client |
| CSP | Pour éviter un blocage par la politique de sécurité du site |
| Cache CDN | Pour éviter de servir une version inattendue du tag |
| Logs serveur | Pour surveiller erreurs, volumes, latence et coûts |
| Documentation interne | Pour que le setup soit compréhensible dans six mois |
Le point le plus important : documenter le choix.
Un chemin du type /assets-core/a9x72 peut se défendre techniquement. Mais si personne ne sait à quoi il correspond, c’est une bombe à retardement.
Le vrai risque : perdre GTM comme tag manager universel
Ma crainte est ailleurs.
GTM a longtemps été perçu comme un tag management system généraliste : Google, Meta, LinkedIn, outils CRM, pixels divers, tags custom, scripts métier, consentement, dataLayer, événements.
Mais depuis plusieurs évolutions récentes, on sent une tension : Google Tag, Google Tag Gateway, destinations Google, settings centralisés, chargement first-party des tags Google…
Tout cela peut être utile. Mais tout cela recentre progressivement l’écosystème autour des besoins Google.
Et la question devient gênante : est-ce que GTM reste un vrai TMS universel, ou devient-il peu à peu une couche d’orchestration prioritairement pensée pour les tags Google ?
Je ne dis pas que la bascule est faite.
Je dis qu’il faut surveiller la direction.
Parce qu’un bon tag manager ne doit pas seulement mieux charger les tags Google. Il doit aider les équipes à gouverner l’ensemble de leur collecte : Analytics, Ads, CRM, consentement, server-side, datawarehouse, activation, qualité de données.
Si GTM devient surtout le bras armé du Google tag, il perd une partie de sa valeur historique.
Ce que je retiens
Le Tag serving path dans le Web Container Client de SGTM est une vraie nouveauté technique.
Elle peut améliorer des architectures first-party propres. Elle peut aussi faciliter des setups plus opaques. Les deux sont vrais.
Je ne la présenterais donc pas comme une “bonne nouvelle” sans nuance.
C’est un outil de plus.
Utile dans une architecture maîtrisée.
Discutable s’il sert à rendre le tracking moins lisible.
Et révélateur d’un mouvement plus large : Google pousse fort vers un tagging first-party, plus robuste, mais aussi plus centré sur son propre écosystème.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.