Google Tag : certaines implémentations gtm.js ne seront bientôt plus supportées

Si vous gérez Google Analytics 4, Google Ads ou Google Tag Manager, vous avez peut-être reçu récemment un email de Google avec un message assez inquiétant :

« This configuration will soon no longer be supported. »

Je préfère commencer par la bonne nouvelle : si votre installation Google Tag Manager est propre, avec un vrai conteneur GTM-XXXXXX et vos balises Google configurées dans GTM, il n’y a aucune raison de paniquer.

Le problème est ailleurs.

Google est en train de supprimer progressivement toute une série de comportements historiques qui permettaient à des implémentations techniquement bancales de continuer à fonctionner. Certaines ont été créées volontairement. D’autres viennent de plugins WordPress, de CMS, de développements anciens ou de migrations GA4 successives.

Et le piège, c’est justement celui-là : une installation peut fonctionner aujourd’hui sans pour autant être correctement implémentée.

Guide comment gérer la fin du support gtm.js

Ce que Google va réellement changer

Le changement tient en une phrase.

Lorsqu’un script gtm.js sera chargé, il initialisera désormais son conteneur sans attendre une éventuelle commande :

gtag('config', 'TAG_ID');

Google l’écrit explicitement : les snippets Google Tag Manager utilisant gtm.js vont bientôt cesser de reconnaître ou d’attendre les commandes gtag('config').

Pourquoi est-ce important ?

Parce que gtag('config') ne sert pas simplement à afficher joliment un identifiant Analytics dans le code.

Cette commande configure une destination Google et peut transporter des paramètres applicables aux événements envoyés vers cette destination. Google documente par exemple des paramètres comme send_page_view, groups ou d’autres réglages propres à Google Analytics et Google Ads.

Une implémentation peut donc actuellement compter sur cette séquence :

Chargement gtm.js
        ↓
attente de gtag('config')
        ↓
configuration de la destination
        ↓
initialisation / événements

Cette dépendance disparaît.

Le nouveau comportement devient plutôt :

Chargement gtm.js
        ↓
initialisation du conteneur
        ↓
gtag('config') éventuellement présent ensuite

Si votre architecture dépendait du premier fonctionnement, vous avez un problème.

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.

Pourquoi Google fait ça maintenant

Ce changement ne tombe pas du ciel.

Depuis plusieurs mois, Google rapproche progressivement Google tag et Google Tag Manager.

Le 20 août 2026, Google a annoncé que les Google tags allaient évoluer vers des conteneurs Google Tag Manager disposant des fonctions de GTM : interface de gestion, debug, versioning et gestion des balises.

Google précise également que les nouveaux snippets de déploiement seront harmonisés et qu’ils n’incluront plus automatiquement la commande gtag('config'). Pour les nouveaux mécanismes d’initialisation, Google recommande notamment le déclencheur gtm init.

Ce n’est donc pas une petite modification de syntaxe.

Google est en train de simplifier son architecture de tagging.

Pendant des années, on avait essentiellement deux mondes.

Google tag / gtag.js chargeait directement les produits Google.

https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX

Et Google Tag Manager / gtm.js chargeait un conteneur.

https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX

Dans la vraie vie, évidemment, les choses sont devenues beaucoup moins propres.

Le vrai problème : les installations hybrides

J’en vois régulièrement dans les audits.

Un bout de Google Analytics ajouté directement dans le thème WordPress. Un GTM installé cinq ans plus tard. Google Ads ajouté par une extension. Une CMP qui pousse quelques commandes gtag(). Puis une migration GA4. Puis quelqu’un rajoute une nouvelle conversion.

Au bout de quelques années, personne ne sait vraiment qui initialise quoi.

On peut alors retrouver quelque chose de ce genre :

<!-- Google Tag Manager -->
<script>
  ...
  j.src='https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX';
  ...
</script>

<script>
  gtag('config', 'G-XXXXXXXXXX');
</script>

Ça ressemble vaguement à Google Tag Manager.

Ça ressemble vaguement à Google tag.

Mais c’est précisément le type de combinaison que Google veut supprimer.

Google donne d’ailleurs cette architecture comme exemple d’implémentation non supportée.

