Moderniser un logiciel ancien sans tout arrêter

Beaucoup d’organisations reposent sur un logiciel métier développé il y a des années : il fonctionne, les équipes le connaissent, mais il devient difficile à faire évoluer, à sécuriser ou à relier aux nouveaux outils. La tentation est grande de tout réécrire d’un coup. C’est rarement la voie la plus sûre : une refonte complète immobilise des équipes longtemps et concentre le risque sur une bascule unique. Une modernisation progressive remplace le système par étapes, sans interrompre l’activité.

Cartographier l’existant

Avant de changer quoi que ce soit, il faut savoir ce que fait réellement le logiciel, pas seulement ce que dit sa documentation.

• Fonctions critiques : celles dont l’arrêt bloque la facturation, la production ou le service aux clients.
• Interfaces : les échanges avec d’autres systèmes, les fichiers importés ou exportés, les traitements programmés la nuit.
• Données : leur structure, leur qualité, les règles métier parfois cachées dans le code ou dans la base.
• Usages réels : les écrans et rapports vraiment utilisés, et ceux que plus personne n’ouvre.

Les personnes qui utilisent le logiciel au quotidien sont la meilleure source d’information. Interrogez-les tôt : elles connaissent les contournements et les cas particuliers qu’aucun document ne décrit.

Prioriser les étapes

La cartographie permet de découper le système en parties que l’on peut moderniser séparément. Pour choisir par où commencer, comparez chaque partie selon deux axes :

Partie du système	Valeur d’une modernisation	Risque de la changer
Module peu couplé, souvent modifié	Élevée	Faible
Rapports et exports	Moyenne	Faible
Cœur des calculs métier	Élevée	Élevé

Un bon premier périmètre est utile et peu risqué : il prouve la démarche, rassure les équipes et révèle les difficultés techniques avant d’attaquer le cœur du système. La nouvelle partie fonctionne à côté de l’ancienne, et le trafic bascule progressivement de l’une à l’autre.

Tester les échanges

Pendant la transition, l’ancien et le nouveau système cohabitent. Les tests portent donc autant sur leurs échanges que sur chaque partie isolée :

1. Tests de non-régression : les résultats du nouveau module sont comparés à ceux de l’ancien, sur des cas réels.
2. Tests d’interface : chaque échange de données entre les deux systèmes est vérifié dans les deux sens.
3. Répétition de la reprise des données : la migration est jouée plusieurs fois sur une copie, jusqu’à ce qu’elle soit fiable et que sa durée soit connue.
4. Fonctionnement en parallèle : quand c’est possible, les deux versions tournent ensemble pendant une période d’observation, et les écarts sont analysés.

Prévoir le retour arrière

Chaque bascule doit pouvoir être annulée. Ce plan se rédige avant la mise en production, pas pendant l’incident.

• Conditions de bascule : les critères qui autorisent le passage, validés par les responsables métier et techniques.
• Surveillance : les indicateurs suivis dans les heures et les jours qui suivent (erreurs, temps de réponse, volumes traités).
• Seuils de retour : les situations qui déclenchent le retour à l’état précédent, et qui prend la décision.
• Procédure de retour : les étapes pour revenir en arrière, y compris pour les données saisies entre-temps.

Un retour arrière bien préparé n’est pas un échec : c’est ce qui permet d’avancer par petites étapes avec confiance.

En résumé

Moderniser sans arrêter l’activité repose sur une idée simple : ne jamais parier tout le système sur une seule bascule. Cartographiez l’existant avec ceux qui l’utilisent, commencez par une partie utile et peu risquée, testez les échanges et préparez chaque retour arrière. Un diagnostic de l’existant permet de construire cette trajectoire et d’en estimer les étapes avant de s’engager.