Claude et Google Tag Manager : auditer un conteneur

Auditer un conteneur Google Tag Manager revient à chercher les balises en pause, les déclencheurs que plus aucune balise n'utilise et les conversions sans documentation. L'API de Tag Manager expose toute cette configuration en JSON, ce qui permet de la faire lire par Claude. Dans les pages que nous avons consultées le 11 octobre 2026 (l'accueil développeurs de Tag Manager, la présentation de l'API, le guide du développeur, l'autorisation, les limites et les références REST), Google ne mentionne aucun serveur MCP pour Tag Manager. La voie documentée est l'API v2 et un script que Claude Code écrit pour vous. Ce guide décrit ce que l'API renvoie, les portées et les quotas, la demande à faire à Claude Code, huit contrôles à dérouler sur le fichier obtenu et les garde-fous.

Les faits cités viennent de la documentation de Google (Tag Manager API) et de celle d'Anthropic (Claude Code), consultées le 11 octobre 2026. La page des limites indique une dernière mise à jour au 16 juillet 2026 : relisez-la avant de vous appuyer sur un quota.

Ce que l'API Tag Manager expose

D'après la présentation de l'API, les ressources sont hiérarchiques : un compte contient des conteneurs, un conteneur contient des espaces de travail, et un espace de travail contient les balises, déclencheurs, variables et dossiers. Un espace de travail permet plusieurs modifications concurrentes d'un conteneur. Une fois ces modifications faites, on crée une version, que l'on peut prévisualiser puis publier.

Pour un audit, la méthode utile est versions:live, qui renvoie la version publiée d'un conteneur, c'est-à-dire ce qui tourne réellement sur le site. La ressource ContainerVersion contient d'un seul bloc les listes tag, trigger, variable, folder et builtInVariable, ainsi que zone, customTemplate, client, gtagConfig et transformation, d'après la référence de la ressource. Lire la version publiée plutôt qu'un espace de travail évite de mélanger la configuration en production et des modifications en cours. La méthode create_version d'un espace de travail, elle, crée une version à partir de ses entités, supprime l'espace de travail et fait de la nouvelle version la version de base : cette opération n'a rien à faire dans un script d'audit.

GET tagmanager.googleapis.com/tagmanager/v2/accounts
GET tagmanager.googleapis.com/tagmanager/v2/{parent}/containers
GET tagmanager.googleapis.com/tagmanager/v2/{parent}/versions:live

La première liste les comptes auxquels l'utilisateur a accès. Dans la deuxième, parent prend la forme accounts/{compte} ; dans la troisième, accounts/{compte}/containers/{conteneur}. Les adresses sont données ici sans le préfixe https. Les listes sont paginées : la réponse contient un nextPageToken à renvoyer dans pageToken. Google indique que l'identifiant du compte figure dans l'adresse de l'interface web, après /accounts/.

Autorisation et quotas

La page d'autorisation précise que l'API n'accepte que OAuth 2.0 et qu'il faut enregistrer l'application dans la console Google API. Elle liste sept portées.

Les références de accounts.list, containers.list et versions:live acceptent tagmanager.readonly. C'est la seule portée à demander pour un audit.

La page des limites fixe 10 000 requêtes par projet et par jour et 0,25 requête par seconde et par projet, soit 25 requêtes sur une fenêtre glissante de 100 secondes. Un dépassement renvoie une erreur 403, les quotas journaliers se renouvellent à minuit PST et une hausse se demande depuis la console API. Auditer un conteneur par sa version publiée coûte une requête de liste des comptes, une par compte pour les conteneurs et une par conteneur. Le plafond journalier se voit donc rarement ; la limite de 25 requêtes par 100 secondes compte surtout pour un script qui boucle sur beaucoup de conteneurs.

Faire écrire le script par Claude Code

Depuis un dossier de projet, avec les identifiants OAuth dans un dossier secrets/, une demande type :

Écris scripts/gtm_pull.py qui interroge l'API Tag Manager v2 avec la seule portée tagmanager.readonly.
Liste les comptes, puis les conteneurs de l'identifiant de compte passé en argument (pagination avec pageToken).
Pour chaque conteneur demandé, appelle versions:live et écris la réponse brute dans data/gtm/<conteneur>-<date>.json.
Respecte au plus 25 requêtes par fenêtre de 100 secondes et attends avant de réessayer après un 403 de quota ; arrête-toi sur un 403 d'accès.
Lis les identifiants dans secrets/, ne les affiche jamais.

Relisez le script avant de l'exécuter : la portée demandée, le dossier d'écriture et la gestion des erreurs se vérifient en quelques lignes. Le guide du développeur de Google recommande d'ailleurs de tester tout code qui crée, modifie ou supprime des entités sur un compte de test, et prévient que les opérations destructrices de l'API se font sans avertissement, sans confirmation et sans annulation. Notre script n'écrit rien dans Tag Manager, mais le réflexe vaut pour toute suite que vous lui ajouteriez.

Huit contrôles à demander sur le fichier

Le fichier est local : Claude l'agrège avec des scripts, sans rappeler l'API. Les contrôles ci-dessous s'appuient sur des champs que la référence de la ressource Tag documente. Le choix des huit contrôles est le nôtre.

1. « Liste les balises dont paused vaut true. » Google définit ce champ comme l'indicateur d'une balise en pause, qui ne se déclenche plus.
2. « Liste les balises dont firingTriggerId est vide. » Une balise se déclenche quand l'un des déclencheurs listés est vrai : sans déclencheur, elle ne part pas sur ses propres déclencheurs (vérifiez d'abord qu'une autre balise ne l'appelle pas comme balise de configuration ou de nettoyage : champs setupTag et teardownTag).
3. « Liste les balises dont scheduleEndMs est dans le passé. » Les champs scheduleStartMs et scheduleEndMs sont des horodatages en millisecondes qui programment une balise : une fenêtre échue indique une campagne terminée.
4. « Liste les déclencheurs et les variables que ni une balise ni un autre déclencheur ne référencent. » Le calcul est un croisement d'identifiants fait par le script : l'API ne fournit pas d'indicateur d'inutilisation.
5. « Regroupe les balises par type et signale celles dont tu ne reconnais pas le type. » Le champ type est le type de balise ; la documentation n'en liste pas les valeurs, c'est donc à vous de valider les types inattendus.
6. « Liste les balises dont consentSettings.consentStatus vaut notSet. » Les valeurs documentées sont notSet (aucun réglage défini), notNeeded et needed. Si le statut est needed, l'exécution vérifie que les types de consentement listés dans consentType ont été accordés. Une balise sans réglage explicite se discute au cas par cas avec votre politique de consentement.
7. « Liste les balises dont tagFiringOption vaut unlimited. » Cette valeur autorise une balise à se déclencher plusieurs fois par événement, alors que oncePerEvent et oncePerLoad la limitent. Sur une balise de conversion, ce réglage est à examiner.
8. « Liste les balises dont le champ notes est vide. » Ce champ sert à noter comment appliquer la balise ; l'absence de notes ne dit rien du bon fonctionnement, mais elle mesure ce que le prochain intervenant devra deviner.

