Reprendre une application .NET que plus personne n’ose toucher

Les situations que je reprends

Une application métier a rarement un problème unique. Elle a une histoire : plusieurs développeurs, des urgences, des raccourcis devenus permanents. Les situations qui arrivent le plus souvent sur mon bureau se ressemblent.

Le développeur est parti

Il connaissait tout, il n’a rien écrit, et depuis son départ personne n’ose déployer. Les premières semaines consistent à reconstruire ce qu’il avait dans la tête : environnements, accès, dépendances, procédure de mise en production. Puis à sécuriser, avant de corriger quoi que ce soit.

Le framework n’est plus supporté

.NET Framework 4.x, .NET Core 3.1, .NET 6, et bientôt .NET 8 et 9 : Microsoft arrête le support de ses versions selon un calendrier public. Une application sur une version arrêtée ne reçoit plus de correctif de sécurité, et les bibliothèques qu’elle utilise cessent une à une d’être mises à jour. La migration vers .NET 10, la version supportée jusqu’en 2028, se fait par étapes et sans interruption quand elle est préparée.

Chaque livraison casse quelque chose

Aucun test automatisé, des modules qui se connaissent trop bien, et une équipe qui a fini par ne plus toucher qu’aux écrans. Le remède n’est pas de tout réécrire : c’est de poser un filet de tests autour des parties qui comptent, puis de découper, module par module, en gardant le système en ligne entre chaque étape.

Plus personne ne comprend le code

Des règles métier enfouies dans des procédures stockées, des noms de variables d’une autre époque, une base de données que tout le monde contourne. Je lis, je documente, je pose des questions au métier, et je remets les règles là où on peut les relire : dans le code, nommées, testées.

Comment je reprends sans arrêter le service

1. Audit en cinq jours. Ce qui tourne, où, comment ça se déploie, ce qui dépend de quoi, ce qui est risqué. Le livrable est un document écrit, avec des priorités et des ordres de grandeur. Vous pouvez le donner à quelqu’un d’autre : il ne vous engage à rien.
2. Filet de tests avant tout changement. Sur les parcours qui font tourner votre activité : facturation, import, calcul métier. Pas de couverture à 100 %, une couverture de ce qui coûte cher quand ça casse.
3. Migration progressive plutôt que réécriture. L’ancien et le nouveau cohabitent, le trafic bascule morceau par morceau. Sur une application ASP.NET, les adaptateurs fournis par Microsoft permettent de partager la session entre les deux pendant la transition. Vos utilisateurs ne voient rien.
4. Documentation et transfert. Chaque décision est écrite au moment où elle est prise. À la fin, votre équipe ou votre prochain prestataire sait où tout se trouve.

Migration .NET Framework vers .NET 10 : ce qui change vraiment

La plupart du code C# passe sans modification. Ce qui demande du travail, ce sont les couches qui n’ont pas d’équivalent direct : les pages WebForms, les services WCF, certaines dépendances Windows, Entity Framework 6. Chacune a une voie de sortie connue, et aucune n’oblige à repartir de zéro.

• WebForms : pas de portage automatique. Migration écran par écran vers Razor Pages ou Blazor, en commençant par les moins utilisés, pendant que l’ancien site continue de servir le reste.
• WCF : selon l’usage, CoreWCF pour garder les contrats existants, ou gRPC et REST quand les clients peuvent évoluer.
• Entity Framework 6 : passage à EF Core avec une attention particulière aux requêtes qui reposaient sur des comportements implicites.
• Bibliothèques Windows : le pack de compatibilité couvre la majorité des cas ; le reste se remplace ou s’isole.

L’outil d’assistance à la migration de Microsoft fait l’inventaire et une partie du travail mécanique. Il ne décide pas de l’ordre, ne pose pas les tests et ne connaît pas votre métier. C’est là que se joue la différence entre une migration qui dure trois mois et une qui n’en finit pas.

Ce que je ne fais pas

Réécrire de zéro « parce que ce serait plus propre ». C’est la proposition qu’on vous fera le plus souvent, et c’est presque toujours la plus mauvaise : plus chère, plus longue, et le nouveau système hérite des mêmes ambiguïtés métier que l’ancien, dans un langage plus récent. Je la recommande uniquement quand le code existant ne peut plus être ni testé ni compris à un coût raisonnable, et je l’écris noir sur blanc dans l’audit quand c’est le cas.

Maintenance après la reprise

Une fois l’application remise en état, la question devient : qui la fait vivre ? Je propose une maintenance à la journée ou au forfait mensuel, avec un délai de réponse écrit, pour les corrections, les petites évolutions et les montées de version. Sans engagement de durée : le jour où votre équipe peut reprendre, elle reprend.