← RETOUR AU BLOG/BUILD WITH AI

Application ou écosystème :décidez avant la base de données

Application ou écosystème : la question à trancher avant de concevoir une seule table. Se tromper, c'est reconstruire la fondation après la prise du béton.

CATÉGORIEBuild with AI
TEMPS DE LECTURE6 min
PUBLIÉ10 oct. 2026
AUTEURLuis Goncalves
Application ou écosystème : une cabane de jardin face à un immeuble, deux fondations de base de données très différentes

Application ou écosystème : c'est la question à trancher avant de concevoir la moindre table de base de données. Construisez-vous une application, ou un écosystème ? Une application sert un type d'utilisateur qui fait un travail. Un écosystème sert plusieurs types d'utilisateurs dont les données se connectent et circulent entre eux. La réponse change tout pour votre base de données — la conception d'un écosystème est environ 10 fois plus complexe — et mieux vaut le savoir avant de couler la fondation qu'après.

C'est la question à laquelle j'ai répondu avant d'écrire la moindre ligne de code pour ma propre plateforme, et c'est la raison pour laquelle la base de données a atteint la taille qu'elle a. Voici comment la poser correctement, à quoi chaque réponse vous engage, et l'exercice qui fait émerger la vérité en vingt minutes.

La question qui décide de toute votre base de données

