Métriques produit : mesurer l'adoption sans construire une usine à tracking

Vous avez un tableau de bord rempli de courbes. Le nombre d'inscriptions monte, les clics sont comptés, chaque écran possède ses événements et personne ne sait répondre simplement à la question : quels utilisateurs obtiennent réellement de la valeur du produit ?

C'est le piège classique de l'analytics produit. On commence par ajouter quelques événements pour répondre à une question. Puis on ajoute un événement par bouton, une variante par écran, un attribut par équipe et une nouvelle vue à chaque comité. Le système collecte de plus en plus de données, mais les décisions ne deviennent pas forcément meilleures.

Le problème n'est pas de mesurer l'usage. Un produit numérique a besoin de signaux pour comprendre ses parcours, détecter les régressions et arbitrer ses investissements. Le problème est de confondre activité mesurée et valeur créée.

Une instrumentation produit utile doit relier trois choses : ce que l'utilisateur essaie de faire, le comportement observable dans l'application et la décision que l'équipe pourra prendre grâce à ce signal.

Une métrique n'est utile que si elle change une décision

Avant de créer un événement, je pose une question très concrète : quelle décision deviendra possible, ou meilleure, grâce à cette donnée ?

Si la réponse est « on verra plus tard » ou « cela pourrait être intéressant », l'événement n'est probablement pas prioritaire. Il ajoutera un coût de développement, de maintenance, de documentation et de gouvernance sans garantie d'être exploité.

Un événement peut servir à plusieurs décisions légitimes :

• vérifier qu'un parcours d'activation fonctionne après une release ;
• identifier l'étape où les utilisateurs abandonnent une tâche importante ;
• comparer l'adoption d'une capacité entre des segments pertinents ;
• détecter qu'une fonctionnalité livrée n'est pas comprise ou utilisée ;
• mesurer l'effet d'une modification du produit sur un résultat métier défini ;
• distinguer une panne technique d'un problème de compréhension ou de conception.

En revanche, « compter tous les clics » n'est pas une stratégie de mesure. C'est une manière de déplacer le problème dans un entrepôt de données.

Partir des parcours, pas des composants d'interface

Une équipe commence souvent par instrumenter ce qu'elle voit dans le code : le clic sur un bouton, l'ouverture d'une modale ou le changement d'un onglet. C'est facile à ajouter, mais fragile à interpréter. Une refonte de l'interface peut supprimer le bouton sans changer le parcours métier, ou conserver le bouton alors que l'action derrière a changé.

Je préfère partir des actions que l'utilisateur veut accomplir :

1. créer son espace de travail ;
2. inviter un collaborateur ;
3. configurer la ressource principale ;
4. terminer une première tâche utile ;
5. revenir utiliser cette capacité ;
6. exporter, partager ou intégrer le résultat.

Le nom de l'événement doit décrire le fait métier observable, pas le détail de présentation. workspace_created est plus stable que signup_button_clicked. report_exported est plus utile que download_icon_clicked.

Cela ne signifie pas qu'un clic ne peut jamais être mesuré. Il peut être pertinent pour diagnostiquer une interface, tester une hypothèse d'ergonomie ou comprendre une étape précise. Mais il doit rester au service d'une question, pas devenir le modèle principal de compréhension du produit.

Séparer les événements produit des signaux techniques

Un même parcours produit traverse plusieurs couches. L'utilisateur clique dans le navigateur, le frontend appelle une API, le backend écrit en base, puis un traitement asynchrone peut déclencher une notification. Chaque couche peut produire des signaux différents, mais ils ne répondent pas à la même question.

Je distingue au minimum :

• les événements produit, qui décrivent une action ou un résultat du point de vue de l'utilisateur ;
• les métriques techniques, qui décrivent la latence, les erreurs, le débit ou la consommation de ressources ;
• les traces, qui permettent de suivre une requête ou un traitement à travers plusieurs services ;
• les logs, qui conservent des détails utiles au diagnostic d'un comportement précis.

Une création de projet réussie peut être un événement produit. Le temps de réponse de l'API de création est une métrique technique. La trace qui relie la requête HTTP à la transaction SQL et au job asynchrone sert au diagnostic. Les mélanger dans un même événement géant rend les deux usages moins lisibles.

OpenTelemetry formalise cette séparation avec des conventions sémantiques pour les traces, les métriques, les logs et les événements. L'intérêt n'est pas d'imposer un outil d'analytics produit, mais de donner un vocabulaire plus cohérent aux signaux qui circulent dans le système. Des noms et attributs stables rendent les données plus faciles à rechercher, comparer et maintenir.

Concevoir un contrat d'événement avant d'écrire le code

Un événement produit est une interface entre le code, les données et les décisions. Il mérite donc un contrat explicite. Pour chaque événement, je documente au minimum :

• son nom et sa définition exacte ;
• le moment où il est émis ;
• ce qui constitue un succès ou un échec ;
• son identifiant de corrélation ou de session, si nécessaire ;
• les propriétés autorisées et leur type ;
• la source de vérité de chaque propriété ;
• les règles de déduplication ;
• la durée de conservation ;
• l'équipe propriétaire ;
• la décision ou le tableau de bord qui l'utilise.

