Un nouvel événement `gtag.config` peut déclencher vos balises à votre insu !

Depuis le 8 octobre 2026, Google a modifié le comportement de Google Tag Manager (GTM) pour harmoniser l’initialisation des conteneurs avec les commandes gtag('config'). Une évolution technique qui pourrait passer inaperçue, sauf qu’elle introduit un nouvel événement dans la chronologie du dataLayer : gtag.config.

Pourquoi est-ce important ? Parce que cet événement peut être intercepté par certains déclencheurs GTM utilisant des expressions régulières génériques, notamment .*. Résultat : des balises Analytics, Google Ads ou d’autres outils peuvent se déclencher alors qu’elles n’étaient pas censées le faire.

Le plus gênant, c’est que ce comportement peut apparaître sans aucune modification de votre conteneur GTM. Votre configuration reste identique, mais les événements auxquels réagissent certaines balises changent.

Google confirme ce changement dans ses notes de version officielles du 8 octobre 2026.

Alerte Google Tag Manager : nouvel événement gtag.config

Qu’est-ce qui change exactement dans Google Tag Manager ?

Google annonce deux évolutions liées au fonctionnement de Google Tag et de GTM.

La première concerne l’initialisation des conteneurs chargés avec gtm.js. Désormais, leur initialisation intervient au chargement du conteneur, indépendamment des commandes gtag('config') présentes sur la page.

L’objectif annoncé est d’uniformiser le comportement des implémentations et d’améliorer leur fiabilité.

La seconde évolution est celle qui mérite une attention particulière : les commandes gtag('config') apparaissent désormais dans la chronologie du dataLayer sous la forme d’événements gtag.config.

Pour comprendre, prenons une commande classique :

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.

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

Cette commande sert à configurer une destination Google Tag, ici identifiée par un ID de mesure GA4.

Avec la mise à jour, son traitement peut désormais faire apparaître un événement nommé gtag.config dans la chronologie de GTM.

Il faut bien distinguer trois choses :

La commande gtag('config'), qui configure une destination.
L’événement gtag.config, désormais visible dans le traitement du dataLayer.
Les balises GTM éventuellement déclenchées par cet événement.

L’apparition de gtag.config ne signifie pas qu’un événement du même nom est automatiquement envoyé à GA4. C’est d’abord un événement visible dans le fonctionnement de GTM. Un envoi supplémentaire vers un outil de mesure dépend des balises et des déclencheurs configurés dans le conteneur.

Pourquoi le nouvel événement `gtag.config` peut poser problème ?

Dans GTM, les déclencheurs de type « Événement personnalisé » permettent d’activer des balises à partir du nom des événements détectés.

Par exemple, je peux créer un déclencheur qui écoute uniquement l’événement purchase pour envoyer une transaction vers GA4.

Mais je peux aussi utiliser une expression régulière pour écouter plusieurs événements.

Un cas courant consiste à configurer un déclencheur avec :

.*

Cette expression régulière correspond à n’importe quelle séquence de caractères, y compris une chaîne vide. Dans un déclencheur d’événement personnalisé, elle peut donc intercepter un très grand nombre de noms d’événements.

C’est pratique pour centraliser des traitements, alimenter des outils de contrôle ou gérer des événements à partir d’une convention de nommage.

Mais c’est aussi très large.

Avec l’arrivée de gtag.config, ces déclencheurs peuvent désormais intercepter un événement supplémentaire qu’ils ne rencontraient pas auparavant. C’est précisément le risque signalé par Google.

Exemple concret : une balise GA4 qui se déclenche une fois de trop

Imaginons une implémentation où les événements métier sont transmis dans le dataLayer :

dataLayer.push({
  event: 'generate_lead',
  form_type: 'contact'
});

Dans GTM, une balise GA4 utilise un déclencheur générique .* et une variable intégrée {{Event}} pour déterminer le nom de l’événement à envoyer.

La configuration peut ressembler à ceci :

Élément	Configuration
Balise	Événement GA4
Nom de l’événement GA4	`{{Event}}`
Déclencheur	Événement personnalisé
Nom d’événement du déclencheur	`.*`
Correspondance regex	Activée

Avant la mise à jour, cette balise pouvait traiter les événements métier prévus par l’implémentation.

Désormais, si le nouvel événement gtag.config apparaît et satisfait les autres conditions, cette même balise peut aussi s’activer.

Dans cet exemple, elle peut envoyer à GA4 un événement supplémentaire portant le nom gtag.config.

