Claude a analysé mes données produit sans que j'ouvre un seul dashboard
J'ai passé des années à construire des produits, et il y a toujours eu cette frustration de fond : tu peux shipper une feature, mais tu ne sais jamais vraiment ce que les gens en font. Ton agent IA peut te générer un onboarding complet, corriger des bugs, livrer une app entière. Mais il n'a aucune idée de l'endroit où tes utilisateurs décrochent. Il ne sait pas si quelqu'un utilise réellement la feature qu'il vient de coder.
Et c'est un vrai problème, parce que construire le produit, c'est seulement la moitié du boulot. Comprendre comment les gens l'utilisent, c'est l'autre moitié.
Alors je me suis posé une question simple : qu'est-ce qui se passerait si on donnait à un agent de code IA un accès direct aux vraies données produit ? Pas des mocks, pas des suppositions. Les données réelles de comportement utilisateur.
Pour tester ça, j'ai utilisé PostHog. C'est une plateforme qui capture comment les gens se comportent une fois qu'ils sont dans ton app. Et récemment, ils ont lancé un serveur MCP qui permet à des agents comme Claude Code ou Cursor d'interagir directement avec tes données produit. Donc dans cette expérience, j'ai construit une petite application, je l'ai connectée à PostHog, j'ai généré de l'activité utilisateur, et j'ai regardé si un agent IA pouvait comprendre ce qui se passait dans le produit sans que j'ouvre jamais un dashboard d'analytics.
Mettre en place les événements qui comptent vraiment
Avant de donner accès aux données à un agent IA, il faut déjà avoir des données. J'ai donc une app SaaS simple : landing page, flow d'inscription, processus d'onboarding, quelques features principales. Le produit exact n'a pas d'importance. Ce qui compte, c'est que les utilisateurs aient des endroits où ils peuvent réussir, se bloquer, ou partir complètement.
La connexion à PostHog est directe. Je crée un nouveau projet, je récupère la clé API, et comme on est sur Next.js, j'installe le SDK PostHog, j'ajoute mes credentials, et j'initialise le tout dans l'application.
À première vue, ça ressemble à un setup analytics classique. Mais PostHog ne collecte pas juste des pages vues. Il capture les données comportementales qu'on va ensuite donner à manger à notre agent IA. Si un agent doit nous dire pourquoi les utilisateurs quittent le produit, il lui faut quelque chose à analyser. Chaque inscription, chaque étape d'onboarding, chaque clic de bouton, chaque interaction avec une feature devient un signal qui construit cette image.
J'ai donc ajouté quelques événements personnalisés. Quand un utilisateur s'inscrit, on capture un événement sign-up. Quand il termine l'onboarding, on capture onboarding_completed. Et quand il utilise une des features principales, on capture feature_used.
L'assistant qui instrumente tout à ta place
J'ai ajouté ces événements à la main, mais il y a un chemin plus rapide. PostHog a un wizard IA qui gère toute la configuration pour toi. Tu lances une seule commande, npx @posthog/wizard, et il scanne ta codebase, identifie les actions qui ont du sens dans ton produit, et instrumente les événements automatiquement. Les inscriptions, les étapes d'onboarding, l'utilisation des features, il branche tout. Et en bonus, il configure même la connexion MCP qu'on va utiliser juste après.
Une chose que j'ai apprise en construisant des produits : un bon analytics repose sur le suivi des bons événements. C'est facile de collecter des milliers de points de données qui ne te disent rien. Le but, c'est de capturer les actions qui représentent une progression réelle dans le produit.
Générer de l'activité et laisser l'agent enquêter
Avec les événements en place, j'ai généré de l'activité. Quelques utilisateurs de test parcourent l'application. Certains terminent l'onboarding avec succès, d'autres partent à mi-chemin, et quelques-uns vont tomber sur un workflow volontairement cassé qu'on utilisera plus tard.
Si je retourne dans PostHog, les données commencent déjà à arriver. Les événements sont capturés, les utilisateurs se déplacent dans le produit, et PostHog construit une image complète de ce qui se passe. Normalement, c'est là que tu ouvrirais des dashboards et que tu commencerais à tout analyser toi-même. Mais ce n'est pas ce qu'on fait aujourd'hui.
À la place, on va laisser un agent IA mener l'enquête. PostHog a lancé un serveur MCP, et dans notre cas, on donne à Claude Code un accès à notre projet PostHog. La configuration est simple : dans la documentation PostHog, ils fournissent la config MCP avec les credentials nécessaires. J'ajoute ça à Claude Code, je redémarre l'agent, et une fois connecté, on est prêts.
Premier test. Au lieu d'ouvrir le dashboard PostHog, je pose simplement une question à Claude : peux-tu accéder à mon projet PostHog et me dire quels événements sont suivis ?
Et voilà. Claude se connecte à PostHog, interroge les événements disponibles, et renvoie les résultats directement dans le terminal. C'est un exemple basique, évidemment. La vraie question, c'est de savoir s'il peut vraiment nous aider à comprendre ce qui se passe dans le produit.
Trouver où les utilisateurs abandonnent l'onboarding
Souvenez-vous de ces utilisateurs de test. Certains ont terminé l'onboarding avec succès, mais d'autres ont décroché avant d'arriver au bout. Normalement, j'ouvrirais un dashboard en entonnoir, je filtrerais les événements, et je passerais du temps à chercher où les gens partent. À la place, je demande à Claude : analyse le flow d'onboarding et dis-moi où les utilisateurs décrochent.
Et là, Claude interroge les données PostHog tout seul. Il extrait les événements pertinents, compare les parcours utilisateurs, cherche des patterns, sans que j'écrive une seule requête SQL. Quelques secondes plus tard, il revient avec une réponse. Selon les données, la plupart des utilisateurs atteignent le flow d'onboarding sans problème, mais un pourcentage significatif abandonne le processus avant de terminer la dernière étape de configuration.
Honnêtement, c'est le moment où ça devient un peu étrange. Parce qu'on ne regarde plus des dashboards. On a une conversation avec notre plateforme d'analytics.
Et tu n'es même pas limité à ton terminal. PostHog vient de lancer une app Slack, qui est une autre surface pour parler à tes données. Au lieu d'être dans ton éditeur de code, tu peux être dans un thread Slack avec ton équipe, tagger PostHog, et poser exactement le même type de question.
Comprendre pourquoi les utilisateurs partent
Trouver un point de décrochage, c'est utile, mais c'est seulement la moitié de l'histoire. Savoir que les utilisateurs abandonnent l'onboarding, c'est une chose. Savoir pourquoi ils l'abandonnent, c'est ce qui t'aide vraiment à améliorer le produit.
Je pousse donc un peu plus loin. Je demande à Claude : peux-tu enquêter sur les raisons pour lesquelles les utilisateurs décrochent avant de terminer l'onboarding ?
C'est là que PostHog devient vraiment intéressant, parce qu'on n'est plus limité aux données d'événements. PostHog a aussi des enregistrements de session, ce qui veut dire qu'on peut voir exactement comment les utilisateurs ont interagi avec le produit avant de partir. Claude commence à parcourir les données et identifie quelques sessions associées à des utilisateurs qui ont abandonné le flow. Et presque immédiatement, un pattern apparaît.
Plusieurs utilisateurs atteignent le même écran d'onboarding, y passent un temps étonnamment long, cliquent un peu partout, puis partent sans terminer le processus. Ouvrons un de ces enregistrements.
Et voilà. L'utilisateur arrive à cette étape, hésite quelques secondes, clique autour pour chercher la prochaine action, essaie plusieurs choses, et finit par quitter l'application.
Ça va devenir encore mieux, parce que PostHog prépare quelque chose qui s'appelle replay vision. L'idée, c'est qu'une IA regarde tes enregistrements à ta place, signale automatiquement les bugs, repère les moments où les utilisateurs sont frustrés, et fait remonter les instants qui comptent vraiment. À surveiller.
Ce qui est intéressant, c'est que quand tu construis le produit toi-même, ce genre de problème est très facile à rater. Tout paraît évident parce que tu sais déjà comment le produit fonctionne. Mais dès que tu regardes un vrai utilisateur interagir avec, tu commences à remarquer des frictions qui ne sont jamais apparues pendant le développement.
Les recommandations de Claude
Je retourne voir Claude et je pose une autre question : en te basant sur les analytics et les enregistrements de session, quels changements recommanderais-tu ?
Quelques instants plus tard, il revient avec plusieurs suggestions. Le flow d'onboarding a une étape suivante peu claire. Les utilisateurs passent trop de temps sur un écran spécifique. Et le call to action n'est pas assez évident pour les nouveaux utilisateurs.
Honnêtement, aucune de ces recommandations n'est révolutionnaire. Un bon product manager pourrait probablement les identifier aussi. Ce qui est intéressant, c'est la vitesse à laquelle on y est arrivé. Au lieu de construire des dashboards manuellement, filtrer des utilisateurs, regarder des enregistrements un par un, et tout assembler soi-même, l'agent IA a mené l'enquête et résumé les conclusions pour nous.
Tester le correctif avec un feature flag
Maintenant qu'on a une hypothèse, voyons si la corriger améliore réellement les résultats. Une chose que j'aime avec PostHog, c'est que ça ne s'arrête pas à l'analytics. Une fois que tu as identifié un problème, tu peux tester des solutions potentielles sans avoir besoin d'une plateforme complètement séparée.
Au lieu de remplacer immédiatement le flow d'onboarding pour tout le monde, on va utiliser un feature flag. Les feature flags sont des déploiements contrôlés. Ils te permettent d'exposer une nouvelle expérience à un sous-ensemble d'utilisateurs pendant que tout le monde continue de voir la version existante.
Pour cet exemple, je mets à jour l'écran d'onboarding en suivant les recommandations de Claude. On rend l'action principale plus évidente, on simplifie certains textes, et on réduit une partie de la friction qui est apparue dans les enregistrements de session. Une fois la nouvelle version prête, je crée un feature flag dans PostHog et je le déploie sur une portion des utilisateurs seulement.
On a maintenant deux groupes. Un groupe voit le flow d'onboarding original, l'autre voit la version mise à jour. Et comme tout est déjà connecté à PostHog, on peut mesurer les résultats automatiquement.
Je génère de l'activité utilisateur supplémentaire et j'attends. Après avoir laissé les deux versions tourner un moment, on compare les taux de conversion. Et effectivement, le flow d'onboarding mis à jour performe nettement mieux. Plus d'utilisateurs terminent le processus, moins d'utilisateurs abandonnent, et le point de décrochage qu'on avait identifié devient beaucoup moins significatif.
Points clés à retenir
- Un agent IA peut analyser tes données produit sans que tu touches à un dashboard : Claude Code connecté via MCP interroge PostHog, compare les parcours utilisateurs, et identifie les points de décrochage en quelques secondes.
- Les enregistrements de session révèlent le pourquoi, pas juste le où : les données d'événements montrent où les utilisateurs partent, mais c'est en regardant les sessions que tu découvres la friction réelle.
- Le wizard PostHog automatise l'instrumentation : une seule commande scanne ta codebase et configure les événements pertinents, plus la connexion MCP.
- Les feature flags ferment la boucle : une fois le problème identifié, tu testes un correctif sur un sous-ensemble d'utilisateurs et tu mesures l'impact sans plateforme séparée.
- L'IA n'a pas remplacé l'analytics, elle a réduit le travail manuel : le même workflow identifier un problème, rassembler des preuves, tester une solution, mesurer le résultat, mais avec beaucoup moins de temps passé à creuser dans les dashboards.
Ce que ça change vraiment
C'est un exemple simplifié, mais c'est essentiellement le même workflow que beaucoup d'équipes produit suivent tous les jours. Tu identifies un problème, tu rassembles des preuves, tu testes une solution, et tu mesures si le changement a réellement aidé. La différence ici, c'est qu'au lieu de passer des heures à creuser dans des dashboards et des enregistrements, on a utilisé un agent IA pour accélérer le processus d'investigation.
Et honnêtement, c'est la partie qui m'a le plus surpris. L'IA n'a pas magiquement remplacé l'analytics, les product managers, ou la recherche utilisateur. Ce qu'elle a fait, c'est réduire drastiquement la quantité de travail manuel nécessaire pour passer d'une question à une réponse. Au lieu de demander où les utilisateurs décrochent et de passer l'heure suivante à chasser dans les données, tu poses simplement la question et tu commences à travailler avec les résultats.
Ce qui est intéressant, ce n'est pas que l'IA puisse analyser ton produit. C'est que l'analytics produit devient quelque chose à qui tu peux parler. Au lieu de creuser dans des dashboards et d'écrire des requêtes, tu poses des questions et tu obtiens des réponses basées sur de vraies données utilisateur.
Et c'est ce que j'aime avec PostHog. Entre l'analytics, les enregistrements de session, les feature flags, l'expérimentation, et maintenant MCP, ça donne aux agents IA le contexte dont ils ont besoin pour comprendre ce qui se passe réellement dans ton produit.