Votre système tourne-t-il sur .NET 8 ? Les mises à jour de sécurité s'arrêtent le 10 novembre

Le 10 novembre 2026, Microsoft cesse de diffuser des mises à jour de sécurité pour deux versions de .NET le même jour : .NET 8 et .NET 9. Après cette date, aucune vulnérabilité découverte dans la plateforme ne sera corrigée sur l'une ou l'autre version. Si votre système de comptabilité, votre point de vente ou votre ERP est construit sur l'une d'elles — et sur le marché saoudien, beaucoup le sont — vous avez moins de deux mois pour décider où vous allez. Pour la plupart des entreprises, la bonne destination est .NET 10, pris en charge jusqu'au 14 novembre 2028, et non .NET 11, dont la première version candidate n'est arrivée qu'il y a deux jours.

Ce qui s'est passé le 8 septembre

Le 8 septembre 2026, Microsoft a annoncé que .NET 11 avait atteint le stade Release Candidate 1, assorti d'une licence de support go-live — ce qui signifie que Microsoft prend officiellement en charge son exécution en production réelle avant la sortie de la version finale. Le même jour, des mises à jour de maintenance courantes ont été diffusées pour .NET 10, .NET 9 et .NET 8.

Voilà pour la nouvelle technique. La nouvelle qui compte pour un chef d'entreprise se trouve sur une page tout à fait différente : la page officielle de la politique de support, mise à jour le même jour, qui indique clairement que .NET 8 et .NET 9 quittent le support le 10 novembre 2026. L'annonce de sortie, bien emballée, retient l'attention ; la ligne qui vous coûte de l'argent réel est écrite dans un tableau ennuyeux.

Pourquoi une version « à support long terme » arrive à expiration

Microsoft publie une version majeure de .NET chaque mois de novembre. Les versions de numéro pair sont à support long terme et reçoivent trois ans de correctifs gratuits ; les versions de numéro impair sont à support standard et en reçoivent deux.

.NET 8 est sorti le 14 novembre 2023 : ses trois ans expirent donc en novembre 2026. .NET 9 est sorti le 12 novembre 2024 : ses deux ans expirent donc à peu près au même moment. C'est pourquoi les deux tombent le 10 novembre. C'est là que les équipes se font piéger : « support long terme » ne veut pas dire pris en charge pour toujours. Cela veut dire trois ans comptés à partir du jour de la sortie, et une bonne partie de ce compteur s'est déjà écoulée pendant que personne ne le regardait.

La bonne cible est .NET 10, pas .NET 11

La réaction réflexe à une nouvelle de ce genre est « nous passerons donc à la plus récente ». Pour la plupart des systèmes de gestion, c'est le mauvais choix, et la raison figure dans le même tableau de support.

.NET 10 est sorti le 11 novembre 2025, c'est une version à support long terme, et elle est prise en charge jusqu'au 14 novembre 2028. Une seule mise à niveau vous achète un peu plus de deux ans de stabilité sans rouvrir le dossier. .NET 11 est une version de numéro impair : elle ne porte donc que deux ans de support standard et sortira du support avant .NET 10, bien qu'elle soit plus récente. Passer à une version plus récente qui expire plus tôt n'est pas une mise à niveau — c'est un report accompagné d'une facture supplémentaire.

Il y a une seconde considération. La version candidate de .NET 11 n'est elle-même prise en charge que jusqu'au 13 octobre 2026, parce qu'il s'agit d'une version de transition dont vous êtes censé partir — vers la candidate suivante, puis vers la version de novembre. Quiconque lit « go-live » comme une invitation à installer une version candidate dans un système de comptabilité et à l'y laisser s'est engagé dans un cycle de mise à niveau mensuel au lieu d'y échapper.

La règle pratique pour une entreprise qui fait tourner un logiciel comptable ou opérationnel : visez toujours la version à support long terme de numéro pair. Laissez les versions de numéro impair aux équipes produit qui montent de version en continu et veulent les fonctionnalités en avance.

Ce qu'apporte réellement .NET 11

Pour que la décision repose sur la connaissance plutôt que sur l'évitement, voici ce que porte la version candidate. En C#, la version 15 a stabilisé les types union — une façon plus claire d'exprimer une valeur pouvant prendre plusieurs formes, comme une opération qui soit réussit, soit échoue pour une raison précise. Côté outillage, la commande de test a amélioré sa prise en charge des applications mobiles et ajouté des contrôles au niveau de l'exécution.

