Développement database-first :concevez avant de prompter

Le développement database-first consiste à concevoir votre base de données avant d'écrire la moindre ligne de code applicatif. Les deux semaines passées à concevoir le système avant de le construire vous feront gagner deux mois de refactoring pendant la construction. Ce n'est pas une hypothèse — c'est un problème de mathématiques vérifié dans chaque base de code que j'ai vue, y compris la mienne.

Les deux semaines les plus importantes de la construction de FIKR Space ont été celles passées à concevoir le schéma de la base de données avant d'écrire du code applicatif. La plupart des gens hochent la tête à cette phrase, puis l'ignorent. Voici la version pratique : les trois choses que « concevoir l'architecture » signifie vraiment, et le calendrier de construction qui en découle une fois que c'est fait.

Développement database-first : pourquoi la tentation est le piège

Vous serez tenté, dès que la validation est terminée, d'ouvrir Claude ou Cursor et de commencer à construire. Vous voudrez la dopamine du code qui s'accumule. Vous voudrez montrer une capture d'écran à votre conjoint à la fin du week-end. Résistez.

Commencer à coder avant que la base de données soit conçue est l'erreur maîtresse — tous les autres pièges de la construction en découlent. Vous vous sentez productif dès le premier jour parce que l'IA génère des écrans, mais la fondation en dessous est fluide, et chaque semaine où elle bouge, tout ce qui est construit dessus doit être refait. Cette boucle de reprise qui s'accélère, c'est exactement la façon dont le piège du vibe coding se referme sur des gens qui se sentaient inarrêtables en première semaine.

Étape 1 : concevoir la base de données — sur papier

Listez chaque entité de votre produit. Utilisateurs. Entreprises. Abonnements. Quels que soient les noms centraux. Puis listez les relations : un utilisateur appartient à une entreprise, une entreprise a plusieurs utilisateurs, un abonnement appartient à une entreprise et suit l'usage.

Dessinez-les sur papier. Oui, du papier. Le geste de dessiner vous fait penser à des cas limites que vous manqueriez dans une conception uniquement mentale. Quand les cases et les flèches cessent de changer, vous avez un schéma. Décrivez ensuite clairement les entités à Claude, et il écrira le SQL pour vous en vingt minutes. Vous avez maintenant votre fondation.

Étape 2 : définir les frontières des services

Quelles sont les grandes opérations que votre système effectue ? S'inscrire. Traiter un paiement. Générer un rapport. Envoyer une notification. Chacune est un service — une partie autonome du système avec une mission définie. Définissez les entrées et sorties de chaque service avant d'écrire le service.

Cela semble bureaucratique. Ça ne l'est pas. C'est la différence entre un système qui peut évoluer et un système qui se fige au bout de trois mois.

Étape 3 : parcourir les parcours utilisateur

Parcourez les trois choses les plus importantes qu'un utilisateur fera avec votre produit : s'inscrire, accomplir sa première action de valeur, renouveler son abonnement. Esquissez chaque parcours comme une séquence d'écrans ou d'interactions — ne concevez pas encore les écrans, seulement la séquence. Vous traquez les endroits où le parcours casse, ou ceux où vous avez supposé quelque chose qui ne sera pas vrai.

Quand la base de données, les services et les parcours tiennent la route sur papier — et la tiennent encore après les avoir regardés d'un œil neuf le lendemain — vous avez une architecture. Vous pouvez maintenant construire.

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 →

Le calendrier de huit semaines qui en découle

L'architecture d'abord n'est pas plus lente. C'est ce qui rend la partie rapide rapide. Voici le planning qu'elle débloque, à raison de quatre à huit heures par semaine de construction concentrée :

À la fin de la semaine six, le produit a ses trois ou quatre parcours centraux qui fonctionnent : s'inscrire, faire l'essentiel, être facturé, revenir demain et recommencer. C'est ce qu'une seule personne peut faire en 2026 et que dix personnes ne pouvaient pas faire en 2020, quel que soit le budget — et chacune de ces fonctionnalités hebdomadaires commence par un brief écrit, pas par un prompt plein d'espoir. C'est la méthode PRP, et elle ne marche que parce que l'architecture en dessous a cessé de bouger.

Ne laissez pas l'IA être l'architecte

Claude est un excellent exécutant et un architecte médiocre. Demandez-lui « cela doit-il être une table séparée ou une colonne JSON ? » et il vous répondra — généralement correctement, parfois mal, à l'occasion brillamment. Le problème, c'est que vous n'avez aucun moyen d'évaluer dans quel cas vous êtes si vous n'avez pas votre propre goût architectural. Développez-le délibérément : regardez comment d'autres produits structurent leurs systèmes, travaillez les compromis sur papier, et écrivez l'architecture avant de demander à Claude de l'implémenter.

Les décisions d'architecture sont les vôtres. Les décisions d'implémentation sont celles de Claude. Gardez cette frontière et la base de code gagne en qualité avec le temps ; brouillez-la et elle se dégrade.

Si vous en êtes là en ce moment, voici votre semaine : consacrez trois soirées aux entités et aux relations. Dessinez le schéma sur papier. Affinez-le. Faites générer le SQL par Claude. Vérifiez-le en parcourant vos trois parcours utilisateur les plus importants pour voir si le schéma les supporte proprement. N'écrivez pas encore de code applicatif. Dimanche soir, vous avez un schéma en lequel vous avez confiance et une liste des quatre à six fonctionnalités centrales que vous construirez durant les six semaines suivantes. Ennuyeux. Lent. Chaque heure en vaut la peine.

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

Questions fréquentes

Qu'est-ce que le développement database-first ?

Construire le modèle de données avant tout code applicatif : listez les entités et relations de votre produit, affinez-les sur papier jusqu'à ce qu'elles cessent de changer, et seulement alors générez le schéma et commencez à construire les fonctionnalités. La base de données est la fondation — tout le reste repose dessus, elle doit donc cesser de bouger en premier.

Combien de temps consacrer à l'architecture avant de coder ?

Deux semaines — base de données, frontières des services et parcours utilisateur. Ces deux semaines vous font gagner deux mois de refactoring pendant la construction, car des fonctionnalités bâties sur une fondation stable n'ont pas à être refaites chaque fois que la fondation bouge.

L'IA peut-elle concevoir ma base de données à ma place ?

L'IA peut écrire le schéma — décrivez clairement vos entités et Claude produit le SQL en vingt minutes. Mais elle ne doit pas prendre les décisions de conception. Claude est un excellent exécutant et un architecte médiocre : les entités, les relations et les compromis sont à vous de les trancher avant de rédiger vos prompts.

Je ne suis pas technique — puis-je vraiment concevoir un schéma ?

Oui, car la partie difficile n'est pas technique. Il s'agit de lister les noms de votre activité — utilisateurs, entreprises, abonnements — et leurs relations, que vous connaissez mieux que n'importe quel développeur. Des cases et des flèches sur papier. Quand elles cessent de changer, la conception est terminée et l'IA se charge de la traduction en SQL.