La stack est une conséquence, pas un point de départ

Quand un projet démarre, la vraie question n’est pas la stack, mais le besoin à adresser.
Vitrine, application, backend, base de données : chaque cas appelle une structure différente. Plutôt que de réinventer la roue à chaque fois, j’ai construit un ensemble de bases et de scripts qui m’orientent rapidement vers la bonne solution, le tout encapsulé dans des devcontainers pour démarrer immédiatement, quel que soit l’environnement.

Formaliser l’entonnoir de décision 🧠

Au départ, tous les projets ne se ressemblent pas, mais les mêmes questions reviennent systématiquement.

Est-ce un site vitrine ou une application ?
Y a-t-il de la donnée à persister ?
Faut-il un backend, une API, une base de données ?

Ces questions conditionnent bien plus l’architecture d’un projet que le choix d’un framework. J’ai donc transformé cette réflexion implicite en quelque chose de plus explicite :
un entonnoir de décision, simple et reproductible.

L’idée est volontairement simple. En fonction du besoin du projet, je veux pouvoir m’orienter rapidement vers une base adaptée :

Vitrine
Structure légère, orientée performance
Application
Front et backend clairement séparés
Donnée
Schéma, ORM et conventions en place

Chaque base répond à un cas précis, sans chercher à couvrir tous les scénarios possibles.

Réduire les décisions répétées 🔁

Ce travail n’a pas pour objectif d’être exhaustif ou universel. Il sert surtout à éliminer les décisions que je prenais systématiquement au début de chaque projet :

structure des dossiers
outils de base
conventions
scripts de démarrage

Une fois ces choix stabilisés, l’énergie peut enfin être mise ailleurs :
sur le besoin réel du client et la logique métier.

Des structures concrètes : les briques du socle 🧱

Une fois l’entonnoir posé, il restait à le matérialiser. Plutôt que de maintenir une structure unique censée tout faire, j’ai choisi de construire plusieurs bases ciblées, chacune adaptée à un type de projet précis. Ces bases ne sont pas des templates figés, mais des points de départ cohérents, pensés pour être utilisés en conditions réelles. Le choix des outils n’est pas un dogme, mais une réponse pragmatique aux projets rencontrés.

Vitrine : une base légère et performante 🚀

Tous les projets n’ont pas besoin d’un backend ou d’une base de données. Pour une vitrine, l’objectif est simple :

performance
clarté
maintenance minimale

Cette base s’appuie sur Astro :

rendu statique par défaut
JavaScript limité au strict nécessaire
structure claire orientée contenu

L’enjeu n’est pas d’ajouter de la complexité, mais au contraire de savoir s’arrêter quand le besoin est simple.

Application : front et backend clairement séparés 🧩

Dès qu’un projet dépasse la simple vitrine, les besoins changent. Il faut gérer :

de la logique métier
des utilisateurs
des échanges avec une API

Pour ces cas, j’ai mis en place un monorepo structuré autour :

d’un backend Express
d’un front Vue
de conventions claires entre les deux

Ce choix facilite :

la cohérence des contrats
l’évolution du projet
l’onboarding d’un autre développeur

Base de données : anticiper sans sur-ingénierie 🗄️

Ajouter une base de données change profondément la nature d’un projet. Les erreurs deviennent plus coûteuses et les choix initiaux pèsent plus longtemps. Pour ces projets, j’ai intégré dès le départ :

un ORM (Prisma)
un schéma explicite
des conventions pour les migrations

L’objectif n’est pas de tout prévoir, mais d’avoir une base saine pour faire évoluer le projet sans repartir de zéro.

Le devcontainer comme socle commun 🐳

Ces structures auraient peu d’intérêt si leur mise en place dépendait encore de la machine ou de l’environnement du développeur. Chaque base est pensée pour être utilisée directement dans un devcontainer :

mêmes versions d’outils
mêmes scripts
même comportement, quel que soit l’OS

Ouvrir le projet, coder, point. Cela permet :

d’éviter les “ça marche chez moi”
de faciliter l’onboarding
de garantir une compatibilité maximale entre environnements

Des scripts au service du besoin ⚙️

Autour de ces bases, j’ai progressivement ajouté des scripts pour :

initialiser un projet
lancer les services nécessaires
rester cohérent d’un projet à l’autre

Ils ne cherchent pas à être magiques.
Ils existent surtout pour réduire les frictions et automatiser ce qui n’a pas besoin d’être redécidé.

Ce que je ferais différemment aujourd’hui 🔍

Avec le recul, une chose me paraît importante à préciser :
les choix de frameworks et d’outils présentés ici sont avant tout des choix personnels. Ils sont directement liés aux projets que j’ai eu à réaliser jusqu’ici, à leurs contraintes, et à ce que je cherchais à optimiser à ce moment-là. Certains de ces socles sont d’ailleurs partis de templates existants, que j’ai progressivement adaptés et revisités à ma façon.
Un peu comme un cuisinier qui part d’une recette existante, puis la revisite selon son goût, ses outils et le contexte. Avec plus d’expérience, je referais probablement certains choix différemment.
Et c’est normal. L’objectif n’est pas de figer une stack idéale, mais de structurer une manière de réfléchir :

partir du besoin
limiter les décisions répétées
construire des bases suffisamment saines pour évoluer

Ces repositories sont moins une vérité technique qu’un instantané de mon parcours à un moment donné.

Ce que ce socle dit de ma façon de travailler ✨

Ce travail n’a pas été motivé par l’envie de créer la bonne stack, mais par celle de mieux travailler au quotidien. Formaliser un entonnoir de décision, stabiliser des bases réutilisables et développer dans des environnements reproductibles m’a appris une chose essentielle : la qualité d’un projet se joue souvent avant la première feature. Aujourd’hui, ce socle me sert de garde-fou.
Il m’aide à éviter de réinventer la roue, à démarrer vite, et à rester concentré sur ce qui apporte réellement de la valeur.

C'est cadeau ☺️ 👉Boilerplate Astro 👉Boilerplate App 👉Devcontainer "Framework"