Logiciel interne qui n'est plus maintenu : comment réussir sa refonte

Beaucoup d'entreprises font tourner une partie de leur activité sur un logiciel développé il y a des années. Un outil maison, construit sur mesure par un prestataire ou par un développeur interne, qui a longtemps rendu exactement le service attendu.

Puis le prestataire a fermé, le développeur est parti, la technologie a vieilli. Le logiciel fonctionne encore, mais plus personne ne sait vraiment comment, et chacun évite d'y toucher. Cet article explique pourquoi cette situation se dégrade toute seule, et comment en sortir sans arrêter l'activité.

Un logiciel qui marche n'est pas un logiciel sain

Le réflexe est compréhensible : tant que l'outil tourne, pourquoi y toucher ? Le problème est qu'un logiciel ne vieillit pas seul. Tout ce qui l'entoure évolue : le système d'exploitation, le navigateur, la base de données, les bibliothèques sur lesquelles il repose, et les outils avec lesquels il échange.

Un logiciel non maintenu ne reste donc pas stable : il prend du retard sur son environnement, un peu plus chaque mois. Il tient jusqu'au jour où une mise à jour de poste, un changement de serveur ou une nouvelle version d'un outil voisin le fait tomber. Et ce jour-là, il n'y a plus personne pour le relever rapidement.

Les signaux qui doivent alerter

Plus personne ne connaît le code. Le prestataire a disparu ou ne répond plus, le développeur interne est parti, la documentation est absente ou périmée. Chaque correction devient une enquête.

La technologie n'est plus supportée. Le langage, le framework ou la base de données ne reçoivent plus de correctifs de sécurité. Les failles connues restent ouvertes, et elles sont précisément celles que les attaques automatisées recherchent.

L'outil dépend d'une machine précise. Un serveur ancien dans un placard, un poste qu'on n'éteint jamais, un navigateur qu'il ne faut surtout pas mettre à jour. Le jour où cette machine tombe en panne, l'activité s'arrête avec elle.

On contourne au lieu de corriger. Les nouveaux besoins sont traités dans des tableurs à côté du logiciel, parce que le faire évoluer paraît trop risqué. Le système d'information se fragmente, et les mêmes données sont saisies deux fois.

Les utilisateurs ont peur des mises à jour. Personne n'ose installer quoi que ce soit, de crainte de casser l'outil. C'est le signe le plus clair qu'il n'est plus maîtrisé.

Aucun de ces signaux n'impose d'agir dans la semaine. Mais chacun réduit la marge de manœuvre, et ils se cumulent. Le bon moment pour lancer une refonte est celui où l'ancien outil tourne encore : on peut alors le remplacer calmement, en s'appuyant sur lui. Attendre la panne revient à refaire le logiciel dans l'urgence, sans pouvoir consulter l'original, avec une activité à l'arrêt pendant ce temps.

Ce que l'ancien logiciel a de précieux

Un vieux logiciel n'est pas qu'un problème : c'est aussi une mine. Il contient des années de règles métier, d'exceptions et de cas particuliers que l'entreprise a affinés au fil du temps, souvent sans jamais les écrire ailleurs. Il contient aussi les données accumulées, qui sont souvent ce que l'entreprise a de plus précieux.

Une refonte réussie commence par reconnaître cet acquis. Le but n'est pas de réinventer le métier, mais de le transporter sur une base saine, en gardant ce qui fonctionne et en profitant du passage pour retirer ce qui ne sert plus.

Pour reconstituer ce que fait l'outil, l'accès au code est utile mais pas indispensable. Le logiciel en fonctionnement, ses écrans, ses exports, ses données et surtout les personnes qui s'en servent tous les jours suffisent à décrire ce qu'il doit continuer à faire.

Tout réécrire ou remplacer progressivement

Deux stratégies s'opposent, et le choix entre elles pèse lourd sur le risque du projet.

La réécriture complète consiste à reconstruire tout le logiciel, puis à basculer d'un coup le jour où le nouveau est prêt. Elle paraît plus simple à organiser. Elle est en réalité la plus risquée : pendant toute la durée du projet, rien de nouveau n'est utilisé, les écarts avec l'ancien outil ne se découvrent qu'à la fin, et la bascule concentre tous les problèmes sur une seule journée. Elle reste adaptée à un outil de petite taille.

Le remplacement progressif consiste à reconstruire le logiciel module par module. Le nouveau prend en charge une fonction, puis une autre, pendant que l'ancien continue d'assurer le reste. Les deux cohabitent le temps nécessaire, en partageant les données ou en se les échangeant. Chaque étape est mise en production et utilisée pour de vrai avant de passer à la suivante.

Cette seconde approche demande un peu plus de travail de raccordement entre l'ancien et le nouveau. En échange, elle livre de la valeur dès les premières semaines, elle permet de corriger le tir en cours de route, et l'ancien logiciel peut être éteint le jour où il ne fait plus rien, sans bascule brutale.

La reprise des données, le poste qu'on sous-estime

Quelle que soit la stratégie, les données de l'ancien logiciel doivent passer dans le nouveau. C'est rarement une simple copie : les formats ont changé, des doublons se sont accumulés, certains champs ont été détournés de leur usage d'origine au fil des années.

Ce travail se prépare avec une personne du métier, qui sait quelles données font foi et lesquelles peuvent être abandonnées. Il se teste sur des copies avant la mise en production, et il se chiffre dès le départ : c'est l'un des postes qui font varier le budget, comme le détaille notre article sur le prix d'une application métier.

Éviter l'effet tunnel

La plupart des refontes qui échouent ne manquent pas de compétences : elles s'éternisent. Le projet part pour quelques mois, découvre en route des fonctions oubliées, accumule les ajouts, et l'ancien logiciel continue de tourner faute d'une date de bascule crédible.

Trois habitudes limitent ce risque :

1. Valider le périmètre avant de développer, sur un prototype visuel qui montre les écrans et les parcours du futur outil. Ce qui manque se voit tout de suite, et pas au moment de la recette.
2. Livrer par étapes courtes, chacune utilisable en production. Une refonte qui ne livre rien pendant des mois est une refonte en danger.
3. Profiter de la refonte, sans tout réinventer. Retirer les fonctions mortes et corriger les irritants connus, oui. Ajouter en route tous les souhaits accumulés depuis dix ans, non : ils viendront après, une fois la base saine.

Par où commencer

Faites l'inventaire de ce que vous savez : ce que fait le logiciel, qui s'en sert, sur quelle machine il tourne, et ce qui vous inquiète le plus. Quelques captures d'écran et un export des données suffisent pour un premier échange.

Chez LPR Studio, ce premier échange débouche sur un prototype visuel gratuit du futur outil, présenté en visio sous 5 jours ouvrés. Il sert de point de départ pour découper la refonte en étapes et choisir la formule adaptée : forfait à prix fixe, ou abonnement qui inclut la maintenance et les évolutions, pour que l'outil ne retombe pas dans l'abandon.