Base Access, application WinDev, logiciel Windows installé sur chaque poste, intranet PHP développé il y a quinze ans : de nombreuses entreprises reposent sur un logiciel ancien qui fait très bien son travail… jusqu’au jour où il ne le fait plus. Le développeur est parti, la technologie n’est plus maintenue, et chaque modification devient une prise de risque.
Moderniser un tel logiciel fait peur, et c’est normal : il contient des années de règles métier, et l’activité ne peut pas s’arrêter pendant les travaux. La bonne nouvelle, c’est qu’il existe une méthode pour le faire sans tout casser.
Les signaux qui doivent alerter
- La technologie n’est plus maintenue. Sans correctifs de sécurité, chaque faille découverte reste ouverte. Les vieux outils ne sont pas les seuls concernés : Windows 10 n’est plus pris en charge depuis octobre 2025, et même des technologies récentes ont une date de fin, comme .NET 8, dont le support s’arrête le 10 novembre 2026.
- Plus personne ne sait le faire évoluer. Le code n’est pas documenté, et la connaissance repose sur une seule personne ou sur un ancien prestataire.
- Chaque modification prend des semaines, et casse quelque chose ailleurs.
- Vos équipes contournent l’outil avec des fichiers Excel ou des notes papier.
- Il ne sait pas communiquer : pas d’accès mobile, pas d’API pour le relier à vos autres outils ou à vos clients.
La fausse bonne idée : tout refaire d’un coup
La tentation est grande de repartir de zéro : spécifier un nouveau logiciel complet, le développer pendant un ou deux ans, puis basculer un beau lundi matin. C’est l’approche dite du « big bang », et elle cumule les risques :
- un long tunnel, sans rien à montrer aux utilisateurs ;
- un ancien logiciel qui continue d’évoluer pendant ce temps, et donc une cible qui bouge ;
- des règles métier oubliées, découvertes après la bascule ;
- une reprise des données à haut risque, concentrée sur un seul jour.
La modernisation progressive
L’alternative consiste à construire le nouveau système autour de l’ancien, module par module. Les deux cohabitent pendant la transition ; l’ancien logiciel se vide progressivement de ses fonctions, jusqu’à pouvoir être arrêté. Les architectes logiciels ont baptisé cette approche le « figuier étrangleur », du nom d’une plante qui pousse autour d’un arbre jusqu’à prendre sa place.
1. Faire l’état des lieux
Quelles fonctions sont réellement utilisées, et par qui ? Où sont les données, et comment sont-elles structurées ? Quelles règles de calcul sont enfouies dans le code ? Avec quels outils le logiciel échange-t-il ? Cet audit évite de reproduire des fonctions que personne n’utilise, et d’oublier celles dont tout le monde dépend.
2. Rendre les données accessibles
On place une API devant les données existantes, ou l’on met en place une synchronisation entre l’ancienne et la nouvelle base. C’est ce qui permet aux deux systèmes de cohabiter sans ressaisie.
3. Commencer par le module qui a le plus de valeur
Ce peut être l’accès mobile des équipes terrain, le tableau de bord de la direction, ou le processus qui génère le plus d’erreurs. Les utilisateurs constatent rapidement un bénéfice concret, et le projet gagne leur confiance.
4. Migrer les données avec méthode
Nettoyage, dédoublonnage, correspondance entre anciens et nouveaux champs, puis migrations « à blanc » répétées avant la vraie. Chaque migration est contrôlée : nombre d’enregistrements, totaux, cas particuliers.
5. Basculer module par module
Chaque bascule est préparée et accompagnée d’une formation, et l’ancien module reste consultable pendant quelque temps pour rassurer tout le monde.
Les pièges à éviter
Oublier les règles cachées. Un calcul de prix, une remise particulière, une exception pour un client historique : l’ancien code en contient toujours. Une bonne pratique consiste à rejouer des cas réels dans les deux systèmes et à comparer les résultats.
Copier l’ancien à l’identique. La modernisation est l’occasion de simplifier : supprimer les écrans inutiles, revoir les parcours, abandonner les contournements. Reproduire en version moderne les défauts de l’ancien serait dommage.
Oublier les utilisateurs. Impliquez tôt quelques utilisateurs clés : ils connaissent les subtilités du métier, et ils seront les meilleurs ambassadeurs du nouvel outil.
Ne pas fabriquer la dette technique de demain
Un logiciel moderne vieillit aussi, simplement plus lentement s’il est bien entretenu. Les technologies évoluent vite : Angular publie une version majeure tous les six mois, .NET une version à support long tous les deux ans. Mises à jour régulières, tests automatisés, documentation, surveillance : un budget annuel de maintenance évite de se retrouver, dans dix ans, face au même mur.
C’est tout le sens de la maintenance évolutive que nous proposons avec nos applications métiers : faire grandir le logiciel avec l’entreprise, plutôt que de le laisser se figer.
