gtag('config') ne fonctionne plus dans GTM le 2 octobre 2026

Si vous avez reçu un email de Google qui parle d’une “unsupported implementation” sur votre conteneur, ne le classez pas sans lire : à partir du 2 octobre 2026, les snippets gtm.js cesseront de reconnaître et d’attendre vos commandes gtag('config'). Concrètement, le combo gtag config + gtm.js que beaucoup de sites utilisent sans le savoir va changer de comportement du jour au lendemain, et certains tags vont soit se déclencher trop tôt, soit ne plus recevoir leurs paramètres. La bonne nouvelle : diagnostiquer votre cas prend 60 secondes, et le correctif est souvent une histoire de copier-coller. Ce guide vous dit si vous êtes concerné, dans lequel des trois cas vous tombez, et quoi faire avant la date fatidique.

Ce que Google change pour gtag(‘config’) le 2 octobre 2026

Aujourd’hui, un snippet gtm.js peut “écouter” les commandes gtag('config', 'G-XXXX') présentes sur la page et attendre leurs paramètres avant d’initialiser. C’est ce comportement d’attente qui disparaît. À partir du 2 octobre 2026, tout snippet gtm.js s’initialise au chargement du conteneur, quels que soient les gtag('config') présents sur la page. La page d’aide officielle le résume sans détour : les snippets Tag Manager ne reconnaîtront plus, et n’attendront plus, aucune commande gtag('config').

Le cas qui pose problème, c’est celui que Google qualifie d’implémentation “non supportée” : un identifiant G- (GA4), AW- (Google Ads) ou DC- (Floodlight) chargé via un chemin gtm.js plutôt que via le vrai snippet gtag.js. Ces setups fonctionnaient jusqu’ici par effet de bord. Ils vont s’arrêter de fonctionner comme prévu, sans autre avertissement que l’email que vous avez peut-être déjà reçu. Ce changement s’inscrit dans la bascule plus large où GTM devient Google Tag : même logique d’unification, mais ici avec une conséquence cassante et datée.

Êtes-vous concerné ? Le test en 60 secondes

Avant de toucher à quoi que ce soit, vérifiez. Ouvrez votre site, lancez les DevTools de Chrome (F12), onglet Network, filtre js, puis rechargez la page. Regardez ce que le navigateur télécharge :

• une requête vers gtm.js (https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXX) : vous chargez un conteneur Tag Manager.
• une requête vers gtag/js (https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX) : vous chargez le vrai Google tag.

Maintenant, dans l’onglet Console ou dans le code source, cherchez la présence d’une ligne gtag('config', 'G-...'), gtag('config', 'AW-...') ou gtag('config', 'DC-...'). Le croisement des deux informations donne votre diagnostic. Si vous chargez uniquement gtm.js mais que vous trouvez un gtag('config') avec un ID G-, AW- ou DC-, vous êtes en implémentation non supportée. Doublez la vérification avec Tag Assistant (Google) : lancez une session de debug, regardez quels tags remontent et avec quel identifiant. Tag Assistant vous montre noir sur blanc quel snippet sert réellement vos tags.

Les 3 cas de figure et leur correctif

Une fois le diagnostic posé, vous tombez forcément dans l’un de ces trois cas. Le tableau ci-dessous résume l’action à mener ; les détails suivent.

Cas A : GTM seul, rien à faire

Vous chargez un conteneur GTM-XXXXXX classique, tous vos tags (GA4, Ads, autres) sont configurés dans l’interface de Tag Manager, et il n’y a aucun gtag('config') en dur dans le code de la page. C’est l’implémentation propre et recommandée. Le changement du 2 octobre ne vous touche pas. Vérifiez quand même avec le test des 60 secondes, parce qu’un gtag('config') oublié dans un vieux template ou un plugin est vite arrivé.

Cas B : ID Google chargé via gtm.js, le vrai correctif

C’est le cas des sites notifiés. Vous chargez un ID G-, AW- ou DC- en passant par un snippet gtm.js, et vous comptez sur gtag('config') pour passer les paramètres. La solution officielle est nette : revenez au vrai snippet gtag.js. Voici les deux blocs, le mauvais et le bon, côte à côte.

Snippet incorrect (ID Google servi par gtm.js) :

<script async src="https://www.googletagmanager.com/gtm.js?id=G-XXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

Snippet correct (vrai gtag.js) :

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

