Windows Server 2019 est-il encore adapté à un nouveau déploiement en 2026 ?

Vérifiez d’abord la durée de support et la contrainte logicielle

Microsoft indique que le support étendu de Windows Server 2019 prend fin le 10 janvier 2029, selon l’heure du Pacifique (fiche officielle du cycle de vie). En 2026, ne choisissez donc pas cette version comme option par défaut pour un nouveau projet : retenez-la seulement si un logiciel métier la demande explicitement, si les essais confirment son bon fonctionnement et si votre équipe accepte la période de support restante. Pour les autres projets, comparez Windows Server 2022 et Windows Server 2025 avant de fixer la version.

Cette décision concerne les équipes qui doivent conserver un ERP, un serveur applicatif ou un composant certifié pour Windows Server 2019. Elle concerne aussi celles qui évaluent la poursuite d’un environnement déjà en service. Enfin, si vous préparez un nouveau site IIS ou un serveur dédié Windows sans version encore arrêtée, les vérifications ci-dessous vous aideront à éviter un choix fondé uniquement sur l’habitude.

Un nouveau serveur peut-il encore fonctionner sous Windows Server 2019 ? Oui, si les prérequis du logiciel et de ses dépendances sont confirmés et si le calendrier de maintenance est accepté. Le fait que le système bénéficie encore d’un support étendu ne signifie ni que votre éditeur prend en charge l’application sur cette version, ni que 2019 convient aux nouveaux projets sans contrainte.

Distinguez la maintenance d’un serveur existant d’un nouveau déploiement

Pour un serveur 2019 déjà en production, la question est généralement de savoir comment le maintenir en état de fonctionnement tout en préparant la suite. Pour un serveur neuf, vous pouvez choisir le système en fonction des exigences actuelles de l’application, sans reprendre automatiquement les décisions prises pour l’ancien environnement. Ces deux situations ne présentent donc pas le même niveau de liberté.

Microsoft date la fin du support standard de Windows Server 2019 au 10 janvier 2024 et la fin du support étendu au 10 janvier 2029 sur sa page de cycle de vie. La période de support étendu a une échéance ; elle ne constitue pas une garantie que chaque éditeur de logiciel, fournisseur de base de données ou fabricant de périphériques continuera à prendre en charge cette version jusqu’à cette date.

Des mises à jour de sécurité seront-elles encore disponibles après cette échéance ? Ne comptez pas sur les mises à jour de sécurité incluses dans le cycle de vie standard après la fin du support étendu. Si un programme distinct de mises à jour ou une exception devait s’appliquer à votre situation, vérifiez ses conditions directement auprès de Microsoft ; ne la supposez pas acquise pour votre serveur.

Pour un environnement existant, établissez plutôt un plan distinct : qui installe et vérifie les mises à jour actuellement proposées, quand l’application peut être testée, quelles dépendances doivent être conservées et quelle solution de retour est possible si une modification casse une fonction métier. Pour une nouvelle machine, cette analyse se transforme en choix de version avant commande. Dans les deux cas, une échéance officielle ne remplace pas une date interne de réévaluation, qui doit tenir compte du cycle de vie de votre propre application.

Évaluez votre situation métier avant de choisir une version

Les équipes qui entretiennent un ancien ERP ne doivent pas déduire sa compatibilité de son comportement sur le serveur précédent. Une nouvelle installation peut différer par ses composants, ses correctifs, ses paramètres de sécurité ou sa configuration réseau. Demandez à l’éditeur quels systèmes sont pris en charge, quelles versions de base de données sont requises et si les interfaces avec les autres logiciels restent couvertes.

Pour une nouvelle application IIS, partez des versions réellement utilisées : environnement d’exécution, dépendances natives, outil de déploiement, modules IIS et éventuels composants tiers. La documentation de Microsoft explique les principes de compatibilité des applications avec Windows Server, mais elle ne certifie pas votre logiciel métier particulier. Il faut également vérifier séparément la liste des systèmes compatibles avec .NET pour Windows, les prérequis de .NET Framework et le cycle de vie d’IIS lorsque ces composants entrent dans votre architecture.

