Le 10 novembre 2026, Microsoft cessera de publier des correctifs de sécurité pour .NET 8 et pour .NET 9. Si votre application métier, votre API ou votre portail client repose sur l'une de ces versions, il vous reste quelques semaines pour planifier la montée vers .NET 10. Voici ce que cette fin de support change concrètement, et comment l'aborder sans précipitation.

Ce que Microsoft a annoncé

Dans un billet publié le 29 juin 2026 sur le blog officiel .NET, Microsoft confirme la fin de support simultanée de deux versions de sa plateforme de développement :

  • .NET 8, version à support long (LTS) sortie le 14 novembre 2023, arrive au bout de ses 36 mois de maintenance.
  • .NET 9, version à support standard (STS) sortie le 12 novembre 2024, bénéficie désormais de 24 mois de support au lieu de 18. Sa fin de support, initialement prévue en mai 2026, a donc été alignée sur la même date.
  • .NET 10, sortie le 11 novembre 2025, est la nouvelle version LTS, maintenue jusqu'en novembre 2028.

Le 10 novembre étant un « Patch Tuesday », une dernière mise à jour pourra être publiée ce jour-là si un problème critique est connu. Ensuite, plus rien : ni correctif de sécurité, ni mise à jour de maintenance, ni support technique de l'éditeur.

Votre application va-t-elle cesser de fonctionner ?

Non, et c'est précisément ce qui rend l'échéance trompeuse. Une application compilée pour .NET 8 continuera de tourner le 11 novembre comme la veille. Microsoft le précise lui-même : les applications existantes restent fonctionnelles.

