Comment nous utilisons PostHog pour mesurer le travail vraiment terminé chez Notis

Un appel d’outil peut réussir alors que la personne qui a demandé de l’aide ne reçoit rien d’utile. C’est une base bancale pour un dashboard d’analytics.

Chez Notis, nous utilisons PostHog pour les événements produit, le suivi des erreurs et les feature flags. Le plus intéressant, c’est de décider ce que ces événements veulent dire. Quelqu’un peut demander à un assistant de faire une recherche, de préparer un document et de le ranger au bon endroit. Compter la première requête API ne me dit presque rien sur le fait que nous ayons terminé le travail.

Voici comment je pense PostHog pour un produit IA : partir du résultat que l’utilisateur peut reconnaître, puis remonter jusqu’au signal qui prouve qu’il s’est produit. Le graphique vient après.

La question produit passe avant le nom de l’événement

Notis accepte du travail par messages, par la voix et via une app desktop ou web. Il peut utiliser des services connectés, des outils locaux et un Cloud computer. Ça nous donne plusieurs endroits où une action peut commencer, et plusieurs endroits où elle peut dérailler.

Prends une demande de document. L’assistant l’accepte. Un outil s’exécute. Une réponse revient. Le document est enregistré. L’utilisateur reçoit un lien. Ce sont des événements liés, mais pas interchangeables.

Ma première question, c’est : que mesurons-nous ? Si c’est l’exécution d’un outil, une réponse réussie de l’outil peut suffire. Si c’est la création d’un document, c’est le document enregistré qui compte. Si c’est la livraison, il nous faut une preuve issue du circuit de livraison. Un seul événement enthousiaste baptisé « success » ne peut pas répondre aux trois.

La documentation product analytics de PostHog décrit les tendances, les funnels, la rétention et les parcours construits à partir des événements capturés. Cette flexibilité est utile. Elle nous met aussi face à nos responsabilités : un funnel construit à partir d’événements flous produit une image très précise de quelque chose de vaguement défini.

Ce que notre instrumentation enregistre vraiment

Notre intégration backend prend en charge la capture d’événements, le signalement des exceptions et l’évaluation des feature flags. Pour la télémétrie produit la plus récente, notre contrat d’implémentation place les événements à la fin d’une tentative et inclut des descriptions bornées de la surface, de l’environnement et du résultat.

« Bornées » est un mot peu glamour mais utile ici. Je veux un petit ensemble de catégories significatives qu’on peut comparer dans le temps. Je ne veux pas que chaque variation de formulation d’un assistant devienne une nouvelle propriété d’événement.

Nous séparons l’état configuré du comportement observé. Savoir que quelqu’un a connecté une intégration, ce n’est pas savoir qu’il l’a utilisée avec succès. Savoir qu’il a installé un Skill, ce n’est pas savoir que le Skill l’a aidé à terminer un travail.

Cette distinction change la question que je peux poser. Un décompte de configurations aide à expliquer ce qui est disponible. Un événement d’usage terminé aide à expliquer ce qui s’est passé. Aucun des deux, à lui seul, ne me dit qu’un client est satisfait.

Instrumenté ne veut pas dire mesuré

Voici une règle que j’aimerais voir chaque fondateur qui construit avec des agents me piquer : du code et un test qui passe prouvent que tu as instrumenté quelque chose. Ils ne prouvent pas que tes analytics de production contiennent l’événement que tu voulais.

Notre contrat d’analytics produit rend cette séparation explicite. Une fonctionnalité ne devient mesurée qu’une fois qu’un événement issu du flux déployé a été relu en production. Tout ce qui précède cette frontière de mesure reste inconnu.

Ça évite une erreur particulièrement tentante : prendre un graphique vide pour la preuve que personne n’utilise la fonctionnalité. Peut-être que personne ne l’utilise. Peut-être que l’événement n’est jamais arrivé. Peut-être que la définition a changé en cours de période. Ces cas appellent des décisions différentes.

