Moderniser un logiciel ancien sans arrêter l'entreprise

Un système ancien n'est pas un système raté

C'est un système qui a survécu. Pendant que d'autres projets étaient abandonnés, celui-là a tourné tous les jours, absorbé les changements de réglementation, encaissé les cas particuliers. Chaque règle bizarre qu'il contient a une histoire, et souvent une bonne raison.

C'est précisément ce qui rend sa modernisation délicate. Le code est la seule documentation à jour de la façon dont l'entreprise travaille réellement. Le jeter pour repartir d'une page blanche, c'est jeter avec lui vingt ans de décisions que plus personne ne sait reconstituer.

Cinq signes qu'il est temps

L'âge n'est pas un motif en soi. Un logiciel de 2005 qui fait son travail et que quelqu'un sait maintenir n'a pas besoin d'être touché. Les vrais signaux sont ailleurs :

• Une seule personne sait le faire évoluer. Et vous retenez votre souffle chaque fois qu'elle prend des vacances.
• Il ne tourne plus que sur une machine qu'on n'ose pas redémarrer, ou sur une version du système d'exploitation qui ne reçoit plus de correctifs de sécurité.
• Les utilisateurs tiennent des tableurs en parallèle « parce que le logiciel ne sait pas le faire ». Chaque contournement est une donnée qui échappe au système.
• Ajouter une fonction coûte anormalement cher, ou devient impossible : pas d'accès mobile, pas d'échange avec les autres applications, pas de rapport exploitable.
• Un éditeur a mis fin au support d'une brique dont vous dépendez, et l'assurance ou l'audit commencent à poser des questions.

Si vous en cochez un seul, il est encore temps d'y réfléchir tranquillement. Si vous en cochez trois, le calendrier ne vous appartient déjà plus tout à fait.

Réécrire d'un coup, ou reprendre par étapes ?

C'est la décision du projet, et elle se prend au début.

La réécriture intégrale est séduisante sur le papier : on repart propre, sans compromis. Dans les faits, elle immobilise l'équipe pendant des mois sans rien livrer d'utilisable — pendant que l'ancien système, lui, continue d'évoluer parce que l'entreprise n'a pas cessé de tourner. Le nouveau court après une cible mouvante, et le jour de bascule concentre tout le risque sur une seule date.

La reprise progressive prend le problème autrement : l'ancien et le nouveau cohabitent sur la même base de données. On reprend un module, on le vérifie, on le met en service ; les utilisateurs continuent d'utiliser l'ancien pour tout le reste. Puis le suivant. L'ancien système se vide progressivement de sa substance jusqu'à ce que plus personne ne l'ouvre.

C'est plus lent à annoncer et beaucoup plus sûr à vivre. Chaque étape apporte une valeur immédiate, et un arrêt du projet à mi-chemin — cela arrive, un budget se déplace — vous laisse avec des modules modernisés en service, pas avec un chantier inachevé.

Comment nous procédons

• Lire le système existant. Pas seulement le code : les écrans, les états imprimés, la base de données, et surtout les personnes qui s'en servent. Ce sont elles qui connaissent les règles que le code applique sans les expliquer.
• Cartographier et ordonner. Quels modules, quelles dépendances, lesquels reprendre en premier. On commence rarement par le plus gros : on commence par celui qui prouve que la mécanique fonctionne.
• Reprendre module par module. Chaque écran porté est comparé à l'ancien sur vos données réelles, pas sur un jeu d'essai commode. Si les deux ne donnent pas le même résultat, on comprend pourquoi avant d'aller plus loin.
• Consigner chaque particularité rencontrée. Les comportements suspects sont relevés et soumis à votre décision, pas corrigés en silence. Vous seul savez si telle règle bizarre est une anomalie ou une exigence d'un client important.
• Accompagner la bascule. Formation, présence pendant les premières semaines, puis soutien continu.

Ce qu'on garde, ce qu'on abandonne

On garde les données et les règles. La base existante reste en place et devient le point de rencontre entre l'ancien et le nouveau. Il n'y a donc pas de grande migration de données à risque : les deux systèmes lisent et écrivent au même endroit.

On abandonne les contournements. Les tableurs parallèles, les doubles saisies, les impressions recopiées à la main. Ce sont eux qui coûtent le plus cher chaque jour, et personne ne les regrette.

On documente ce qui ne l'était pas. À la fin, vous ne possédez pas seulement un système à jour : vous possédez enfin une description écrite de la façon dont votre entreprise travaille. C'est souvent le bénéfice le plus durable.

Combien de temps, combien ça coûte

Le facteur déterminant n'est pas l'âge du système ni le langage dans lequel il est écrit : c'est le nombre d'écrans et la densité des règles métier. Un logiciel de gestion avec trois cents écrans et des calculs réglementaires ne se reprend pas comme un outil interne de vingt écrans.

En pratique, un premier module utilisable sort en quelques semaines. Un système d'entreprise complet se reprend sur plusieurs mois à quelques années — mais réparti en étapes qui produisent chacune leur valeur, et non en une facture unique au bout du tunnel.

Avant tout engagement, nous produisons un cadrage écrit : ce qui est à faire, ce qui ne l'est pas, dans quel ordre, à quel coût. Vous décidez sur une base claire, et ce document vous reste que nous réalisions la suite ou non.

Questions fréquentes

Faut-il tout réécrire d'un coup ou migrer par étapes ?

Par étapes, dans la très grande majorité des cas. La réécriture intégrale ne se justifie que pour de petits systèmes, ou quand la base de données elle-même doit disparaître.

Perd-on les données de l'ancien système ?

Non. La base existante reste en place pendant toute la transition, justement pour éviter une migration de données à risque.

Que devient le comportement bizarre que tout le monde connaît ?

Il est relevé, consigné, et soumis à votre décision. Le reproduire aveuglément serait une erreur ; le corriger sans demander en serait une autre. C'est à vous de trancher, en connaissance de cause.

Peut-on moderniser sans interrompre l'exploitation ?

Oui — c'est le principal argument de la reprise progressive. Il n'y a pas de journée de bascule générale, donc pas de risque concentré sur une seule date.

Et si nous voulons changer de fournisseur en cours de route ?

Vous le pouvez. Le code est lisible, documenté, et vous appartient. Un système qu'on ne peut confier à personne d'autre est un système dont vous êtes prisonnier — c'est exactement la situation dont vous cherchez à sortir.