Mise à jour Google Tag Manager 2026 : GTM devient un Google Tag, et ce n’est pas un détail

Google prépare une mise à jour majeure de Google Tag Manager et du Google tag.

Pas une petite retouche d’interface. Pas un simple renommage marketing. Un vrai changement d’architecture. Je pense que je vais passer mes vacances à mettre à jour mes programmes de formation GTM !

Le principe est simple : les Google tags et les conteneurs Google Tag Manager vont être unifiés. Concrètement, un conteneur GTM pourra fonctionner comme un Google tag pleinement opérationnel. Et les sites qui utilisent uniquement le Google tag pourront accéder à des fonctionnalités de Google Tag Manager : interface de configuration, debug, versioning, gestion par conteneur.

Sur le papier, c’est une bonne nouvelle.

Dans la vraie vie, ça mérite quand même un peu de lecture froide. Parce que dès qu’un outil de tag management devient plus étroitement intégré aux produits Google, il faut regarder deux choses : ce que ça améliore, et ce que ça déplace comme pouvoir de configuration.

Ce que Google annonce

Google a publié une page d’aide datée du 20 mai 2026 pour détailler les prochaines évolutions de Google tag et Google Tag Manager. La page ne donne pas de date ferme de déploiement. Elle indique seulement que ces mises à jour arriveront prochainement.

Trois changements sont annoncés :

Évolution	Ce que Google change	Impact concret
Interface GTM simplifiée	Nouvelle page Overview, onglet Settings, onglet Advanced	Interface plus lisible, sans suppression annoncée des fonctions existantes
Unification Google tag / GTM	Les Google tags pourront devenir des conteneurs GTM complets	Les utilisateurs Google tag accèdent à des fonctions GTM
Optimisation des conteneurs GTM	GTM pourra envoyer directement aux destinations Google	Moins de chargements JavaScript intermédiaires, donc meilleure performance potentielle
Visual tagging	Création d’événements par sélection visuelle sur le site	Plus simple pour les équipes marketing, mais à surveiller côté fiabilité

Le message de Google est clair : simplifier le tagging, améliorer la performance, centraliser la gestion des paramètres et rendre l’écosystème Google plus cohérent.

Dit comme ça, personne ne va protester.

Mais comme toujours avec le tracking, le diable n’est pas dans l’annonce. Il est dans les détails d’implémentation.

GTM ne disparaît pas

Première clarification importante : Google Tag Manager ne disparaît pas.

Un conteneur GTM reste un conteneur GTM. Les déclencheurs, variables, templates et folders ne sont pas supprimés. Google indique simplement qu’ils seront regroupés dans une section Advanced de l’interface.

C’est un choix d’interface. Pas une disparition fonctionnelle.

En revanche, ce changement raconte quelque chose : Google veut rendre GTM moins intimidant pour les annonceurs qui utilisent surtout GA4, Google Ads ou Floodlight. Les éléments techniques restent disponibles, mais ils sont moins visibles dans l’interface principale.

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.

Pour un expert tracking, ce n’est pas neutre.

Parce que ce qui est moins visible devient moins utilisé. Et ce qui est moins utilisé finit souvent par être moins bien compris par les équipes.

Le vrai changement : le conteneur GTM devient aussi un Google tag

C’est le point central.

Jusqu’ici, on pouvait voir GTM comme une couche d’orchestration : un conteneur charge des tags, déclenche des événements, applique des règles, exécute du JavaScript, envoie des données vers GA4, Google Ads, Meta, LinkedIn, Matomo, Piwik PRO, ou n’importe quelle autre plateforme.

Avec cette mise à jour, Google rapproche fortement GTM du Google tag.

L’idée : un conteneur GTM pourra jouer le rôle de Google tag, et les destinations Google pourront être rattachées plus proprement au conteneur.

Exemple simple.

Aujourd’hui, un site peut avoir :

