La BI sans data lake

La plupart des projets de BI dans les startups démarrent trop tôt et voient trop grand.

Un fondateur pose une question simple : « Les utilisateurs venus de ce canal reviennent-ils après leur première exécution ? » La réponse devrait tenir dans une requête. Au lieu de cela, cela se transforme souvent en projet de plateforme : connecter chaque source, construire un entrepôt, définir des événements, nettoyer les identités, câbler des tableaux de bord, et attendre.

Ce travail finit par compter. Mais pour une petite équipe, ce peut être le mauvais premier mouvement. La base de données du produit sait déjà l'essentiel de ce que le fondateur a besoin de savoir. Elle sait qui s'est inscrit, qui a exécuté quelque chose, ce qu'ils ont utilisé, combien cela a coûté, ce qui a échoué, et s'ils sont revenus.

Le vrai problème n'est pas de savoir où réside la vérité. C'est de savoir comment laisser un agent analyser cette vérité sans exposer la base de données de production brute.

C'est le modèle que nous utilisons chez VM0 : une branche Neon masquée, en lecture seule, qui donne à nos agents assez de vérité pour faire de la BI, sans leur donner les données qu'ils ne devraient jamais voir.

Le problème du fondateur : les questions arrivent avant l'équipe data

Les entreprises en phase d'amorçage ne manquent pas de questions. Elles manquent de temps.

Chaque jour, l'équipe fondatrice veut savoir des choses comme :

• Le trafic d'hier s'est-il transformé en vrais utilisateurs ?
• Quels canaux d'inscription produisent des personnes qui exécutent réellement quelque chose ?
• Les utilisateurs de la première exécution reviennent-ils après 7 ou 30 jours ?
• Quels comptes payants deviennent silencieux ?
• Quelle route de modèle génère le coût ?
• Les fraudeurs en période d'essai consomment-ils du calcul avant de convertir ?
• La santé du produit s'est-elle améliorée ou dégradée depuis hier ?

Aucune de ces questions n'est exotique. Elles constituent le rythme opérationnel d'une startup.

Mais y répondre avec le manuel BI traditionnel génère beaucoup de surcharge. On commence généralement par déplacer les données hors de la base de données du produit vers un autre système. On les normalise ensuite, on définit des métriques, on reconstruit les relations et on met en place des tableaux de bord. L'équipe obtient une stack analytique plus propre, mais le fondateur attend souvent des jours ou des semaines une réponse qui aurait pu commencer par une requête SQL.

Pour une petite startup, ce compromis peut être à l'envers. Vous n'avez pas besoin d'une plateforme de données complète pour poser vos 20 premières questions opérationnelles. Vous avez besoin d'un moyen sûr d'interroger la source de vérité que vous possédez déjà.

La base de données est déjà la source de vérité

Chez VM0, la base de données du produit contient les faits qui comptent pour bon nombre de décisions au niveau du fondateur :

• Organisations et utilisateurs
• État d'inscription et d'abonnement
• Exécutions et planifications d'agents
• Consommation de crédits et événements d'usage
• Modèles sélectionnés et routes de fournisseurs
• État des connecteurs
• État des échecs et horodatages

Ces relations sont déjà présentes. Elles sont plus fraîches que n'importe quel tableau de bord en aval, et elles reflètent le fonctionnement réel du produit.

Cela importe parce que beaucoup de questions BI précoces sont relationnelles. Un fondateur ne veut pas seulement des pages vues ou des décomptes d'exécutions. Il veut relier les comportements à travers le système :

Parmi les utilisateurs inscrits depuis ce canal, combien ont exécuté quelque chose au jour zéro, et combien sont revenus après leur première exécution ?

Ou :

Quelles organisations payantes n'ont rien exécuté au cours des 7 derniers jours, et semblaient-elles actives auparavant ?

Ou :

Combien de calcul les nouveaux comptes d'essai ont-ils consommé durant leurs 6 premières heures, avant et après que nous ayons modifié notre patrouille anti-abus ?

Ces questions trouvent naturellement leur place dans la base de données du produit. Elles deviennent bien plus difficiles lorsque chaque réponse commence par le déplacement des données vers une plateforme distincte.

Le raccourci dangereux : l'accès brut à la production

Le raccourci tentant est évident : il suffit de laisser l'agent interroger la production.

Ce n'est pas acceptable.

