GTM devient Google Tag : ce qui change vraiment dans votre plan de taggage

Depuis l’annonce de Google le 20 mai 2026 à Google Marketing Live, GTM devient Google Tag : les containers GTM peuvent désormais se comporter comme un Google Tag à part entière, les anciens tags Google se transforment en « Destinations », et un nouveau Visual Event Builder permet de configurer certaines conversions sans toucher au code. C’est le changement d’architecture le plus structurant depuis le passage à GA4. Pas de panique — mais pas d’attentisme non plus.

Ce que « Destinations » change vraiment dans la plomberie

Si vous utilisez GTM, vous utilisiez en fait un manager pour injecter un autre manager (le Google Tag). Cette redondance était connue, tolérée, et franchement peu élégante. Aujourd’hui, un container avec GA4, Google Ads et Floodlight finit par charger des scripts séparés pour chaque produit.

Sous le nouveau modèle, un seul script de container gère l’ensemble, ce qui devrait se traduire par moins de scripts chargés sur le site et un gain de performance réel, modeste mais concret, pour quiconque fait tourner plusieurs produits Google via GTM.

Le gain technique le plus concret, dans l’analyse de Simo Ahava, concerne la suppression des chargements additionnels de gtag.js par destination. Une fois les Destinations ajoutées au container, tout passe par le JavaScript du container GTM.

L’autre bénéfice, moins spectaculaire mais tout aussi utile au quotidien : la centralisation des paramètres. Une fois vos tags en Destinations, des éléments comme la configuration du Consent Mode et le cross-domain measurement se définissent une seule fois au niveau du container, au lieu d’être répétés — et potentiellement désynchronisés — sur chaque tag individuel. Quiconque a hérité d’un container GTM avec cinq configurations de consentement légèrement différentes comprend pourquoi c’est important.

Le Visual Event Builder : utile, mais ne lui confiez pas vos revenus

Google intègre un visual event builder qui vous permet de parcourir un flux de conversion sur votre site réel. Une interface WYSIWYG s’ouvre sur votre site, vous cliquez sur des éléments (comme un transaction ID ou une valeur de conversion) et GTM génère automatiquement les tags et variables correspondants à partir des sélecteurs CSS.

C’est séduisant. Vous lancez le processus en cliquant sur le bouton « Start guided setup » dans la carte de bienvenue de l’Overview. Pour l’instant, cela ne fonctionne que pour les conversions d’achat Google Ads, mais on peut s’attendre à ce que ça s’étende à d’autres événements et destinations.

Sauf que, s’appuyer sur des sélecteurs CSS pour des conversions critiques en termes de revenus est risqué. Comme le notent Simo Ahava et Julius Fedorovicius, les pages de confirmation dynamiques et les layouts CSS qui changent vont inévitablement casser ces configurations. Pour des données critiques comme les achats, la recommandation reste de travailler avec les développeurs pour pousser les données dans le dataLayer plutôt que de scraper la page visuellement.

Ancienne école vs méthode actuelle :

Situation	Ancienne approche	Avec le nouveau GTM
Tracking d’achat	Tag GA4 + Tag Ads séparés, chacun avec son déclencheur	Une Destination GA4 + une Destination Ads dans un container unifié
Consent Mode	Paramètre répété sur chaque tag	Configuré une fois au niveau container
Debug	Preview Mode + Tag Assistant séparés	Vue unifiée, debug Consent Mode intégré
Nouveau tracking Ads	Création manuelle de tag/trigger/variable	Visual Event Builder (beta, achat Ads uniquement)

Migrer maintenant ou attendre : la vraie question

Les upgrades ne sont pas automatiques. Vous serez invité à upgrader chaque container et pourrez prévisualiser les changements, tester dans un workspace, et revenir en arrière si nécessaire. Ce processus s’applique également au nouveau modèle de « Settings » centralisé.

Trois précisions critiques : GTM ne commencera pas à collecter des données automatiquement. Upgrader votre container ne le fait pas envoyer des hits à GA4, Google Ads ou Floodlight sans votre configuration explicite.

La fenêtre actuelle est plutôt favorable à une migration tranquille : containers à faible enjeu d’abord, critiques ensuite une fois les patterns validés.

Le point que tout le monde esquive : le consent et le droit

Avant de cliquer sur « upgrade », un rappel qui brûle. Un arrêt du « Verwaltungsgericht Hannover » de mars 2025 a établi que Google Tag Manager ne peut pas s’activer avant qu’un consentement explicite ait été obtenu en droit allemand, le tribunal ayant constaté que GTM transmettait des données de l’appareil de l’utilisateur — y compris les adresses IP — vers des serveurs américains avant toute interaction de consentement. Cet arrêt conditionne la façon dont de nombreuses organisations européennes abordent tout changement de leur infrastructure de taggage.

En juillet 2025, Google a appliqué les exigences du Consent Mode V2 aux annonceurs au Royaume-Uni et dans l’EEE — et les comptes avec des bannières de consentement visibles mais non correctement câblées à la couche Google Tag ont commencé à perdre des données d’attribution définitivement. Un client a vu ses conversions Google Ads chuter de 90% du jour au lendemain sans aucun changement de campagne, de budget ou d’enchères. La cause racine : une bannière de consentement qui collectait les choix des utilisateurs sans transmettre les paramètres ad_user_data et ad_personalization.

La migration vers le container unifié ne règle rien de ce côté-là. Elle peut même amplifier l’exposition si vous centralisez un consent mal configuré.

Ce que je ferais dès maintenant

Voici un prompt à utiliser avec un LLM pour auditer rapidement votre container avant toute migration :

Tu es un expert GTM. Voici l'export JSON de mon container GTM [coller l'export].
Identifie :
1. Tous les tags Google (GA4, Ads, Floodlight) qui pourraient devenir des Destinations
2. Les tags qui ont des configurations de Consent Mode incohérentes entre eux
3. Les variables et déclencheurs qui dépendent de sélecteurs CSS fragiles
4. Les tags qui se déclenchent sur All Pages sans condition de consentement explicite
Produis un tableau de synthèse avec niveau de risque (critique / moyen / faible) 
et action recommandée pour chaque item.

Ça prend dix minutes. Ça vous évite de migrer un container qui a trois versions du Consent Mode qui coexistent sans que personne ne s’en soit rendu compte.

La vraie question, au fond, n’est pas « est-ce que j’upgrade mon container ? ». C’est : est-ce que je comprends exactement ce que mon container fait aujourd’hui avant de le transformer en quelque chose de plus puissant ?