Moderniser un système .NET existant sans réécriture complète

Le réflexe, lorsqu'un système .NET Framework existant semble lent et difficile à faire évoluer, est de proposer une réécriture complète. C'est rarement le bon choix. Un système suffisamment ancien pour être considéré comme existant a généralement encodé des années de règles métier que personne n'a entièrement documentées, des règles qu'une réécriture ferait disparaître silencieusement.

Nous privilégions le modèle « strangler » : les nouvelles fonctionnalités sont construites sous forme de services modernes distincts (généralement .NET 8+ ou un service JS/TS lorsque cela est pertinent) placés derrière la même interface exposée par le système existant, tandis que les anciennes fonctionnalités sont migrées pièce par pièce, au fur et à mesure qu'elles doivent de toute façon évoluer.

La modernisation de la base de données doit généralement se faire en parallèle, car les schémas existants portent souvent la même dette accumulée que le code applicatif. Nous priorisons les tables et requêtes à l'origine de véritables problèmes de performance ou de fiabilité, plutôt que de moderniser tout de manière uniforme.

Les tests de caractérisation précèdent toute refactorisation, pas l'inverse. Avant de toucher à un module contenant des règles métier non documentées, nous écrivons des tests qui capturent son comportement actuel exactement tel qu'il est, bugs compris, afin de savoir si un changement ultérieur est une correction délibérée ou une régression accidentelle. Sans cette étape, « moderniser » un système existant en change silencieusement le comportement, ce qui est souvent pire que de ne pas y toucher.

La transition des compétences de l'équipe est un coût réel que les calendriers de projet ignorent systématiquement. Une équipe qui a maintenu .NET Framework et WebForms pendant dix ans ne devient pas à l'aise en .NET moderne et avec un nouveau framework front-end en lisant de la documentation le temps d'un week-end. Nous intégrons le pair programming et le transfert de connaissances au projet lui-même, pas comme un à-côté séparé, afin que l'équipe du client puisse maintenir le système modernisé, pas seulement nous.

Le résultat est un système qui continue de faire fonctionner l'entreprise tout au long du processus, avec un risque concentré dans de petites étapes réversibles plutôt que dans une bascule unique à fort enjeu après dix-huit mois. C'est plus lent pour atteindre une base de code entièrement moderne, mais c'est la version qui ne met pas l'entreprise en péril pour y parvenir.