Build in Public #15 : +116% d'utilisateurs, -25% d'achats. Le piège des bons chiffres.

TL;DR :

• Le score PostHog est passé de 6% (V1) à 28% (V2) puis à 7,0/10 (V3). Trois audits en trois mois. La progression est réelle.
• Ce qui progresse fort : L'acquisition a doublé (173 vs 80 users sur période comparable), l'engagement chat a triplé (44 vs 12 users), le LLM Analytics est exploitable (973 appels IA, coût total tracké à 0,96 USD), et PostHog passe de 4 à 15 dashboards.
• Le nouvel onboarding : Refondu le 21 avril avec des objectifs personnalisés, un choix de persona coach, et un plan sur mesure généré par l'IA. Les events existent bien. Le souci vient de l'ordre des étapes dans certains funnels : onboarding_completed arrive avant signup_completed dans le flow réel, ce qui casse les funnels ordonnés mal construits.
• Le problème : La conversion paywall vers achat est passée de 8,7% à 3,1%. Le paywall est vu par 97 users (vs 36 avant). Les achats complétés : 3 (vs 4 avant). Le produit attire et active plus de monde. Il ne convertit pas encore.

L'audit PostHog en 3 versions : mesurer la même app à 3 moments différents (V1, V2, V3) avec la même méthode permet de voir la trajectoire réelle d'un produit. Les chiffres bruts mentent souvent. La comparaison V1 → V2 → V3 dit ce qui progresse, ce qui stagne, et ce qui régresse. C'est la vraie boussole d'un Solo Builder.

---

Salut 👋

Dans le dernier épisode, je partageais les premiers signaux de la V2 de Sam Tennis : 4 refus Apple, 50 téléchargements en 4 jours, un DAU qui explose. Trois semaines plus tard, j'ai assez de recul pour plonger dans la data.

C'est le troisième audit PostHog de Sam Tennis. Le premier (1er mars) était un constat d'échec : 85% de la base inexploitable, 0 action, 0 funnel fonctionnel. Score : 6%. Le deuxième (14 avril), juste après le lancement V2, montrait les premiers progrès : taxonomie doublée, tracking LLM opérationnel, funnel paywall à 8,7%. Score : 28%.

Ce troisième audit couvre les 22 jours post-lancement (14 avril au 5 mai). La bonne nouvelle, c'est que presque tout progresse. La mauvaise nouvelle, c'est que la seule métrique qui compte pour un business (les achats) régresse.

1. Le tableau de bord V1 vers V2 vers V3

La trajectoire est nette. En trois mois, PostHog est passé d'un tracking minimal à une infrastructure analytique structurée. Mais les chiffres bruts ne racontent qu'une partie de l'histoire.

2. L'acquisition : le haut du funnel explose

Comparaison entre la période du 24 mars au 13 avril et du 14 avril au 5 mai :

L'acquisition a plus que doublé. Les installations passent de 80 à 173 utilisateurs uniques sur une période comparable. Les signups complétés passent de 31 à 75. Et le taux d'échec de signup a chuté de 39,8% à 14,8%. Le haut du funnel fonctionne.

Le signal le plus positif dans ces chiffres, c'est le ratio. Plus de volume ET moins d'échecs. Ce n'est pas juste de l'acquisition brute qui se dilue en qualité.

3. Le nouvel onboarding : plus engageant, tracking à corriger

Ce qui a changé

J'ai refondu l'onboarding le 21 avril, en m'appuyant sur la méthode BMAD pour structurer la refonte. L'ancien parcours était linéaire et générique. Le nouveau est personnalisé :

• L'utilisateur choisit ses objectifs (gagner du classement, préparer un tournoi, améliorer sa régularité, gérer le mental, comprendre la tactique)
• Il sélectionne sa main dominante et son type de revers (une main ou deux mains)
• Il choisit un persona de coach parmi plusieurs profils
• Sam génère un plan sur mesure basé sur son classement FFT et ses objectifs, avec une courbe de progression sur 8 semaines