Prenons report_exported. Il faut savoir si l'événement est émis quand l'utilisateur demande l'export, quand le fichier est réellement disponible ou quand le téléchargement est terminé. Ces trois moments racontent des choses différentes.

Il faut aussi décider si une relance produit deux événements, si un export échoué doit avoir son propre état, et si une génération automatique compte comme une action utilisateur. Sans ces définitions, deux équipes peuvent utiliser le même nom avec des significations incompatibles.

Le contrat doit être versionné comme le serait un contrat d'API. Une propriété renommée ou une définition modifiée peut casser un tableau de bord, une analyse de cohorte ou une décision en cours. Ajouter un événement coûte peu. Le faire évoluer proprement demande une discipline comparable à celle d'une interface technique.

Mesurer l'adoption, pas seulement l'exposition

Une fonctionnalité affichée n'est pas une fonctionnalité adoptée. Une page visitée ne prouve pas qu'une valeur a été obtenue. Un bouton activé une fois ne signifie pas qu'un problème utilisateur est résolu.

Pour analyser l'adoption, je sépare plusieurs étapes :

1. Exposition, l'utilisateur a pu voir ou découvrir la capacité.
2. Intention, il a commencé à l'utiliser.
3. Activation, la configuration nécessaire est terminée.
4. Première valeur, il a obtenu le résultat attendu.
5. Usage répété, il revient utiliser la capacité dans un contexte réel.
6. Résultat métier, l'usage contribue à l'objectif défini.

Cette chaîne évite de conclure trop vite. Une fonctionnalité peut avoir un excellent taux de clic et un faible taux de première valeur parce que la configuration est trop complexe. Elle peut être peu utilisée en volume mais essentielle pour un segment précis. Elle peut être fréquemment ouverte, mais rarement terminée parce qu'elle ne répond pas au besoin.

Les métriques doivent donc être lues avec leur contexte : segment, période, version du produit, état de déploiement, canal d'acquisition et éventuelle expérimentation. Une moyenne globale masque souvent les différences qui devraient guider la décision.

Ne pas laisser les métriques remplacer les conversations

Une métrique observe un comportement. Elle n'explique pas toujours la motivation, le blocage ou l'attente qui se trouve derrière.

Si beaucoup d'utilisateurs abandonnent au même endroit, la donnée indique un problème à investiguer. Elle ne dit pas automatiquement s'il s'agit d'un manque de confiance, d'une incompréhension, d'un délai trop long, d'une erreur technique ou d'une fonctionnalité inutile. Il faut compléter le signal avec des retours, des entretiens, du support, des tickets et parfois une observation directe du parcours.

C'est la même logique que pour le monitoring d'un SaaS : un indicateur isolé ne donne pas un diagnostic. Il faut relier les signaux et conserver une hypothèse explicite.

Je me méfie particulièrement des métriques qui deviennent des objectifs sans que leur relation avec la valeur utilisateur soit démontrée. Une équipe peut augmenter le nombre de sessions, de notifications ou de clics sans améliorer le produit. Le chiffre progresse, le comportement se dégrade.

Instrumenter côté serveur les résultats importants

Les événements capturés uniquement dans le navigateur sont pratiques, mais ils ne constituent pas toujours une source de vérité fiable. Le réseau peut couper, le consentement peut limiter la collecte, un bloqueur peut empêcher l'envoi ou un utilisateur peut fermer la page avant la confirmation.

Pour les résultats importants, je préfère émettre l'événement depuis le serveur ou depuis le système qui confirme réellement l'opération :

• une commande acceptée et enregistrée ;
• une invitation effectivement créée ;
• un export rendu disponible ;
• un paiement confirmé par le fournisseur ;
• une intégration activée et testée ;
• une tâche asynchrone terminée avec succès.

Le frontend peut produire un signal d'intention. Le backend doit confirmer le résultat quand il en est la source de vérité. Cette distinction permet aussi de relier la donnée produit aux traces et aux erreurs techniques, sans demander au navigateur de raconter ce qu'il croit avoir réussi.

Il faut ensuite gérer l'idempotence. Une requête peut être répétée, un job peut être rejoué, un événement peut être livré deux fois. Les consommateurs et les pipelines d'analyse doivent pouvoir dédupliquer les événements selon un identifiant stable. Une métrique fausse parce qu'un retry est compté comme une nouvelle action finit par conduire à de mauvaises décisions produit.

La minimisation des données est une décision d'architecture

La question « peut-on collecter cette donnée ? » ne doit pas être la seule question. Il faut aussi demander : en avons-nous besoin, pendant combien de temps et avec quel niveau de précision ?

Un événement utile n'a pas besoin de contenir le contenu complet d'un document, l'adresse email d'un utilisateur ou une copie de toutes les données affichées à l'écran. Dans la plupart des cas, un identifiant technique pseudonymisé, un type d'action, un statut et quelques dimensions contrôlées suffisent.

