.NET 11 : faut-il migrer les applications de votre PME ?

.NET 11 est disponible depuis le 10 novembre 2026, mais son lancement ne signifie pas que toutes les PME doivent migrer immédiatement vers cette version. La priorité concerne les entreprises dont les applications fonctionnent encore avec .NET 8 ou .NET 9 : ces deux versions ont atteint leur fin de support le même jour. Microsoft confirme ces échéances dans sa politique officielle de support.

Pour un dirigeant, la décision n’est donc pas simplement « faut-il installer la dernière version ? ». Il faut identifier les logiciels concernés, choisir une cible maintenue et organiser une migration sans perturber les ventes, la production ou les opérations. Pour un CTO, il faut aussi distinguer les nouveautés utiles des changements qui ajoutent du risque sans bénéfice immédiat.

Voici comment arbitrer entre .NET 10 et .NET 11, demander les bonnes preuves à votre prestataire et cadrer le travail avant d’engager un budget.

Ce que Microsoft a annoncé le 10 novembre

Microsoft a publié la version finale de .NET 11 le 10 novembre 2026. L’annonce de l’équipe .NET et les notes de publication du dépôt officiel confirment sa disponibilité.

Cette livraison apporte notamment des évolutions de C# 15, d’ASP.NET Core, des bibliothèques et des outils de développement. Microsoft annonce également des améliorations pour les applications web, mobiles et les usages d’intelligence artificielle. La documentation des nouveautés de .NET 11 permet de vérifier les composants réellement utiles à votre application.

Le lancement crée deux décisions différentes : traiter la fin de support des anciennes versions et évaluer l’intérêt de la nouvelle. Les mélanger conduit à deux erreurs opposées : reporter une migration nécessaire parce que les nouveautés semblent accessoires, ou transformer une opération de maintenance en refonte générale.

Notre recommandation : séparez le chantier de maintien en condition opérationnelle du chantier d’innovation produit. Une application de gestion n’a pas besoin de changer d’interface ou d’intégrer un agent IA pour revenir sur une version maintenue.

Votre entreprise est-elle concernée par cette migration .NET ?

Votre entreprise est concernée si elle exploite une application reposant sur une version de .NET arrivée en fin de support, directement ou à travers un logiciel fourni par un prestataire. Pour le vérifier, demandez la version effectivement exécutée en production, pas seulement celle installée sur le poste du développeur.

Commencez par les applications dont l’indisponibilité aurait une conséquence métier immédiate :

• un portail de commande utilisé par vos clients professionnels ;
• un backoffice qui prépare les expéditions ou pilote les stocks ;
• un logiciel de planification, de devis ou de suivi d’intervention ;
• une API qui relie votre site e-commerce à votre ERP ;
• un service qui synchronise des données ou exécute des traitements nocturnes.

Ne limitez pas l’inventaire aux écrans visibles. Demandez également la liste des connecteurs, tâches planifiées et services secondaires. Pour un logiciel métier développé sur mesure, exigez une correspondance entre chaque composant technique et le processus qu’il sert : commande, facturation, approvisionnement, suivi client.

Les informations à demander à votre équipe technique

Une fiche courte par application suffit pour engager l’arbitrage. Elle devrait contenir le responsable, la version cible du projet, le runtime de production, le mode de déploiement, les dépendances importantes et l’existence d’une procédure de retour arrière.

Cette distinction entre projet et environnement est essentielle. Selon la documentation Microsoft sur la publication des applications, une application peut utiliser un runtime installé sur son environnement ou embarquer son propre runtime dans un déploiement autonome. Dans ce second cas, mettre à jour le serveur ne remplace pas le runtime livré avec l’application.

Pour le dirigeant, la bonne question devient : « Pouvez-vous me montrer quel artefact est déployé, avec quelle version, et comment il sera remplacé ? » Une réponse vérifiable vaut davantage qu’un « le serveur est à jour ».

Faut-il choisir .NET 10 ou .NET 11 ?

Choisissez la version qui combine compatibilité, maintenance maîtrisée et bénéfice concret pour votre application. .NET 11 n’est pas obligatoire pour sortir de .NET 8 ou .NET 9 : .NET 10 reste une option maintenue, comme le précise Microsoft dans son annonce.

Un détail change l’arbitrage : au 11 novembre 2026.NET 10 et .NET 11 ont la même date de fin de support annoncée, le 14 novembre 2028. .NET 10 est une version LTS, tandis que .NET 11 est une version STS. Microsoft indique que ces catégories partagent les mêmes politiques de qualité et de maintenance, mais correspondent à des durées de support différentes depuis leur lancement. Ces informations sont vérifiables dans le calendrier de support actualisé le 10 novembre 2026.

