Guide sur la fusion de GTM et de la balise Google

Le conteneur GTM devient une balise Google. Destinations, fin du gtag.js par produit, onglet Paramètres, droits d’accès : ce qui change et comment migrer sans casser votre tracking.

C’est lancé. Google Tag Manager et la balise Google ne forment plus qu’un seul produit, et ça passe par une mise à jour manuelle de votre conteneur. Annoncé à Google Marketing Live le 20 mai 2026, le changement est entré dans les release notes GTM du 12 octobre.

Le principe : votre conteneur GTM devient une balise Google à part entière. GA4, Google Ads ou Floodlight ne sont plus des balises Google posées séparément, ce sont des destinations du conteneur. Les réglages remontent dans un onglet Paramètres commun, et le chargement de gtag.js par destination disparaît.

Rien n’est déployé d’office. Mais ce qui se déplace — paramètres partagés et droits d’accès — c’est exactement là qu’on casse un tracking si on migre vite. Je détaille ce qui change, ce que ça implique techniquement, et comment migrer proprement, avec le code pour auditer avant/après.

Le conteneur GTM devient une balise Google

Jusqu’ici, GTM et la balise Google cohabitaient de façon un peu absurde : avec GTM, on utilisait en pratique un gestionnaire pour injecter un autre gestionnaire, la balise Google. C’est fini. Côté Google, les balises Google sont transformées en conteneurs GTM complets, et chaque destination Google dispose de sa propre balise, ce qui préserve votre configuration et vos déclencheurs existants.

Découvrez égalementComment contrôler les données avec le Server-Side GTM ?

Concrètement, sur la page Vue d’ensemble, la nouvelle carte visuelle montre le flux : Conteneur ➔ balises Google ➔ Destinations. Une destination, c’est là où arrivent vos données de mesure : un flux de données web GA4 ou un compte Google Ads par exemple. La balise de destination relie directement le conteneur à cette destination.

Trois points à ne pas mal comprendre :

• L’upgrade ne déclenche aucun envoi automatique vers GA4, Google Ads ou Floodlight sans configuration explicite.
• Les balises non Google et les implémentations custom restent pleinement supportées.
• Si vous voulez garder l’ancien fonctionnement (réglages séparés, chargements de librairies supplémentaires), vous pouvez continuer à utiliser les balises Google legacy dans GTM.

Un détail qui change le déploiement : l’ID. Un snippet déployé avec un ID GTM- est un conteneur complet ; déployé avec un ID produit (G-, AW-), il est limité au périmètre des produits Google. L’audit de l’ID de conteneur devient donc une nouvelle action à mener. Et côté snippet, les nouveaux snippets de déploiement ne contiennent plus la commande gtag config ; Google recommande de configurer l’initialisation via un nouveau déclencheur gtm init.

À noter aussi pour ceux qui forment des équipes marketing : l’interface est refondue, avec une section Paramètres centralisée, tandis que déclencheurs, variables, modèles et dossiers passent dans une section Avancé repliable.

Performance : la fin du gtag.js par destination

Découvrez égalementComment structurer les variables Google Tag Manager ?

C’est le gain le plus concret. Dans l’ancien système, chaque balise Google du conteneur charge son propre fichier gtag.js. Un conteneur qui fait tourner GA4, Google Ads et Floodlight charge donc trois librairies en plus du script GTM. Après l’upgrade, les destinations passent entièrement par le JavaScript unique du conteneur. Google reconnaît que ce gtag.js supplémentaire pouvait introduire de la latence dans la transmission des mesures.

Ne vous attendez pas à un miracle sur toutes les pages : le résultat dépend de votre implémentation, et la migration ne retire pas les balises Google installées à côté via le template du site, un plugin ou un autre service. C’est le premier truc que je vérifie, parce qu’un gtag.js posé par un plugin WordPress qui traîne en parallèle, c’est des doublons garantis.

Pour mesurer avant/après, je colle ce script dans la console Chrome :

