Le 14 août, j’ai remplacé une image dans public/, relancé le build puis redémarré le portfolio avec pm2. L’ancienne image continuait pourtant d’être servie.
Le fichier était correct. Le déploiement aussi. C’était le cache d’images de Next.js, conservé dans .next/cache/images, qui survivait aux deux opérations. J’ai ajouté sa suppression au script de déploiement.
C’est le genre de problème que ma stack produit. Pas parce qu’elle est mauvaise, mais parce que j’ai choisi de garder beaucoup de responsabilités chez moi. Mes outils ne suppriment pas la maintenance. Ils déterminent surtout les tâches que je vais devoir assurer moi-même.
## SQLite me laisse gérer un fichier
Le contenu de mon portfolio vit dans SQLite, derrière Prisma. Pour mon projet actuel, la base est sur la même machine que l’application et sert principalement le site et son panneau d’administration.
SQLite correspond bien à cette forme. La base tient dans un fichier, sans processus de base de données séparé à administrer. La documentation de Prisma reflète directement ce modèle avec une URL qui pointe vers un chemin local.
Avec Postgres, je gagnerais un vrai serveur de base de données, une meilleure séparation et plus de marge pour les accès concurrents. J’ajouterais aussi un service supplémentaire à installer, configurer et surveiller. Aujourd’hui, mon portfolio ne justifie pas cette couche.
La limite n’est pas cachée. SQLite n’autorise qu’un seul écrivain à la fois. Si le portfolio devenait très chargé en écritures ou devait tourner sur plusieurs serveurs, le fichier local passerait d’avantage à contrainte. Pour le moment, mon admin maison et le site public ne produisent pas ce besoin.
Je garde donc SQLite tant que la réalité du projet reste celle d’une application sur une machine. Pas parce que Postgres serait trop compliqué dans l’absolu.
## Mon VPS me laisse gérer la machine
Vercel automatise les déploiements liés à Git et ses fonctions exécutent du code serveur sans demander de gérer directement le serveur. C’est précisément une partie de ce que je ne veux pas déléguer sur mes projets personnels.
Mon portfolio et mon dashboard tournent sur mon VPS. J’y garde l’application, la base SQLite, les fichiers envoyés par l’admin et le reste de la chaîne de déploiement. pm2 maintient les processus Node en fonctionnement et fournit les commandes dont j’ai besoin pour les redémarrer ou consulter leurs logs. Sa documentation reste volontairement proche de ce rôle de gestionnaire de processus.
En échange, personne ne purge un cache à ma place. Je dois comprendre ce que fait npm run build, ce que conserve Next.js et ce que pm2 restart redémarre réellement. Je dois aussi maintenir le serveur, le reverse proxy et mes scripts.
C’est utile parce que je veux apprendre cette chaîne complète. Ce serait un mauvais compromis si mon objectif principal était de publier le plus vite possible sans toucher à l’infrastructure. Ce serait également fragile si mes projets exigeaient plusieurs machines ou une disponibilité que je ne peux pas assurer seul.
## Le CSS maison me laisse gérer les conventions
Le portfolio utilise des modules CSS écrits à la main. Next.js leur donne une portée locale grâce à des noms de classes générés, comme l’explique sa documentation sur les CSS Modules. Pour le reste, je garde la cascade, les sélecteurs, les variables et la mise en page directement visibles.
Ce choix est plus lent qu’un framework CSS. Je dois nommer mes classes, éviter les répétitions et décider moi-même de ce qui mérite une règle globale. En contrepartie, la direction terminal du portfolio n’est pas assemblée depuis un vocabulaire de classes utilitaires. Chaque style correspond à une décision que je peux retrouver dans le fichier du composant.
La limite apparaît dès que l’interface grandit. Sans conventions solides, le CSS maison peut accumuler des valeurs presque identiques et des composants qui réinventent le même espacement. Je ne gagne pas automatiquement un système de design parce que j’ai refusé un framework.
## TypeScript me laisse gérer les frontières réelles
J’utilise TypeScript partout où mon écosystème le permet : composants React, routes serveur, logique d’administration et scripts du projet. Son vérificateur statique peut détecter certaines incohérences avant l’exécution. Sur un projet où le front et le serveur partagent le même langage, cela réduit les changements faits à moitié.
Mais un type ne contrôle pas une requête reçue en production. C’est pour cela que mon admin utilise aussi zod pour la validation. TypeScript décrit ce que mon code croit manipuler. Il ne rend pas automatiquement fiables les données venant d’un formulaire, d’un token ou d’un upload.
Ma stack est donc une liste de tâches acceptées : surveiller un fichier SQLite, maintenir une machine, organiser mon CSS et définir mes types sans les confondre avec une validation réelle.
La prochaine tâche est déjà dans le dépôt : continuer à durcir le script de déploiement après le problème de cache, sans transformer chaque incident local en nouvelle couche permanente.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.