Le tableau suivant sert à orienter les vérifications ; il ne remplace pas les matrices officielles des éditeurs.

Un ancien ERP impose-t-il réellement 2019 ? Vérifiez si l’éditeur parle d’une exigence, d’une version testée ou d’une simple configuration historique. Demandez aussi ce qui est pris en charge en cas d’incident sur une version plus récente. Si l’application fonctionne seulement en environnement de test mais sort de la matrice de support, vous devez traiter ce risque comme une décision métier, et non comme une compatibilité garantie.

Comparez 2019, 2022 et 2025 selon votre horizon de maintenance

Pour un projet neuf sans exigence d’ancienne version, Windows Server 2022 et Windows Server 2025 méritent une évaluation avant de retenir 2019. Microsoft fournit les échéances de support pour Windows Server 2022 et Windows Server 2025. Consultez ces fiches au moment de la décision : elles permettent de comparer les calendriers officiels, sans présumer que l’application que vous déployez sera compatible avec chaque version.

Faut-il choisir 2019 ou 2022 pour un nouveau projet ? Si l’éditeur de votre application exige 2019 et refuse de prendre en charge 2022, suivez cette contrainte après validation en environnement de test. Si aucune contrainte ne l’impose, comparez les dates de support et les exigences de vos composants, puis demandez à l’éditeur de confirmer la version cible. Les pages de cycle de vie de Microsoft donnent les échéances du système ; elles ne déterminent pas la compatibilité d’un ERP, d’un logiciel de gestion ou d’un module IIS tiers.

Pour 2025, ne vous contentez pas d’une liste de nouvelles fonctions : confirmez que celles dont vous avez besoin correspondent à votre édition et à votre architecture, puis vérifiez les prérequis des logiciels concernés. Les informations de version publiées par Microsoft, notamment son suivi des versions et mises à jour de Windows Server, sont utiles pour contrôler les changements et les mises à jour, mais ne remplacent pas le support déclaré par les éditeurs de vos applications.

Testez le scénario réel avant de commander ou de basculer

Procédez dans un environnement isolé autant que possible, avec des données de test et une méthode de retour définie. L’objectif n’est pas seulement de vérifier qu’un programme s’installe : vous devez observer son usage normal, ses échanges avec les autres composants et les opérations qui se lancent sans intervention.

• [ ] Recueillez les prérequis officiels de chaque application. Dans le portail de support ou la documentation de l’éditeur, relevez le système d’exploitation pris en charge, les versions de bases de données, les dépendances, les droits et les composants requis. En PowerShell, consignez l’environnement du serveur existant avec Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber ; cette commande décrit le système, mais ne prouve pas la compatibilité de l’application.
• [ ] Dressez la liste des rôles et des services nécessaires. Dans le Gestionnaire de serveur, examinez les rôles et fonctionnalités installés ; pour IIS, utilisez aussi Get-WindowsFeature Web-Server. Comparez cette liste aux instructions de l’éditeur et identifiez les modules ou réglages qui ne sont pas inclus dans une installation standard.
• [ ] Contrôlez les versions d’exécution utilisées. Dans une invite de commandes ou PowerShell, exécutez dotnet --list-runtimes si l’application dépend de .NET. Pour .NET Framework ou un composant fourni par un tiers, suivez les exigences publiées par son éditeur plutôt que de déduire la version à partir de la seule présence d’IIS.
• [ ] Reproduisez les opérations métier importantes. Faites installer l’application, connectez les utilisateurs de test autorisés, lisez et écrivez des données de test, puis vérifiez les échanges avec les services externes. Pour les traitements planifiés, consultez le Planificateur de tâches et contrôlez les résultats d’exécution dans l’Observateur d’événements. En PowerShell, Get-ScheduledTask aide à inventorier les tâches ; il ne valide pas leur résultat fonctionnel.
• [ ] Vérifiez le déploiement et les mises à jour dans les conditions prévues. Pour IIS, contrôlez les sites et pools d’applications dans le Gestionnaire des services Internet, puis utilisez les procédures de déploiement de votre équipe. Confirmez auprès des éditeurs les versions prises en charge avant d’installer une mise à jour du système, de .NET ou d’un module.
• [ ] Écrivez la procédure de retour avant la mise en production. Définissez comment restaurer les données et la configuration à partir de sauvegardes que vous avez vérifiées, comment interrompre la bascule et qui autorise le retour. Pour une nouvelle installation, conservez l’ancien environnement disponible jusqu’à ce que les critères d’acceptation soient atteints, si votre organisation peut le faire.

