Migration .NET 8 vers .NET 10 : le guide concret du freelance

Le compte à rebours est lancé : le support de .NET 8 s'arrête le 10 novembre 2026. Après cette date, plus aucun correctif de sécurité, plus aucun patch. Pour les applications qui tournent en production - API, sites ASP.NET Core, services Windows, traitements batch - rester sur .NET 8 au-delà de l'automne 2026 revient à accepter un risque connu et daté. La bonne nouvelle : la migration de .NET 8 vers .NET 10 est l'une des montées de version les plus raisonnables de l'histoire de la plateforme, à condition de la mener méthodiquement. Voici ce qu'elle implique vraiment, les pièges classiques, et comment un freelance .NET senior mène ce chantier sans interrompre votre activité.

Pourquoi migrer maintenant (et pas en octobre 2026)

Le calendrier .NET est prévisible : une version majeure chaque mois de novembre, avec une alternance LTS (support 3 ans) et STS (support 18 mois). .NET 8 est une LTS sortie en novembre 2023, supportée jusqu'au 10 novembre 2026. .NET 9, version STS, est déjà sortie du support depuis mai 2026. .NET 10, LTS sortie en novembre 2025, est supportée jusqu'en novembre 2028 : c'est la cible naturelle de toutes les applications actuellement en .NET 8.

Attendre le dernier moment est le pire scénario : les équipes qui migrent en octobre 2026 le feront dans l'urgence, en même temps que tout le monde, avec des fenêtres de recette raccourcies. Migrer pendant une période calme - l'été, typiquement - permet de dérouler le chantier sereinement, de laisser tourner la nouvelle version en pré-production plusieurs semaines, et d'absorber les imprévus sans pression de calendrier.

Au-delà de la sécurité, .NET 10 apporte des gains immédiats : des performances runtime en progression à chaque version (JIT, garbage collector, allocations réduites) - souvent mesurables sans changer une ligne de code -, le langage C# 14 et ses simplifications, et deux ans de tranquillité avant la prochaine échéance LTS.

Faut-il passer par .NET 9 ? Non.

Question récurrente en début de mission : « doit-on migrer version par version ? » Pour une application .NET 8, la réponse est non : on cible directement .NET 10. Les versions intermédiaires ne sont pas des étapes obligatoires - .NET 9 est d'ailleurs déjà hors support. Une stratégie LTS vers LTS est le standard pour les applications d'entreprise : moins de migrations, moins de recettes, moins de risque cumulé. Les breaking changes de .NET 9 et .NET 10 se traitent en une seule passe, et Microsoft documente les deux listes.

Ce que la migration implique vraiment

Sur le papier, migrer se résume à changer le TargetFramework de net8.0 vers net10.0 et recompiler. En pratique, le retarget est la partie visible d'un chantier qui touche toute la chaîne de livraison :

• Le graphe NuGet : chaque paquet doit être monté vers une version compatible .NET 10. C'est là que se cachent les vraies difficultés - paquets abandonnés, montées majeures avec leurs propres breaking changes (EF Core 10, bibliothèques de sérialisation, clients d'API), conflits de versions transitives.
• Les APIs obsolètes : les avertissements d'obsolescence accumulés depuis .NET 8 deviennent parfois des erreurs. Une passe de nettoyage s'impose, guidée par les analyzers et la liste officielle des breaking changes.
• La chaîne CI/CD : SDK épinglé dans global.json, images Docker de base (mcr.microsoft.com/dotnet/aspnet:10.0), agents de build Azure DevOps ou GitHub Actions, scripts de déploiement. Une migration qui oublie le pipeline casse au premier build.
• La validation : recette fonctionnelle ciblée sur les zones à risque (accès données, sérialisation JSON, authentification, tâches planifiées), comparaison des performances avant/après, et période d'observation en pré-production.

Les pièges classiques que je rencontre en mission

Le premier piège est le paquet NuGet orphelin : une dépendance critique dont le mainteneur a disparu et qui ne ciblera jamais .NET 10. Il faut la détecter en début de chantier - pas en semaine 6 - et décider : remplacement, fork, ou réécriture du périmètre concerné. Le deuxième est la bibliothèque interne partagée entre plusieurs applications : la faire multi-cibler (net8.0;net10.0) pendant la transition évite de forcer la migration simultanée de tout le parc. Le troisième est l'absence de tests automatisés : dans ce cas, on sécurise d'abord les parcours critiques par des tests d'intégration avant de toucher au framework - c'est la différence entre une migration mesurée et un saut dans le vide.

Mention spéciale pour les applications encore en .NET Framework 4.x : là, il ne s'agit plus d'une montée de version mais d'un vrai portage, avec un périmètre et une méthode différents - c'est un sujet que je traite dans le cadre de mes prestations de développement .NET. Si votre parc mélange les deux générations, l'audit initial permet justement de séquencer les chantiers.

La méthode : auditer, planifier, migrer par lots, observer

Une migration réussie commence par un audit d'un à trois jours : inventaire des solutions et projets, cartographie du graphe NuGet, détection des dépendances à risque, état de la couverture de tests, revue du pipeline de livraison. L'audit produit un plan chiffré, par lots : d'abord les bibliothèques partagées (en multi-ciblage), puis les applications les moins exposées, enfin les applications critiques - chacune avec sa recette et sa fenêtre de déploiement. Sur la plupart des parcs .NET 8 bien entretenus, la migration d'une application se compte en jours, pas en semaines ; c'est l'état du graphe de dépendances qui fait varier la facture, et c'est exactement ce que l'audit révèle avant d'engager quoi que ce soit.

Freelance ou ESN pour ce chantier ?

Une migration .NET 8 vers .NET 10 est un chantier borné, technique et outillé : le profil idéal est un développeur senior qui en a déjà mené, pas une équipe projet complète. Passer par un freelance évite l'effet tunnel et les couches d'intermédiaires : vous échangez directement avec la personne qui fait, le démarrage se compte en jours, et le budget correspond à du temps de production réel. Avec plus de quinze ans de .NET - du Framework aux versions actuelles, avec les migrations qui vont avec - et une pratique quotidienne des pipelines Azure DevOps, j'interviens précisément sur ce type de chantier : vous trouverez le détail de mon parcours sur ma page expertise.

Télétravail et disponibilité

Ce type de mission se mène très bien à distance : audit en visio, développements sur vos environnements, revues de code et démonstrations en continu. Je travaille en remote pour des entreprises partout en France, et je peux intervenir en présentiel dans les Hauts-de-France (Valenciennes, Lille, Douai, Cambrai, Maubeuge) quand le contexte le demande - ateliers de cadrage, bascules de production.

En résumé

La fin de support de .NET 8 en novembre 2026 n'est ni une surprise ni une fatalité : c'est une échéance connue qui se prépare. Cibler directement .NET 10 LTS, auditer le graphe de dépendances avant d'engager le chantier, migrer par lots avec une vraie recette, et laisser une période d'observation : voilà la méthode qui transforme une contrainte de calendrier en gain net - sécurité, performances, et deux ans de sérénité. Si vos applications tournent encore en .NET 8, c'est le bon moment pour en parler - avant que l'échéance ne choisisse la date à votre place.