Un agent IA qui audite votre GA4/GTM tout seul — voici comment le construire

L’audit GTM/GA4 est une tâche que tout le monde reporte. Pas parce qu’elle est difficile, mais parce qu’elle est ingrate : vérifier event par event, comparer les noms de paramètres, traquer les doublons de triggers… Un seul trigger dupliqué peut gonfler vos conversions, un paramètre manquant casse une audience, et un linker mal configuré fragmente vos sessions. On le sait. On ne le fait quand même pas assez souvent.

C’est exactement là qu’un agent IA change la donne — pas de manière abstraite, mais concrètement, en Python, avec des appels API réels.

Ce qu’un agent IA fait que ChatGPT ne fait pas

Un LLM classique répond à un prompt. Il s’arrête là. La plupart des IA aujourd’hui sont réactives : elles exécutent un prompt, complètent une tâche, et s’arrêtent. L’agentic AI introduit un modèle différent — des systèmes capables de poursuivre un objectif, enchaîner plusieurs actions, et s’ajuster en fonction des résultats.

La différence tient à trois choses. Mémoire, outils, et capacité de planification et de raisonnement — ce sont ces avancées qui font passer l’IA de simples LLMs isolés à une architecture agentique plus complexe.

Pour notre cas d’usage — auditer une propriété GA4 — ça se traduit par un agent capable de : appeler l’API GA4, analyser ce qu’il reçoit, décider quelle vérification faire ensuite, et produire un rapport structuré. Sans intervention humaine entre chaque étape.

Le pattern ReAct : le cerveau de l’agent

Le framework qui sous-tend la plupart des agents sérieux s’appelle ReAct — Reasoning + Acting. L’idée centrale est de pousser le LLM à générer non seulement une action, mais aussi le raisonnement qui la précède. Ce processus se déroule en boucle : le LLM génère d’abord une pensée sur la façon d’approcher l’objectif, puis une action à effectuer (comme utiliser un outil), et attend enfin une observation (le résultat de cette action). Cette observation est réinjectée dans le prompt pour le cycle suivant, permettant à l’agent de se corriger, collecter plus d’informations, ou décider qu’il en sait assez pour répondre.

Appliqué à l’audit GA4, ça donne ce flux logique :

OBJECTIF : Auditer la propriété GA4 #123456789

[Cycle 1]
Thought : Je dois d'abord récupérer la liste des événements actifs sur les 30 derniers jours.
Action   : ga4_api.run_report(property_id, metrics=["eventCount"], dimensions=["eventName"])
Observation : 47 événements distincts détectés. "purchase" présent, "add_to_cart" absent.

[Cycle 2]
Thought : "add_to_cart" manquant est suspect pour un site e-commerce. Je vérifie si le tag GTM correspondant existe.
Action   : gtm_api.list_tags(container_id)
Observation : Tag "GA4 - add_to_cart" trouvé, trigger associé = "Click - Bouton Panier". Statut : PAUSED.

[Cycle 3]
Thought : Le tag existe mais est en pause. C'est la cause du manque de données. Je génère la recommandation.
Action   : llm.generate_recommendation(context)
Observation : Recommandation rédigée → "Réactiver le tag add_to_cart dans GTM et vérifier le trigger."

RAPPORT FINAL généré.

Ce pattern Reasoning + Acting transforme un comportement opaque en quelque chose que vous pouvez suivre, déboguer et auditer — chaque pensée et chaque action est visible dans la trace d’exécution.

La stack technique : ce qu’on utilise vraiment

Pour construire cet agent, on s’appuie sur trois couches.

LangGraph pour l’orchestration. LangGraph est un framework construit au-dessus de LangChain qui facilite la conception et l’exécution d’agents IA multi-étapes et stateful, en utilisant une architecture basée sur des graphes. Chaque nœud du graphe correspond à une étape de l’audit : fetch des données, analyse, génération de recommandation.

La GA4 Data API (v1beta) comme outil principal de l’agent. L’agent interagit directement avec la Google Analytics Data API pour contourner la latence de l’interface standard. Il utilise les méthodes run_realtime_report et run_report pour récupérer les données brutes d’événements.

Un LLM avec tool calling — GPT-4o ou Claude 3.5 Sonnet font très bien le travail ici. L’important : le modèle doit savoir quand appeler un outil et quand s’arrêter.