Le résultat : un onboarding qui donne immédiatement de la valeur au lieu de collecter des informations. L'utilisateur voit son plan avant même d'envoyer son premier message à Sam.

Les micro-events

Le nouvel onboarding est richement instrumenté. 13 events distincts trackent chaque étape :

C'est le niveau de granularité que je n'avais pas avant. Je peux maintenant voir exactement où les utilisateurs décrochent dans l'onboarding.

Le funnel d'acquisition global

Le funnel complet post-14 avril montre un net progrès par rapport à avant :

En V2, le funnel était complètement cassé : 95 installations puis 0 partout. Le merge d'identité ne fonctionnait pas du tout. En V3, le funnel n'est plus cassé au début : 173 vers 70 vers 53 vers 14.

4. L'engagement : le rebond

C'est la partie la plus encourageante de l'audit V3.

En V2, le chat était en baisse (13 users vs 25 en V1). C'était un signal inquiétant. En V3, le rebond est net : 44 utilisateurs ont envoyé un message à Sam. Le quiz quotidien passe de 9 à 33 utilisateurs. Le Mode Match touche 30 utilisateurs contre 8 avant.

Le quiz montre un taux de complétion de 90,9% (30 complétés sur 33 démarrés). Les utilisateurs qui le commencent vont au bout. C'est un bon signal de qualité de la feature.

Le DAU : pic puis refroidissement

