Aller au contenu

ADR-023 — Product analytics de l'outil d'analyse sur PostHog (EU)
Statut Accepted
Date 07/07/2026
Décideurs Nicolas Léonard
Origine PR project-analysis #454 + demande Nicolas (07/07/2026)

Contexte

On ne mesure aujourd'hui rien du comportement d'usage de l'outil d'analyse (analyse.bricks.co). On sait tracer le pipeline LLM (LangSmith, ADR-021) mais pas ce que font réellement les personas dans l'app : temps passé, vues ouvertes, sections consultées, sorties vers d'autres outils. Or les personas sont posés au niveau égal (ADR-019) et la boucle d'apprentissage prime sur la spec amont (pilier #1) : il faut observer l'usage réel plutôt que le supposer, en priorité sur le persona Analyste.

Le trigger : poser une base de tooling product analytics, et le faire proprement (choix d'outil, périmètre, privacy) plutôt qu'au coup par coup.

Décision

PostHog (région EU) est le backend de product analytics de Bricks, et son périmètre est limité à l'outil d'analyse (project-analysis, frontend).

  • Une seule app trackée : l'outil d'analyse. Aucune autre app Bricks (Bubble, espace investisseur, etc.) n'est instrumentée par cette décision.
  • Désactivé par défaut : no-op tant que VITE_POSTHOG_KEY est absente (dev, tests, preview). Activation par variable d'environnement Railway, sans changement de code.
  • Personas : identification par le rôle système brut + un label persona lisible (analyste / am / admin-tech / autre). Pas de rôle « comité » inventé — on reste fidèle aux 4 rôles réels tant qu'aucun rôle comité n'existe.
  • Privacy : session recordings avec masquage des saisies par défaut, niveau pilotable par env (VITE_POSTHOG_REPLAY : inputs | all-text | off).
  • Taxonomie d'events versionnée dans le repo (front/src/lib/analytics.ts), pas de posthog.capture dispersé dans le code.

Séparation nette de responsabilité : PostHog = comportement produit / UI (funnels, rétention, temps passé, replay) ; LangSmith = observabilité pipeline LLM / éval (ADR-021). Les deux ne se recouvrent pas.

Détail d'implémentation : documentation/posthog-analytics.md.

Rationale

  • Boucle d'apprentissage > spécification amont (pilier #1) : on veut savoir si la vue analyste est utilisée, comment, et si les analystes restent in-app — des faits, pas des hypothèses. C'est la mesure du cap déclaratif (ADR-018) côté usage réel.
  • Capture passive > annotation forcée (pilier #4) : events + session replay captent le comportement sans rien demander à l'analyste.
  • Activer > construire (pilier #3) : PostHog fournit funnels, rétention, replay et hébergement EU clés en main ; réimplémenter ça en interne serait réinventer une roue mûre pour un gain nul.
  • Less is more (pilier #2) : une seule app trackée, gating par env, une couche d'events unique. On instrumente le strict nécessaire pour répondre aux questions posées, pas un dashboard spéculatif.
  • Bon outil pour le bon job : le product analytics (parcours UI, replay, rétention) n'est pas la même chose que l'observabilité LLM. Mélanger les deux dans LangSmith serait un mauvais usage des deux.

Conséquences

Ce qui change

  1. PostHog (EU) devient le backend de product analytics de l'outil d'analyse.
  2. Les personas sont identifiés (person profiles) → toute analyse est segmentable par persona / role / analyst_level.
  3. Une taxonomie d'events métier existe et vit dans le repo project-analysis (events analyste + détection de sortie d'app).
  4. Les session recordings sont disponibles (masquage saisies par défaut).

Ce qu'il faut faire

  • Renseigner VITE_POSTHOG_KEY (clé EU) côté environnement Railway du frontend pour activer.
  • Ajuster le niveau de privacy replay via VITE_POSTHOG_REPLAY selon l'arbitrage RGPD (données projet sensibles affichées dans la vue analyste).
  • Étendre la taxonomie uniquement via front/src/lib/analytics.ts.

Ce qu'il faut éviter

  • Étendre le tracking à d'autres apps Bricks sans une nouvelle décision — le périmètre est volontairement limité à l'outil d'analyse.
  • Envoyer une clé US : une clé US enverrait les données hors du workspace EU (résidence des données).
  • Appeler posthog.capture hors de la couche analytics.ts — casse la taxonomie stable et la documentation.
  • Confondre product analytics et observabilité LLM — PostHog ne remplace pas LangSmith et réciproquement.

Alternatives écartées

  • Étendre LangSmith au product analytics : mauvais outil pour le job. LangSmith trace des runs LLM/éval, pas des funnels UI, de la rétention ni du session replay. On empilerait un usage bancal sur un backend pensé pour autre chose.
  • Tracker toutes les apps Bricks d'emblée (Bubble, espace investisseur…) : scope creep. On veut d'abord la boucle d'apprentissage sur l'outil d'analyse (là où vit le travail analyste), pas un déploiement analytics tous azimuts.
  • GA4 / Matomo / Amplitude : PostHog réunit analytics produit + session replay + hébergement EU + feature flags dans un seul outil open-source ; aucun de ces concurrents ne couvre l'ensemble sans empiler des briques.
  • Instrumentation maison (events → table Neon + dashboards custom) : réinvente funnels, rétention et replay, coûteux à construire et à maintenir — contraire à « activer > construire ».

Verbatims

« Je veux poser une base de tooling pour Bricks sur la partie product analytics. […] en priorité sur les user ayant un rôle d'analyste. » — Nicolas, cadrage initial

« C'est la seule app qu'on souhaite tracker avec Posthog. » — Nicolas, sur le périmètre

Voir aussi

Sources