Vous cliquez sur Submit dans Google Tag Manager, et là, surprise : le champ du nom de version affiche « Generating… », puis se remplit tout seul avec un titre et une description de vos changements. Depuis la mi-septembre 2026, GTM génère le nom et la description de chaque version avec l’IA, et c’est activé par défaut. Pratique sur le papier. Sauf que ce résumé de version IA n’est pas exhaustif : Simo Ahava l’a vu oublier 29 tags mis en pause dans une seule publication. Autant dire qu’un historique de versions rempli à l’aveugle par un modèle, ce n’est plus un outil d’audit, c’est une fausse sécurité.
Cet article montre où se trouve l’interrupteur, ce que l’IA rate concrètement, et surtout comment reprendre la main : une convention de nommage, un process de relecture, et des garde-fous pour le jour où des agents IA modifient aussi votre conteneur. Le tout dans le contexte plus large des refontes GTM 2026.
Ce qui a changé dans l’écran de publication
Le fonctionnement est simple. Après avoir fait vos modifications et prévisualisé votre workspace, vous cliquez sur Submit. L’overlay de publication apparaît, et le champ Version Name affiche désormais un label « Generating… » pendant que le modèle analyse les changements du workspace. Quelques secondes plus tard, vous obtenez un nom de version et une description listant ce qui a bougé.
Si vous modifiez encore le workspace ou annulez un changement, un bouton Suggest apparaît pour régénérer les métadonnées. Et si vous voulez couper le comportement, il y a un toggle « Suggested version summary » à basculer sur OFF, directement dans le flux de création de version.
Détail important pour les équipes : au 24 septembre 2026, la fonctionnalité n’apparaît toujours pas dans les release notes officielles de GTM (dernière entrée : 9 juillet 2026). Elle a été repérée entre le 9 et le 16 septembre par la communauté, activée sans annonce. Le toggle existe donc bien dans l’écran de publication, mais il n’y a pas, à ce jour, d’interrupteur global au niveau du compte pour l’imposer à tous vos conteneurs d’un coup.
Ce que le résumé de version IA voit, et ce qu’il rate
Voilà le vrai sujet. Le générateur ne produit pas une liste complète de tout ce qui a changé. Il se concentre sur ce qu’il juge « important », et ce jugement varie d’une génération à l’autre. Traduction : deux clics sur Suggest peuvent donner deux résumés différents pour le même workspace.
Pour vous faire une idée, prenez un cas de publication réaliste et comparez ce que vous avez réellement fait avec ce que l’IA mentionne :
| Changement effectué | Impact réel | Mentionné par l’IA ? |
|---|---|---|
Ajout d’un tag GA4 purchase | Élevé (nouvelle conversion) | Souvent |
| Correction de la valeur d’achat (variable) | Élevé (revenus faussés sinon) | Variable |
| Mise en pause de 29 tags | Très élevé (arrêt de collecte) | Raté dans le test de Simo Ahava |
| Modification d’une variable utilisée par 20 tags | Très élevé (effet en cascade) | Rarement détaillé |
| Changement d’un déclencheur de consentement | Critique (conformité) | À ne jamais présumer |
Le motif est clair : plus un changement est structurel et discret (pause, variable partagée, consentement), plus le risque qu’il passe à la trappe est grand. Or ce sont précisément les changements qui cassent une collecte en production. Un ajout de tag bien visible, l’IA le voit ; une variable pivot modifiée en silence, beaucoup moins.
Conclusion de praticien : traitez le résumé généré comme un brouillon de stagiaire enthousiaste. Utile pour démarrer, jamais à publier tel quel sur un conteneur de production.
Garder, corriger ou couper : l’arbre de décision
La bonne réponse dépend de votre contexte. Trois profils, trois réflexes.
Agence multi-clients
Gardez la génération activée, mais imposez la relecture systématique. Le résumé IA vous fait gagner du temps sur la première rédaction, ce qui est précieux quand vous publiez sur dix conteneurs par semaine. En revanche, personne ne valide une version sans avoir complété ce que l’IA a raté. La convention de nommage ci-dessous devient votre filet.
Entreprise avec contraintes de confidentialité
Prudence. Tant que Google ne documente pas précisément ce qui est envoyé au modèle et comment c’est traité, une équipe soumise à des exigences strictes (secteur régulé, données sensibles dans les noms de tags ou de variables) a tout intérêt à couper le toggle et à s’en tenir à un nommage manuel. On y revient dans la FAQ, mais la règle est simple : en l’absence de documentation officielle claire, on ne présume rien.
Freelance solo
Gardez-la, franchement. Le vrai risque quand on travaille seul, c’est de nommer ses versions « asdf » ou « test final v2 » et de galérer trois mois plus tard. Le résumé IA, même imparfait, vous force à documenter. Corrigez le nom en dix secondes et passez à autre chose.
Une convention de nommage qui tient la route
L’IA propose, l’humain valide. Pour que la relecture soit rapide et l’historique lisible, adoptez un format fixe. Celui-ci fonctionne bien :
2026-09-24 | GA4 | fix valeur purchase | ticket #123
Soit : date (tri chronologique immédiat), périmètre (GA4, Ads, consentement, sGTM…), action en clair (verbe + objet), référence (ticket, PR, nom). L’IA remplit souvent bien la partie « action » ; à vous d’ajouter le périmètre, la référence, et surtout les changements qu’elle a oubliés.
Un bon réflexe complémentaire : documentez le « pourquoi » du changement dans la description de version, pas seulement le « quoi ». Et si vos modifications touchent la structure des données, tenez à jour votre documentation dataLayer en parallèle (voir le guide dataLayer GTM). Le nom de version renvoie au ticket, le ticket renvoie à la spec. C’est cette chaîne qui rend un audit possible.
Gouvernance quand un agent IA publie à votre place
Nouveau contexte 2026 : les serveurs MCP pour GTM (Stape, Markifact, PaidSync côté Gemini) permettent à des agents IA de créer des tags, des déclencheurs, et parfois de publier. Combinez ça avec des résumés de version eux aussi générés par IA, et vous obtenez un conteneur où la machine écrit ET documente les changements. Sans garde-fou, l’historique devient illisible pour un humain.
Trois principes pour garder le contrôle :
- Workspaces dédiés. Faites travailler les agents dans un workspace séparé, jamais directement sur le workspace par défaut partagé. Vous isolez leurs changements et vous pouvez les relire d’un bloc.
- Séparer « Approve » et « Publish ». GTM distingue les permissions d’approbation et de publication (voir la doc Google sur les versions et approbations). Donnez à l’agent, au mieux, le droit de créer et d’approuver, jamais celui de publier seul en production.
- Relecture humaine obligatoire avant Publish. Un humain lit le diff, complète le résumé de version, valide. C’est le même principe que pour le résumé IA classique, appliqué à un contributeur qui, cette fois, n’est pas humain.
Si vous outillez des agents autour de la Google Marketing Platform, les articles sur le serveur MCP GA4 et sur Claude Code pour le data analyst donnent le cadre technique. Retenez surtout : plus vous automatisez la création, plus la traçabilité humaine des versions devient votre dernière ligne de défense. Ça vaut aussi pour vos conteneurs server-side, où une erreur passe encore plus facilement inaperçue côté serveur.
La checklist avant de publier
À dérouler à chaque version, que le résumé soit écrit par vous ou par l’IA :
- Le nom de version suit la convention (date, périmètre, action, référence).
- Tous les tags mis en pause ou supprimés sont listés explicitement.
- Toute variable partagée modifiée est signalée, avec les tags impactés.
- Les changements de consentement ou de conformité sont mentionnés en clair.
- Le résumé IA a été relu et complété, jamais publié brut.
- La description renvoie à un ticket ou une spec (le « pourquoi »).
- Sur un conteneur sensible, le toggle « Suggested version summary » est coupé si votre politique l’exige.
- Les changements d’un agent IA (le cas échéant) ont été relus par un humain.
- Un rollback est possible : la version précédente est propre et identifiable.
- Rien d’inattendu dans le diff (croisez avec votre routine d’audit GA4).
Bonus contexte : avec la fin de gtag('config') dans GTM au 2 octobre 2026, beaucoup d’équipes vont enchaîner les publications ces prochaines semaines (voir l’article dédié). Autrement dit, beaucoup de versions à documenter proprement, et un très mauvais moment pour laisser l’IA nommer vos publications sans relecture.
FAQ
Peut-on désactiver les résumés IA pour tout le compte ? Pas à ce jour. Le toggle « Suggested version summary » se trouve dans le flux de création de version, pas au niveau du compte. Il faut donc le gérer conteneur par conteneur, voire publication par publication. Vérifiez régulièrement les release notes GTM : un interrupteur global pourrait arriver.
Le contenu de mon conteneur est-il envoyé à un modèle IA ? La fonctionnalité génère le résumé à partir des changements du workspace, donc un traitement des données du conteneur a bien lieu. Au-delà de ça, Google ne documente pas publiquement les détails (quel modèle, quelle rétention, quel périmètre exact). En l’absence de documentation officielle, une équipe avec des contraintes de confidentialité devrait couper le toggle plutôt que de présumer. Ne citez que ce que Google confirme.
Une IA peut-elle publier une version à ma place ? Non, pas la fonctionnalité de résumé : elle se contente de proposer un nom et une description, vous gardez le clic final. Le seul cas où une IA publie réellement, c’est un agent MCP à qui vous avez explicitement accordé les droits de publication. D’où l’importance de séparer « Approve » et « Publish ».
Le fond du sujet tient en une phrase : l’IA est un excellent point de départ pour documenter vos versions, jamais le point d’arrivée. Gardez-la pour gagner du temps, relisez-la systématiquement, coupez-la quand la confidentialité l’exige, et ne laissez jamais un historique de versions, humain ou machine, mentir sur ce qui tourne vraiment en production.