Votre application tourne-t-elle sur un socle en fin de vie ?

Votre application fonctionne. Vos clients s'y connectent, les commandes passent, personne ne se plaint. Et pourtant, elle peut être exposée à une faille connue de tous, publiée, documentée, que plus personne ne corrigera jamais. Ce risque porte un nom : le socle en fin de vie.

Qu'est-ce que le « socle » d'une application ?

Une application web ne tourne jamais seule. Elle repose sur plusieurs couches que votre prestataire n'a pas écrites :

• le moteur d'exécution, par exemple Node.js, qui fait tourner le code côté serveur ;
• le framework, par exemple Next.js, qui organise les pages, la navigation et la sécurité des accès ;
• les dépendances, des centaines de petites bibliothèques téléchargées automatiquement.

2026 : deux fins de vie qui concernent beaucoup d'applications

Un exemple concret : la faille CVE-2025-29927

En mars 2025, une faille critique a été publiée sur Next.js. Elle permettait, en ajoutant un simple en-tête à une requête, de contourner le middleware, c'est-à-dire la couche qui vérifie souvent si un visiteur a le droit d'accéder à une page. Autrement dit : entrer dans un espace réservé sans être connecté.

La faille a été corrigée rapidement… dans les versions maintenues. Les applications restées sur une ancienne version ne sont protégées que si quelqu'un a fait la mise à jour. Nous l'avons constaté nous-mêmes lors d'un audit : sur une version ancienne, le contournement fonctionnait réellement. Ce n'est pas un risque théorique.

Pourquoi « ça marche » ne veut pas dire « c'est sûr »

Une application sur un socle en fin de vie ne tombe pas en panne. Elle continue de fonctionner exactement comme avant. C'est ce qui rend le problème invisible :

• aucune alerte ne se déclenche le jour où la maintenance s'arrête ;
• les failles découvertes ensuite sont publiées, donc connues des attaquants ;
• les outils d'attaque automatisés testent ces failles sur tout Internet, sans cibler personne en particulier.

Comment savoir si votre application est concernée

Posez trois questions à votre prestataire :

• Sur quelle version de Node.js tourne l'application en production ? La réponse doit être une version maintenue (22 ou 24 en 2026).
• Quelle version du framework est utilisée ? Pour Next.js, tout ce qui est antérieur à la 16 mérite un plan de migration.
• Les versions des dépendances sont-elles figées ? Une application sérieuse installe des versions précises, vérifiées, et jamais « la dernière disponible » sans contrôle.

Migrer sans casser : la méthode

Une montée de version n'est pas un simple clic. Elle se prépare :

• une seule variable à la fois : on change le moteur, on vérifie, puis le framework, on vérifie. Tout changer d'un coup rend impossible de savoir ce qui a cassé ;
• mesurer avant et après : temps de réponse, parcours critiques (connexion, paiement, formulaires), erreurs remontées. Sans point de comparaison, « ça marche » ne prouve rien ;
• garder un retour arrière prêt : l'ancienne version doit pouvoir être remise en service en quelques minutes si un problème apparaît ;
• sauter les versions condamnées : inutile de passer par une version qui mourra dans quelques semaines.

Ce que nous faisons pour nos clients

Chez Qualitech-Conseil, la maintenance ne se limite pas à corriger les bugs signalés. Nous suivons le calendrier de fin de vie de chaque brique utilisée par les applications que nous hébergeons, et nous planifions les migrations avant l'échéance, pas après l'incident.

Toutes nos nouvelles applications partent sur Node.js 24 et Next.js 16, avec des dépendances figées et un délai de sécurité avant d'adopter toute nouvelle version publiée.

Votre application a été développée il y a plus de deux ans ? Vous ne savez pas sur quelle version elle tourne ? Contactez-nous pour un diagnostic du socle : en une journée, vous saurez où vous en êtes et ce qu'il faut prévoir.