Comment auditer votre dataLayer avant une refonte e-commerce ?

En bref : auditer son dataLayer avant une refonte e-commerce, ce n'est pas vérifier que le tracking fonctionne aujourd'hui. C'est produire trois choses avant que le site ne change : une référence gelée de ce qui est collecté, une baseline chiffrée de vos volumes par événement, et des critères de validation qui diront, après le go-live, si l'écart vient du nouveau site ou du nouveau tracking. Sans ces trois éléments, la question sera indécidable.

J+15 après la refonte. Les conversions affichent -22 %. La question tombe en comité : c'est le site ou le tracking ?

Personne ne peut répondre. Pas parce que l'équipe est mauvaise, mais parce que deux variables ont changé le même jour et qu'il n'existe aucun point de comparaison fiable. Le tracking a été refait en même temps que les parcours, donc le thermomètre a changé en même temps que la température. On passe alors trois semaines à débattre au lieu de corriger, et pendant ce temps les budgets média continuent de s'optimiser sur des données dont personne ne garantit la validité.

Ce scénario est évitable, mais pas après coup. Il s'évite avant, et c'est tout l'objet de cet article : ce qu'un audit avant refonte doit produire, à quel moment le lancer, et les pièges spécifiques à un changement de plateforme.

Pourquoi une refonte est le pire moment pour découvrir son tracking

Une mise en production ordinaire ne touche qu'une partie du site. Une refonte touche tout à la fois : le CMS, le DOM, les URL, souvent le conteneur GTM, presque toujours la CMP. Chacun de ces éléments est une dépendance directe du dataLayer.

Mais le vrai risque d'une refonte n'est pas que le tracking casse. C'est banal, et ça se recette. Le risque propre à une refonte, c'est de perdre la comparabilité. Tant que vous ne pouvez pas isoler la variable, aucune décision post-refonte n'est solide : ni « on revient en arrière », ni « on laisse tourner, ça va remonter ».

Nos propres mesures montrent qu'une régression met en moyenne deux semaines à être remarquée, sauf quand elle touche directement le chiffre d'affaires. Sur une refonte, ces deux semaines tombent exactement dans la fenêtre où vous êtes censé juger si le nouveau site performe.

La ligne à retenir : une refonte ne casse pas seulement des événements, elle casse votre capacité à prouver ce qui s'est passé.

Ce qu'un audit avant refonte doit produire

Un audit avant refonte n'est pas un rapport que l'on lit une fois. Ce sont trois livrables qui vont servir après le go-live :

1. La référence gelée. L'état exact de ce qui est collecté aujourd'hui : événements, variables, valeurs types, destinations. Si vous avez un plan de marquage à jour, c'est lui. Sinon, l'audit consiste d'abord à le reconstituer depuis le site existant, et c'est du temps à prévoir.
2. La baseline chiffrée. Les volumes par événement sur une période stable, typiquement 30 jours. Pas « add_to_cart existe », mais « add_to_cart se déclenche environ 42 000 fois par mois, avec value renseignée dans 98 % des cas ».
3. Les critères de validation. Ce que la nouvelle version du site doit reproduire pour être acceptée. Écrits avant, validés avec les équipes produit et média, opposables le jour du go-live.

C'est le troisième point qui manque presque toujours, et c'est le seul qui transforme le débat des données en décision. Un critère de validation, c'est une phrase du type : « le volume de purchase ne doit pas s'écarter de plus de 5 % du volume moyen constaté habituellement, à trafic comparable ».

Quand lancer l'audit

Six à huit semaines avant le go-live, pas la semaine d'avant.

Cette durée n'est pas confortable, elle est mécanique. La baseline demande 30 jours de données stables, donc elle doit être lancée avant que quoi que ce soit ne bouge. Reconstituer une référence absente demande des allers-retours avec les développeurs. Et surtout : les critères de validation doivent être validés à froid, pas dans l'urgence d'un lancement de nouveau site, sinon ils seront revus à la baisse au moment où ils gênent.

Un audit lancé la semaine précédant la bascule ne produit qu'un constat. Il ne produit pas de référence utilisable.

L'audit avant refonte, étape par étape

Geler la référence

Documentez ce qui est collecté sur le site actuel, événement par événement, avec les variables et un exemple de valeur réelle. Datez ce document et n'y touchez plus : sa valeur vient précisément de ce qu'il décrit l'avant.

Mesurer la baseline sur une période stable

Sur 30 jours, relevez pour chaque événement le volume, le taux de remplissage des paramètres clés et la répartition mobile/desktop. Évitez les périodes de soldes ou de pic promotionnel, qui rendent la comparaison ultérieure discutable.

Référencer ce qui doit être conservé

Tout ne mérite pas d'être repris. C'est le bon moment pour trancher : quels événements servent réellement une décision, lesquels ont été ajoutés pour un besoin oublié. Une refonte est l'occasion rare de réduire le périmètre plutôt que de le porter tel quel dans la nouvelle plateforme.

Écrire les critères de validation

Pour chaque événement critique, un seuil d'écart acceptable et la façon de le mesurer. Incluez les revenus, le taux de consentement et le remplissage des paramètres monétaires, pas seulement les volumes d'événements.

Recetter la préproduction avant la mise en production

Dès que la préprod est prête, confrontez-la au site de référence, pas à l'intuition. Rejouez les parcours réels, y compris le compte client, la recherche interne et les cas d'erreur de paiement. Vérifiez aussi que la donnée arrive bien dans les outils et pas seulement dans le dataLayer.

Contrôler à J0, J+1 puis à J+7

Le jour de la bascule, un passage complet sur les parcours critiques. Une semaine plus tard, une comparaison chiffrée contre la baseline. C'est ce second contrôle qui attrape les régressions qui ne se voient pas en navigation manuelle : un paramètre vide sur un segment de trafic, un événement qui ne part que sur un navigateur.

