Parler à ses données produit sans construire un nouveau dashboard
Ta croissance cale quelque part, mais où ? Ce qui bloque tes utilisateurs est déjà écrit dans ta base de données — mais y répondre en langage naturel demande un système plus sophistiqué qu’il n’y paraît. Voici comment un tel système fonctionne vraiment, couche par couche.
Ta croissance cale quelque part dans ton produit — et cet endroit est déjà écrit dans ta base de données
Tu sais que quelque chose bloque : des utilisateurs qui s’inscrivent puis disparaissent, un plan qui convertit moins bien qu’un autre, des comptes actifs qui ralentissent avant de résilier. Ce que tu ne sais pas, c’est où exactement, ni pourquoi — et tu n’as ni le temps ni l’envie de devenir data analyst pour le découvrir.
La réponse existe déjà, quelque part dans ta base de données. Ce qui manque n’est pas la donnée — c’est tout ce qu’il faut construire pour qu’une question posée en langage naturel obtienne une vraie réponse, fondée sur cette donnée.
1. Ce qu’un tel système peut réellement te révéler
Avant de s’attarder sur comment un tel système fonctionne, il vaut la peine de s’arrêter sur ce qu’il permet vraiment. Une base de données produit contient déjà les réponses à la plupart des questions qui décident si ton SaaS grandit ou stagne — encore faut-il pouvoir les poser.
Ce ne sont pas des questions de data analyst. Ce sont celles que tout founder se pose sans jamais avoir le temps ni l’outil pour vraiment y répondre — et la réponse, aujourd’hui, dort déjà dans ta base.
- Quel pourcentage des inscrits crée un premier projet dans les 24 heures ?
- À quelle étape précise de l’onboarding perd-on le plus de monde ?
- Quels comptes ralentissent leur usage depuis un mois, avant même de songer à résilier ?
- Quelles fonctionnalités distinguent vraiment les comptes qui restent des comptes qui partent ?
- Quel plan convertit le mieux depuis l’essai gratuit, et ce chiffre évolue-t-il ?
- Qui, parmi mes clients les plus actifs, n’a jamais parlé à mon équipe support ?
2. Accumuler la bonne donnée avant de pouvoir répondre à quoi que ce soit
Une base transactionnelle classique enregistre ce qui se passe — une inscription, un paiement, un clic — mais rarement sous une forme qui répond directement à une question analytique. Savoir « à quelle étape les utilisateurs décrochent » suppose d’avoir déjà capturé, événement par événement, l’avancement de chacun dans l’onboarding, pas seulement la date de son inscription.
Construire ça demande des migrations concrètes : ajouter des colonnes ou des tables dédiées aux métriques — première action, compteurs d’usage par fonctionnalité, indicateurs d’activité — puis les tenir à jour en continu à chaque nouvel événement. Sans cette base posée à l’avance, aucune requête, même parfaitement écrite, ne peut répondre à une question dont la donnée n’existe simplement pas.
- Une question analytique ne se répond qu’avec une donnée déjà structurée pour ça.
- Ajouter une métrique demande une migration, pas juste une nouvelle requête.
- L’historique manquant ne se rattrape pas toujours après coup.
- Plus une métrique est pensée tôt, plus elle a d’historique à interroger plus tard.
3. Suivre un schéma qui bouge, pas une photo prise une fois
Un schéma de base de données n’est jamais figé : chaque fonctionnalité livrée ajoute une table, renomme une colonne, ou laisse une ancienne relation devenir obsolète sans la supprimer. Une compréhension du schéma qui date de six mois peut suffire à faire joindre deux tables sur une clé qui n’a plus le même sens qu’avant.
Un système fiable doit donc relire la structure réelle avant chaque question, pas se reposer sur une documentation figée ou un schéma mémorisé une fois pour toutes — sinon la migration la plus récente casse silencieusement toutes les réponses suivantes, sans que personne ne le remarque avant qu’une décision soit prise dessus.
- Chaque fonctionnalité livrée peut changer discrètement la structure sous-jacente.
- Une clé de jointure valide hier peut ne plus l’être après une migration.
- La structure réelle doit être relue à chaque question, pas mémorisée une fois.
- Une erreur de schéma silencieuse est plus coûteuse qu’une absence de réponse.
4. Enchaîner plusieurs requêtes, pas en écrire une seule
« Pourquoi cette cohorte part plus vite que les autres » ne se répond presque jamais avec une seule requête. Il faut d’abord définir la cohorte, puis mesurer son comportement sur une période donnée, puis comparer ce résultat à une référence — trois requêtes distinctes, dont la deuxième dépend directement du résultat de la première.
Enchaîner ces requêtes, adapter la suivante au résultat de la précédente, et savoir reconnaître le moment où la réponse est suffisamment étayée pour s’arrêter : c’est un exercice de raisonnement au moins autant que d’écriture SQL — et c’est ce qui sépare un vrai système conversationnel d’un simple générateur de requête isolée.
- La plupart des questions utiles demandent plusieurs requêtes liées entre elles, pas une seule.
- Chaque requête suivante s’ajuste au résultat réel de la précédente.
- Savoir quand s’arrêter compte autant que savoir quoi interroger.
- Une requête isolée, aussi bien écrite soit-elle, répond rarement à une vraie question business.
5. Transformer un tableau de résultats en réponse qu’on comprend
Une table de résultats — trois colonnes, douze lignes, des identifiants techniques — n’est pas une réponse. Il faut encore la lire, la remettre en contexte (est-ce que 12 % est beaucoup ? est-ce nouveau ou habituel ?), et la reformuler dans les mots qu’on utiliserait pour l’expliquer à un collègue plutôt qu’à une base de données.
Cette dernière étape est celle qu’on sous-estime le plus en construisant ce genre de système : traduire correctement dans les deux sens — la question humaine vers la requête technique, puis le résultat technique vers l’explication humaine — sans perdre de nuance, ni en ajouter une qui n’est pas dans la donnée.
- Un résultat brut n’est pas une réponse tant qu’il n’est pas remis en contexte.
- Le même chiffre peut être normal ou alarmant selon l’historique de comparaison.
- La traduction se fait dans les deux sens : question, puis résultat.
- Aucune nuance n’est ajoutée qui ne soit pas réellement présente dans la donnée.
6. Garantir qu’aucune requête ne peut modifier la donnée, quoi qu’il arrive
Un système qui explore une base de production doit distinguer sans exception la lecture de l’écriture. La question n’est pas seulement « est-ce que ça répond bien », c’est « est-ce que ça peut, techniquement, casser quelque chose » — même si la question posée était ambiguë ou si le système s’est trompé d’interprétation.
La bonne réponse ne tient pas à une consigne qu’on espère respectée, mais à une contrainte imposée par la base elle-même : un rôle dédié qui ne peut physiquement pas écrire, quel que soit ce qu’on lui demande. Toute commande qui modifierait une donnée doit être traitée à part, et attendre une confirmation explicite avant de s’exécuter.
- La lecture et l’écriture ne doivent jamais emprunter le même chemin technique.
- La garantie vient de la base elle-même, pas d’une instruction qu’on espère suivie.
- Une question ambiguë ne doit jamais pouvoir déclencher une écriture par erreur.
- Toute modification reste une action distincte, jamais une conséquence automatique.
Ce que ce système ne décide jamais à ta place
- Ce qui compte comme un succès pour ton produit reste une décision produit — le système mesure ce qu’on lui demande de mesurer, il ne fixe pas tes objectifs.
- Une réponse juste sur une donnée mal accumulée reste fausse — si une métrique n’a jamais été suivie, aucune requête ne peut la faire apparaître rétroactivement.
- Une corrélation trouvée dans les résultats n’est pas une cause : elle reste une hypothèse à vérifier, pas une conclusion à exécuter telle quelle.
- Toute écriture ou migration reste une décision humaine, quel que soit le niveau de confiance de l’analyse.
Un système redoutable — mais qui ne se monte pas en un week-end
Mis bout à bout, ça donne un système puissant : poser n’importe quelle question sur son produit, en langage naturel, et obtenir une réponse fondée sur les vraies données, mise à jour en continu à mesure que le produit évolue. Mais ce n’est pas un projet d’un week-end — le construire soi-même demande une vraie expertise en base de données pour concevoir les bonnes migrations et accumuler les métriques avant d’en avoir besoin, et une expertise tout aussi rare pour enchaîner correctement langage naturel → plusieurs requêtes SQL → réponse en langage naturel. Peu d’équipes SaaS, surtout en petite structure, ont les deux sous la main en même temps.
C’est exactement ce qu’Onny a déjà construit : l’exploration de schéma, l’enchaînement de requêtes en lecture seule, et la traduction en langage clair. Connecte ta base Supabase et tu peux poser ta première vraie question — et obtenir ta première réponse sourcée — dans la journée, sans recruter un data engineer pour y arriver.
Récupère tes premiers insights produit dès aujourd’hui
Connecte Supabase et pose la question qui te trotte dans la tête depuis des semaines. L’exploration de schéma, les requêtes enchaînées et la traduction en langage clair sont déjà prêtes — pas dans six mois, aujourd’hui.
Analyser mon produit