un conteneur GTM ;
un tag GA4 ;
un tag Google Ads ;
parfois plusieurs configurations Google tag ;
des paramètres dispersés entre GA4, Ads, Floodlight et GTM ;
des scripts gtag.js chargés en complément selon les cas.

Avec l’optimisation annoncée, Google veut centraliser cette logique. Le conteneur devient le point de pilotage principal pour les destinations Google.

Sur le fond, c’est cohérent.

Sur la gouvernance, ça demande du contrôle.

Pourquoi Google parle de meilleure performance

Google explique que les conteneurs GTM optimisés pourront envoyer les données directement vers les destinations Google. Avant, GTM pouvait charger du JavaScript supplémentaire, notamment gtag.js, pour envoyer les données vers une destination Google.

Ce chargement additionnel pouvait ajouter de la latence.

La promesse est donc simple : moins de JavaScript intermédiaire, moins de chargements inutiles, une transmission plus directe.

C’est crédible.

Sur un site qui charge plusieurs destinations Google — GA4, Google Ads, Floodlight — l’optimisation peut réduire la complexité du chargement. Ce n’est pas forcément spectaculaire sur tous les sites, mais techniquement, c’est logique.

La performance web ne se joue pas uniquement sur les gros scripts visibles. Elle se joue aussi dans l’accumulation de petits appels, de dépendances, de chargements asynchrones et de règles déclenchées dans le navigateur.

Un conteneur GTM propre, avec moins de bibliothèques inutiles, c’est toujours mieux qu’un empilement historique que personne n’ose nettoyer.

Ce qui ne change pas automatiquement

C’est probablement le point le plus important pour éviter les mauvaises interprétations.

Google indique que l’optimisation du conteneur GTM est recommandée, mais qu’aucun changement ne sera appliqué automatiquement. Les utilisateurs disposant des droits suffisants pourront lancer un flux d’optimisation depuis une bannière, prévisualiser les changements, puis publier ou non. Si vous avez besoin d’aide, notre agence Google Tag Manager peut vous aider.

Donc non, à ce stade, Google ne dit pas :

que votre conteneur va être modifié sans action ;
que vos tags tiers vont disparaître ;
que vos événements vont être réécrits ;
que vos configurations de consentement vont être contournées ;
que GTM va commencer à envoyer automatiquement toutes vos données vers GA4 ou Google Ads.

Il faut être précis.

Le sujet n’est pas “Google va tout casser”. Le sujet est : Google introduit une nouvelle architecture optionnelle qu’il faudra auditer avant publication.

Ce n’est pas la même chose.

La nouvelle interface GTM : plus simple, mais plus orientée Google

Google annonce une page Overview plus simple, avec deux zones importantes :

Nouvelle zone	Rôle
Settings	Centraliser les paramètres du conteneur et les réglages Google tag
Advanced	Regrouper les fonctions techniques : triggers, variables, templates, folders

L’onglet Settings devient central. C’est là que les paramètres du conteneur et les destinations Google seront visibles.

C’est utile, parce que beaucoup de configurations Google sont aujourd’hui dispersées. Sur certains comptes, il faut naviguer entre GA4, Google Ads, GTM, les paramètres Google tag, les conversions améliorées, le consentement et les destinations. Ce n’est pas exactement un modèle de clarté.

Mais cette simplification a un prix : elle pousse naturellement l’utilisateur vers une lecture “Google products first”.

Et c’est là que je reste vigilant.

GTM a toujours eu une valeur forte : être un outil de tag management généraliste. On peut y piloter GA4, Meta Ads, LinkedIn Ads, Matomo, Piwik PRO, Brevo, HubSpot, ActiveCampaign, des pixels personnalisés, des webhooks, des tags HTML, des appels API via templates, etc.

Si l’interface met davantage en avant les destinations Google, il faudra continuer à défendre une approche propre : un plan de taggage global, pas une configuration pensée uniquement pour Google Ads.

Les nouveaux snippets ne contiendront plus `gtag config`