Cela ne signifie pas automatiquement que les conversions métier seront comptabilisées deux fois. En revanche, si une balise de conversion utilise ce même déclencheur générique, elle peut être activée à tort.

Quels sont les risques pour vos données Analytics et Ads ?

Tout dépend des balises associées à vos déclencheurs.

Voici les principaux scénarios que je vérifierais.

Configuration GTM	Risque potentiel
Balise GA4 avec nom d’événement dynamique `{{Event}}`	Envoi d’un événement supplémentaire `gtag.config`
Balise GA4 avec nom d’événement fixe	Envoi supplémentaire de cet événement fixe
Balise de conversion Google Ads	Déclenchement d’une conversion sans action métier correspondante
Balise HTML personnalisée	Exécution supplémentaire d’un script
Balise de journalisation ou de monitoring	Apparition de nouveaux événements dans les logs
Déclencheur ciblant uniquement `purchase`	Aucun effet direct lié à `gtag.config`

Ces conséquences sont des scénarios techniques possibles, pas des incidents systématiquement constatés sur tous les sites.

Google précise que les déclencheurs génériques peuvent activer des balises supplémentaires. Il ne dit pas que toutes les implémentations GA4 vont générer des doublons.

Et c’est une distinction importante : un déclenchement supplémentaire, un appel réseau supplémentaire et une conversion effectivement comptabilisée sont trois choses différentes.

Comment vérifier si votre conteneur GTM est concerné ?

Je commencerais par les déclencheurs, pas par les rapports GA4. Le problème se situe en amont, au moment où GTM décide d’activer les balises.

1. Identifier les déclencheurs utilisant des expressions régulières génériques

Dans Google Tag Manager, ouvrez Déclencheurs, puis recherchez les déclencheurs de type « Événement personnalisé » utilisant une correspondance avec expression régulière.

Vérifiez particulièrement les expressions :

.*

Mais aussi les expressions très larges, par exemple :

^(.*)$

ou :

^.+$

Ces expressions peuvent toutes correspondre à gtag.config.

Attention, toutes les expressions régulières ne sont pas problématiques. Un déclencheur limité à ^(purchase|generate_lead)$ ne correspond pas au nouvel événement.

Le problème vient des règles trop permissives.

2. Contrôler les déclenchements dans le mode Aperçu GTM

Ouvrez le mode Aperçu avec Tag Assistant, puis parcourez votre site.

Si des commandes gtag('config') sont exécutées et que le nouvel événement apparaît, recherchez gtag.config dans la chronologie des événements.

Sélectionnez cet événement et examinez les balises associées.

Deux informations sont particulièrement intéressantes :

Tags Fired : les balises effectivement déclenchées.
Tags Not Fired : les balises qui n’ont pas été déclenchées.

La présence de gtag.config dans la chronologie ne suffit pas à conclure à un dysfonctionnement.

En revanche, si une balise de conversion se déclenche sur cet événement sans justification fonctionnelle, vous avez identifié une configuration à corriger.

3. Vérifier les appels réseau envoyés

Le mode Aperçu permet de repérer un déclenchement, mais je recommande de compléter le contrôle avec l’onglet Réseau des outils de développement du navigateur.

Pour GA4, recherchez notamment les requêtes de collecte vers les endpoints Google Analytics, puis examinez le nom des événements transmis.

Pour Google Ads, vérifiez que les requêtes de conversion correspondent bien aux actions métier attendues.

L’objectif est de distinguer un simple événement interne GTM d’une véritable collecte supplémentaire.

Comment empêcher `gtag.config` de déclencher vos balises ?

La solution dépend de l’architecture de votre conteneur.

Si vous avez réellement besoin d’un déclencheur générique, vous pouvez exclure le nouvel événement de son périmètre.

Une première solution consiste à utiliser une expression régulière avec exclusion :

^(?!gtag.config$).*

Cette expression correspond aux noms d’événements autres que gtag.config.

Le fonctionnement est simple :

^ indique le début de la chaîne.
(?!gtag.config$) exclut exactement gtag.config.
.* autorise les autres noms d’événements.

Autre possibilité, conserver le déclencheur générique et ajouter une condition :

Paramètre	Valeur
Type de déclencheur	Événement personnalisé
Nom d’événement	`.*`
Correspondance regex	Activée
Déclenchement	Certains événements personnalisés
Variable	`{{Event}}`
Opérateur	Ne correspond pas à l’expression régulière
Valeur	`^gtag.config$`

Cette approche exclut explicitement le nouvel événement sans modifier la règle générale de détection.

Google documente les filtres des déclencheurs et les opérateurs utilisant des expressions régulières.

