J’ai parlé à 400 utilisateurs. Les analytics ne m’ont toujours pas dit quoi construire.

J’ai passé un temps gênant à fixer des analytics produit en espérant que le prochain graphique me dirait quoi construire. Ça n’est jamais arrivé. Les décisions produit les plus claires de Notis sont venues d’entretiens de découverte client (plus de 400 conversations avec des utilisateurs), pas d’un Dashboard. Les analytics me montraient où les gens décrochaient. Les appels m’expliquaient pourquoi ça comptait pour eux, ce qu’ils essayaient de faire et quel problème méritait d’être résolu ensuite.

Cette distinction compte si tu es un fondateur en phase de démarrage. Les données quantitatives sont excellentes pour mesurer un comportement une fois qu’il y a assez de comportement à mesurer. Elles sont bien moins bonnes pour découvrir les mots, les inquiétudes, les contournements et les usages inattendus derrière ce comportement. La bonne réponse n’est pas « entretiens ou analytics ». C’est les analytics pour le quoi, les conversations pour le pourquoi, et un système rigoureux pour transformer les deux en décision.

Les analytics m’ont dit ce qui s’était passé. Les utilisateurs m’ont dit ce que ça voulait dire.

Un Dashboard peut montrer que l’activation chute après l’étape trois. Il ne peut pas te dire de façon fiable si l’utilisateur était perdu, distrait, pas convaincu, inquiet pour sa vie privée, ou simplement en train de résoudre un autre problème que celui que ton onboarding supposait. Les cinq peuvent produire le même schéma d’événements. Ils demandent cinq décisions produit différentes.

Dans mon cas, le schéma le plus important n’était pas une demande de fonctionnalité. C’était la personne derrière la demande. Après suffisamment d’appels, j’ai compris que beaucoup des fondateurs qui tiraient le plus de valeur de Notis avaient des traits de TDAH, même quand ce n’était pas comme ça qu’ils se décrivaient. Ils n’avaient pas besoin d’un Dashboard parfait de plus. Ils avaient besoin d’un moyen sans friction de capturer une intention et de laisser un agent faire avancer le travail depuis les endroits où ils communiquaient déjà.

Aucun rapport d’analytics ne m’a apporté ce positionnement. Il s’est accumulé lentement, puis tout s’est éclairé d’un coup. C’est la vérité un peu agaçante de la découverte client menée par le fondateur : le tableur contient rarement la percée. C’est ton cerveau qui construit un modèle à force d’entendre la même douleur, formulée de mille façons.

Lance avant que tes analytics soient impressionnants

Les fondateurs repoussent souvent les conversations clients jusqu’à ce que le produit soit présentable. C’est l’inverse qu’il faut faire. Les conseils essentiels de Y Combinator sont sans détour : lance tout de suite, parle à tes clients et itère au lieu d’attendre un produit « parfait ». Le produit doit juste être assez utile pour que sa valeur l’emporte sur ses défauts.

Ça correspond à mon expérience avec Notis. J’ai mis la landing page en ligne dès la première semaine et j’ai commencé à embarquer des utilisateurs dès que j’ai eu quelque chose que j’utilisais moi-même. La première version était pleine de bugs. Les gens lui mettaient quand même cinq étoiles, parce qu’ils voyaient que je m’en souciais, que je répondais et que je corrigeais. Les premiers utilisateurs ne sont pas allergiques aux bugs. Ils sont allergiques à l’indifférence.

Lancer tôt ne sert pas à collectionner des inscriptions pour la vanité. Ça sert à réduire la distance entre tes hypothèses et la réalité. Un petit nombre de vrais utilisateurs peut t’en apprendre plus qu’une montagne d’études de marché hypothétiques, parce que leur friction a un enjeu. Ils ont essayé d’accomplir une tâche et quelque chose les en a empêchés.

Un système de découverte client qui ne s’effondre pas à 400 appels

Au début, parler aux utilisateurs est merveilleusement impossible à industrialiser. Avec le temps, cette même force devient un problème : tu retiens l’appel le plus bruyant, la dernière plainte ou le client que tu apprécies. La réponse n’est pas d’arrêter de parler. C’est d’ajouter un système qui préserve les preuves et réduit le biais de récence.

Commence par une analyse par conversation

Ne balance pas des centaines de transcriptions dans un prompt géant en demandant « les principaux enseignements ». Ça produit une bouillie plausible. Analyse d’abord chaque conversation séparément. Extrais l’objectif de l’utilisateur, sa friction, son contournement, l’enjeu émotionnel, le résultat demandé et les passages exacts qui appuient chaque affirmation. Garder la première passe étroite la rend plus facile à vérifier.

Consolide par utilisateur avant de consolider par marché

