Le .NET Framework a longtemps été le socle des applications Windows d’entreprise : applications métier, services Windows, sites ASP.NET Web Forms. Mais Microsoft a figé son développement à la version 4.8 : le .NET Framework ne recevra plus de nouveautés majeures et reste cantonné à Windows. Migrer vers .NET 8 (l’évolution de .NET Core, désormais la plateforme unifiée) permet de rendre les applications portables sur Linux, de réduire les coûts de licence Windows Server et de bénéficier d’un runtime moderne, performant et activement maintenu.
Pourquoi quitter le .NET Framework
Rester sur le .NET Framework, c’est accepter plusieurs limites structurantes. D’abord, la dépendance à Windows : chaque serveur Windows et chaque licence IIS représente un coût récurrent, alors que .NET 8 s’exécute sur Linux et dans des conteneurs. Ensuite, la performance : .NET 8 apporte des gains significatifs grâce à un JIT optimisé, au compilateur AOT (Native AOT) et à une meilleure gestion mémoire. Enfin, l’écosystème : les dernières versions d’ASP.NET Core, d’Entity Framework Core et des bibliothèques tierces ciblent .NET 8, et les développeurs modernes s’attendent à travailler sur la plateforme unifiée.
| Critère | .NET Framework 4.8 | .NET 8 |
|---|---|---|
| Systèmes supportés | Windows uniquement | Windows, Linux, macOS |
| Déploiement | IIS, dépendances installées | Auto-contenu, conteneurs, AOT |
| Performance | Référence | JIT optimisé, Native AOT |
| Évolution | Figée (maintenance seule) | Active (LTS jusqu’à 2026) |
| Coûts d’infra | Licences Windows Server | Linux, cloud |
Ce qui change entre les deux plateformes
La migration n’est pas une recompilation triviale : .NET Core puis .NET 5+ ont redessiné la plateforme. Les principaux écarts sont :
- Les API absentes ou déplacées : Windows Forms, WPF et les services Windows restent disponibles mais uniquement sur Windows ; ASP.NET Web Forms, WCF (côté serveur) et AppDomains n’ont pas d’équivalent direct et imposent une refonte.
- La configuration : le
web.configetapp.configsont remplacés parappsettings.jsonet le système de configuration moderne. - Le modèle de projet : les fichiers projet (
csproj) sont simplifiés (SDK-style), et les packages passent par NuGet. - La gestion des dépendances natives et de la sérialisation (BinaryFormatter retiré pour raisons de sécurité) doit être revue.
Les étapes d’une migration maîtrisée
- Audit du parc : inventorier les applications, leurs dépendances NuGet, leurs usages d’API spécifiques et leurs intégrations.
- Analyse de compatibilité : utiliser l’outil officiel .NET Upgrade Assistant et les analyseurs de portabilité pour repérer les API indisponibles.
- Choix de la stratégie : portage direct vers .NET 8, ou refonte partielle (remplacement de Web Forms par ASP.NET Core, de WCF par gRPC ou REST).
- Migration du code : adapter le projet, remplacer les API manquantes, migrer la configuration et la gestion des données.
- Tests de non-régression et de performance : valider le comportement et mesurer les gains sur un environnement de préproduction Linux.
- Déploiement : basculer vers Linux ou conteneurs, avec un plan de rollback et une période d’observation.
Les pièges à anticiper
La sérialisation est un piège récurrent : BinaryFormatter, retiré pour des raisons de sécurité, doit être remplacé par JSON, protobuf ou un format versionné. Les chemins de fichiers et l’encodage diffèrent entre Windows et Linux (casse, séparateurs, encodage par défaut), ce qui peut casser silencieusement des traitements de fichiers. Enfin, les services Windows doivent être réécrits en workers services ou en services systemd pour fonctionner sous Linux, et les intégrations COM/ActiveX n’ont pas d’équivalent : il faut les remplacer par des API ou des bibliothèques modernes.
Conteneurisation et déploiement sur Linux
La promesse de portabilité de .NET 8 ne se réalise pleinement qu’avec un déploiement adapté. Les applications ASP.NET Core s’exécutent nativement sur Linux, soit derrière un reverse proxy (Nginx), soit dans des conteneurs Docker. La conteneurisation apporte une cohérence entre les environnements, un déploiement reproductible et une montée en charge facilitée dans Kubernetes. .NET 8 propose en outre le Native AOT, qui compile l’application en binaire natif pour un démarrage quasi instantané et une empreinte mémoire réduite — un atout majeur pour les microservices.
Points de vigilance pour le passage à Linux :
- Auditer les chemins de fichiers et la casse des noms : le système de fichiers Linux est sensible à la casse, contrairement à Windows ;
- Vérifier les encodages par défaut et les fins de ligne, qui diffèrent entre les deux plateformes ;
- Remplacer les dépendances spécifiques à Windows (composants COM, ActiveX, services Windows, registre) par des équivalents multiplateformes ;
- Configurer les variables d’environnement et les secrets via le système de configuration moderne, et non via le registre ou
web.config.
Enfin, le passage à Linux est l’occasion de repenser l’observabilité : intégrez la journalisation structurée, les métriques et le traçage distribué dès la migration, pour disposer d’une visibilité équivalente à celle du monde Windows.
Mesurer les gains et planifier le rollback
Une migration .NET vers Linux ne se conclut qu’après avoir mesuré ses bénéfices : temps de démarrage, empreinte mémoire, latence et coût d’infrastructure doivent être comparés avant et après bascule. Prévoyez également un plan de retour arrière : conserver l’ancien environnement Windows fonctionnel pendant la période de stabilisation permet de revenir en arrière en cas de régression imprévue. Cette fenêtre de sécurité, combinée à des métriques de production et à une journalisation structurée, transforme un saut technologique en une transition maîtrisée et démontrable auprès des équipes et de la direction.
Refondre Web Forms, WCF et l’accès aux données (EF Core)
Trois composants du .NET Framework n’ont pas d’équivalent direct dans .NET 8 et concentrent l’essentiel du travail de refonte : ASP.NET Web Forms, WCF et la couche d’accès aux données.
Web Forms reposait sur un modèle événementiel serveur (ViewState, postbacks) incompatible avec ASP.NET Core. La refonte se fait généralement vers Razor Pages (pour une migration progressive) ou vers une SPA (Angular, React, Blazor) pour les applications riches. Le ViewState et les contrôles serveur disparaissent, ce qui exige de reconstruire les écrans en HTML/CSS moderne, mais améliore nettement les performances et la maintenabilité.
WCF côté serveur se remplace par gRPC (performant, typé, idéal en interne) ou par des API REST avec ASP.NET Core. Les contrats de service, les bindings et la sécurité doivent être réécrits, et les clients mis à jour en conséquence.
L’accès aux données migre d’ADO.NET ou d’Entity Framework 6 vers Entity Framework Core, plus performant et multiplateforme. Les requêtes LINQ, les migrations de schéma et le suivi des changements diffèrent ; une revue des requêtes critiques et des tests de performance sont nécessaires. Ces trois refontes, bien menées, sont aussi l’occasion de simplifier une architecture vieillissante.
L’accompagnement d’un expert
Migrer du .NET Framework vers .NET 8 est un projet qui mêle portage de code, choix d’architecture et évolution de l’infrastructure d’hébergement. Chez Performances Digital, nous pilotons cette modernisation de bout en bout : audit de compatibilité, portage du code, remplacement des API obsolètes, migration vers les conteneurs Linux et accompagnement de vos équipes vers la plateforme .NET moderne. Notre objectif : des applications plus rapides, plus économes en licences, et capables de tourner sur l’infrastructure la plus adaptée.
Le .NET Framework est en fin de parcours : chaque nouvelle application Windows ajoute de la dette et des coûts de licence. Demandez votre devis gratuit : nous évaluerons votre parc .NET Framework et vous remettrons une feuille de route de migration vers .NET 8, adaptée à vos applications et à votre infrastructure.