La CNIL rappelle que l'analytics peut couvrir des usages très différents, de mesures nécessaires au fonctionnement d'un service jusqu'à des analyses détaillées comme les tests A/B, les cartes de chaleur ou la relecture de session. Le niveau de collecte, la finalité et la base légale doivent donc être examinés au cas par cas. Ajouter un SDK ne dispense pas de définir ce qu'il collecte et pourquoi.

Concrètement :

• définissez les propriétés autorisées plutôt que d'envoyer un objet utilisateur complet ;
• interdisez les données libres dans les attributs d'événement ;
• excluez les secrets, tokens, contenus clients et données sensibles ;
• séparez les environnements de test et de production ;
• appliquez une durée de conservation cohérente avec l'usage ;
• documentez la base légale et le parcours d'information lorsque des données personnelles sont traitées ;
• prévoyez un mécanisme de suppression ou d'anonymisation quand il est nécessaire.

La minimisation n'est pas seulement une contrainte juridique. Elle réduit aussi le bruit, le coût de stockage, le risque d'exposition et la complexité des analyses.

Une gouvernance légère vaut mieux qu'un comité qui bloque tout

La gouvernance des événements ne doit pas devenir une usine administrative. Une petite équipe peut déjà instaurer quelques règles simples :

• un catalogue unique des événements actifs ;
• un propriétaire par domaine fonctionnel ;
• une revue lors de la création et de la suppression ;
• une validation automatique des noms et des types ;
• une alerte sur les événements sans consommation connue ;
• un processus de dépréciation pour les propriétés obsolètes ;
• une vérification des données sensibles avant ingestion.

Les événements liés à une fonctionnalité temporaire doivent avoir une date de retrait, comme un feature flag. Un événement conservé indéfiniment finit par être interprété hors de son contexte initial. Le nettoyage des données et du code fait partie de la livraison, pas d'un futur hypothétique.

Ma grille avant d'ajouter une métrique produit

Avant d'accepter une nouvelle instrumentation, je vérifie :

1. Quelle question utilisateur ou produit cherche-t-on à comprendre ?
2. Quelle décision sera prise avec cette information ?
3. Quel est le résultat observable qui prouve la valeur ?
4. Quelle couche possède la source de vérité ?
5. Comment éviter les doublons et les changements de définition ?
6. Quelles données sont réellement nécessaires ?
7. Qui maintient le contrat et qui supprimera l'événement ?

Si l'équipe ne peut pas répondre à ces questions, elle n'est pas encore prête à instrumenter. Elle est peut-être encore en train de formuler le problème produit.

FAQ : analytics et métriques produit

Quelle est la différence entre une métrique produit et une métrique technique ?

Une métrique produit décrit l'usage, l'adoption ou le résultat obtenu par un utilisateur. Une métrique technique décrit le fonctionnement du système, par exemple la latence, le taux d'erreur ou la disponibilité. Elles doivent être reliées pour diagnostiquer un problème, mais elles ne répondent pas à la même question.

Faut-il mesurer tous les clics d'une application ?

Non. Mesurez d'abord les parcours et les résultats qui correspondent à une décision concrète. Les clics peuvent aider à diagnostiquer une interface, mais ils ne prouvent pas qu'une fonctionnalité a créé de la valeur.

Où faut-il émettre un événement produit ?

Le signal d'intention peut venir du frontend. Le signal qui confirme un résultat important doit plutôt être émis par le serveur ou le composant qui possède la source de vérité. Cette séparation évite de compter comme réussies des actions interrompues ou rejetées.

Comment éviter les doublons dans les événements ?

Attribuez un identifiant stable à l'opération ou à l'événement, rendez les consommateurs idempotents et définissez ce qui constitue une nouvelle action. Les retries réseau et les relances de jobs ne doivent pas gonfler artificiellement les métriques.

Comment respecter le RGPD avec l'analytics produit ?

Commencez par définir la finalité, la nécessité, les données collectées, la durée de conservation et l'information fournie aux personnes. Évitez les données libres et les contenus personnels inutiles. La base légale et les règles applicables dépendent du traitement concret, de l'outil et du contexte.

Les métriques produit peuvent-elles décider seules de la roadmap ?

Non. Elles fournissent des signaux utiles, mais doivent être confrontées aux retours utilisateurs, aux objectifs du produit, aux contraintes techniques, aux coûts et aux risques. Une donnée indique où regarder, elle ne remplace pas le jugement produit.

---

Une bonne instrumentation ne consiste pas à tout enregistrer. Elle consiste à rendre visibles les décisions importantes du produit, avec des données suffisamment fiables, compréhensibles et proportionnées pour être utilisées.

Le bon indicateur n'est donc pas le nombre d'événements présents dans votre outil. C'est la capacité de l'équipe à répondre à une question précise, à vérifier son hypothèse et à agir sans reconstruire le sens des données à chaque réunion.

Sources

• OpenTelemetry, conventions sémantiques
• OpenTelemetry, conventions sémantiques pour les événements
• OpenTelemetry, conventions sémantiques pour les métriques
• CNIL, guide du développeur RGPD
• CNIL, recommandation sur les applications mobiles