Mes choix de stack ne sont pas des choix définitifs. Je n’utilise pas SQLite parce que Postgres serait mauvais, ni un VPS pour prouver que je sais ouvrir une connexion SSH. Ces outils correspondent simplement à la taille actuelle de mes projets et à ce que je veux apprendre en les maintenant.
La vraie question n’est donc pas seulement pourquoi je les utilise. C’est aussi ce qui me ferait les remplacer.
## SQLite tant que la base reste dans l’application
Le portfolio stocke ses projets, ses articles, ses messages de contact et ses abonnés dans SQLite via Prisma. L’application et le fichier de base vivent sur la même machine. Il n’y a pas de serveur de base séparé, pas de connexion réseau à maintenir, pas de service supplémentaire à surveiller.
Le connecteur SQLite de Prisma pointe directement vers un fichier. Pour mon cas, cette simplicité compte plus qu’une capacité de montée en charge que je n’utilise pas.
La limite est claire. SQLite n’autorise qu’un seul writer à un instant donné. Mes écritures viennent surtout du panneau d’admin, du formulaire de contact, de la newsletter et du script qui publie les articles. Je n’ai pas plusieurs serveurs qui écrivent en parallèle.
Je passerais à Postgres si cette topologie changeait. Plusieurs instances de l’application, beaucoup d’écritures concurrentes ou une base accessible par plusieurs services rendraient le fichier local moins logique. Le seuil n’est pas un nombre arbitraire de lignes. C’est le moment où la base ne peut plus raisonnablement rester attachée à une seule application sur une seule machine.
## Mon VPS tant que je veux posséder les problèmes
Mon portfolio et mon dashboard tournent sur mon VPS. pm2 garde les processus Node actifs et me donne leurs états et leurs logs. C’est exactement le périmètre présenté dans la documentation de pm2 : démarrer, redémarrer et observer des processus sans installer une plateforme entière.
Devant Next.js, nginx sert de reverse proxy. Ce n’est pas un montage détourné : la documentation d’auto-hébergement de Next.js recommande elle-même de placer un reverse proxy devant le serveur.
Ce choix me donne le contrôle, mais il me donne aussi les pannes. Le 28 juillet, les liens de confirmation de la newsletter renvoyaient vers localhost:3004, parce que l’origine vue derrière nginx était l’adresse interne. J’ai dû séparer l’origine utilisée entre services de l’origine publique placée dans les emails. Le même VPS m’a aussi obligé à comprendre pourquoi cron ne chargeait pas nvm comme ma session SSH.
Vercel m’éviterait une partie de cette plomberie. Pour l’instant, cette plomberie fait partie du projet. Je changerais si l’exploitation du serveur prenait régulièrement plus de temps que le produit, ou si plusieurs machines devenaient nécessaires. À ce moment-là, pm2 sur un VPS unique ne serait plus de la simplicité. Ce serait une architecture trop petite que je m’obstinerais à conserver.
## Du CSS maison tant que le design reste spécifique
Le portfolio utilise des modules CSS écrits à la main. Next.js prend directement en charge les fichiers .module.css, avec des classes limitées au composant, comme l’explique sa documentation sur les CSS Modules.
Je voulais une interface terminal précise, pas une composition rapide à partir d’un système visuel déjà décidé. Écrire le CSS m’a forcé à comprendre les dimensions, les empilements et les animations que j’aurais pu masquer derrière des classes utilitaires.
Le coût existe. Chaque nouvel écran demande plus de temps. Je dois maintenir moi-même les espacements, les couleurs et les variantes. Si le projet grossissait jusqu’à répéter les mêmes décisions dans des dizaines de composants, un framework ou un vrai système de design redeviendrait intéressant. Je ne suis pas contre TailwindCSS. Je ne veux simplement pas l’ajouter avant que la répétition justifie cette couche.
## TypeScript tant que le code doit continuer à bouger
TypeScript est le choix le moins négociable dans mon écosystème Next.js, React et Node. Son contrôle statique attrape une partie des incohérences avant l’exécution. Sur un projet avec un panneau d’admin, des routes API, des composants et des scripts, je préfère que les changements cassent dans l’éditeur plutôt qu’après le déploiement.
Il ne valide pas pour autant les données reçues à l’exécution. C’est pour ça que le portfolio utilise aussi zod aux frontières. TypeScript décrit ce que mon code pense manipuler. Il ne transforme pas une requête invalide en donnée correcte.
Pour l’instant, je ne prépare aucune migration. Je surveille plutôt quatre signaux : la concurrence des écritures, le temps passé à administrer le VPS, la répétition dans le CSS et les contournements du typage. Le prochain changement de stack viendra de l’un de ces problèmes, pas d’une liste d’outils à adopter en 2026.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.