Un champ de plus aide à comprendre une balise absente de vos tests : liveOnlylimite une balise à l'environnement publié, donc hors prévisualisation et hors mode débogage.

Pour suivre l'évolution d'un conteneur, datez chaque export et demandez à Claude de comparer deux fichiers : balises ajoutées, retirées, mises en pause. L'historique reste chez vous, consultable sans rappeler l'API. Les articles sur le server-side tagging et sur les conversions améliorées indiquent ce qu'un conteneur sain doit contenir pour la mesure des campagnes.

Ce que le JSON ne dit pas

• Il décrit la configuration, pas ce qui se déclenche sur les pages. Cette phrase est notre lecture de la documentation, qui présente l'API comme un accès aux données de configuration : la vérification d'un déclenchement réel passe par la prévisualisation de Tag Manager et par vos outils de contrôle réseau.
• Il ne dit rien de la qualité des données reçues par Google Ads ou GA4. Pour cela, voir notre guide sur le MCP GA4 et celui sur l'écart de conversions entre Google Ads et GA4.
• Il ne couvre que les conteneurs auxquels le compte autorisé a accès. Un conteneur géré par un autre prestataire sans droit de lecture pour vous n'apparaîtra pas.

Les garde-fous

• Portée tagmanager.readonly uniquement, dans le script comme dans le projet OAuth.
• Identifiants hors du dépôt et hors de la portée de Claude. La documentation des permissions prévoit des règles Read en refus pour un chemin (par exemple Read(./secrets/**)) et des règles Bash avec une commande suivie d'un astérisque.
• Un script relu avant exécution, et lancé par une commande précise plutôt qu'un shell ouvert.
• Les exports contiennent la configuration complète du conteneur d'un client : traitez-les comme un document client et vérifiez que votre contrat autorise leur envoi à Claude.

{
  "permissions": {
    "allow": ["Bash(python3 scripts/gtm_pull.py *)"],
    "deny": ["Read(./secrets/**)"]
  }
}

La documentation signale que les règles de refus s'appliquent aux outils de lecture de Claude et aux commandes de fichiers qu'elle reconnaît, mais pas à une commande qui lit des fichiers sans les nommer, comme un grep -r lancé depuis le dossier concerné. Le script que vous avez relu et lancé lit le dossier des identifiants par construction : la règle protège contre une lecture directe par Claude, pas contre ce que fait ce code.

Par où commencer

1. Créer un projet dans la console Google API, activer l'API Tag Manager et générer des identifiants OAuth.
2. Faire écrire gtm_pull.py par Claude Code avec la seule portée de lecture, puis le relire.
3. Exporter la version publiée d'un conteneur de test et ouvrir le JSON à la main pour repérer les champs.
4. Poser les deux règles de permission, puis dérouler les huit contrôles sur le fichier.
5. Valider chaque résultat dans l'interface de Tag Manager avant de corriger quoi que ce soit.

Questions fréquentes sur Claude et Google Tag Manager

Sources consultées le 11 octobre 2026

• Google : Tag Manager pour les développeurs, présentation de l'API, guide du développeur, autorisation, limites et quotas, accounts.list, containers.list, versions.live, ressource ContainerVersion, workspaces.create_version, ressource Tag
• Anthropic : permissions de Claude Code