Je pourrais justifier chaque outil de ma stack séparément. SQLite est léger. pm2 garde mes processus en vie. TypeScript ajoute des types. Le CSS maison laisse du contrôle.
Ce sont de bonnes raisons, mais ce n’est pas celle qui relie vraiment mes choix.
Je développe et je maintiens mes projets seul. Quand quelque chose casse, je veux limiter le nombre d’endroits où chercher. Ma stack n’est donc pas optimisée pour éviter les problèmes. Elle est optimisée pour que je puisse encore comprendre le problème quand il arrive.
## SQLite garde la donnée au même endroit que l’application
Le contenu de mon portfolio, les articles, les messages du formulaire et l’administration vivent dans SQLite via Prisma. La base est un fichier sur le VPS. La documentation du connecteur SQLite de Prisma reflète bien ce modèle : la connexion pointe vers un chemin de fichier, pas vers un serveur séparé.
Pour mon usage, c’est exactement ce que je veux. Je n’ai pas un service Postgres à installer, exposer, mettre à jour et diagnostiquer. Si le portfolio fonctionne mais que ses données ne remontent plus, la recherche reste sur la même machine et dans le même déploiement.
Ça ne rend pas SQLite magique. J’ai laissé toutes les pages publiques en force-dynamic, donc chaque visite frappait la base alors que le contenu change surtout depuis l’admin. Le problème n’était pas SQLite. C’était mon modèle de rendu. Je suis passé à l’ISR pour arrêter de demander à la base de refaire un travail inutile.
La limite est connue : SQLite n’accepte qu’un seul écrivain à un instant donné et devient moins adapté quand plusieurs serveurs doivent partager directement la même base. Sa propre page sur les usages appropriés de SQLite le dit clairement. Mon portfolio n’a ni plusieurs serveurs ni une forte concurrence en écriture. Postgres m’ajouterait aujourd’hui une couche sans résoudre un problème que j’ai réellement.
## Le VPS et pm2 me montrent la chaîne entière
Vercel présente le déploiement de Next.js comme une intégration sans configuration, avec notamment des URLs de prévisualisation liées aux pull requests. C’est utile. Ce n’est simplement pas ce que je cherche sur mes projets personnels.
Mon dashboard et mon portfolio tournent sur mon VPS. nginx reçoit les requêtes, Next.js écoute sur un port interne et pm2 garde le processus actif. La documentation de pm2 couvre ce dont j’ai besoin : démarrage, redémarrage et logs depuis une CLI.
En échange, je récupère aussi les problèmes de cette chaîne.
J’ai eu des liens de newsletter qui renvoyaient vers localhost:3004, parce que l’origine vue derrière nginx n’était pas l’origine publique. Un cron ne chargeait pas nvm et risquait donc d’utiliser le Node du système. Des images ajoutées après le démarrage existaient sur le disque, mais next start répondait 404 jusqu’au redémarrage.
Ce sont des bugs que Vercel aurait pu m’éviter ou déplacer. Sur mon VPS, ils sont à moi. Mais je peux suivre la requête du domaine jusqu’au processus, regarder les variables d’environnement, le système de fichiers et les logs. Je préfère actuellement cette responsabilité à une abstraction que je comprends moins bien.
## Le CSS maison retire un vocabulaire intermédiaire
Le portfolio utilise des modules CSS. Next.js les prend en charge directement, avec des classes limitées localement au composant.
Je n’ai donc pas besoin d’un framework CSS pour obtenir cette isolation. J’écris la propriété que le navigateur doit appliquer. Quand une orbite de technologies tournait autour du mauvais centre, le problème venait de la taille des éléments et de leur point de rotation. Le corriger m’a obligé à comprendre les boîtes concernées, pas à chercher quelle classe utilitaire produisait le résultat.
C’est plus lent. Je répète parfois des valeurs. Je dois construire moi-même les composants visuels et maintenir la cohérence du site. Pour une grosse interface produite à plusieurs, ce coût pourrait devenir inutile. Sur ce portfolio, chaque écran est particulier et le design fait partie du projet. Le temps passé dans le CSS n’est donc pas seulement du coût : c’est aussi le travail que je voulais faire.
## TypeScript réduit les changements de langage mental
TypeScript est partout dans mon écosystème Next.js et Node. La promesse officielle reste simple : du JavaScript avec une syntaxe de types. Pour moi, l’intérêt principal est la continuité.
Les composants, les routes API, l’admin, les scripts et les accès Prisma utilisent les mêmes objets et les mêmes outils. Je passe moins de temps à reconstruire mentalement la forme d’une donnée entre deux parties du projet.
Les types ne protègent toutefois pas d’une mauvaise origine publique, d’un SMTP absent ou d’un fichier inaccessible après le démarrage. Ils disparaissent aussi à l’exécution. C’est pour cela que j’utilise encore zod aux frontières où les données entrent réellement.
Aujourd’hui, je garde donc SQLite, mon VPS avec pm2, mes modules CSS et TypeScript. Pas parce que cette combinaison serait supérieure. Elle concentre les responsabilités dans des endroits que je peux inspecter. Le prochain bug ne sera pas évité par la stack. Je saurai au moins où commencer à chercher.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.