L’IA est en train de tuer mon métier de tracking. Enfin, presque.

Je fais du tracking depuis assez longtemps pour avoir connu une époque où poser correctement quelques tags demandait déjà de mettre les mains dans le code, de harceler un développeur et d’attendre une mise en production.

Google Tag Manager a déjà supprimé une partie de ce travail.

L’IA est en train d’en supprimer une deuxième, beaucoup plus grosse.

Et là, ça commence à devenir sérieux.

Quand je vois passer ce genre de promesse :

« Dites simplement à Claude ce que vous voulez mesurer. Il audite votre container GTM, crée les tags, triggers et variables, corrige les erreurs et prépare une nouvelle version prête à publier. »

Découvrez égalementGoogle Tag Manager vs Google Analytics lequel choisir ?

Ma première réaction n’est pas de rire.

Parce que techniquement, c’est devenu largement possible.

Pas parce que Claude aurait soudainement appris à cliquer dans Google Tag Manager comme un consultant sous caféine.

Claude peut être connecté à Google Tag Manager via MCP — Model Context Protocol — ou via une intégration utilisant directement l’API Google Tag Manager. Et cette API permet réellement de lire et gérer des comptes, containers, workspaces, tags, triggers, variables, dossiers et versions. (Google for Developers)

Des outils commencent déjà à exploiter cette possibilité. Markifact propose par exemple de connecter Claude à GTM pour auditer un container, construire tags et triggers, travailler dans un workspace et soumettre la publication à validation humaine. D’autres projets MCP proposent la même logique. (Markifact)

Découvrez égalementComment utiliser Google Tag Manager pour suivre vos clics ?

Donc oui.

Une partie du métier que j’ai pratiqué pendant des années est en train de devenir automatisable.

Et c’est une excellente nouvelle.

Est-ce que créer des tags GTM était vraiment mon expertise ?

C’est probablement la question la plus désagréable.

Pendant longtemps, une partie de la valeur d’un expert tracking venait tout simplement de sa capacité à manipuler correctement des outils que les autres ne maîtrisaient pas.

Découvrez égalementGoogle Tag Manager change quoi dans son interface ?

Créer :

• une variable Data Layer ;
• un Custom Event ;
• un trigger ;
• une balise GA4 ;
• une conversion Google Ads ;
• un pixel Meta ;
• une variable JavaScript ;
• une lookup table ;
• un workspace propre ;
• une convention de nommage cohérente.

Il fallait connaître GTM.

Il fallait connaître GA4.

Il fallait comprendre le dataLayer.

Il fallait parfois connaître JavaScript.

Et surtout, il fallait du temps.

Aujourd’hui, une IA à laquelle j’ai donné les bons outils peut exécuter une grosse partie de cette mécanique.

La nuance est importante : Claude n’a pas nativement un bouton magique “Google Tag Manager”. Il faut lui fournir les accès et les outils nécessaires.

Mais une fois cette infrastructure en place, le potentiel est énorme.

Google expose officiellement dans son API les ressources nécessaires pour gérer les workspaces, tags, triggers, variables, dossiers et versions d’un container. L’automatisation de GTM n’est d’ailleurs pas née avec les LLM : l’API permet depuis longtemps de réaliser programmatiquement ce type d’opérations. (Google for Developers)

Ce qui change avec Claude, ce n’est donc pas tellement l’API.

C’est l’interface entre l’humain et l’API.

Avant, il fallait coder :

objectif métier
      ↓
expert tracking
      ↓
configuration technique
      ↓
API / interface GTM

Maintenant, je peux tendre vers :

objectif métier
      ↓
Claude
      ↓
outils MCP / API
      ↓
workspace GTM
      ↓
validation humaine

Et ça change complètement la productivité.

Qu’est-ce que je peux réellement déléguer à Claude ?

Beaucoup plus de choses que je ne l’aurais imaginé il y a encore quelques années.

Prenons un besoin banal :

