La fusion GTM et Google Tag : une seule architecture
Jusqu’ici, GTM et le Google Tag (ce fameuxgtag.js) coexistaient comme deux produits distincts. Vous déployiez GTM sur votre site, puis à l’intérieur de GTM vous configuriez un tag Google Analytics, un tag Google Ads, un Conversion Linker… chacun chargeant sa propre librairie JavaScript.
Avec la mise à jour 2026, les containers GTM deviennent des Google Tags. Les produits fusionnent sous une architecture unifiée.
Concrètement : vos tags Google existants (GA4, Google Ads Remarketing, Conversion Linker) deviennent des Destinations de votre container. Au lieu que chaque tag charge son propre fichier gtag.js, toutes les Destinations partagent un seul fichier JavaScript chargé par le container.
Ce que ca change sur un setup client type :
Sur les comptes que nous gérons chez Elorion, un setup standard comprend un Google Tag GA4, des tags GA4 Event, un tag Google Ads Conversion Tracking, un Conversion Linker et un tag Remarketing. Aujourd’hui, ces éléments chargent plusieurs ressources réseau distinctes à chaque page vue. Après migration vers les Destinations, c’est un seul fichier, une seule requête. La page se charge plus vite, les données arrivent plus proprement.
Infographie
De plusieurs gtag.js a une architecture Destinations
Chaque tag Google chargeait sa propre librairie JavaScript. Avec les Destinations, un seul fichier JS gere tout.
Avant
Container GTM
gtm.js
↓ ↓ ↓
gtag.js
GA4
1 requete
gtag.js
Google Ads
1 requete
gtag.js
Remarketing
1 requete
3 fichiers JS charges
Bande passante x3
Parsing JS repete
Risque de collision
Latence accrue
Parsing JS repete
Risque de collision
Latence accrue
→
Apres — ete 2026
Container GTM
1 seul fichier JS
↓ ↓ ↓
Destination
GA4
Destination
Google Ads
Destination
Remarketing
1 seul fichier JS partage
Bande passante ÷3
Parsing JS unique
Parametres centralises
Page plus rapide
Parsing JS unique
Parametres centralises
Page plus rapide
Cliquer sur un element pour en savoir plus
Nouvelle architecture DestinationsAncienne architecture
Les paramètres Google Tag entrent dans GTM
Voilà un changement qui va simplifier le quotidien de quiconque gère des comptes sérieusement. Aujourd’hui, quand vous configurez le cross-domain tracking, les paramètres de consentement ou l’anonymisation des données pour votre Google Tag, vous devez naviguer dans deux interfaces distinctes : GTM pour les tags, et GA4 (Admin > Data Streams > Configure) pour les paramètres du tag. Une même configuration, deux endroits à maintenir. À partir de mai 2026, les paramètres essentiels du Google Tag sont accessibles directement dans le menu GTM. Une seule interface, une seule source de vérité. Les paramètres s’appliquent à toutes les Destinations, avec la possibilité de surcharges par Destination si nécessaire.Infographie
Les parametres Google Tag entrent dans GTM
Avant mai 2026, la configuration demandait deux interfaces. Apres, tout est dans GTM.
Avant
GTM
Tags
Triggers
Variables
↓ separes
GA4 — Admin
Cross-domain
Anonymisation IP
Param. consentement
Config Google Tag
2 interfaces a maintenir
→
Apres — mai 2026
GTM
Tags
Triggers
Variables
Cross-domain
Anonymisation IP
Param. consentement
Config Google Tag
Surcharges par Destination
1 seule source de verite
GA4 — Admin
config tag retiree
↓ en savoir plus
Cliquer sur un element pour en savoir plus
Interface apres mai 2026Interface avant
Le Visual Event Builder : fini les tags créés un par un
C’est probablement la fonctionnalité qui va changer le plus le rythme de travail sur les nouveaux setups. Jusqu’ici, configurer le tracking d’un clic sur un numéro de téléphone nécessitait de créer manuellement un déclencheur (trigger), de définir les conditions de déclenchement, puis de créer le tag GA4 Event ou Google Ads Conversion qui lui est associé. Multiplié par le nombre d’actions à tracker sur un site (clics tel, envois de formulaire, clics vers la réservation, téléchargements PDF…), ca représente facilement une heure de configuration par client. Le Visual Event Builder change cette logique. Vous naviguez sur le site de votre client en mode prévisualisation, vous interagissez avec les éléments à tracker, et GTM génère automatiquement les tags, déclencheurs et variables correspondants. Ce qui prenait trente à soixante minutes devient une affaire de quelques minutes. La fonctionnalité est annoncée pour l’été 2026. Elle ne remplace pas le jugement d’un expert (il faudra toujours valider la pertinence de ce qui est généré), mais elle supprime la partie mécanique et répétitive du setup.Pour les setups server-side : les Destinations s’appliquent aussi
Pour les clients qui bénéficient d’un tracking server-side via SirData, l’architecture évolue dans la même direction. Aujourd’hui, un container sGTM comprend plusieurs clients qui reçoivent les hits du container web et les routent vers les tags correspondants : GA4 Measurement Protocol, Google Ads Conversion, Facebook CAPI. Avec les Destinations, ces clients deviennent des points de sortie du container, avec moins de couches intermédiaires à configurer. Le résultat attendu : des données plus fiables entre le container web et le server-side, et une configuration simplifiée pour les nouveaux setups. Si vous ne savez pas encore pourquoi le tracking server-side est devenu indispensable, cet article l’explique en détail.Ce qui ne change pas
Avant de répondre à la question que tout le monde se pose : non, upgrader votre container ne va pas déclencher des envois de données vers GA4 ou Google Ads sans votre configuration explicite. La migration est opt-in, elle se fait container par container, avec prévisualisation, test et possibilité de retour arrière à tout moment. Les tags non-Google (Facebook CAPI, TikTok Pixel, Sirdata, balises Custom HTML) restent entièrement supportés. L’écosystème ne se referme pas sur les produits Google. Les configurations existantes restent fonctionnelles. Il n’y a pas d’urgence à migrer.Quand migrer ?
La recommandation que nous donnerons à nos clients : attendre que les premiers retours terrain soient disponibles (courant été 2026), puis commencer par un container à faible criticité pour valider le comportement avant de migrer les comptes principaux. Le Visual Event Builder et les Destinations directes (sans Google Tag intermédiaire) ne sont pas encore déployés à date de publication de cet article. Ce sont des fonctionnalités annoncées pour l’été 2026. Nous mettrons cet article à jour dès que ce sera disponible.Notre lecture
Ce que Google fait avec cette mise à jour, c’est réduire la friction entre la configuration du tracking et son exploitation dans les campagnes. Moins de tags redondants, moins d’interfaces à croiser, moins d’erreurs de configuration possibles. Pour les annonceurs, ca se traduit en données plus complètes et en campagnes mieux optimisées. Pour les agences, ca se traduit en setups plus rapides et plus robustes. Chez Elorion, nous suivons ce déploiement de près. Si vous avez des questions sur l’impact de ces changements sur vos comptes Google Ads ou sur votre setup de tracking, contactez-nous. Vous trouverez aussi des réponses aux questions fréquentes sur Google Ads sur notre blog.Sources : Annonce officielle Google Tag Manager, GA4 Optimizer – GTM 2026, GTM Changes May 2026 – Duga Digital Article publié le 11 mai 2026. Mis à jour dès déploiement des fonctionnalités été 2026.