Ma stack peut ressembler à une suite de refus : pas de Postgres, pas de Vercel, pas de framework CSS, pas de JavaScript sans types.
Ce n’est pas vraiment comme ça que je l’ai choisie. Le point commun est plutôt la proximité. J’essaie de garder les données, le processus, les styles et les contrats près du projet qui les utilise.
Ça ne rend pas le projet plus simple dans l’absolu. Ça me donne surtout une chaîne cohérente avec ma manière de travailler seul sur mon VPS.
## SQLite reste avec l’application
Le contenu de mon portfolio vit dans SQLite via Prisma. La base est sur la même machine que l’application. Je n’ai pas un service Postgres séparé à configurer uniquement pour stocker mes projets, mes articles et les données de mon panneau d’admin.
C’est précisément le modèle de SQLite : la base est intégrée à l’application, sans processus serveur distinct. Sa propre documentation oppose cette approche locale aux bases client-serveur et recommande SQLite lorsque les données restent sur la même machine que l’application et que les écritures concurrentes sont limitées. La limite est explicite : plusieurs lectures peuvent avoir lieu en même temps, mais les écritures passent une par une. (sqlite.org)
Pour mon portfolio, ce compromis correspond au produit réel. L’admin n’est pas utilisé par une équipe entière. Je n’ai pas plusieurs serveurs qui écrivent dans la même base.
La limite n’est donc pas théorique. Si le projet devait répartir ses données sur plusieurs machines ou absorber beaucoup d’écritures simultanées, SQLite deviendrait un mauvais point de rassemblement. Postgres aurait alors une vraie fonction. Aujourd’hui, il ajouterait surtout un service de plus.
## Mon VPS garde le processus visible
Mon portfolio et mon dashboard tournent sur mon VPS. Next.js documente officiellement l’auto-hébergement derrière un reverse proxy, donc je ne détourne pas le framework de son usage. Je choisis simplement de maintenir moi-même cette partie. (nextjs.org)
pm2 garde les applications lancées et me donne des commandes directes pour voir leur état, consulter leurs logs ou les redémarrer. Sa documentation couvre aussi la restauration des processus après un redémarrage de la machine avec pm2 startup et pm2 save. C’est un gestionnaire de processus assez proche de ce dont j’ai besoin, sans transformer mon déploiement en plateforme complète. (pm2.keymetrics.io)
Je préfère ça à Vercel parce que je veux posséder le chemin complet : build, fichiers, processus et reverse proxy. En contrepartie, personne ne corrige ce chemin à ma place.
Mes commits du 14 août le montrent bien. J’ai dû purger le cache d’images de Next.js pendant le déploiement. Le même jour, j’ai corrigé mon script Bash qui continuait à exécuter son ancienne version après son propre git pull. Ce sont exactement les problèmes que mon choix me laisse.
## Le CSS reste une partie du composant
Pour le portfolio, j’écris le CSS à la main avec des modules. Next.js prend directement en charge les fichiers .module.css et génère des noms de classes locaux pour éviter les collisions. Je n’ai donc pas besoin d’ajouter un framework pour obtenir cette isolation. (nextjs.org)
La raison est liée au projet. Le portfolio a une direction terminal, un accent cyan et aucun template. Je voulais décider de l’espacement, des états et de la mise en page plutôt que composer l’interface à partir d’un vocabulaire de classes déjà défini.
C’est plus lent. Chaque règle doit être écrite, nommée et maintenue. Sur une interface composée rapidement de nombreux écrans conventionnels, je pourrais préférer un framework. Ici, cette lenteur fait partie du travail que je voulais faire.
## TypeScript traverse toutes les frontières internes
TypeScript est présent dans les composants React, les routes Next.js et le code Node. Son rôle n’est pas de rendre le programme correct par magie. Il vérifie les formes et les usages des valeurs avant l’exécution, comme l’explique le handbook officiel. (typescriptlang.org)
Pour moi, son intérêt principal est la continuité. Quand une donnée passe de l’admin au serveur puis à un composant, je reste dans le même langage et le même système de types.
Cette continuité s’arrête dès qu’une donnée arrive de l’extérieur. Un formulaire ou un upload n’est pas fiable parce qu’une interface TypeScript affirme sa forme. C’est pour cela que mon admin utilise aussi Zod, qui effectue une validation réelle des données à l’exécution. (zod.dev)
Je ne prévois donc pas de remplacer une de ces quatre briques maintenant. Mon prochain travail reste plus concret : maintenir le script de déploiement corrigé le 14 août et vérifier que les prochaines modifications d’images passent bien par la purge prévue. Si cette chaîne recommence à cacher son état, ce sera le prochain endroit à ouvrir.