PostHog

Ce qu'est PostHog

PostHog a démarré en 2020 et est devenu une plateforme exceptionnellement large : analytique produit avec capture automatique ou instrumentation manuelle, tableau de bord d'analytique web à la manière de GA, relecture de session pour le web et le mobile, feature flags, expérimentations, suivi d'erreurs, logs, sondages, un entrepôt de données qui se synchronise depuis des outils comme Stripe, des pipelines vers une vingtaine de destinations, et de l'observabilité pour les applications à base de LLM qui capte traces, latence et coût. Le README liste tout cela derrière une seule installation, et l'espace de travail se pilote depuis Slack, l'application web, un client de bureau ou votre éditeur via son serveur MCP, et non seulement depuis un tableau de bord. Le dépôt est un monorepo mené par Python et réellement actif : le dernier push au moment de la capture datait du même jour.

La licence et l'hébergement comptent ici plus qu'ailleurs, car c'est le genre d'outil que l'on adopte pour des années ou que l'on arrache. Le dépôt est disponible sous licence MIT expat sauf son répertoire ee, qui porte la sienne, et un dépôt distinct, posthog-foss, existe avec les parties propriétaires retirées pour qui a besoin que tout soit du logiciel libre. Chaque outil a son propre volume gratuit mensuel sur leur cloud — le README cite le premier million d'événements, 5k enregistrements, 1M de requêtes de flags, 100k exceptions et 1500 réponses de sondage chaque mois — après quoi la facturation est à l'usage. L'auto-hébergement tient en une ligne de Docker avec 4GB de mémoire recommandés, mais lisez le cadrage du projet avant d'y compter : ils bornent les déploiements open source à environ 100k événements par mois, recommandent au-delà de migrer vers leur cloud, et disent clairement que les installations open source viennent sans support ni engagement.

Ce qu'il faut instrumenter d'abord

La tentation, avec une plateforme aussi large, est de tout allumer en un après-midi, ce qui produit un espace de travail rempli de tableaux de bord que personne n'ouvre. Le guide de démarrage de PostHog parcourt l'activation, puis la rétention, puis le revenu, et cet ordre mérite d'être suivi à la lettre :

1. Un événement d'activation nommé Décidez du seul moment où une nouvelle personne obtient pour la première fois ce qu'elle venait chercher, et captez-le sous un nom que vous avez choisi. Tout le reste s'interprète par rapport à lui, et le taux d'activation est le seul chiffre qui garde du sens quand vous n'avez qu'une poignée d'utilisateurs.
2. Une vue de rétention sur cet événement Pas sur les inscriptions. Une courbe d'inscriptions vous flatte parce qu'elle ne fait que monter ; une courbe de retour vous dit si le produit vaut d'être ouvert une deuxième fois.
3. Le revenu, rattaché à la même identité Tant que l'argent ne repose pas sur la même personne que les événements, vous ne pouvez pas distinguer un canal cher d'un bon canal, et c'est toute la question derrière savoir si votre marketing fonctionne.
4. La relecture de session, sur la seule étape qui fuit La relecture est le moyen le plus rapide de comprendre pourquoi une étape échoue et le plus facile de perdre un après-midi. Pointez-la sur l'étape du tunnel que votre vue de rétention a déjà signalée, regardez cinq sessions, puis fermez.

La capture automatique est l'exception raisonnable au principe d'instrumenter plus tard, car elle enregistre les interactions sans que vous ayez à les nommer d'avance — ce qui est réellement utile tant que vous ne savez pas encore ce qui compte, et réellement bruyant dès que vous le savez. Les feature flags et les expérimentations méritent d'être câblés le jour où vous avez assez de trafic pour qu'un résultat signifie quelque chose, et pas avant : une expérimentation sur cent visiteurs mesure surtout votre patience.

Ce que nous avons appris en branchant PostHog sur notre propre tunnel

Cette partie vient de l'exploitation, pas de la lecture. AgentCeres — l'AI Growth Officer sur agentceres.com — utilise PostHog pour les pages vues et la conversion d'inscription, et la leçon la plus coûteuse qu'on en ait tirée est structurelle : un événement côté navigateur est une requête que le navigateur est libre de refuser. Environ la moitié de nos inscriptions n'a jamais produit l'événement client que nous comptions, et le manque était le plus marqué précisément dans la cohorte que nous payions pour acquérir, la recherche payante au Brésil, où le blocage de publicité est courant. Le chiffre n'était pas bruité, il était absent, et un événement absent ressemble exactement à un utilisateur qui n'a pas fait la chose. Pour un champ sur lequel une décision produit reposait vraiment, nous avons cessé d'interroger le navigateur et l'avons écrit côté serveur, dans notre propre base, au moment où cela se produisait.

La règle générale que nous en avons tirée : tout chiffre sur lequel repose une décision devrait être enregistré là où vous contrôlez l'écriture, et l'analytique sert à la forme du comportement plutôt qu'au grand livre. Il vaut aussi la peine d'être clair sur ce qu'un tel outil fait et ne fait pas pour la croissance. PostHog vous dira, avec une réelle précision, quelle étape de votre tunnel fuit et qui est parti ; il n'écrira pas le post, n'enverra pas l'e-mail et ne remplira pas le tunnel à nouveau. Cet écart, c'est le travail ; si vous n'avez besoin que de trafic et de chiffres par page, Umami est l'alternative plus légère, et le versant exécution — rédiger le contenu et la prospection, un humain validant tout ce qui sort — est ce pour quoi AgentCeres existe.