Il existe un deuxième cas encore plus trompeur

On rencontre aussi des intégrations qui utilisent bien le loader gtm.js…

mais avec un identifiant qui n’est pas un conteneur GTM.

Par exemple :

/gtm.js?id=G-XXXXXXXX

ou :

/gtm.js?id=AW-XXXXXXXX

au lieu de :

/gtm.js?id=GTM-XXXXXXXX

Google cite explicitement les identifiants G-, AW- et DC- chargés par le chemin GTM comme implémentations non supportées.

On trouve d’ailleurs déjà des exemples concrets dans l’écosystème WordPress : un utilisateur saisit un identifiant Google Ads AW-... dans un emplacement conçu pour recevoir un identifiant de conteneur GTM-..., puis le plugin génère mécaniquement un loader gtm.js. Le site fonctionne suffisamment bien pour que personne ne remarque le problème… jusqu’au mail de Google.

C’est exactement le genre d’erreur qui peut rester invisible pendant plusieurs années.

Une modification de juillet 2026 annonçait déjà la couleur

Il y a un autre changement important qui aide à comprendre ce qui se passe.

Le 9 juillet 2026, Google a modifié la manière dont GTM traite les chemins de chargement incorrects.

Désormais, les capacités du conteneur dépendent principalement du préfixe de l’identifiant utilisé.

Un GTM-XXXX dispose de toutes les capacités GTM.

Un identifiant produit comme G-XXXX ou AW-XXXX reste limité aux balises Google, même s’il est chargé à travers un chemin inhabituel.

Google indiquait déjà avoir envoyé des notifications par email aux administrateurs des conteneurs significativement concernés.

Le changement d’octobre s’inscrit dans la même logique : Google cesse progressivement de maintenir les comportements accidentels ou historiques créés par des combinaisons de snippets non prévues.

Comment savoir si votre site est concerné

Le plus simple est de regarder ce que charge réellement le navigateur.

Ce tableau résume les principaux cas.

Ce que je trouve sur la page	Diagnostic
`/gtm.js?id=GTM-XXXX` et toutes les configurations GA4/Ads sont dans GTM	Installation GTM normale
`/gtag/js?id=G-XXXX` ou `AW-XXXX` avec `gtag('config')`	Installation directe Google tag normale
`/gtm.js?id=G-XXXX`, `AW-XXXX`, `DC-XXXX` ou autre ID Google	À corriger
`/gtm.js?id=GTM-XXXX` + `gtag('config', 'G-...')` dont le fonctionnement dépend du code de la page	Installation hybride à auditer
Plusieurs loaders GTM/gtag provenant du CMS, du thème et de plugins	Audit nécessaire avant toute suppression

Il y a une nuance importante ici.

Voir /gtm.js dans Chrome n’est absolument pas une anomalie si vous utilisez réellement Google Tag Manager.

Je le précise parce que certains articles recommandent déjà de chercher gtm.js dans DevTools et de le remplacer systématiquement par gtag/js.

C’est faux.

Un conteneur GTM normal utilise toujours gtm.js.

La recommandation de Google consistant à vérifier la présence de gtag/js après migration concerne les sites qui souhaitent utiliser directement Google tag et les commandes gtag('config').

Si vous utilisez vraiment Google Tag Manager

C’est le cas que je privilégie généralement sur les implémentations professionnelles.

Le site charge :

GTM-XXXXXXXX

et Google Analytics, Google Ads, Floodlight ou les autres outils sont gérés depuis le conteneur.

Dans cette situation, je ne remplacerais certainement pas GTM par un snippet gtag.js simplement parce qu’un email Google est arrivé.

Je commencerais par chercher pourquoi Google a envoyé l’alerte.

Il peut rester un ancien :

gtag('config', 'G-XXXXXXXX');

dans le thème.

Ou dans un plugin.

Ou dans un module e-commerce.

Ou dans une ancienne intégration Google Ads.

Ou dans une couche de code utilisée par la CMP.

La correction consiste alors généralement à ramener la configuration Google dans GTM, puis à supprimer les dépendances inutiles dans le code de la page.