Autre changement important : Google indique que les nouveaux snippets de déploiement seront uniformisés et ne contiendront plus la commande gtag config.

À la place, Google recommande de gérer le comportement d’initialisation avec le trigger gtm init.

Pourquoi c’est important ?

Parce que la commande gtag config était souvent placée directement dans le code de la page. Elle servait à initialiser une destination, par exemple une propriété GA4 ou un ID Google Ads.

Avec cette évolution, la logique d’initialisation bascule davantage dans GTM.

C’est plutôt sain si le conteneur est bien géré.

Mais ça veut aussi dire qu’il faudra être rigoureux sur :

l’ordre de déclenchement ;
les tags d’initialisation ;
le consentement par défaut ;
les paramètres partagés ;
les événements envoyés avant ou après consentement ;
la compatibilité avec les configurations existantes.

Un mauvais ordre d’exécution dans GTM, et vous pouvez vite créer des écarts de mesure.

Visual tagging : séduisant, mais pas magique

Google annonce aussi une fonction de visual tagging.

Le principe : sélectionner un élément directement sur le site pour créer un événement ou une conversion, sans coder manuellement les sélecteurs, les déclencheurs ou les paramètres techniques.

Pour une équipe marketing, c’est évidemment séduisant.

Vous cliquez sur un bouton, vous dites “ce clic est une conversion”, et l’outil s’occupe du reste.

Mais il faut garder les pieds sur terre.

Le visual tagging peut être utile pour des cas simples, mais il peut aussi créer du tracking fragile si le site repose sur :

des composants JavaScript dynamiques ;
des classes CSS générées automatiquement ;
un thème WordPress qui change ses sélecteurs ;
des boutons identiques sur plusieurs zones ;
des formulaires injectés par un outil tiers ;
une refonte partielle ;
un site e-commerce avec variantes, pop-ins ou composants front complexes.

Un sélecteur CSS fragile peut fonctionner aujourd’hui et casser demain.

Pour un tracking robuste, je préfère toujours un dataLayer propre.

Un dataLayer, c’est une couche de données exposée par le site pour GTM. Au lieu de “deviner” qu’un clic sur tel bouton correspond à une demande de devis, le site pousse explicitement un événement :

<script>
window.dataLayer = window.dataLayer || [];

window.dataLayer.push({
  event: 'lead_form_submit',
  form_type: 'contact',
  page_type: 'service',
  lead_category: 'audit_tracking'
});
</script>

C’est moins sexy qu’un outil visuel. Mais c’est plus fiable.

Et dans le tracking, je préfère fiable à sexy.

La question du consentement

Google ne dit pas que cette mise à jour contourne le consentement.

C’est important.

La page officielle parle d’unification, de performance, de centralisation et de visual tagging. Elle ne dit pas que les règles de consentement seront ignorées.

Simo Ahava avait déjà clarifié un point voisin sur l’évolution d’avril 2025 : quand GTM charge automatiquement un Google tag pour certains événements Ads ou Floodlight, cela ne change pas le fonctionnement du consentement dans GTM. Si les tags Ads ou Floodlight respectent le consentement, le Google tag chargé le respecte aussi.

Très bien.

Mais en entreprise, je ne me contente jamais d’une promesse générale.

Dès qu’une optimisation modifie la façon dont les tags Google sont chargés, reliés ou centralisés, je vérifie.

Concrètement, je contrôle :

les Consent Settings dans GTM ;
les Consent Checks des tags concernés ;
le comportement avant acceptation ;
le comportement après refus ;
le comportement après acceptation ;
les requêtes réseau envoyées ;
les cookies déposés ;
les paramètres gcs et gcd liés au Consent Mode ;
les destinations réellement appelées.

Le consentement ne se valide pas dans une slide. Il se valide dans le navigateur.

Le sujet discret : les accès entre GTM et les produits Google

Google indique que l’optimisation pourra lier le conteneur aux comptes de destination Google. Ces liens rendent le conteneur visible et gérable dans d’autres interfaces Google. Les accès sont établis automatiquement pendant l’optimisation, avec un accès Read par défaut, ajustable dans la gestion des utilisateurs GTM.

