Tout savoir sur Netvigie Tracking

Non. Et c'est probablement la question la plus importante de cette page.

Un plan documenté est une intention. Ce qui est collecté est un fait. Entre les deux, il y a votre site, vos développeurs, votre gestionnaire de tags, vos prestataires et six mois de mises en production.

Deux échecs classiques l'illustrent. Le référentiel impeccable qui décrit un site d'il y a dix-huit mois : personne n'a menti, il a simplement cessé d'être vrai. Et l'outil de scan qui signale des erreurs sans savoir ce qui était attendu : il détecte du bruit, pas des écarts.

Netvigie Tracking réunit les deux dans un seul objet. La définition qui documente est celle qui teste, donc votre intention est vérifiée en continu et tout écart devient une alerte qualifiée, avec son périmètre et son ancienneté.

Une nuance volontaire, qui en dit long sur la manière dont le produit est construit : la plateforme ne déclare jamais qu'un événement est «conforme ». Elle nomme ce qui viole une règle. Un événement sans anomalie peut aussi bien respecter toutes ses règles que n'en avoir aucune. C'est pour ça que la couverture de vos KPI est un indicateur plus honnête qu'un taux de conformité : elle vous dit ce qui est réellement sous contrôle, et ce qui ne l'est pas encore.

Oui, et c'est le scénario pour lequel la plateforme est faite.

Votre parcours de conversion est décrit une fois, avec une exigence explicite : l'événement d'achat doit être présent à l'étape finale, avec son montant et sa devise. Ce contrôle se déclenche depuis votre chaîne de déploiement, sur la préproduction, avant que la refonte parte en ligne. Un tracking cassé fait échouer la livraison comme n'importe quel test.

Si la refonte passe quand même, le même parcours tourne en continu sur la production. L'échec est constaté au passage suivant, une alerte s'ouvre, et vous êtes notifié par mail ou sur votre messagerie d'équipe.

Vous ne perdez donc plus un mois, mais quelques minutes. Et l'alerte ne dit pas seulement «l'événement d'achat est absent » : elle dit quels KPI ne sont plus garantis, en l'occurrence votre taux de conversion et votre CA e-commerce.

Il n'y a aucune raison. C'est exactement ce que change une surveillance continue : ce n'est plus vous qui allez chercher l'anomalie, c'est elle qui vient à vous.

Vous choisissez la fréquence de contrôle, jusqu'à quelques minutes sur un parcours critique. Vous choisissez les destinataires : mail, Slack, Teams, et une notification en temps réel dans l'application. Vous pouvez cibler par site, par environnement ou par nature de problème, pour que chaque équipe ne reçoive que ce qui la concerne.

Le message est rédigé en clair : la nature du problème, son ampleur, le périmètre touché, et les KPI menacés. Lisible sans être technicien, ce qui compte quand l'alerte arrive un vendredi soir sur le téléphone du responsable analytics.

La différence avec le reporting mensuel n'est d'ailleurs pas seulement une question de délai. Au reporting, vous constatez un trou et vous lancez une enquête. Avec l'alerte, vous avez déjà la cause, l'endroit et la date de début.

Plus que vous ne le pensez. Sur la plupart des sites analysés, une partie des tags qui se déclenchent n'est documentée nulle part.

Netvigie vous donne les deux inventaires qui manquent pour trancher.

Ce qui part de vos pages sans être déclaré : les tags oubliés, les pixels posés un jour pour une campagne et jamais retirés, les scripts d'un prestataire qui n'est plus votre prestataire. La reconnaissance s'appuie sur une base de signatures mise à jour quotidiennement, donc même un tag que personne dans l'équipe ne sait nommer est identifié.

Et l'inverse : ce que vous croyez collecter mais qui ne part plus. Un tag déclaré qui n'apparaît plus dans les contrôles remonte comme une anomalie. C'est souvent ainsi qu'on découvre les tags morts.

Entre les deux listes, vous savez enfin ce qui tourne réellement sur votre site. La décision de couper reste la vôtre, c'est un arbitrage métier. Mais elle se prend sur des faits.

En rejouant vos parcours dans chaque état de consentement, et en vérifiant ce qui part vraiment.

Vous décrivez les états : tout accepter, tout refuser, et les variantes de finalités qui vous concernent. Un parcours met la page dans l'état voulu avant le contrôle. Vous déclarez ensuite qu'en cas de refus, tel tag doit être absent. Tout tag qui part malgré tout est un manquement localisé, jusqu'à la page et l'étape concernées, avec la capture et la vidéo du parcours pour le prouver. Le contrôle porte aussi sur l'avant : ce qui se déclenche entre le chargement de la page et le clic sur la bannière, avant que l'internaute ait exprimé quoi que ce soit.

Ce contrôle est rare sur le marché, pour une raison structurelle : on ne peut pas demander à de vrais visiteurs de refuser pour vérifier que les tags se taisent. Un outil qui observe le trafic ne voit donc quasiment jamais le cas qui vous expose le plus. Nous le rejouons à volonté, y compris après chaque mise à jour de votre bannière par son éditeur.

Deux apports.

Une capacité de preuve. La question «nos tags respectent-ils réellement le refus de consentement ? »reçoit une réponse vérifiée et datée, page par page et parcours par parcours, au lieu d'une affirmation de l'équipe technique. Chaque contrôle laisse une trace, ce qui permet de démontrer la régularité de la surveillance, et non un audit isolé vieux de dix-huit mois.

Aucun nouveau traitement à encadrer. Netvigie Tracking ne dépose rien sur le site et n'observe pas les visiteurs. Vous n'ajoutez donc pas un sous-traitant qui collecte des données personnelles pour surveiller celles que vous collectez déjà.

 La plateforme est éditée et opérée en Europe, ce qui simplifie l'analyse des transferts.

En produisant la preuve du contrôle, pas une déclaration d'intention.

Netvigie Tracking rejoue vos parcours dans l'état « refus » et vérifie que les tags concernés sont bien absents. Chaque exécution laisse un résultat daté et immuable, avec le périmètre exactement contrôlé — quelles pages, quels parcours, quel état de consentement — et le détail de tout manquement, capture et vidéo à l'appui.

Vous disposez donc des deux choses qu'un audit demande toujours : la démonstration que le contrôle est régulier et non ponctuel, et l'historique de ce qui a été trouvé puis corrigé, avec les dates.

 C'est aussi ce qui permet de répondre à la question la plus difficile en cas de manquement : pendant combien de temps a-t-il duré ?

Le data layer est la couche de données qu'un site expose à ses outils de mesure : un objet JavaScript qui décrit la page en cours et les actions de l'internaute, et dans lequel le gestionnaire de tags (Google Tag Manager, Tag Commander, Tealium) vient puiser.

Il se dégrade pour une raison structurelle : il est alimenté par le code du site, mais consommé par le marketing et la data. Personne ne casse un data layer volontairement. Il casse quand un développeur renomme un champ sans savoir qui le lit, quand une refonte oublie un gabarit de page, ou quand un nouveau composant n'alimente pas la même structure que l'ancien.

D'où l'intérêt de le contrôler automatiquement, gabarit de page par gabarit de page, plutôt que de découvrir la panne au reporting mensuel.

Celles-là, et ce sont les plus coûteuses parce qu'elles reviennent sans cesse :

 • recopier un onglet pour créer la variante d'un autre pays ;

 • prévenir par mail que le plan a changé, et espérer que les bonnes personnes ouvrent le mail ;

 • tenir une colonne «à jour ? » que personne n'ose remplir ;

 • recetter le tracking URL par URL avant chaque mise en production ;

 • chercher laquelle des cinq copies du fichier fait foi ;

 • constituer un dossier de captures d'écran pour prouver que ça marchait ;

 • reconstituer après coup depuis quand un événement avait cassé.

À la place : une configuration unique et versionnée, rejouée automatiquement, et des alertes qui viennent à vous au lieu d'être cherchées.

Ce qui ne disparaît pas, autant le dire : décrire vos parcours critiques et définir vos gabarits de page. C'est fait une fois, et c'est le seul vrai investissement.

À partir du moment où vous ne pouvez plus affirmer qu'il décrit la réalité. Ce jour-là, il ne documente plus votre tracking : il vous donne une fausse assurance, et les décisions continuent de se prendre dessus.

 Les signaux, un seul suffit :

 • vous ne savez pas dire depuis quand un événement a cessé de partir ;

 • personne ne peut affirmer que le fichier décrit ce qui est réellement collecté aujourd'hui ;

 • le deuxième site a été traité en dupliquant un onglet, et les deux ont divergé depuis ;

 • vous découvrez les ruptures au reporting mensuel, pas à la mise en production ;

 • la recette du tracking est un dossier de captures d'écran ;

 • la personne qui tenait le fichier est partie ;

 • trois versions circulent et personne ne sait laquelle fait foi.

Le point commun de tous ces symptômes : un tableur ne peut pas se vérifier lui-même. Tant que le plan n'est pas confronté au site, il se périme sans que personne s'en aperçoive.

L'essentiel de cette recette.

Vos parcours sont décrits une fois. Soit vous les enregistrez, soit vous donnez une consigne en français : « connecte-toi, ajoute un produit au panier, va jusqu'au paiement». Dans ce second cas, l'agent exécute réellement le parcours sur votre site et n'enregistre que ce qui a fonctionné. Ce que vous récupérez est déjà passé une fois.

Ensuite ils se rejouent à la demande, ou directement depuis votre chaîne d'intégration continue. Le verdict sort au format JUnit : vos échecs de tracking s'affichent au même endroit que vos autres tests.

Sur le « des erreurs passent encore », c'est là que ça se joue. Le contrôle est plus fin qu'une relecture humaine : présence de l'événement, type et valeur de chaque paramètre, tag interdit qui ne doit pas partir. Et la restitution vous montre la valeur relevée face à la valeur attendue, avec la capture et la vidéo du parcours joué. Là où un testeur, au bout de trois heures, ne voit plus qu'un identifiant produit est vide.

Ce qui reste humain : décider quoi tester, et arbitrer une alerte. Le reste tourne sans vous.

Plus maintenant. C'est même une des raisons pour lesquelles on sort le plan de marquage d'un fichier. Pour reconstruire ce qui a été perdu, la plateforme part de votre site. Elle vous expose ce qui est réellement collecté sans être documenté, avec le contrôle correspondant déjà proposé, déduit des valeurs observées. Vous reconstruisez depuis le réel, pas depuis la mémoire de quelqu'un. Et si un ancien fichier traîne, même périmé, il sert de point de départ.

Pour ne plus jamais dépendre d'une personne : le référentiel est dans l'outil, versionné, attribué, rejoué automatiquement. Il ne peut plus dériver en silence, donc il ne dépend plus de la vigilance d'un individu.

Le problème n'a d'ailleurs jamais été la documentation manquante. C'était qu'elle ne se vérifiait pas. Celle qui est exécutée. Et comme il n'y a plus de fichier, il n'y a plus de copie.

Une seule configuration vivante, partagée, dont la version en service est celle qui est réellement rejouée sur votre site et qui sert de référence de conformité. La question « laquelle fait foi ? » se répond d'elle-même.

Il supprime.

Ce qui disparaît : la recette du tracking avant chaque mise en production, la vérification URL par URL, la relecture du fichier pour retrouver ce qui était attendu, les captures d'écran justificatives.

Ce qui apparaît : un investissement initial fait une fois, décrire vos parcours et définir vos gabarits. Et un geste nouveau, traiter les alertes.

C'est ce dernier point qu'il faut regarder en face, parce que c'est là que se joue la vraie différence. Vos équipes passent d'un travail de vérification, chercher s'il y a un problème, qui prend des heures et ne trouve pas tout, à un travail de correction : traiter ceux qui ont été trouvés, avec leur périmètre exact et le KPI concerné. Le second est plus court, plus utile, et nettement plus valorisant.

Le seul cas où l'outil ajoute de la charge, c'est si personne ne traite les alertes. Alors elles s'accumulent, et vous avez juste un tableau de bord de plus.

La taille du site compte moins que trois autres facteurs.