// Audit des scripts Google Tag chargés sur la page.
// À lancer avant migration puis après publication de la version optimisée.
// gtm.js = conteneur ; gtag/js = une librairie par balise Google legacy.
const tagScripts = performance.getEntriesByType('resource')
  // Adaptez la regex si vous servez GTM via un domaine first-party (tag gateway, sGTM)
  .filter(r => /googletagmanager.com/(gtm.js|gtag/js)/.test(r.name))
  .map(r => {
    const url = new URL(r.name);
    return {
      type: url.pathname.includes('/gtag/js') ? 'gtag.js' : 'gtm.js',
      id: url.searchParams.get('id'),          // GTM-XXXX, G-XXXX, AW-XXXX…
      transfer_kb: Math.round(r.transferSize / 1024), // 0 si servi depuis le cache
      duree_ms: Math.round(r.duration)
    };
  });

console.table(tagScripts);

// Alerte doublons : même ID chargé plusieurs fois (plugin + GTM, par ex.)
const ids = tagScripts.map(s => s.id);
const doublons = ids.filter((id, i) => ids.indexOf(id) !== i);
if (doublons.length) console.warn('ID chargés plusieurs fois :', [...new Set(doublons)]);

// Combien de gtag.js restent après migration ? L'objectif est 0 pour les destinations optimisées.
console.log('gtag.js chargés :', tagScripts.filter(s => s.type === 'gtag.js').length);

Avant migration, vous devriez voir un gtm.js et un gtag/js par ID Google. Après, les gtag/js des destinations optimisées doivent disparaître. S’il en reste un, il vient d’ailleurs que de GTM.

Onglet Paramètres, consentement et droits d’accès : ce qui se déplace

L’onglet Paramètres

Découvrez égalementAlerte Google Tag Manager : nouvel événement gtag.config

L’onglet Paramètres centralise les réglages à l’échelle du conteneur, avec possibilité de les surcharger balise par balise. Il affiche aussi une carte des flux montrant les destinations Google auxquelles ces réglages s’appliquent. Attention à la confusion : cette section est distincte d’Admin, où se gèrent l’administration et les accès du conteneur, et elle ne remplace pas tous les réglages de GA4 ou Google Ads.

Ce que je relis systématiquement après import : les domaines pour la mesure cross-domain, la détection automatique d’événements (et son recouvrement avec vos événements custom), l’autorisation des données fournies par l’utilisateur dans le cadre des conversions améliorées, et les contrôles de consentement — la migration ne remplace ni votre bannière ni vos mises à jour de consentement.

Les nouveaux contrôles de consentement

Deux réglages méritent votre attention. Le premier, « Override consent mode defaults », impose au niveau du conteneur un état « denied » immédiat pour que les balises qui partent trop tôt envoient des pings sans cookie, en attendant la commande update de votre CMP. Le second, « Manage data transmission », permet de couper totalement la transmission publicitaire quand ad_storage est refusé — utile si votre juridique refuse même les pings anonymes.

Je garde quand même le default dans le code de la page, avant le snippet GTM. Le réglage conteneur est un filet, pas une raison de supprimer la ceinture :

<!-- Placé AVANT le snippet GTM, dans le <head> -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }

  // État par défaut : tout refusé tant que la CMP n'a pas répondu
  gtag('consent', 'default', {
    ad_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    analytics_storage: 'denied',
    wait_for_update: 500 // ms laissées à la CMP pour pousser l'update
  });
</script>

<!-- La CMP (Cookiebot, OneTrust, Axeptio…) pousse ensuite : -->
<!-- gtag('consent', 'update', { analytics_storage: 'granted', ... }); -->

Les droits d’accès

C’est le point le plus sensible. Lier un conteneur aux comptes de destination accorde par défaut un accès en lecture, ajustable ensuite dans la gestion des utilisateurs de GTM. Autrement dit, des gens qui avaient accès à la balise Google côté GA4 ou Ads peuvent se retrouver à voir votre conteneur.

Plus piégeux : l’assistant crée les liens de comptes externes dès l’ajout au workspace, et ces changements de permissions s’appliquent immédiatement, avant même la publication du tagging. Si vous gérez des conteneurs clients ou multi-équipes, c’est là qu’il faut regarder à deux fois.

Et un bug d’interface à connaître : au moment d’ajouter une destination, GTM affirme que vous avez un accès admin aux destinations listées, alors que la liste inclut toute propriété GA4 liée à votre compte, y compris celles où vous êtes en lecture seule.

