Retrouver les règles d’un logiciel ancien avant de le reprendre

Blog · Laurent Lécluse · 5 septembre 2026

Un logiciel ancien fonctionne parfois depuis si longtemps que ses utilisateurs ne distinguent plus les règles prévues, les habitudes acquises et les contournements. Au moment de le remplacer, une question devient décisive : que faut-il réellement préserver ?

Mes travaux de modernisation d’un logiciel de gestion de caisse m’amènent à retrouver des règles dans le code existant pour préparer leur reprise dans une application web. Voici les questions qui structurent cette démarche.

Découvrir le chantier de modernisation

Partir d’une opération complète

Je commence par une action que les utilisateurs savent décrire : créer un dossier, modifier une information, valider une opération ou produire un document.

Un écran isolé montre les champs et les boutons. Le parcours complet fait apparaître les préconditions, les changements d’état et les conséquences dans les autres parties de l’application.

Pour comprendre ce parcours, je cherche notamment à savoir :

• Quelles informations doivent déjà exister ?
• Qui peut effectuer l’opération ?
• Quels calculs ou contrôles se déclenchent ?
• Que devient le résultat : un état, un document, un échange avec un autre outil ?
• Comment corrige-t-on une erreur ensuite ?

Croiser ce que l’on raconte et ce que fait le logiciel

Les utilisateurs connaissent la finalité du travail et les situations qui leur posent problème. Le code décrit le comportement implémenté. Les données montrent comment les informations ont été enregistrées et reliées.

Ces trois sources peuvent se contredire. Une option paraît facultative à l’écran, alors qu’un traitement ultérieur en dépend. Un utilisateur applique une correction manuelle parce qu’une exception n’a jamais été intégrée.

Une contradiction devient une question à résoudre avec les personnes concernées. Il faut décider si le comportement existant correspond encore à une règle utile, s’il révèle un défaut ou s’il répond à une contrainte désormais disparue.

Écrire un exemple qui distingue deux comportements

Prenons un cas pédagogique : dans une application de gestion, une remise peut être calculée avant ou après le plafonnement d’un montant. Sur de petites valeurs, les deux traitements produisent parfois le même résultat. Sur d’autres, ils divergent.

Un exemple bien choisi permet alors de poser une question précise : « Dans cette situation, quel montant doit-on obtenir, et pourquoi ? »

La réponse sert à décrire le comportement attendu et à préparer un contrôle. Elle évite de trancher une règle métier uniquement parce qu’une version du code est plus facile à écrire.

Distinguer ce que l’on conserve et ce que l’on change

Pour chaque parcours repris, je cherche à rendre explicites trois choses :

1. Les règles que la nouvelle application doit conserver.
2. Les changements souhaités par les utilisateurs ou les responsables.
3. Les questions encore ouvertes qui demandent une investigation.

Cette distinction facilite les démonstrations. On peut examiner une différence et savoir si elle correspond à une amélioration décidée ou à un comportement perdu pendant la reprise.

Préparer la transition autant que les nouveaux écrans

Les données existantes doivent retrouver une place compréhensible dans la nouvelle application. Les identifiants, les relations, les historiques et les valeurs particulières peuvent demander un travail de correspondance.

Je cherche à définir les contrôles qui permettront d’examiner cette reprise : dossiers représentatifs, totaux utiles, informations indispensables et exceptions connues. La mise en service se prépare à partir de ces éléments et des contraintes du projet.

Le résultat attendu d’une première analyse est concret : un parcours décrit, des règles identifiées, des exemples de validation et une liste de points à éclaircir. Cela donne une base pour estimer et organiser la modernisation.

Votre logiciel fonctionne encore, mais personne n’ose le faire évoluer ? Nous pouvons commencer par un parcours limité pour retrouver ses règles et examiner les options de reprise.

Faire le point sur un logiciel existant · Me parler de votre situation