C’est d’ailleurs exactement ce que recommande Google lorsque Google Tag Manager sert déjà à gérer d’autres tags : conserver le snippet GTM, utiliser le bon identifiant GTM-XXXXXX et gérer les Google tags et leurs configurations depuis l’interface GTM.

Si vous n’utilisez pas réellement Google Tag Manager

Deuxième scénario : vous voulez simplement installer GA4, Google Ads ou une autre destination Google directement dans votre site.

Dans ce cas, utilisez le vrai snippet Google tag :

<script async
  src="https://www.googletagmanager.com/gtag/js?id=TAG_ID">
</script>

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

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

  gtag('js', new Date());
  gtag('config', 'TAG_ID');
</script>

C’est le modèle actuellement documenté par Google pour une installation directe avec gtag.js.

Le principe devient alors cohérent :

gtag.js → commandes gtag()

ou :

gtm.js → configuration GTM

Ce que Google cherche justement à éliminer, ce sont les architectures qui utilisent un peu des deux sans frontière claire.

Et `gtag('consent')` dans tout ça ?

C’est une distinction importante.

L’alerte Google concerne spécifiquement la dépendance aux commandes :

gtag('config')

La commande :

gtag('consent')

est une autre commande de l’API gtag.

Google documente séparément config, event, set, get et consent.

Donc la simple présence de :

gtag('consent', 'default', ...);

ou :

gtag('consent', 'update', ...);

ne suffit pas à conclure que votre site est concerné par ce changement.

Il faut analyser l’architecture complète.

C’est particulièrement important avec Consent Mode v2, parce qu’une intervention trop rapide sur les snippets peut régler le mail de Google tout en cassant votre gestion du consentement. Ce serait un progrès assez relatif.

Ce qui peut réellement casser

Je serais prudent avec les gros titres du type « votre tracking va disparaître le 2 octobre ».

Google ne dit pas ça.

Google dit que le comportement des tags peut être modifié si l’installation repose sur cette architecture non supportée.

Le risque dépend donc de ce que votre commande config faisait réellement.

Prenons :

gtag('config', 'G-XXXXXXXX', {
  send_page_view: false
});

Ici, votre application indique que la balise ne doit pas envoyer automatiquement un page_view.

Ou :

gtag('config', 'G-XXXXXXXX', {
  groups: 'agency'
});

Ici, la configuration participe au routage des événements.

Google documente précisément ces notions de portée : un paramètre config s’applique aux événements envoyés vers une cible particulière et se situe entre les paramètres globaux set et les paramètres spécifiques à l’événement.

Si votre architecture suppose que GTM attend cette configuration avant de commencer à travailler, le changement d’ordre d’initialisation peut produire un comportement différent.

Ce n’est pas forcément une panne spectaculaire.

Et c’est justement ça qui m’inquiète davantage.

Un tracking complètement cassé se voit assez vite.

Un tracking qui continue d’envoyer 93 % des données tout en perdant une partie de ses paramètres, de ses conversions ou de ses conditions de configuration peut rester faux pendant des semaines.

Tag Assistant est utile, mais je ne m’arrêterais pas là

Google recommande naturellement Tag Assistant pour vérifier l’installation après correction.

Je compléterais toujours avec DevTools.

Dans Network, je regarde précisément quelles bibliothèques sont chargées.

googletagmanager.com/gtm.js
googletagmanager.com/gtag/js

Je contrôle ensuite leurs paramètres id.

Je regarde les requêtes de collecte.

Je vérifie les événements GA4.

Je contrôle les conversions Ads.

Puis je regarde le dataLayer.

Enfin, je refais le test dans différents états de consentement.

C’est beaucoup plus fiable que de constater simplement qu’un voyant Tag Assistant est vert.

Attention aux installations server-side

Avoir un Google Tag Manager server-side ne permet pas automatiquement d’ignorer le sujet.

Le navigateur doit toujours initier une partie de la collecte.

Et les installations utilisant Google tag gateway ou un endpoint first-party peuvent également servir gtag.js ou gtm.js depuis un chemin de mesure personnalisé.

Google documente d’ailleurs séparément la manière de router les deux loaders à travers Google tag gateway.

Je contrôlerais donc toujours la couche Web avant la couche Server.

La question n’est pas :

« Avons-nous un serveur GTM ? »

