Brouillon auto

Visual Tagging : La mise à jour Google Tag Manager

Par / / Google Tag Manager

Google Tag Manager change de moteur : ce que l’unification avec Google tag va vraiment changer

Le 20 août 2026, Google a accéléré une transformation de Google Tag Manager engagée depuis plusieurs mois. Nouvelle interface, rapprochement avec Google tag, conteneurs optimisés, Visual Tagging capable de construire une conversion en cliquant directement dans une page…

Google tag et Google Tag Manager convergent vers une infrastructure commune, GTM peut envoyer directement des données aux destinations Google sans charger gtag.js comme intermédiaire, les nouveaux snippets abandonnent le traditionnel gtag('config'), et la configuration se déplace progressivement du tag individuel vers le conteneur.

Ça change beaucoup plus de choses qu’un nouveau menu.

Visual Tagging va supprimer une bonne partie du travail mécanique

Je commence par la nouveauté qui sera probablement la plus commentée : Visual Tagging.

Le principe est assez simple.

Découvrez égalementComment splitter GA4 avec server_container_url dans SGTM ?

Pour une conversion Purchase Google Ads, je peux maintenant lancer une procédure guidée depuis Google Ads et Tag Assistant, effectuer une vraie commande test puis sélectionner directement les éléments de la page de confirmation contenant les données nécessaires.

Google prévoit actuellement :

  • Transaction ID ;
  • Order subtotal ;
  • Currency ;
  • Customer name ;
  • Customer email ;
  • Customer phone.

Une fois ces données associées aux éléments de la page, GTM peut créer automatiquement les tags, triggers et variables nécessaires.

C’est important : Google ne génère pas simplement une variable. Il automatise une chaîne de configuration GTM.

Le fonctionnement ressemble à ça :

Commande test
     ↓
Page de confirmation
     ↓
Tag Assistant analyse la page
     ↓
Je sélectionne :
transaction_id
value
currency
email...
     ↓
GTM génère
variables + triggers + tags
     ↓
Publication
Découvrez égalementMon expertise GTM vaut-elle encore quelque chose face à l’IA ?

C’est exactement le genre de travail manuel dont je me passe volontiers.

Créer encore à la main une variable, recopier une valeur, configurer un trigger et reconstruire une balise Google Ads pour la cinquantième fois n’a jamais été la partie la plus intéressante du tracking.

Google automatise cette plomberie. Très bien.

La nouveauté reste toutefois beaucoup plus cadrée que le raccourci « GTM devient point-and-click ».

En août 2026, la fonctionnalité est encore en beta pour les conversions Purchase Google Ads. Google prévoit d’élargir progressivement les cas d’usage.

Découvrez égalementGoogle Tag Manager vs Google Analytics lequel choisir ?

Il faut également déjà disposer d’une action de conversion, d’une Google tag installée sur le site, d’une page de confirmation de commande et d’un accès en modification au conteneur. Google recommande même de pouvoir effectuer une vraie commande test.

On est donc devant un constructeur assisté de tracking, pas devant une intelligence capable d’auditer spontanément tout un plan de mesure.

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.

Visual Tagging : La mise à jour Google Tag Manager

La partie la plus importante est l’unification entre Google tag et GTM

Google formule le changement très clairement : les Google tags vont être upgraded to fully capable Google Tag Manager containers.

C’est beaucoup plus structurant.

Un site qui utilisait seulement Google tag pourra bénéficier de fonctions jusqu’ici associées à GTM :

  • interface de configuration ;
  • debugging ;
  • contrôle des versions ;
  • fonctionnalités de gestion du conteneur.

Google précise que cette migration ne doit pas modifier le comportement actuel de la Google tag dans la page. L’objectif est de donner accès aux fonctions du conteneur, pas de changer silencieusement la mesure existante.

Je ne raisonnerais donc plus vraiment en opposant :

gtag.js
versus
Google Tag Manager

La logique devient plutôt :

                 Google Tag Platform
                         │
                  même infrastructure
                         │
             ┌───────────┴───────────┐
             │                       │
         G- / AW-                  GTM-
             │                       │
    capacités limitées      conteneur complet
             │                       │
       Google only          Google + tiers

Et c’est là qu’un détail technique devient important.

Un conteneur GTM- et un conteneur G- ne donnent pas les mêmes capacités

L’unification ne signifie pas que tous les conteneurs vont pouvoir exécuter n’importe quoi.

Google utilise le préfixe de l’identifiant comme une frontière fonctionnelle.

Avec un identifiant :

GTM-XXXXXXX

je conserve les capacités complètes de Tag Manager : tags Google, templates, scripts tiers, Custom HTML et autres fonctions avancées.

