Le raisonnement derrière chaque choix
Pas juste « c'est quoi » — mais pourquoi celle-là plutôt qu'une autre. De quoi expliquer ta stack à quelqu'un qui ne la connaît pas, et savoir toi-même pourquoi tu t'en sers.
Chaque outil de cette stack a été choisi pour la même raison : c'est un standard éprouvé, avec une grosse communauté, une bonne documentation, et pas de risque qu'il disparaisse dans deux ans. Aucun n'a été pris parce qu'il est nouveau ou à la mode.
Et surtout : c'est toujours la même stack, projet après projet. Ce n'est pas de la paresse — c'est volontaire. Changer d'outil à chaque projet, c'est repartir de zéro à chaque fois. Garder la même stack, c'est devenir vraiment bon dessus.
01 Fondations — Next.js, React, TypeScript
React s'est imposé comme le standard pour construire des interfaces : le plus gros écosystème, le plus de développeurs qui le connaissent, le plus de composants déjà écrits par d'autres. Apprendre React plutôt que Vue ou Svelte, c'est un pari sur la taille de la communauté, pas sur la technique pure.
Next.js ajoute ce que React seul ne fait pas : le routage (les pages), le rendu côté serveur, et des routes API. Sans lui, il faudrait assembler soi-même un routeur, un serveur, un bundler — Next.js fait ces choix à ta place et les fait bien.
TypeScript n'est pas un extra : sur un projet qui grandit, JavaScript pur laisse passer des erreurs bêtes (appeler une fonction avec le mauvais type de donnée) jusqu'en production. TypeScript les attrape à l'écriture du code.
Vue et Svelte sont solides aussi, mais React a plus de ressources d'apprentissage et se retrouve dans plus d'offres d'emploi — un critère qui compte pour toi. Angular est plus lourd et plus rigide pour un usage en solo.
02 Interface — Tailwind, shadcn/ui, React Hook Form, Zod
Tailwind évite deux extrêmes : écrire du CSS à la main (lent, on invente 40 noms de classes différents pour la même chose) ou dépendre d'une librairie de composants qui impose son propre style (Bootstrap, Material UI) et qu'il faut ensuite forcer pour la personnaliser.
shadcn/ui règle le problème des composants de base (bouton, formulaire, carte) sans imposer de dépendance : le code du composant est copié directement dans ton projet. Tu peux le modifier librement, il ne se met pas à jour tout seul dans ton dos et ne casse jamais après une mise à jour de librairie.
React Hook Form + Zod forment un duo : Zod décrit ce qu'une donnée doit être (« un email valide », « un texte de 1 à 80 caractères »), React Hook Form branche cette règle à un formulaire et affiche l'erreur au bon endroit. Sans ça, chaque formulaire réinvente sa propre validation, souvent en oubliant des cas.
03 Données — PostgreSQL, Supabase, Prisma
PostgreSQL est une base relationnelle : les données sont dans des tables liées entre elles (un client a plusieurs commandes, une commande a plusieurs lignes...). C'est le bon défaut pour la plupart des projets, où les données ont une structure claire et des relations entre elles — contrairement à une base NoSQL, pensée pour des données sans structure fixe.
Supabase héberge cette base en ligne gratuitement pour démarrer. L'alternative serait d'installer Postgres soi-même (avec Docker par exemple) et de gérer un serveur — une charge inutile tant que le projet est petit.
Prisma évite d'écrire du SQL à la main pour chaque requête. Tu décris ton schéma une fois, et Prisma génère du code TypeScript avec autocomplétion pour lire et écrire les données, plus un système de migrations pour faire évoluer les tables proprement.
MongoDB (NoSQL) est tentant pour sa simplicité de départ, mais devient vite un problème dès que les données ont des relations claires — ce qui est le cas dans presque tous tes projets (utilisateurs, commandes, produits...).
04 Comptes & paiement — Better Auth, Stripe
L'authentification (mots de passe, sessions, sécurité) est un domaine où une erreur coûte cher — un mot de passe mal haché ou une session mal protégée, et c'est une fuite de données. Better Auth prend ce risque en charge : c'est du code testé par une large communauté, pas une implémentation maison à faire valider par personne d'autre que toi.
Stripe est le standard du paiement en ligne. Il gère la conformité bancaire (PCI-DSS) à ta place — sans lui, il faudrait toi-même respecter des normes de sécurité bancaires très strictes rien que pour stocker un numéro de carte, ce qui est hors de portée d'un projet solo.
05 Qualité & déploiement — Vitest, Playwright, GitHub Actions, Vercel
Vitest teste des petits bouts de logique isolés (une validation Zod, une fonction de calcul) — rapide à exécuter, utile pour attraper une régression tout de suite après une modification.
Playwright teste un parcours complet en pilotant un vrai navigateur (s'inscrire → créer une file → ajouter une entrée) — plus lent, mais ça vérifie que tout s'enchaîne vraiment, pas juste chaque brique séparément.
GitHub Actions relance ces tests automatiquement à chaque push, et peut bloquer une mise en ligne si un test échoue — un filet de sécurité qui ne dépend pas de ta discipline personnelle un jour de fatigue.
Vercel héberge le site. Il est fait par la même équipe que Next.js et le déploie automatiquement à chaque push, sans configuration serveur à gérer.
06 Mobile — Expo, React Native, NativeWind
Si un jour tu veux une app installable, tu n'as pas besoin d'apprendre un nouveau langage natif (Swift pour iOS, Kotlin pour Android). React Native reprend les mêmes principes que React ; Expo ajoute l'outillage pour tester en direct sur ton téléphone et publier sur les stores sans installer Xcode ou Android Studio pour démarrer.
Le backend ne change pas : ton projet Next.js reste la même API, juste appelée depuis l'app mobile en plus du site web. C'est pour ça que le mobile est une couche en plus, pas un projet séparé à reconstruire de zéro.
· Ce qui est volontairement absent, pour l'instant
NestJS / FastAPI — utile seulement si le backend doit un jour vivre séparément du frontend (ex. plusieurs apps différentes qui partagent une même API, ou une équipe backend distincte). Tant que c'est toi seul sur un projet complet, un backend séparé n'apporte rien de plus que les routes API déjà incluses dans Next.js — juste de la complexité en plus.
Docker — utile pour figer un environnement identique entre plusieurs machines ou déployer sur ton propre serveur. Supabase et Vercel évitent ce besoin dès le départ : ils gèrent déjà cet environnement pour toi.
Ce n'est pas qu'ils sont mauvais — c'est qu'ils répondent à un problème que tu n'as pas encore. Les ajouter avant d'en avoir besoin, c'est de la complexité gratuite.