Le nombre de personnes qui touchent au tracking. Dès que le marquage est modifié par plusieurs équipes —développement, marketing via le gestionnaire de tags, agences, partenaires— plus personne ne détient l'état réel.

La fréquence des mises en production. À une release par mois, une recette manuelle tient encore. À une release par semaine, elle décroche.

La dépendance de vos décisions à la donnée. Si vous arbitrez des budgets média ou des priorités produit sur vos conversions, le coût d'une donnée fausse dépasse vite celui de l'outil.

En pratique, un site de deux cents pages avec trois équipes et des livraisons hebdomadaires a davantage besoin de gouvernance qu'un site de cent mille pages stable, géré par une seule personne.

Ces fonctions sont utiles, mais elles portent sur ce qui transite par le gestionnaire de tags. Trois limites en découlent.

Le périmètre. Ce quine passe pas par le TMS n'est pas couvert : les tags codés en dur dans le site, les scripts ajoutés par un partenaire, le marquage d'une application mobile.

La nature du contrôle. La validation porte sur la structure des données transmises, pas sur le contexte. Elle ne dira pas qu'un événement d'achat est absent des fiches produit d'un seul site du groupe.

L'indépendance. Le juge est le même que l'exécutant : c'est l'outil qui pose les tags qui déclare qu'ils sont conformes.

Un contrôle externe observe le résultat depuis le navigateur, quelle que soit l'origine du tag, et le confronte à un plan indépendant du TMS. C'est aussi ce qui vous laisse libre de changer de gestionnaire de tags sans perdre votre référentiel.

Un outil de supervision surveille votre infrastructure et votre application : disponibilité, temps de réponse, erreurs serveur. Il vous dira que votre site est debout. Pas que votre événement d'achat a cessé de partir.

Ce sont deux natures de panne différentes. Une rupture de collecte est silencieuse : rien ne tombe, aucune erreur n'est levée, les pages s'affichent normalement. Seule la donnée manque, et elle manque en aval, dans un outil que la supervision ne regarde pas.

Netvigie Tracking couvre précisément cette zone : la conformité de ce qui est collecté au regard de ce qui était attendu. C'est complémentaire d'une supervision, pas concurrent.

C'est l'objection la plus légitime, et la réponse tient en trois points.

Le coût. Vérifier des hits analytics dans un test demande d'intercepter les requêtes réseau, de décoder le format propre à chaque outil (GA4, Piano, chaque régie) et de maintenir tout ça à chaque changement d'implémentation. C'est du code que personne ne veut porter sur la durée.

L'attendu. Un test end-to-end vérifie ce que le développeur a écrit dans le test. Il n'existe aucun référentiel partagé que l'équipe analytics puisse lire, amender et faire évoluer sans passer par le code.

La surveillance. Vos tests s'exécutent quand vous livrez. Or une grande partie des ruptures de collecte n'ont rien à voir avec vos livraisons : un tag modifié dans le TMS, une bannière mise à jour par son éditeur, un prestataire qui change son implémentation.

Ajoutez le lien avec vos KPI, qu'un test ne portera jamais, et la maintenance des sélecteurs, que nous prenons en charge.

Le mode aperçu de Google Tag Manager est un excellent outil de diagnostic. C'est aussi un outil manuel et ponctuel : il vérifie une page, à un instant, pour la personne qui a ouvert la fenêtre. Et il ne connaît pas votre plan de marquage — il montre ce qui part, il ne sait pas ce qui manque.

Trois choses lui échappent structurellement. La couverture : personne ne passe le mode aperçu sur dix mille pages. La répétition : rien ne vous prévient demain matin. La mémoire : aucune trace de ce qui était attendu, ni de ce qui a changé.

Netvigie Tracking ne remplace pas GTM. Il vérifie ce que GTM produit, automatiquement, sur l'ensemble de votre périmètre, et en le confrontant à un attendu écrit.

Un plan de marquage— tracking plan en anglais — décrit ce que votre site ou votre application doit mesurer : quels événements sont collectés (affichage de page, ajout au panier, achat), quels paramètres les accompagnent, et dans quel contexte ils doivent se déclencher.

C'est le contrat entre trois métiers. Le marketing exprime un besoin de mesure, les équipes techniques l'implémentent, les équipes data exploitent le résultat.

Sa forme la plus répandue reste le tableur. C'est aussi sa faiblesse : un tableur ne peut pas vérifier qu'il décrit encore la réalité du site. Un plan de marquage gouverné dans un outil comme Netvigie est exécutable — la définition qui documente est celle qui teste.

La recette analytics est la vérification du tracking avant une mise en production. On parcourt le site, on ouvre l'inspecteur du navigateur ou le mode aperçu du gestionnaire de tags, et on contrôle que chaque événement part avec les bons paramètres.

Elle reste manuelle pour une raison simple : elle demande de reproduire des parcours réels, se connecter, remplir un panier, aller jusqu'au paiement, puis de lire ce qui est envoyé. Aucun test unitaire ne fait ça, et les tests end-to-end existants vérifient l'interface, pas les hits.

Résultat : plusieurs jours par mise en production, des captures d'écran comme preuve, et des erreurs qui passent quand même. C'est exactement ce que Netvigie Tracking automatise.

Un seul de ces signaux suffit :

 • vous ne savez pas dire depuis quand un événement a cessé de partir ;

 • personne ne peut affirmer que votre plan décrit ce qui est réellement collecté aujourd'hui ;

 • plusieurs équipes modifient le marquage (développement, marketing via le TMS, agences) et plus personne ne détient l'état réel ;

 • vous découvrez les ruptures au reporting mensuel ;

 • la recette du tracking prend plusieurs jours et des erreurs passent quand même ;

 • vous arbitrez des budgets média sur des conversions que personne ne garantit ;

 • la personne qui tenait le plan est partie.

Le critère de fond, derrière tous ceux-là : vos décisions dépendent-elles de données dont personne ne peut prouver la fiabilité ? Si oui, le coût d'une donnée fausse dépasse déjà celui de l'outil.

Vous décidez, site par site, qui fait quoi : consulter, modifier la configuration, lancer les contrôles, administrer les accès. Les droits s'emboîtent, et un niveau au-dessus permet aux équipes qui pilotent plusieurs sites de gérer l'ensemble d'un coup.

La répartition habituelle :

 • l'équipe Data détient la modification du plan de marquage, c'est elle qui en répond ;

 • l'IT et la QA lancent les contrôles et lisent les résultats ;

 • le Marketing et le Produit consultent.

Le point qui rassure en pratique : consulter les résultats ne demande qu'un droit de lecture. Vous ouvrez donc la restitution à qui vous voulez, direction comprise, sans que personne puisse toucher au référentiel.

Et la sécurisation ne s'arrête pas aux droits. Une évolution se prépare dans une feature, se teste réellement, puis se fusionne. Ce n'est pas un champ modifié un vendredi soir sans que personne s'en aperçoive : c'est un changement daté, attribué, et vérifié avant d'être appliqué.

Oui aux deux, et c'est le cas d'usage pour lequel le multisite existe.

Vous gérez toutes vos marques dans un même espace, avec un plan de marquage mutualisé. La définition commune est écrite une fois ; les spécificités de chaque marque restent locales. Une correction sur un événement commun profite à tout le monde, une particularité espagnole n'affecte personne d'autre.

La vue consolidée suit. Chaque résultat et chaque alerte portent le site dont ils viennent, et vous interrogez l'ensemble du périmètre depuis un seul endroit. « Ce tag n'échoue que sur la marque espagnole» est une question qui a une réponse immédiate, sans comparer douze rapports.

Côté droits, vous cadrez qui voit et qui modifie quoi, site par site. Chaque équipe travaille sur son périmètre, l'équipe centrale garde la vision d'ensemble.

Et si vos filiales sont réellement autonomes, l'autre organisation reste possible : un espace par marque, cloisonné, avec une lecture consolidée au niveau du groupe.

Depuis un seul espace, avec un seul plan de marquage.

Chaque définition est commune par défaut, spécialisable pour un site donné, ou désactivable localement. Sur trente sites, ça donne :

 • un événement commun se corrige une fois, pour les trente ;

 • une spécificité pays reste isolée ;

 • un même parcours se rejoue sur trente domaines sans être réécrit trente fois.

Le contrôle suit la mutualisation. Chaque résultat et chaque alerte portent leur site, donc l'équipe centrale distingue immédiatement ce qui casse partout, et vient donc probablement d'une définition commune, de ce quine casse que sur un site et relève du local. C'est la distinction qui fait gagner le plus de temps quand on gère un parc.

Résultat : votre charge ne croît pas avec le nombre de sites. Vous décrivez une fois, la plateforme vérifie partout.

Un seul référentiel, partagé, avec des variantes explicites là où c'est nécessaire.

Ce qui est commun est écrit une fois. Ce qui est propre à un site, un tag local, un paramètre supplémentaire, une exception réglementaire, reste local sans dupliquer le reste.

Et la mutualisation ne s'arrête pas à la documentation, c'est là que beaucoup d'outils s'arrêtent. Le contrôle suit : chaque exécution est rattachée à son site et à son environnement, donc un plan mutualisé rend quand même des résultats site par site.

C'est ce qui évite le dilemme habituel : un plan unique qu'on ne peut pas adapter, ou un plan par site qu'on ne peut plus maintenir.

La raison qui poussait à fabriquer des copies disparaît aussi. Quand quelqu'un veut préparer une évolution, il ouvre une feature, c'est-à-dire une branche de configuration. Il l'édite à part, il la teste, il la fusionne. Plus besoin de rouvrir un fichier à côté « en attendant ».

Et chaque évolution reste datée et attribuée : on sait qui a changé quoi, et quand.

Oui, c'est un usage prévu.

Chaque client dispose de son propre espace, avec sa configuration, ses parcours, ses environnements et ses résultats, cloisonnés les uns des autres. Vos consultants accèdent aux espaces dont ils s'occupent, et vous décidez du niveau : consultation, modification de la configuration, lancement des contrôles.

Vous pouvez aussi ouvrir un accès en lecture à votre client, pour qu'il consulte les résultats sans toucher au paramétrage.

L'intérêt pour une agence est double. Industrialiser la recette du tracking, aujourd'hui du temps facturé peu valorisant. Et rendre visible un travail qui l'est rarement, en fournissant la preuve datée que le marquage livré fonctionne, et la couverture des KPI de votre client mois après mois.

Cinq niveaux suffisent :

 • l'outil destinataire (GA4, Piano Analytics, une régie) ;

 • l'événement, avec son intitulé métier et son nom technique exact ;

 • les paramètres attendus, chacun avec son type et son caractère obligatoire ou non ;

 • le contexte de déclenchement : sur quel type de page, à quelle étape du parcours ;

 • la source de la valeur : le data layer, un élément de la page, l'URL.

Le niveau le plus souvent oublié est le quatrième. Un plan qui liste les événements sans dire où ils sont attendus n'est pas vérifiable, et un plan non vérifiable finit toujours par être faux.

Un sixième niveau fait la différence entre une documentation et une gouvernance : à quel indicateur métier chaque élément contribue. C'est ce qui permet de dire «ce paramètre alimente notre CA e-commerce», et donc de savoir ce que vous perdez quand il casse.

En cessant de le maintenir à la main. À ce rythme, aucune équipe ne tient une documentation à jour par discipline : elle se périme entre deux releases.

La réponse est de faire du plan la référence exécutée. Il est rejoué à chaque cycle, et tout écart remonte immédiatement. Vous n'avez alors que deux gestes possibles, corriger le site ou mettre le plan à jour, et dans les deux cas la documentation redevient exacte. Deux mécanismes rendent le rythme soutenable. Les nouveaux événements observés vous sont proposés avec leur contrôle déjà déduit des valeurs réelles. Et un parcours existant ne se recasse pas à chaque release : une simple évolution de l'interface est distinguée d'une vraie régression.

À ce rythme-là, le plan de marquage cesse d'être une dette qui s'accumule.

Le plan de marquage est l'intention : ce que vous avez décidé de mesurer. Le data layer est un moyen : la structure technique par laquelle le site met ses données à disposition des tags.

