Le 20 juillet, Next.js a publié sa première mise à jour de sécurité mensuelle. Les versions 16.2.11 et 15.5.21 corrigent quatre vulnérabilités classées élevées et cinq classées moyennes.
Le détail important pour moi n’est pas le nombre de correctifs. C’est le mot mensuelle.
Next.js avait annoncé une semaine plus tôt un nouveau processus de publication des correctifs de sécurité, avec un calendrier plus régulier et une annonce préalable. Ça transforme une alerte exceptionnelle en rendez-vous de maintenance.
Sur Vercel, une partie de l’exploitation disparaît derrière la plateforme. Mes projets, eux, tournent sur mon VPS. Le portfolio comme le dashboard passent par mon propre déploiement. Si une version doit être corrigée, personne ne va le faire à ma place.
## Avant, mes mises à jour suivaient surtout mes changements
Mon portfolio est encore en mouvement. Ces derniers jours, j’ai ajouté le blog, la newsletter, les notifications SMTP, les uploads et l’ISR. Chaque modification passe par le dépôt, le build, Prisma quand le schéma change, puis le redémarrage du processus avec pm2.
Dans ce flux, une dépendance pouvait être mise à jour parce qu’une fonctionnalité l’exigeait ou parce que le build ne passait plus. La maintenance de sécurité n’avait pas encore sa propre place visible.
Le nouveau calendrier de Next.js ne modifie aucune ligne de mon application. Il ne corrige pas mon origine publique dans les emails. Il ne règle pas nginx, pm2 ou la manière dont mes images ajoutées après le démarrage sont servies. Mais il me donne une date extérieure à mes commits.
C’est utile parce qu’un projet personnel en production dérive facilement vers une logique simple : tant que le site répond, je n’y touche pas. Sur un portfolio statique, ce serait déjà discutable. Sur le mien, il y a un panneau d’administration, une authentification, des uploads, un formulaire de contact, une newsletter et des routes serveur. Le framework n’est pas seulement là pour afficher du CSS.
## Je ne vais pas installer next@latest automatiquement
La réponse facile serait d’ajouter une mise à jour automatique au déploiement. Je ne vais pas faire ça.
Mon VPS héberge des projets que j’utilise vraiment. Le dashboard s’ouvre des dizaines de fois par jour. Le portfolio contient maintenant assez de routes et de comportements serveur pour qu’une montée de version non testée puisse casser autre chose que la page d’accueil.
La politique de support de Next.js distingue actuellement Next.js 16 en Active LTS et Next.js 15 en Maintenance LTS. Les versions plus anciennes ne sont plus dans la fenêtre normale de support. Avant de décider quoi installer, je dois donc commencer par une information très basique : quelle version exacte tourne dans chacun de mes dépôts ?
Ensuite seulement, la décision se sépare en deux cas.
- Si le projet est déjà sur une branche supportée, je peux viser le correctif indiqué, lancer le build et vérifier les routes importantes avant de déployer.
- S’il est sur une branche plus ancienne, ce n’est plus un simple patch. C’est une migration à préparer, avec les changements du framework entre les deux versions.
Cette distinction évite de mélanger sécurité et envie de nouveauté. Je n’ai pas besoin des dernières fonctions de navigation ou de cache pour justifier un correctif. À l’inverse, un correctif urgent ne rend pas automatiquement raisonnable une migration majeure lancée sans vérifier le projet.
## Ce que ça change vraiment sur mon VPS
Je ne change pas de framework. Next.js reste adapté au dashboard et au portfolio : composants React, rendu serveur quand j’en ai besoin, routes intégrées et un seul déploiement Node.
Ce qui change, c’est mon calendrier.
Une publication mensuelle identifiable est plus simple à intégrer qu’une surveillance vague de toutes les dépendances. Je peux vérifier les versions installées, lire l’avis officiel, mettre à jour sur une branche, construire, puis déployer avec la même chaîne que mes autres changements.
Je garde aussi une limite claire : je ne vais pas transformer chaque publication mensuelle en refonte du projet. Si le correctif concerne ma branche, je le prends. S’il impose une migration, je sépare cette migration du reste au lieu de la cacher dans un npm update géant.
Ma prochaine tâche est donc courte et peu spectaculaire : relever les versions de Next.js du portfolio et du dashboard, les comparer aux branches encore supportées, puis préparer le patch correspondant. Le nouveau processus de Next.js ne m’oblige pas à basculer de stack. Il m’enlève surtout une excuse pour attendre qu’un problème apparaisse dans les logs.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.