La couche de données : ce que votre site doit dire à vos outils

Sommaire

Une mesure qui tombe en panne après une refonte n’est pas un accident. C’est la conséquence prévisible d’un choix fait des mois plus tôt : celui de laisser les outils deviner l’information au lieu de la leur déclarer.

La couche de données est le lieu de cette déclaration. C’est la brique la plus citée des dispositifs de mesure et la moins souvent définie — on la trouve mentionnée dans les guides Tag Manager, exigée dans les plans de marquage, et rarement expliquée pour ce qu’elle est.

Deviner ou déclarer

Prenons une page de confirmation de commande — le cas où la question se pose avec le plus de conséquences, détaillé dans l’article sur le suivi d’une boutique. Le montant y est affiché quelque part, dans un élément de la page. Deux façons de le récupérer.

Deviner. On indique à l’outil : « va chercher le texte contenu dans le troisième élément de la zone de récapitulatif ». Ça marche. Jusqu’au jour où un développeur ajoute une ligne au récapitulatif, et où l’outil se met à remonter les frais de port comme montant de commande. Personne ne le voit : le chiffre existe toujours, il est simplement faux.

Déclarer. Le site dit explicitement, dans un objet prévu pour ça : « cette commande vaut 148,50 €, elle porte l’identifiant 10932, elle contient trois articles ». L’outil lit une valeur nommée. Le jour où le design change, la déclaration ne bouge pas.

Ce que c’est, concrètement

Techniquement, c’est peu de chose : un tableau JavaScript déclaré sur la page, dans lequel le site dépose des objets. Chaque objet porte un nom d’événement et les données qui l’accompagnent.

Un dépôt de commande ressemble à ceci : un événement nommé achat, accompagné d’un identifiant de transaction, d’un montant, d’une devise et de la liste des articles. Rien de plus. Ce n’est ni une base de données, ni un cache, ni un endroit où stocker l’état de l’application : c’est un canal de déclaration, alimenté au moment où quelque chose se produit.

Le gestionnaire de balises écoute ce canal. Quand un objet y est déposé, il évalue ses déclencheurs, et les balises concernées partent avec les valeurs déclarées.

Ce qu’on y met

La règle de sélection est la même que pour un plan de marquage : une donnée entre dans la couche parce qu’une décision en dépend, pas parce qu’elle est disponible.

Trois familles se justifient presque toujours :

• Ce que l’utilisateur vient de faire — l’événement lui-même, avec son contexte immédiat : le formulaire envoyé, le produit ajouté, l’étape franchie.
• La valeur métier associée — le montant réel, la catégorie, la quantité. C’est ce qui permet de passer d’un décompte d’actions à une mesure d’activité.
• Le contexte durable — le type de page, le statut de connexion, le segment de client. Ce qui aide à interpréter, et qui ne change pas d’un événement à l’autre.

Ce qui n’a rien à y faire

La couche de données est lisible par n’importe qui ouvrant la console du navigateur. Ce seul fait tranche la moitié des questions.

• Aucune donnée directement identifiante — nom, adresse e-mail, téléphone, adresse postale. Si un outil en a besoin, cela se traite ailleurs et sous conditions, pas en clair dans la page.
• Aucun secret — jeton d’API, clé, identifiant de session serveur.
• Aucune donnée sensible au sens du RGPD, dont le cadre impose un traitement particulier.
• Rien qui ne serve à personne. Une couche qui grossit à chaque sprint devient illisible, et le premier réflexe en cas de doute sera d’aller relire le DOM — c’est-à-dire de revenir en arrière.

Un exemple, de bout en bout

Une boutique, deux moments, deux dépôts différents.

À l’ouverture de la fiche produit, le site déclare le contexte : type de page « produit », identifiant de l’article, catégorie, prix affiché, disponibilité, et statut de connexion du visiteur. Rien de tout cela n’est un événement : c’est le décor, déposé avant que le gestionnaire de balises ne se charge.

Au moment où la commande est confirmée, le site dépose un événement : le nom achat, l’identifiant de la transaction, le montant hors frais de port, les frais séparément, la devise, et la liste des articles avec leur quantité.

Chaque clé sert une décision précise. L’identifiant de transaction permet de dédoublonner et de rapprocher avec le back-office. Le montant hors frais permet de comparer la valeur réelle des paniers plutôt que la géographie des clients. La catégorie permet de savoir quelle gamme finance l’acquisition. La disponibilité, elle, explique pourquoi une fiche très vue convertit mal.

