Demandez à vos données où les gens lâchent

Ce que c'est et pourquoi ça compte

Les gens téléchargent votre app, et ensuite ? Une partie arrive au premier vrai usage, une autre se perd en route. Où, en général vous ne le savez pas : vous ouvrez vos analytics, regardez dix graphiques et refermez sans rien avoir changé.

Si vous utilisez PostHog pour vos analytics, vous pouvez le connecter à Claude Code avec son serveur MCP. MCP est la façon standard dont Claude Code parle à un service externe : une fois connecté, Claude interroge vos données tout seul, avec les outils de PostHog pour les funnels, les requêtes, les insights, les feature flags et les expériences. Et comme c'est la même session que celle qui contient votre code, il passe directement du chiffre à l'écran.

La boucle complète : le funnel, l'étape où vous perdez le plus de monde, le code de cet écran, une modification montrée à la moitié des utilisateurs, le résultat quelques jours plus tard. Se connecter au serveur MCP est gratuit et PostHog a une offre gratuite généreuse sur chaque produit, sans carte bancaire. Seuls certains outils qui utilisent l'IA de PostHog peuvent être facturés à part.

1. Connectez PostHog à Claude Code

Le serveur MCP de PostHog est hébergé par PostHog, à l'adresse https://mcp.posthog.com/mcp. Dans le terminal, en dehors de Claude Code, lancez :

claude mcp add --transport http posthog https://mcp.posthog.com/mcp -s user

-s user veut dire « pour moi, dans tous les projets ». Sans, le serveur ne vaut que dans le projet où vous êtes, qui est la portée par défaut. Ensuite, ouvrez Claude Code, tapez /mcp, choisissez posthog et connectez-vous : le navigateur s'ouvre, vous vous identifiez sur PostHog et vous autorisez. Pas de clés à copier, et c'est PostHog qui vous envoie vers la bonne région, États-Unis ou Europe, selon votre compte.

Avec Claude Code, le serveur n'expose qu'un outil, exec, avec lequel Claude trouve et appelle les autres quand il en a besoin : vous économisez du contexte. D'abord, vérifiez le projet :

Utilise PostHog : dis-moi à quelle organisation et à quel projet tu es connecté, et donne-moi les 20 événements les plus fréquents des 30 derniers jours, avec le nombre de personnes uniques pour chacun. Ne crée et ne modifie rien.

Si au début vous voulez que Claude puisse seulement lire, utilisez celle-ci à la place de la commande précédente, avec ?readonly=true à la fin de l'adresse : les outils qui créent, modifient ou suppriment disparaissent. Pour la partie flag, retirez-la avec claude mcp remove posthog et remettez la connexion normale. Et comme le dit PostHog lui-même, lisez chaque appel avant de l'approuver.

claude mcp add --transport http posthog "https://mcp.posthog.com/mcp?readonly=true" -s user

2. Le funnel, de l'installation au premier vrai usage

Un funnel, ou entonnoir, est une suite d'étapes dans l'ordre, avec le nombre de personnes qui atteignent chacune. Le premier vrai usage, c'est vous qui le définissez : le premier entraînement terminé, la première note enregistrée. Pas « a ouvert l'app », mais le moment où la personne a obtenu ce pour quoi elle l'a téléchargée. Dans les apps mobiles, les SDK de PostHog peuvent enregistrer tout seuls l'événement Application Installed : vérifiez qu'il est activé.

Utilise PostHog. Construis un funnel des 30 derniers jours, de l'installation au premier vrai usage de mon app : [Application Installed] → [inscription terminée] → [onboarding fini] → [premier entraînement terminé]. Vérifie d'abord que ces événements existent vraiment et dis-moi s'il en manque, sans les inventer. Ensuite, donne-moi pour chaque étape combien de personnes l'atteignent, le pourcentage par rapport à l'étape précédente et le temps qu'elles mettent en général.

Remplacez les noms entre crochets par ceux de vos événements : si vous ne les connaissez pas, prenez-les dans la liste de tout à l'heure. Et demandez le pourcentage par rapport à l'étape précédente : la documentation de PostHog explique que c'est lui qui montre où il y a le plus à gagner.

3. Trouvez où ils lâchent

Dans le funnel, à quelle étape est-ce que je perds le plus de monde ? Donne-moi le nombre et le pourcentage. Ensuite, découpe cette étape par système d'exploitation, version de l'app et pays, et dis-moi si la chute est la même pour tout le monde ou concentrée dans un groupe. Enfin, trouve dans le code l'écran où se passe cette étape et montre-moi le fichier.

Le découpage par groupes compte : si la chute est entièrement sur une version ou un système, c'est peut-être un bug et pas un problème de design. Et si vous enregistrez les sessions avec PostHog, demandez à Claude de lister quelques personnes qui se sont arrêtées précisément là et regardez leurs enregistrements : c'est souvent le moyen le plus rapide de comprendre pourquoi.

4. Une modification, pour la moitié des utilisateurs

Maintenant, demandez une proposition, pas une correction :

