Google a modifié début octobre la façon dont Google Tag Manager se charge sur les sites. Deux notes de version, datées du 8 et du 12 octobre 2026, changent le comportement des conteneurs. Pour la plupart des sites, rien ne casse. Mais un montage qu’on retrouve souvent sur les sites livrés « vite fait » est désormais déclaré non pris en charge par Google. Mieux vaut le savoir avant de découvrir des trous dans ses statistiques.
Les points :
Ce que Google a annoncé le 8 octobre #
La première note, intitulée « Standardizing gtag(‘config’) command behavior for Google Tag Manager », figure dans les notes de version officielles de Tag Manager. Google y explique que tous les extraits de code gtm.js s’initialisent désormais dès le chargement du conteneur. Ils n’attendent plus la commande gtag('config') qui les accompagnait parfois.
Conséquence directe : ces commandes de configuration apparaissent maintenant dans le dataLayer sous la forme d’événements visibles, nommés gtag.config. Les balises qui reposent sur un déclencheur d’événement personnalisé « joker » (qui réagit à tout événement) peuvent donc se déclencher une fois de plus que prévu. Google le dit lui-même : ce changement peut faire partir ces balises.
À lire KPI définition : 15 indicateurs essentiels
Le montage désormais hors des clous
Le cas visé est précis. D’après le décryptage publié par PPC Land, qui cite la page d’aide de Google, il s’agit des sites qui chargent le script gtm.js avec un identifiant G- (Analytics), AW- (Google Ads) ou DC- (Campaign Manager) au lieu d’un identifiant GTM-. Le schéma typique : l’extrait Tag Manager classique, puis une ligne gtag('config', 'G-XXXX') isolée, sans le script gtag.js qui devrait la charger. Google qualifie cette implémentation de « non prise en charge ».
Ce bricolage vient souvent d’un copier-coller : un thème WordPress, une extension ou un prestataire a ajouté une ligne de configuration à côté d’un conteneur existant. Tant que tout fonctionnait, personne n’y touchait. C’est justement ce qui change.
Le 12 octobre : des conteneurs qui se passent de gtag.js #
La seconde note, « Optimizing Google Tag Manager containers », va dans le même sens. Les conteneurs Tag Manager peuvent désormais envoyer les données directement aux outils de mesure de Google, sans charger un script gtag.js supplémentaire. Google met en avant trois bénéfices : de meilleures performances pour le site, des réglages et des accès utilisateurs regroupés dans le conteneur, et un diagnostic plus simple grâce aux balises de destination.
Un script de moins à télécharger, c’est un gain concret pour la vitesse d’affichage, surtout sur mobile. Pour un site vitrine ou une petite boutique, chaque requête évitée compte.
À lire Mailing : Guide Email Marketing 2026
La suite d’un chantier lancé cet été
Ces deux notes prolongent la fusion de Google Tag et de Tag Manager. Fin août, Search Engine Roundtable rapportait les explications de Ginny Marvin, chargée de liaison Google Ads : une interface remaniée, des outils réunis pour gérer Google Ads et Google Analytics au même endroit, un suivi d’événements sans code et une vue « visuelle » qui montre quelles plateformes reçoivent les données. Le principe reste le même : un seul point d’entrée pour la mesure.
Ce qu’il faut vérifier sur votre site #
Si votre site a été créé sur mesure ou repris par plusieurs prestataires successifs, un contrôle prend quelques minutes et peut éviter des semaines de données faussées.
Repérer le montage concerné
Ouvrez le code source de votre page d’accueil et cherchez « googletagmanager.com ». Si vous trouvez gtm.js suivi d’un identifiant commençant par G-, AW- ou DC-, ou une ligne gtag('config') isolée à côté de l’extrait Tag Manager, vous êtes dans le cas visé. Google a d’ailleurs averti par e-mail les propriétaires des conteneurs concernés, selon PPC Land, sans préciser combien de comptes ont reçu ce message. Pensez à vérifier la boîte associée à votre compte Google.
Choisir l’une des deux corrections
Google propose deux voies. Première option : remplacer le tout par l’extrait gtag.js complet, sur toutes les pages, juste après l’ouverture de la balise head, en supprimant l’extrait gtm.js et les lignes de configuration isolées. Seconde option, la plus logique si vous utilisez Tag Manager pour d’autres balises (pixel publicitaire, outil de heatmap, chat) : conserver l’extrait Tag Manager avec son identifiant GTM- et installer la balise Google à l’intérieur du conteneur.
À lire BtoB Marketing : Stratégies Efficaces 2026
Contrôler les déclencheurs « joker »
Dans votre conteneur, passez en revue les déclencheurs d’événements personnalisés qui utilisent une expression du type .*. Ils réagiront désormais à l’événement gtag.config. Le spécialiste Simo Ahava, cité par PPC Land, conseille d’exclure cet événement au niveau du déclencheur, ou au minimum d’en tenir compte dans vos annotations et vos journaux. Sans cela, une balise de conversion pourrait compter un événement en double.
Valider après modification
Une fois la correction en place, ouvrez Tag Assistant : l’en-tête « Google tags found » doit lister vos balises. Vous pouvez aussi ouvrir l’onglet Réseau des outils de développement de Chrome et vérifier les requêtes envoyées vers Google. Comparez ensuite vos sessions et conversions sur quelques jours avec la période précédente pour repérer un écart anormal.
Pourquoi c’est le bon moment pour faire le ménage #
Ni la note de version ni la page d’aide ne donnent de date butoir ferme : la page d’aide parle d’une mise à jour « prochaine » des extraits, alors que la note décrit le comportement comme déjà actif. Cette incertitude plaide pour agir maintenant plutôt qu’attendre une chute brutale des chiffres.
C’est aussi l’occasion de faire le tri dans les scripts accumulés au fil des refontes. Un site sur mesure bien construit charge une seule fois ses outils de mesure, au bon endroit, avec une documentation claire de ce qui est installé. Si votre prestataire ne sait plus dire quelles balises tournent sur votre site, ce changement de Google est une bonne raison de lui poser la question.
