Réécrire une application ancienne sans casser le métier : la méthode des tests de parité

Votre application tourne depuis des années. Elle est lente, difficile à faire évoluer, peut-être plus tout à fait sûre. Mais elle fonctionne, et votre activité en dépend. La moderniser fait peur, et cette peur est justifiée : beaucoup de réécritures échouent pour la même raison.

Le vrai risque : les règles métier invisibles

Une application ancienne contient des années de décisions : un calcul de montant particulier, une exception pour un type de client, un document généré dans un cas précis. Ces règles métier sont rarement toutes documentées. Elles vivent dans le code, et dans la tête de quelques utilisateurs.

Lors d’une réécriture « d’un seul coup », une partie de ces règles est oubliée. On ne le découvre qu’après la mise en service, quand un client reçoit une facture fausse ou qu’un dossier se bloque.

Le principe des tests de parité

Un test de parité décrit un comportement de l’application vu de l’extérieur : quand on fait ceci, on doit obtenir cela. Par exemple : « quand une facture est entièrement payée, la commande passe au statut soldée ».

L’idée clé est simple :

1. On écrit le test en langage métier, sans dépendre de la technique.
2. On le fait d’abord tourner sur l’ancienne application, pour vérifier qu’il décrit bien la réalité.
3. On fait tourner exactement le même test sur la nouvelle application. Tant qu’il ne passe pas, la nouvelle version n’est pas prête.

Concrètement, les tests s’appuient sur une petite couche intermédiaire qui sait « parler » à l’ancienne application, puis une autre qui sait parler à la nouvelle. Les tests eux-mêmes ne changent pas. C’est ce qui en fait une preuve solide.

La méthode, étape par étape

1. Inventorier les comportements critiques avec les utilisateurs : ce qui ne doit jamais casser (calculs, statuts, documents, droits d’accès).
2. Écrire les tests de parité pour ces comportements, en commençant par les plus importants.
3. Les valider sur l’ancienne application : chaque test doit passer, sinon c’est qu’on a mal compris la règle.
4. Reconstruire module par module. Chaque partie réécrite doit passer les mêmes tests que l’ancienne.
5. Basculer quand tous les tests passent, avec une reprise des données vérifiée et un suivi rapproché des premières semaines.

« Bug ou règle ? » : la question qui revient

En écrivant les tests, on découvre toujours des comportements étranges. Certains sont des bugs que tout le monde contourne depuis des années. D’autres sont des règles que quelqu’un a voulues un jour.

La bonne réponse n’est pas technique : c’est une décision métier. On liste ces cas, on les tranche avec le responsable de l’activité, et on documente chaque décision. La nouvelle application corrige les bugs volontairement, et conserve les règles en connaissance de cause.

Ce que vous y gagnez

• De la confiance : vous savez, preuve à l’appui, que la nouvelle application fait ce que faisait l’ancienne.
• Un avancement mesurable : le nombre de tests qui passent sur la nouvelle version indique où en est le projet.
• Un filet de sécurité pour l’avenir : les tests restent, et protègent chaque évolution future.

En résumé

Moderniser une application n’a pas à être un saut dans le vide. Avec des tests de parité, on avance étape par étape, sans perdre une seule règle métier, et sans interrompre votre activité.

Votre application vieillit ? Un appel découverte de 30 minutes permet de voir si cette approche convient à votre situation.