Au début de ma carrière, j’ai travaillé essentiellement sur du B2B, où le sujet du tracking n’était pas central. La pratique convenue était de développer en fonction des demandes directes des entreprises clientes. Lorsque j’ai rejoint Molotov TV fin 2018 — une plateforme de streaming grand public — j’ai vite compris que cette manière de fonctionner ne pouvait pas suivre des centaines de milliers d’utilisateurs par jour.

C’est là que j’ai découvert le tracking : comprendre le comportement des utilisateurs était vital pour prioriser les efforts produit. Utile dans un contexte B2C, le tracking s’appuie sur des notions qui s’appliquent tout aussi bien en B2B — où elles restent souvent sous-exploitées.

J’applique encore aujourd’hui cette expérience à NuCorder , où même à petite échelle, savoir où les musiciens décrochent dans leur parcours oriente plus d’une décision technique.

Illustration du tracking applicatif
Illustration générée par IA (ChatGPT / DALL·E).

Dans cet article, je me concentrerai sur le tracking applicatif : celui qui observe ce que les utilisateurs font dans un produit (une page visitée, un clic, une action réalisée). Les notions restent les mêmes qu’on parle de web ou de mobile, mais pour garder les choses simples, je me concentre sur le web. Je laisse volontairement de côté les autres formes de tracking (email, publicitaire cross-site, etc.), qui répondent à des logiques différentes et qui rendraient cet article bien plus difficile à suivre.

Le tracking est pour moi un sujet souvent mal compris, tant par le grand public que par les entreprises, ou réduit à sa version la plus intrusive : des cookies qui suivent tout le monde partout, sans qu’on sache vraiment à quoi ça sert. La réalité est plus nuancée : bien utilisé, le tracking est un outil de décision, pas de surveillance. Il est tout à fait possible de le mettre en place en gardant la main sur ses données, sans dépendre d’un tiers.

Je vais donc démystifier ce qu’est le tracking applicatif, expliquer à quoi il sert concrètement, puis montrer comment le mettre en place avec Matomo (une solution auto-hébergeable qui simplifie la conformité RGPD). Je ne parlerai ni d’A/B testing, ni de comment héberger Matomo soi-même, ni des bloqueurs de publicité et de leur impact sur la fiabilité du tracking (si ces sujets vous intéressent, n’hésitez pas à m’en faire part).

Qu’est-ce que le tracking applicatif ?

Le tracking consiste à enregistrer les actions des utilisateurs sur une application, pour ensuite pouvoir analyser leur comportement. Concrètement, ça se traduit par un vocabulaire assez simple une fois qu’on l’a démystifié :

  • Track (ou événement) : une action enregistrée (une page vue, un clic sur un bouton, un ajout au panier). C’est la brique de base : chaque interaction significative devient un événement horodaté.
  • Identify : le fait d’associer ces événements à un utilisateur, qu’il soit anonyme (identifié uniquement par un cookie ou un ID technique) ou connu (une fois connecté, par exemple). C’est ce qui permet de reconstituer un parcours complet, plutôt qu’une série d’actions déconnectées les unes des autres.
  • Traits : les attributs associés à cet utilisateur (son plan d’abonnement, son rôle, son ancienneté sur le produit). Ils permettent d’affiner l’analyse et de comprendre, par exemple, si un comportement est propre à un segment d’utilisateurs plutôt qu’à l’ensemble.
  • Identifiant : ce qui relie les événements à une personne (cookie, user ID en base, device ID sur mobile). C’est un point clé à garder en tête, parce que c’est précisément ce qui fait basculer certaines données dans la catégorie des données personnelles identifiantes.
  • Donnée personnelle identifiante : toute donnée qui, seule ou combinée à d’autres, permet de ré-identifier une personne. On y reviendra en détail dans la partie RGPD.

À noter : ce tracking peut se faire côté client (dans le navigateur ou l’app) ou côté serveur. Je ne rentre pas dans ce débat ici, les deux approches coexistent souvent selon les cas d’usage.

À quoi ça sert concrètement ?

Une fois les événements collectés, l’intérêt du tracking apparaît vite : il permet de prendre des décisions sur des faits plutôt que sur des intuitions. Quelques exemples concrets :

  • Un parcours trop compliqué : si une part importante des utilisateurs abandonne à la même étape (une inscription, un paiement), c’est un signal fort d’un point de friction à corriger. Sans tracking, ce genre de problème reste invisible jusqu’à ce qu’il se traduise en churn (le taux de clients ou d’utilisateurs qui se détournent d’un produit).
  • Un potentiel bug : une chute brutale et inhabituelle sur une action précise (un taux de clic qui s’effondre du jour au lendemain) peut trahir une régression technique avant même qu’un utilisateur ne remonte le problème.
  • Une fonctionnalité peu utilisée : si une fonctionnalité sur laquelle l’équipe a investi du temps n’est quasiment jamais sollicitée, on peut se poser la question de sa pertinence, ou de sa découvrabilité dans l’interface.