« Je veux mesurer les achats sur ce tunnel e-commerce dans GA4 et Google Ads. »

Un système correctement outillé peut analyser un container, identifier les composants existants et préparer les modifications nécessaires.

Il peut potentiellement :

• inventorier les tags, triggers et variables existants ;
• détecter certaines incohérences de configuration ;
• créer les variables Data Layer nécessaires ;
• créer ou modifier les triggers ;
• créer les événements GA4 ;
• configurer les tags Google Ads ;
• respecter une convention de nommage ;
• ranger les éléments dans des dossiers ;
• travailler dans un workspace dédié ;
• générer une nouvelle version ;
• documenter les changements ;
• s’arrêter avant publication et demander une validation.

Ce dernier point est essentiel.

Google Tag Manager distingue bien le travail réalisé dans un workspace de sa publication. Une modification n’est active sur le site qu’après publication d’une version. (Google Aide)

C’est exactement la frontière que je veux conserver.

L’IA prépare. Je décide.

Pour un gros container, l’audit est également intéressant.

L’API permet de récupérer toute sa structure. On peut donc demander à un LLM d’analyser plusieurs centaines de tags, variables et triggers sans passer deux heures à ouvrir chaque élément à la main. Cette utilisation de l’API pour inventorier et nettoyer des containers était déjà documentée avant l’arrivée des agents IA. (InfoTrust)

L’IA apporte ici quelque chose de nouveau : elle peut interpréter cette structure au lieu de simplement l’exporter.

Et ça, oui, ça peut me faire gagner énormément de temps.

Alors, où est le problème ?

Dans une phrase qu’on oublie beaucoup trop vite :

un LLM produit une réponse probable. Pas une vérité.

Anthropic le dit lui-même dans sa documentation.

Même avec une température réglée à zéro, les réponses de Claude ne sont pas totalement déterministes et deux appels identiques peuvent produire des résultats différents. (Claude Platform Docs)

C’est un détail énorme dans mon métier.

Moi, quand j’écris :

if (event === 'purchase') {
  sendPurchase();
}

j’attends un comportement déterministe.

La même entrée doit produire le même comportement.

Le tag doit partir quand les conditions sont réunies.

Il ne doit pas partir « probablement ».

Il ne doit pas décider que cette fois-ci une autre implémentation lui semble plus élégante.

Je pourrais comparer ça à la physique quantique parce que l’image est séduisante : on manipule des probabilités plutôt qu’un résultat prédéfini.

Mais scientifiquement, la comparaison s’arrête là.

Un LLM n’est pas un ordinateur quantique.

Le vrai concept qui m’intéresse est beaucoup plus simple :

Claude est probabiliste. Mon système de tracking doit être déterministe.

Et toute mon architecture doit respecter cette séparation.

Une configuration GTM correcte peut-elle quand même produire un tracking faux ?

Évidemment.

C’est même là que commence réellement le métier.

Un agent peut ouvrir mon container et constater :

GA4 - purchase
Trigger : purchase
Variable : {{DLV - ecommerce.value}}

Magnifique.

Tout semble propre.

Sauf que peut-être que le site envoie :

dataLayer.push({
  event: "order_completed",
  ecommerce: {
    transaction_id: "12345",
    total: 129.90
  }
});

Le container est cohérent.

Le tracking est faux.

Ou plutôt : il ne fonctionne simplement pas.

Et il existe des cas beaucoup plus vicieux.

Un purchase peut partir deux fois.

Le transaction_id peut être réutilisé.

value peut contenir le montant TTC alors que le métier attend le HT.

Une SPA peut déclencher deux événements de page.

Un formulaire peut envoyer l’événement avant que la validation serveur soit réellement terminée.

Le consentement peut arriver après certaines balises.

Une CMP peut fonctionner correctement en France et différemment dans un autre pays.

Une variable peut avoir le bon nom et le mauvais type.