Migrer le conteneur sans casser le tracking

Lancer l’optimisation

Il faut des droits de modification, d’approbation ou de publication sur le conteneur pour lancer le flux d’optimisation. Ne comptez pas forcément sur la bannière : dans les conteneurs testés, le chemin passait par Vue d’ensemble, section « Container quality », survol d’une balise Google dans le schéma, puis « Get started » dans la popover « Optimize for faster, easier tagging ». On choisit ensuite « Better tag performance ».

Le reste du flux tient en quatre décisions :

1. Vérifier les balises sélectionnées et leurs IDs. Surtout si vos comptes de test et de prod ont des noms proches. Le niveau d’accès s’affiche à côté de chaque balise.

2. Choisir les réglages par défaut. Si vos balises Google ont des réglages différents, l’assistant vous demande laquelle sert de référence pour le conteneur — il ne fusionne pas tout. Vous pouvez aussi ne rien importer et tout configurer vous-même.

3. Relire l’aperçu. « Show details » ouvre l’écran Preview changes : workspace, réglages ajoutés, balises ajoutées ou modifiées, et la section Permission changes avec IDs et niveaux d’accès.
4. Ajouter au workspace. Rien ne passe en ligne à ce stade : il faut encore soumettre et publier.

Avant de démarrer, vérifiez les modifications non publiées du workspace pour ne pas publier du travail sans rapport en même temps que la migration. Moi je crée un workspace dédié, point.

Auditer plusieurs conteneurs via l’API GTM

Si vous gérez un parc de conteneurs, je recense d’abord les balises Google legacy et les destinations déjà liées. L’API Tag Manager v2 expose une ressource destinations (endpoint GET sur le chemin du conteneur parent, avec le scope tagmanager.readonly suffisant) :

# pip install google-api-python-client google-auth
# Prérequis : un compte de service ajouté comme utilisateur (lecture) sur les conteneurs GTM
from google.oauth2 import service_account
from googleapiclient.discovery import build

SCOPES = ["https://www.googleapis.com/auth/tagmanager.readonly"]
creds = service_account.Credentials.from_service_account_file("sa.json", scopes=SCOPES)
gtm = build("tagmanager", "v2", credentials=creds)

def audit_container(account_id: str, container_id: str):
    parent = f"accounts/{account_id}/containers/{container_id}"

    # 1. Destinations Google liées au conteneur
    dest = gtm.accounts().containers().destinations().list(parent=parent).execute()
    for d in dest.get("destination", []):
        print(f"[destination] {d['destinationId']} - {d.get('name', '')}")

    # 2. Balises Google legacy (type 'googtag') dans chaque workspace
    workspaces = gtm.accounts().containers().workspaces().list(parent=parent).execute()
    for ws in workspaces.get("workspace", []):
        tags = gtm.accounts().containers().workspaces().tags().list(parent=ws["path"]).execute()
        legacy = [t for t in tags.get("tag", []) if t["type"] == "googtag"]
        for t in legacy:
            # Le paramètre 'tagId' contient l'ID G-/AW- ciblé
            tag_id = next((p.get("value") for p in t.get("parameter", []) if p["key"] == "tagId"), "?")
            print(f"[legacy googtag] ws={ws['name']} | {t['name']} -> {tag_id}")

audit_container("1234567", "7654321")

Ça vous donne la liste des IDs à vérifier dans l’assistant et repère les workspaces où traînent des balises Google oubliées.

La recette en Preview

En mode Preview, contrôlez dans Tag Assistant que destinations et balises d’événement se déclenchent quand prévu, avec le bon ID, les bons paramètres et sans doublon. Pour les achats, vérifiez transaction ID, valeur et devise, et testez le comportement consentement refusé puis accepté. Pour forcer un achat de test sans passer commande :

// Push e-commerce GA4 de test, à lancer dans la console en mode Preview.
// Vérifiez ensuite dans Tag Assistant que l'événement part une seule fois
// vers la destination G- attendue, avec transaction_id, value et currency.
window.dataLayer = window.dataLayer || [];
dataLayer.push({ ecommerce: null }); // purge de l'objet ecommerce précédent
dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'TEST-MIGRATION-001', // préfixe identifiable pour filtrer ensuite
    value: 49.90,
    currency: 'EUR',
    items: [{ item_id: 'SKU_TEST', item_name: 'Produit test', price: 49.90, quantity: 1 }]
  }
});