Ces orientations sont des recommandations de cadrage, pas des règles imposées par Microsoft. Une bibliothèque incompatible peut faire pencher le choix vers .NET 10. À l’inverse, un besoin précis et validé peut justifier .NET 11. Le numéro de version ne doit pas remplacer cette analyse.

Quelles nouveautés de .NET 11 peuvent avoir une valeur métier ?

Les nouveautés de .NET 11 méritent un investissement lorsqu’elles répondent à une difficulté identifiée : maintenance du code, intégration d’API, performance ou évolution d’une interface. Aucune annonce générale ne permet de promettre un gain sur votre application sans essai représentatif.

Des règles métier plus explicites

C# 15 introduit notamment des types union et des hiérarchies fermées, présentés dans l’annonce officielle de .NET 11. Ces mécanismes permettent de mieux exprimer les états possibles d’un résultat et leur traitement par le code.

Prenons un exemple hypothétique : un contrôle de commande peut aboutir à une validation, à une rupture de stock ou à un dépassement d’encours. Notre lecture : des résultats explicites peuvent aider l’équipe à vérifier que chaque situation a un traitement prévu. Cela ne dispense pas de définir les règles avec les utilisateurs ni de tester les exceptions.

Des échanges d’API à vérifier avec les consommateurs

ASP.NET Core apporte notamment la validation asynchrone et le support d’OpenAPI 3.2, selon la même annonce. Pour votre équipe, le sujet à examiner est l’effet sur les contrats d’API, la documentation et les clients qui consomment ces services, plutôt qu’une adoption automatique de chaque nouveauté.

Dans un SaaS B2B, demandez par exemple si un intégrateur client utilise un SDK généré à partir de votre description d’API. Prévoyez alors un test de ce SDK dans la recette, au lieu de vérifier uniquement que votre serveur démarre.

Des fonctions IA dont il faut contrôler la maturité

Microsoft présente aussi des composants Blazor AI expérimentaux intégrés au protocole AG-UI. Leur caractère expérimental est explicitement signalé dans l’annonce de lancement.

Ne faites pas d’un composant expérimental le prérequis d’une migration de maintenance. Si une nouvelle expérience conversationnelle vous intéresse, évaluez-la dans un prototype séparé, avec ses propres critères de validation et une solution de remplacement. Le maintien d’un logiciel de facturation ne devrait pas dépendre de la réussite d’un essai d’interface IA.

Le plan d’action à engager maintenant

Au 11 novembre 2026, pour une application encore sur .NET 8 ou .NET 9, l’échéance de support est passée. Il faut ouvrir le chantier, sans confondre urgence de décision et déploiement précipité. Voici un ordre de travail recommandé.

1. Attribuer un responsable. Nommez la personne qui coordonne l’inventaire, l’arbitrage et la mise en production. Incluez le propriétaire métier.
2. Recenser les composants réellement exploités. Reliez chaque application à son dépôt, son hébergement et son processus de déploiement.
3. Tester la cible. Faites compiler une branche dédiée et relevez les dépendances bloquantes avant d’annoncer une date ferme.
4. Définir la recette métier. Listez les opérations indispensables et leurs résultats attendus.
5. Préparer le déploiement et son annulation. Précisez les conditions de bascule, les vérifications et la personne autorisée à décider du retour arrière.
6. Documenter la clôture. Conservez la version livrée, les tests exécutés et les éventuelles réserves.

Pour une PME de négoce, une recette pourrait couvrir la création d’une commande, la réservation du stock, l’édition du bon de préparation, la facturation et l’export comptable. Pour une entreprise de maintenance, choisissez plutôt la planification, l’accès terrain, le compte rendu et la facturation de l’intervention. Ce sont des exemples de scénarios, à adapter à vos flux.

Le guide Novane consacré à la recette d’une application web permet de formaliser ces critères avec les utilisateurs, sans leur demander de juger le code.

Pour les CTO : vérifier toute la chaîne de livraison

Microsoft recommande de traiter ensemble le SDK, les frameworks cibles, les packages, les environnements de compilation et les hôtes de déploiement. L’éditeur rappelle qu’installer un SDK récent ne modifie pas à lui seul la cible d’une application. Son parcours de mise à niveau demande aussi de vérifier les changements incompatibles, les prérequis CPU et le mode de publication.

Commencer par un état des lieux reproductible

Les commandes suivantes servent à examiner l’environnement dans lequel elles sont exécutées. Leur rôle est décrit dans la documentation officielle de la commande dotnet.