Une base de données de production peut contenir les éléments les plus sensibles de l'entreprise : adresses e-mail, prompts, contenu de conversations, identifiants, état chiffré des fournisseurs, journaux, messages d'erreur, clés API et registres opérationnels internes. Même si un agent est prudent, l'accès brut crée un problème de frontière. L'agent peut voir trop de choses. Une erreur dans une requête, un rapport ou une capture d'écran peut divulguer des informations que l'équipe n'avait jamais eu l'intention d'exposer.

L'accès en écriture est encore pire. La BI ne devrait pas pouvoir modifier la production. Un analyste, humain ou agentique, ne devrait pas être à une mauvaise commande de modifier les données des utilisateurs.

La question n'est donc pas de savoir si les agents peuvent écrire du SQL. Ils le peuvent. La question est de savoir si vous pouvez leur donner assez de vérité pour être utiles tout en gardant la confidentialité et la sécurité comme contraintes strictes.

Pour nous, ces contraintes sont l'essentiel :

• Les agents ne doivent pas voir les prompts bruts.
• Les agents ne doivent pas voir les e-mails bruts.
• Les agents ne doivent pas voir les identifiants ou les secrets.
• Les agents ne doivent pas voir les journaux sensibles en texte libre.
• Les agents ne doivent pas avoir d'accès en écriture à la source BI.
• L'équipe fondatrice doit tout de même pouvoir poser rapidement des questions opérationnelles concrètes.

Voilà la forme du système dont nous avions besoin.

Le juste milieu sûr : une base de données masquée, en lecture seule

Neon rend possible un modèle utile, car les branches sont des copies bon marché et isolées d'une base de données Postgres. Vous pouvez créer une branche semblable à la production, la transformer et exposer cette branche plutôt que la production elle-même.

Chez VM0, nous utilisons cela pour créer ce que nous appelons MaskDB.

Le flux est simple :

1. Partir de la branche parente Neon de production.
2. Créer une nouvelle branche de manière planifiée.
3. Installer PostgreSQL Anonymizer et des assistants de masquage spécifiques à VM0.
4. Appliquer des étiquettes de sécurité aux colonnes sensibles.
5. Exécuter l'anonymisation statique sur la branche.
6. Appliquer les masques personnalisés finaux pour les champs nécessitant un traitement particulier.
7. Créer un rôle masked_readonly avec un accès SELECT.
8. Laisser les agents interroger ce rôle, et non la production.

Le détail important est que le masquage est statique. Les valeurs sensibles sont réécrites sur la branche masquée avant que l'agent ne se connecte. C'est différent de demander à chaque requête en aval de se souvenir de ce qu'il ne faut pas sélectionner. La branche elle-même est la frontière.

Dans notre MaskDB, les identifiants et les secrets sont caviardés. Les e-mails et numéros de téléphone sont partiellement masqués. Le contenu utilisateur tel que les prompts, les messages de chat, les prompts planifiés et les sorties d'agents est supprimé. Le texte d'erreur est réduit à une classe plutôt qu'à une pile d'appels ou un message complet. Les tables qui ne devraient jamais apparaître dans l'analyse peuvent être entièrement supprimées.

En même temps, les identifiants opaques comme org_id, user_id et clerk_user_id restent jointurables. C'est ce qui rend la BI possible. Nous n'avons pas besoin que l'agent connaisse l'adresse e-mail d'une personne ou le texte de son prompt. Nous avons besoin qu'il sache que la même organisation s'est inscrite, a exécuté une tâche, consommé des crédits, souscrit un abonnement, est devenue inactive ou est revenue plus tard.

Cet équilibre est tout l'enjeu : masquer les éléments lisibles par l'humain et sensibles, préserver la colonne vertébrale relationnelle.

Ce que les agents peuvent faire une fois la frontière en place

Une fois la base de données masquée en lecture seule en place, l'agent peut devenir utile très rapidement.

Il peut poser des questions directement sur les données du produit :

• Rétention des utilisateurs à 7 et 30 jours
• Activation de l'inscription à la première exécution
• Rétention ancrée sur la première exécution
• Dormance des organisations payantes
• État des abonnements et surveillance du churn
• Usage des modèles par modèle sélectionné
• Routes intégrées (built-in) vs routes fournisseur utilisateur
• Consommation de calcul en période d'essai
• Coût par exécution par modèle
• Taux d'échec et taux d'achèvement par cohorte

Il peut aussi combiner cette vérité de la base de données avec les systèmes qui l'entourent.