La bonne question est :

« Quel script le navigateur charge-t-il, avec quel ID, qui le configure et dans quel ordre ? »

Je déconseille fortement la correction “rechercher/remplacer”

C’est probablement le principal message que je donnerais à un client qui vient de recevoir cet email.

Ne remplacez pas :

gtm.js

par :

gtag/js

partout dans votre site.

Et ne supprimez pas tous les gtag('config') sous prétexte que Google vient d’envoyer une alerte.

Il faut d’abord comprendre qui fait quoi.

Sur un site un peu ancien, une même destination Google Analytics peut être créée depuis le thème, GTM, un plugin SEO, un module e-commerce ou une application marketing.

Supprimer le mauvais morceau peut entraîner un double page_view, supprimer une conversion Google Ads, casser du cross-domain ou modifier le Consent Mode.

Le problème d’origine est souvent une architecture empilée pendant plusieurs années. La résoudre proprement nécessite justement de remettre une responsabilité claire sur chaque couche.

Ce que je contrôlerais avant le 2 octobre

Sur un site concerné, mon audit ne se limiterait pas à regarder le snippet principal.

Je vérifierais :

les scripts réellement injectés dans le HTML et ceux ajoutés dynamiquement ;
tous les identifiants GTM-, GT-, G-, AW- et DC- ;
les commandes gtag('config'), gtag('set') et gtag('consent') ;
les Google tags présents dans GTM et leurs paramètres ;
les plugins, CMS, CMP et modules e-commerce susceptibles d’injecter une seconde implémentation ;
le Consent Mode dans les différents états de consentement ;
les appels GA4 et Google Ads avant et après modification ;
la présence éventuelle de GTM server-side ou Google tag gateway ;
les doublons de tags, de page_view et de conversions ;
les données réellement reçues dans GA4 et Google Ads après mise en production.

Je conserverais aussi une référence avant migration : volume d’événements, transactions, revenus, conversions Google Ads et principales métriques techniques.

Sinon on risque de découvrir quinze jours plus tard qu’un « petit changement de snippet » a fait perdre 20 % des conversions.

Cet email est surtout une bonne occasion de nettoyer votre tracking

Je vois cette évolution comme quelque chose de plutôt sain.

Google réduit progressivement les zones grises entre Google tag et Google Tag Manager.

Le 20 août, Google a annoncé la convergence des deux architectures. Les nouveaux snippets vont être harmonisés, les Google tags vont gagner les capacités de GTM et l’initialisation ne reposera plus systématiquement sur les anciennes commandes gtag('config').

Le revers, c’est que les implémentations bricolées qui ont continué à fonctionner pendant des années arrivent en bout de course.

Et c’est souvent là que l’on découvre le vrai problème.

Pas le changement Google.

L’absence de maîtrise de son propre dispositif de collecte.

Vous avez reçu l’email Google ? Je commencerais par un audit, pas par une migration

Chez webAnalyste, c’est exactement le type de sujet sur lequel j’interviens : Google Tag Manager, GA4, Google Ads, Consent Mode, dataLayer et tracking server-side.

Si vous avez reçu l’alerte Google, l’objectif n’est pas simplement de faire disparaître le warning.

Il faut déterminer pourquoi votre domaine a été détecté, supprimer l’implémentation non supportée sans créer de doublons et vérifier que GA4, Google Ads, vos conversions et votre consentement fonctionnent toujours après la correction.

Sur des dispositifs importants, je préfère passer une heure à comprendre le chemin complet de la donnée plutôt que cinq minutes à remplacer un snippet.

Les cinq minutes coûtent généralement plus cher quand elles sont mauvaises.

Les sources Google à conserver

La page la plus importante est la nouvelle documentation Google consacrée spécifiquement aux installations gtm.js / gtag.js non supportées. Documentation Google — Set up your Google tag installation correctly for gtag.js

Pour comprendre le contexte plus large, Google détaille également la convergence entre Google tag et Google Tag Manager annoncée le 20 août 2026. Google — Updates to Google tag and Google Tag Manager

La référence technique officielle de gtag() permet enfin de comprendre précisément ce que font config, event, set, get et consent. Google Tag API reference

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.