Ce sont ces réponses qui justifient les clés — pas l’inverse. Une clé dont on ne sait pas dire quelle question elle sert n’a pas à être déposée.

Nommer les clés

Les noms de clés sont un contrat entre l’équipe technique et l’équipe qui exploite la mesure. Ils se décident une fois, s’écrivent quelque part, et ne changent plus.

Trois règles suffisent. Un format unique — celui de l’outil de destination si vous n’en avez pas déjà un. Un vocabulaire métier, pas technique : montant_ttc et non val2. Aucune référence à l’affichage : libelle_bouton_bleu vieillira mal.

Les contraintes de l’outil qui reçoit s’appliquent ensuite. Google Analytics 4 accepte 40 caractères pour un nom de paramètre et 100 pour une valeur, et tronque en silence au-delà (limites documentées par Google, consultées en septembre 2026).

Le moment compte autant que le contenu

Une couche de données correcte remplie trop tard ne sert à rien. Deux moments à distinguer.

Le contexte de page doit exister avant le chargement du gestionnaire de balises. Type de page, statut de connexion, identifiant de catégorie : si ces valeurs arrivent après, les balises de page vue partent sans elles.

Les événements se déposent au moment où ils se produisent, et une seule fois. Le doublon le plus courant vient d’un dépôt à la fois au chargement de la page de confirmation et au retour de l’appel de paiement.

Qui l’écrit

La couche de données est du code. Elle est produite par le site, donc par l’équipe technique — jamais par le gestionnaire de balises, qui ne peut que la lire.

Cette répartition est souvent contournée : faute de temps de développement, on « fait avec » des variables qui lisent la page. Le contournement fonctionne et il coûte cher plus tard. La conversation utile n’est pas « pouvez-vous ajouter une couche de données », trop vague pour être priorisée, mais : « voici les huit valeurs dont dépendent nos décisions d’investissement, voici leur nom, voici quand elles doivent être déposées ».

C’est exactement ce qu’un plan de marquage produit, et c’est pour cela qu’il vient avant.

Consentement

Déposer une valeur dans la couche de données n’est pas un traitement en soi : rien n’est encore envoyé nulle part, rien n’est écrit sur le terminal. Ce qui est soumis au consentement, c’est ce que les balises en font ensuite.

La conséquence pratique est qu’on peut alimenter la couche sans attendre, et conditionner les envois. Mais elle ne dispense pas de deux précautions : ne rien y mettre d’identifiant en clair, comme dit plus haut, et vérifier que les balises conditionnées ne partent effectivement pas quand le signal de consentement manque.

Ce que la couche devient côté serveur

Quand la collecte passe par un conteneur serveur, la couche de données ne disparaît pas — elle devient plus importante. C’est elle qui alimente l’unique envoi sortant du navigateur, et tout ce qu’elle ne déclare pas est définitivement perdu pour la suite de la chaîne.

Le serveur peut ensuite enrichir : ajouter la marge réelle depuis le back-office, le segment client depuis le CRM, le statut de la commande après vérification. Mais il ne peut enrichir qu’à partir d’une clé de rapprochement — le plus souvent l’identifiant de transaction. Si cette clé manque dans la couche, l’enrichissement est impossible, et l’architecture serveur perd sa principale justification.

La recette

Quatre contrôles, dans la console du navigateur, sur le site réel.

1. Le contexte existe-t-il avant le gestionnaire de balises ? On regarde l’ordre des entrées, pas seulement leur présence.
2. Chaque événement part-il une fois ? On compte les occurrences, on ne se contente pas de constater qu’il y en a.
3. Les valeurs sont-elles justes ? On compare le montant déclaré au montant réel de la commande, sur une vraie transaction.
4. Le contexte se met-il à jour ? Sur une application monopage, on navigue et on vérifie que les valeurs suivent.

Les erreurs fréquentes

La créer après coup. Une couche de données conçue une fois les balises en place se contente de reproduire ce que les sélecteurs lisaient déjà. Elle n’apporte rien : elle déplace la fragilité.

Y mettre l’état de l’application. Elle n’est pas un magasin de données. Tout ce qui n’est pas destiné à sortir n’a pas à y entrer.

La laisser sans propriétaire. Comme le plan de marquage, elle a besoin d’une personne qui répond quand une clé disparaît — et les clés disparaissent, à chaque refonte.

Ne pas la documenter. Un tableau à deux colonnes — la clé, ce qu’elle contient — suffit. Sans lui, la connaissance tient dans la mémoire d’une personne, et elle part avec elle.