Expertise
Migration et modernisation .NET
Moderniser une application en production ne consiste pas à changer un numéro de version. Le vrai sujet est de réduire le risque tout en faisant évoluer l’architecture, l’outillage et l’exploitation.
Commencer par le risque, pas par la version cible
Une migration .NET doit d’abord identifier ce qui peut casser : dépendances, contrats d’API, accès aux données, pipelines, environnement d’hébergement et comportements non documentés. Sur des systèmes critiques, la stratégie de non-régression compte autant que le travail de portage.
.NET Framework vers .NET moderne
Mon parcours couvre des applications historiques en .NET Framework ainsi que des plateformes récentes en .NET 8 et .NET 10. Chez Aon, la modernisation associait refonte Angular, API .NET Core et migration Azure d’un système existant. Chez ENGIE GEMS, les microservices ont été migrés de .NET 6 vers .NET 10 avec tests unitaires et campagne de non-régression.
Moderniser aussi le delivery
Une base de code moderne avec un delivery ancien reste difficile à maintenir. La modernisation peut donc inclure CI/CD, quality gates, sécurité de la chaîne de build, observabilité et documentation. La migration Azure DevOps vers GitHub réalisée sur un environnement récent s’inscrit dans cette logique.
Frontend et architecture
Le legacy n’est pas uniquement backend. J’ai également travaillé sur des refontes de frontends historiques vers Angular. Le découpage entre frontend, API et services métier doit être conçu pour permettre des évolutions indépendantes sans multiplier les couches artificielles.
Le critère de réussite n’est pas “la solution compile en .NET 10”. C’est “la nouvelle version se comporte comme prévu, peut être déployée de façon fiable et reste exploitable en production”.