Moderniser un logiciel vieillissant
Moderniser un logiciel ancien consiste à le faire évoluer vers des technologies maintenues sans interrompre l'activité qu'il supporte. Trois voies existent : la reprise du code existant, la reconstruction progressive module par module, ou le remplacement complet.
Le logiciel qui tient encore
Il a été développé il y a dix ou quinze ans. Il fait tourner l'activité tous les jours. Mais celui qui l'a écrit n'est plus là, la technologie n'est plus maintenue, et chaque demande d'évolution se heurte au même mur.
Les signes qui imposent une décision :
- Plus personne ne sait comment fonctionne une partie du code
- Le logiciel ne tourne que sur d'anciennes versions de système
- Aucune mise à jour de sécurité n'est possible
- Les nouveaux besoins sont refusés parce que trop risqués à implémenter
- Une panne demanderait des jours de rétro-ingénierie
- Le matériel qui l'héberge ne se remplace plus
Pourquoi ne pas simplement tout refaire
La reconstruction complète est la tentation naturelle, et c'est souvent la plus risquée. Un logiciel qui tourne depuis quinze ans contient des règles métier accumulées, des cas particuliers traités un par un, des corrections apportées après des incidents que plus personne ne se rappelle.
Tout réécrire, c'est risquer de perdre cette connaissance. La plupart des échecs de refonte viennent de là : le nouveau logiciel fait 90 % de ce que faisait l'ancien, et les 10 % manquants sont justement ceux qui comptaient.
Les trois voies
- La reprise
- Garder le code existant et le moderniser sur place : mise à jour des composants, sécurisation, ajout de tests. Possible quand le code est lisible et la technologie encore supportée. La moins coûteuse.
- La modernisation progressive
- Remplacer les modules un par un, en gardant l'ancien et le nouveau connectés pendant la transition. Plus long, mais l'activité n'est jamais interrompue et chaque étape est réversible.
- La reconstruction
- Repartir d'une base neuve, en reprenant les données et les règles. Justifié quand la technologie est morte ou le code irrécupérable. Demande une phase d'analyse approfondie de l'existant.
L'audit préalable
Aucune de ces trois voies ne se choisit sans avoir regardé le code. Un audit examine l'état réel : lisibilité, dépendances obsolètes, présence de tests, documentation, complexité des règles.
Il aboutit à une recommandation argumentée et à un chiffrage. Ce document vous appartient, même si vous choisissez ensuite un autre prestataire ou de ne rien faire.
Questions fréquentes
Peut-on moderniser sans interrompre l'activité ?
Oui, c'est même le principe de la modernisation progressive. L'ancien et le nouveau système fonctionnent en parallèle, connectés, et les modules basculent un par un. Chaque étape est réversible si un problème apparaît.
Que faire si personne ne connaît plus le code ?
C'est le cas général. L'audit commence par de la lecture de code et de l'analyse de la base de données. Les règles métier se retrouvent dans le code, dans les données, et dans ce que savent les utilisateurs quotidiens : ces trois sources se recoupent.
Nos données sont-elles récupérables ?
Presque toujours. Même les bases anciennes se lisent, et même un logiciel sans export laisse ses données accessibles au niveau de la base. La difficulté n'est généralement pas l'extraction mais le nettoyage.
Combien coûte un audit de code ?
L'audit est une mission courte et facturée, en amont de tout devis de développement. Son coût dépend de la taille du logiciel et du nombre de technologies impliquées. Il aboutit à un document exploitable qui vous appartient.
Combien de temps prend une modernisation ?
Une reprise se compte en semaines, une modernisation progressive en mois, une reconstruction complète peut dépasser l'année pour un système important. L'audit donne une estimation réaliste avant tout engagement.