Notre Morning Brief s'alimente auprès de Plausible, Axiom, Sentry, Google Ads, GitHub et d'autres sources opérationnelles. La base de données nous dit ce que les utilisateurs et les organisations ont fait. Plausible nous dit ce qui s'est passé sur le site. PostHog peut aider avec le contexte des événements produit. Axiom nous dit ce qui s'est passé dans les journaux et les chemins de requêtes. Sentry capture les erreurs. Stripe et Clerk aident à expliquer la facturation et l'identité. GitHub montre la cadence d'ingénierie.

L'objectif n'est pas de remplacer chaque outil par du SQL. L'objectif est de laisser l'agent connecter les faits qui comptent vraiment pour les fondateurs.

Par exemple :

Hier, le canal Google payant a envoyé plus de trafic que l'organique. Ces utilisateurs ont-ils réellement atteint la première exécution, ou se sont-ils arrêtés en haut de l'entonnoir ?

Ou :

Nous avons modifié la patrouille anti-abus en période d'essai. Les nouveaux comptes d'essai ont-ils consommé moins de calcul durant leurs premières heures ?

Ou :

Cette route de modèle est moins chère par exécution. Cela se vérifie-t-il dans l'usage réel et historique des conversations, ou seulement en théorie tarifaire ?

Ce ne sont pas des questions de tableau de bord. Ce sont des questions opérationnelles. Elles changent de semaine en semaine, parfois de jour en jour. Un agent disposant d'un accès sûr à la base de données peut y répondre sans demander à l'ingénierie de construire une nouvelle vue à chaque fois.

Un exemple réel : rétention et santé des utilisateurs externes

L'une de nos analyses internes quotidiennes examine la santé des utilisateurs externes sur les 24 dernières heures.

Le rapport part de MaskDB, puis applique un ensemble d'exclusions strict. Les organisations internes VM0 sont retirées. Les organisations spam bannies ou verrouillées dans Clerk sont retirées. Ce même ensemble d'exclusions est appliqué partout, y compris pour les décomptes d'inscriptions et les cohortes de rétention, afin que les dénominateurs restent auditables.

À partir de là, l'agent peut produire un rapport opérationnel compact :

• Exécutions et organisations externes actives
• Taux d'achèvement
• Répartition des déclencheurs entre web, CLI, planifications et routes non-Zero
• Répartition des modèles
• Mode fournisseur
• Activité des organisations payantes
• Organisations payantes dormantes
• Nouvelles inscriptions payantes et organisations en essai
• Surveillance du churn
• Segmentation des utilisateurs sur 30 jours
• Rétention de l'inscription à l'exécution
• Rétention de la première exécution

C'est exactement le type de rapport dont une équipe fondatrice a besoin. Il ne nécessite pas de prompts bruts. Il ne nécessite pas d'e-mails bruts. Il ne nécessite pas d'accès en écriture à la production.

Il nécessite en revanche la capacité de joindre correctement les faits du produit.

Lors d'une exécution, l'agent a constaté qu'un petit nombre d'organisations externes actives générait l'essentiel du volume, que plusieurs organisations payantes étaient devenues silencieuses, et que les cohortes d'inscription récentes présentaient une falaise d'activation brutale, probablement causée par des inscriptions spam gonflant le dénominateur. Ce sont le genre de choses qu'un fondateur devrait voir rapidement, et non découvrir des semaines plus tard lors d'une revue de tableau de bord.

Un deuxième exemple : l'économie de l'abus en période d'essai

Les données produit masquées sont également utiles pour des questions qui ne sont pas des graphiques BI classiques.

Lorsque nous avons examiné l'abus en période d'essai, la métrique utile n'était pas le calcul total dépensé. La dépense totale serait biaisée en faveur des comptes plus anciens, car ils ont eu plus de temps pour consommer des crédits. La meilleure question était :

Combien de calcul d'essai un nouveau compte consomme-t-il durant ses premières heures après l'inscription ?

À l'aide de MaskDB, l'agent a mesuré la consommation de calcul dans des fenêtres comparables après l'inscription. Il a utilisé la consommation de crédits provenant des événements d'usage, les horodatages d'inscription issus des métadonnées d'organisation, et l'état d'abonnement pour séparer l'économie de l'essai de l'usage payant.

Après la mise en service de la patrouille, le calcul d'essai moyen consommé dans les premières heures suivant l'inscription a chuté de plus de 80 %. La traîne des fortes consommations a presque disparu. Au 90e centile, le calcul d'essai des premières heures est passé d'environ 4,05 $ à environ 0,26 $, une baisse de 94 %.