Pour la publication de conteneurs, la génération d'images est désormais reproductible et évite de téléverser à nouveau les couches déjà existantes, ce qui raccourcit le temps de déploiement et facilite l'audit de ce que vous avez livré. Pour la gestion des paquets, la mise à jour des paquets porteurs de vulnérabilités connues fonctionne maintenant même lorsque les avertissements sont traités comme des erreurs — un vieux blocage qui contraignait les équipes à désactiver le contrôle de sécurité juste pour faire passer un build. Dans ASP.NET Core, les API de rafraîchissement de l'authentification de SignalR ont été finalisées, et les circuits Blazor Server mettent désormais à jour leur état après un rafraîchissement au lieu de conserver une identité périmée. Le rapport d'incident en cours de processus est arrivé sur les systèmes Unix, ce qui signifie de meilleurs diagnostics lorsqu'un serveur tombe à trois heures du matin.

Ce sont de véritables améliorations. Aucune ne pèse plus lourd que le risque de faire tourner un système financier sur une version qui expire plus tôt que l'alternative.

Pourquoi c'est un dossier de conformité, et non un dossier technique

Faire tourner une plateforme qui ne reçoit plus de correctifs de sécurité n'est pas une affaire de préférence d'ingénierie. La loi sur la protection des données personnelles (PDPL) oblige toute organisation qui manipule des données clients à appliquer des mesures de protection appropriées, et tout audit de sécurité sérieux demandera quelle version de plateforme vous faites tourner et quand son support s'achève. « Nous sommes sur une version sortie du support il y a huit mois » n'est pas une réponse défendable devant un auditeur, devant un grand client qui vous envoie un questionnaire de sécurité avant de signer, ou devant un assureur cyber.

Il en va de même pour les systèmes de facturation électronique connectés à la plateforme Fatoora. Un système qui signe numériquement des factures et les transmet à une autorité publique doit reposer sur une plateforme qui reçoit encore les correctifs cryptographiques. Ce n'est pas un détail interne — cela fait partie de la chaîne de confiance sur laquelle repose votre facture.

Un plan d'action d'ici novembre

• Cette semaine — faites le point. Demandez à votre prestataire ou à votre équipe technique l'inventaire de la version de .NET derrière chaque système que vous exploitez, y compris les petits outils internes et les services d'arrière-plan auxquels personne ne pense. Sur un serveur, dotnet --list-runtimes l'affiche ; dans le projet lui-même, c'est l'entrée du framework cible dans le fichier de projet.
• La semaine suivante — triez. Signalez tout ce qui tourne sur .NET 8 ou plus ancien et tout ce qui tourne sur .NET 9. Tout ce qui est déjà sur .NET 10 est tranquille jusqu'en 2028. Tout ce qui est sur .NET 6 ou 7 est hors support depuis des années et exige un traitement urgent, pas un calendrier.
• Sous deux semaines — lisez les changements cassants. Microsoft publie une liste des changements cassants pour chaque version. Passer de 8 à 10 se déroule généralement sans heurt, mais lire avant de commencer vous épargne des jours.
• Sous un mois — mettez d'abord à niveau l'environnement de test. Changez le framework cible, compilez, lancez les tests, puis faites tourner le système sur une copie de données réelles avant toute autre chose.
• Avant novembre — déployez. Laissez au moins deux semaines de marge de sécurité avant le 10 novembre, et ne déployez pas pendant une clôture de fin de mois ni en pleine saison de pointe commerciale.
• Une fois, définitivement. Inscrivez dès aujourd'hui le 14 novembre 2028 dans l'agenda de l'entreprise et posez une règle : chaque mise à niveau va vers la version de numéro pair suivante. Cela transforme ce dossier d'une surprise annuelle en une ligne budgétaire connue.

Si le système provient d'un prestataire

Beaucoup d'entreprises ne détiennent pas le code source ; elles achètent un système fini à un fournisseur. Dans ce cas, l'unique e-mail que vous envoyez aujourd'hui pose trois questions : sur quelle version de .NET le système tourne-t-il, quand livrerez-vous une version sur .NET 10, et la mise à niveau est-elle couverte par notre contrat de support ou facturée à part. La façon dont votre prestataire répond vous en dira plus sur le produit que n'importe quelle présentation. Et un prestataire qui ne connaît pas la réponse, ou qui temporise, est celui-là même que vous appellerez le 11 novembre.

Sources

• Microsoft — Annonce de .NET 11 Release Candidate 1, 8 septembre 2026 : devblogs.microsoft.com
• Microsoft — politique de support officielle de .NET et dates de fin de support : dotnet.microsoft.com
• Microsoft — changements cassants dans .NET 11 : learn.microsoft.com
• Autorité saoudienne des données et de l'intelligence artificielle — loi sur la protection des données personnelles : sdaia.gov.sa