Construire un pipeline analytics en startup : ELT, pas ETL

Si je pouvais revenir au premier mois de construction d'analytics produit en startup, je changerais exactement une décision : arrêter de transformer les données avant de les stocker. On a commencé avec l'approche ETL classique. Il a fallu trois pivots douloureux pour comprendre pourquoi c'était une erreur.

Produit fictif. Patterns d'ingénierie réels.

Ce qu'on a raté au départ

Sur PulseBoard — une plateforme de Customer Success — le besoin initial semblait clair : mesurer l'engagement client. Mais "engagement" est un mot-valise. Est-ce les pages vues ? Le temps passé ? Les téléchargements de contenu ? La fréquence de connexion ? L'adoption de fonctionnalités ? La réponse changeait chaque semaine à mesure que l'équipe CS découvrait comment les clients utilisaient réellement le produit.

Avec un pipeline ETL classique, chaque changement de définition aurait nécessité de modifier le code de transformation, redéployer, et parfois rejouer les données historiques. En early-stage, ce cycle est trop lent. On l'a appris à nos dépens quand l'équipe CS nous a demandé de pondérer rétroactivement le "temps passé sur les docs d'onboarding" différemment — et que notre pipeline ne pouvait pas recalculer trois mois d'historique sans une réécriture complète de la logique d'ingestion.

Avec le recul, l'erreur était de traiter l'analytics comme une feature à livrer. Ce n'en est pas une. C'est une infrastructure d'apprentissage, et elle doit être aussi flexible que les questions qui la guident. Si quelqu'un me l'avait dit avant qu'on passe six semaines à construire un pipeline qu'on allait démonter, ça nous aurait épargné pas mal de frustration.

Ce qu'on a reconstruit — et pourquoi ça a survécu à chaque pivot

Le choix a été radicalement différent. Des trackers Snowplow intégrés dans React via des hooks personnalisés capturaient chaque interaction significative — ouvrir un document, regarder une vidéo, progresser dans une checklist d'onboarding, télécharger une ressource. Les événements atterrissaient dans Snowflake comme données brutes et immuables. Aucune transformation au passage. Plus de 500 000 événements par jour transitaient par ce pipeline, et pas un seul n'était modifié avant stockage.

Toute la logique métier vivait dans des modèles DBT versionnés. Événements bruts → sessions → métriques d'engagement par compte → scores de santé. Quand la définition de l'engagement changeait — et elle changeait souvent — on modifiait un modèle DBT, on rebuild, et les nouvelles métriques étaient calculées sur l'historique complet. Pas de redéploiement applicatif. Toute la chaîne de transformation, de l'événement brut à la métrique dashboard, était auditable dans Git.

C'est ce que j'appelle l'assurance contre sa propre ignorance. On ne savait pas, en construisant le pipeline, que le "taux de complétion de l'onboarding" deviendrait le prédicteur le plus fort de rétention. Mais parce qu'on avait stocké chaque interaction brute depuis le premier jour, on a pu construire cette métrique rétroactivement sans perdre un seul point de donnée.

Là où la vraie difficulté se cachait

CubeJS servait de couche sémantique au-dessus de Snowflake, exposant des mesures pré-agrégées que le frontend requêtait sans SQL. Les managers CS obtenaient des dashboards avec tendances d'engagement, comparaisons de comptes et analyses de cohortes — le tout alimenté par le même pipeline. L'architecture était propre. Le plus dur n'était pas technique.

Le score d'engagement condensait des dizaines de signaux en un seul indicateur de santé par compte. Pages vues, temps passé, téléchargements, fréquence de connexion, adoption de fonctionnalités — chacun pondéré selon sa corrélation avec la rétention. L'activité récente pesait plus que l'historique. La largeur d'usage — utiliser beaucoup de fonctionnalités légèrement — scorait différemment de la profondeur — utiliser une fonctionnalité intensément.

Le plus dur n'était pas les maths. C'était la calibration — l'écart entre ce que disent les données et ce que savent les gens expérimentés. Les premières versions du modèle de scoring produisaient des chiffres qui ne correspondaient pas à l'intuition CS sur les comptes sains. Un compte avec beaucoup de pages vues mais aucun téléchargement scorait "engagé" — mais l'équipe CS savait d'expérience que le browsing passif sans action était un signal de churn, pas d'engagement. Un autre compte se connectait à peine mais téléchargeait chaque ressource publiée — le modèle le scorait à risque, mais le CS savait que c'était un power user qui consommait le contenu hors-ligne.

Itérer signifiait ajuster les poids dans les modèles DBT, rebuilder la chaîne de transformation, et comparer les résultats aux outcomes de rétention connus. On est passés par sept itérations avant que le score s'aligne avec ce que l'équipe CS observait sur le terrain. L'approche code-based et versionnée rendait ce cycle d'itération rapide — typiquement quelques heures entre hypothèse et changement validé — et chaque ajustement était auditable. Avec le recul, cette boucle de calibration est là où la vraie valeur produit s'est construite — pas dans l'architecture du pipeline, mais dans la conversation entre données et expertise métier.

La latence pipeline : la contrainte dont personne ne nous avait prévenus

Des analytics qui arrivent trop tard sont inutiles pour du CS proactif. Si un score de santé chute mais que le dashboard ne le reflète que le lendemain, l'équipe CS ne peut pas intervenir avant que le client ne se désengage.

L'objectif de latence pipeline était sous 15 minutes, de la capture de l'événement à la disponibilité dans le dashboard. Les événements Snowplow atteignaient le collecteur en quasi-temps-réel. La fenêtre de chargement Snowflake était le goulot d'étranglement — on a affiné la fréquence des micro-batches pour équilibrer fraîcheur et coûts de compute. Les modèles DBT incrémentaux ne traitaient que les nouveaux événements à chaque exécution au lieu de recalculer l'historique complet, gardant le temps de transformation maîtrisé à mesure que le dataset grossissait.

Le résultat : un pipeline où un manager CS pouvait voir l'activité matinale d'un client reflétée dans son dashboard avant le déjeuner. Pas du temps réel, mais assez rapide pour la prise de décision humaine.

Ce que je me dirais au départ

En startup, vos données brutes sont votre actif le plus précieux. Stockez-les d'abord, posez les questions ensuite. L'ELT n'est pas juste un pattern technique — c'est une assurance contre votre propre ignorance de ce qui comptera demain. Le modèle d'engagement sur lequel on a atterri ne ressemblait en rien à celui qu'on avait planifié. Mais parce qu'on avait tout stocké et transformé dans du code versionné, chaque pivot n'était qu'un rebuild DBT, pas un projet d'ingénierie.

Le pipeline traitait plus de 500 000 événements par jour avec une latence bout-en-bout sous 15 minutes. Mais la métrique qui comptait le plus n'était pas le débit — c'était le nombre de fois où l'équipe CS a changé sa définition de l'engagement, et la vitesse à laquelle on a pu suivre.