Ces données servent aussi de base à des pratiques plus poussées, comme les A/B tests ou la définition d’objectifs à suivre dans le temps.

À noter : comme toute donnée, le tracking a besoin d’un minimum de volume pour être conclusif. C’est un outil au service d’une décision, pas un substitut à l’intuition (qu’il peut au contraire valider) ni à la prise de risque.

Je précise également (ce qui fera sans doute sourire plus d’un data analyste) qu’une donnée exploitable doit avoir un sens et être maintenue : pensez à bien vérifier que la donnée est fiable, cohérente avec votre activité et surtout qu’elle n’a pas été victime d’une régression au fil du temps.

Un rapide panorama des solutions SaaS

Pour mettre en place ce genre de tracking, la première réaction est souvent de se tourner vers une solution SaaS clé en main. Google Analytics est probablement la plus connue, historiquement pensée pour l’analyse de trafic web, avec un plan gratuit qui a démocratisé le sujet auprès de nombreuses entreprises. Amplitude se positionne davantage sur l’analyse comportementale produit (parcours, rétention, funnels), avec des fonctionnalités plus poussées mais un modèle payant dès qu’on dépasse un usage basique — ce sont les deux solutions que j’ai eu l’occasion de tester personnellement, la liste du marché étant bien plus large.

Elles ont toutefois un point commun : ce sont des acteurs américains, chez qui les données transitent et sont stockées. Pratique pour démarrer rapidement, mais ça soulève une question de fond, à la fois de souveraineté et de conformité : qui a la main sur ces données, où sont-elles hébergées, et sous quelles conditions peut-on les exploiter ?

À noter : au début de mon apprentissage de développeur, sur mes projets perso, j’avais utilisé Xiti — une solution française. Elle a depuis été rachetée par l’américain Piano et rebaptisée Piano Analytics : la nationalité d’un éditeur n’est jamais une garantie définitive.

RGPD : ce que ça implique

⚠️ Je ne suis pas juriste. Ce qui suit est une synthèse pratique, pas un avis juridique. Pour toute décision engageante, mieux vaut consulter les textes eux-mêmes ou un professionnel du droit.

Dès qu’un outil de tracking associe des événements à un identifiant (cookie, ID utilisateur…), on manipule potentiellement des données personnelles au sens du RGPD, et quelques principes simples s’appliquent :

  • Consentement : à l’échelle européenne, le dépôt de cookies non essentiels nécessite en principe le consentement explicite de l’utilisateur — un choix libre, spécifique, éclairé, et aussi simple à refuser qu’à accepter (directive ePrivacy ). En France, c’est la CNIL qui en précise l’application — voir sa page dédiée au sujet .
  • Minimisation : ne collecter que ce qui est nécessaire à l’objectif poursuivi (article 5.1.c du RGPD ), pas « tout ce qu’on peut » par précaution.
  • Anonymisation / pseudonymisation : limiter autant que possible l’identification directe des personnes (article 4.5 du RGPD pour la définition de la pseudonymisation).
  • Durée de conservation : les données ne doivent pas être gardées indéfiniment ; une durée doit être définie et justifiée (article 5.1.e du RGPD ).
  • Droits des personnes : chacun a le droit de demander l’accès, la rectification ou la suppression des données le concernant — voir les pages CNIL sur le droit d’accès et le droit à l’effacement .

À noter : sous certaines conditions strictes (données anonymes, pas de transmission à des tiers, usage limité à la mesure d’audience), la CNIL exempte certains outils de mesure d’audience du consentement. Un point qui rend Matomo particulièrement intéressant une fois bien configuré — on y revient dans la section suivante.

Matomo : reprendre la main sur ses données

Logo Matomo

Matomo (anciennement Piwik) est une solution open source de web analytics, auto-hébergeable. Contrairement à Google Analytics ou Amplitude, les données restent chez vous : sur votre propre serveur, sous votre propre responsabilité.

Ça change concrètement la donne. Côté conformité, héberger soi-même ses données facilite grandement le respect des exigences du RGPD vues plus haut : vous maîtrisez la durée de conservation, il n’y a pas de transfert vers un pays tiers, et vous savez précisément qui accède à quoi. Côté configuration, Matomo peut être paramétré pour rentrer dans le cadre de l’exemption de consentement de la CNIL évoquée juste avant — de quoi éviter la friction d’une bannière cookie pour le seul besoin de la mesure d’audience.

Je ne vais pas détailler ici comment héberger Matomo soi-même, ce serait trop long pour cet article. La documentation officielle est bien fournie si vous voulez vous lancer.

À noter : Matomo propose aussi une offre cloud pour ceux qui ne veulent pas gérer l’infrastructure eux-mêmes. Elle reste plus respectueuse de vos données qu’une solution comme Google Analytics ou Amplitude, mais sans toutes les garanties de la version auto-hébergée — les données ne sont alors plus chez vous, mais chez Matomo.