Google rappelle par exemple qu’un événement purchase doit transmettre correctement certains paramètres, notamment currency, transaction_id, value et items, avec les types attendus. Une valeur numérique envoyée sous forme de chaîne peut déjà fausser le résultat. (Google Aide)

Ce ne sont pas des problèmes de création de tags.

Ce sont des problèmes de compréhension du système mesuré.

Et ça change tout.

Le Data Layer reste-t-il le vrai champ de bataille ?

Pour moi, oui.

Je peux demander à Claude :

Crée-moi le tracking e-commerce GA4.

Il peut connaître parfaitement la documentation Google.

Mais il doit encore savoir ce que mon site considère comme :

• un produit affiché ;
• un produit sélectionné ;
• un panier ;
• un début de checkout ;
• un paiement réussi ;
• une transaction remboursée.

Sur Shopify, WooCommerce, Magento, Prestashop ou une application React maison, la réalité technique n’est pas la même.

Et deux entreprises qui utilisent exactement la même technologie peuvent avoir des règles métier complètement différentes.

Prenons simplement le mot lead.

Un lead, c’est quoi ?

Un clic sur « Envoyer » ?

Un formulaire accepté par le navigateur ?

Une réponse HTTP 200 ?

Une création effective dans Salesforce ?

Un prospect dédupliqué ?

Un prospect qualifié ?

C’est là que l’IA atteint une frontière assez amusante.

Elle sait parfaitement créer le tag.

Elle ne peut pas deviner ce que l’entreprise veut réellement mesurer si personne ne l’a défini.

La qualité du tracking dépend donc toujours de quelque chose de beaucoup moins sexy qu’un agent IA :

la qualité du plan de mesure.

Est-ce que l’IA peut auditer mon tracking ?

Oui.

Mais il faut comprendre ce qu’elle audite.

Un audit de configuration et un audit de collecte sont deux choses différentes.

Claude peut lire un container et me signaler :

Cette balise n’a aucun trigger.

Très bien.

Ces deux tags semblent envoyer le même événement.

Intéressant.

Cette variable n’est utilisée par aucune balise.

Probablement utile.

Mais si Claude voit :

GA4 Event : generate_lead
Trigger : form_success

il ne sait pas automatiquement si form_success correspond réellement à un lead métier.

Markifact le dit d’ailleurs explicitement dans son guide d’audit GTM avec Claude : il faut distinguer ce que GTM est configuré pour faire de ce que le navigateur fait réellement. (Markifact)

Voilà exactement le problème.

Un container GTM n’est qu’une partie du système.

Il faut observer :

Site / application
        ↓
dataLayer / événements
        ↓
GTM Web
        ↓
éventuellement GTM Server
        ↓
endpoint Analytics / Ads
        ↓
GA4 / plateformes publicitaires
        ↓
rapports

Et je dois vérifier chaque étage.

Pourquoi je continuerai à ouvrir Tag Assistant ?

Parce que je ne crois pas un tracking sur parole.

Même s’il a été créé par Claude.

Même si Claude m’explique pendant trois paragraphes qu’il est correct.

Je veux voir les événements.

Je veux voir les valeurs.

Je veux voir les requêtes.

Je veux voir ce qui est réellement envoyé.

Google recommande lui-même l’utilisation du mode Preview et de DebugView pour vérifier les implémentations. DebugView permet d’observer les événements et propriétés utilisateur collectés en temps réel. (Google Aide)

Avec un container server-side, le principe est encore plus évident.

Le debugger permet d’inspecter les requêtes entrantes, le client qui les prend en charge, les tags exécutés, les valeurs des variables et les requêtes sortantes envoyées vers GA4 ou d’autres destinations. (Google for Developers)

C’est précisément ce que j’appelle la preuve.

Claude peut me dire :

Le tag est correctement configuré.

Moi, je veux pouvoir dire :

J’ai réalisé le parcours. Le purchase est parti une seule fois. Le transaction_id est correct. La valeur correspond à la commande. Le consentement est respecté. La requête est reçue par le serveur. GA4 reçoit l’événement.