On peut avoir un data layer impeccable et un plan de marquage faux, si personne n'a écrit ce qui était attendu. On peut avoir un plan de marquage impeccable et un data layer incomplet, et c'est le cas le plus fréquent.

Un outil de gouvernance couvre les deux : il porte le plan (les événements, leurs paramètres, leur contexte) et il contrôle ce que le data layer expose réellement, page après page.

Documenter, c'est écrire ce qu'on veut mesurer. Gouverner, c'est organiser la vie de ce document : qui a le droit de le modifier, comment une évolution se prépare et se valide, comment on sait ce qui a changé et quand. Et surtout, comment on vérifie qu'il est respecté. 

La différence se voit à l'usage. Une documentation se périme sans que personne s'en aperçoive : vraie le jour où on l'écrit, fausse six mois plus tard, et rien ne le signale. Une gouvernance rend cette dérive visible —chaque écart entre le plan et le site est remonté, daté et attribué.

C'est ce que fait un outil de gouvernance du plan de marquage comme Netvigie Tracking : un référentiel unique, versionné, avec des droits, et confronté en permanence à ce que le site fait vraiment.

Oui, dans les deux sens.

Côté travail, votre charge ne croît pas avec le nombre de sites. Une définition commune est écrite une fois et s'applique partout : ajouter un site, c'est déclarer ses spécificités, pas réécrire le plan.

Côté offre, le volume contrôlé est ce qui détermine votre consommation. Vous montez quand votre périmètre monte, et vous n'achetez pas par anticipation. Le dimensionnement se réajuste avec nos équipes quand vos besoins évoluent.

Et le référentiel absorbe la croissance : les nouveaux événements qui apparaissent sur votre site vous sont proposés avec leur contrôle déjà déduit des valeurs observées. Vous n'avez pas à tout redéclarer à chaque campagne.

Par les droits, qui se posent site par site et par niveau.

Vous donnez à votre agence l'accès aux sites dont elle s'occupe, et vous choisissez ce qu'elle peut faire : consulter seulement, modifier la configuration, ou lancer les contrôles. Elle ne voit rien du reste de votre périmètre. Le point qui rassure en pratique : consulter les résultats ne demande qu'un droit de lecture. Vous pouvez donc ouvrir la restitution à un prestataire sans lui donner la main sur le référentiel.

Et comme chaque évolution est datée et attribuée, vous savez toujours qui a modifié quoi. Un prestataire qui part ne laisse pas de zone d'ombre : son travail est dans le référentiel, pas dans sa tête.

Oui, sur les trois.

SSO. Connexion fédérée via votre fournisseur d'identité. Il s'impose au niveau du domaine email : une fois votre domaine revendiqué, tous les comptes concernés passent exclusivement par votre fournisseur et les mots de passe locaux sont neutralisés. Aucun compte n'est créé au login — un email inconnu, ou non invité, est refusé.

Gestion centralisée des accès. Les droits se posent sur deux étages, l'espace de travail et chaque site suivi, avec des rôles qui vont de la lecture seule à l'administration. Retirer tous les droits d'une personne la détache : il n'y a pas de geste séparé qu'on risque d'oublier au départ d'un collaborateur.

Journal d'audit. Les actions sont tracées par utilisateur, avec date, action et contexte. Et la configuration elle-même est versionnée : chaque évolution du plan de marquage est datée et attribuée à son auteur. C'est souvent la trace que l'on cherche vraiment quand on demande un journal d'audit.

Pour les comptes qui restent en mot de passe, un second facteur est disponible.

Oui.

 Vous déclarez vos points de collecte serveur, et tout appel reconnu pendant un contrôle est rattaché à la session en cours. Il est ensuite vérifié comme n'importe quel hit navigateur : présence de l'événement, type et valeur de chaque paramètre.

Google Tag Manager server-side est couvert, les autres plateformes aussi, en proxy comme en natif.

C'est un point à regarder de près au moment de choisir un outil. Passer ses tags côté serveur, c'est gagner en performance et en maîtrise, et perdre la recette : ce qui part du serveur n'apparaît plus dans l'inspecteur du navigateur. Beaucoup d'équipes découvrent cet angle mort après la migration.

Oui, et c'est une des raisons d'être du produit : le type de page est au cœur du modèle Netvigie Tracking. Vos pages se rangent automatiquement dans leurs gabarits : accueil, page de liste, fiche produit, panier, étape de tunnel. Un site de dix mille pages en compte rarement plus d'une quinzaine.

Et vos exigences se posent gabarit par gabarit. « Sur une fiche produit, le data layer doit porter la référence, le prix et la disponibilité. » Pas une règle uniforme sur tout le site, qui n'a de sens nulle part et que personne ne peut tenir.

Le contrôle suit le même découpage. Vous ne recevez pas« le data layer a des problèmes ». Vous recevez « la référence produit manque, uniquement sur les pages de liste, uniquement sur le site espagnol ». C'est le niveau où un développeur peut agir tout de suite.

C'est aussi ce qui rend le contrôle tenable à grande échelle : vous décrivez quinze gabarits une fois, la plateforme les vérifie sur dix mille pages à chaque passage.

Aucun, et pour une raison simple : nous ne déployons rien sur vos pages.

C'est le choix qui nous sépare des approches RUM, qui posent un script chez vos visiteurs pour observer le trafic réel. Elles doivent arbitrer en permanence entre finesse de mesure et poids du script. Nous n'avons pas cet arbitrage à faire.

Nos contrôles tournent dans nos navigateurs, depuis nos datacenters français et allemands, sur votre site public comme sur votre préproduction. Vos Core Web Vitals ne bougent pas d'un millième. Et vous y gagnez trois fois :

 • rien à faire valider par votre DSI, rien à caser dans une release : vous démarrez quand vous voulez ;

 • aucune donnée de vos visiteurs ne transite chez nous, puisque nous mesurons nos propres sessions. Pas de traitement supplémentaire à inscrire à votre registre ;

 • vous contrôlez ce qui n'est pas encore en ligne, ce qu'aucun script posé en production ne saura jamais faire.

Le trafic réel apporte une chose que le test ne reproduit pas : la variété. Des combinaisons d'appareils et de navigateurs inattendues, des contenus rares, des comportements que personne n'avait imaginés, la distribution réelle des valeurs collectées.

C'est le vrai avantage des approches RUM, et il se paie : un script chez vos visiteurs, un traitement de données personnelles à encadrer, et une dépendance à ce que les visiteurs ont fait cette semaine.

Notre réponse est différente. Le périmètre est explicite et s'élargit par décision : les parcours que vous jugez critiques, vos gabarits de page, les listes d'URL à couvrir à coup sûr. Vous ne dépendez pas du hasard pour savoir si votre tunnel de réservation fonctionne.

Et vous gagnez ce que l'observation ne donne pas : la reproductibilité. Quand un contrôle échoue, il échoue dans des conditions connues, donc l'écart est imputable. Une baisse observée sur du trafic réel, elle, peut toujours être un changement d'audience. Il faut enquêter pour savoir s'il s'agit d'un bug ou d'un marché.

Quatre choses, et elles sont essentielles.

Ce qui n'est pas encore en ligne. Une préproduction n'a pas de visiteurs à observer. L'erreur se corrige donc avant la mise en production, pas après.

Un parcours qu'aucun visiteur n'a emprunté cette semaine. La fonctionnalité tout juste lancée, le tunnel d'un pays secondaire, le formulaire de rappel. C'est souvent là que le tracking est cassé depuis des mois sans que personne le sache.

Un tunnel authentifié rejoué à l'identique, avec les mêmes données, jusqu'au paiement.

Le refus de consentement. On ne peut pas demander à de vrais visiteurs de refuser pour vérifier que les tags se taisent. Un pan entier de votre conformité n'est vérifiable qu'en synthétique.

S'y ajoute le déterminisme. Le même parcours rejoué dans les mêmes conditions permet d'affirmer « ça a cassé entre hier et aujourd'hui ». C'est une certitude, pas une hypothèse à instruire.

Parce que les deux moments n'attrapent pas les mêmes pannes.

Le contrôle avant mise en ligne attrape ce que vous venez de casser. Il se déclenche depuis votre chaîne de déploiement, sur une préproduction, et peut bloquer la livraison avant qu'elle n'atteigne vos visiteurs.

La surveillance continue attrape ce que vous n'avez pas touché. Un tag modifié par un prestataire. Une publication faite dans le gestionnaire de tags par le marketing, un vendredi à 18h. Une bannière de consentement mise à jour par son éditeur. Un partenaire qui change son implémentation. Aucun de ces événements ne passe par votre pipeline de développement, et ils représentent une grande partie des ruptures constatées.

S'arrêter au premier, c'est ne protéger que la moitié des causes.

Chez nous, c'est la même configuration et le même moteur dans les deux cas. Vous décrivez vos parcours une fois, vous choisissez quand ils sont joués.

Le marché se partage en deux familles.

Les outils d'observation du trafic déduisent votre tracking du comportement de vos visiteurs. Ils voient la variété du réel, au prix d'un script déployé sur vos pages, et ils ne voient que ce que les visiteurs ont fait.

Les outils synthétiques exécutent des contrôles dans des navigateurs pilotés. Ils ne déploient rien, et voient ce que vous décidez de contrôler, y compris ce qui n'est pas en ligne.

Ceux qui revendiquent les deux le font en ajoutant l'observation à l'audit. Ils reviennent donc au script sur vos pages, avec la validation technique et les données visiteurs que ça implique.

Netvigie Tracking appartient à la seconde famille, et l'assume. Trois contrôles sont impossibles autrement : la préproduction, le parcours authentifié, et le refus de consentement. Ce sont aussi les trois qui vous exposent le plus.

Et nous ajoutons une dimension que ni l'une ni l'autre famille ne couvre habituellement : le lien entre ce qui est contrôlé et vos indicateurs métier.

Jusqu'au bout de la chaîne, avec un seul plan de marquage.

Server-side. Vous déclarez vos points de collecte serveur, et les appels qu'ils déclenchent pendant un contrôle sont vérifiés comme n'importe quel hit navigateur. GTM server-side est couvert, les autres plateformes aussi. Vous ne perdez donc pas la visibilité au moment précis où la plupart des équipes la perdent : en passant leurs tags côté serveur.

Apps mobiles. Une app est un objet de plein droit, pas une adaptation du web. La version installée remplace l'URL comme point d'entrée, les parcours se jouent sur de vrais appareils, et le plan de marquage reste commun à iOS et Android : ses variations sont portées par des conditions, pas par un second plan à maintenir.

Une seule définition d'« ajout au panier », contrôlée sur le web, sur iOS, sur Android et côté serveur. Et un seul KPI « taux de conversion » qui les agrège, quelle que soit la couche où la chaîne casse.

Il s'adapte sur les événements, il vous demande votre avis sur les parcours.

Les nouveaux événements sont repérés sans que vous touchiez à quoi que ce soit. Ce qui apparaît sur votre site et que rien ne documente vous est présenté, avec le contrôle déjà proposé, déduit des valeurs réellement observées. Il vous reste à l'accepter. Ce geste est volontaire : sans lui, votre plan finirait par décrire vos bugs comme s'ils étaient l'intention. Les nouveaux parcours se déclarent. La plateforme peut explorer votre site et vous proposer ceux qui mériteraient d'être surveillés, mais l'arbitrage reste le vôtre.

Sur l'existant, la bonne nouvelle : un parcours déjà décrit ne casse pas à chaque release. Quand un élément de page change, la plateforme distingue une simple évolution de l'interface, qu'elle sait rattraper avec votre accord, d'une vraie régression qui doit vous alerter. C'est exactement ce qui fait abandonner les équipes qui ont tenté de monter ces tests en interne : la maintenance finit par coûter plus cher que la recette manuelle.

Ce n'est pas un obstacle, mais ça demande une autorisation explicite— comme pour n'importe quel outil de test automatisé.

Nos contrôles s'exécutent depuis des datacenters identifiés en France et en Allemagne. Il suffit de les autoriser dans votre pare-feu applicatif ou votre protection anti-bot. C'est un réglage à faire une fois, au démarrage, et il figure dans la liste des prérequis.

