Ton MVP peut être lean. Ton modèle de données, non.

Introduction

Dans l'univers startup et produit, une image revient sans cesse : avant de construire une Ferrari, construis d'abord une skateboard. Valide que les gens veulent se déplacer avant d'investir dans un moteur V8.

C'est la base du Lean. Et c'est une approche qu'on applique au quotidien chez Leando, cabinet de conseil en innovation, à travers notre méthodologie : faire le minimum pour créer le maximum de valeur.

Mais après plusieurs années à concevoir, reprendre et auditer des applications pour nos clients, j'ai identifié une composante qui ne supporte pas cette logique itérative : le modèle de données.

Et c'est précisément là que beaucoup de projets perdent du temps, de l'argent, et de la confiance.

La métaphore : skateboard, trottinette, moto, Ferrari

Imaginons que tu construis un produit. L'approche lean, c'est :

• V1 - La skateboard : un formulaire, une base simple, une feature core. Tu valides le besoin.
• V2 - La trottinette : tu ajoutes des fonctionnalités, un dashboard, quelques intégrations.
• V3 - La moto : tu structures une vraie plateforme, des rôles, de l'automatisation.
• V4 - La Ferrari : le produit complet, scalable, avec tout l'écosystème.

Cette progression est saine pour les features, l'UI, l'infrastructure. Tu n'as pas besoin de Kubernetes pour 50 utilisateurs.

Mais le modèle de données, lui, c'est le squelette du véhicule.

Si tu conçois un squelette de skateboard, tu ne pourras jamais y greffer un moteur de Ferrari sans tout démonter. En revanche, si tu conçois un squelette de Ferrari dès le départ, rien ne t'empêche de n'y monter que quatre roues et une planche pour commencer.

C'est là toute la nuance : concevoir le modèle pour la cible, implémenter les features pour l'étape actuelle.

Pourquoi le modèle de données est différent

Quand tu changes l'UI de ton app, personne ne le sent en base de données. Quand tu migres de React à Next.js, ta base ne bouge pas. Quand tu ajoutes un bouton, c'est du front.

Mais quand tu dois :

• transformer un champ role: string en une table roles avec des permissions granulaires,
• éclater une table event monolithique en event, session, ticket, participant,
• passer d'une relation 1-to-1 à du many-to-many parce que le besoin a évolué,

…là, tu touches au squelette. Et ça fait mal.

Le vrai coût, ce n'est pas la migration elle-même. C'est tout ce qui va avec :

• Les régressions dans le code qui dépend de l'ancien modèle
• La réécriture des requêtes, des API, parfois de pans entiers du back-end
• La migration des données existantes (et la gestion des cas limites)
• Le temps de test pour s'assurer que rien n'est cassé
• La perte de vélocité de l'équipe pendant des semaines

Pour un champ qu'on aurait pu anticiper dès le jour 1.

Cas concret : historiser ou pas ?

Récemment, dans la conception d'un modèle de données avec un de nos clients, on a fait face à un dilemme classique.

Le contexte : on modélise tout le parcours d'un contrat - de l'offre commerciale jusqu'à la signature. La question qui se pose :

Est-ce qu'on met en place l'historisation des données dès maintenant, ou est-ce qu'on attend d'en avoir besoin ?

Concrètement, historiser, qu'est-ce que ça veut dire dans un modèle de données ? C'est relativement simple : ajouter des champs de dates (created_at, updated_at, deleted_at), mettre en place des soft deletes pour ne jamais perdre une donnée, et s'assurer que chaque version d'un enregistrement est conservée plutôt qu'écrasée.

L'argument "skateboard" disait : "On n'a pas besoin de stats aujourd'hui, on n'a pas de crawlers qui vont exploiter cet historique, on verra dans 6 mois."

L'argument "Ferrari" disait : "L'historisation, c'est quelques champs et une convention de soft delete. Ça ne coûte presque rien à mettre en place maintenant. Mais si on attend, on paie deux fois."

On a tranché en faveur de l'historisation dès le jour 1. Et voici pourquoi :

1. Le coût de l'ajout est quasi nul aujourd'hui, mais explose demain. Ajouter un deleted_at et un mécanisme de versioning sur une table vide, c'est une affaire de minutes. Le faire sur une table en production avec des milliers d'enregistrements déjà écrasés les uns sur les autres ? C'est une migration, du développement, des tests de non-régression - et des données historiques perdues à jamais.

2. La donnée qu'on n'a pas conservée est irréversiblement perdue. C'est la vraie asymétrie. Si tu historises et que tu n'exploites pas les données pendant 6 mois, tu n'as rien perdu. Mais si tu n'historises pas et qu'au bout de 6 mois tu veux faire des stats, analyser l'évolution des contrats, comprendre les taux de conversion par étape… tu n'as plus rien. Les anciennes valeurs ont été écrasées. Aucune migration ne peut recréer ce qui n'a jamais été enregistré.

C'est exactement ça, "penser Ferrari en données" : identifier les décisions qui coûtent presque rien aujourd'hui mais qui seraient douloureuses - voire impossibles - à rattraper plus tard. L'historisation en est l'exemple parfait.

Le framework : penser Ferrari, construire skateboard

Concrètement, comment on fait chez Leando ? Voici notre approche en 4 étapes :

1. Cartographier la vision produit complète

Avant de toucher à une base de données, on liste toutes les fonctionnalités de la cible finale - pas juste du MVP. On ne va pas les construire, mais on doit les connaître.

2. Identifier les entités et leurs relations

À partir de cette vision, on dessine le modèle de données complet : toutes les tables, toutes les relations, toutes les cardinalités. C'est un exercice de modélisation, pas de développement.

3. Implémenter le squelette, pas la chair

On crée les tables et les relations dès le départ, même si elles restent vides. Une table permissions sans données, ça ne coûte rien. Mais le jour où on en a besoin, la structure est là.

4. Marquer les "points d'extension"

Dans notre documentation, on identifie explicitement les endroits où le modèle est prêt à accueillir de nouvelles features. Ça permet à n'importe quel développeur de comprendre l'intention derrière la structure.

Conclusion

Le lean, c'est puissant. L'itération, c'est indispensable. Mais toutes les composantes d'un produit ne se valent pas face à l'itération.

Le front-end, tu peux le refaire. L'infra, tu peux la migrer. Les features, tu peux les ajouter et les retirer.

Le modèle de données, si tu le construis pour une skateboard, tu paieras le prix de chaque évolution en dette technique, en retard, et en frustration.

Construis ton skateboard en features. Pense ta Ferrari en données.

C'est ce petit investissement en conception initiale qui fait la différence entre un produit qui grandit et un produit qu'on reconstruit tous les 6 mois.

On aide les startups et les grands groupes à construire des produits numériques qui tiennent la route - méthodologiquement et techniquement.