Ce chiffre n'est pas qu'un point analytique. Il modifie la vision opérationnelle de l'entreprise. Il indique à l'équipe fondatrice que l'abus était non seulement détecté, mais que l'économie unitaire de l'essai évoluait dans la bonne direction.

Et cela a été possible parce que la base de données détenait la vérité, tandis que la branche masquée rendait sûr pour un agent l'analyse de cette vérité.

Un troisième exemple : le coût des modèles dans le produit réel

Les pages de tarification et les fiches de benchmark sont utiles, mais elles ne répondent pas à la question qui intéresse vraiment les fondateurs :

Combien coûte ce modèle dans notre produit réel, sur des exécutions réelles ?

À l'aide de MaskDB, l'agent a comparé les exécutions de chat historiques en joignant les enregistrements d'exécution au modèle sélectionné au moment de l'exécution et en agrégeant les crédits facturés à partir des événements d'usage.

Cette distinction compte. Vous ne devez pas attribuer les exécutions historiques en fonction du fournisseur de modèle par défaut actuel de l'utilisateur, car les valeurs par défaut changent. Le modèle sélectionné au moment de l'exécution est la source de vérité.

Dans notre analyse, DS v4 Pro affichait un coût médian en crédits-modèle par exécution de chat d'environ 49 % de celui de Sonnet. Autrement dit, l'exécution de chat médiane réelle était environ 51 % moins chère sur cette route.

Là encore, c'est de la BI au niveau du fondateur. Elle relie le comportement produit, le coût d'infrastructure et la stratégie de modèles. Elle ne nécessite pas un nouvel entrepôt. Elle nécessite un accès sûr aux bonnes données relationnelles.

Ce n'est pas un remplacement définitif d'un entrepôt

Il arrive un moment où une entreprise a besoin d'une stack de données plus formelle.

Lorsque les métriques nécessitent une gouvernance sémantique forte, lorsque de nombreuses équipes dépendent des mêmes définitions, lorsque les rétro-remplissages historiques deviennent complexes, lorsque les tableaux de bord font partie du système d'exploitation, un entrepôt ou un lakehouse peut être la bonne réponse.

Mais beaucoup de startups optent pour cette réponse trop tôt.

Si vous êtes une petite équipe fondatrice, votre premier système BI devrait vous aider à répondre aux questions, et non créer un second produit à maintenir. Une base de données masquée peut servir de pont. Il ne s'agit pas de prétendre que la modélisation des données n'a pas d'importance. Il s'agit de reconnaître que la base de données du produit contient déjà les relations dont vous avez besoin pour la prochaine série de décisions.

L'agent ne supprime pas le besoin de jugement. Il rend simplement la première version de l'analyse moins coûteuse à réaliser.

Le modèle pour les équipes fondatrices

Le modèle est simple :

1. Traiter la base de données du produit comme la première source de vérité.
2. Ne jamais exposer la production brute aux agents.
3. Utiliser une branche semblable à la production, et non un jeu de données échantillon construit à la main.
4. Masquer statiquement les colonnes sensibles avant l'accès.
5. Préserver les identifiants de jointure opaques afin que l'analyse fonctionne toujours.
6. Exposer la branche via un rôle en lecture seule.
7. Laisser les agents exécuter la boucle d'analyste sur la base masquée et les outils environnants.

Cela offre à une équipe fondatrice un système d'exploitation utile sans avoir à construire d'abord une plateforme de données complète.

Cela crée aussi une posture de sécurité plus propre. L'agent dispose d'une frontière stricte. La base de données qu'il voit a déjà été transformée. Le rôle qu'il utilise ne peut pas écrire. Les rapports qu'il produit peuvent être limités à des identifiants hachés ou agrégés.

C'est l'équilibre que nous voulions chez VM0 : la confidentialité et la sécurité comme socle, et non comme compromis, tout en donnant à l'équipe fondatrice un moyen bien plus rapide de comprendre l'entreprise.

Avant de construire un data lake, demandez-vous si une branche masquée, en lecture seule, de votre base de données produit peut répondre aux 20 prochaines questions que votre équipe se pose réellement.

Pour nous, ce fut le chemin le plus rapide vers la BI.

Sources

• Neon, « Create Environments with Masked Production Data Using Neon Branches » : https://neon.com/blog/environments-masked-production-data
• Fork Neon de PostgreSQL Anonymizer : https://github.com/neondatabase/postgresql_anonymizer