Fin du support de .NET 8 le 10 novembre 2026 : que faire de votre application ?

En bref. Le 10 novembre 2026, Microsoft arrête de publier des correctifs de sécurité pour .NET 8 et .NET 9 : votre application continue de tourner, mais chaque faille découverte ensuite ne sera plus corrigée par Microsoft. La voie recommandée est de migrer vers .NET 10, version LTS supportée jusqu'au 14 novembre 2028, en commençant par un inventaire de vos dépendances.

Dates vérifiées le 3 novembre 2026 sur la politique de support .NET de Microsoft.

Que signifie la fin de support de .NET 8 ?

La fin de support est la date à partir de laquelle Microsoft ne fournit plus de correctifs, de mises à jour ni d'assistance technique pour une version. Pour .NET 8, c'est le 10 novembre 2026.

Concrètement :

votre application continue de fonctionner ;
aucune nouvelle mise à jour de sécurité ne sera publiée ;
le support technique de Microsoft s'arrête.

Microsoft l'écrit explicitement : utiliser une version hors support peut mettre en risque vos applications, leurs données et votre environnement.

Et .NET 9 ? Il s'arrête le même jour. En septembre 2025, Microsoft a porté le support des versions STS de 18 à 24 mois, ce qui a décalé la fin de .NET 9 du 12 mai au 10 novembre 2026. Passer à .NET 9 ne vous fait donc gagner aucun délai.

Et les versions plus anciennes ? .NET 6 et .NET 7 sont déjà hors support depuis 2024. .NET Framework 4.8, lui, suit le cycle de vie de la version de Windows sur laquelle il est installé, et aucune date de fin n'est annoncée.

Qu'est-ce qui change pour la sécurité, la conformité et les dépendances ?

La sécurité

Le risque n'est pas une panne, mais une exposition qui grandit à chaque faille publiée et non corrigée. L'hébergement est concerné aussi :

les images de conteneur .NET 8 de Microsoft restent téléchargeables, mais ne reçoivent plus aucune mise à jour ;
sur Azure App Service, l'application tourne toujours, sans correctifs pour ce runtime ; il faudra migrer pour retrouver du support.

La conformité

Si une norme de sécurité, une réglementation ou vos contrats vous demandent de gérer vos vulnérabilités, un runtime qui ne reçoit plus de correctifs de son éditeur devient difficile à justifier en audit.

Les dépendances NuGet

Les bibliothèques Microsoft de la génération 8, comme Entity Framework Core 8, suivent le même calendrier : plus de correctifs après le 10 novembre. Vos paquets tiers ont leur propre rythme : certains n'ont pas de version compatible avec .NET 10, d'autres ne sont plus maintenus.

Quelles sont vos options ?

Option	Ce que cela implique	Quand c'est raisonnable
Rester sur .NET 8	Plus aucun correctif Microsoft. Des offres payantes de support étendu existent chez des tiers.	Comme pont temporaire pendant la migration, jamais comme cible.
Migrer vers .NET 10 (recommandé)	Changement de framework cible, mise à jour des paquets, prise en compte des changements de .NET 9 et .NET 10.	Dans la grande majorité des cas. Version LTS, supportée jusqu'au 14 novembre 2028.
Réécrire	Nouveau projet, nouvelle architecture, coût et risque les plus élevés.	Rarement. Seulement si le produit doit de toute façon être repensé.

Pour une application déjà en .NET 8, Microsoft décrit le passage à une version plus récente comme un effort généralement plus limité qu'une modernisation depuis .NET Framework.

Faut-il viser .NET 11 ? .NET 11 est une version STS. Au 4 novembre 2026, il en est au stade de version candidate : la RC3, publiée le 25 octobre 2026, est déjà supportée par Microsoft en production, selon sa page de téléchargement, mais ce n'est pas encore la version finale. Pour une entreprise qui veut de la stabilité, .NET 10 LTS reste la cible la plus sûre.

Par où commencer la migration vers .NET 10 ?

1. Faire l'inventaire des dépendances

Avant de toucher au code, listez ce dont l'application dépend. Les commandes du SDK donnent un premier état :

