Comment recetter un dataLayer avant et après une mise en production ?

En bref : recetter un dataLayer, c'est vérifier, avant et après chaque mise en production, que chaque événement se déclenche au bon moment, avec les bonnes variables et les bonnes valeurs. Concrètement : on repart du plan de marquage, on rejoue les parcours clés, et on contrôle dans le mode Preview de GTM et la console que la donnée envoyée est conforme.

Vendredi, 18 h. Le site part en production, tout le monde rentre chez soi content. Lundi matin, les chiffres de Google Analytics 4 racontent n'importe quoi : le nombre d'achats a fondu, mais le back-office, lui, affiche un week-end tout à fait normal. Que s'est-il passé ? Une mise en prod a déplacé un bout de code, un événement du dataLayer ne part plus, et personne ne l'a vu. Parce que personne n'avait recetté.

La recette du dataLayer, c'est précisément ce qui évite ce scénario. C'est la phase la moins glamour du tracking, celle qu'on saute quand on est pressé, et pourtant c'est elle qui sépare une donnée de confiance d'un tableau de bord qui ment. Dans cet article, je vais vous expliquer quand recetter, comment le faire pas à pas, et je vous donne une checklist de points de contrôle réutilisable. On en parle.

Recetter un dataLayer, c'est différent de « poser » un dataLayer ?

Oui, et c'est une confusion fréquente. Poser un dataLayer, c'est l'implémenter : un développeur écrit le code qui pousse les données et les événements. Recetter un dataLayer, c'est vérifier que ce code fait réellement ce qu'il est censé faire.

Pour rappel, la référence de tout ça, c'est le plan de marquage : le document qui spécifie quels événements doivent être collectés, avec quelles variables et à quel moment. Poser le dataLayer, c'est traduire ce plan en code. Recetter, c'est confronter le code à ce plan et vérifier qu'ils disent la même chose.

Une image simple : poser le dataLayer, c'est écrire le texte ; recetter, c'est le relire à voix haute pour attraper les fautes avant publication. Si vous ne savez pas encore ce qu'est un dataLayer, commencez par cet article avant de lire la suite.

La ligne à retenir : un dataLayer non recetté est un dataLayer dont vous ignorez s'il est juste.

Quand faut-il recetter son dataLayer ?

La réponse courte : plus souvent que vous ne le faites aujourd'hui. En pratique, une recette s'impose à quatre moments :

• À la mise en place initiale d'un plan de marquage. Le premier jet contient presque toujours des coquilles : variable oubliée, mauvais format, événement au mauvais endroit.
• Avant chaque mise en production (MEP), idéalement en préproduction. C'est le moment de valider que ce qui va partir en ligne est conforme, pendant qu'on peut encore corriger sans stress.
• Après chaque MEP, en production cette fois. Parce qu'un déploiement peut réserver des surprises que la préprod n'avait pas révélées.
• Après toute refonte, nouvelle fonctionnalité ou changement de CMP (la plateforme de gestion du consentement). Ces chantiers touchent au code et à l'ordre de chargement, deux choses dont dépend directement le dataLayer.

La règle est simple : chaque fois que le site change, le tracking peut casser. Donc chaque fois que le site change, on recette.

Comment recetter un dataLayer, étape par étape ?

Partir du plan de marquage

On ne recette pas « au feeling ». On part du plan de marquage, event par event, et on coche. Si le plan prévoit un add_to_cart avec une devise, une valeur et une liste d'articles, c'est exactement ça qu'on va chercher. Pas de plan de marquage à jour ? C'est le premier chantier, avant même de recetter.

Rejouer les parcours clés comme un utilisateur

On parcourt le site pour de vrai : page produit, ajout au panier, tunnel de commande, formulaire, connexion. À chaque étape, un ou plusieurs événements doivent se déclencher. L'idée est de reproduire les parcours réels de vos utilisateurs, pas seulement la home et une fiche produit. Gardez à l'esprit que les régressions se cachent souvent dans les parcours qu'on teste le moins : le checkout, le compte client, les cas d'erreur.

Vérifier structure, valeurs et déclenchement

C'est le cœur de la recette. Pour chaque événement, on ouvre le mode Preview de Google Tag Manager et la console du navigateur, et on vérifie trois choses :

• L'événement se déclenche-t-il au bon moment (ni trop tôt, ni deux fois) ?
• Toutes les variables attendues sont-elles présentes, et bien nommées ?
• Les valeurs sont-elles correctes : bon format, bon type, pas de undefined, pas de champ vide ?

Concrètement, sur un ajout au panier, on s'attend à voir arriver quelque chose comme :

window.dataLayer.push({
  event: 'add_to_cart',
  ecommerce: {
    currency: 'EUR',
    value: 29.90,
    items: [{ item_id: 'SKU-123', item_name: 'T-shirt', price: 29.90 }]
  }
});

Si value arrive à 0, si items part vide, ou si l'événement ne se déclenche pas du tout, vous venez de trouver un bug avant qu'il ne pollue vos données. C'est tout l'intérêt.