dotnet --info
dotnet --list-sdks
dotnet --list-runtimes

Exécutez ce diagnostic là où il est pertinent : poste de développement, agent de compilation et environnement d’exécution disposant de la commande. Complétez-le par l’inspection des fichiers projet, de global.json, des images de conteneurs et des paramètres de publication. La liste des runtimes installés n’établit pas, à elle seule, celui qu’une application autonome embarque.

Isoler la migration des autres transformations

Notre conseil : évitez de changer simultanément de version .NET, d’hébergeur, de modèle de données et de mécanisme d’authentification. Si plusieurs transformations sont indispensables, découpez-les en étapes vérifiables. Cette discipline facilite l’identification d’une régression et la décision de revenir en arrière.

Pour une application utilisant une base de données, demandez une validation spécifique des requêtes critiques et des traitements en volume. Comparez les résultats fonctionnels et les temps observés avec une référence capturée avant migration. N’acceptez pas un simple « les tests passent » sans savoir quels usages ces tests couvrent.

Tester le retour arrière avec les données

Préparez un exercice de retour arrière avant la mise en production. Vérifiez non seulement la remise en place de l’application précédente, mais aussi sa capacité à relire les données après la bascule envisagée. Si une évolution de schéma est prévue, faites préciser ses conséquences et la procédure de récupération.

Pour un SaaS destiné à plusieurs entreprises clientes, ajoutez à la recette les droits d’accès et les parcours de chaque catégorie d’utilisateur. Le changement technique doit préserver les engagements fonctionnels du produit.

Quel budget prévoir sans inventer un prix de migration ?

Un budget sérieux doit être établi après examen du dépôt, des dépendances et du déploiement. La taille apparente de l’application ne suffit pas : un petit outil sans procédure de compilation fiable peut nécessiter un travail différent d’un produit plus vaste déjà bien testé.

Demandez un chiffrage séparant les postes suivants :

• Diagnostic : inventaire, reproduction de la compilation et identification des blocages.
• Adaptation : changements de code, mise à jour des dépendances et configuration.
• Validation : tests automatisés, recette métier et essais de charge pertinents.
• Livraison : préparation des environnements, bascule et vérification du retour arrière.
• Suivi : observation après déploiement et traitement des réserves.

Exigez également les hypothèses : accès disponibles, compatibilité des composants tiers, disponibilité des utilisateurs pour la recette et éventuelles modifications exclues. Un prix global sans ces précisions rend les offres difficiles à comparer.

Pour le budget 2027, distinguez ensuite la maintenance récurrente de cette migration ponctuelle. Prévoyez un responsable et un processus pour surveiller les échéances, qualifier les mises à jour et conserver une capacité de déploiement. Le livrable utile n’est pas seulement une version plus récente, mais une application que votre entreprise peut continuer à faire évoluer.

Trois cas particuliers à ne pas traiter comme une migration standard

Votre logiciel est fourni par un éditeur

Ne modifiez pas vous-même les composants techniques d’un produit tiers sans procédure validée. Demandez à l’éditeur quelles versions du produit utilisent un environnement maintenu, quel correctif installer et quelles opérations vous incombent. Obtenez une réponse écrite et rattachée à la version précise que vous exploitez.

Votre application utilise .NET Framework

.NET Framework possède une trajectoire distincte de celle de .NET 8, 9, 10 et 11. Microsoft précise dans sa documentation sur les versions de .NET Framework qu’une migration vers .NET moderne n’est pas systématiquement nécessaire. Faites vérifier le cycle de vie applicable à votre combinaison de version et de système, plutôt que de lancer une réécriture à partir du seul mot « .NET ».

Votre prestataire historique n’est plus disponible

Commencez par récupérer les sources, les droits d’accès, les procédures de compilation et les paramètres de déploiement. Vérifiez qu’un intervenant peut produire et tester une livraison sans dépendre d’un poste personnel. Sans cette capacité, la première prestation à cadrer est la reprise technique, pas une migration forfaitaire promise à l’aveugle.

Décider sur des preuves, pas sur le numéro de version

Le lancement de .NET 11 doit déclencher une vérification ciblée de votre parc applicatif, pas une refonte automatique. Pour chaque application concernée, demandez une cible justifiée, une recette métier et un déploiement réversible.

Vous devez arbitrer entre .NET 10 et .NET 11, reprendre un logiciel métier ou vérifier une proposition de migration ? La séance de consulting IT offerte par Novane permet de confronter vos contraintes métier et techniques avant d’engager le chantier.