Ce point mérite beaucoup plus d’attention qu’il n’en recevra.

Pourquoi ?

Parce que les droits sont souvent le parent pauvre des projets analytics.

On trouve régulièrement :

des anciens prestataires encore présents ;
des comptes Gmail personnels ;
des droits Admin donnés trop vite ;
des utilisateurs Ads qui ne devraient pas toucher au tracking ;
des accès GA4 hérités ;
des comptes Floodlight mal documentés ;
des droits GTM jamais revus.

Si l’optimisation crée ou expose de nouveaux liens de gestion, il faut les documenter.

Pas dans six mois. Le jour de l’activation.

Est-ce que GTM devient un outil Google Ads ?

Non. Pas officiellement.

Mais la direction est claire : Google veut que ses tags soient plus faciles à configurer, plus rapides à charger, plus visibles dans ses produits, et plus simples à gérer par les équipes marketing.

C’est logique commercialement.

Google Ads, GA4 et Floodlight sont au centre de l’écosystème publicitaire Google. Plus le tagging est simple, plus l’adoption est forte, plus la mesure est complète.

Mais un bon consultant tracking ne doit pas confondre simplicité et gouvernance.

Un conteneur GTM ne doit pas devenir une poubelle de pixels Google optimisés.

Il doit rester un système de mesure structuré :

des événements nommés correctement ;
des variables propres ;
un plan de marquage documenté ;
des règles de consentement vérifiées ;
des tags tiers maîtrisés ;
un versioning clair ;
une logique compatible avec GA4, Ads, CRM, server-side tracking, datawarehouse et reporting.

GTM peut devenir plus intégré à Google sans perdre sa valeur.

Mais seulement si on garde la main.

Ce que je crains vraiment

Ma crainte n’est pas que Google supprime GTM.

Ma crainte est plus subtile : que GTM devienne progressivement, dans l’usage courant, un outil de configuration Google plutôt qu’un vrai outil de gouvernance du tracking.

Ce n’est pas une question technique. C’est une question de pratique.

Si les équipes utilisent GTM uniquement pour créer des conversions Google Ads via visual tagging, sans plan de mesure, sans dataLayer, sans documentation, sans validation du consentement, on va fabriquer du tracking rapide, mais fragile.

Et dans six mois, quand les chiffres ne colleront pas entre GA4, Google Ads, le CRM HubSpot ou Salesforce, BigQuery et Looker Studio, tout le monde dira : “GTM ne marche pas.”

Non.

Ce ne sera pas GTM le problème. Ce sera la méthode.

Ce que je recommande avant d’activer l’optimisation

Je ne refuserais pas cette mise à jour par principe. Elle peut apporter de vrais bénéfices.

Mais je ne l’activerais jamais à l’aveugle.

Voici la checklist minimale que j’appliquerais sur un conteneur client.

Contrôle	Pourquoi c’est indispensable
Exporter le conteneur GTM actuel	Pouvoir revenir en arrière proprement
Lire les changements proposés dans le workflow	Ne pas publier une optimisation comprise à moitié
Auditer les tags Google existants	Identifier GA4, Ads, Floodlight, doublons, tags obsolètes
Vérifier les paramètres Google tag	Cross-domain, user-provided data, enhanced conversions, auto-events
Contrôler le Consent Mode	S’assurer que les signaux respectent bien le choix utilisateur
Tester en Preview GTM	Observer l’ordre réel de déclenchement
Comparer les requêtes réseau	Vérifier ce qui part avant/après optimisation
Vérifier les cookies	Contrôler les dépôts avant et après consentement
Auditer les droits utilisateurs	Supprimer les accès inutiles, documenter les nouveaux liens
Publier une version nommée clairement	Garder une trace exploitable dans GTM

Je rajouterais un test simple dans le navigateur.

Dans Chrome DevTools, onglet Network, filtrez sur :

