Fin de support 2026-2027 : le calendrier des technos à migrer

En bref : entre novembre 2026 et octobre 2027, plusieurs briques très répandues arrivent en fin de support : .NET 8 et .NET 9 le 10 novembre 2026, PHP 8.2 le 31 décembre 2026, Windows Server 2016 le 12 janvier 2027, Node.js 22 le 30 avril 2027, puis SQL Server 2017 le 12 octobre 2027. Une application qui repose sur l’une d’elles continue de fonctionner, mais ne reçoit plus de correctifs de sécurité.

Une fin de support logiciel ne fait pas de bruit. Le jour J, rien ne casse. Le problème arrive plus tard, quand une faille est publiée sur un composant que plus personne ne corrige. Voici le calendrier des échéances qui touchent le plus souvent les applications métier, et la façon de décider, pour chacune, entre mettre à jour, payer un support étendu ou migrer.

Que change concrètement une fin de support logiciel ?

Quand un éditeur arrête le support d’une version, il cesse de publier des correctifs, y compris pour les failles de sécurité. L’application tourne toujours, mais chaque vulnérabilité découverte ensuite reste ouverte. Or les failles d’un composant populaire sont documentées publiquement, souvent avec un exemple d’exploitation : il suffit ensuite de chercher les serveurs qui n’ont pas été mis à jour.

Il y a aussi un effet en cascade. Les bibliothèques que vous utilisez abandonnent à leur tour les anciennes versions : la prochaine mise à jour d’un module de paiement ou d’un pilote de base de données exigera un framework récent. Plus on attend, plus la montée de version devient un chantier.

Enfin, un composant sans support ressort dans presque tous les contrôles externes : audit de sécurité, test d’intrusion, questionnaire sécurité d’un grand client, préparation à NIS2. C’est souvent là que le sujet devient urgent, au pire moment. Nous détaillons ces risques dans notre article sur les risques de sécurité invisibles des applications anciennes.

Le calendrier 2026-2027

Les dates ci-dessous viennent des calendriers officiels des éditeurs, relevés le 5 novembre 2026 : politique de support .NET, versions de PHP supportées et cycle de vie de Windows Server 2016.

Les trois échéances des trois prochains mois

.NET 8 et .NET 9 : le 10 novembre 2026

Les deux versions s’arrêtent le même jour : .NET 8 au terme de ses trois ans de support long, .NET 9 au terme de son support standard. La cible est .NET 10, sortie en novembre 2025 et supportée jusqu’en novembre 2028. Depuis .NET 8, le passage consiste le plus souvent à changer la version cible du projet, mettre à jour les paquets NuGet et corriger les quelques API modifiées. Le vrai travail est la recette : tester les écrans et traitements critiques avant de redéployer.

Ne confondez pas avec le .NET Framework 4.x des anciennes applications Windows : il suit le cycle de vie de Windows et n’est pas concerné par cette date. Son passage vers .NET 10 est, lui, une vraie migration.

PHP 8.2 : le 31 décembre 2026

PHP 8.2 reçoit ses derniers correctifs de sécurité jusqu’au 31 décembre. Passer en 8.3 ne fait gagner qu’un an : visez directement PHP 8.4 ou 8.5. L’effort dépend des fonctions dépréciées que votre code utilise encore et, surtout, des bibliothèques tierces : un framework ou un module ancien peut bloquer la montée de version tant qu’il n’est pas mis à jour lui aussi. Un passage dans un outil d’analyse statique permet d’en dresser la liste avant de chiffrer.

Beaucoup d’hébergeurs laissent l’ancienne version disponible après la date. Rien ne vous force donc à migrer, et c’est justement le piège.

Windows Server 2016 : le 12 janvier 2027

La difficulté n’est pas le système lui-même mais ce qui est installé dessus : une application métier ancienne, un service Windows écrit il y a dix ans, un pilote ou un connecteur dont on n’a plus les sources. Avant de planifier la migration du serveur, vérifiez que chacun de ces éléments fonctionne sur Windows Server 2022 ou 2025. La démarche que nous avons décrite pour la fin de support de Windows Server 2012 reste valable.

Comment savoir si vos applications sont concernées ?

La réponse tient rarement dans un seul document. Les versions se cachent à plusieurs endroits : le système du serveur, l’environnement d’exécution (.NET, PHP, Node.js, Java), la base de données, le framework et les dizaines de bibliothèques tierces. Quelques commandes suffisent pour un premier relevé :

• dotnet --list-runtimes sur le serveur, ou la balise TargetFramework des fichiers .csproj ;
• php -v, et la contrainte php du fichier composer.json ;
• node -v, et le champ engines du package.json ;
• SELECT @@VERSION; sur SQL Server ;
• winver sur les serveurs Windows.

Reportez chaque résultat dans un tableau simple : application, composant, version, date de fin de support, responsable. Ce tableau devient votre feuille de route. Il sert aussi au budget de l’année : une échéance connue douze mois à l’avance se planifie, une échéance découverte lors d’un incident se subit.

Faut-il mettre à jour, payer un support étendu ou migrer ?

Pour chaque composant en fin de support, trois options existent.

Le support étendu est une solution d’attente, pas une stratégie. Il a du sens quand il finance le temps nécessaire à une migration déjà planifiée. Quand une application cumule plusieurs composants obsolètes, la question change de nature : il ne s’agit plus d’une mise à jour, mais de choisir comment moderniser l’application.

Un ordre de priorité simple : d’abord ce qui est exposé à Internet (sites, portails, API), ensuite ce qui manipule des données sensibles, enfin les outils internes.

Comment nous traitons une fin de support logiciel

Nous commençons par un inventaire des dépendances de l’application : versions, bibliothèques, échéances, vulnérabilités connues. Il débouche sur une liste courte et priorisée, avec pour chaque point l’effort estimé et le risque à ne rien faire. Ensuite seulement vient la montée de version, d’abord sur un environnement de test, avec une recette des traitements critiques avant toute mise en production.

Questions fréquentes

Mon application fonctionne très bien, pourquoi la toucher ?
Elle fonctionnera encore demain. Le risque n’est pas la panne mais la faille qui ne sera jamais corrigée, et la montée de version qui devient plus lourde chaque mois.

Combien de temps faut-il pour passer de .NET 8 à .NET 10 ?
Pour une application maintenue régulièrement, cela se compte le plus souvent en jours ou en semaines, recette comprise, pas en mois. Le chiffrage dépend surtout des bibliothèques utilisées et de la couverture de tests.

Mon hébergeur propose encore PHP 8.2 en 2027. Est-ce un problème ?
Oui. Que la version soit disponible ne veut pas dire qu’elle est corrigée. Après le 31 décembre 2026, les failles découvertes dans PHP 8.2 ne seront plus corrigées par le projet PHP.

Le support étendu payant de Microsoft est-il une bonne solution ?
Pour gagner du temps, oui. Comme solution durable, non : il coûte chaque année et s’arrête à une date fixe. Utilisez-le pour financer une migration planifiée.

Faut-il tout migrer en même temps ?
Non. Commencez par les applications exposées à Internet et celles qui traitent des données sensibles, puis traitez le reste dans l’ordre des échéances.

Vous ne savez pas quelles applications sont concernées ? Nous réalisons l’inventaire des dépendances de votre parc et vous remettons une liste priorisée des montées de version, avec l’effort estimé pour chacune.