Modèle de données : le choix le plus cher

Un fondateur peut déléguer la construction de sa base de données. Il ne peut pas déléguer les règles métier qu'elle doit protéger. Quand une mauvaise hypothèse se retrouve dans chaque client, chaque facture et chaque historique, la corriger ne consiste plus à modifier quelques lignes de code. Il faut reprendre les données déjà produites sans casser le produit. C'est ce qui fait du modèle de données l'un des choix les plus chers d'un MVP.

J'ai vu des fondateurs arriver à 500 utilisateurs avant de découvrir que leur modèle ne pouvait pas accompagner la suite. L'équipe n'a pas perdu une journée à changer un écran. Elle a arrêté le développement pendant deux mois pour reprendre la structure des données. Pendant ce temps, la roadmap n'avançait plus et les demandes clients continuaient d'arriver. Voilà le coût réel d'une décision qui paraissait invisible au lancement.

Votre base enregistre les règles de l'entreprise

Une base de données ne conserve pas seulement des noms, des dates et des montants. Elle enregistre ce que le produit considère comme vrai. Un utilisateur appartient-il à une seule entreprise ou peut-il travailler pour plusieurs ? Une facture validée peut-elle encore changer ? Une commission existe-t-elle avant le paiement du client ? Ces questions sont métier avant d'être techniques.

Dans Designing Data-Intensive Applications, Martin Kleppmann et Chris Riccomini expliquent que la manière de représenter les données influence aussi notre manière de penser le problème. Leur chapitre sur les modèles de données rappelle une idée essentielle : avant de choisir un outil, il faut traduire correctement le monde réel que le logiciel doit représenter.

Prenez un SaaS qui rattache chaque utilisateur directement à une entreprise. Le choix paraît raisonnable tant que chaque personne n'a qu'un seul compte. Le jour où un cabinet doit gérer cinq filiales, le produit ne peut pas se contenter d'un bouton supplémentaire. Il faut revoir les invitations, les droits d'accès, la facturation et tous les écrans construits sur l'hypothèse initiale.

Le modèle de données fixe donc les frontières du produit. Il décide ce qui appartient à qui, ce qui peut changer et ce qui doit rester vrai. Le développeur peut proposer une façon de l'implémenter. Le fondateur reste responsable des règles, car elles viennent du modèle commercial, des contrats et des usages promis aux clients.

Le sujet devient critique pour l'argent, les accès et les engagements. Si le produit accepte deux factures avec la même référence, oublie qui a autorisé un remboursement ou mélange les données de deux clients, ce n'est plus un détail d'architecture. C'est une erreur que l'entreprise devra expliquer.

Une mauvaise hypothèse facture chaque feature

Un raccourci dans l'interface se corrige souvent sur un écran. Un raccourci dans le modèle s'applique à toutes les données déjà créées. Plus le produit fonctionne, plus l'ancienne hypothèse s'enracine.

Imaginez un paiement enregistré uniquement comme « payé » ou « non payé ». Cela suffit jusqu'au premier acompte, au premier remboursement partiel ou au premier impayé régularisé. Pour ajouter ces cas, l'équipe doit comprendre ce que signifient les anciennes données, modifier les factures, corriger les tableaux de bord et sécuriser les exports comptables. Une fonctionnalité estimée à trois jours peut en prendre quinze parce qu'elle réveille une décision vieille de six mois.

Le problème inverse existe aussi : une même information peut être copiée à plusieurs endroits. Conserver l'adresse d'un client sur une facture est utile, car la facture doit garder l'adresse valable au moment de son émission. Copier son offre actuelle dans cinq parties du produit crée en revanche plusieurs versions de la vérité. Une mise à jour échoue, puis le support, la facturation et le client ne voient plus la même chose.

J'ai rencontré cette difficulté sur RefCampaign. Le produit conservait bien le résultat des commissions, paiements et remboursements, mais pas toujours l'origine de la modification. Quand une opération paraissait incohérente, je voyais son état final sans savoir si elle venait d'un utilisateur, d'une intégration ou d'un traitement automatique. L'enquête prenait des heures et certaines informations passées étaient impossibles à reconstituer. Le vrai manque n'était pas un outil de débogage. C'était une donnée métier qui n'avait jamais été enregistrée.

C'est la leçon la plus coûteuse : le code peut être réécrit, mais une information absente de l'historique ne réapparaît pas par magie. On peut parfois l'estimer à partir d'autres traces. On ne peut plus la garantir.

Le prix d'un mauvais modèle ne se lit donc pas seulement sur une facture technique. Il se voit dans une roadmap ralentie, des chiffres auxquels personne ne fait confiance, des opérations manuelles et des clients que l'équipe hésite à servir. Chaque nouvelle fonctionnalité paie une partie de la dette.

Les décisions à prendre avant de coder

Un MVP n'a pas besoin de prévoir les dix prochaines années. Chercher à représenter tous les cas possibles produirait un système lourd avant même d'avoir appris du marché. L'objectif est plus modeste : sécuriser les règles dont la violation ferait réellement mal.

Commencez par la propriété. Pour chaque donnée importante, demandez qui en est responsable et qui peut la consulter. Un projet appartient-il à une personne ou à une entreprise ? Que devient-il si son créateur part ? Un consultant peut-il intervenir auprès de plusieurs clients avec le même compte ? Ces réponses déterminent les futurs droits d'accès.

