Votre serveur a une date d'expiration : le 12 janvier 2027

Dans la plupart des PME québécoises, il y a un serveur dont personne ne parle. Il est dans un local au fond du corridor, parfois dans une garde-robe convertie, avec un onduleur qui bipe une fois par année. Il tourne sous Windows Server 2016. Il a été installé par quelqu'un qui n'est plus dans l'entreprise. Et il fonctionne — c'est précisément pour ça que le dossier n'est jamais monté sur le bureau de la direction.

Le 12 janvier 2027, ce serveur cesse de recevoir des correctifs de sécurité. Il ne s'éteindra pas. Il continuera de servir les fichiers, l'application de gestion et les ouvertures de session comme la veille. La seule chose qui change, c'est qu'à partir de cette date, chaque nouvelle faille découverte dans Windows Server 2016 restera ouverte pour toujours.

Ce qui se termine exactement

Le support courant de Windows Server 2016 est terminé depuis janvier 2022. Depuis quatre ans, le produit vit sur le support étendu : correctifs de sécurité uniquement, pas de nouvelles fonctionnalités. C'est ce dernier filet qui disparaît le 12 janvier 2027.

Et cette échéance n'arrive pas seule. Plusieurs pièces du même écosystème sont déjà tombées ou tombent en même temps :

SQL Server 2016 est sorti du support en juillet 2026 — c'est-à-dire le mois dernier. Beaucoup d'applications de gestion en PME s'appuient sur cette base de données, souvent installée sur le même serveur. Et le sursis payant y est désormais une véritable dépense : là où la génération précédente donnait accès aux correctifs sans frais additionnels dans certains scénarios, l'ESU pour SQL Server 2016 se paie.
Windows Server 2012 et 2012 R2 terminent en octobre 2026 la troisième et dernière année de leur programme de sursis payant. Si vous en avez encore un, le compte à rebours est plus court que celui de 2016.
Exchange Server 2016 et 2019 ne sont plus supportés depuis octobre 2025. Un serveur de courriel local non corrigé est, aujourd'hui, l'une des cibles les plus rentables qui existent.
Windows Server 2019, lui, tient jusqu'en janvier 2029. Migrer vers cette version en 2026 serait acheter deux ans.

Autrement dit : ce n'est pas un serveur à traiter, c'est un ensemble de dépendances à démêler.

Le sursis payant, cette fois, est un mauvais pont

Pour Windows 10, le programme de mises à jour de sécurité étendues (ESU) offrait au moins une porte de sortie chiffrable : un prix fixe par appareil, qui double chaque année. Côté serveur, le calcul est nettement moins accueillant, et quatre détails éliminent l'option pour la majorité des PME.

Premier détail : la facturation se fait par cœur, avec un minimum de 16 cœurs par serveur. Le prix annuel représente une fraction majeure — parfois la totalité — du prix d'une licence Windows Server neuve. Payer chaque année l'équivalent d'une licence neuve pour ne recevoir que des correctifs, c'est un arbitrage qui se défend rarement.

Deuxième détail, le plus décisif : l'admissibilité. L'ESU serveur exige des licences couvertes par Software Assurance via un programme de licences en volume, ou un abonnement serveur équivalent. Les licences OEM — celles qui sont arrivées préinstallées avec le serveur, donc l'immense majorité du parc PME — ne sont pas admissibles. Les licences achetées au détail non plus. Et contrairement aux générations précédentes, le SPLA n'est pas disponible pour Windows Server 2016 : la porte est encore plus étroite qu'avant. Pour beaucoup d'entreprises, l'ESU n'est donc pas une option chère : ce n'est pas une option du tout.

Troisième détail : l'adhésion est cumulative et bornée. Embarquer en deuxième année implique de payer la première aussi, et le programme s'arrête définitivement après trois ans. Le pont mène à janvier 2030, pas plus loin. Quant à la gratuité, elle existe toujours — mais uniquement pour les charges déjà hébergées chez Microsoft : machines virtuelles Azure, Azure VMware Solution, Azure Local, Azure Stack. Ce qui, par définition, ne règle en rien le cas du serveur dans le local technique.

Quatrième détail, souvent découvert trop tard : même en achetant par licences en volume, le serveur doit être enregistré dans Azure Arc pour que les correctifs soient activés. Le « sursis » suppose donc une petite infrastructure de gestion à mettre en place, sur un serveur qu'on souhaitait justement ne plus toucher.

La conclusion est la même que pour les postes de travail, en plus tranchée : le sursis est un pont, pas une destination. Sauf que cette fois, le pont est à péage élevé, à accès restreint, et il aboutit dans trois ans.

Comment savoir si vous êtes admissible? La question se règle en quelques minutes : votre partenaire de licences peut confirmer si vos licences Windows Server sont couvertes par Software Assurance ou par un abonnement. C'est la première chose à vérifier, parce que la réponse élimine ou non une des options avant même de commencer à comparer les scénarios.

La vraie question : qu'est-ce que ce serveur fait encore?

