Je n’ai pas construit ma stack en cherchant l’outil le plus simple pour chaque ligne du projet. Sinon, je n’aurais probablement ni panneau d’admin maison, ni VPS à maintenir, ni autant de CSS écrit à la main.
Mon choix est moins régulier que ça. Je retire certaines couches et j’en garde volontairement d’autres. SQLite m’évite d’administrer un serveur de base de données. À l’inverse, mon VPS m’oblige à gérer le déploiement. Ce n’est pas contradictoire. Je choisis surtout où je veux placer la difficulté.
## SQLite retire une responsabilité qui ne m’intéresse pas encore
Le portfolio stocke son contenu dans SQLite via Prisma. Pour ce projet, les données et l’application vivent sur la même machine. Je n’ai pas plusieurs serveurs qui doivent écrire en parallèle, ni plusieurs applications qui se connectent directement à une base distante.
Dans ce contexte, Postgres m’ajouterait un service séparé à installer, configurer et maintenir. Ce serait utile si mon architecture le demandait. Aujourd’hui, ce serait surtout une couche de plus.
La documentation de SQLite distingue clairement ce cas des bases client-serveur : SQLite vise le stockage local d’une application et ne permet qu’un seul écrivain à un instant donné. Cette limite existe. Elle correspond simplement à mon usage actuel.
Je ne choisis donc pas SQLite parce que Postgres serait trop compliqué à apprendre. Je le choisis parce que je n’ai pas de problème qui exige Postgres. Je peux garder du SQL, des migrations et un modèle de données propre sans exploiter un serveur de base séparé.
La contrepartie est claire : si le portfolio devient très intensif en écritures ou doit tourner sur plusieurs machines, le fichier local cessera d’être le bon centre de gravité.
## Le VPS ajoute une responsabilité que je veux garder
Pour le déploiement, je fais le choix inverse. Une plateforme comme Vercel peut créer automatiquement un déploiement depuis un dépôt Git et fournir des environnements de prévisualisation. C’est exactement le type de chaîne présenté dans sa documentation officielle.
Je préfère pourtant mon VPS pour le portfolio et le dashboard.
Je veux savoir où tourne le processus Node, où arrivent les requêtes, où sont écrits les fichiers et comment l’application redémarre. Je veux aussi posséder la chaîne complète, pas seulement pousser un commit et attendre une URL.
Cela me coûte du temps. Quand le serveur a un problème, il n’y a pas de plateforme entre lui et moi. Je dois regarder le processus, les logs, le reverse proxy ou les fichiers présents sur la machine. Pour mes projets personnels, ce travail fait partie du projet.
J’utilise pm2 parce qu’il couvre la partie précise dont j’ai besoin : démarrer l’application, consulter son état, lire ses logs et la relancer. Il peut également restaurer une liste de processus après un redémarrage avec pm2 startup et pm2 save, comme l’explique son guide de démarrage.
pm2 n’efface pas l’exploitation du serveur. Il évite seulement que mon application dépende d’un terminal laissé ouvert. Le reste reste chez moi.
## Le CSS maison ralentit la construction, volontairement
Sur le portfolio, je n’utilise pas de framework CSS. J’écris des modules CSS à la main. Next.js prend directement en charge les fichiers .module.css et leur applique une portée locale, sans que j’ajoute une autre convention par-dessus, comme le décrit la documentation des CSS Modules.
C’est plus lent que d’assembler des classes utilitaires que je connais déjà. Je dois décider des espacements, des breakpoints, des variables et des états. Je peux aussi créer des règles incohérentes ou dupliquer une valeur.
Mais la mise en page du portfolio fait partie de ce que je voulais travailler. Le thème terminal ne vient pas d’un template. Si je masque cette couche derrière un framework, je termine plus vite, mais je retire aussi une partie de l’exercice.
Je ne ferais pas automatiquement ce choix sur chaque projet. Ici, la lenteur est acceptable parce que le CSS est une partie du produit, pas seulement son emballage.
## TypeScript évite de changer de langage à chaque couche
TypeScript est le choix le moins expérimental de l’ensemble. Mon front, mes routes serveur et mon administration restent dans le même écosystème. Les types sont supprimés à la compilation et ne changent pas le comportement JavaScript à l’exécution, ce que rappelle le manuel TypeScript.
Sa limite est justement là. TypeScript peut vérifier ce que mon code affirme, pas garantir qu’une requête externe ou un formulaire réel respecte cette affirmation. C’est pour cela que le portfolio utilise aussi zod pour valider les données à l’exécution.
Je garde donc TypeScript partout pour réduire les changements de contexte, pas pour prétendre que les erreurs deviennent impossibles.
Pour le prochain widget du dashboard ou la prochaine évolution de l’admin, je repartirai probablement avec les mêmes choix. Mais je vérifierai encore la même chose : quelle couche est nécessaire, et laquelle je conserve seulement parce que je veux mettre les mains dedans.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.