Ancienne école vs méthode augmentée par IA

Tâche	Audit manuel	Agent IA
Vérifier les événements actifs	Ouvrir GA4, explorer les rapports, noter à la main	API call automatique, comparaison avec un plan de marquage de référence
Détecter un événement manquant	Croiser plusieurs vues, chercher dans GTM	Vérification en quelques minutes, signalement des événements manquants, triggers obsolètes ou dupliqués, et tags non vérifiés
Anomalie de données	Alert manuelle si quelqu’un pense à regarder	Modélisation ARIMA et algorithmes Isolation Forest pour détecter les irrégularités subtiles dans les données temporelles, en différenciant la volatilité naturelle des pannes réelles de tracking
Rapport de recommandations	Rédaction manuelle, souvent incomplète	Généré automatiquement, contextualisé par propriété

Le prompt qui déclenche tout

Voici un exemple de prompt système pour initialiser l’agent d’audit :

Tu es un expert en implémentation GA4/GTM. Tu as accès aux outils suivants :
- ga4_run_report : interroge la GA4 Data API pour récupérer événements et métriques
- ga4_get_metadata : récupère les dimensions et métriques disponibles sur la propriété
- gtm_list_tags : liste les tags actifs dans un conteneur GTM
- gtm_list_triggers : liste les triggers et leur état (actif/pause)

Ta mission : auditer la propriété GA4 [PROPERTY_ID] en vérifiant :
1. La présence des événements clés définis dans [TRACKING_PLAN_JSON]
2. Les événements avec un volume anormalement bas sur les 7 derniers jours
3. Les tags GTM en pause qui correspondent à des événements manquants

Pour chaque anomalie détectée, génère une recommandation concrète avec priorité (haute/moyenne/basse).
Ne résume pas : liste les problèmes, les causes probables, et les actions correctives.

Ce prompt est délibérément directif. Plus vous êtes précis sur ce que l’agent doit vérifier, moins il hallucine ou part dans des directions inutiles.

Le vrai défi : les données manquantes et le bruit

Le modèle événementiel de GA4 crée plus de points de défaillance que Universal Analytics n’en avait jamais eu. Chaque événement personnalisé, paramètre et propriété utilisateur représente un point de rupture potentiel dans votre pipeline analytics — les praticiens rapportent régulièrement que les architectures événementielles échouent silencieusement. Un événement d’achat e-commerce mal configuré peut se déclencher sans valeur de transaction pendant des semaines avant que quelqu’un remarque l’écart dans le reporting de revenus.

L’agent doit donc distinguer le bruit normal du signal réel. Une approche efficace : calculer le Z-Score pour chaque métrique de manière horaire. Si une métrique comme purchase_revenue présente un Z-Score supérieur à 3,0 (trois écarts-types par rapport à la moyenne), elle est signalée comme anomalie statistiquement significative.

Un point souvent oublié : le Consent Mode. Si le trafic en provenance de la région EU chute de manière disproportionnée, l’agent peut vérifier que les signaux Consent Mode v2 (ad_storage, analytics_storage) se déclenchent correctement. C’est exactement le genre de vérification qu’on oublie dans un audit manuel sous pression.

Ce qu’on ne délègue pas encore à l’agent

L’agent est bon pour détecter, comparer, signaler. Il est moins fiable pour interpréter le contexte business. Si votre taux de conversion chute de 40% un vendredi soir, il va le flaguer. Mais il ne saura pas que vous avez intentionnellement coupé une campagne payante ce jour-là.

La plupart des organisations optent pour une autonomie bornée plutôt qu’une indépendance totale. L’objectif est de laisser les agents agir seuls là où les résultats sont prévisibles, tout en maintenant les humains dans la boucle quand le risque ou l’incertitude augmente.

En pratique : laissez l’agent tourner chaque nuit sur votre propriété GA4, recevoir les anomalies dans Slack ou par email, et décidez vous-même ce qui mérite une intervention. C’est déjà une avancée considérable par rapport à l’audit trimestriel qu’on reporte depuis six mois.

La prochaine étape concrète : ouvrez la documentation de la GA4 Data API et identifiez les trois événements clés de votre propriété que vous n’avez jamais vraiment vérifiés de manière systématique. Ce sont exactement ceux que votre agent devrait surveiller en premier.