Modernisation : faire évoluer ou réécrire ?
La modernisation se juge sur les changements qu’elle rend possibles et les risques qu’elle réduit. L’ancienneté d’une technologie ne suffit pas à justifier une refonte.
Comparer le coût du maintien et celui du remplacement
Une application ancienne peut remplir correctement son rôle, tandis qu’une dépendance isolée bloque les évolutions. Une réécriture complète engage aussi les règles métier implicites, les données et les habitudes d’exploitation. La décision doit comparer ces risques à ceux du maintien et des évolutions ciblées.
Ce qu’il faut vérifier avant une refonte
- Quel problème mesurable doit être résolu ? Distinguer les incidents, les délais de livraison, les dépendances non maintenues et les limites fonctionnelles.
- Quelles règles et quelles données doivent être préservées ? Documenter les comportements critiques et les vérifier par des tests.
- Peut-on isoler une partie du logiciel ? Chercher une frontière permettant une évolution progressive avec des contrats explicites.
- Comment basculer et revenir en arrière ? Prévoir la validation des données, la coexistence éventuelle et les critères d’arrêt.
Valider une première étape avant de poursuivre
Comparer trois options sur un périmètre précis : stabiliser, faire évoluer ou remplacer. Tester la première étape sur une fonction représentative, puis réévaluer la trajectoire à partir des résultats. Le plan doit rester compréhensible par les équipes qui maintiendront l’application.