Avec :

G-XXXXXXXX

ou :

AW-XXXXXXXX

Google restreint le conteneur aux capacités compatibles avec les destinations Google.

C’est une différence fondamentale.

On peut donc partager une même infrastructure technologique sans partager les mêmes droits d’exécution.

J’y vois clairement un mécanisme de gouvernance.

Un simple conteneur Google tag n’a aucune raison d’obtenir par défaut le droit d’injecter du JavaScript arbitraire dans une page. Un vrai conteneur GTM-, lui, conserve cette capacité.

La release note de Google publiée en 2026 précise d’ailleurs que les restrictions sont déterminées par l’ID utilisé, et non simplement par le chemin JavaScript qui a servi à charger le conteneur.

C’est loin d’être un détail d’interface.

La nouvelle interface GTM rend cette architecture visible

Google a aussi complètement revu la page Overview du conteneur.

Les composants classiques n’ont pas disparu, mais leur place change.

Un nouvel espace Settings regroupe les paramètres applicables au conteneur. Les éléments historiques de GTM passent dans un menu Advanced :

  • Triggers ;
  • Variables ;
  • Templates ;
  • Folders.

Google confirme que cette organisation ne supprime aucune fonctionnalité existante.

Ce déplacement me paraît révélateur.

L’ancien GTM mettait naturellement ses objets techniques au premier plan :

Tags
Triggers
Variables
Folders
Templates

Le nouveau GTM commence davantage à se lire comme une infrastructure :

Container
│
├── Settings
│   ├── configuration
│   ├── destinations
│   └── data flow
│
└── Advanced
    ├── triggers
    ├── variables
    ├── templates
    └── folders

Google présente également directement les destinations reliées au conteneur.

Autrement dit, la question n’est plus seulement :

Quelle balise ai-je créée ?

Elle devient davantage :

Quelle configuration alimente quelles destinations ?

Pour quelqu’un qui travaille sur des environnements multi-destinations, c’est une manière beaucoup plus logique de penser le tagging.

La documentation Google du nouvel environnement montre désormais explicitement les comptes, les Google tags, les containers, les versions et l’accès aux composants du workspace dans cette logique.

L’optimisation change réellement le chemin d’exécution

La migration proposée aux conteneurs GTM existants n’est pas qu’une réorganisation de menus.

Google annonce un mécanisme d’optimisation permettant au conteneur d’envoyer directement les données vers les destinations Google.

Historiquement, certaines configurations suivent ce chemin :

Page
  ↓
GTM container
  ↓
gtag.js
  ↓
Google destination

Après optimisation :

Page
  ↓
GTM container
  ↓
Google destination

Google dit explicitement que gtag.js n’a plus besoin d’être chargé comme étape intermédiaire dans cette configuration optimisée.

Techniquement, c’est beaucoup plus intéressant qu’un changement de navigation.

On retire :

  • une ressource JavaScript intermédiaire ;
  • une étape de chargement ;
  • une partie de la latence potentielle avant l’envoi de la mesure.

Je ne transformerais toutefois pas ça en promesse SEO ou Core Web Vitals.

Google ne publie pas de benchmark permettant de dire qu’un conteneur gagnera 50, 100 ou 200 millisecondes. L’amélioration architecturale est réelle ; son impact réel dépend du conteneur et du site.

Et surtout, le gtag('config') disparaît des nouveaux snippets

C’est probablement la ligne la plus technique de toute l’annonce, et l’une des plus intéressantes.

Google indique que les nouveaux snippets de déploiement vont devenir identiques et ne contiendront plus de commande gtag config.

On connaît tous cette logique :

window.dataLayer = window.dataLayer || [];

function gtag() {
  dataLayer.push(arguments);
}

gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');

Le config initialise la destination Google.

Google recommande désormais de déplacer ce comportement vers le trigger :

gtm init

et prévoit la possibilité de demander à ce trigger d’attendre une commande config pour conserver un comportement legacy.

La logique évolue donc vers :

Page
  ↓
snippet commun
  ↓
container runtime
  ↓
gtm init
  ↓
configuration / destination

C’est un déplacement de responsabilité.

L’initialisation n’est plus nécessairement décrite explicitement dans le code de la page. Elle peut être pilotée depuis le conteneur.

Pour une installation basique, ce sera transparent.

Pour une implémentation avec séquencement précis, Consent Mode, code historique, configurations multiples ou dépendances autour du config, je regarderais cette migration beaucoup plus attentivement.

Le Data Layer n’a jamais été aussi important

C’est ici que je suis nettement plus réservé face au côté spectaculaire du Visual Tagging.