Les bases de données sont des fondations, et les fondations sont façonnées par ce qui reposera dessus. Une cabane de jardin et un immeuble ont tous deux besoin de béton — mais personne ne coule la dalle d'une cabane et décide ensuite d'ajouter douze étages. Le logiciel, c'est pareil : la forme de votre modèle de données est fixée par la version la plus ambitieuse de ce que vous construisez, et c'est la seule partie de votre produit qui est vraiment douloureuse à changer plus tard. (Vous découvrez ce qu'est un modèle de données ? Commencez par les bases de données expliquées aux fondateurs non techniques.)

Le premier acte de conception n'est donc pas de dessiner des tables. C'est de décider ce que vous construisez réellement. Pas les fonctionnalités — la vision.

À quoi ressemble « juste une application »

Une application a un seul type d'utilisateur qui fait un seul travail. Un suivi du temps. Un générateur de factures. Un outil de suivi d'habitudes. Sa base de données est d'une petitesse rafraîchissante : une table d'utilisateurs, une table de projets, une table de tâches — terminé. Simple.

Il n'y a rien de mal à cela. Si votre vision est vraiment un outil ciblé pour une seule audience, une base de données petite et propre est une force : plus rapide à construire, plus facile à raisonner, moins chère à maintenir. L'erreur n'est pas de construire une application. L'erreur est de construire la fondation d'une application sous l'ambition d'un écosystème.

À quoi ressemble un écosystème

Quand j'ai commencé ma plateforme, je ne me suis pas assis pour construire « une application ». Je me suis assis pour construire un écosystème. La vision : une plateforme où les startups gèrent toute leur activité, où les accélérateurs gèrent leurs programmes et leurs portefeuilles, où les fonds de VC suivent leur deal flow et leurs investissements, et où les affiliés font la promotion et gagnent de l'argent — tous connectés, tous en dialogue les uns avec les autres.

Ce seul paragraphe a transformé la base de données. Au lieu d'une table d'utilisateurs, il me fallait des organisations de types fondamentalement différents — startups, accélérateurs, VC, affiliés — avec des utilisateurs rattachés à elles selon différents rôles. Au lieu des tables d'un seul produit, il me fallait dix produits — OS, HUB, CAP, Money, People, Score, Pitch, Accelerator, Affiliates, VC — partageant des données qui circulent entre eux : la startup dirigée par un fondateur est la même que celle qu'un accélérateur coache et qu'un VC évalue. Des relations entre tous, partout.

C'est pourquoi la plateforme tourne sur 964 tables. Pas parce que je voulais de la complexité — parce que la vision l'exigeait. La base de données d'un écosystème n'est pas une base d'application en plus grand ; c'est un objet d'une autre nature, comme le réseau routier d'une ville n'est pas une allée plus longue.

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 →

Application ou écosystème : les différences concrètes

ApplicationÉcosystème
UtilisateursUn seul type, pour un seul travailPlusieurs types, avec des rôles différents
OrganisationsGénéralement un seul type (ou aucun)Plusieurs types qui sont en relation entre eux
DonnéesAutonomes pour chaque utilisateurPartagées, circulant entre types d'utilisateurs et produits
Base de donnéesUne poignée de tablesEnviron 10 fois plus complexe
Coût d'une mauvaise estimationDe la tuyauterie surdimensionnée dont vous n'aviez pas besoinReconstruire la fondation sous un produit en production

Notez l'asymétrie de la dernière ligne. Choisir « écosystème » alors qu'il ne vous fallait qu'une application vous coûte un peu de structure inutile. Choisir « application » alors que votre vision était un écosystème vous coûte la fondation elle-même — greffer des liens entre types d'utilisateurs sur des tables qui n'ont jamais été conçues pour être en relation est le genre de chirurgie qui paralyse un produit pendant des mois.

Pourquoi décider maintenant, pas plus tard

Parce qu'une complexité multipliée par 10 est parfaitement gérable quand on la connaît d'emblée, et brutale quand on la découvre à mi-chemin. Mieux vaut le savoir maintenant que s'en rendre compte après avoir construit la mauvaise fondation.

Décider « écosystème » tôt débloque aussi le choix structurel le plus important qui rend les écosystèmes possibles : concevoir pour plusieurs organisations dès le premier jour, chaque ligne de données appartenant à exactement une d'elles. Ce schéma — le multi-tenant — est quasiment gratuit à intégrer au départ et quasiment impossible à greffer plus tard. C'est la première conséquence concrète de la réponse à la question application ou écosystème, et c'est exactement pourquoi la question vient avant les tables.

Et pour être clair, cela vaut dans les deux sens : si la réponse honnête est « application », construisez une application. Ne surchargez pas un outil ciblé de tuyauterie d'écosystème parce que cela paraît plus ambitieux. Le péché n'est pas d'être petit ; c'est l'inadéquation.

L'exercice : écrivez la vision, pas les fonctionnalités

Avant votre prochaine table, prenez vingt minutes et écrivez la vision. Pas la liste des fonctionnalités — la vision. Trois questions font le travail :

Qui sont TOUS les utilisateurs ? Pas seulement l'évident. Qui d'autre intervient — administrateurs, partenaires, évaluateurs, acheteurs, promoteurs ? Comment se connectent-ils ? Lesquels ont besoin de voir, de partager ou d'agir sur les mêmes enregistrements ? Quelles données partagent-ils ? Quelles informations circulent entre eux plutôt que de vivre dans le silo d'une seule personne ?

Si les réponses sont « un seul type d'utilisateur, aucune connexion, rien de partagé », félicitations : vous construisez une application, et votre base de données peut rester magnifiquement petite. Si les réponses impliquent plusieurs types d'utilisateurs qui échangent des données — vous construisez un écosystème, et chaque table que vous concevrez à partir de maintenant doit le savoir.

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

Questions fréquentes

Un écosystème est-il meilleur qu'une application ?

Non — l'adéquation vaut mieux que l'inadéquation. Une application ciblée avec une petite base de données adaptée à sa vision bat un écosystème à moitié construit à tous les coups. Le but n'est pas de viser plus grand ; c'est de rendre votre base de données honnête sur ce que vous construisez réellement.

Puis-je commencer par une application et évoluer vers un écosystème ?

Oui — si la fondation le permet. Le compromis qui fonctionne : cadrer les fonctionnalités comme pour une application, mais faire la poignée de choix fondamentaux (multi-tenant, organisations comme enregistrements de premier rang, références propres) comme si la vision d'écosystème pouvait se réaliser. Les fonctionnalités s'ajoutent facilement plus tard ; les fondations, non.

De combien de tables un écosystème a-t-il besoin ?

Il n'y a pas de nombre magique — 964 est ce qu'un vrai écosystème de dix produits a exigé, pas un objectif. La réponse honnête : autant que la vision en demande, et c'est exactement pourquoi on écrit d'abord la vision et on laisse le nombre de tables en découler, plutôt que l'inverse.

L'IA me posera-t-elle la question application ou écosystème ?

Non — et c'est le danger. Demandez à l'IA de « me construire une plateforme » et elle produira volontiers un schéma en forme d'application, parce que les applications sont la moyenne statistique de tout ce qu'elle a vu. La vision vit dans votre tête. Énoncez-la explicitement — tous les types d'utilisateurs, les connexions, les données partagées — et l'IA pourra concevoir en conséquence. Laissez-la implicite et vous obtenez une dalle de cabane sous votre immeuble.

À quel point êtes-vous piégé ?

Faites l'Indice d'Asphyxie Corporate, l'évaluation gratuite pour savoir si vous êtes prêt à devenir solopreneur.

Commencer l'évaluation →