Nouveau Google Tag Manager : ce qui change vraiment avec le Google tag
Google prépare une évolution importante de Google Tag Manager web. Le sujet mérite un article sérieux, parce qu’il touche à la base du tracking : le tag posé sur le site, les destinations Google, les paramètres de collecte, le consentement et la place de GTM comme vrai Tag Management System.
Je vais être clair : tout n’est pas encore documenté officiellement par Google dans le détail. Google a publié l’annonce principale. La communauté GTM, notamment Simo Ahava, a apporté des précisions techniques. Je m’appuie sur les sources disponibles, sans transformer les hypothèses en certitudes.
- Nouveau Google Tag Manager : ce qui change vraiment avec le Google tag
- Ce que Google a annoncé
- Ce que dit Simo Ahava
- Ce qu’est une Destination
- Ce que ça change dans GTM
- Le gain technique annoncé
- Ce que Google avait déjà commencé en 2025
- Ce que cette mise à jour ne veut pas dire
- La vraie question : GTM reste-t-il un Tag Manager généraliste ?
- Pourquoi cette crainte est légitime
- Le bon réflexe pour les équipes data et marketing
- Ce que je surveille après le 21 mai
- Mon analyse
- Conclusion
Ce que Google a annoncé
Google a publié une annonce le 5 mai 2026, en amont de Google Marketing Live 2026. Dans cette annonce, Google explique qu’il met à jour le Google tag avec un nouveau visual setup flow. L’objectif annoncé : permettre aux annonceurs qui ont déjà des tags déployés d’upgrader leurs tags existants en quelques clics, sans installer un nouveau tag et sans coder. Google ajoute que cette évolution centralise les paramètres et les accès utilisateurs, améliore la collecte des données et la performance globale du site.
Google Marketing Live EMEA 2026 a lieu le 21 mai 2026 à 11h BST. C’est dans ce contexte que cette évolution de GTM et du Google tag est discutée.
Voilà le socle factuel.
Google ne dit pas dans cette annonce que GTM devient exclusivement réservé à GA4 ou Google Ads. Google ne dit pas non plus que les sites doivent poser un nouveau snippet. Google parle d’un upgrade des tags existants, sans nouveau tag et sans code.
Ce que dit Simo Ahava
Simo Ahava a publié une analyse détaillée sur LinkedIn. Son point central : les containers Google Tag Manager web pourront devenir des Google Tags. Il précise que l’upgrade est optionnel, que GTM continue de fonctionner comme avant, et que cet upgrade ne signifie pas que GTM va collecter automatiquement des données vers GA4, Google Ads ou Floodlight.
Il indique aussi que les anciens Google Tags présents dans le container peuvent être transformés en Destinations du container GTM. Dans ce modèle, GTM n’a plus besoin de charger des fichiers gtag.js additionnels par destination : tout passe par le JavaScript du container.
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.
Ce point n’est pas encore détaillé dans une documentation Google complète dédiée à cette mise à jour. Je le traite donc comme une information experte, utile, mais distincte de l’annonce officielle Google.
Ce qu’est une Destination
Une Destination, dans la documentation Google, représente un produit Google connecté, comme Google Ads ou Google Analytics. Le Google tag utilise les IDs de destination pour charger les paramètres propres à chaque destination et router les événements.
Google donne deux exemples simples :
| Produit Google | Exemple d’ID de destination |
|---|---|
| Google Ads | AW-98765 |
| Google Analytics | G-12345 |
Ces formats existent toujours dans la documentation officielle. Donc non, tout ne devient pas uniquement GTM-. GTM- identifie un container Google Tag Manager. AW- et G- restent des IDs de destination documentés pour Google Ads et Google Analytics.
Je ne mets pas ce point au centre du sujet, mais il compte pour les audits. Quand une configuration évolue autour du Google tag et des Destinations, il faut savoir ce qui identifie le container, ce qui identifie le tag, et ce qui identifie la destination.
Ce que ça change dans GTM
Le changement important n’est pas “un nouvel ID”.
Le changement important est là :
GTM devient plus directement lié au Google tag.
Aujourd’hui, GTM sert déjà à déployer des tags Google et non-Google. Le Google tag, lui, sert à envoyer des données vers des destinations Google. Google rapproche ces deux logiques.
Côté Google, l’objectif est assumé : simplifier les connexions de données, centraliser les réglages, améliorer la collecte et réduire la friction de déploiement.
Côté GTM, d’après Simo Ahava, cela se traduit par un upgrade du container, la conversion possible des anciens Google Tags en Destinations, une page Overview revue, un menu simplifié avec certains éléments rangés dans une section “Advanced”, et un outil visuel de création d’événements.
Le mot important : upgrade.
Je ne parlerais pas de “migration” au sens lourd. Google parle d’upgrader les tags existants sans nouveau tag et sans code. Simo parle d’un upgrade optionnel du container. Les mots doivent rester propres.
Le gain technique annoncé
Le gain technique le plus concret, dans l’analyse de Simo Ahava, concerne la suppression de chargements additionnels de gtag.js par destination. Une fois les Destinations ajoutées au container, tout passe par le JavaScript du container GTM.
Google, de son côté, annonce une amélioration de la collecte et de la performance globale du site, sans détailler encore cette mécanique dans une documentation GTM complète.
Je retiens donc deux niveaux :
| Niveau | Ce qui est sourcé |
|---|---|
| upgrade no-code des tags existants, centralisation, amélioration de la collecte et de la performance | |
| Simo Ahava | Destinations dans GTM, moins de chargements gtag.js, upgrade optionnel, test et rollback |
C’est la bonne séparation.
Ce que Google avait déjà commencé en 2025
Cette évolution n’arrive pas dans le vide.
Depuis le 10 avril 2025, Google Tag Manager charge automatiquement un Google tag dans certains containers qui contiennent des tags Google Ads ou Floodlight, quand aucun Google tag correspondant n’est déjà chargé avant l’envoi des événements. Google présente ce changement comme une amélioration de la fiabilité du tracking Google Ads.
Simo Ahava avait publié une clarification sur ce changement. Il expliquait que GTM modifiait la façon dont il charge automatiquement gtag.js pour les événements Ads et Floodlight qui se déclenchent sans Google Tag correspondant chargé au préalable.
Donc la direction est claire : Google rapproche progressivement GTM et Google tag.
Ce que cette mise à jour ne veut pas dire
Cette évolution ne veut pas dire que GTM collecte automatiquement toutes vos données vers GA4, Google Ads ou Floodlight. Simo Ahava le dit explicitement dans son post.
Elle ne veut pas dire que vous devez utiliser les produits Google avec GTM. Il le précise aussi.
Elle ne veut pas dire que GTM cesse de fonctionner comme avant. L’upgrade est présenté comme optionnel.
Elle ne veut pas dire que les tags tiers disparaissent. Google documente toujours les custom tags, les templates tiers et la Community Template Gallery. GTM supporte plusieurs plateformes de tags, des templates tiers et des templates partagés par la communauté.
La vraie question : GTM reste-t-il un Tag Manager généraliste ?
C’est mon point de vigilance.
Google Tag Manager a toujours été intéressant parce qu’il n’était pas seulement un outil Google. C’était un Tag Management System généraliste. On pouvait y gérer GA4, Google Ads et Floodlight, mais aussi Meta, LinkedIn Ads, TikTok, Matomo, Piwik PRO, Piano, Hotjar, des tags CRM, des pixels métiers, des scripts maison et des templates communautaires.
Google documente encore cette ouverture. La Community Template Gallery permet aux utilisateurs GTM de découvrir et d’ajouter des templates de tags et variables créés par la communauté. Google précise aussi que ces templates sont fournis par des développeurs tiers, pas par Google.
Google indique également que la Community Template Gallery est une plateforme ouverte où des éditeurs tiers peuvent partager des templates qu’ils maintiennent eux-mêmes.
Donc les faits sont clairs : GTM reste aujourd’hui un outil ouvert aux tags tiers.
Ma crainte ne porte pas sur l’état actuel. Elle porte sur la direction produit.
La nouveauté annoncée par Google est centrée sur le Google tag, les destinations Google, les paramètres centralisés et l’amélioration de la collecte pour l’écosystème Google.
C’est logique pour Google. Mais pour un expert tracking, cela pose une vraie question : est-ce que GTM va continuer à progresser comme Tag Manager généraliste, ou concentrer ses nouveautés sur la stack Google ?
Je ne dis pas que GTM se ferme. Les sources ne le disent pas.
Je dis que la mise à jour renforce le poids du Google tag dans GTM. C’est factuel. Et c’est le point à surveiller.
Pourquoi cette crainte est légitime
Un Tag Manager généraliste doit permettre de gouverner tout le tracking, pas seulement les produits Google.
Dans un setup réel, GTM sert souvent à gérer :
| Famille de tags | Exemples |
|---|---|
| Analytics | GA4, Matomo, Piwik PRO, Piano |
| Ads | Google Ads, Meta Ads, LinkedIn Ads, TikTok Ads |
| UX / CRO | Hotjar, Clarity, AB Tasty, Kameleoon |
| Consentement | CMP, Consent Mode, règles par finalité |
| CRM / Marketing automation | HubSpot, Salesforce, Brevo, Marketo |
| Scripts métiers | tracking interne, pixels partenaires, webhooks |
Si les nouvelles fonctions GTM servent surtout à mieux piloter Google tag, Google Ads, GA4 et Floodlight, l’outil gagne en efficacité pour Google. Mais il devient moins neutre dans sa dynamique produit.
Ce n’est pas un procès d’intention. C’est une lecture du mouvement annoncé.
Google parle de centraliser les paramètres et les accès autour du Google tag. Simo parle de containers GTM qui deviennent des Google Tags et d’anciens Google Tags qui deviennent des Destinations.
La direction technique est bien centrée sur Google tag.
Le bon réflexe pour les équipes data et marketing
Je ne conseille pas de refuser l’upgrade par principe.
Je conseille de l’aborder comme un changement d’architecture.
Avant d’activer l’upgrade, je vérifierais :
| Point à vérifier | Objectif |
|---|---|
| Tags Google existants | Comprendre ce qui va être centralisé |
| Destinations Google | Identifier où les données partent |
| Consentement | Tester les états acceptés / refusés |
| Tags non-Google | Vérifier qu’ils restent bien gouvernés |
| Templates communautaires | Identifier les dépendances tierces |
| Performance réseau | Comparer les chargements avant / après |
| Versions GTM | Garder une capacité de retour arrière |
Simo indique que l’upgrade peut être prévisualisé, testé dans un workspace et rollbacké si besoin.
C’est une bonne nouvelle. Mais ça ne remplace pas un audit.
Ce que je surveille après le 21 mai
Je surveille trois choses.
La première : la documentation officielle Google. Il faut une page claire sur l’upgrade GTM, les Destinations, les paramètres centralisés, le comportement du container et les limites.
La deuxième : la place des tags tiers dans l’interface. Si GTM continue d’améliorer les custom templates, la Community Template Gallery et les workflows non-Google, le Tag Manager reste généraliste.
La troisième : le consentement multi-éditeurs. Un vrai Tag Manager doit gérer plusieurs logiques de consentement, pas seulement les besoins Google Ads / GA4.
Mon analyse
Cette mise à jour est utile.
Elle simplifie le Google tag. Elle rapproche GTM d’une architecture plus cohérente. Elle réduit une partie de la friction historique entre GTM, gtag.js, Google Ads, GA4 et les Destinations.
Mais elle renforce aussi le centre de gravité Google dans GTM.
C’est le vrai sujet.
Je ne vois pas une fermeture de GTM aux autres éditeurs dans les sources disponibles. Google documente toujours les tags tiers, les custom tags et la Community Template Gallery.
Je vois en revanche une évolution forte : les nouveautés les plus visibles concernent le Google tag, les destinations Google et la centralisation des paramètres Google.
Pour moi, la question à suivre n’est donc pas :
“Est-ce que GTM va disparaître ?”
La vraie question est :
“Est-ce que GTM va continuer à évoluer comme Tag Management System généraliste, ou devenir surtout l’interface avancée du Google tag ?”
Aujourd’hui, la réponse n’est pas tranchée.
Mais le signal est suffisamment fort pour être pris au sérieux.
Conclusion
Le nouveau Google Tag Manager annoncé autour de Google Marketing Live 2026 n’est pas une migration lourde. Google parle d’un upgrade des tags existants, sans nouveau tag et sans code.
D’après les informations partagées par Simo Ahava, l’upgrade est optionnel, GTM continue de fonctionner comme avant, les containers peuvent devenir des Google Tags, et les anciens Google Tags peuvent être rattachés comme Destinations.
Le changement est important parce qu’il rapproche GTM du Google tag. Il améliore la logique Google. Il rend les setups Google plus cohérents.
Mais il impose une vigilance : GTM doit rester un vrai Tag Manager, pas seulement un gestionnaire avancé de la stack Google.
Pour les équipes sérieuses, le bon réflexe est simple : ne pas paniquer, ne pas cliquer trop vite, auditer le container, tester l’upgrade, vérifier les destinations, contrôler le consentement et surveiller la place des tags non-Google.
GTM devient plus central dans l’écosystème Google.
À nous de vérifier qu’il reste aussi central dans l’écosystème marketing au sens large.
⭐ 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.