Ma stack personnelle n’est pas construite pour absorber une croissance imaginaire. Elle est construite pour mes projets actuels : un portfolio, son panneau d’admin et un dashboard que j’ouvre des dizaines de fois par jour.
Tout tourne autour de la même idée : garder peu de pièces, comprendre leur rôle et accepter leurs limites. Ce n’est pas la stack que je choisirais automatiquement pour un autre contexte.
## SQLite plutôt que Postgres
Le contenu du portfolio vit dans SQLite via Prisma. Les projets, le parcours, les articles, les messages de contact et les abonnés à la newsletter finissent dans un fichier sur le même VPS que l’application.
Pour ce volume et cet usage, ajouter Postgres me donnerait surtout un service supplémentaire à installer, sécuriser, sauvegarder et surveiller. Le connecteur SQLite de Prisma pointe directement vers un fichier local. C’est exactement le niveau d’infrastructure dont j’ai besoin.
La vraie limite n’est pas cachée. SQLite n’accepte qu’un seul écrivain à un instant donné. Sa propre documentation recommande plutôt une base client-serveur quand il faut beaucoup d’écritures concurrentes ou plusieurs serveurs applicatifs. Elle détaille clairement les cas où SQLite convient et ceux où il faut regarder ailleurs.
Mon portfolio reçoit surtout des lectures. Les écritures passent par moi, le formulaire de contact, la newsletter et quelques routes ciblées. Je n’ai pas plusieurs machines qui attaquent directement la même base.
J’ai même réduit les lectures inutiles récemment. Les pages publiques frappaient SQLite à chaque visite à cause de force-dynamic. Je les ai passées en ISR avec une revalidation d’une heure. Ce changement a ensuite exposé un autre problème : une navigation interne pouvait afficher un parcours périmé juste après une modification dans l’admin. Une stack simple ne supprime pas les problèmes de cache. Elle rend seulement le chemin jusqu’au problème plus court.
## Mon VPS et pm2 plutôt que Vercel
Vercel présente son déploiement Next.js comme une intégration sans configuration. C’est précisément une partie de ce que je ne cherche pas à déléguer sur mes projets personnels.
Je veux savoir quel processus écoute sur quel port, où se trouve la base, comment le build arrive sur la machine et ce qui redémarre l’application. Mon dashboard écoute sur un port, le portfolio sur un autre, puis le reverse proxy distribue les requêtes. La documentation de Next.js sur l’auto-hébergement recommande justement de placer un reverse proxy devant le serveur Next.js.
pm2 garde les processus actifs et me donne des commandes simples pour les redémarrer ou lire leurs logs. Sa documentation de démarrage couvre exactement ce petit périmètre.
Le prix du contrôle, c’est que mes erreurs d’infrastructure sont aussi les miennes. J’ai eu un cron qui ne chargeait pas nvm, un déploiement qui utilisait le mauvais Node et une revalidation qui visait localhost:3000, donc le dashboard au lieu du portfolio sur 127.0.0.1:3004.
Vercel m’éviterait une partie de cette plomberie. Mon VPS m’oblige à la comprendre. Aujourd’hui, je préfère payer ce choix en temps de maintenance.
## Du CSS écrit à la main
Le portfolio utilise des modules CSS, sans framework. Je voulais une interface terminal où le rythme, les espacements, les orbites de technologies et les effets de masque ne ressemblent pas à un assemblage de composants déjà vus.
Écrire le CSS directement m’a obligé à revenir sur la cascade, les contextes de positionnement et les dimensions réelles des éléments. Quand les technologies de l’orbite quittaient leurs anneaux, le problème venait de boîtes de tailles variables utilisées comme pivots de rotation. Une classe utilitaire différente n’aurait pas remplacé cette compréhension.
Je ne considère pas pour autant les frameworks CSS comme une erreur. J’utilise aussi TailwindCSS. Sur le portfolio, le CSS maison sert le projet. Sa limite est simple : c’est plus lent, plus répétitif et plus facile à désorganiser si je ne tiens pas mes conventions.
## TypeScript partout dans le web
Next.js, les routes API, les scripts et l’admin restent dans le même langage. Je peux suivre une donnée depuis Prisma jusqu’au composant sans changer de modèle mental à chaque couche.
TypeScript reste un vérificateur statique : il travaille avant l’exécution, comme l’explique son Handbook officiel. Il ne rend pas valide une requête HTTP reçue en production. C’est pour cette frontière que j’utilise Zod dans l’admin et les API.
Cette stack tient parce que mes contraintes tiennent encore sur une machine. Le premier signal de changement sera concret : plusieurs instances, beaucoup d’écritures concurrentes ou une maintenance serveur qui prend plus de temps que le produit. Tant qu’aucun de ces signaux n’est là, je garde les pièces que je sais diagnostiquer.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.