Sans cette autorisation, la protection bloque les contrôles. Vous le savez immédiatement, plutôt que d'obtenir des résultats faux.

Oui, et c'est même un des cas où le contrôle automatisé est le plus utile.

Les applications monopages compliquent le tracking pour une raison connue : la navigation ne recharge pas la page, donc les événements de vue de page doivent être émis parle code applicatif, au bon moment. Les oublis et les doublons sont fréquents, et une refonte de composant les réintroduit facilement.

Netvigie Tracking pilote un vrai navigateur et suit le parcours comme un internaute. Les changements de vue sans rechargement, les contenus chargés à la demande, les interactions asynchrones sont observés tels qu'ils se produisent.

C'est la différence avec une analyse statique du code ou une lecture du seul HTML initial, qui ne voient rien de ce qui se passe après le premier affichage.

Vous déclarez des jeux de données —identifiants, mots de passe, adresses, références produit —que les parcours consomment à l'exécution. Une valeur peut être propre à un environnement : le même parcours joue avec un compte de préproduction en préproduction et un compte de production en production.

Un jeu de données peut être déclaré exclusif : une même valeur ne sera jamais utilisée par deux exécutions simultanées. C'est ce qui évite les collisions classiques, comme deux contrôles qui alimentent le même panier en même temps.

En pratique, un ou deux comptes de test dédiés suffisent à couvrir vos parcours critiques.

Non. Un parcours désigne les éléments de la page par des sélecteurs, et un changement de design en déplace certains. C'est le coût de maintenance classique des tests automatisés, et la raison pour laquelle beaucoup d'équipes finissent par les abandonner.

Netvigie Tracking traite ce cas spécifiquement. Quand une action ne retrouve plus son élément, la plateforme distingue les causes. Une simple évolution de l'interface, où l'élément est toujours là mais désigné autrement, est identifiée comme telle et un nouveau sélecteur vous est proposé, appliqué seulement avec votre accord. Une vraie régression, un élément disparu ou une étape amont quine produit plus son effet, est signalée comme un problème à corriger.

La distinction est essentielle : elle évite les deux dérives habituelles, la maintenance sans fin et la réparation automatique qui masque un vrai bug.

Oui, et c'est même un de nos points forts face aux outils qui observent le trafic.

La notion d'environnement est native : production, préproduction, recette, chacun avec ses propres adresses. Un même parcours se rejoue sur l'un ou l'autre sans être réécrit.

Si votre préproduction est protégée par une authentification, elle se traite comme n'importe quel parcours authentifié, avec un compte de test.

Si elle est fermée par filtrage réseau, il suffit d'autoriser nos exécutions : elles partent de datacenters identifiés en France et en Allemagne. C'est un réglage à faire une fois, au démarrage.

Deux approches, souvent combinées.

Contrôler le tunnel jusqu'à l'étape qui précède le paiement. La majorité des événements de conversion (vue du panier, début de commande, informations de livraison, choix du mode de paiement) se déclenchent avant la transaction elle-même. C'est déjà l'essentiel du tunnel. La validation de commande est également possible mais nécessite une exclusion automatique dans votre back office.

Jouer une vraie commande sur un environnement de test, avec un moyen de paiement de test. C'est le moyen le plus simple de vérifier l'événement d'achat lui-même, celui qui porte le montant et qui alimente votre CA e-commerce.

Le choix se fait avec vos équipes, selon ce que votre environnement de test permet. Dans les deux cas, vos parcours consomment des jeux de données dédiés : vous ne testez jamais avec un vrai compte client.

En rejouant le même parcours dans l'état «refus », puis en vérifiant que les tags concernés sont bien absents.

Vous décrivez les états de consentement : tout accepter, tout refuser, et les variantes de finalités qui vous concernent. Un parcours met la page dans l'état voulu avant le contrôle. Vous déclarez ensuite qu'en cas de refus, tel tag doit être absent. Tout tag qui part malgré tout est un manquement localisé, avec la capture et la vidéo du parcours pour le prouver. 

Ce contrôle est rare sur le marché, et pour une raison structurelle : on ne peut pas demander à de vrais visiteurs de refuser. Un outil qui observe le trafic ne voit donc quasiment jamais le cas qui vous expose le plus.

Pas dans GA4 : ses rapports montrent ce qui est arrivé, jamais ce qui manque. Le mode aperçu de Google Tag Manager et Tag Assistant permettent un contrôle ponctuel, page par page, à la main.

Pour un contrôle systématique, il faut confronter les hits GA4 à un plan déclaré. Chaque événement attendu est-il présent, sur le bon type de page et à la bonne étape ? Chaque paramètre est-il renseigné, du bon type, avec une valeur plausible ? Aucun événement ne part-il en double ?

Netvigie Tracking décode le contenu des hits GA4 et applique ces contrôles automatiquement, sur les pages et les parcours que vous avez désignés. Y compris sur une préproduction, et dans plusieurs états de consentement.

En décrivant une fois les parcours à vérifier, puis en les rejouant automatiquement sur la préproduction avant chaque mise en ligne.

Les parcours s'enregistrent, ou se décrivent par une consigne en français. Les exigences du plan se posent par gabarit de page et par étape. Le contrôle se déclenche à la demande ou depuis votre chaîne d'intégration continue, et rend un verdict exploitable : une régression de marquage fait échouer la livraison.

Ce que vous gagnez n'est pas seulement du temps. C'est la fin des erreurs qui passent parce qu'un testeur, au bout de trois heures de recette, ne voit plus qu'un identifiant produit est vide.

En jouant vos pages et vos parcours, puis en listant tout ce qui a été observé.

Vos outils d'analytics, mais aussi les régies, les pixels d'affiliation, les scripts de retargeting, y compris ceux qu'aucune documentation ne mentionne. La reconnaissance s'appuie sur une base de signatures mise à jour quotidiennement : même un tag que personne dans l'équipe ne sait nommer est identifié.

L'inventaire fonctionne dans les deux sens. Ce qui part sans être déclaré, et ce qui est déclaré mais ne part plus. C'est entre ces deux listes que se prennent les décisions : couper un tag oublié, corriger un tag mort.

Et contrairement à un audit ponctuel, celui-ci se refait tout seul à chaque contrôle. Votre inventaire ne se périme pas le lendemain de sa livraison.

C'est le cas le plus fréquent, et le plus difficile à voir : rien ne casse, un volume baisse. Dans un rapport analytics, une absence ressemble à une baisse d'audience, et se discute pendant des semaines.

La seule façon de le détecter tôt est de déclarer l'attendu, puis de le vérifier régulièrement. Netvigie rejoue vos pages et vos parcours à l'intervalle que vous choisissez, et l'absence d'un événement attendu ouvre une alerte.

Vous savez alors non seulement que le tag ne part plus, mais depuis quand, à la minute, et où précisément : sur tous les sites ou seulement l'un d'eux, sur toutes les fiches produit ou seulement celles d'une marque. Et quels indicateurs métier en dépendent.

Par un appel depuis votre pipeline, avec une clé d'API.

Le principe est celui de n'importe quel test automatisé. Le pipeline déclenche le contrôle, récupère un identifiant d'exécution, attend le verdict (par interrogation régulière ou par rappel HTTP), puis décide de poursuivre ou d'échouer la livraison.

Le verdict sort au format JUnit, donc directement lisible par GitHub Actions, GitLab CI, Jenkins ou CircleCI. Vos échecs de tracking s'affichent au même endroit que vos autres tests, avec le détail de ce qui était attendu.

C'est le geste qui change la nature du sujet : le tracking cesse d'être le seul périmètre non testé de votre produit.

Piano Analytics a ses propres conventions : des événements et des propriétés, et un format de hit distinct de celui de Google. Un outil conçu autour de l'écosystème Google le détecte au mieux comme un tag tiers, sans lire ce qu'il transporte. Vous voyez alors qu'un tag est parti, sans savoir s'il a envoyé les bonnes données.

Netvigie décode ces hits nativement et traite Piano au même niveau que GA4, événement par événement et propriété par propriété. Vous vérifiez donc qu'un événement d'achat porte bien son montant, sa devise et ses références produit, sur les gabarits et les parcours concernés.

Un plan de marquage Piano prêt à l'emploi est disponible à l'import, ce qui vous évite de tout déclarer à la main.

C'est faire jouer un parcours par un navigateur piloté, dans des conditions que vous choisissez, plutôt que d'observer ce que font vos visiteurs. Appliqué au tracking : on rejoue la fiche produit, l'ajout au panier, le paiement, et on vérifie que les événements attendus partent avec les bons paramètres.

L'avantage est le contrôle. Vous décidez du parcours, de l'environnement, de l'état de consentement et de la fréquence. Vous pouvez donc contrôler une préproduction avant la mise en ligne, rejouer un tunnel authentifié à l'identique, et vérifier ce qui se passe quand l'internaute refuse les cookies. Trois choses impossibles en observant du trafic réel.

Et rien n'est déployé sur vos pages.

Le tracking server-side consiste à faire partir les hits depuis un serveur que vous contrôlez, et non depuis le navigateur de l'internaute. Google Tag Manager server-side en est l'exemple le plus courant. On y gagne en performance, en résistance aux bloqueurs de publicité, et en maîtrise de ce qui est transmis aux tiers.

Le revers est un angle mort : ce qui part du serveur n'apparaît plus dans l'inspecteur du navigateur. Beaucoup d'équipes perdent leur capacité de recette au moment même où elles gagnent en maîtrise.

Netvigie Tracking couvre ce cas. Vous déclarez vos points de collecte serveur, et les appels qu'ils déclenchent pendant un contrôle sont vérifiés comme n'importe quel hit navigateur.

Un gabarit de page, ou template, est le type auquel appartient une page : accueil, page de liste, fiche produit, panier, étape de tunnel. Un site de dix mille pages en compte rarement plus d'une quinzaine.

C'est la bonne maille parce que les exigences ne sont pas les mêmes partout. Une fiche produit doit porter une référence et un prix, une page de liste doit porter un nombre de résultats. Une exigence uniforme sur tout le site n'a de sens nulle part, et personne ne peut la tenir.

Chez Netvigie Tracking, vos pages sont classées automatiquement par gabarit et les règles se posent par gabarit. C'est ce qui permet à une alerte de dire « le data layer est incomplet uniquement sur les pages de liste», au lieu de « le data layer a des problèmes».

Oui, c'est natif. L'environnement est un axe de premier plan, pas un paramètre.

Vous déclarez vos environnements —dev, recette, préproduction, production — chacun avec ses propres adresses. Un même parcours s'y rejoue sans être réécrit, et vos jeux de données suivent : le parcours joue avec un compte de recette en recette, un compte de production en production.

Les règles s'adaptent de deux façons. Vous choisissez ce que vous contrôlez sur chaque environnement : inutile de vérifier vos tags publicitaires sur la dev. Et vous ajustez la fréquence, par exemple un contrôle déclenché à chaque livraison sur la préproduction, et une surveillance continue sur la production.

Enfin, l'environnement est un axe de restitution. Une alerte dit « uniquement en préproduction »quand c'est le cas, ce qui évite de mobiliser quelqu'un en urgence sur un problème qui n'atteint aucun visiteur.

Oui, de deux façons.

Par l'horodatage. L'alerte porte l'instant exact de sa première apparition. Comme la surveillance peut tourner à quelques minutes d'intervalle, la fenêtre de suspicion se réduit d'autant : « l'anomalie apparaît à 14h07, votre livraison est de 14h05 » suffit à conclure. Le recoupement avec votre journal de déploiements est immédiat.

Par le déclenchement, et c'est mieux. Faites lancer le contrôle par votre chaîne de déploiement elle-même : le lien avec la livraison devient explicite, et surtout l'anomalie est vue avant la mise en ligne plutôt qu'attribuée après coup.

Ce que ça change dans une organisation : la discussion où personne ne peut prouver quelle release a cassé la collecte s'arrête.

Oui, et l'indicateur existe : la couverture de vos KPI.

