Étude de cas database-first :les tables avant un écran

Dans cette étude de cas database-first, j'ai conçu la base de données avant de construire le moindre écran — et 18 mois plus tard, à 1 000 tables et toujours en développement, elle n'a jamais eu besoin d'être reconstruite. Pas une seule fois. Voici l'étude de cas : ce que ces premières semaines peu glorieuses ont coûté, et exactement ce qu'elles ont rapporté.

La méthode elle-même — pourquoi vos données doivent passer avant vos écrans — a son propre article : le développement database-first. Celui-ci en est la preuve. Une méthode, on hoche facilement la tête, et on l'abandonne tout aussi facilement dès qu'on est impatient de voir quelque chose à l'écran. Voici donc ce qui s'est réellement passé quand j'ai parié tout un produit sur le fait de faire d'abord la partie ennuyeuse : FIKR Space, aujourd'hui 11 produits intégrés et plus de 3 millions de lignes de code, tous posés sur une fondation de données conçue avant que rien de tout cela n'existe.

Étude de cas database-first : deux semaines et demie sans rien à montrer

Phase un — une semaine à cartographier les domaines. Avant la moindre ligne de code, j'ai listé chaque zone que le système toucherait un jour. Plus de 20 domaines au total, répartis en cinq groupes :

• Cœur : organisations, utilisateurs, équipes, permissions
• Produit : projets, tâches, objectifs, sprints
• Argent : tables de capitalisation, levées de fonds, transactions, valorisations
• Plateforme : programmes d'accélération, candidatures, cohortes, programme de formation
• Support : commentaires, pièces jointes, notifications, journaux d'activité

Phase deux — une semaine à concevoir chaque table. Chaque table a reçu la même ossature : quelle organisation possède l'enregistrement, qui l'a créé et quand, qui l'a modifié en dernier et quand, et des suppressions qui masquent les enregistrements au lieu de les détruire. Sur cette ossature, chaque domaine a reçu ses champs propres et ses listes de statuts et de types stockées comme des données modifiables — jamais figées dans le code.

Phase trois — trois jours à cartographier les relations. Une carte complète de la façon dont tout se connecte : quels enregistrements appartiennent à quels autres, lesquels sont liés en plusieurs-à-plusieurs, lesquels — comme les commentaires et les pièces jointes — peuvent se rattacher à n'importe quoi.

Total : environ deux semaines et demie. Toute la fondation, conçue et connectée — avant qu'un seul écran existe. Pour qui regardait, je n'avais rien construit. On me prenait pour un fou : « Pourquoi ne pas commencer à construire et voir en chemin ? » Parce que je n'avais pas le temps de reconstruire, pas d'argent à gaspiller, et aucune marge d'erreur. La base de données devait être juste du premier coup.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Ce que la fondation database-first a réellement rapporté

Puis les bénéfices ont commencé — et ne se sont jamais arrêtés. Voici chaque refonte majeure traversée par FIKR Space, et ce que chacune a exigé de la base de données :

Cinq refontes de l'interface. Zéro changement de base de données. Les écrans sont des fenêtres sur les données — je pouvais redécouper les fenêtres à l'infini parce que les murs ne bougeaient jamais. Cette asymétrie est tout l'argument du database-first : vous pouvez refondre complètement votre interface ; vous ne pouvez pas refondre complètement votre base de données.

La fondation a rapporté deux autres choses que l'argent ne peut pas rattraper après coup. D'abord, une source unique de vérité : le tableau de bord et la liste de tâches ne peuvent jamais se contredire, car chaque écran pose les mêmes questions aux mêmes tables. Ensuite, l'isolation des clients dès le premier jour : chaque enregistrement nomme l'organisation qui le possède, si bien que les données d'un client ne peuvent pas fuiter vers le compte d'un autre — et chaque fonctionnalité ajoutée depuis a hérité automatiquement de cette protection.

Comment pouvais-je savoir que j'aurais besoin de 1 000 tables ?