Le tableau de validation

Voici la structure que nous utilisons pour arbitrer un go-live. Une ligne par indicateur, comparée à la baseline :

Le rapprochement avec le back-office est la ligne la plus importante et la plus souvent absente. C'est la seule qui compare votre collecte à une vérité extérieure plutôt qu'à elle-même.

La ligne attribution est celle qui surprend le plus après une bascule. Une refonte change les URL, donc les redirections, et une redirection mal configurée perd la chaîne de requête : les paramètres UTM disparaissent en route et le trafic bascule en « (direct) / (none) ». Le tracking d'événements peut être parfait et l'attribution fausse, ce qui déplace le problème sur les budgets média sans toucher aux conversions collectées.

Les pièges propres à une refonte

• Le nouveau DOM casse les déclencheurs. Les déclencheurs GTM basés sur des classes CSS ou des chemins d'éléments ne survivent pas à un changement de thème. Ils ne renvoient pas d'erreur, ils cessent simplement de se déclencher.
• La migration de conteneur GTM laisse deux conteneurs actifs. Le temps d'une bascule, les deux cohabitent et chaque événement est compté deux fois. C'est l'une des erreurs les plus fréquentes et l'une des plus flatteuses : le trafic paraît excellent.
• La CMP est réimplémentée, et l'ordre change. Nouvelle intégration, nouveau timing, et des tags qui partent avant le consentement alors que ce n'était pas le cas avant.
• Les nouvelles URL cassent les conditions de déclenchement. Toute règle qui contient un fragment d'URL doit être réécrite, y compris les exclusions.
• La navigation devient client-side. Passer à un rendu SPA change la façon dont les vues de page se déclenchent. Le page_view historique disparaît ou se duplique, selon l'implémentation.
• Le nouveau tunnel change la sémantique des événements. Un checkout en une page au lieu de trois n'a plus les mêmes étapes. Le tableau de validation doit alors être explicitement ajusté, et cet ajustement doit être écrit, pas improvisé.

Après le go-live : la fenêtre où tout se joue

Les deux semaines qui suivent une bascule sont le moment où le tracking est le plus fragile et le moins surveillé, parce que toute l'attention est sur le site. C'est aussi la période où une régression coûte le plus cher, puisque les décisions de rollback et de budget média se prennent exactement là.

C'est cette fenêtre que MayIA° couvre. La référence produite pendant l'audit devient exécutable : des agents LLM rejouent les parcours comme un utilisateur, comparent chaque événement observé à ce que la référence annonce, et l'alerte tombe quand l'écart apparaît, pas au comité de J+15. Concrètement, cela transforme le tableau de validation ci-dessus en contrôle automatique plutôt qu'en tâche manuelle que personne n'a le temps de faire pendant un lancement. Si vous comparez les approches disponibles, nous avons détaillé les outils de QA dataLayer automatisée et ce qui les sépare d'une recette faite à la main.

Pour conclure

Une refonte e-commerce ne se prépare pas côté tracking en vérifiant que ça marche. Elle se prépare en produisant une référence gelée, une baseline chiffrée et des critères de validation écrits à froid. Ces trois livrables coûtent quelques jours avant le go-live, et ils sont la seule chose qui vous permettra de répondre en une heure, plutôt qu'en trois semaines, à la question qui viendra forcément : est-ce le site ou le tracking ?

Une refonte est prévue dans les prochains mois et vous voulez sécuriser la collecte avant la bascule ? Parlons-en, on regarde ça ensemble.

FAQ

Combien de temps avant une refonte faut-il auditer son dataLayer ?

Six à huit semaines avant le go-live. Ce n'est pas une marge de confort : la baseline demande 30 jours de données stables, donc elle doit démarrer avant que quoi que ce soit ne bouge, et les critères de validation doivent être négociés à froid plutôt que dans l'urgence du lancement.

Quelle est la différence entre un audit avant refonte et une recette de dataLayer ?

Une recette vérifie la conformité d'une implémentation à un instant donné. Un audit avant refonte produit en plus une référence gelée et une baseline chiffrée, qui servent après le go-live à déterminer si un écart vient du nouveau site ou du nouveau tracking. La recette regarde le présent, l'audit prépare la comparaison.

Faut-il refaire tout le tracking pendant une refonte ?

Non, et c'est même l'occasion de réduire le périmètre. Une refonte est le rare moment où l'on peut supprimer les événements ajoutés pour des campagnes oubliées. Reporter mécaniquement tout l'existant dans la nouvelle plateforme revient à payer la maintenance d'une collecte que personne n'exploite.

Comment savoir si une baisse de conversions après une refonte vient du site ou du tracking ?

En comparant la collecte à une vérité extérieure, en pratique le back-office. Si le nombre de transactions du back-office est stable alors que les purchase collectés baissent, le problème est dans la collecte. Sans ce rapprochement, la comparaison se fait entre deux versions de la même mesure et ne tranche rien.

Qu'est-ce qu'un critère de validation ?

Un seuil d'écart acceptable, écrit avant la bascule, entre la nouvelle version et la baseline. Par exemple : le volume de purchase ne doit pas s'écarter de plus de 5 % du volume moyen constaté, à trafic comparable. Écrit avant, il est opposable ; improvisé après, il sera revu à la baisse.

Quels sont les problèmes de tracking les plus fréquents après une refonte ?

Les déclencheurs GTM basés sur des classes CSS qui ne se déclenchent plus après le changement de thème, deux conteneurs GTM actifs pendant la bascule qui doublent les comptages, une CMP réimplémentée qui change l'ordre de déclenchement, et les règles contenant un fragment d'URL devenues obsolètes.