Le risque est ailleurs. Toute faille découverte après cette date dans le moteur d'exécution, dans ASP.NET Core ou dans les bibliothèques de base restera ouverte. Pour une application interne isolée, l'exposition est limitée. Pour une application accessible depuis Internet (extranet, portail client, API appelée par des partenaires, back-office d'application mobile), elle grandit à chaque vulnérabilité publiée.

Viennent ensuite des effets indirects, souvent sous-estimés :

  • Les outils de développement : Visual Studio 2022 marquera les composants .NET 8 et .NET 9 comme hors support lors d'une prochaine mise à jour.
  • Les bibliothèques tierces : les éditeurs de composants (génération PDF, connecteurs, rapports) alignent progressivement leurs nouvelles versions sur les plateformes supportées.
  • Les outils de supervision : certains agents de mesure de performance ont déjà annoncé l'arrêt de leur compatibilité avec .NET 8 et 9 dès le lendemain de l'échéance.
  • Vos exigences de conformité : un questionnaire de sécurité client, un audit ou une assurance cyber peuvent demander si vos logiciels reposent sur des composants maintenus.

Quelles applications sont concernées chez vous ?

La première difficulté, dans une PME, n'est pas technique : c'est de savoir ce qui tourne réellement. Une application développée il y a deux ou trois ans par un prestataire, une API écrite pour relier l'ERP au site e-commerce, un service Windows qui importe des fichiers chaque nuit : tous peuvent cibler .NET 8 sans que personne ne s'en souvienne.

Pour le vérifier, trois sources suffisent :

  1. Le code source : dans chaque fichier de projet (.csproj), la propriété TargetFramework indique la version visée, par exemple net8.0 ou net9.0.
  2. Les serveurs : la commande dotnet --list-runtimes liste les moteurs d'exécution installés sur une machine.
  3. Vos contrats et prestataires : si l'application a été fournie par un éditeur, Microsoft recommande de lui demander directement une version compatible .NET 10.

Ce recensement est aussi l'occasion de repérer les applications encore plus anciennes, sous .NET Framework 4.x ou .NET Core 3.1, dont la situation est d'une autre nature et relève davantage d'une reprise et modernisation que d'une simple montée de version.

Migrer de .NET 8 vers .NET 10 : ce que cela représente

Bonne nouvelle : passer d'une version moderne de .NET à la suivante n'a rien d'une réécriture. Sur le papier, il s'agit de remplacer net8.0 par net10.0 dans les fichiers de projet, puis de mettre à jour les environnements de développement et d'hébergement. Dans la pratique, l'effort dépend de quatre facteurs :

  • Les changements cassants documentés par Microsoft pour .NET 9 et .NET 10 : la plupart sont mineurs, mais certains touchent la sérialisation, l'authentification ou le comportement par défaut d'ASP.NET Core.
  • Les paquets NuGet : chaque dépendance doit exister dans une version compatible. Un composant abandonné par son auteur peut imposer un remplacement.
  • L'hébergement : serveur Windows avec IIS, conteneur Docker, service cloud. L'image de base ou le module d'hébergement doivent suivre.
  • La couverture de tests : une application dotée de tests automatisés se migre et se valide vite ; sans tests, la recette repose sur des vérifications manuelles plus longues.

L'assistant de mise à niveau de Microsoft (.NET Upgrade Assistant) automatise une partie du travail, mais ne remplace ni l'analyse des dépendances ni la recette métier.

Notre méthode en 5 étapes

  1. Inventorier les applications, leur version cible, leur exposition (interne ou Internet) et leur criticité métier.
  2. Prioriser : les applications exposées sur Internet et celles qui traitent des données personnelles passent en premier.
  3. Analyser les dépendances et les changements cassants applicables, puis estimer l'effort application par application.
  4. Migrer et tester dans un environnement de préproduction qui reproduit la production, avec un plan de retour arrière.
  5. Déployer et fixer le prochain rendez-vous : .NET 10 est supporté jusqu'en novembre 2028. Inscrivez dès maintenant la prochaine montée de version dans votre plan de maintenance, plutôt que de la découvrir dans deux ans.

Les erreurs à éviter

  • Attendre un incident pour agir : migrer sous la pression d'une faille publiée coûte toujours plus cher qu'une migration planifiée.
  • Passer à .NET 9 : sa fin de support tombe le même jour que celle de .NET 8. Seul .NET 10 a du sens aujourd'hui.
  • Oublier les serveurs : recompiler l'application sans installer le bon moteur d'exécution sur l'hébergement provoque un arrêt au déploiement.
  • Mélanger migration et évolutions : profiter de la montée de version pour ajouter des fonctionnalités rend la recette illisible. Migrez d'abord, faites évoluer ensuite.

Questions fréquentes

Quelle est la date de fin de support de .NET 8 ?

Le 10 novembre 2026. Microsoft ne publiera plus de correctif de sécurité ni de mise à jour pour .NET 8 après cette date, sauf une éventuelle dernière mise à jour le jour même en cas de problème critique.

Mon application .NET 8 fonctionnera-t-elle encore après le 10 novembre 2026 ?

Oui, elle continuera de fonctionner. En revanche, les failles de sécurité découvertes ensuite ne seront plus corrigées, ce qui pose surtout problème pour les applications accessibles depuis Internet.

Faut-il migrer vers .NET 9 ou vers .NET 10 ?

Vers .NET 10. La version 9 arrive en fin de support le même jour que .NET 8, alors que .NET 10 est une version à support long maintenue jusqu'en novembre 2028.

Combien de temps prend une migration de .NET 8 vers .NET 10 ?

Cela dépend du nombre de dépendances, des changements cassants concernés et de la présence de tests automatisés. Pour une application moderne bien tenue, l'effort reste nettement inférieur à une refonte ; un diagnostic préalable permet de le chiffrer précisément.

Comment savoir si une application utilise .NET 8 ?

Ouvrez le fichier de projet .csproj et regardez la propriété TargetFramework (net8.0 pour .NET 8). Sur un serveur, la commande dotnet --list-runtimes liste les moteurs installés.

Faites le point avant l'échéance. Chez Pulsar Forge, nous réalisons l'inventaire de vos applications .NET, chiffrons la migration vers .NET 10 et la menons sans interrompre votre activité, que l'application ait été développée par nos soins ou par un autre prestataire. Quelques semaines suffisent si l'on s'y prend maintenant.

Parlons de votre migration .NET