Reprendre une application .NET que personne ne maîtrise plus

Le point de départ

Une application métier écrite il y a dix ou quinze ans, en .NET Framework 4.x, souvent en WebForms ou en WCF. Elle tourne, elle est critique, et les deux personnes qui la connaissaient sont parties. Chaque évolution prend des semaines, chaque mise en production fait peur, et l'idée d'une réécriture complète revient à chaque comité.

Nous en avons repris une douzaine. Le protocole ci-dessous tient en six semaines et ne commence jamais par réécrire.

Semaines 1 et 2 — l'audit

• Cartographier ce qui existe réellement : dépôts, branches, binaires déployés, bases, jobs planifiés, dépendances externes. L'écart entre le code source et ce qui tourne en production est la première surprise, une fois sur deux.
• Reconstruire l'application depuis zéro sur un poste neuf. Si ce n'est pas possible en une journée, c'est le premier chantier.
• Relever les flux : qui appelle quoi, avec quelles données, à quelle fréquence. Les journaux applicatifs et les traces réseau en disent plus que la documentation.

Semaines 3 et 4 — le filet

Avant de modifier une ligne, nous posons des tests de non-régression au niveau des frontières : appels HTTP, fichiers échangés, tables écrites. Des tests de caractérisation, qui figent le comportement actuel — y compris ses défauts — pour détecter tout changement involontaire. À ce stade, une chaîne d'intégration continue construit et teste l'application à chaque commit.

Semaines 5 et 6 — les premières évolutions

Les demandes métier en attente servent de test réel : nous en livrons deux ou trois, petites, en production. Chacune passe par le filet posé aux semaines précédentes. C'est le moment où l'équipe cliente reprend confiance, et où nous décidons ensemble de la trajectoire : moderniser par morceaux (vers .NET 8, service par service) ou stabiliser et maintenir.

Ce que nous ne faisons pas

• Réécrire « from scratch » sans avoir compris l'existant : le projet dure deux fois plus longtemps et perd les règles métier que personne n'avait écrites.
• Migrer le framework en premier : la migration est une évolution parmi d'autres, elle vient quand le filet de tests existe.
• Travailler seuls : un référent métier et une personne de l'IT du client sont dans l'équipe du premier au dernier jour, c'est la garantie que la connaissance reste chez vous.