Cette vérification vous évite de confondre « le service démarre » et « la solution est exploitable ». Un ERP peut s’ouvrir alors qu’un traitement nocturne, un export ou une interface avec un autre système échoue. De même, un site IIS peut répondre pendant un test élémentaire sans que le processus de publication, l’authentification ou une dépendance externe ait été validé.

Préparez l’exploitation, l’accès et la commande de la machine

Avant la mise en service, consignez le système choisi, la langue requise, les responsables des mises à jour et les méthodes d’administration. Si l’équipe doit administrer Windows à distance, vérifiez les droits d’accès, les comptes, les règles réseau et les pratiques de sécurité retenues ; le guide d’accès SSH et RDP d’OVN Cloud explique le mode d’accès prévu pour ces systèmes. Ne supposez pas qu’un accès distant remplace les contrôles de sécurité ou la procédure de retour.

• [ ] Le fournisseur du logiciel a confirmé par écrit la compatibilité de la version choisie, ou vous avez consigné le risque s’il ne la garantit pas.
• [ ] La version du système, la langue et les composants applicatifs ont été testés dans une configuration proche de la production.
• [ ] Les accès d’administration et les personnes autorisées sont définis avant l’ouverture du serveur.
• [ ] Les données nécessaires au démarrage ont été sauvegardées et un retour a été vérifié.
• [ ] Le calendrier de maintenance tient compte à la fois du cycle de vie du système et de celui des applications.
• [ ] La page de configuration a été vérifiée pour confirmer les options Windows réellement disponibles au moment de la commande.

Si vous louez un serveur Windows, confirmez la version et la langue effectivement proposées dans les options actuelles d’OVN Cloud, puis vérifiez les conditions et le coût affichés au moment de la commande. Ne déduisez pas l’option choisie de la disponibilité d’une version chez Microsoft : le catalogue du fournisseur et les exigences de votre application doivent tous deux correspondre.

Un serveur dédié physique devient pertinent lorsque vous avez besoin d’une machine réservée à votre charge Windows et que l’exploitation doit rester stable sur la durée. Une instance partagée peut impliquer des ressources utilisées en commun, des limites propres à l’offre ou une facturation à examiner attentivement ; ces caractéristiques varient selon les services et ne doivent pas être généralisées à tous les fournisseurs. À l’inverse, louer une machine dédiée n’est pas nécessairement adapté à un essai bref, à une charge légère ou à un besoin qui exige une élasticité immédiate. Si votre application impose Windows et que vous avez besoin de ressources dédiées pour une exploitation suivie, une machine physique AMD d’OVN Cloud mérite d’être comparée à votre solution actuelle, après validation de la version et des options réelles dans le catalogue.

Avant de finaliser votre choix, faites confirmer la compatibilité par l’éditeur du logiciel, puis rapprochez cette réponse des systèmes Windows et des langues affichés dans la configuration d’OVN Cloud. Ce contrôle vous permet de choisir une version adaptée à votre charge, sans présumer que le fournisseur du serveur garantit le fonctionnement de vos applications.