Il existe également une autre solution : ajouter une exception de déclenchement aux balises concernées.

Dans GTM, une exception permet de bloquer l’exécution d’une balise même lorsque son déclencheur principal est satisfait.

Personnellement, je privilégierais une correction au niveau du déclencheur générique, lorsque celui-ci est partagé par plusieurs balises et que l’exclusion est valable pour toutes.

C’est plus lisible et cela évite de multiplier les exceptions sur chaque balise.

Encore faut-il vérifier les autres événements nécessaires à l’implémentation. Je déconseille de remplacer une regex générique sans examiner ses usages actuels.

Faut-il modifier toutes les implémentations GTM ?

Non.

Si vos balises utilisent des déclencheurs précis, fondés sur des événements métier correctement nommés, ce changement peut n’avoir aucun impact sur votre collecte.

Un déclencheur qui attend add_to_cart, purchase ou generate_lead ne se déclenchera pas simplement parce que gtag.config apparaît dans la chronologie.

Le sujet concerne surtout les conteneurs qui utilisent des déclencheurs génériques pour centraliser la collecte, exécuter des scripts ou automatiser le traitement d’événements.

Je vérifierais également les implémentations qui combinent des commandes gtag() directement dans le code du site et un conteneur GTM. C’est précisément autour de cette coexistence que Google annonce son changement de comportement.

Dans ses notes de version, Google rappelle aussi que les pages utilisant du code de configuration gtag() doivent disposer d’une installation correcte de Google Tag (gtag.js). Cela ne signifie pas qu’il faut ajouter systématiquement gtag.js à tous les sites équipés de GTM : il faut d’abord examiner la configuration existante.

Une modification de GTM peut affecter votre tracking sans nouvelle publication

C’est le point que je retiens de cette mise à jour.

On a souvent tendance à considérer qu’une implémentation est stable tant que personne ne publie de nouvelle version du conteneur.

Mais GTM dépend aussi d’un environnement technique qui évolue : les scripts de Google, les mécanismes de traitement des commandes et les événements disponibles.

Cette évolution du 8 octobre en est un bon exemple. Google introduit un nouvel événement visible dans le dataLayer et, mécaniquement, les déclencheurs qui écoutent tous les événements peuvent réagir différemment.

Je recommande donc de vérifier les déclencheurs génériques, de contrôler leurs balises associées et de tester les principaux parcours métier en mode Aperçu.

Ce n’est pas une raison pour revoir toute votre implémentation. C’est une bonne raison pour vérifier qu’elle ne repose pas sur des conditions de déclenchement trop larges.

Un tracking fiable, ce n’est pas seulement une collecte qui fonctionne aujourd’hui. C’est une collecte dont on maîtrise les conditions de déclenchement, y compris lorsque les outils évoluent.

FAQ — Nouvel événement `gtag.config` dans Google Tag Manager

Questions courantes pour les administrateurs GTM et les responsables du tracking.

À quoi correspond le nouvel événement gtag.config dans GTM ?

Il correspond à la visibilité des commandes gtag('config') dans la chronologie des événements du dataLayer. Depuis la mise à jour du 8 octobre 2026, ces commandes peuvent apparaître sous la forme d’événements gtag.config dans GTM.

Est-ce que gtag.config envoie automatiquement un événement à GA4 ?

Non. Sa présence dans GTM ne signifie pas qu’un événement est automatiquement transmis à GA4. Un envoi supplémentaire peut se produire si une balise GA4 est activée par cet événement.

Quels déclencheurs GTM sont concernés ?

Principalement les déclencheurs « Événement personnalisé » utilisant des expressions régulières génériques comme .*. Les expressions plus larges qui correspondent également à gtag.config peuvent aussi être concernées.

Cette mise à jour peut-elle créer des conversions en double ?

C’est possible selon la configuration des balises. Si une balise de conversion se déclenche sur gtag.config alors qu’elle ne devrait pas, un envoi supplémentaire peut se produire. Ce n’est toutefois pas une conséquence automatique de la mise à jour.

Comment exclure gtag.config dans GTM ?

Vous pouvez ajouter une condition d’exclusion sur la variable {{Event}}, avec l’opérateur « Ne correspond pas à l’expression régulière » et la valeur ^gtag.config$. Testez ensuite le résultat en mode Aperçu.

Faut-il publier une nouvelle version de GTM ?

Uniquement si votre audit révèle une configuration à modifier. L’apparition de gtag.config ne justifie pas, à elle seule, une nouvelle publication.

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.