Le piège du “on verra plus tard”
Quand on lance un MVP B2B, la pression sur le time-to-market est telle qu’on coupe partout où on peut. Et le premier sacrifié, neuf fois sur dix, c’est le data layer.
L’argument est toujours le même : « On n’a pas encore d’utilisateurs, on verra ça quand on aura du volume. »
Six mois plus tard, le PMF commence à émerger, vous avez 30 clients, et vous réalisez que :
- Vous ne savez pas vraiment quel feature est utilisé par qui
- Vous n’avez aucune idée du temps entre signup et première valeur
- Vous découvrez que 60% de votre activité vient de 3 clients que vous ne soupçonniez pas
- Vous avez deux dashboards qui contredisent un troisième
À ce moment-là, vous ne pouvez plus reconstruire l’historique. Vos décisions des 6 prochains mois se prennent sur de l’intuition.
Ce que veut dire “data layer” concrètement
Ce n’est pas un produit qu’on achète. C’est une architecture qui repose sur trois choses :
1. Un tracking événementiel structuré. Chaque action significative dans le produit émet un événement nommé (user.signup, checkout.completed, feature.used, trial.started), avec des propriétés typées (user_id, plan, value, timestamp, source).
2. Un entrepôt qui collecte ces événements. BigQuery, Snowflake, ou pour démarrer plus light : ClickHouse ou Postgres avec une partition events. Peu importe, tant que c’est requêtable en SQL.
3. Des transformations versionnées. Les événements bruts, c’est du flux. Les insights, c’est du calculé. La logique de calcul (qu’est-ce qu’un “active user”, c’est quoi un “churn”, c’est quoi le “MRR”) doit vivre dans du code versionné (dbt, SQL files dans Git), pas dans un dashboard cliqué à la souris.
Ces trois pièces ensemble, c’est ton data layer. Sans cette base, toutes les analyses sont reconstruites à la main à chaque fois, avec un risque d’erreur à chaque exécution.
Pourquoi J1 et pas J90
Quatre raisons techniques très concrètes :
A. Les événements ne se rétroactivent pas. Si tu n’as pas tracké checkout.completed les 6 premiers mois, tu ne peux pas reconstruire le funnel a posteriori. La donnée n’existe pas. Tu auras des trous noirs dans ton historique pour toujours.
B. Le schéma s’arrête une fois figé. Si tu poses ton premier event sans le typer correctement (value: "10.50" au lieu de value: 10.50), tu vas le payer en cleanup pendant deux ans. Mieux vaut une heure de réflexion sur la structure de l’event au début que 40h de chirurgie SQL plus tard.
C. Tes premiers utilisateurs sont les plus précieux. Ce sont ceux qui te disent où est ton vrai PMF. Si tu ne traces pas ce qu’ils font, tu rates le signal le plus important de ton année.
D. Les premières décisions stratégiques se prennent à 5 utilisateurs. Pivot, pricing, segmentation, première embauche commerciale. Toutes ces décisions ont besoin d’au moins quelques signaux quantitatifs, sinon elles se prennent à l’intuition (ce qui est OK, mais pas idéal).
Le minimum viable, pour démarrer
Tu n’as pas besoin de Snowflake et dbt et Segment et Looker dès le premier jour. Voici la stack que je conseille à mes clients startups en early stage :
Tracking : la lib posthog-js (ou Rudderstack, ou Segment si tu as du budget). Free tier 1M events / mois, largement suffisant.
Warehouse : pour démarrer, garde tout dans Postgres avec une table events partitionnée par mois. Quand tu passes le million d’events / mois, tu migres vers ClickHouse ou BigQuery (1 semaine de travail à ce moment-là, pas grave).
Transformations : commence avec des views SQL dans Postgres, ou dbt-core (gratuit, OSS). Chaque metric importante (MRR, active users, churn) est définie une seule fois, dans un fichier .sql versionné dans ton repo.
Visualisation : Metabase (OSS, free) ou Posthog directement. Pas besoin de Looker à 50K€/an avant d’avoir 100 employés.
Coût total de cette stack pour un startup qui débute : 0 €/mois en infra, juste le temps de mise en place (typiquement 1 semaine de dev en J0).
La liste des 10 events à tracker absolument dès le départ
Pour un SaaS B2B classique, voici le squelette minimum :
user.signup(avec : source, plan, company_size)user.activated(premier moment de valeur, à toi de définir)trial.startedtrial.upgradedoutrial.expiredsubscription.created(avec : plan, mrr_eur)subscription.upgraded/downgraded/canceledfeature.used(avec : feature_name, frequency)payment.succeeded/payment.failedsupport.ticket_openedreferral.invited/referral.accepted
Avec ces 10 events, tu peux construire 90% de tes dashboards founder (acquisition, activation, rétention, revenue, referral). Plus tu attends pour les poser, plus tu paies cher de les rattraper.
Sécurité et RGPD : pas une excuse pour reporter
L’autre raison qu’on entend pour ne pas faire de data layer dès J1, c’est : « On verra le RGPD quand on aura plus de clients. »
C’est faux dans les deux sens. D’abord parce que le RGPD s’applique dès le premier utilisateur. Ensuite parce que c’est mille fois plus simple à mettre en place sur 100 events bien structurés que sur 6 mois de tracking improvisé.
Concrètement : tu poses un consent banner, tu hashes le user_id côté tracker, tu mets en place un endpoint de purge sur demande, et tu documentes ton registre de traitement. C’est 2 jours de travail au démarrage.
La bonne nouvelle
Tout ce que je viens de décrire — tracking, warehouse, transformations versionnées, RGPD — est ce qu’on installe systématiquement chez nos clients startups B2B, dès la première semaine du MVP. C’est inclus dans le forfait Build. Tu n’as pas à choisir entre time-to-market et infrastructure : on fait les deux en parallèle.
Si tu veux en discuter sur ton cas précis, prends 30 minutes ou fais notre diagnostic gratuit pour voir où tu en es aujourd’hui.