Mise en œuvre technique

Une fois Matomo installé (auto-hébergé ou cloud), l’intégration côté application repose sur un tracker JavaScript assez simple à mettre en place.

Suivi d’une page vue

Le snippet de base, à placer sur chaque page à suivre, ressemble à ceci :

javascript
var _paq = window._paq = window._paq || [];
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);

(function() {
  var u = "https://votre-instance-matomo.tld/";
  _paq.push(['setTrackerUrl', u + 'matomo.php']);
  _paq.push(['setSiteId', '1']);
  var d = document, g = d.createElement('script'), s = d.getElementsByTagName('script')[0];
  g.async = true;
  g.src = u + 'matomo.js';
  s.parentNode.insertBefore(g, s);
})();

Ce script enregistre automatiquement une page vue à chaque chargement, et active le suivi des liens sortants et des téléchargements.

Suivi d’un événement personnalisé

Pour suivre une action spécifique (un clic sur un bouton, une soumission de formulaire), on utilise trackEvent :

javascript
document.querySelector('#cta-inscription').addEventListener('click', function() {
  _paq.push(['trackEvent', 'Inscription', 'Clic bouton', 'CTA header']);
});

Les trois paramètres après « trackEvent » correspondent à la catégorie, l’action et un nom optionnel. Une valeur numérique optionnelle peut être utilisée comme quatrième paramètre (utile pour suivre un montant, par exemple).

Sur une application React, Vue ou Angular

Pour une application React, Vue ou Angular, où les changements de page ne rechargent pas le document, mieux vaut passer par un SDK dédié plutôt que de déclencher le tracking manuellement à chaque route. Matomo référence les intégrations communautaires pour les principaux frameworks (React, Vue, Angular, React Native) sur sa page officielle Apps & SDKs.

Découpler le tracking du code métier

Appeler directement _paq.push(...) un peu partout dans le code fonctionne, mais ça couple fortement l’application à Matomo. Si demain vous voulez ajouter un second outil, ou changer de solution, il faut retoucher tous les appels.

Une approche plus robuste consiste à émettre des événements génériques depuis le code métier (via un simple event bus, ou l’objet dataLayer popularisé par Google Tag Manager), puis à faire écouter ces événements par un module dédié qui se charge de les relayer vers Matomo (et potentiellement d’autres outils). Cette séparation facilite la maintenance et permet de brancher plusieurs destinations sur une même source d’événements, sans dupliquer les appels dans le code applicatif.

Un exemple simplifié avec un event bus maison :

javascript
eventBus.emit('signup_clicked', { source: 'CTA header' });

eventBus.on('signup_clicked', (payload) => {
  _paq.push(['trackEvent', 'Inscription', 'Clic bouton', payload.source]);
});

Le code métier ne sait même pas que Matomo existe : il se contente de décrire ce qui s’est passé. C’est le module de tracking qui décide quoi en faire.

Ce que ça donne côté Matomo

Une fois les événements collectés, Matomo propose un tableau de bord qui centralise plusieurs vues utiles :

  • Vue d’ensemble : nombre de visiteurs, pages vues, taux de rebond, sur la période choisie.

    Vue d’ensemble du tableau de bord Matomo
  • Parcours utilisateur : le cheminement réel des visiteurs, page par page, utile pour repérer les points de friction évoqués plus haut.

    Parcours utilisateur dans Matomo
  • Événements personnalisés : les actions suivies via trackEvent (comme le clic sur le CTA d’inscription de notre exemple), avec leur volume dans le temps.

    Rapport d’événements personnalisés dans Matomo

Rien de plus simple à interpréter : les mêmes notions qu’avec une solution comme Google Analytics ou Amplitude, mais avec les données qui restent chez vous.

Ce que j’en retiens

Le tracking applicatif n’est ni un gadget ni un outil de surveillance : c’est un moyen de prendre des décisions sur des faits plutôt que sur des intuitions, que ce soit pour corriger un parcours qui bloque, détecter un bug, ou questionner la pertinence d’une fonctionnalité. Le vocabulaire (track, identify, traits, identifiant) est simple une fois démystifié, et sa mise en place technique reste accessible, à condition de bien découpler le tracking du reste du code applicatif.

Reste la question de la maîtrise des données. Entre les solutions SaaS américaines et une solution auto-hébergée comme Matomo, le choix n’est pas seulement technique : c’est aussi celui de garder la main sur ses données, dans un cadre RGPD plus simple à respecter.

Vous vous posez la question du tracking sur votre application ?

Si vous envisagez de mettre en place ce genre de solution, que la conformité RGPD de votre tracking actuel vous questionne, ou simplement si cet article vous a donné des idées, n’hésitez pas à me contacter !

Parlons-en