Pour réécrire un logiciel legacy sans documentation, on ne part pas d'un cahier des charges qui n'existe pas : on part du code en production. On en extrait les règles métier en langage clair, on les fait valider une par une par les gens qui utilisent l'outil, puis on réécrit avec un test automatisé par règle, et on fait tourner l'ancien et le nouveau en parallèle avant de basculer. C'est ce que nous avons fait pour eRcane : vingt ans de PHP réécrits en Go, bascule à J+19 sans interruption.
La méthode : du code vers les specs, pas l'inverse
On appelle ça code to specs. L'idée est simple : le code en production est la seule spécification complète et à jour qui existe. Il faut la lire, pas la deviner. Voici les six étapes, telles qu'on les pratique.
1. Lire le code et en extraire les règles
Un outil d'analyse assisté par IA parcourt le code source et en sort des règles métier en français : « une mesure datée de plus de N jours est signalée comme périmée », « un utilisateur usine ne voit que sa propre usine », etc. Chaque règle garde la référence exacte du code d'origine (fichier, fonction), pour pouvoir vérifier. Sur eRcane, 34 règles sont sorties de cette lecture.
2. Faire valider les règles par les utilisateurs
C'est l'étape que les projets sautent, et c'est la plus importante. On présente chaque règle à la personne qui utilise l'outil, avec une question simple : « c'est bien ça, et on le garde ? ». Trois réponses possibles : on garde, on corrige, on abandonne. Le résultat est un référentiel de règles validées, écrit en langage métier, que tout le monde comprend.
3. Montrer des écrans avant d'écrire du code
Des écrans statiques, sans logique derrière, qui montrent à quoi ressemblera chaque page du nouvel outil. Le client réagit sur du concret. Pour eRcane, 15 écrans ont été validés avant le premier commit.
4. Réécrire avec un test par règle
Chaque règle validée devient un test automatisé, écrit avant ou avec le code qui l'implémente. Le test porte le nom de la règle. Résultat : à tout moment, on peut prouver que le nouveau logiciel respecte les 34 règles, en lançant une commande. Sur eRcane, 95 fonctions de test couvrent les 34 règles.
5. Faire tourner l'ancien et le nouveau en parallèle
Le nouvel outil est mis en ligne sur une adresse de test, alimenté par les mêmes données que l'ancien. Le client compare, page par page, pendant plusieurs jours. Chaque écart est soit une règle mal comprise (on corrige), soit un bug de l'ancien outil (on décide ensemble si on le garde).
6. Basculer, et garder l'ancien sous la main
Quand la comparaison est concluante, on fait pointer le domaine vers le nouveau. L'ancien reste accessible quelques semaines, au cas où. Sur eRcane, la bascule a eu lieu 19 jours après la réunion de cadrage, en pleine campagne sucrière, sans interruption.
Ce que ça donne dans le temps : le cas eRcane
Le suivi en temps réel des deux sucreries de La Réunion tournait sur un PHP de 2006, enrichi pendant vingt ans, sans documentation. Voici la chronologie, en jours calendaires à partir de la réunion de cadrage (J0) :
| Jour | Ce qui se passe |
|---|
| J-11 | Écrans statiques envoyés au client |
| J-4 | Accord de principe |
| J0 | Réunion de cadrage |
| J+3 | Analyse du code, extraction des 34 règles |
| J+4 | Premier commit |
| J+7 | Version en ligne, testée par le client |
| J+7 à J+18 | Comparaison page par page avec l'ancien outil |
| J+18 | Procès-verbal de recette |
| J+19 | Bascule du domaine, sans interruption |
Le nouveau site : 4 931 lignes de Go écrites à la main, dont 2 096 de tests, sans framework, hébergé en conteneur. Le détail est dans le cas client eRcane.
Faut-il vraiment réécrire ? Les cas où non
Réécrire n'est pas toujours la bonne réponse. Avant de lancer un projet, on pose trois questions :
- L'outil pose-t-il un vrai problème ? Lent, impossible à faire évoluer, faille de sécurité, dépendance à une personne. Si la réponse est « il est moche », ce n'est pas un problème.
- Le périmètre est-il stable ? Si l'entreprise ne sait pas encore ce qu'elle veut faire de l'outil dans un an, on commence par le cadrage, pas par la réécriture.
- Peut-on faire moins ? Parfois, extraire les règles et documenter l'existant suffit à débloquer la situation. Parfois, une seule partie du logiciel mérite d'être refaite.
C'est pour ça que ce type de projet démarre chez nous par un audit du code : on lit, on extrait les règles, on vous dit ce qu'on a trouvé et ce que ça coûterait de réécrire. Le prix de la réécriture se fixe après cet audit, pas avant, parce que tout dépend de ce qu'il y a dans le code.