dotnet list package --vulnerable --include-transitive : paquets avec des vulnérabilités connues, y compris les dépendances indirectes ;
dotnet list package --outdated : paquets en retard de version ;
dotnet list package --deprecated : paquets abandonnés par leur auteur.

Vérifiez ensuite sur nuget.org la compatibilité de chaque paquet avec .NET 10.

2. Sécuriser avec des tests

Une migration modifie le comportement à des endroits inattendus. Sans tests automatisés sur les parcours critiques, vous découvrirez ces écarts en production. Si la couverture est faible, commencez par là.

3. Migrer par lots

Ne basculez pas tout d'un coup. Avancez projet par projet, en partant des bibliothèques de plus bas niveau :

changez le framework cible de net8.0 à net10.0 et, si le dépôt en contient un, mettez à jour global.json ;
passez les paquets Microsoft.* en version 10 ;
relisez les changements cassants de chaque version franchie, donc .NET 9 et .NET 10.

.NET Upgrade Assistant est officiellement déprécié ; Microsoft oriente vers son agent de modernisation GitHub Copilot. Un outil accélère le travail mécanique, il ne remplace ni l'inventaire ni les tests.

Quels pièges anticiper ?

Des bibliothèques d'authentification retirées. ADAL ne reçoit plus aucun correctif de sécurité depuis le 30 juin 2023 ; la cible est MSAL. IdentityServer4 n'est plus supporté depuis décembre 2022. Et dans ASP.NET Core 10, les points d'API reconnus comme tels (contrôleurs [ApiController], API minimales) protégés par cookie renvoient désormais 401 ou 403 au lieu d'une redirection vers la page de connexion.
Des paquets sans version compatible. Une bibliothèque qui ne cible que .NET Framework peut ne pas fonctionner sur .NET 10. Si un paquet vulnérable n'a pas de correctif, il faut le remplacer.
BinaryFormatter. Depuis .NET 9, il lève systématiquement une exception, quels que soient les réglages. Passer directement de .NET 8 à .NET 10 ne vous en dispense pas.
Du code lié à Windows ou à IIS. System.Drawing.Common ne fonctionne que sous Windows. L'hébergement IIS vous lie à Windows, et l'authentification Windows demande une configuration Kerberos spécifique hors de Windows. À repérer si vous visez des conteneurs Linux.
Azure Functions en modèle « in-process ». Son support s'arrête lui aussi le 10 novembre 2026 et il ne fonctionne qu'avec .NET 8. Passer à .NET 10 impose de migrer vers le modèle « isolated worker ».
Un audit NuGet plus strict. Dès que le projet cible .NET 10, la restauration analyse aussi les dépendances indirectes. Si votre build traite les avertissements comme des erreurs, elle peut échouer dès le premier essai.
L'absence de tests. Elle rend chaque piège précédent plus coûteux.

Comment évaluer l'effort avant de vous engager ?

Je propose un audit Migration dédié au passage de .NET Framework ou .NET 8 à .NET 10. Il comprend tout l'audit Complet, plus l'inventaire des dépendances et des API bloquantes, une estimation de l'effort par module et une feuille de route de migration par lots. Il représente 6 jours de travail, pour 5 500 € net, TVA non applicable.

Voir le détail de l'audit Migration ou consulter un exemple de rapport d'audit.

Questions fréquentes

Mon application .NET 8 va-t-elle s'arrêter le 10 novembre 2026 ?

Non. Elle continuera de fonctionner. Elle ne recevra plus de correctifs de sécurité ni de support de Microsoft.

Faut-il passer à .NET 10 ou attendre .NET 11 ?

Passez à .NET 10. C'est une version LTS supportée jusqu'au 14 novembre 2028. Au 4 novembre 2026, .NET 11 est une version STS qui n'est pas encore sortie en version finale, et sa date de fin de support n'est pas publiée.

Mon application est en .NET Framework 4.8 : suis-je concerné ?

Pas par cette échéance. .NET Framework 4.8 suit le cycle de vie de Windows et n'a pas de date de fin annoncée. Une migration vers .NET reste un chantier plus lourd, à planifier sans urgence artificielle.