Un même utilisateur peut décrire le même problème de fond pendant l’onboarding, au support et lors d’un appel avec le fondateur. Synthétise ces échanges en une vue par utilisateur avant de comparer les utilisateurs entre eux. Sinon, tes clients les plus bavards comptent pour trois voix et les plus discrets pour une seule.

Cherche les schémas qui changent une décision

Un thème n’est pas utile parce qu’il revient souvent. Il l’est quand il change ce que tu fais. Relie chaque schéma à une décision : corriger l’onboarding, améliorer la fiabilité, changer le positionnement, construire une fonctionnalité, ajuster les prix ou délibérément ne rien faire. Garde les preuves attachées pour que le fondateur puisse contester la synthèse au lieu de se fier à un paragraphe sûr de lui écrit par un modèle.

L’IA doit démultiplier l’écoute, pas la remplacer

Le workflow que j’ai construit pour moi part des traces de conversation, envoie un sous-agent sur chaque conversation, consolide les résultats par utilisateur, puis produit un rapport transversal. Des modèles bon marché suffisent pour l’extraction ; le modèle plus puissant doit être réservé à la synthèse et à la priorisation. Le rapport n’est pas la roadmap. C’est le dossier de preuves que j’utilise pour décider de ce qui mérite de l’attention.

Des outils comme Langfuse donnent déjà aux équipes produit IA des traces structurées, des sessions, des scores et des métadonnées. Cette instrumentation a de la valeur. Mais l’observabilité répond à une autre question que la stratégie. Savoir qu’un agent a échoué, a réessayé ou a obtenu un mauvais score ne te dit pas automatiquement quel segment d’utilisateurs prioriser ni quel cas d’usage doit définir le produit.

C’est là que la génération actuelle d’outils « d’insights produit par IA » risque de devenir un Dashboard de plus. Un fondateur n’a pas besoin d’un joli nuage de demandes de fonctionnalités. Le résultat utile, c’est un brief hebdomadaire qui dit : voici les besoins récurrents, voici les preuves, voici qui les vit, voici ce qui a changé, et voici les décisions qui méritent maintenant d’être discutées.

La vie privée n’est pas un réglage qu’on ajoute après coup

Les conversations clients sont souvent les données les plus sensibles d’un produit. Elles contiennent des informations personnelles, des problèmes d’entreprise, un historique de support et des informations dont les utilisateurs n’imaginaient pas qu’elles deviendraient du matériel d’entraînement générique. Je n’enverrais pas des conversations Notis brutes à un service d’analyse tiers quelconque, même avec un Dashboard magnifique.

Pour les produits sensibles, la meilleure architecture est locale ou contrôlée par le client : livrer la logique d’analyse sous forme de Skill ou de MCP, la faire tourner dans l’environnement Claude ou Codex de l’entreprise, et ne renvoyer que le rapport demandé par l’équipe. Langfuse documente aussi une option de déploiement auto-hébergé pour les équipes qui ont besoin de contrôler l’infrastructure. L’auto-hébergement ne règle pas à lui seul toutes les questions de confidentialité, mais il déplace la frontière vers un endroit que le client peut inspecter et gouverner.

Ce que je ferais si je relançais aujourd’hui

Je lancerais dès qu’un vrai cas d’usage fonctionnerait de bout en bout. Je planifierais des conversations avant de monter une vraie pile d’analytics. Après chaque appel, je noterais le résultat souhaité par l’utilisateur, son contournement actuel, sa plus forte frustration et la phrase qui résume le mieux le problème. Une fois le volume devenu pénible, j’automatiserais la synthèse, pas la relation.

Je garderais aussi toute la boucle connectée. Les notes ne doivent pas mourir dans un dossier de transcriptions. Les schémas doivent devenir des décisions, les décisions des tâches, et les changements livrés doivent être confrontés aux conversations suivantes. Cette couche d’exécution connectée, c’est la raison pour laquelle on a reconstruit Notis autour d’un Workspace agentique, au lieu de traiter l’IA comme une boîte de chat qui produit encore plus de texte.

Quatre cents appels ne m’ont pas donné une roadmap parfaite. Ils m’ont donné mieux : un modèle plus précis des personnes pour qui je construisais. Les analytics m’ont aidé à mesurer ce modèle. Ils ne l’ont pas créé.

Si tu es encore en train de peaufiner avant le lancement, arrête. Mets la partie utile devant quelqu’un. Demande ce qu’il essayait d’accomplir. Écoute le contournement qu’il avait bricolé avant ton arrivée. Puis recommence jusqu’à ce que les schémas deviennent impossibles à ignorer. Le Dashboard peut attendre une semaine. La conversation, non.