Vous déclarez vos indicateurs métier, vous leur rattachez les éléments du plan dont ils dépendent, et la plateforme vous dit lesquels sont réellement sous contrôle. La lecture est immédiate : huit de vos douze indicateurs sont sous cloche, trois ne sont couverts qu'en partie, un ne l'est pas du tout.

C'est une phrase qui passe en comité, parce qu'elle parle d'indicateurs métier et pas d'erreurs techniques.

Et voilà ce qui la rend défendable quand quelqu'un creuse : elle repose sur des contrôles explicites que vous avez définis, pas sur une note de confiance calculée par un algorithme. À la question « ce chiffre, il mesure quoi exactement ? », vous ouvrez la liste des règles qui le composent et le périmètre sur lequel elles ont été vérifiées.

Détail utile : cette couverture se calcule sans lancer le moindre test. Elle se lit sur votre configuration seule.

Par deux courbes que vous suivez mois après mois : la couverture de vos KPI, et le volume d'anomalies sur le périmètre contrôlé. La première est la plus parlante. Elle monte quand vous fiabilisez, et elle descend mécaniquement quand votre site s'enrichit sans que le plan suive. C'est un indicateur de maturité, pas un compteur de pannes.

La seconde s'appuie sur l'historique. Chaque contrôle laisse un résultat daté et immuable, avec le détail du périmètre vérifié. Cet historique se constitue tout seul, sans geste de votre part.

Un choix de conception le rend réellement exploitable dans la durée : les libellés sont figés au moment du contrôle. Un gabarit renommé ou supprimé six mois plus tard laisse des résultats toujours lisibles, parce qu'ils décrivent la configuration réellement jouée ce jour-là. C'est ce qui manque à la plupart des historiques, qui deviennent illisibles dès la première refonte.

Vous suivez donc une tendance sur un an, au lieu de réagir aux incidents du jour.

C'est l'écart entre ce que vous avez décidé de collecter et ce qui est réellement collecté.

Elle ne se mesure donc pas dans GA4 ou Piano Analytics. Leurs rapports montrent ce qui est arrivé, jamais ce qui manque : une absence y ressemble à une baisse d'audience.

Elle se mesure en confrontant le plan de marquage au site. Chaque événement attendu est-il présent, à l'endroit prévu ? Chaque paramètre est-il renseigné, du bon type, avec une valeur cohérente ? Aucun tag interdit ne part-il quand l'internaute a refusé le consentement ?

L'indicateur le plus lisible est la couverture de vos KPI : combien de vos indicateurs métier reposent sur des données réellement contrôlées, et lesquels ne le sont pas encore. La data quality cesse alors d'être une impression pour devenir un chiffre.

Oui. C'est même le principe : Netvigie Tracking ne vous impose aucun standard, il exécute le vôtre.

Une règle se compose de trois choses. L'événement attendu, les paramètres qui doivent l'accompagner, et le contexte où l'exigence s'applique : tel gabarit de page, telle étape de parcours, tel état de consentement.

Sur chaque paramètre, vous choisissez le niveau d'exigence. Présent. D'un type donné. Égal à une valeur précise. Cohérent avec une donnée collectée ailleurs sur la page. Vous pouvez aussi déclarer l'inverse, c'est-à-dire qu'un tag doit être absent dans un contexte donné.

 Vos conventions de nommage, vos règles de casse, vos formats maison : tout ça se déclare.

Et comme les règles sont versionnées et attribuées, vos standards deviennent un référentiel partagé plutôt qu'un document que chaque équipe interprète à sa façon.

En reliant votre plan de marquage à vos indicateurs.

Vous déclarez vos KPI dans l'outil (taux de conversion, CA e-commerce, performance des mises en avant) et vous leur rattachez les éléments du plan dont ils dépendent : les événements, les paramètres, les règles. Ce sont les ingrédients du KPI.

À partir de là, chaque anomalie sait quels indicateurs elle met en danger. L'alerte ne dit plus « le paramètre montant est absent sur l'événement d'achat ». Elle dit «votre CA e-commerce et votre panier moyenne sont plus garantis, sur les fiches produit du site espagnol, depuis mardi 14h ».

Vous obtenez donc les trois éléments dont dépend tout chiffrage : quel indicateur, sur quel périmètre exactement, et depuis quand, à la minute près.

Le calcul du montant, lui, reste chez vous, et c'est volontaire. Netvigie Tracking ne recalcule pas vos indicateurs : c'est le travail de Piano ou de GA4. Nous garantissons la donnée qui les alimente, et nous vous donnons la durée et l'étendue exactes. Vous seul connaissez la valeur d'une semaine de conversions faussées sur vos fiches produit.

Parce que votre plan de marquage et vos KPI vivent dans le même outil, reliés l'un à l'autre.

Vous déclarez vos indicateurs et vous leur rattachez les éléments du plan dont ils dépendent. Une anomalie sait donc immédiatement quels KPI elle met en danger, et un même paramètre peut en menacer plusieurs : ils sont tous affichés.

 Sur vos trois questions :

 • quel KPI : ceux qui portent l'élément en cause comme ingrédient ;

 • depuis quand : la date de première observation, à la minute, jamais modifiée après coup ;

 • avec quel impact : le périmètre exact, calculé par contraste avec ce qui fonctionne. «Uniquement sur les fiches produit du site espagnol » et « sur l'ensemble du tunnel, tous sites confondus» n'appellent pas la même réaction.

La différence avec un outil de suivi de tags tient en un mot : vous ne recevez pas un symptôme, vous recevez un diagnostic. Et il ne se regénère pas à chaque passage —une alerte vit, se résout et se clôt.

En reliant votre plan de marquage à vos indicateurs.

Vous déclarez vos KPI dans l'outil et vous leur rattachez les éléments du plan dont ils dépendent : les événements, les paramètres, les règles. Ce sont les ingrédients du KPI.

Dès lors, toute anomalie sait ce qu'elle met en danger. L'alerte ne dit plus « le paramètre montant est absent sur l'événement d'achat», elle dit « votre CA e-commerce et votre panier moyen ne sont plus garantis, sur les fiches produit du site espagnol, depuis mardi 14h ». Un même paramètre peut menacer plusieurs indicateurs : ils sont tous affichés.

 Netvigie Tracking ne recalcule pas la valeur de vos KPI, c'est le travail de Piano ou de GA4. Il garantit la donnée qui les alimente, et vous dit précisément quoi, où et depuis quand.

Par les KPI menacés, qui sont affichés sur chaque alerte. Vous déclarez vos indicateurs et vous leur rattachez les éléments du plan dont ils dépendent. Une alerte qui touche votre taux de conversion ne se traite donc pas comme une alerte sur un libellé de page, et la distinction est immédiate, sans expertise technique.

 S'y ajoutent trois critères que l'alerte porte :

 • son ampleur, la proportion réelle d'échecs sur ce qui a été contrôlé ;

 • son étendue — un problème cantonné à une préproduction ou à un gabarit rare ne pèse pas comme un problème sur toutes les fiches produit en production ;

 • son ancienneté.

Le montant en euros, lui, se calcule avec vos données. Netvigie Tracking vous donne l'indicateur touché, le périmètre exact et la durée ; vous seul connaissez la valeur d'une semaine de conversions faussées sur ce périmètre.

Les quatre, et dans cet ordre de fréquence.

Les décisions faussées. Le risque le plus coûteux, et le moins visible. Un mois de conversions mal collectées, ce sont des budgets déplacés vers les mauvais canaux, des tests A/B conclus à l'envers, des priorités produit réorientées sur un signal inexistant. Et il faut ensuite refaire les analyses.

Le média mal piloté. Vos plateformes publicitaires optimisent sur les conversions que vous leur remontez. Une conversion qui ne part plus, c'est un algorithme qui apprend sur des données incomplètes— et l'effet dépasse largement la durée de la panne.

La perte de chiffre d'affaires. Indirecte mais réelle : un tunnel dont la mesure casse, c'est une optimisation qu'on ne fait pas et un problème d'expérience qu'on ne voit pas.

La non-conformité. Des tags qui se déclenchent malgré un refus de consentement vous exposent. C'est le seul des quatre qui peut devenir une sanction.

Ce que Netvigie Tracking réduit dans les quatre cas, c'est la même chose : la durée d'exposition. De plusieurs semaines à quelques minutes.

Nous avons peu de faux positifs à filtrer, parce que nous en produisons peu.

La différence tient à ce qu'on observe. Un outil branché sur le trafic réel voit passer des navigateurs obsolètes, des extensions qui bloquent les tags, des connexions qui lâchent : autant d'anomalies qui n'en sont pas. Nous rejouons un parcours que vous avez décrit, dans un navigateur que nous maîtrisons, dans un état de consentement choisi. Les conditions sont les mêmes à chaque passage. Ce qui change vient de votre site, pas de l'environnement.

S'ajoute la répétition : un échec isolé est rejoué avant d'être retenu. Le site qui tousse une fois ne réveille personne. Pour autant, rien n'est mis de côté. Une alerte s'ouvre dès le premier échec constaté, avec ses preuves attachées. Ce qui attend confirmation, c'est la notification, pas la détection : vous ne découvrirez jamais qu'un vrai problème avait été écarté en silence. Et une alerte ne se referme pas parce qu'un passage est repassé au vert. Il faut que la disparition soit établie.

En pratique, ce qui détermine ce que vous voyez n'est donc pas un réglage de sensibilité, mais l'étendue de ce que vous faites contrôler.

QA : le tracking entre dans le pipeline. Le contrôle se déclenche depuis la chaîne d'intégration continue et rend un verdict au format JUnit. Une régression de marquage fait échouer la livraison, comme un test unitaire. La checklist manuelle disparaît, et le tracking cesse d'être le seul périmètre non testé du produit.

Data : l'écart n'est plus découvert au reporting. L'alerte nomme l'élément en cause, affiche la valeur relevée face à celle attendue, porte sa date d'apparition et les KPI menacés. L'équipe passe de l'enquête à la correction.

Produit : « la mesure de cette fonctionnalité est-elle en place ? »devient vérifiable avant la mise en ligne, sur la préproduction, et dans les deux états de consentement. On ne lance plus une fonctionnalité en espérant pouvoir en mesurer l'usage. Et pour les trois, le même changement de posture : la mise en production cesse d'être un moment d'angoisse sur le tracking.

Celle qui menace le KPI le plus important pour vous. Et l'alerte vous le dit.

Chaque alerte porte les éléments qui décident d'une priorité :

 • les KPI qu'elle met en danger. C'est le premier critère, et le seul qui parle à tout le monde autour de la table ;

 • son ampleur, c'est-à-dire la proportion réelle d'échecs sur ce qui a été contrôlé. Un événement absent une fois sur cent n'est pas un événement absent partout ;

 • son étendue : un problème cantonné à une préproduction ou à un gabarit rare ne pèse pas comme un problème sur toutes les fiches produit en production ;

 • son ancienneté ;

 • sa nature : un tag qui part malgré un refus de consentement est un risque réglementaire, un libellé mal orthographié attendra.

Vous arbitrez donc sur des faits, pas sur une pile d'erreurs indifférenciées où le plus grave et le plus bénin se présentent de la même façon.

Parce qu'ils regardent la même alerte.