collect
gtag
gtm
googleads
doubleclick

Puis testez trois scénarios :

première visite sans consentement ;
refus du consentement ;
acceptation du consentement.

Ce test permet de voir rapidement si des requêtes partent trop tôt, si des destinations sont appelées sans raison, ou si le comportement change après optimisation.

Server-side GTM : attention à ne pas tout mélanger

Cette mise à jour concerne d’abord le tagging côté navigateur et l’unification Google tag / GTM.

Elle ne remplace pas une architecture server-side GTM.

Le server-side GTM répond à d’autres enjeux :

proxyfication des hits ;
meilleure maîtrise des données envoyées aux vendors ;
enrichissement serveur ;
filtrage ;
réduction de l’exposition navigateur ;
stratégie first-party ;
routage vers plusieurs destinations ;
intégration avec BigQuery, CRM ou APIs métier selon les architectures.

Donc non, cette mise à jour ne rend pas le server-side GTM inutile.

Elle peut améliorer la gestion des tags Google côté web. Mais elle ne remplace pas une vraie architecture serveur quand le besoin est la maîtrise avancée des flux de données.

Ce que ça change pour les équipes marketing

Pour une équipe marketing, cette mise à jour peut simplifier plusieurs choses.

Moins de dispersion. Moins de dépendance au code. Plus de visibilité dans les produits Google. Une création d’événements plus accessible. Un debug plus simple pour les sites qui n’utilisaient que Google tag.

C’est positif.

Mais il faudra éviter le piège classique : croire qu’un outil plus simple rend la mesure plus juste.

La qualité de la donnée ne vient pas de l’interface. Elle vient du modèle de mesure.

Avant de créer un événement, il faut savoir pourquoi il existe.

Un clic sur un bouton n’est pas forcément une conversion. Une page vue n’est pas forcément une intention. Un formulaire soumis n’est pas forcément un lead qualifié. Une conversion Google Ads n’est pas forcément une vente réelle.

Le tracking n’est pas une collection de tags. C’est une traduction technique d’un modèle business.

Ce que ça change pour les profils analytics

Pour les profils analytics, cette évolution impose de revoir certains réflexes.

Il faudra surveiller :

les nouveaux modes d’initialisation ;
les paramètres centralisés ;
les destinations Google ;
les droits entre produits ;
les effets sur les requêtes réseau ;
les interactions avec le Consent Mode ;
la place du dataLayer face au visual tagging.

Le travail ne sera pas de cliquer sur “Optimize” puis de passer à autre chose.

Le travail sera de comprendre ce que l’optimisation modifie réellement dans le conteneur, et de valider que la donnée reste conforme, robuste et exploitable.

Mon avis

Cette mise à jour est importante.

Elle peut améliorer GTM. Elle peut réduire certains chargements inutiles. Elle peut rendre les configurations Google plus propres. Elle peut aider des annonceurs à sortir de configurations bricolées avec des Google tags dispersés partout.

Mais elle confirme aussi une tendance : Google veut rapprocher GTM de son propre écosystème publicitaire et analytics.

Ce n’est pas choquant. C’est même logique.

Mais ça oblige les experts tracking à rester fermes sur la méthode.

Un bon conteneur GTM ne doit pas être optimisé uniquement pour Google. Il doit être optimisé pour la qualité de mesure globale de l’entreprise.

Cela veut dire :

mesurer ce qui compte vraiment ;
respecter le consentement ;
documenter les événements ;
garder des noms propres ;
limiter les tags inutiles ;
contrôler les vendors ;
connecter proprement Analytics, Ads, CRM et reporting ;
éviter les automatismes opaques ;
tester avant de publier.

La mise à jour GTM 2026 n’est pas une catastrophe. Ce n’est pas non plus un détail.

C’est une étape de plus vers une plateforme Google tag unifiée.

À nous de l’utiliser proprement, sans abandonner la gouvernance.

Franck Scandolera

⭐ 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.