Plan de Taggage

Sur la plupart des sites que j'audite, le tracking a été construit au fil de l'eau : un développeur ajoute un événement pour une fonctionnalité, un stagiaire en ajoute un autre trois mois plus tard avec un nom différent, une agence en ajoute encore d'autres pour une campagne ponctuelle. Six mois après, plus personne ne sait ce qui est vraiment suivi, pourquoi, ni si les chiffres dans GA4 correspondent à ceux de Google Ads ou de Meta. Voir notre guide sur le plan de taggage pour une app mobile si votre problème est côté application plutôt que site web. Voir aussi notre page sur la fiabilisation du tracking en server-side, qui suppose toujours un plan de taggage propre en amont.

Le problème n'est presque jamais l'outil (GTM, GA4, Piano). C'est l'absence d'un document de référence unique qui dit : quel événement existe, ce qu'il signifie exactement, avec quels paramètres, et qui a le droit d'en ajouter un nouveau. C'est ça, un plan de taggage. Ce guide explique comment j'en construis un pour de vrai, avec la méthode que j'utilise en mission, pas une liste théorique de définitions.

Pourquoi la plupart des plans de taggage existants ne servent à rien

J'en vois trois types en audit, tous les trois cassés d'une manière différente :

• Le fichier Excel mort : construit une fois au lancement du site, jamais rouvert depuis. La moitié des événements qu'il liste n'existent plus, la moitié de ceux qui existent n'y sont pas.

• Le plan qui vit uniquement dans GTM : les noms de balises et de déclencheurs sont compréhensibles pour la personne qui les a créées, personne d'autre. Aucune vue d'ensemble de ce qui part réellement vers GA4 ou les régies pub.

• Le plan trop détaillé pour être maintenu : 40 colonnes, une ligne par variante de bouton. Personne ne le met à jour parce que le mettre à jour prend plus de temps que de re-créer l'événement à la main.

Un plan de taggage qui fonctionne a un seul objectif : que n'importe qui dans l'équipe (dev, marketing, vous dans un an) puisse répondre en 30 secondes à "cet événement existe-t-il déjà, et que fait-il exactement ?"

La méthode en 4 étapes

Je l'applique de la même façon quelle que soit la taille du site — voir aussi la méthodologie complète en 4 étapes que j'utilise sur l'ensemble d'une mission tracking.

Étape 1 — Cadrer avec les vraies parties prenantes, pas seulement la technique

Avant d'écrire le premier nom d'événement, je fais lister par le marketing et le produit les 5 à 10 actions qui comptent réellement pour le business : une vente, une demande de devis, une inscription, un rendez-vous pris. Pas "tous les clics possibles" — les actions qui, si elles n'étaient pas suivies, empêcheraient de piloter l'activité.

Étape 2 — Construire le dictionnaire d'événements

Chaque événement a : un nom stable (qui ne change jamais, même si le bouton change de libellé), une définition d'une phrase, et la liste des paramètres qui l'accompagnent. Un événement, une action réelle — jamais un événement générique du type click qui mélange 15 actions différentes derrière un seul nom.

Étape 3 — Documenter les déclencheurs, pas seulement les événements

Un plan de taggage incomplet liste les événements sans dire précisément quand ils se déclenchent. "Achat" ne suffit pas : est-ce au clic sur "Payer", à la confirmation de paiement, à la réception du webhook de la banque ? Ces trois moments donnent des chiffres différents. Le plan doit trancher, et l'implémentation GTM (ou serveur) doit suivre cette décision à la lettre.

Étape 4 — Le faire vivre, pas le figer

La règle la plus simple à appliquer et la plus souvent oubliée : aucune nouvelle fonctionnalité ne part en production sans qu'on se soit demandé si elle a besoin d'un nouvel événement, et sans avoir mis à jour le document. Un plan de taggage non versionné redevient un fichier Excel mort en moins d'un an.

Nomenclature : les règles qui évitent le chaos

• snake_case, toujours : generate_lead, pas Generate Lead ni generateLead. Ça évite les doublons créés par erreur de casse et ça correspond aux conventions GA4 (Recommended Events).

• Un vocabulaire fermé, pas libre : décidez une fois pour toutes si c'est submit ou send pour un formulaire, et interdisez l'autre. Sans ça, on se retrouve avec form_submit, form_sent et contact_send qui désignent la même action.

• Pas d'accents, pas d'espaces, pas de caractères spéciaux dans les noms techniques — uniquement dans les descriptions destinées aux humains.

• Le nom décrit l'action, pas la page : purchase, pas page_produit_clic_final. Un événement bien nommé reste valable même si vous refondez le site.

Exemple concret : un plan de taggage pour un site de génération de leads

Voici la base que je pose pour un site B2B qui vend sur devis — le type de profil le plus fréquent chez mes clients. C'est volontairement court : un plan de taggage démarre avec l'essentiel, pas avec 40 lignes.

Notez ce qui manque volontairement : pas d'événement "clic sur bouton" générique, pas de suivi de chaque interaction possible. Ces 6 lignes couvrent déjà l'essentiel du pilotage commercial d'un site B2B. On étend ensuite au cas par cas, jamais par défaut.

Les erreurs qui coûtent le plus cher

• Dupliquer un événement après une refonte : le site change, le nouvel événement s'appelle différemment de l'ancien, personne ne fait le lien. Résultat : une chute de conversions dans les rapports qui n'en est pas vraiment une.

• Ne pas documenter la frontière client-side / server-side : quand une partie du tracking part du navigateur et une autre d'un serveur (voir notre page sur le server-side), un plan de taggage qui ne précise pas laquelle des deux sources fait foi en cas d'écart devient une source de débats sans fin en interne.

• Oublier le consentement : un événement marketing (Ads, Meta) documenté dans le plan mais qui se déclenche avant le consentement de l'utilisateur n'est pas un détail technique, c'est un manquement RGPD.

• Confondre plan de taggage et plan de mesure : le plan de taggage dit quoi tracker techniquement. Il ne remplace pas la réflexion business sur quels KPIs suivre — c'est un travail en amont, pas le même document.

Un point de départ automatisé

Si vous partez de zéro, un générateur de plan de taggage arrive prochainement dans nos outils gratuits : quelques questions sur votre type de site et vos objectifs, pour sortir une première base d'événements avec un exemple de dataLayer. Ce ne sera pas un plan de taggage clé en main — exactement le point de départ de l'étape 2 ci-dessus, à affiner avec votre équipe.

Christophe Dubois

Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.