Avant de choisir une destination, il faut savoir ce qu'on déménage. C'est l'étape que presque tout le monde escamote, et c'est celle qui explique les mauvaises surprises en cours de migration.

Un serveur de PME cumule typiquement cinq à dix rôles, dont la moitié ont été ajoutés au fil des années sans documentation :

L'annuaire d'entreprise (Active Directory), le DNS, le DHCP — ce qui veut dire : les ouvertures de session de tout le monde
Les partages de fichiers, avec des permissions accumulées depuis dix ans
L'application de gestion et sa base de données
L'hôte de virtualisation, qui fait tourner d'autres serveurs
Les files d'impression, l'accès à distance, le scan des multifonctions
La tâche planifiée que personne n'a documentée, et qui envoie le rapport du vendredi
Et parfois, la destination de vos sauvegardes — ce qui signifie que le serveur à risque garde aussi votre filet de sécurité

Ce dernier point vaut un rappel : une sauvegarde qui vit sur le serveur qu'elle est censée protéger n'est pas une sauvegarde. C'est le même sujet que le mythe de la sauvegarde automatique dans Microsoft 365 , transposé au local technique.

L'inventaire de ces rôles est un exercice de quelques heures avec les bons outils, et c'est la première étape de tout audit sérieux . Sans lui, la question « on met à niveau ou on remplace? » n'a pas de réponse valable.

Trois sorties, pas quatre

Une fois l'inventaire fait, les options se comptent sur trois doigts.

1. Mettre à niveau le système sur place. Vers Windows Server 2022 ou 2025, en conservant le matériel. C'est la voie la plus rapide sur papier, mais elle bute souvent sur deux murs : le matériel de 2016-2018 arrive en fin de vie de garantie, et l'application de gestion n'est pas toujours certifiée sur les versions récentes. À valider avec l'éditeur du logiciel avant d'acheter la licence, pas après.

2. Remplacer le serveur. Nouveau matériel, système récent, garantie qui redémarre. C'est le choix logique quand un ou plusieurs rôles doivent rester sur place : une application métier lourde, un volume de fichiers important, une contrainte de latence, une exigence contractuelle de localisation des données.

3. Retirer les rôles, un par un. C'est l'option la plus intéressante, et la moins souvent évaluée. Beaucoup de ces rôles n'ont plus besoin d'un serveur physique : les partages de fichiers peuvent migrer vers SharePoint et OneDrive, l'annuaire vers Microsoft Entra ID, l'application de gestion vers la version hébergée par son éditeur, les sauvegardes vers un service infonuagique. Au bout de l'exercice, certaines PME découvrent qu'il ne reste plus assez de raisons d'avoir un serveur. C'est une migration à planifier , pas un interrupteur — mais elle règle le problème pour de bon, plutôt que de le reporter à la prochaine date d'expiration.

La quatrième option — ne rien faire — n'est pas une option, pour trois raisons qui n'ont rien à voir avec la technique. La Loi 25 exige des mesures de sécurité raisonnables : plaider le « raisonnable » avec un serveur d'annuaire non corrigé depuis des mois est un exercice perdu d'avance. Votre assureur, au renouvellement, demande explicitement si vos systèmes sont supportés par leur éditeur. Et les éditeurs de vos logiciels cesseront eux aussi de certifier leurs mises à jour sur un système hors support.

Le calendrier à rebours

Cinq mois, c'est confortable — à condition de compter à l'envers depuis le 12 janvier plutôt qu'à partir d'aujourd'hui.

Août et septembre : inventaire et dépendances. Quels rôles tournent où, quelle version de base de données, quel éditeur doit confirmer quoi. C'est aussi le moment d'appeler le fournisseur de votre application de gestion : ses délais de réponse, en pratique, sont votre vrai chemin critique.

Octobre : décision et budget. La migration de serveur tombe pile dans la saison de préparation des budgets 2027. C'est une coïncidence utile : présentez le dossier une fois, avec les trois scénarios chiffrés, plutôt que de revenir en janvier en mode urgence.

Novembre : commandes. Les délais d'approvisionnement en matériel de serveur se comptent en semaines, pas en jours, et se rallongent en fin d'année. Commander en novembre pour installer en décembre est réaliste; commander en décembre ne l'est pas.

Décembre et début janvier : bascule. En évitant vos périodes critiques — fin d'année financière, inventaire, paie. Et avec un plan de retour arrière écrit, testé, avant de commencer.

Le serveur au fond du local technique a une date d'expiration. La seule décision qui vous appartient encore, c'est de savoir si vous la choisissez cet automne, avec un plan et trois soumissions — ou si vous la subissez en janvier, avec un devis d'urgence et une semaine d'arrêt.

Chez MMO Techno, on fait cet exercice régulièrement pour les PME québécoises : inventaire des rôles réellement utilisés, validation des dépendances logicielles avec les éditeurs, comparaison chiffrée des trois scénarios, et bascule planifiée hors de vos périodes critiques. Si vous ne savez pas au juste ce que votre serveur fait encore, c'est le meilleur moment de l'année pour le découvrir. Parlons-en .