Ce n’est pas la même phrase.

Et le Consent Mode dans tout ça ?

Excellent exemple de la limite du « fais-moi le tracking ».

Une IA peut parfaitement configurer :

ad_storage
analytics_storage
ad_user_data
ad_personalization

Google documente précisément ces paramètres pour Consent Mode. (Google for Developers)

Mais une configuration correcte ne garantit toujours pas que le système fonctionne correctement.

Il faut tester :

• avant consentement ;
• après acceptation ;
• après refus ;
• après modification du choix ;
• avec différentes régions si des règles géographiques existent ;
• avec les différentes catégories de consentement ;
• avec la CMP réellement utilisée.

Google recommande d’ailleurs explicitement de répéter les vérifications selon les zones géographiques lorsque des comportements régionaux sont configurés. (Google for Developers)

Là encore, Claude peut énormément m’aider.

Mais quelqu’un doit savoir quels scénarios doivent être testés.

Ce quelqu’un reste l’expert.

Ce que l’IA est réellement en train de tuer

Pas mon métier.

La partie ouvrière de mon métier.

Et franchement, tant mieux.

Voici comment je vois maintenant la répartition.

Le déplacement de valeur est évident.

Avant, je pouvais consacrer beaucoup de temps à fabriquer l’implémentation.

Demain, je vais surtout consacrer mon temps à concevoir et valider l’implémentation.

Et ça me convient très bien.

Le junior tracking est-il plus menacé que l’expert ?

Là, je pense que le sujet devient beaucoup plus inconfortable.

Une grande partie des tâches traditionnellement confiées à un profil junior sont précisément celles que l’IA sait maintenant absorber :

• créer des variables ;
• dupliquer des tags ;
• adapter des triggers ;
• documenter un container ;
• appliquer des conventions ;
• vérifier des configurations ;
• préparer un workspace.

Le problème n’est pas que Claude connaisse GTM.

Le problème est qu’il peut effectuer ces opérations à une vitesse qu’aucun humain n’atteindra.

Mais cela crée un paradoxe.

Comment devient-on expert si on ne réalise plus soi-même les tâches qui permettaient d’apprendre le métier ?

C’est probablement l’un des vrais problèmes de l’arrivée des agents IA.

L’expert de demain devra peut-être apprendre beaucoup plus vite à raisonner sur :

• l’architecture de collecte ;
• le modèle de données ;
• les flux réseau ;
• JavaScript ;
• les APIs ;
• les problèmes de consentement ;
• les méthodes de test ;
• les règles métier.

Savoir « où cliquer dans GTM » va perdre de la valeur.

Comprendre pourquoi la donnée obtenue est fausse va en prendre beaucoup.

Puis-je laisser Claude publier directement en production ?

Techniquement ?

Oui.

Bonne idée ?

Pour moi, non.

Du moins pas pour un tracking important.

L’API Google Tag Manager permet de publier une version. (Google for Developers)

Mais ce n’est pas parce qu’une action est disponible qu’il faut la donner sans contrôle à un agent.

Anthropic recommande d’ailleurs explicitement de contrôler les permissions accordées à Claude Code et rappelle que l’utilisateur reste responsable de la vérification des commandes et du code proposés avant leur approbation. (Claude Platform Docs)

Le problème devient encore plus intéressant avec MCP.

Une connexion MCP donne au modèle des outils externes. Anthropic recommande de ne connecter que des serveurs de confiance et avertit notamment du risque d’injection de prompt lorsqu’un serveur récupère du contenu externe. (Claude Platform Docs)

Autrement dit :

on ne branche pas un LLM sur un container GTM de production avec tous les droits en espérant qu’il soit sage.

Je préfère quelque chose comme :

Demande
   ↓
Claude analyse
   ↓
Claude propose un plan
   ↓
Validation humaine
   ↓
Claude crée un workspace
   ↓
Claude construit les éléments
   ↓
Tests automatisés
   ↓
Tests fonctionnels
   ↓