Je ne le savais pas. Je ne connaissais pas chaque table à l'avance — certains domaines ont évolué, et des champs ont été ajoutés en cours de route. Mais je connaissais le système : une plateforme multi-tenant pour startups, investisseurs et accélérateurs, gérant de l'argent réel, exigeant des permissions complexes et des pistes d'audit, avec plusieurs produits partageant une même fondation. Connaître le système vous dit quels types de tables doivent exister — entités, relations, tables de référence, journaux d'audit — avant même de connaître chaque champ. Quand de nouveaux besoins sont apparus, ils se sont insérés dans les schémas existants au lieu de les combattre.

C'est la moitié du travail de l'architecte — la répartition complète des rôles est dans vous êtes l'architecte, l'IA est le bâtisseur. L'IA a généré chaque migration exactement comme je l'avais spécifiée. Elle n'a pris aucune décision d'architecture. De l'exécution pure. Et elle a lutté en permanence contre la discipline : oublier l'étiquette d'organisation, sauter les index, proposer des raccourcis — les signaux d'alerte sont répertoriés dans 11 signes que l'IA se trompe avec aplomb.

Le contrefactuel : ce que coûte le fait de sauter cette étape

Voici à quoi ressemble la version « interface d'abord » de cette histoire. Semaine un, vous construisez un beau tableau de bord et créez une table pour l'alimenter. Semaine deux, vous construisez une liste de tâches et créez une autre table. Semaine trois, le tableau de bord affiche 15 tâches et la liste en montre 18 — parce que vous avez maintenant deux sources de vérité, et personne ne sait quand elles ont divergé ni laquelle a raison.

Maintenant, passez à l'échelle. Supposons que j'aie sauté l'isolation des clients et dû l'ajouter plus tard : chaque table modifiée, chaque requête réécrite, chaque règle d'accès créée, toutes les données existantes migrées. Des semaines de travail à haut risque touchant tout à la fois — le genre de chirurgie qui tue les produits solo. Parce qu'elle était conçue dès le premier jour, il n'y a jamais rien eu à rattraper.

Et l'argent ? La facture totale d'outils pour construire tout cela a été de 3 250 € — le détail est dans la pile à 3 250 €. L'investissement coûteux n'a jamais été le cash. C'était la discipline de consacrer deux semaines et demie aux fondations alors qu'il n'y avait rien à démontrer. Des centaines de fonctionnalités plus tard, toutes s'emboîtant, cela reste l'investissement au meilleur rendement que j'aie jamais fait dans un produit.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Pourquoi concevoir toute la base de données avant l'interface ?

Parce que l'interface peut changer et la base de données non — du moins pas à bas coût. Les écrans sont des fenêtres sur les données ; refaites-les aussi souvent que vous voulez. Mais restructurer les données sous un produit en production, c'est toucher toutes les fonctionnalités à la fois. Soignez la fondation et tout ce qui repose dessus tient debout.

Combien de temps a pris la conception de la base de données ?

Environ deux semaines et demie : une semaine à cartographier plus de 20 domaines, une semaine à concevoir chaque table avec une ossature commune, et trois jours à cartographier les relations entre elles. C'est le prix complet de la fondation — à comparer à 18 mois de construction sans aucune reconstruction.

La base de données a-t-elle déjà dû être reconstruite ?

Non. Pas une seule fois en 18 mois. Des champs ont été ajoutés et certains domaines ont évolué, mais toujours dans les schémas existants. Cinq refontes complètes de l'interface — tableau de bord, navigation, mise en page, style, mobile — n'ont nécessité aucun changement de base de données entre elles.

Ai-je besoin de 1 000 tables pour mon produit ?

Non. Ce nombre reflète 11 produits intégrés partageant une même fondation. Le principe s'applique à toute taille : listez chaque entité de votre système, cartographiez leurs relations, concevez tout cela avant de construire les écrans. La discipline est la même, que votre produit demande une douzaine de tables ou des centaines.