La différence tient sur un mot dans l’URL : gtag/js au lieu de gtm.js. Le reste du code ne bouge pas. Une fois cette bascule faite, votre gtag('config') est de nouveau lu et attendu comme prévu, parce que vous chargez enfin le script qui est censé le gérer.

Cas C : GTM légitime plus config gtag, rapatrier dans l’interface

Vous utilisez réellement Tag Manager pour piloter plusieurs tags (déclencheurs, variables, autres plateformes) et vous avez un gtag('config') sur la page pour un GA4 ou un Ads. Ne cassez pas votre conteneur : gardez le snippet GTM-XXXXXX, mais déplacez la configuration qui vivait dans gtag('config') vers l’interface de GTM, sous forme de tag Google configuré proprement avec ses paramètres. C’est le moment d’auditer votre dataLayer pour vous assurer que les valeurs dont dépendaient vos paramètres config sont bien poussées côté conteneur ; le guide complet du dataLayer GTM détaille comment structurer ça sans casser vos events GA4.

Le déclencheur gtm init : ce qu’il fait vraiment

Google introduit un nouveau déclencheur, gtm init, pour reprendre en main le comportement d’initialisation que gtag('config') gérait implicitement. Il se déclenche à l’amorçage du conteneur et sert de point d’ancrage pour tout ce qui doit partir en premier. Point important pour les setups anciens : gtm init peut être configuré pour attendre la commande config avant de laisser filer les tags, ce qui vous offre un filet de sécurité si votre implémentation historique dépendait de cette attente. Autrement dit, si vous ne pouvez pas migrer proprement d’ici le 2 octobre, ce déclencheur est votre roue de secours, pas votre solution cible.

Le piège consentement : l’ordre qui casse tout

C’est ici que la plupart des setups vont se planter en silence. Trois moments d’initialisation coexistent désormais et leur ordre décide si un tag part avant ou après le consentement : Consent Initialization (gtm.init_consent), puis Initialization (gtm.init), puis votre gtm init. Un tag dépendant du consentement mal câblé sur le mauvais déclencheur partira avant que la CMP ait renvoyé son signal, et vous collecterez des données sans base légale, ou au contraire vous perdrez des conversions parce que le tag part trop tard.

La règle : tout ce qui touche à la publicité et à la mesure consent-dependent doit se caler après Consent Initialization, jamais avant. Si vous avez déjà bataillé avec le Consent Mode v2 dans GA4, vous savez que le paramètre ad_storage gouverne désormais seul le flux vers Google Ads : un tag qui se réveille avant le signal de consentement, c’est exactement le scénario qui vide vos conversions. Vérifiez l’ordre de déclenchement avant de considérer la migration terminée.

Vérification post-migration

Une migration non vérifiée n’est pas une migration. Après avoir appliqué votre correctif, déroulez ce contrôle :

1. Tag Assistant : relancez une session, confirmez que vos tags se déclenchent avec le bon identifiant et via le bon snippet.
2. DevTools, onglet Network : vérifiez que la requête part bien vers gtag/js (cas B) et que les hits GA4 (/g/collect) et Ads partent avec les bons paramètres.
3. GA4 temps réel : contrôlez que les événements remontent et que les paramètres attendus sont présents.
4. Conversions Google Ads sur 48 h : c’est le vrai juge de paix. Surveillez le volume de conversions sur deux jours pour détecter une chute liée à un tag qui ne part plus ou qui part trop tôt.

Si vous voulez un cadre plus large pour ce contrôle, l’audit GA4 des erreurs de configuration reprend les points qui faussent le plus souvent les données après une manip sur le tagging.

Checklist avant le 2 octobre 2026

Pour ne rien oublier, voici la liste courte à cocher avant la date :

• Test des 60 secondes fait (Network gtm.js vs gtag/js + recherche gtag('config')).
• Cas identifié (A, B ou C) et correctif choisi.
• Snippet corrigé (cas B) ou config rapatriée dans l’UI GTM (cas C).
• Ordre des déclencheurs vérifié : consentement avant les tags publicitaires.
• Contrôle Tag Assistant + DevTools + GA4 temps réel.
• Surveillance des conversions Google Ads sur 48 h après la bascule.

Dernier point utile : ce changement ne concerne que le client-side. Si vos tags passent déjà par un GTM server-side, ou si vous servez votre snippet en first-party via Google Tag Gateway, la logique d’initialisation côté serveur n’est pas impactée par cette bascule. Reste à traiter votre couche client, et à le faire avant le 2 octobre plutôt que le 3.