Pour un nouvel événement, ma checklist concrète est simple :

• Définir l’action exacte et la condition qui vaut achèvement.
• Déclencher cette condition via la surface produit concernée.
• Retrouver l’événement produit dans les analytics de production.
• Vérifier le résultat, l’environnement et la fenêtre de temps.
• Noter à partir de quand la définition est devenue assez fiable pour être rapportée.

C’est moins excitant que d’annoncer un nouveau dashboard. C’est aussi comme ça que le dashboard mérite sa place.

La logique de retry fait partie de la conception de la mesure

Le travail d’un agent peut impliquer des retries et un nettoyage différé. Si un événement d’analytics est réémis à chaque passage du nettoyage, le produit paraît plus performant chaque fois que son infrastructure devient moins fiable. Joli graphique. Conclusion désastreuse.

Pour la télémétrie de nos outils payants à l’usage, l’implémentation inclut une outbox d’événements persistante. Le résultat de l’outil peut être enregistré d’abord, et l’événement d’analytics envoyé ensuite à partir de l’état persisté. La déduplication utilise un identifiant dérivé plutôt que de transmettre aux analytics la référence d’exécution brute du fournisseur.

La leçon générale n’est pas que chaque produit a besoin d’une outbox sophistiquée. C’est qu’il faut décider si tu comptes des tentatives, des résultats ou des livraisons. Puis concevoir le comportement des retries autour de ce choix.

Je préfère un petit nombre d’événements bien définis à une taxonomie tentaculaire à laquelle personne ne fait assez confiance pour s’en servir.

Garde le travail de l’utilisateur hors du graphique

Un assistant IA voit passer des contenus qui n’ont rien à faire dans une dimension d’analytics pratique. Prompts, messages, contenu des documents, commandes, URL privées : tout ça peut expliquer une interaction individuelle. Ça ne veut pas dire que ça a sa place dans les analytics produit.

Notre contrat de télémétrie produit le plus récent exclut ces contenus et utilise des catégories comme la fonctionnalité, la surface et le résultat. Il s’agit d’une frontière d’instrumentation précise, pas d’une affirmation générale sur chaque événement historique de notre système.

La question que je me pose en relisant la charge utile d’un événement est simple : ce champ changerait-il une décision produit, ou est-il juste intéressant à avoir ? Si la réponse relève surtout de la curiosité, je veux qu’il disparaisse.

Tu peux enquêter sur un échec via le workflow de débogage approprié sans transformer un rapport d’adoption en copie du workspace de l’utilisateur.

Les feature flags et les erreurs apportent du contexte

PostHog intervient aussi dans nos circuits de feature flags et de suivi des erreurs. C’est important, parce qu’un décompte d’événements sans contexte peut induire en erreur. Une fonctionnalité peut n’être disponible que sur une surface donnée ou derrière une condition de déploiement. Une variation des échecs peut faire baisser l’adoption apparente alors que la demande n’a pas changé.

J’examinerais ces possibilités avant de réécrire l’onboarding parce qu’une courbe a plongé. L’intérêt concret, c’est de pouvoir étudier ensemble le comportement, la disponibilité et les échecs. Ce n’est pas la preuve qu’un flag ou un dashboard en particulier a amélioré la rétention.

Commence par une décision que tu es prêt à prendre

Si tu instrumentes un produit IA, choisis une vraie décision : améliorer la livraison des documents, simplifier la configuration des intégrations ou enquêter sur un workflow qui échoue. Définis l’action terminée qui éclairerait cette décision. Vérifie que cette action arrive bien dans tes analytics. Ensuite seulement, élargis le rapport.

C’est le rôle que joue PostHog dans notre stack. Il nous donne des outils pour examiner les comportements, mais c’est encore à nous de définir ces comportements honnêtement. Mon premier graphique préféré, c’est celui où je peux expliquer exactement ce qui a fait bouger la courbe.