Pouvoir cliquer sur :

<span class="order-total">
  129,00 €
</span>

pour transformer cette valeur en montant de conversion est pratique.

Mais la vraie question reste :

est-ce que ce <span> est réellement la bonne source de vérité ?

Une valeur présente dans le DOM appartient d’abord à la couche de présentation.

Elle peut changer parce que :

  • le thème change ;
  • un composant React est réécrit ;
  • le checkout change ;
  • la classe CSS change ;
  • la valeur devient asynchrone ;
  • la structure HTML est modifiée ;
  • un A/B test produit une variante différente.

Pour une donnée métier importante, je préfère largement que l’application exprime elle-même l’événement :

dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'A1458',
    value: 129.00,
    tax: 21.50,
    shipping: 8.00,
    currency: 'EUR',
    items: [
      {
        item_id: 'SKU-1842',
        item_name: 'Produit A',
        price: 121.00,
        quantity: 1
      }
    ]
  }
});

Là, je ne demande plus au tracking de deviner ce que représente l’interface.

L’application me dit :

une transaction A1458 vient d’être validée, voici ses données.

C’est beaucoup plus robuste.

Google lui-même continue d’ailleurs de recommander le Data Layer pour récupérer notamment l’identifiant de transaction utilisé dans les conversions Google Ads et éviter les doublons.

La différence architecturale est nette :

DOM

interface HTML
    ↓
sélecteur
    ↓
variable GTM
    ↓
Google Ads

contre :

Application / backend
        ↓
 événement métier
        ↓
    Data Layer
        ↓
       GTM
        ↓
 ┌──────┼──────┬──────┐
 GA4   Ads    Meta    autre

Le premier système décrit ce que l’utilisateur voit.

Le second décrit ce qui s’est réellement passé dans l’application.

Pour une conversion critique, ce n’est pas la même chose.

Visual Tagging peut même augmenter le risque de doublons

Il y a une petite ironie dans la documentation Google.

Visual Tagging vérifie si une conversion Purchase existe déjà dans le conteneur.

Si c’est le cas, Google affiche explicitement un avertissement indiquant que continuer peut provoquer un double comptage.

Ce n’est pas surprenant.

Une entreprise peut déjà avoir :

purchase
   │
   ├── GA4 → import Google Ads
   │
   ├── Google Ads Conversion tag
   │
   ├── plugin e-commerce
   │
   ├── pixel custom
   │
   └── server-side

Si quelqu’un arrive ensuite dans Google Ads, voit un assistant « Fix conversions » et génère une nouvelle implémentation sans auditer l’existant, on vient de rendre le doublon plus facile à produire.

Faciliter la création ne réduit pas automatiquement la complexité du système.

Parfois, c’est même l’inverse.

Le consentement montre immédiatement la limite du point-and-click

Prenons Consent Mode.

Une balise Google peut dépendre de plusieurs signaux :

ad_storage
analytics_storage
ad_user_data
ad_personalization

Ces états ne décrivent pas le bouton sur lequel quelqu’un vient de cliquer.

Ils décrivent ce que le système a le droit de faire avec la donnée.

Dans GTM, ces contrôles font partie du comportement d’exécution des tags.

Une configuration réelle peut donc devoir répondre à des questions comme :

Consentement disponible ?
        │
       non
        ↓
Dois-je bloquer le tag ?
Envoyer un cookieless ping ?
Attendre une mise à jour CMP ?
        │
       oui
        ↓
Quel storage est accordé ?
        ↓
Quelle destination peut recevoir quoi ?

Aucun sélecteur CSS ne répond à ça.

Même chose avec un conteneur server-side, un proxy first-party, une déduplication navigateur/serveur ou un traitement spécifique des identifiants.

Le Visual Tagging simplifie l’entrée du système.

Il ne remplace pas le système.

Le server-side reste une autre architecture

Google continue d’ailleurs de présenter explicitement le Server-Side Tagging comme une architecture permettant de déplacer une partie du traitement des tags du navigateur vers un serveur.

Dans GTM, une Google tag peut notamment être configurée avec :

server_container_url

pour envoyer les événements vers un conteneur serveur au lieu de les envoyer directement vers Google Analytics.

Le chemin devient alors :

Browser
   ↓
Web GTM
   ↓
server_container_url
   ↓
Server GTM
   ↓
Clients / transformations
   ↓
Tags serveur
   ↓
GA4 / Ads / autres destinations

Visual Tagging ne supprime aucune de ces couches.

Il peut éventuellement produire l’événement qui entre dans la chaîne.

Ensuite commencent justement les sujets intéressants.

Ce qui disparaît progressivement, c’est l’expertise du clic dans l’interface

