You Don't Know GA — Standardiser, Opérationnaliser, Distribuer

Contexte et objectifs

Présentation MeasureCamp : comment transformer une méthodologie de consultant GTM en produit distribué, en trois niveaux — standardiser (conventions parsables), opérationnaliser (agent IA piloté par SOPs), distribuer (MCP comme canal universel).

La thèse centrale : une convention bien conçue est un protocole, un protocole bien conçu devient un produit.

Niveau 1 — Standardiser

Le casing comme système de typage

La première brique est la convention de nommage. Pas une charte PDF : un protocole parsable où la forme du nom encode le type de donnée.

Catégorie	Casing	Exemple	Sémantique
Raw data	$ + lowercase	$user_id, $_session_token	Miroir exact de la source. Possédé par les devs.
Fonction	camelCase + verbe	isFirstPurchase, calculateOrderTotal	Le verbe annonce le travail et le type de retour.
Processed data	TitleCase	NormalizedOrderID, HashedUserEmail	Résultat d'un calcul. Possédé par le container.
Constante	UPPERCASE	G-XXXXXXXX, GA4_CURRENCY	Valeur littérale, exacte dans le nom si possible.

L'œil parse la liste sans lire : la forme du nom est le type. Aucun préfixe nécessaire.

Les séparateurs comme caractères de parsing

Deux séparateurs choisis pour ne jamais collisionner avec les données réelles :

• | structure le tag : Purpose | Vendor | Trigger | Detail
• § attache les variantes : purchase, purchase § Processed, purchase § Except

Le nom canonique reste une substring → la recherche devient un détecteur de doublons. Deux niveaux de structure, zéro confusion.

ggLowCodeGTMKit — le savoir-faire packagé

La librairie ggLowCodeGTMKit contient 250+ templates de variables GTM zéro-code, organisées en 14 catégories, avec 2 modes d'exécution (Direct / Apply). Open source MIT, Web + Server-side.

Pipeline composable — du fonctionnel dans GTM, via l'UI native. Nommage uniforme et docs machine-readable : conçue dès le départ pour consommation humaine et IA.

Le pivot

Standardisé = parsable = automatisable.

Quatre implications directes de la convention déterministe :

1. audit_naming devient une regex, pas une opinion
2. Nom canonique en substring (§) → consolidate_duplicates devient une recherche + signature de config
3. Casing = typage → create_variable sait quelle forme générer, sans deviner
4. Descriptions structurées (owner / purpose / end_date) → audits cross-container triviaux

80 % du travail d'un expert GTM est déterministe une fois le standard posé. C'est du code, pas de l'IA.

Niveau 2 — Opérationnaliser

L'agent : un pair programmer GTM

Architecture en trois couches :

1. Intent Router (Gemini Flash) — intention → SOP
2. SOP Engine — 16 procédures (audit · rename · consolidate · create)
3. API GTM — lecture / écriture temps réel

naming-rules.js — toute création / modification passe par la convention. Sans exception.

Pas un gros prompt magique : un routeur léger qui dispatche vers des procédures testées (SOPs), chacune streamant sa pensée, ses validations, ses erreurs.

LLM seulement quand un jugement est requis

Du code (déterministe)	Du LLM (jugement)
Appliquer la convention de nommage	Comprendre « corrige mon plan de marquage »
Détecter les doublons (signature de config)	Choisir la SOP face à une demande floue
Renommer en masse via l'API	Générer un payload depuis une phrase
Valider un schéma de variable	Nommer l'intention métier d'un asset

Moins de LLM = plus rapide, moins cher, plus fiable. L'IA est un routeur + un traducteur, pas l'exécutant.

Preview → apply : jamais d'écriture sans validation

Le pattern en deux temps :

1. Preview — l'agent génère un aperçu : tableau des renommages, fusions proposées, diffs
2. Validation humaine — vous relisez, ajustez, confirmez. Rien ne part sans votre OK explicite
3. Apply — l'API GTM applique. Les renames sont safe : GTM référence par ID

Un agent qui écrit dans un container de prod sans garde-fou, c'est un incident qui attend son heure.

Niveau 3 — Distribuer

MCP en 30 secondes : l'USB-C des LLMs

API classique	Serveur MCP
1 service = 1 contrat propriétaire	Protocole standard, client universel
10 services = 10 intégrations à coder	Tools auto-découverts au runtime
Doc écrite pour des devs humains	Schémas + descriptions lus par le LLM

≈ OpenAPI + client universel + découverte dynamique, pensé pour qu'un LLM — pas un dev — soit le consommateur.

Où vit l'intelligence ?

Pas dans les prompts. Trois couches distinctes :

1. Descriptions des tools (QUAND appeler) — routing uniquement, courtes, lisibles par n'importe quel LLM client
2. Logique serveur (COMMENT bien faire) — naming-rules.js, signatures de config, garde-fous. IP non exposée
3. Réponses des tools (ET ENSUITE ?) — l'output pilote l'action suivante du LLM client. Orchestration depuis le serveur

Votre naming convention n'est pas un prompt. C'est du code — et c'est précisément ce qui la protège.

La thèse

Agences : votre méthodologie est-elle encodable ?

OUI → votre savoir-faire devient un produit	NON → vos clients demanderont à un LLM
Votre MCP, branché dans le Claude / Cursor de vos clients	Le GTM « moyen » est déjà gratuit
Revenu récurrent, scalable, sans staffing	Une méthode non formalisée n'est pas défendable — ni vendable
Le conseil reste pour le vrai jugement	Le TJM ne survit pas à la commodité

La standardisation n'est plus de l'hygiène. C'est la condition de survie de votre IP.

Par où commencer

1. Standardisez — Convention = règles parsables : casing typé, séparateurs sans collision, descriptions structurées
2. Encodez — Tout ce qui peut être une règle devient du code. Le LLM n'entre que là où un jugement est requis
3. Outillez — Des tools aux périmètres nets + le pattern preview / apply imposé côté serveur
4. Distribuez — Wrapper MCP + OAuth lié au compte. Vos tools dans le LLM de vos clients — votre logique chez vous

L'ordre compte : un MCP sur une méthode non standardisée distribue du chaos plus vite.