Ouvre le code de l'écran [étape] et donne-moi les 3 raisons les plus probables pour lesquelles les gens s'arrêtent là, à partir de ce que tu vois dans le code et dans les données. Pour chacune, propose une seule petite modification. N'écris pas de code tant que je n'en ai pas choisi une.

Choisissez-en une. Pour la tester, il faut un feature flag, c'est-à-dire un interrupteur que l'app lit pendant qu'elle tourne (j'en parle dans le guide INTERRUTTORE, strikt.fit/interruttore). Pour mesurer, le plus propre est une expérience PostHog : elle crée le flag avec deux variantes, control (comme maintenant) et test (la modification), répartit les gens au hasard, garde la trace de qui voit quoi et fait les calculs statistiques à votre place.

Utilise PostHog. Crée une expérience appelée [onboarding-plus-court] avec deux variantes, control et test, réparties 50/50, avec le funnel de [étape] à [premier entraînement terminé] comme métrique principale. Ensuite, mets la modification choisie derrière son flag : avec control l'utilisateur voit l'écran actuel, avec test le nouveau. N'inclus que les personnes qui arrivent sur cet écran pour la première fois, et si le flag ne peut pas être lu, affiche la version actuelle. Avant de la lancer, dis-moi combien de personnes il faut et combien de jours ça prend avec mon trafic.

« Pour la première fois », parce que PostHog conseille de n'inclure que les personnes concernées par la modification. « Si le flag ne peut pas être lu », pour qu'un problème réseau ne montre pas à tout le monde quelque chose à moitié fini. « Combien de personnes il faut », parce que le calculateur de PostHog vous le dit avant de commencer. Et sur iPhone, la modification doit déjà être dans la version publiée : le flag n'allume que du code qui existe.

Avant le 50/50, PostHog suggère un tour d'essai sur une petite partie des utilisateurs, par exemple 5 %, pendant quelques jours : vous vérifiez que les événements arrivent et qu'il n'y a pas de plantages. Si l'expérience démarre cassée et que vous la relancez, les résultats ne sont plus fiables, parce que beaucoup de gens ont déjà vu la modification.

5. Lisez le résultat

Quand les jours indiqués par le calculateur sont passés, par exemple une semaine :

Utilise PostHog. Donne-moi les résultats de l'expérience [onboarding-plus-court] : combien de personnes par variante, la conversion de control et de test, et si la différence est statistiquement significative. Dis-moi si on a atteint le nombre de personnes nécessaire. Si ce n'est pas significatif ou s'il en manque, dis-le clairement et ne déclare pas de gagnant.

Si test gagne, vous l'étendez à tout le monde et vous faites le ménage : PostHog lui-même dit qu'en fin d'expérience on garde le code de la variante gagnante et on supprime celui de la perdante. S'il n'y a pas de différence, c'est aussi un résultat : revenez à la liste des 3 causes et essayez la deuxième.

C'est test qui a gagné l'expérience [onboarding-plus-court]. Termine-la dans PostHog en étendant test à tout le monde, puis retire du code le flag et l'ancienne version, lance les tests et dis-moi ce que tu as changé.

6. Comment ne pas vous tromper vous-même

• Décidez la durée à l'avance. Regarder les résultats tous les jours et s'arrêter au premier joli chiffre, c'est ce que PostHog appelle le peeking problem : à force de jeter un œil, tôt ou tard quelque chose semble gagner par hasard.
• Assez de monde. Avec peu d'utilisateurs, une différence n'est souvent que du hasard. Pour vous donner une idée, dans l'exemple de la documentation de PostHog, avec une conversion de 10 % et un changement de 20 % à détecter, il faut environ 3 600 personnes par variante. Si vous en avez beaucoup moins, testez des modifications plus grosses.
• Une modification à la fois. Si vous changez le texte, la couleur et le nombre d'étapes en même temps, vous ne saurez jamais ce qui a marché.
• Regardez aussi ce qui empire. Un écran plus court peut amener plus de monde à l'étape suivante et moins de monde à revenir le lendemain. Choisissez à l'avance une seconde métrique à surveiller.

Les erreurs les plus courantes

• Laisser Claude deviner les noms des événements. Demandez d'abord la liste, puis construisez le funnel.
• Travailler sur le mauvais projet. Une connexion a un compte et un projet actif : vérifiez lequel avant de créer quoi que ce soit.
• Activer la modification pour tout le monde. Sans un groupe qui voit l'ancienne version, vous n'avez rien à comparer.
• Arrêter l'expérience au premier bon jour. Attendez la durée décidée à l'avance.
• Laisser le flag dans le code après la décision. Retirez le flag et la variante perdante.

Check-list

• Serveur MCP de PostHog ajouté et connexion faite depuis /mcp.
• Bon projet vérifié, liste des événements en main.
• Funnel jusqu'au premier vrai usage, avec les pourcentages étape par étape.
• Pire étape découpée par groupes et écran trouvé dans le code.
• Une seule modification, derrière une expérience 50/50, testée d'abord sur peu d'utilisateurs.
• Durée et nombre de personnes décidés avant de commencer.
• Résultat lu avec sa significativité, flag retiré à la fin de l'expérience.

Questions fréquentes