Google a modifié Google Tag Manager deux fois en octobre 2026. Le premier changement, du 8 octobre, s'applique déjà à tous les conteneurs, sans que personne n'ait rien touché. Le second, du 12 octobre, est une mise à jour de Google Tag Manager proposée, qu'il faut accepter soi-même.
Aucun des deux ne casse un site. Le risque est plus discret : des conversions comptées en double, des balises qui partent sans raison, et des chiffres qui dérivent sans message d'erreur. Si votre site utilise Tag Manager (c'est le cas de beaucoup de sites installés par un prestataire il y a quelques années), voici les deux réglages à vérifier, et ce que nous recommandons de faire.
Google Tag Manager : ce qui a changé en octobre
| Date | Changement | Actif sans rien faire ? | Risque concret |
|---|
| 8 octobre 2026 | Les commandes gtag('config') deviennent des événements visibles gtag.config | Oui | Balises déclenchées en trop, conversions gonflées |
| 8 octobre 2026 | Le conteneur démarre sans attendre ces commandes | Oui | Réglages ignorés sur les pages sans le script Google tag (gtag.js) |
| 12 octobre 2026 | Balises de destination : le conteneur envoie directement les données à Google Analytics, Google Ads et Floodlight | Non, mise à niveau à valider | Faible si la migration est testée, réel si elle est publiée à l'aveugle |
Changement n° 1 : des balises qui peuvent partir en trop
Un peu de vocabulaire d'abord. Tag Manager fonctionne avec une file d'attente appelée dataLayer : le site y dépose des événements (« page vue », « achat », « formulaire envoyé »), et des déclencheurs décident quelles balises partent à chaque événement. Une balise, c'est le petit bout de code qui envoie l'information à Google Analytics, Google Ads ou Meta.
Depuis le 8 octobre 2026, selon les notes de version officielles de Google, chaque commande gtag('config') présente dans le code du site apparaît dans cette file sous la forme d'un événement nommé gtag.config. Avant, ces commandes configuraient la mesure en coulisses, sans laisser de trace dans la file.
Le problème vient des déclencheurs « attrape-tout ». Beaucoup de conteneurs ont un déclencheur de type événement personnalisé avec l'expression .*, qui signifie « n'importe quel événement ». Google prévient lui-même que ce déclencheur s'exécute sur tous les événements détectés, y compris ceux que Tag Manager et la balise Google émettent automatiquement. Le nouvel événement gtag.config entre donc dans le lot, et les balises rattachées partent une fois de plus par commande de configuration.
Si la balise concernée est un simple outil de diagnostic, c'est une ligne de plus dans un journal. Si c'est une balise de conversion ou de remarketing, c'est plus gênant : si rien ne dédoublonne ces envois, les conversions montent alors que les ventes ne bougent pas, et les algorithmes d'enchères de Google Ads ou de Meta apprennent sur des conversions qui n'ont jamais eu lieu. Aucune source n'a encore chiffré l'ampleur du phénomène ; le signe à chercher est une hausse des conversions à partir du 8 octobre que vos commandes ou vos demandes de devis ne confirment pas.
Le second effet : la configuration sans script Google
Le même jour, Google a précisé que tout conteneur Tag Manager démarre désormais au chargement, sans tenir compte des commandes gtag('config'). Certains sites contenaient une ligne de configuration écrite en dur, sans charger le script Google tag (gtag.js) qui la lit. Ce montage n'a jamais été documenté par Google, mais il existe. La consigne officielle est claire : une page qui garde du code de configuration doit charger gtag.js. Sinon, il faut déplacer ces réglages dans le conteneur.
La vérification, en un quart d'heure
- Listez vos déclencheurs. Dans Tag Manager, ouvrez « Déclencheurs » et repérez les déclencheurs « Événement personnalisé » qui utilisent une expression régulière, en particulier
.*.
- Regardez ce qui y est attaché. Pour chacun, notez les balises rattachées. Commencez par les balises de conversion, de remarketing et les pixels tiers.
- Ouvrez le mode Aperçu. Chargez une page du site : si un événement
gtag.config apparaît dans la colonne de gauche, cliquez dessus et regardez quelles balises se sont déclenchées sur cet événement. Il ne devrait y en avoir aucune.
- Comparez avec la réalité. Mettez côte à côte les conversions par jour avant et après le 8 octobre, et les commandes, appels ou formulaires réellement reçus sur la même période.
- Annotez vos rapports à la date du 8 octobre, pour que personne ne prenne plus tard une hausse artificielle pour une bonne nouvelle.
La correction est simple : remplacer .* par la liste des événements réellement utiles, par exemple ^(purchase|generate_lead)$, comme le recommande l'analyse publiée par TrackingDesk. C'est aussi ce que Google conseille dans sa documentation des déclencheurs : une expression plus restreinte plutôt qu'un attrape-tout.
Changement n° 2 : la mise à jour des balises de destination
Jusqu'ici, pour envoyer des données à un produit Google, Tag Manager chargeait un script supplémentaire, gtag.js, avec ses propres réglages et ses propres accès. Google reconnaît dans ses notes du 12 octobre que ce montage pouvait retarder l'envoi des mesures et rendre le diagnostic plus difficile.
Désormais, un conteneur « optimisé » envoie directement les données à Google Analytics, Google Ads et Floodlight, sans script supplémentaire. Les réglages sont regroupés dans un nouvel onglet de paramètres du conteneur, et la relation entre chaque balise et sa destination devient lisible. Selon l'analyste Simo Ahava, l'ancienne balise Google passe au statut d'héritage, tout comme l'éditeur de liens de conversion (Conversion Linker), dont les nouvelles balises reprennent le rôle.
Ce n'est pas automatique. Un bandeau propose la mise à niveau, un assistant guide la consolidation, et rien n'est publié tant que vous n'avez pas ajouté les changements à l'espace de travail puis cliqué sur « Envoyer ». Google indique que les balises d'événement et les déclencheurs existants sont conservés.
Faut-il migrer ?
Oui, mais comme une vraie migration, pas comme une mise à jour de routine. Le gain est réel : un script de moins à charger, donc une page un peu plus légère, et un diagnostic plus clair. Mais un site dont la mesure a été bricolée au fil des ans peut réserver des surprises au moment de fusionner des réglages contradictoires.
Notre ordre de marche :
- D'abord le changement n° 1. Inutile de migrer un conteneur qui compte déjà mal.
- Ensuite, migrer dans une période calme. Pour une boutique, pas pendant le Black Friday ni les commandes de fin d'année : une erreur de mesure à ce moment-là coûte plus cher qu'un script en trop.
- Tester en mode Aperçu avant de publier, destination par destination si les réglages divergent.
- Noter la version de départ pour pouvoir revenir en arrière. Une précaution : Google signale que les permissions d'accès ne sont pas versionnées. Si la migration ouvre l'accès du conteneur à des personnes liées à vos comptes Google, ce point ne se défait pas en restaurant une version, il se règle dans les paramètres d'administration.
Ce que cela ne change pas
- Le consentement reste votre affaire. Les nouvelles balises tiennent compte du mode consentement de Google, et une option permet de retenir les envois tant que l'accord n'est pas donné (Simo Ahava et Stape la décrivent). Mais le bandeau de consentement, son paramétrage et vos choix restent à votre charge, et l'option ne concerne que les balises Google. Pour le détail, voir notre article sur le mode consentement sans casser la mesure.
- Le suivi côté serveur n'est pas remplacé. Selon Stape, ces changements peuvent simplifier la partie navigateur, mais ne réduisent pas en eux-mêmes le volume envoyé à un conteneur serveur. Si vous en avez un, vérifiez simplement que rien ne casse après la migration. Ce que le suivi serveur récupère, nous l'avons détaillé dans cet article.
- Meta, TikTok ou Pinterest ne sont pas concernés. Les balises de destination ne couvrent que les produits Google. Vos autres pixels se gèrent comme avant.
Que faire selon votre situation
| Votre situation | Action | Urgence |
|---|
| Vous ne savez pas si votre site utilise Tag Manager | Demandez à votre prestataire, ou cherchez « GTM- » dans le code source d'une page | Cette semaine |
Tag Manager avec des déclencheurs .* reliés à des conversions | Restreindre les déclencheurs, puis comparer conversions et ventes réelles depuis le 8 octobre | Haute |
Code gtag('config') sur le site sans script gtag.js | Ajouter gtag.js ou déplacer la configuration dans le conteneur | Haute |
| Conteneur propre, bandeau de mise à niveau affiché | Migrer vers les balises de destination, en période calme, après test | Moyenne |
| Boutique Shopify avec l'application Google, sans ancien code en dur | Vérifier qu'aucune balise Tag Manager ne double les achats déjà envoyés par l'application | Moyenne |
Ce dernier cas rejoint un piège que nous avions décrit à propos des ventes GA4 qui augmentent toutes seules sur Shopify : quand deux chemins envoient le même achat, le chiffre monte, pas le chiffre d'affaires.
Ce que nous en retenons
Une mesure ne se juge pas à l'absence d'erreur, elle se vérifie contre la réalité : les commandes, les appels, les devis signés. Les changements d'octobre ne sont ni graves ni compliqués, mais ils rappellent qu'un conteneur Tag Manager est un morceau de logiciel qui vit, et qui dérive si personne ne le relit.
Si vous voulez savoir ce que valent vos chiffres, notre audit gratuit inclut un regard sur la mesure. Pour fiabiliser durablement le suivi des conversions, voyez notre offre de tracking server-side, notre agence web à La Réunion, ou contactez-nous directement.
Sources : notes de version de Google Tag Manager (8 et 12 octobre 2026) et aide officielle Tag Manager (optimisation du conteneur, déclencheurs d'événement personnalisé) ; Simo Ahava, « Optimized Tagging Experience For Google Tag Manager » (13 octobre 2026) ; TrackingDesk (10 octobre 2026) ; Stape, récapitulatif des mises à jour Google tag et GTM (mis à jour le 16 octobre 2026).
