Fin de support Windows Server 2016 : le 12 janvier 2027, et que faire de l'application qui tourne dessus

En bref : la fin de support de Windows Server 2016 tombe le 12 janvier 2027, avec un dernier correctif de sécurité ce jour-là. Ses équivalents poste de travail, Windows 10 Entreprise LTSB 2016 et IoT Entreprise 2016 LTSB, sont déjà en fin de support depuis le 13 octobre 2026. Après janvier, chaque nouvelle faille reste ouverte, sauf à payer à Microsoft des mises à jour de sécurité étendues (ESU) dont le prix pour Server 2016 n'est pas encore publié. Pour beaucoup de PME, le serveur est la partie facile. La partie difficile, c'est l'application métier installée dessus : un ERP, un outil de devis, un intranet ou une base Access développée il y a des années. Voici les dates, ce que les ESU couvrent vraiment, et les trois façons d'en sortir.

---

Les dates

Le support standard de Windows Server 2016 a pris fin le 11 janvier 2022. Depuis, il ne reçoit plus que des correctifs de sécurité. Le 12 janvier 2027, ceux-là s'arrêtent aussi.

Ce que les ESU vous achètent

Microsoft vend des Extended Security Updates (ESU) pendant trois ans au maximum après la fin de support. Selon son chef de produit, elles n'incluent « ni nouvelles fonctionnalités, ni correctifs de qualité, ni demandes de modification », et ne prolongent pas le support technique. Ce sont des correctifs de sécurité, rien de plus.

Le prix pour Windows Server 2016 n'était pas publié au moment où nous écrivons. Les seuls chiffres fermes pour 2016 concernent l'édition poste de travail LTSB : 61 dollars par poste la première année, 45 dollars si le poste est géré par Intune ou Windows Autopatch, doublés chaque année, et cumulatifs : commencer en deuxième année oblige à payer aussi la première. Il faut s'attendre à la même logique de doublement côté serveur.

Les ESU valent le coup quand on a un plan de sortie daté. Achetées à la place d'un plan, c'est un loyer qui double chaque année pour un serveur qui ne s'améliore pas.

D'abord, savoir ce que fait vraiment ce serveur

Avant de choisir, faites la liste de ce qui tourne dessus. Dans les PME avec lesquelles nous travaillons, un « serveur 2016 » est en général l'une de deux choses, et elles n'ont pas la même réponse.

De l'infrastructure Windows : Active Directory, partages de fichiers, impression, Exchange, bureau à distance. C'est une mise à niveau Windows ou un passage à Microsoft 365, et c'est le métier de votre infogérant. Ce n'est pas le nôtre, et nous vous le dirons.

Une application métier : une application web .NET ou PHP sous IIS, une base SQL Server, une tâche planifiée qui envoie les factures, un frontal Access utilisé tous les jours par trois personnes. C'est là qu'est le risque, parce que :

• elle tourne souvent sur des versions anciennes de sa propre pile (.NET Framework, SQL Server, PHP), qui ont leur propre calendrier de fin de support : nous avons détaillé celui de PHP, Symfony et AngularJS dans cet article ;
• la personne qui l'a écrite est souvent partie, et personne ne sait ce qu'une mise à niveau du système va casser ;
• elle est souvent joignable depuis Internet, pour un portail client ou une équipe terrain, donc un serveur non corrigé est directement exposé.

Trois options pour l'application

1. Mettre à niveau vers Windows Server 2022 ou 2025. Le moins de changement, et le bon choix quand l'application est saine, documentée et liée à Windows. Il faut de nouvelles licences, un environnement de test, et quelqu'un capable de dire si l'application fonctionne encore après. Le risque : vous gardez tels quels tous les autres composants anciens.

2. Acheter des ESU et préparer la migration. Le bon choix quand l'application est critique et que la migration ne peut pas être faite avant janvier. Fixez une date de sortie avant de signer : la deuxième année coûte le double, la troisième encore le double.

3. Sortir l'application du serveur. Mettre l'application dans un conteneur, la base sur un service managé, et le serveur hors du tableau. C'est ce que nous faisons : nous reprenons le code, nous l'auditons, et nous le migrons vers un hébergement que nous exploitons, où le système, les correctifs et les sauvegardes sont notre problème plutôt que le vôtre. Nos applications tournent sur Google Cloud dans des conteneurs, sans aucune interface d'administration joignable depuis Internet, avec des dépendances surveillées par Dependabot et une infrastructure décrite en code. Le détail est sur notre page sécurité.

C'est plus de travail qu'une mise à niveau la première fois. Ensuite, il n'y a plus de « serveur 2016 » à voir arriver en fin de vie, parce que plus personne ne possède de serveur.

Comment décider cette semaine

1. Listez ce qui tourne sur chaque serveur 2016. Si la réponse est « personne n'est sûr », c'est le premier constat.
2. Vérifiez ce qui est joignable depuis Internet. Un serveur non corrigé derrière un portail public, c'est le cas urgent.
3. Vérifiez les versions sous l'application : .NET, SQL Server, PHP, le framework. Certaines ont leur propre fin de support, avant ou après janvier.
4. Trouvez qui peut modifier le code. Si personne ne le peut, une mise à niveau du système est un pari, et rester aussi.
5. Choisissez une option et une date. Si cette date tombe après le 12 janvier 2027, budgétez les ESU jusqu'à elle.

Si les étapes 3 et 4 restent sans réponse, un audit court est le bon point de départ : vous obtenez la liste de ce qui tourne, de ce qui est exposé et de ce qui n'est plus maintenu, avec un ordre de travail.

À lire aussi : la fin de support PHP, Symfony et AngularJS, la TMA, avec les prix, et les frigos de supermarchés piratés et les interfaces d'administration sur Internet.