Contrôler l'ordre des push et le consentement

Dernier point, souvent négligé : l'ordre. Les événements liés au consentement doivent partir avant les événements custom, sinon vous risquez de collecter (ou de perdre) de la donnée au mauvais moment. Le mode Preview permet de visualiser cette séquence et de repérer les race-conditions, ces situations où deux scripts se courent après et où le résultat dépend de qui gagne la course.

La checklist des points de contrôle

Voici la checklist que j'utilise en clientèle. Elle se réutilise telle quelle, event par event.

À noter que la dernière ligne est la plus oubliée : un dataLayer correct ne garantit pas que le hit (la requête envoyée à l'outil) arrive bon dans GA4 ou Meta. Vérifier le dataLayer, c'est nécessaire. Vérifier que la donnée arrive à destination, c'est le cran au-dessus.

Les erreurs qu'une recette permet de rattraper

Pour rendre ça concret, voici des cas bien réels (anonymisés) que la recette a permis d'attraper, ou aurait permis d'éviter :

• Le panier muet. Après le déploiement d'un nouveau panier, l'événement view_cart ne se déclenchait plus du tout. Personne ne s'en était rendu compte pendant des semaines.
• L'achat sans montant. Après la refonte d'un tunnel, l'événement purchase partait bien vers GA4, mais sans le montant. Résultat : des ventes comptées, mais un chiffre d'affaires fantôme.
• Le double comptage. Deux conteneurs GTM cohabitaient sur le site après une migration. Chaque page_view était donc compté deux fois. Le trafic paraissait excellent, il était faux.
• La liste vide. Après une migration, le tableau items partait vide vers GA4. Les revenus e-commerce étaient mécaniquement sous-estimés, sans la moindre alerte.

Le fil rouge de tous ces cas : la régression passe inaperçue pendant des semaines, jusqu'à ce qu'une analyse ou un budget média en pâtisse. C'est exactement ce qu'une recette rigoureuse, faite au bon moment, permet d'éviter.

Recette manuelle ou monitoring continu : la limite du fait-main

Tout ce que je viens de décrire, c'est de la recette manuelle. Et soyons honnêtes : elle est indispensable, mais elle a une limite de taille. Elle ne passe pas à l'échelle.

Recetter à la main, c'est rejouer chaque parcours, sur mobile et sur desktop, pour chaque événement, à chaque mise en production. Sur un gros site qui déploie plusieurs fois par semaine, c'est intenable. Alors on recette au lancement, puis de temps en temps, et entre deux recettes, le tracking peut casser sans que personne ne regarde. La recette humaine est une photo à l'instant T, pas une surveillance continue.

C'est précisément ce vide que MayIA° vient combler : un système qui rejoue les parcours comme un utilisateur et vérifie chaque événement du dataLayer en continu, avant et après chaque MEP, avec une alerte contextualisée quand quelque chose casse. La recette manuelle reste parfaite pour le cadrage initial et les cas complexes ; l'automatisation prend le relais pour ce que l'humain ne peut pas faire : surveiller en permanence.

Pour conclure

Si vous ne devez retenir qu'une chose : recetter un dataLayer n'est pas une formalité de fin de projet, c'est un réflexe à chaque évolution du site. Partez du plan de marquage, rejouez les vrais parcours, contrôlez structure, valeurs et déclenchement, et surtout n'oubliez pas de vérifier que la donnée arrive vraiment dans vos outils.

Une refonte ou une grosse MEP approche, et vous voulez sécuriser votre collecte ? N'hésitez pas à nous contacter chez Smart Bees, on regarde ça ensemble.

FAQ

Quelle est la différence entre recetter et débugger un dataLayer ?

Recetter, c'est vérifier méthodiquement que le dataLayer est conforme au plan de marquage, souvent avant ou après une mise en production. Débugger, c'est diagnostiquer et corriger un problème déjà identifié. La recette est préventive, le débogage est curatif.

Faut-il recetter en préproduction ou en production ?

Les deux idéalement. La préproduction valide avant la mise en ligne, pendant qu'on peut corriger sans impact. La production confirme qu'après déploiement tout se comporte comme prévu. Un environnement ne remplace pas l'autre.

Combien de temps prend une recette de dataLayer ?

Cela dépend du nombre d'événements et de la complexité des parcours. Sur un site e-commerce, une recette sérieuse va de quelques heures à quelques jours, surtout en couvrant mobile et desktop séparément.

Peut-on automatiser la recette d'un dataLayer ?

Oui en partie. Des solutions de monitoring rejouent les parcours et vérifient les événements en continu, prenant le relais de la recette manuelle pour la surveillance dans le temps. La recette humaine reste utile pour le cadrage initial.

Qui doit recetter le dataLayer, le développeur ou l'analyste ?

Idéalement les deux. Le développeur vérifie l'aspect technique, l'analyste valide que la donnée correspond aux besoins de mesure du plan de marquage. La recette est un point de rencontre entre technique et métier.