Validation humaine
   ↓
Création de version
   ↓
Publication

Et éventuellement :

PUBLICATION = action déterministe
AUTORISÉE uniquement si validation_humaine = true

Ce n’est plus vraiment du prompting.

C’est de l’architecture.

Voilà pourquoi je ne veux surtout pas d’une IA autonome

Il y a une confusion permanente autour des agents IA.

On imagine souvent que le niveau ultime consiste à supprimer l’humain.

Je pense exactement l’inverse.

Pour un système critique, le niveau ultime consiste à déterminer où l’humain n’est plus nécessaire et où il reste obligatoire.

Je peux laisser un programme créer automatiquement cent variables parce que l’opération est facilement contrôlable.

Je peux laisser Claude analyser dix containers et me produire une liste de suspects.

Je peux même lui demander de corriger automatiquement certaines erreurs triviales.

Mais je ne vais pas lui déléguer une décision métier implicite du genre :

Détermine ce qu’on devrait considérer comme une conversion importante et modifie le tracking.

Là, il manque quelque chose.

Le sens.

Un LLM peut raisonner sur le contexte que je lui donne.

Il ne possède pas magiquement le contexte que je ne lui donne pas.

Et quand il manque une information, le comportement le plus dangereux n’est pas qu’il s’arrête.

C’est qu’il produise une réponse parfaitement crédible.

La vraie révolution n’est donc pas « Claude remplace l’expert GTM »

C’est beaucoup plus intéressant.

Pendant quinze ans, une partie de mon expertise était prisonnière des interfaces.

Je savais transformer un besoin métier en dizaines d’objets techniques :

besoin
→ événement
→ paramètres
→ dataLayer
→ variables
→ triggers
→ tags
→ tests
→ documentation

L’IA peut maintenant prendre en charge une bonne partie du milieu de cette chaîne.

Je peux me concentrer davantage sur les deux extrémités :

COMPRENDRE
↓
CONCEVOIR
↓
──────────────
IA EXÉCUTE
──────────────
↓
TESTER
↓
VALIDER

Ce n’est pas une disparition de l’expertise.

C’est une compression de l’exécution.

Et pour quelqu’un qui connaît déjà le métier, le gain peut être brutal.

Mon expertise n’a finalement jamais été de créer un trigger

C’est probablement la conclusion qui me dérange le plus.

Pendant des années, on a confondu expertise et maîtrise d’outil.

Être rapide dans GTM n’a jamais été le cœur du métier.

C’était juste nécessaire.

Mon métier consiste plutôt à répondre à des questions beaucoup moins sympathiques :

Pourquoi avons-nous 18 % de transactions de moins dans GA4 que dans le back-office ?

Pourquoi ce tag part-il deux fois uniquement avec PayPal ?

Pourquoi le consentement fonctionne-t-il sur Chrome mais pas comme prévu dans un autre scénario ?

Pourquoi cette SPA génère-t-elle deux page_view ?

Pourquoi Google Ads et GA4 n’attribuent-ils pas les mêmes conversions ?

Pourquoi cette valeur est-elle correcte dans le Data Layer mais incorrecte dans la requête ?

Pourquoi le container fonctionne-t-il parfaitement en Preview et pas dans certaines conditions réelles ?

Quelle donnée faut-il réellement collecter ?

Quelle donnée ne faut-il surtout pas collecter ?

Et surtout :

est-ce que je peux faire confiance à cette donnée pour prendre une décision ?

Claude va devenir extraordinairement bon pour m’aider à répondre à certaines de ces questions.

Il peut lire énormément de configuration, rapprocher des informations, générer du code, utiliser des APIs, proposer des hypothèses et exécuter des opérations beaucoup plus vite que moi.

Je compte bien en profiter.

Mais quand Claude travaille sur mon tracking, il reste une différence fondamentale entre nous.

Claude cherche la réponse la plus probable.

Moi, je cherche la preuve.

Et pour l’instant, je préfère largement être du côté de la preuve.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.