Windows Server 2016 ne sera plus pris en charge à partir de janvier 2027
Il n’y a qu’une date à retenir. Le support étendu de Windows Server 2016 prend fin le 12 janvier 2027. Le support standard avait déjà pris fin le 11 janvier 2022. Depuis, le système recevait uniquement des correctifs de sécurité. Après janvier 2027, il ne recevra même plus ces correctifs.
Ce calendrier n’a rien d’une surprise. Les versions de Windows Server issues du canal de maintenance à long terme ont un cycle de vie fixé à dix ans : cinq ans de support standard et cinq ans de support étendu. La date était connue dès la sortie du système. Pourtant, presque personne ne l’inscrit dans le calendrier de l’entreprise.
Le véritable piège, c’est que le serveur démarrera normalement le 13 janvier 2027. Rien ne s’éteindra et aucun avertissement ne s’affichera sur l’écran de connexion. Les applications fonctionneront comme la veille. Une seule chose changera, de manière invisible. La prochaine vulnérabilité découverte dans ce système ne sera plus corrigée.
Il est utile de regarder au-delà d’une seule version. Le support étendu de Windows Server 2019 court jusqu’au 9 janvier 2029. Le support standard de Windows Server 2022 prend fin le 13 octobre 2026 et son support étendu se poursuit jusqu’au 14 octobre 2031. Si vous achetez actuellement un nouveau serveur, ces dates ont une incidence directe sur le choix de la version du système.
Un serveur sans correctifs est un problème pour toute l’entreprise
Microsoft décrit clairement les conséquences. La fin du support signifie la fin des correctifs et des bulletins de sécurité. Cela peut entraîner des problèmes de sécurité et de conformité, ainsi que mettre en danger les applications métier. Cette phrase provient de la documentation de l’éditeur. Il ne s’agit pas de l’interprétation d’un prestataire.
En pratique, tout commence par des questions auxquelles quelqu’un doit répondre par écrit. Un audit demande si les systèmes utilisés sont toujours pris en charge par leur éditeur. Lors du renouvellement d’une cyberassurance, il faut remplir un questionnaire dans lequel la même question apparaît généralement. Les grands clients la posent dans leurs questionnaires destinés aux fournisseurs. Une réponse négative clôt rarement le sujet immédiatement, mais elle ouvre toujours une discussion sur les conditions.
Il existe un autre aspect que l’on oublie facilement. Les éditeurs de logiciels métier précisent dans leurs exigences les systèmes sur lesquels leur produit est pris en charge. Lorsqu’un système disparaît de cette liste, toute demande adressée à leur assistance technique se termine par une invitation à effectuer une mise à niveau. Un incident qui aurait normalement nécessité une journée se transforme alors en projet pour tout un trimestre.
Reste l’aspect le plus concret. Plus un système reste longtemps sans correctifs, plus il devient difficile d’y intervenir par la suite. Le nombre d’éléments à traiter pendant une seule fenêtre de maintenance augmente : le système, les pilotes, l’application, la base de données et parfois le matériel. Une migration menée sous la pression d’un incident se déroule tout autrement qu’une migration planifiée six mois à l’avance.
Commencez par l’état des lieux, pas par la décision
Avant de choisir entre une mise à niveau et le cloud, il faut savoir combien de machines sont concernées. Dans beaucoup d’entreprises, la première réponse est deux ou trois. Après consultation de l’hyperviseur, il s’avère qu’il y en a huit. Les serveurs sous Windows Server 2016 sont rarement les plus visibles. Il s’agit plus souvent de machines auxquelles personne ne touche, car une seule application y fonctionne et tout le monde redoute d’intervenir. Pour chaque machine, l’état des lieux doit répondre à plusieurs questions :
- quelle version et quelle édition exactes du système sont installées
- quels rôles remplit cette machine, par exemple contrôleur de domaine, serveur de fichiers et d’impression, serveur d’applications ou base de données
- quelle application ou quel processus de l’entreprise s’exécute sur cette machine et qui l’utilise
- s’il s’agit d’une machine physique ou virtuelle et sur quel hyperviseur elle fonctionne
- quel est le statut des licences et si l’entreprise dispose d’une Software Assurance active ou d’un abonnement adapté
- qui, du côté de l’éditeur du logiciel, est responsable de l’application qui s’y exécute
Il convient de vérifier séparément les équipements qui ne sont pas officiellement des serveurs. Les systèmes de contrôle d’accès, les enregistreurs de vidéosurveillance, les automates de machines de production et les équipements livrés avec un logiciel préinstallé intègrent souvent Windows Server. Tous ne peuvent pas être mis à niveau, mais il faut savoir qu’ils sont présents et prévoir une protection distincte.
Lorsque vous recensez les serveurs, recensez aussi les bases de données. Le calendrier y est encore plus serré. Le support étendu de SQL Server 2016 a pris fin le 14 juillet 2026. Cette échéance est donc déjà passée. SQL Server 2017 l’atteindra le 12 octobre 2027 et SQL Server 2019 seulement le 8 janvier 2030. Notez les versions des instances avec les systèmes, car la base de données et le système sur lequel elle repose sont très souvent remplacés dans le cadre d’un même projet.
Première option, la mise à niveau sur place
C’est l’option la plus simple à décrire et la plus souvent choisie. Vous installez un système plus récent sur la même machine, tout en conservant les rôles, les paramètres et les données. Depuis Windows Server 2016, vous pouvez ainsi passer directement aux versions 2019, 2022 ou 2025. Microsoft encadre par ailleurs l’ampleur du saut autorisé. Si la cible est la version 2025, vous pouvez franchir jusqu’à quatre versions en une seule fois. Si la cible est la version 2022 ou une version antérieure, la limite est de deux versions. Dans un cluster, la règle est plus stricte. La mise à niveau s’effectue alors une version à la fois.
Voici les contraintes. Tous les rôles ne peuvent pas être conservés lors d’une mise à niveau sur place. Il faut donc le vérifier pour la configuration concernée, sans partir du principe que cela fonctionnera. Un contrôleur de domaine suit ses propres règles et son propre ordre d’intervention. Il n’est pas possible de passer d’une installation Server Core à une installation avec interface graphique, ni de faire l’inverse pendant cette opération. Si la machine utilise NIC Teaming, cette fonction doit être désactivée avant la mise à niveau, puis réactivée après. Un système démarré depuis un fichier VHD ne peut pas du tout être mis à niveau de cette manière.
Il existe aussi un coût que les clients découvrent souvent à la fin. Chaque mise à niveau de Windows Server nécessite une licence distincte. Il ne s’agit pas d’un passage gratuit d’une ancienne version à une nouvelle, comme pour le système installé sur l’ordinateur d’un salarié.
Cette voie présente aussi un inconvénient moins visible. Une mise à niveau sur place transfère vers le nouveau système tout ce qui s’est accumulé pendant dix ans. D’anciennes exceptions de pare-feu, des comptes de service dont personne ne se souvient et des paramètres ajoutés pour un seul après-midi en 2018. Il arrive que ces éléments provoquent ensuite des pannes que personne ne parvient à relier à la mise à niveau. Une sauvegarde réalisée avant de commencer et un plan de retour arrière testé ne sont pas des options. Ce sont des conditions préalables.
Deuxième option, un nouveau serveur et la migration des rôles
Vous effectuez une installation propre du nouveau système, puis vous migrez les rôles, les données et les autorisations. Cela demande plus de travail qu’une mise à niveau sur place, mais le résultat est une machine sans le passif de l’ancienne installation. C’est généralement la seule voie lorsque le matériel arrive de toute façon en fin de vie, lorsque l’éditeur du logiciel ne prend pas en charge l’application sur un système plus récent dans le cadre de la même installation ou lorsqu’un des rôles ne peut pas être mis à niveau.
Cette voie offre aussi une possibilité que la mise à niveau sur place ne donne pas. L’ancien serveur reste en service à côté du nouveau jusqu’à la bascule. Le retour arrière est donc naturel. Vous revenez au système qui fonctionne toujours. Avec une mise à niveau sur place, revenir en arrière signifie toujours restaurer une sauvegarde. Cela entraîne une interruption plus longue et davantage de stress.
Voici les contraintes. Il faut disposer d’un emplacement pour installer la seconde machine, même s’il ne s’agit que d’une machine virtuelle utilisée pendant la migration. Il faut aussi passer en revue les éléments que l’on oublie le plus facilement : les entrées DNS, les certificats, les partages et les autorisations, les tâches planifiées, les comptes de service, les intégrations avec d’autres systèmes et les imprimantes. Il faut également définir avec l’éditeur du logiciel comment transférer la licence et l’installation vers la nouvelle machine.
Le coût principal n’est pas le matériel. C’est le temps nécessaire à une bascule maîtrisée et aux tests qui la précèdent. Une migration des rôles réalisée en une nuit sans tests représente le même travail, mais avec une issue moins favorable.
Troisième option, la migration vers le cloud
La troisième possibilité consiste à transférer le serveur vers le cloud, le plus souvent vers Azure ou Google Cloud. La machine reste une machine. Elle est simplement hébergée chez un fournisseur cloud. Le modèle de coûts change également. Un achat de matériel pour plusieurs années est remplacé par une facture mensuelle. Une décision d’augmentation de capacité ne nécessite plus de commande.
Dans ce scénario précis, un point plaide clairement en faveur d’Azure. Les correctifs du programme Extended Security Updates sont gratuits pour les machines virtuelles dans Azure, alors qu’ils doivent être achetés en dehors d’Azure. Si votre entreprise envisage déjà le cloud, la fin du support est un bon moment pour aborder le sujet.
Voici les contraintes. Toutes les applications ne sont pas adaptées au cloud. Les systèmes qui communiquent avec des équipements au bureau ou sur un site de production ont besoin d’une bonne connexion et d’un temps de réponse prévisible. Parfois, ils doivent tout simplement rester sur site. Les licences dans le cloud se calculent différemment des licences sur votre propre matériel. Il est utile de faire ce calcul avant la migration, et non après la première facture.
Il existe aussi un piège dans lequel il est facile de tomber. Le transfert d’un ancien système vers le cloud ne le rajeunit pas. Windows Server 2016 exécuté dans le cloud reste Windows Server 2016 et son support prend toujours fin en janvier 2027. Une répartition est donc généralement pertinente. Certaines machines migrent vers le cloud, tandis que d’autres restent sur site avec un système plus récent. Pour chacune, la décision dépend de ce qui y fonctionne, et non d’une règle unique appliquée à toute l’entreprise.
ESU permet de gagner trois ans, mais ce n’est pas une solution
Si l’échéance ne peut pas être respectée, il reste la possibilité de recourir au programme Extended Security Updates. Microsoft le présente comme une option de dernier recours et comme une mesure transitoire pour la durée de la migration, et non comme une solution pérenne. Le programme couvre les correctifs destinés aux vulnérabilités classées critiques ou importantes, pendant trois ans au maximum à compter de la fin du support étendu.
Il est également utile de savoir ce qu’ESU n’apporte pas. Le programme ne propose aucune nouvelle fonctionnalité, aucun correctif sans rapport avec la sécurité et aucune modification à la demande. L’assistance technique habituelle n’est pas incluse non plus. Le programme couvre uniquement les correctifs. Dans les faits, l’assistance se limite à leur déploiement et aux problèmes qu’ils provoquent, pas aux problèmes généraux du système. ESU ne prolonge pas le cycle de vie du produit. Il ne fait que différer une conséquence précise.
À cela s’ajoutent des conditions qui surprennent lors du premier devis. Hors Azure, les correctifs doivent être achetés. Une Software Assurance active ou un abonnement adapté est nécessaire. Vous ne pouvez pas passer directement à une année ultérieure. Pour acheter la deuxième année, il faut avoir acheté la première. Si vous rejoignez le programme plus tard, vous payez aussi les mois déjà écoulés. Après la troisième année, les correctifs s’arrêtent tout simplement et vous vous retrouvez exactement au même point.
La conclusion pratique est simple. ESU se justifie si vous l’utilisez pour acheter en connaissance de cause le temps nécessaire pour terminer une migration déjà engagée et assortie d’une date de fin. Si vous vous en servez seulement pour reporter le sujet d’un an, ce n’est qu’une façon plus coûteuse de temporiser.
Que faire avant qu’il ne soit trop tard
Il reste moins de six mois avant janvier 2027, et certaines échéances liées aux bases de données sont déjà passées. Ce délai reste suffisant pour mener la migration sereinement, dans les fenêtres de maintenance que vous choisissez vous-mêmes. Mais seulement si l’état des lieux est réalisé maintenant, et non au trimestre prochain.
Voici la marche à suivre qui a fait ses preuves :
- dressez l’inventaire des machines et des versions des systèmes, ainsi que des instances SQL Server
- notez pour chaque machine ce qui y est exécuté et qui en dépend
- choisissez une approche distincte pour chaque machine, car une règle unique ne fonctionne presque jamais pour toutes
- validez avec les éditeurs de logiciels les systèmes sur lesquels ils prennent en charge leurs produits
- définissez les fenêtres de maintenance et le plan de retour arrière avant toute modification
- décidez seulement à la toute fin si vous avez besoin d’ESU et pour combien de temps
Si vous ne savez pas par où commencer, le plus simple est d’examiner ce qui se trouve réellement dans la salle des serveurs et d’établir une liste réaliste des échéances pour chaque machine. Deux échanges suffisent généralement pour voir quels serveurs doivent être traités en priorité et lesquels peuvent attendre l’année suivante. Nous réalisons volontiers cet état des lieux avec votre équipe.