Côté server-side : le paramètre server_container_url des balises produit continue de fonctionner comme avant, même quand le conteneur est chargé via sGTM. Vérifiez quand même que les requêtes arrivent bien au conteneur serveur — la migration concerne le conteneur web et ne remplace pas vos balises server-side.

Les pièges et pourquoi je ne me précipiterais pas

Les statuts dans le tableau « Google destinations » trompent facilement. « Optimized : Yes » signifie que la destination est configurée pour recevoir les données en direct, mais si les changements ne sont pas publiés, ça ne prouve pas que c’est en ligne. Et « External account link : Not linked » ne veut pas dire, à lui seul, que le tracking est cassé.

Deuxième piège, l’ajout manuel : « Add destination » ne remplace pas automatiquement une balise Google existante pour la même destination. Ajouter puis publier direct, c’est doubler vos hits.

Troisième, le Conversion Linker. Google confirme que ses capacités sont couvertes par les balises de destination et les Paramètres pour les destinations optimisées. Mais vérifiez les destinations non optimisées avant de supprimer la balise, et ça ne vaut pas pour un Conversion Linker server-side.

Quatrième, les nouveautés qui arrivent dans le même paquet. Le visual tagging génère des balises à partir de sélecteurs CSS en parcourant votre site — pour des conversions qui pèsent du chiffre d’affaires, le dataLayer reste plus fiable. Et les résumés de version générés par IA sont activés par défaut, sans interrupteur au niveau du compte.

La nouvelle est bonne, franchement. Mais je ne vous conseille pas d’essuyer les plâtres. Laissez passer quelques jours, le temps que les bugs d’interface remontent. Sur un conteneur entreprise chargé de variables custom, de règles de consentement imbriquées et de balises HTML personnalisées, forcer la migration maintenant est un risque inutile. Et si le flux ne s’affiche pas chez vous, pas d’inquiétude : le déploiement est progressif, et l’absence de bannière ne signifie pas que votre conteneur a déjà été migré.

Un seul tag Google, mais une migration à piloter

La fusion simplifie enfin l’architecture : un conteneur, des destinations, un onglet Paramètres, et plus de gtag.js empilés par produit. Le gain de perf est réel, la centralisation aussi. Mais ce qui bouge — réglages partagés, liens de comptes, droits d’accès appliqués avant publication — exige une vraie recette. Auditez vos IDs et vos doublons, migrez dans un workspace dédié, testez consentement et e-commerce en Preview, puis publiez. Et donnez-vous quelques jours avant de basculer les conteneurs critiques.

FAQ

• La migration vers les destinations est-elle obligatoire ?
  Non. Google la recommande sans l’imposer, et vous pouvez garder votre configuration actuelle pendant que vous évaluez la nouvelle.
• Mon conteneur va-t-il envoyer des données à GA4 ou Google Ads tout seul après la mise à jour ?
  Non. Le changement est structurel. Aucun hit ne part vers une destination sans configuration explicite de votre part.
• Mes balises d’événement GA4 vont-elles être modifiées ?
  Non : les réglages de vos balises Google sont transférés dans l’onglet Paramètres, et vos balises d’événement restent inchangées.
• Qui obtient accès à mon conteneur après l’optimisation ?
  L’optimisation crée automatiquement des liens entre le conteneur et les comptes de destination, avec un accès en lecture par défaut. Vous pouvez les revoir ensuite dans Admin, puis « External Account Links ».
• Dois-je supprimer ma balise Conversion Linker ?
  Uniquement si toutes vos destinations sont optimisées, et jamais celle de votre conteneur serveur.
• Quelle différence entre déployer avec l’ID GTM- et l’ID G- ou AW- ?
  Chaque nouvelle balise Google aura à la fois un ID de conteneur GTM et un ID produit. Le déploiement avec l’ID GTM donne toutes les fonctionnalités du conteneur ; avec l’ID produit, il se limite aux balises des produits Google.

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.