Demandez ensuite ce qui peut changer. Un nom de profil se remplace facilement. Une facture validée, un tarif accepté ou une autorisation sensible demande souvent de conserver l'ancienne valeur. Sans cette distinction, une simple mise à jour peut réécrire le passé et rendre un export impossible à justifier.

L'histoire à conserver dépend du risque. Pour une préférence d'affichage, connaître l'état actuel suffit. Pour un paiement ou un changement de permission, il faut souvent savoir ce qui s'est passé, quand et à l'initiative de qui. Ce niveau de traçabilité n'est pas un luxe réservé aux grands groupes. Il devient vite indispensable dès qu'un client conteste un montant ou un accès.

Enfin, testez le modèle avec des situations inconfortables. Que se passe-t-il si un client change d'offre au milieu du mois ? Si un remboursement intervient après le versement d'une commission ? Si une personne quitte une entreprise tout en restant membre d'une autre ? Une réponse floue signale une règle encore floue. Elle mérite une décision avant que plusieurs écrans ne l'interprètent chacun à leur façon.

Ces conversations peuvent tenir sur une page. Le but n'est pas de dessiner toute la base avec le fondateur. Il est d'écrire les règles importantes dans un langage que le métier et l'équipe technique comprennent de la même manière.

Faut-il corriger votre modèle maintenant ?

Une migration devient prioritaire quand le modèle crée un risque financier, fragilise les accès ou bloque plusieurs éléments de la roadmap. Si trois fonctionnalités différentes contournent déjà la même limite, attendre ne simplifie pas le problème. L'entreprise accumule seulement plus de données à reprendre.

À l'inverse, une gêne isolée ne justifie pas toujours une intervention immédiate. Si elle concerne peu de données, n'affecte aucun engagement client et dépend d'une hypothèse produit encore incertaine, documentez-la. Fixez un signal de réévaluation, par exemple l'arrivée d'un second type de client ou d'un nouveau mode de facturation. Un modèle parfait n'est pas l'objectif.

La bonne question n'est donc pas « notre base est-elle propre ? », mais « quel coût allons-nous payer si nous repoussons cette correction de six mois ? ». Comparez le coût estimé aujourd'hui avec les fonctionnalités ralenties, les manipulations manuelles et le risque de produire une donnée fausse. Cette comparaison rend la décision accessible sans demander au fondateur de lire le code.

Corriger ne signifie pas forcément arrêter le SaaS. L'équipe peut ajouter la nouvelle représentation, faire fonctionner l'ancienne et la nouvelle pendant une période, puis reprendre progressivement les données historiques. Elle retire l'ancien fonctionnement une fois les contrôles terminés. La technique exacte appartient aux développeurs ; le métier doit décider comment interpréter l'historique incomplet et quelles approximations sont acceptables.

Changer le modèle n'impose pas non plus de réécrire toute l'application. Une zone métier peut évoluer seule si ses dépendances sont connues. Le danger vient surtout d'une bascule massive, sans période de coexistence ni vérification des résultats.

Lundi matin, demandez à l'équipe quelles sont les trois règles de données qui coûteraient le plus cher si elles étaient fausses. Pour chacune, vérifiez qui en est propriétaire, ce qui peut changer et quelle histoire doit être conservée. Si les réponses divergent, vous avez trouvé le prochain sujet à clarifier.

Ce qu'il faut retenir

Le modèle de données traduit les règles que votre SaaS promet de respecter. Un fondateur n'a pas à choisir les détails de la base, mais il doit valider la propriété, les accès, l'argent et l'historique. Ce sont des décisions de produit et d'entreprise.

Le coût augmente avec chaque donnée créée sur une mauvaise hypothèse. Une correction devient urgente lorsqu'elle bloque plusieurs fonctionnalités, menace la facturation ou fragilise les droits d'accès. Elle peut souvent être menée progressivement, sans arrêter le produit. Le risque le plus difficile à réparer reste l'information que personne n'a pensé à conserver.

Questions fréquentes

Comment évaluer un modèle de données sans être technique ?

Demandez une explication des règles, pas un dessin de la base. Qui possède chaque information importante ? Laquelle peut changer ? Quel historique faut-il garder ? Testez ensuite les réponses avec trois situations réelles, comme un remboursement, un changement de propriétaire ou un départ d'entreprise. Si l'équipe ne donne pas la même réponse, le modèle mérite d'être clarifié.

Est-il trop tard après le lancement du MVP ?

Non. Un modèle peut évoluer pendant que le produit fonctionne, à condition de procéder par étapes et de contrôler les données reprises. Plus vous attendez, plus le volume et le nombre de fonctionnalités concernées augmentent. Il faut donc arbitrer selon le risque métier, pas selon une recherche de perfection technique.

Qui doit valider les règles du modèle ?

Le fondateur ou le responsable métier valide le sens des règles. L'équipe technique vérifie qu'elles peuvent être appliquées et que le changement reste sûr. Quand ces compétences ne sont pas réunies en interne, un CTO part-time peut traduire les contraintes métier en décisions techniques avant qu'elles ne bloquent la roadmap.

Conclusion

Si votre modèle de données ralentit déjà la roadmap ou rend vos chiffres difficiles à défendre, réservez un échange de 30 minutes pour identifier les règles à sécuriser avant d'engager une refonte.