J’ai longtemps considéré qu’une partie du travail dans GTM était du travail d’exécution.

Créer :

  • un tag ;
  • un trigger ;
  • une variable ;
  • un lookup ;
  • un événement ;
  • une configuration Google Ads.

Ce travail demande de connaître l’outil, mais ce n’est pas forcément là que se trouve la plus grande valeur.

Aujourd’hui, trois forces attaquent exactement cette partie du métier.

Google automatise directement certaines configurations avec Visual Tagging.

L’API GTM permet depuis longtemps de créer programmatiquement comptes, containers, workspaces, tags, triggers, variables et versions. Google la documente toujours comme une fonction majeure de Tag Manager.

Et les LLM savent de mieux en mieux produire ou analyser ce type de configuration.

Donc oui : la valeur du spécialiste qui sait simplement cliquer dans GTM va continuer à diminuer.

Ça ne me gêne pas spécialement.

Parce que ce n’est pas là que se trouvent les problèmes difficiles.

Le vrai métier commence avant GTM et se termine après GTM

Sur une implémentation sérieuse, je dois encore déterminer :

Business requirement
       ↓
Measurement model
       ↓
Event taxonomy
       ↓
Data contract
       ↓
Data Layer / API
       ↓
Consent policy
       ↓
GTM
       ↓
Destinations
       ↓
Validation
       ↓
Réconciliation CRM / back-office

GTM n’est qu’une partie de cette chaîne.

Le problème difficile n’est pas :

Comment créer l’événement purchase ?

Le problème est :

À quel moment une transaction est-elle suffisamment certaine pour être considérée comme purchase ?

Puis :

Quelle valeur dois-je envoyer ?

Et :

Que se passe-t-il lorsqu’elle est annulée ?

Ou :

Pourquoi le CRM contient 3 842 commandes alors que GA4 en mesure 3 506 et Google Ads en attribue 2 117 ?

Aucun bouton point-and-click ne répond à ça.

Et tant mieux.

Google Tag Manager devient progressivement un routeur de données

C’est finalement ce que je trouve le plus intéressant dans cette évolution.

Le nom Tag Manager vient d’une époque où l’on raisonnait surtout en balises JavaScript :

Page
 ↓
Tag A
Tag B
Tag C
Tag D

Le modèle qui se dessine maintenant ressemble beaucoup plus à ça :

                   EVENTS
                      │
                      ▼
                GTM CONTAINER
                      │
        ┌─────────────┼─────────────┐
        │             │             │
   Settings        Policies      Transformations
        │             │             │
        └─────────────┼─────────────┘
                      │
                Destinations
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
       GA4           Ads        autres outils

Le conteneur devient progressivement une couche de configuration, d’orchestration et de distribution.

Je trouve cette lecture beaucoup plus intéressante que « Google a déplacé Variables dans Advanced ».

Google rend le tracking simple plus simple. Et c’est exactement ce qu’il fallait faire

Je ne vais certainement pas regretter une époque où il fallait passer quinze minutes à configurer manuellement une conversion basique.

Pour un petit annonceur dont le besoin est :

quand cette commande est confirmée, envoyez sa valeur à Google Ads

Visual Tagging peut être une excellente solution.

Pour Google, c’est également logique.

Une conversion mal installée détériore la mesure, l’attribution et donc potentiellement l’optimisation des campagnes. Réduire les erreurs de configuration est directement dans son intérêt.

Google présente d’ailleurs officiellement l’évolution 2026 comme une manière de réduire les efforts, les erreurs de configuration et la dépendance aux cycles de développement.

Je n’y vois aucun problème.

Le problème commencerait si on confondait facilité de configuration et qualité de mesure.

Ce sont deux choses complètement différentes.

Ce que cette évolution change vraiment

Je vais probablement créer moins de choses manuellement dans GTM.

Et tant mieux.

Je préfère passer mon temps à concevoir un bon Data Layer, sécuriser une architecture server-side, vérifier Consent Mode, auditer les doublons, tester les cas limites ou réconcilier les données Analytics avec le système métier.

Ce sont ces problèmes qui coûtent cher lorsqu’ils sont mal traités.

Créer un trigger ne devrait pas être une expertise rare.

Savoir pourquoi ce trigger existe, quelle donnée l’alimente, ce qu’il déclenche et comment je prouve que le résultat est juste, oui.

C’est finalement ce que raconte assez bien cette mise à jour.

Google n’est pas en train de tuer Google Tag Manager.

Il est en train d’automatiser sa plomberie.

Et plus la plomberie devient invisible, plus la qualité de l’architecture derrière devient importante.

Retour en haut
Formations Analytics