Le DAU (Daily Active Users, le nombre d'utilisateurs actifs par jour) a culminé à 29 le jour du lancement (14 avril). Depuis, il a refroidi progressivement vers 9-13 par jour. C'est normal après un effet de lancement, mais la tendance est à surveiller. Le niveau reste au-dessus du pré-lancement (0-3 DAU), mais le plateau haut de 20+ DAU n'a pas tenu.

La vraie question de rétention (les utilisateurs de la semaine 1 reviennent-ils en semaine 3 ?) nécessite des cohortes propres. C'est la prochaine priorité.

5. La monétisation : le problème

C'est le point le plus important de cet audit. Et c'est celui qui ne va pas dans la bonne direction.

Le paywall est vu par presque 3 fois plus de monde. Les achats complétés baissent.

En V2, le funnel paywall vers achat convertissait à 8,7% (4 achats sur 46 paywalls vus). En V3, il convertit à 3,1% (3 achats sur 97 paywalls vus). Le paywall est beaucoup plus exposé, mais il convertit beaucoup moins.

Et un signal négatif supplémentaire : 6 utilisateurs ont annulé leur achat en cours de route (contre 1 avant). C'est plus d'annulations que d'achats complétés.

Ce que ça veut dire

Le produit sait attirer des utilisateurs. Il sait les activer (onboarding, chat, quiz). Mais quand ils voient le prix, quelque chose ne passe pas. Trois hypothèses :

• Le paywall est montré trop tôt dans le parcours, avant que l'utilisateur ait perçu assez de valeur
• Le prix ($34,99/an ou $6,99/mois) est trop élevé pour la valeur perçue à ce stade
• L'offre n'est pas assez claire sur ce que "Sam Pro" apporte de plus que la version gratuite

C'est la priorité n°1 pour les prochaines semaines. Comprendre pourquoi 97 personnes voient le paywall et seulement 3 achètent.

6. Le tracking LLM : enfin exploitable

Le LLM Analytics est passé de "opérationnel mais incomplet" en V2 à "exploitable" en V3.

973 appels IA en 22 jours, pour 0 erreur. Je me suis basé sur la structure de Claude Code qui a leaké il y a quelques semaines pour améliorer l'insfrastructure des appels IA derrière Sam. C'est une belle réussite de ce côté.

La répartition par modèle :

Gemini 2.5 Flash fait le gros du travail (64% des appels) à une latence acceptable de 2,6 secondes. Les embeddings OpenAI pour le RAG ne coûtent quasi rien. Et Gemini 3.1 Flash Lite intervient en complément pour des tâches plus lourdes.

Pour la première fois, je peux répondre à la question "combien coûte l'IA par utilisateur" : environ 0,012 USD par utilisateur sur 3 semaines. C'est négligeable. Le coût IA ne sera pas un problème de scaling.

7. L'infrastructure PostHog : le rattrapage

C'est le domaine qui a le plus progressé entre V2 et V3.

Les 15 dashboards incluent des dashboards thématiques (Acquisition, Engagement & Activation, Rétention & Lifecycle, Monétisation, LLM Analytics) qui n'existaient pas en V2. Les 4 Feature Flags actifs (match-mode-enabled, new-onboarding-flow, premium-trial-7d, proactive-notifications) sont une progression majeure par rapport au zéro des deux premiers audits.

Ce qui reste à zéro

Les alertes. Quatre alertes sont actives : DAU < 5, 0 signup_completed en 24h, pic de signup_failed > 10 en 1h, et 0 purchase_completed en 7 jours. Le filet de sécurité de base est posé. Ce qui manque encore : une alerte dédiée sur la chute de l'onboarding (entre onboarding_started et onboarding_wow_completed) et une alerte sur les erreurs IA. Sans ces deux-là, je ne saurais pas immédiatement si une refonte casse le parcours d'activation ou si un modèle remonte des erreurs en production.

Les experiments. Les Feature Flags existent mais ne sont pas utilisés comme couche d'expérimentation. Le new-onboarding-flow devrait être rattaché à une mesure A/B. Il ne l'est pas.

Les surveys. 5 sont configurés (Post-Onboarding NPS, Pourquoi Sam Tennis, Churner J+7, Post-achat Premium, Post-Onboarding NPS archivé). Le problème : sur les 22 jours post-14 avril, les stats affichent 0 shown, 0 sent, 0 dismissed. Les surveys existent dans PostHog mais ne collectent aucune donnée. C'est le vrai point PostHog à creuser ce mois-ci : pourquoi les surveys ne se déclenchent pas, alors que les events de ciblage existent bien. Sans surveys actifs, je n'ai aucun signal qualitatif sur les 90 utilisateurs qui ont dismissé le paywall.

8. La scorecard V3

13 domaines sur 14 ont progressé entre V2 et V3. Un seul a régressé : la monétisation (7/10 vers 4/10). Les alertes étaient mon angle mort jusqu'à ce que je relise le projet : 4 alertes sont bien actives et passent à 7/10. L'identité utilisateur progresse aussi : la confusion vient des persons anonymes (sans email), pas d'un trou applicatif.

9. Ce que je mets en place

Priorité 1 : comprendre la régression de monétisation

• Auditer le parcours paywall complet. Pourquoi 97 utilisateurs voient le paywall et seulement 3 achètent
• Analyser les 7 purchase_cancelled : à quelle étape ils annulent, sur quel plan, combien de temps après avoir vu le paywall
• Tester si le paywall est montré trop tôt dans le parcours utilisateur

Priorité 2 : harmoniser les funnels onboarding

• Aligner les funnels sur le flow réel : Application Installed → onboarding_started / onboarding_welcome_viewed → onboarding_wow_completed / onboarding_completed → signup_completed
• Filtrer les analyses business sur les persons identifiées (email is set) pour éviter que les anonymes faussent les propriétés
• Harmoniser le DAU sur une seule source (plutôt Application Opened, car certaines alertes utilisent encore app_opened)

Priorité 3 : compléter ce qui existe

• Faire remonter les surveys (PostHog affiche encore 0 shown / 0 sent malgré le ciblage configuré)
• Ajouter une alerte dédiée sur la chute de l'onboarding et une alerte sur les erreurs IA
• Transformer les Feature Flags en experiments mesurés

Conclusion : le produit scale, pas le business

Le troisième audit PostHog confirme une progression réelle sur presque tous les fronts. L'acquisition double, l'engagement triple, le tracking LLM est exploitable, l'infrastructure PostHog rattrape son retard. Le produit est meilleur, mesurable, et attire du monde.

Mais les achats ne suivent pas. 3 conversions payantes malgré 173 installations et 97 paywalls vus. C'est le prochain verrou. Tant que je ne comprends pas pourquoi les utilisateurs voient le prix et partent, tout le reste (acquisition, engagement, rétention) n'a pas d'impact business.

La prochaine étape est claire : creuser la monétisation. Pas ajouter des features, pas optimiser l'onboarding, pas chercher plus d'utilisateurs. Comprendre pourquoi ceux qui sont là ne paient pas.

Cet article clôt la trilogie PostHog que je publie depuis le partenariat : audit V1 (le constat), audit V2 (la refonte), audit V3 (la trajectoire). Trois mois de Build in Public, trois audits, une seule constante : sans PostHog, je n'aurais pas pu écrire un seul de ces articles. Tracker l'invisible, c'est ce qui transforme un produit qui semble fonctionner en un produit qu'on peut vraiment piloter.

La semaine prochaine, je te montrerai comment je crée une vidéo par jour sur 4 plateformes en moins d'une heure avec Claude, ElevenLabs, Nano Banana, Kling AI et CapCut. La machine à contenu qui fait tourner la distribution de Sam Tennis, automatisée avec des Skills Claude.

À très vite,

Guillaume 👋

---

---

Questions fréquentes

Pourquoi faire un audit PostHog tous les mois sur la même app ?

Un audit isolé ne dit rien de la trajectoire. Il dit juste où tu en es à un instant T. Trois audits successifs avec la même grille de lecture (V1, V2, V3) montrent ce qui progresse, ce qui stagne, et ce qui régresse. C'est cette comparaison qui rend les décisions de produit possibles. Sans elle, tu pilotes à l'aveugle même avec un dashboard ouvert en permanence.

Comment tracker le coût d'un agent IA dans une application ?

PostHog propose un module LLM Analytics qui capture automatiquement les appels API vers les modèles (OpenAI, Anthropic, Gemini). Pour chaque appel, tu récupères le modèle utilisé, la latence, le nombre de tokens en entrée/sortie, et le coût en USD. Sur Sam Tennis, ça permet de voir que 973 appels IA coûtent 0,96 USD au total, soit 0,012 USD par utilisateur sur 3 semaines.

Pourquoi le funnel ordonné de PostHog peut afficher des chiffres incohérents ?

Le funnel ordonné exige que chaque étape soit envoyée par le même distinct_id, dans l'ordre, et après l'étape précédente. Si l'app change d'identité entre l'install et le signup (ID anonyme vs ID authentifié), ou si certaines étapes sont envoyées dans le désordre temporel, le funnel affiche zéro. Les volumes bruts par event restent corrects, mais le funnel est cassé. La correction passe presque toujours par un appel posthog.identify() au bon moment.

Faut-il configurer des alertes PostHog dès le début ?

Oui, surtout en phase post-lancement. Une alerte sur le DAU, le taux de signup et les achats te prévient quand quelque chose casse, sans que tu aies à regarder le dashboard tous les jours. Sur Sam Tennis V3, j'ai 4 alertes actives (DAU < 5, 0 signup_completed en 24h, pic signup_failed > 10/h, 0 purchase_completed en 7 jours). Ce qui manque : une alerte dédiée sur la chute de l'onboarding et une alerte sur les erreurs IA en production.

---

Pour aller plus loin

• Guide Complet PostHog 2026 - Toutes les fonctionnalités, le MCP, les Feature Flags, les coûts à éviter
• Build in Public #14 : Sam Tennis V2 (audit V2) - Le deuxième audit, juste après le lancement
• Build in Public #12 : L'audit PostHog V1 - Le premier audit, le constat d'échec
• Build in Public #13 : Les données de surface mentent - L'intégration FFT et l'agent LinkedIn
• Build in Public #11 : La méthode BMAD - Comment j'ai structuré la refonte V2/V3
• Guide Skills Claude 2026 - L'automatisation derrière la machine à contenu Sam Tennis
• Voir tous mes outils recommandés