Une alerte Netvigie Tracking est un objet à part entière, pas une ligne dans un rapport. Elle porte son numéro, ce qui était attendu (la règle telle que vous l'avez écrite) et ce qui s'est réellement passé : la valeur relevée, la capture de la page, le contenu exact du hit. Elle porte aussi son périmètre (ce site, cet environnement, ce gabarit, cette étape du parcours) et sa date de première apparition.

Le développeur y trouve la cause et l'endroit. Il n'a pas d'enquête à mener : l'attendu et le réel sont côte à côte.

Le métier y trouve les KPI mis en danger. C'est là que la jonction se fait. Vos indicateurs sont déclarés dans l'outil avec les éléments du plan de marquage dont ils dépendent, et chaque alerte affiche donc ceux qu'elle menace. La même alerte se lit «paramètre manquant sur l'événement d'achat » d'un côté, «votre CA e-commerce n'est plus garanti » de l'autre.

Le gain est très concret : la réunion ne commence plus par dix minutes à établir de quel problème on parle.

Les quatre, pour des raisons différentes.

L'équipe Data détient le plan de marquage et répond de la fiabilité des chiffres. C'est l'utilisateur principal.

Les équipes techniques et la QA intègrent le contrôle dans leur chaîne de livraison, et cessent d'apprendre trois semaines plus tard qu'une livraison avait cassé la collecte.

Le Produit vérifie que la mesure d'une fonctionnalité est en place avant son lancement, pas pendant l'analyse de ses résultats.

Le Marketing pilote ses investissements sur ces données. Savoir qu'elles sont fiables, ou savoir précisément quand elles ne l'étaient pas, change ses arbitrages.

Quant à la direction, elle est concernée à un autre titre : c'est elle qui porte le coût d'une décision prise sur une donnée fausse. C'est d'ailleurs pour ça que les KPI sont au cœur du produit. Un taux de conversion garanti n'est pas un sujet technique.

Peu de choses à faire, et une contrainte en moins.

Rien à intégrer : aucune balise, aucun composant, aucun paquet à ajouter à votre application. Vous n'êtes pas sollicité pour installer l'outil.

Ce qui change, à votre avantage : vous cessez d'apprendre trois semaines après coup qu'une de vos livraisons avait cassé le tracking. Le contrôle se déclenche depuis la chaîne d'intégration continue et rend un verdict au format JUnit, affiché au même endroit que vos autres tests. Un événement manquant devient un échec de build, lisible et situé, au lieu d'un ticket vague reçu un mois plus tard.

Et quand un écart est constaté, l'alerte nomme l'élément en cause et affiche la valeur relevée face à celle attendue, avec la vidéo du parcours. Vous n'avez pas d'enquête à mener.

Vous cessez d'être le point de passage obligé de tout le monde.

Aujourd'hui, vous êtes la personne à qui on demande ce qui est censé être collecté. Celle qui recette le tracking avant chaque mise en production. Celle qui découvre au reporting qu'un événement manque, et qui doit ensuite reconstituer depuis quand.

Avec Netvigie Tracking : le plan est un référentiel que chacun consulte sans vous solliciter. La recette est automatisée et intégrée aux livraisons. Les ruptures vous parviennent au lieu d'être cherchées. Et chaque alerte porte sa date, son périmètre et les KPI menacés.

Votre travail se déplace de la vérification vers la définition : décider ce qui doit être mesuré, et pourquoi. C'est aussi ce qui rend votre rôle visible en interne, parce que la couverture de vos KPI est enfin un chiffre que vous pouvez présenter.

Parce que les deux lisent le même objet, à deux hauteurs différentes.

Le développeur descend jusqu'au paramètre. Quel événement, sur quel gabarit de page, avec quelle valeur attendue, et ce qui est réellement parti. Rien n'est arrondi : c'est son niveau de travail, et il y trouve de quoi corriger sans mener l'enquête.

Le métier remonte jusqu'au KPI. Vous déclarez vos indicateurs dans l'outil (taux de conversion, CA e-commerce, performance des mises en avant) et vous leur rattachez les éléments du plan de marquage dont ils dépendent. On appelle ça les ingrédients du KPI. À partir de là, « taux de conversion » cesse d'être un chiffre qui tombe d'un rapport : c'est une liste d'événements et de paramètres identifiés, dont vous savez lesquels sont sous contrôle et lesquels ne le sont pas encore.

C'est ce lien qui rend les alertes lisibles des deux côtés. La même alerte dit au développeur « le montant est vide sur l'événement d'achat, sur les fiches produit», et à la direction marketing « votre CA e-commerce n'est plus garanti depuis mardi ». Personne n'a besoin de traduire pour l'autre.

Un point qui évite les malentendus : Netvigie Tracking ne recalcule pas vos indicateurs. C'est le travail de Piano ou de GA4. Nous garantissons la donnée qui les alimente.

Les exemples que vous citez, navigateurs obsolètes et extensions qui bloquent les tags, sont exactement le bruit que produit l'observation du trafic réel. Nous ne l'avons pas, parce que nous ne l'observons pas.

Nos contrôles s'exécutent dans un navigateur que nous maîtrisons, sur un parcours que vous avez décrit, dans un état de consentement choisi. Les conditions sont identiques à chaque passage : ce qui change vient de votre site, pas de l'équipement du visiteur.

S'ajoute la répétition. Un échec isolé est rejoué avant d'être retenu, donc le site qui tousse une fois ne réveille personne.

Et la fatigue vient surtout des doublons. Chez nous, une alerte par problème, pas un signal par symptôme : trois cents pages en échec pour la même cause font une alerte, et un problème qui persiste alimente l'alerte existante au lieu d'en créer une nouvelle chaque matin.

Par mail, sur votre messagerie d'équipe (Slack, Microsoft Teams), et en temps réel dans l'application.

Vous choisissez qui reçoit quoi, sur trois axes : les types de problème, les sites, les environnements. L'équipe e-commerce ne reçoit pas les alertes du site corporate, et le DPO ne reçoit que ce qui touche au consentement.

Le message est pré-rédigé en clair : la nature du problème, son ampleur, le périmètre touché, les éléments concernés et les KPI menacés. Lisible sans être technicien, ce qui compte quand il arrive un vendredi soir sur un téléphone.

Et c'est vous qui fixez la fréquence de contrôle, jusqu'à quelques minutes sur un parcours critique. C'est elle qui détermine votre délai de détection.

Vers celles que vous désignez, sur les canaux qu'elles utilisent déjà : mail, messagerie d'équipe (Slack, Microsoft Teams), et notification en temps réel dans l'application. Le ciblage se déclare sur trois axes : les types de problème, les sites, les environnements. Un axe laissé vide ne restreint rien.

Vous pouvez donc envoyer les alertes de consentement au DPO, les ruptures de conversion à l'équipe e-commerce, et tout ce qui concerne la préproduction aux développeurs, sans que personne reçoive le bruit des autres. C'est la première condition pour que les alertes continuent d'être lues.

 Le message est pré-rédigé en clair : nature du problème, ampleur, périmètre touché, éléments concernés et KPI menacés.

La répartition qui fonctionne le mieux, et que l'outil rend applicable :

Data / Analytics —responsable. Détient le plan de marquage, arbitre les évolutions, répond de la fiabilité des chiffres. C'est le seul rôle qui modifie le référentiel.

Tech / QA —exécutant. Implémente, lance les contrôles, corrige les régressions. Le contrôle est branché sur leur chaîne de déploiement.

Marketing —consulté. Exprime les besoins de mesure et consulte les résultats. Il ne modifie pas le plan, mais il voit l'état de ses indicateurs.

Produit — consulté. Vérifie avant lancement que la mesure d'une fonctionnalité est en place.

Direction —informée. Suit la couverture des KPI, pas les erreurs techniques.

Ce qui rend ce RACI tenable, c'est que les droits de l'outil le reflètent exactement. La responsabilité cesse d'être un document qu'on se repasse pour devenir un paramétrage.

Oui, et c'est ce qui raccourcit le plus le délai de correction.

 L'alerte porte tout ce qu'il faut pour reproduire :

 • la valeur relevée face à la valeur attendue ;

 • l'URL exacte et le gabarit de page concerné, ou l'étape du parcours s'il s'agit d'un scénario ;

 • l'environnement, le mode de test et l'état de consentement sous lesquels le contrôle a tourné ;

 • la capture de la page et la vidéo du parcours joué ;

 • le contenu exact du hit.

 Autrement dit, votre développeur n'a pas d'enquête à mener, et il n'a pas besoin de vous pour démarrer. Il ouvre l'alerte, il voit la scène, il corrige.

 C'est toute la différence avec un ticket qui dit « le tracking ne marche pas sur les fiches produit », et qui coûte une demi-journée d'aller-retour avant même que quelqu'un commence à chercher.

Oui aux trois, et c'est leur articulation qui rend le dispositif exploitable.

 Les règles de qualité se posent sur l'événement ou le paramètre, avec leur contexte d'application. C'est le cœur du produit.

 L'owner et la criticité passent par les attributs : des dimensions que vous définissez vous-même et que vous posez sur vos règles et vos paramètres. L'équipe responsable, le domaine métier, le niveau de criticité, le périmètre réglementaire : ce que votre organisation a besoin de qualifier. Vous n'héritez pas d'une taxonomie imposée, vous déclarez la vôtre.

 Ces attributs servent ensuite au routage des alertes — elles partent vers l'équipe qui porte l'élément en cause — et vos filtres de restitution s'appuient sur les mêmes dimensions. Le KPI est l'autre bout de la chaîne. Vous déclarez vos indicateurs métier et vous leur rattachez les éléments du plan dont ils dépendent. Un même paramètre peut en nourrir plusieurs.

 Les deux se complètent sans se confondre. L'attribut dit qui s'en occupe et ce que ça vaut pour vous ; le KPI dit ce que vous perdez si ça casse.

Vous repartez avec plus que ce que vous avez apporté.

Votre plan de marquage est un référentiel structuré et versionné, récupérable par API ou via notre serveur MCP. Vous récupérez la configuration à jour, c'est-à-dire votre plan enrichi de tout ce qui a été corrigé, complété et découvert depuis l'import. Vos résultats de contrôle sortent de la même façon.

L'historique suit : chaque évolution est versionnée, datée et attribuée à son auteur. Vous ne perdez ni le référentiel, ni la trace de la façon dont il a évolué.

Nous ne construisons pas de mécanisme de rétention. Un produit qui a besoin d'enfermer ses clients pour les garder a un problème ailleurs.

Oui. Pas de carte bancaire, pas d'engagement, pas de compte à rebours.

Ce qui est gratuit : construire et maintenir votre plan de marquage, l'importer depuis vos fichiers, travailler à plusieurs avec des droits, gérer plusieurs sites, déclarer vos KPI et voir lesquels sont déjà couverts par des contrôles. Toute la partie référentiel et collaboration, sans limite de durée.

Ce qui est payant : l'exécution. Lancer les contrôles, surveiller en continu, recevoir les alertes. La frontière est facile à retenir. Décrire ce que vous voulez collecter ne coûte rien. Vérifier que c'est bien le cas, c'est le service que vous achetez.

Au moment où vous demandez à la plateforme de contrôler.

Documenter votre plan de marquage est gratuit, sans limite de durée. Dès que vous lancez des tests ou une surveillance continue, vous consommez. La mesure porte sur ce qui est réellement exécuté : les pages contrôlées et les parcours joués.

Trois choses font varier le montant. Le nombre de sites, le nombre de parcours critiques à surveiller, et la fréquence de contrôle. Un tunnel d'achat vérifié toutes les heures ne pèse pas comme un catalogue balayé chaque nuit.

Le chiffrage se fait avec nos équipes, sur votre périmètre réel. Et la bonne façon dele comparer n'est pas le montant seul, mais ce que vous coûtent aujourd'hui les journées de recette avant chaque mise en production.

Trackingplan observe le trafic de vos visiteurs et en déduit un schéma de ce que vous collectez. Netvigie Tracking part de l'inverse : vous déclarez ce que vous voulez collecter, et nous allons vérifier sur votre site que c'est bien le cas.

La conséquence est plus profonde qu'elle n'en a l'air. Un schéma déduit décrit votre tracking tel qu'il est, erreurs comprises. Il ne peut pas vous dire qu'un événement manque, puisqu'il ne l'a jamais vu. Un plan déclaré, lui, dit ce qui devrait être là : il détecte l'absence.

S'ajoute tout ce que l'observation du trafic ne permet pas :

 • contrôler une préproduction avant la mise en ligne, là où il n'y a aucun visiteur à observer ;

 • rejouer un tunnel d'achat authentifié à l'identique, autant de fois que nécessaire ;

 • vérifier que vos tags se taisent quand l'internaute refuse le consentement, parce qu'on ne peut pas demander à de vrais visiteurs de refuser ;

 • démarrer sans rien installer sur vos pages, donc sans passer par une release.

Et Netvigie Tracking relie ce plan à vos KPI. Une anomalie ne dit pas seulement «ce tag est cassé », elle dit quel indicateur métier n'est plus garanti.

Les deux plateformes sont françaises et adressent la gouvernance du plan de marquage et la conformité du consentement. Trois choses nous distinguent.

Le plan de marquage est exécutable. Ce ne sont pas deux outils côte à côte, un référentiel d'un côté et un scanner de l'autre. Les définitions qui documentent sont exactement celles qui testent. Votre référentiel ne peut donc pas dériver sans que vous le sachiez.

Le consentement est un état de rejeu, pas un rapport à part. On relance le même contrôle en mode refus et on vérifie que les tags concernés sont bien absents, page par page et étape par étape.

L'alerte est reliée à vos KPI. Elle ne dit pas seulement qu'une règle est violée : elle dit quel indicateur métier n'est plus garanti, sur quel périmètre et depuis quand.

Pour le reste, le plus honnête est de comparer en démo sur votre propre site. Les différences d'approche deviennent visibles en quelques minutes, bien mieux que sur un tableau de fonctionnalités.

Avo travaille en amont, du côté du code : un contrat de tracking et de la génération de code dans l'application. La promesse est que le marquage est correct parce qu'il est généré. Netvigie Tracking part de votre site tel qu'il est. Rien à instrumenter, aucun code à générer, et le contrôle porte sur ce qui part réellement de vos pages.

Deux différences pèsent en pratique.

Nous couvrons le marquage que vos développeurs ne codent pas : les tags posés par votre gestionnaire de tags, les pixels ajoutés parle marketing pour une campagne, les scripts de vos partenaires. C'est souvent là que se trouvent les écarts, et un contrat côté code ne les voit pas.

Et la valeur arrive tout de suite. Pas de chantier de refonte de l'instrumentation avant d'obtenir le premier résultat, donc pas de dépendance au planning de vos équipes techniques.

Les deux approches ne s'excluent pas : l'une discipline l'écriture du tracking, l'autre vérifie le résultat en production.

ObservePoint est un outil d'audit : il scanne et vous rend des rapports. Netvigie Tracking est un outil de gouvernance qui teste. La nuance change tout l'usage quotidien.

Votre plan de marquage vit dans l'outil. Structuré, versionné, avec des variantes par site et des branches pour préparer vos évolutions. Ce n'est pas une campagne de scan qu'on relance, c'est l'endroit où votre référentiel habite.

Un écart ne devient pas une ligne dans un rapport, mais une alerte dont le périmètre est calculé(« uniquement en préproduction, sur les fiches produit ») et qui se ferme d'elle-même quand le problème a disparu.

Vos parcours se créent sans code : vous les enregistrez, ou vous donnez une consigne en français et l'agent les joue sur votre site avant de les enregistrer.

Et vos KPI sont dans la boucle. Vous ne suivez pas un taux d'erreurs techniques, vous suivez la part de vos indicateurs métier qui est réellement sous contrôle.

 Enfin, le produit est européen : édition et support français, exécution depuis des datacenters en France et en Allemagne.

Le démarrage est assisté, pas à refaire. Vous déposez votre plan existant, la plateforme analyse votre site, et vous validez en une fois la configuration proposée.

 Deux profils suffisent :

 • la personne qui connaît le plan de marquage, pour relire la proposition et arbitrer ce qu'on reprend ;

 • quelqu'un qui sait décrire les parcours à surveiller, comme le tunnel d'achat, l'inscription ou la prise de rendez-vous.

 Aucun développeur n'est mobilisé, aucune instrumentation n'est à poser, rien n'est à déployer sur le site. Vous ne dépendez donc pas d'un créneau dans le planning des équipes techniques pour commencer. C'est souvent ce qui fait la différence entre un projet qui démarre et un projet qui attend le prochain trimestre.

 En pratique, on conseille de commencer par un site et deux ou trois parcours critiques, puis d'élargir. Vous avez des résultats sur ce périmètre avant même d'avoir fini de tout décrire.

Quatre choses, et elles ne sont pas anecdotiques.

 Vous passez d'un fichier à un référentiel structuré, où chaque événement porte son vendor, ses paramètres et le contexte dans lequel il est attendu. Vous récupérez votre plan existant sans le retaper. Vous travaillez à plusieurs avec des droits. Et vous gérez plusieurs sites avec un seul plan.

 Surtout, vous déclarez vos KPI et vous voyez immédiatement lesquels sont couverts par des contrôles et lesquels ne le sont pas. Cette lecture ne demande aucune exécution : elle se calcule sur votre configuration seule. Autrement dit, avant même d'avoir lancé un test, vous savez ce qui n'est pas sous cloche. C'est souvent ce moment qui déclenche le passage au payant. Mettre son plan au propre, c'est découvrir qu'on ne sait pas s'il est respecté.

Oui. La plupart des outils de data quality du tracking sont américains, ce qui pose trois questions à une direction juridique européenne : la localisation des données, l'exposition aux réglementations extraterritoriales, et le droit applicable au contrat.

 Netvigie Tracking est une société française. La plateforme est éditée et opérée en Europe, les contrôles s'exécutent depuis des datacenters en France et en Allemagne, et le support est en français.

 S'y ajoute un avantage fonctionnel qui n'est pas anecdotique. Les outils conçus aux États-Unis sont pensés autour de Google Analytics : Piano Analytics, très présent en France et en Europe, y est au mieux détecté comme un tag tiers, sans lecture de son contenu. Netvigie Tracking le traite au même niveau que GA4, et lit les data layers des gestionnaires de tags européens comme Tag Commander et Eulerian.

Les deux séparément ne fonctionnent pas, et c'est l'enseignement le plus utile de ce marché.

 Un outil de gouvernance sans contrôle produit une documentation qui se périme : vraie le jour où on l'écrit, fausse six mois plus tard, et rien ne le signale.

 Un outil de monitoring sans référentiel produit du bruit : il signale des erreurs techniques sans savoir ce qui était attendu, donc sans pouvoir dire si c'est grave ni même si c'est nouveau.

 La valeur naît de la jonction. Le référentiel donne le sens, le contrôle donne la vérité, et les KPI disent ce que vous perdez quand ça casse. C'est le principe de Netvigie Tracking : une seule définition documente et teste, donc le référentiel ne peut pas dériver sans qu'on le sache.

Huit critères discriminent réellement. Les autres se ressemblent d'un outil à l'autre.

 • le référentiel est-il exécutable, ou faut-il un second outil pour vérifier ce que le premier documente ?

 • faut-il déployer quelque chose sur vos pages, avec la validation technique et le traitement de données que ça implique ?

 • peut-on contrôler une préproduction, avant la mise en ligne ?

 • peut-on rejouer un parcours authentifié, et le refus de consentement ?

 • vos outils sont-ils décodés, ou seulement détectés ? La question se pose surtout hors écosystème Google.

 • le server-side et les applications mobiles sont-ils couverts parle même plan ?

 • la restitution donne-t-elle des alertes qualifiées — quel KPI, où, depuis quand —ou une liste d'erreurs à retrier à chaque passage ?

 • quel est le délai avant le premier résultat, et qui doit être mobilisé pour l'obtenir ?

 Ce dernier décide en pratique. Un outil qui exige un chantier d'intégration avant de produire quoi que ce soit ne sera jamais adopté.

Quatre familles, qui répondent à des questions différentes.

 Les outils de gouvernance du plan de marquage portent le référentiel (événements, paramètres, contextes) avec des droits et un historique. Ils documentent ; ils ne vérifient pas tous.

 Les outils d'observation du trafic déduisent ce que vous collectez du comportement de vos visiteurs, via un script déployé sur vos pages. Ils voient la variété du réel, mais rien de ce qui n'est pas en ligne.

 Les outils d'audit synthétique rejouent des pages et des parcours dans des navigateurs pilotés et signalent les erreurs constatées, généralement sans référentiel de ce qui était attendu.

 Les contrats de tracking côté code disciplinent l'écriture du marquage dans l'application, mais ne voient pas les tags posés par un gestionnaire de tags ni par le marketing.

 Netvigie Tracking réunit la première et la troisième, et y ajoute le lien avec vos indicateurs métier. Le référentiel est exécutable : ce sont les mêmes définitions qui documentent et qui testent.

Quatre, et ils se mesurent.

La couverture de vos KPI. Le chiffre de départ est souvent un choc : combien de vos indicateurs métier reposent sur des données réellement contrôlées ? À trois mois, cette courbe a monté. C'est le gain le plus présentable en interne.

Le délai de détection. Vous passez de « on s'en est aperçu au reporting » à « l'alerte est tombée dans l'heure ». C'est mesurable sur chaque incident.

Le temps de recette. Une demi-journée par mise en production qui disparaît, et une recette qui ne dépend plus de la disponibilité de quelqu'un.

Les anomalies dormantes trouvées au démarrage. Presque tous les clients en découvrent : des tags morts, des paramètres vides, des événements absents d'un gabarit. Elles étaient déjà là avant, et personne ne les voyait.

Le cinquième gain ne se chiffre pas : les discussions où personne ne sait si le chiffre est faux ou si le marché a bougé s'arrêtent.

Tout est récupérable, et par plusieurs chemins.

Votre plan de marquage est un référentiel structuré et versionné, accessible par API ou via notre serveur MCP. Vous pouvez donc l'exposer à vos propres outils, ou le faire lire par un assistant.

Vos résultats de contrôle s'interrogent par API, avec filtres, agrégations et regroupements. De quoi alimenter votre entrepôt de données ou vos tableaux de bord existants.

Vos contrôles se déclenchent depuis votre chaîne d'intégration continue, avec un retour au format JUnit ou un rappel HTTP.

Vos alertes partent vers Slack, Microsoft Teams ou par mail, sur le périmètre que vous déclarez.

Le principe : Netvigie Tracking est l'endroit où le plan de marquage vit et se vérifie, pas un endroit de plus où vos équipes doivent aller regarder.

Netvigie occupe une place que ces outils ne couvrent pas, et il s'y branche.

Votre catalogue Data décrit les données une fois arrivées. Votre plateforme Data les transforme. Votre observabilité surveille l'infrastructure. Aucun des trois ne sait dire qu'un événement a cessé de partir du navigateur — à ce stade, la donnée n'existe déjà plus.

Netvigie Tracking couvre l'amont, la collecte elle-même, puis rend ses résultats à vos outils. Le plan de marquage s'expose par API, les résultats s'interrogent et alimentent votre entrepôt, les alertes partent sur vos canaux existants et les contrôles se déclenchent depuis votre chaîne de livraison.

Et via notre serveur MCP, votre plan de marquage devient directement lisible par un assistant. Vos équipes peuvent lui demander ce qui est attendu sur une page, ou quels indicateurs dépendent d'un paramètre, sans ouvrir la plateforme. C'est l'inverse d'un silo : la connaissance sort de l'outil au lieu d'y rester enfermée.

Le bon test, d'ailleurs : quelqu'un doit-il se connecter à un outil de plus pour faire son travail ? Chez nous, le développeur reçoit l'échec dans sa chaîne de livraison, l'équipe data reçoit l'alerte sur Slack, et la direction lit la couverture des KPI dans son tableau de bord habituel.

Quelles données. Votre configuration, c'est-à-dire votre plan de marquage, et le résultat de nos exécutions : les hits que nos propres navigateurs ont déclenchés, les captures et les vidéos des parcours joués.

Ce que nous ne traitons pas : le comportement de vos visiteurs. Nous ne déployons rien sur vos pages, donc aucune donnée d'utilisateur final ne transite par nos systèmes. Les seules données personnelles en jeu sont celles de vos collaborateurs qui utilisent la plateforme, et les comptes de test que vous nous confiez pour jouer les parcours authentifiés.

Où. Les contrôles s'exécutent depuis des datacenters en France et en Allemagne, et l'ensemble de la plateforme est opéré en Europe. Netvigie est une société française : pas de transfert hors Union européenne à justifier, pas d'exposition aux réglementations extraterritoriales.

Combien de temps. Les durées de conservation sont fixées par votre contrat. C'est un vrai point à arbitrer avec nous, parce que l'historique est ce qui vous permet d'affirmer qu'une anomalie a duré du 3 au 14 : votre besoin de preuve et vos propres obligations de conservation déterminent la durée utile.

Trois postes, dont un seul est un coût direct.

Le temps de recette. Une demi-journée par mise en production qui disparaît, multipliée par votre rythme de livraison. C'est le chiffre le plus facile à défendre, parce qu'il est déjà dans vos plannings.

Le coût de l'aveuglement. Il se calcule avec vos données : la part du budget média pilotée sur vos conversions, multipliée par la durée moyenne pendant laquelle une anomalie passe inaperçue aujourd'hui. Si vous découvrez les ruptures au reporting mensuel, cette durée est de plusieurs semaines. Le coût de reconstruction. Après une anomalie, il faut refaire les analyses, redécider, et parfois expliquer à sa direction que les chiffres du trimestre étaient faux. Ce poste n'est presque jamais compté, et c'est souvent le plus douloureux.

Pour une première défense en interne, le plus efficace n'est pas le calcul complet. C'est de poser une question à laquelle personne ne sait répondre : depuis quand nos événements de conversion partent-ils correctement, et comment le savons-nous ?

Les premiers écarts remontent dès le premier contrôle. C'est même l'étape la plus frappante d'un démarrage : presque toutes les équipes découvrent des anomalies dormantes qui étaient là depuis des mois. Des tags morts, des paramètres vides, un événement absent d'un gabarit entier.

Et avant même de lancer un contrôle, vous avez déjà un résultat : la couverture de vos KPI. Combien de vos indicateurs reposent sur des données réellement vérifiées ? Cette lecture se calcule sur votre configuration seule.

Les gains de processus arrivent ensuite, au rythme de vos livraisons. La recette automatisée se mesure à la première mise en production qui passe sans journée de vérification manuelle. Le délai de détection se mesure au premier incident.

La courbe qui intéresse une direction — la couverture qui monte, les anomalies qui baissent — devient lisible au bout de quelques cycles de livraison.

Le support est en français, assuré par les équipes qui construisent le produit. Vous ne passez pas par un centre de contact qui transmettra.

Sur un incident de collecte critique, la plateforme a déjà fait le plus gros du travail avant même que vous nous appeliez. L'alerte porte l'élément en cause, le périmètre exact, la date de début, les KPI menacés, et la vidéo du parcours. La plupart des incidents se traitent donc directement par vos équipes, sans nous, et c'est le meilleur des supports.

Notre intervention est utile sur deux cas : un doute sur l'interprétation d'un résultat, et un besoin d'élargir rapidement le contrôle pour cerner l'étendue d'un problème.

Les engagements de niveau de service se contractualisent selon votre contexte.

Ces outils surveillent que vos parcours fonctionnent : le tunnel d'achat aboutit, la page se charge, le formulaire s'envoie. C'est un sujet de disponibilité et d'expérience, et ils le traitent bien.

 Netvigie Tracking part du même geste, rejouer un parcours dans un vrai navigateur, mais pose une autre question : ce parcours est-il correctement mesuré ? L'événement d'achat part-il avec le bon montant, la bonne devise, les bonnes références ? Le data layer est-il complet sur ce gabarit ? Les tags se taisent-ils en cas de refus de consentement ?

 La différence tient au référentiel. Nous portons votre plan de marquage et nous le confrontons au site.

 Un outil de monitoring de parcours constate qu'on peut acheter. Il ne sait pas dire que l'achat n'a pas été mesuré. Les deux sont complémentaires, et une équipe qui a déjà l'un comprend immédiatement la valeur de l'autre.

Les modèles du marché se ressemblent : un abonnement dont le montant dépend du volume contrôlé —nombre de sites, de pages, de parcours, et fréquence.

 Chez Netvigie Tracking, la documentation et la collaboration sont gratuites, sans limite de durée. Construire et maintenir votre plan, l'importer, travailler à plusieurs, gérer plusieurs sites, déclarer vos KPI. Vous ne payez que l'exécution des contrôles et la surveillance continue.

 La bonne façon de comparer n'est pas le prix affiché, mais le coût complet : ce que représentent aujourd'hui les journées de recette avant chaque mise en production, et le coût d'une décision prise sur une donnée fausse pendant plusieurs semaines.

Non, dans notre cas. Netvigie Tracking ne déploie rien sur vos pages et ne collecte pas le comportement de vos visiteurs. Les contrôles s'exécutent dans nos navigateurs, sur nos propres sessions.

Les données manipulées sont donc votre configuration, c'est-à-dire votre plan de marquage, et le résultat de nos exécutions : les hits que nous avons nous-mêmes déclenchés.

C'est une différence de fond avec les outils qui observent le trafic réel. Leur fonctionnement suppose un script sur vos pages, donc un traitement à encadrer : mention au registre, base légale, information des personnes, parfois une analyse d'impact.

Les seules données personnelles en jeu chez nous sont celles de vos utilisateurs de la plateforme, vos collaborateurs, et les comptes de test que vous nous confiez pour jouer les parcours authentifiés.

Trois choses, et aucune ne mobilise vos équipes de développement :

 • l'adresse de votre site, et celle de votre préproduction si vous voulez contrôler avant mise en ligne ;

 • votre plan de marquage existant, dans l'état où il est —un fichier de quatre ans fait très bien l'affaire ;

 • un ou deux comptes de test, si vos parcours critiques nécessitent une connexion.

Rien à installer, aucune balise à poser, aucun développement.

Le seul prérequis technique éventuel : autoriser nos contrôles si votre site est protégé contre les robots. Un réglage à faire une fois, au démarrage.

Les contrôles s'exécutent depuis des datacenters situés en France et en Allemagne, et l'ensemble de la plateforme est opéré en Europe. Netvigie est une société française.

C'est un critère qui pèse dans les appels d'offres et pour les directions juridiques : pas de transfert hors Union européenne à justifier, pas d'exposition aux réglementations extraterritoriales, un interlocuteur et un contrat de droit français.

La localisation a aussi un intérêt fonctionnel. Contrôler un site depuis plusieurs pays permet de vérifier ce que voient réellement des internautes de zones différentes, ce qui compte quand votre bannière de consentement, vos tags ou vos contenus varient selon la géolocalisation.

En partant de votre fichier, pas d'une page blanche.

Vous le déposez. En parallèle, la plateforme analyse votre site pour reconnaître ce qui est en place : bannière de consentement, gestionnaire de tags, data layer, gabarits de page. Les deux se croisent en une proposition complète. Vous relisez, vous décochez ce qui n'a plus lieu d'être, vous validez. Tout est créé d'un coup.

Un conseil de méthode : ne nettoyez pas le fichier avant de migrer. Un plan Excel de quatre ans contient des lignes périmées et personne ne sait lesquelles. C'est le premier contrôle sur votre site réel qui vous le dira, en quelques minutes plutôt qu'en trois réunions.

 Et commencez petit : un site, deux ou trois parcours critiques. Vous aurez des résultats avant même d'avoir fini de tout décrire.

La bonne mesure n'est pas le temps passé, c'est ce qu'on en fait.

En manuel, l'essentiel part dans la vérification : recetter avant chaque mise en production, parcourir les pages, relire le fichier pour retrouver ce qui était attendu, enquêter quand un chiffre semble faux. Sur une recette avant mise en production, c'est une demi-journée qui disparaît avec l'automatisation.

Avec l'outil, le temps se déplace vers la correction : traiter les alertes qui remontent, avec leur périmètre exact et le KPI concerné. C'est plus court, parce que l'enquête est déjà faite. Reste un investissement initial, fait une fois : décrire vos parcours, définir vos gabarits, déclarer vos KPI.

Et un cas où l'outil n'allège rien : si personne ne traite les alertes. Elles s'accumulent, et vous avez un tableau de bord de plus.

Non, surtout pas. Nettoyer avant, c'est trois réunions pour trancher des lignes dont personne ne sait si elles sont encore vraies.

Déposez-le tel quel. La plateforme le lit, analyse votre site en parallèle, et croise les deux. Le premier contrôle vous dira ce qui est réellement collecté, ce qui ne l'est plus, et ce qui tourne sans être documenté.

Autrement dit, le tri se fait sur des faits en quelques minutes, au lieu de se faire sur des souvenirs en quelques semaines.

Et si votre plan est vraiment trop pauvre, ce n'est pas bloquant. La plateforme part du site : ce qui est observé sans être documenté vous est proposé avec son contrôle déjà déduit des valeurs réelles. Vous reconstruisez en acceptant, pas en écrivant.

Quatre étapes, et la première produit déjà de la valeur.

Reprendre. Vous déposez votre plan existant, la plateforme analyse votre site et vous propose une configuration complète. Vous relisez, vous validez.

Déclarer. Vous posez vos KPI et vous leur rattachez les éléments dont ils dépendent. Vous voyez immédiatement lesquels sont couverts et lesquels ne le sont pas, sans avoir lancé le moindre test.

Contrôler. Vous décrivez vos parcours critiques et vous lancez la surveillance sur un premier périmètre. C'est ici que commence la partie payante.

Industrialiser. Vous branchez le contrôle sur votre chaîne de déploiement, vous cadrez les destinataires des alertes, et vous élargissez aux autres sites.

Commencez par un site et deux ou trois parcours. L'élargissement ne demande pas de refaire le paramétrage.

Quasi nul, et c'est un parti pris.

Rien à installer sur votre site : aucune balise, aucun composant, aucun paquet. Vos développeurs ne sont pas sollicités pour le déploiement, et vous ne dépendez pas d'un créneau dans leur planning pour démarrer.

Deux points d'attention seulement, et ils prennent quelques minutes :

 • autoriser nos contrôles si votre site est protégé contre les robots ;

 • fournir un ou deux comptes de test si vos parcours critiques nécessitent une connexion.

L'implication des développeurs vient plus tard, et par choix : brancher le contrôle sur la chaîne d'intégration continue. C'est une demi-journée, et c'est là qu'ils y gagnent le plus. Le tracking devient un test qui échoue avant la livraison, au lieu d'un ticket reçu un mois après.

Oui. Le démarrage est accompagné, et c'est le moment où ça compte le plus : c'est là que se décident vos gabarits de page, vos parcours critiques et vos KPI.

Concrètement, nos équipes vous aident à reprendre votre plan existant, à choisir les premiers parcours à surveiller, et à déclarer les indicateurs qui doivent être sous cloche. Ce sont des choix structurants : bien posés au départ, ils évitent de refaire le paramétrage six mois plus tard.

Ensuite, le produit est fait pour être tenu par vos équipes sans nous. Les parcours se créent sans code, le plan se lit sans formation technique, et la restitution est rédigée en français clair.

Le support est en français, assuré par les équipes qui construisent le produit.

Le principe est simple : vous ne payez que l'exécution.

Documenter votre plan de marquage, collaborer à plusieurs, gérer plusieurs sites et déclarer vos KPI est gratuit, sans limite de durée ni carte bancaire. Le payant commence quand vous demandez à la plateforme de contrôler.

La consommation se mesure sur ce qui est réellement exécuté : les pages contrôlées et les parcours joués. Trois variables déterminent votre volume — le nombre de sites, le nombre de parcours à surveiller, et la fréquence de contrôle.

Vous pouvez donc commencer sur un périmètre réduit et monter progressivement, sans jamais refaire votre paramétrage. Le dimensionnement se cale avec nos équipes sur votre périmètre réel, et se réajuste quand il évolue.

Oui, et c'est ce qu'on recommande.

Commencez par un site et deux ou trois parcours critiques : le tunnel d'achat, l'inscription, la prise de rendez-vous. Vous avez des résultats rapidement, sur un périmètre où vous saurez juger si ce qu'on remonte est vrai et utile.

Rien ne vous engage au-delà. La documentation est gratuite et sans limite de durée, donc vous pouvez même construire tout votre référentiel et déclarer vos KPI avant d'activer le moindre contrôle. Vous verrez déjà lesquels sont couverts et lesquels ne le sont pas.

L'élargissement se fait ensuite sans rejouer le paramétrage : vous ajoutez un site, un environnement ou des parcours, et le plan commun s'applique.