Réécrire un logiciel legacy sans cahier des charges est possible à une condition : extraire les règles métier du code existant, les faire valider par le client, et les convertir en tests avant d'écrire la première ligne du nouveau code. C'est ce qu'on appelle code to specs. Le langage cible n'a plus d'importance, puisque la spec ne dépend pas de lui.
Nous l'avons appliqué sur le site de suivi des sucreries de La Réunion, un PHP de 2006 sans documentation, réécrit en Go et mis en production trois semaines après le cadrage, en pleine reprise de campagne. Cet article détaille la méthode, ce que l'IA y fait, et ce qu'elle n'y fait pas.
Au sommaire
Pourquoi les refontes de legacy échouent
Un logiciel qui tourne depuis quinze ou vingt ans a accumulé des règles que plus personne ne connaît. Un arrondi particulier. Un seuil d'alerte ajouté après un incident. Un cas limite traité un jour de 2013 à la demande d'un utilisateur parti depuis. Rien de tout ça n'est écrit ailleurs que dans le code, et souvent dans un commentaire daté au milieu d'une fonction de six cents lignes.
Face à ça, les refontes prennent l'un de deux chemins, et les deux sont mauvais.
Repartir des écrans
On refait ce qu'on voit, en plus joli. On livre. Et on découvre en production que trois comportements ont disparu, parce qu'ils ne se voyaient que dans un cas précis que personne n'a pensé à tester. Le client, lui, s'en aperçoit tout de suite.
Relire le code ligne à ligne
On documente tout à la main avant de réécrire. C'est la bonne idée, mais elle coûte le prix du projet avant d'avoir produit quoi que ce soit d'utilisable. Presque personne ne la finance, donc presque personne ne le fait.
Le troisième chemin consiste à faire faire la relecture par une IA, mais pas n'importe comment : pas pour qu'elle réécrive le code, pour qu'elle en extraie les règles, dans un format qu'un client peut relire et contester.
Ce qu'est code to specs, concrètement
Code to specs prend en entrée une copie du code en production et produit trois livrables, dans cet ordre. Aucun des trois n'est du code.
| Livrable | Ce qu'il contient | Qui le lit |
|---|---|---|
| 1. L'analyse de l'existant | Architecture, circuit des données, dette technique, valeurs métier dispersées, points de vigilance pour la migration, questions à trancher. | Le CTO et le client, pour cadrer. |
| 2. Les règles métier | Une règle par comportement, nommée, en français, avec ses critères d'acceptation et la référence exacte du code dont elle vient. | Le client, qui valide ou conteste chaque règle. |
| 3. Les specs du nouveau | Ce qui n'existait pas et qu'on ajoute : comptes, back-office, mobile. Avec des écrans statiques et un plan de tests. | Le client, sur des écrans qu'il manipule. |
Le point décisif est le deuxième livrable. Une règle qui dit « si l'écart entre l'heure du fichier et l'heure courante dépasse cinq minutes, l'indicateur passe en alerte » peut être lue, comprise et validée par quelqu'un qui n'ouvrira jamais le code. Et parce qu'elle référence la ligne d'origine, on peut toujours retourner vérifier.
Une fois validées, ces règles ne dépendent d'aucune technologie. On peut réécrire en Go, en TypeScript, en Python. La spec reste la même, et les tests qui en découlent aussi.
La méthode en six étapes
Copier le code en production, pas le dépôt
Ce qui tourne fait foi. Un dépôt peut avoir divergé de la production depuis des années. On part de ce que les utilisateurs utilisent réellement, fichiers de données compris.
Produire l'analyse de l'existant
Une journée. Elle sert à cadrer avec le client et à repérer ce qui doit absolument être conservé, souvent des comportements que le client lui-même avait oubliés.
Extraire les règles et les faire valider
Chaque règle porte un identifiant, un énoncé, des critères d'acceptation et sa référence dans le code. Le client relit la liste et tranche : c'est une règle à conserver, ou c'est un bug qu'on ne reproduit pas.
Spécifier le nouveau sur des écrans statiques
Ce qu'on ajoute se valide comme sur n'importe quelle V1 : des écrans cliquables, des specs courtes, un plan de tests. Le client navigue avant qu'une ligne de back-end existe.
Réécrire, une règle égale un test
Chaque règle validée devient un test nommé d'après elle, avec un cas par critère. Les jeux d'essai sont les vraies données du site d'origine. Le développement assisté par IA travaille contre ces tests, pas contre une intention floue.
Comparer les deux, puis basculer
Ancien et nouveau côte à côte, alimentés par les mêmes données, page par page. Une période de coexistence, un PV de recette, et seulement ensuite la bascule du domaine.
Sur le site des sucreries, ça donne : 34 règles extraites et validées, 15 écrans statiques, 95 fonctions de test, et une bascule 19 jours après la réunion de cadrage. Le déroulé complet est dans le cas client.
De la règle validée au test automatisé
Voici une règle réelle du projet, et le test qui en découle. La règle vient d'une fonction du site d'origine qui classe l'ancienneté des données en quatre niveaux. Le client l'a validée telle quelle. Le test reprend ses quatre critères, en testant chaque borne.
Ce qui compte ici, ce n'est pas le test en lui-même. C'est que le client a validé les quatre critères sans lire une ligne de code, et que le nouveau site ne peut plus s'en écarter sans que la suite de tests le signale. Si dans deux ans quelqu'un change le seuil, il saura exactement quelle règle il touche, et qui l'a validée.
Pourquoi les jeux d'essai réels changent tout
Sur un legacy, les données ont des défauts que personne ne documente : encodages mélangés, libellés en double, fichiers tronqués pendant un dépôt. Tester avec des données inventées, c'est tester un système qui n'existe pas. Tester avec les fichiers réels, c'est vérifier que le nouveau site encaisse exactement ce que l'ancien encaissait, y compris ce qui n'aurait jamais dû arriver.
Ce que l'IA fait, et ce qu'elle ne décide pas
L'IA lit vingt ans de code en quelques heures, suit chaque variable jusqu'à son affichage, repère les seuils codés en dur et les commentaires datés, et en sort des règles rédigées. C'est un travail de fourmi qu'un humain ne fait bien ni vite. Là-dessus, elle est irremplaçable.
En revanche, elle ne décide pas ce qui est une règle métier et ce qui est un bug hérité. Un arrondi bizarre peut être une exigence comptable ou une erreur de 2011. Un seuil peut être une valeur réglementaire ou un chiffre mis là pour tester et jamais retiré. Seul le client peut trancher, et c'est pour ça que la validation règle par règle n'est pas une formalité. C'est l'étape où le projet se joue.
Un logiciel que plus personne n'ose toucher ?
On regarde votre existant en 30 minutes et on vous dit ce qu'on en sortirait. Sans cahier des charges, puisque vous n'en avez pas.
Points clés à retenir
- Le code en production est la seule spécification fiable d'un legacy. Il faut le traduire en règles avant de le réécrire.
- Code to specs produit trois livrables, aucun n'est du code : l'analyse de l'existant, les règles métier avec critères d'acceptation, les specs du nouveau.
- Le client valide chaque règle en français, et tranche entre règle à conserver et bug à ne pas reproduire.
- Chaque règle validée devient un test nommé d'après elle. La réécriture peut alors se faire dans n'importe quel langage.
- Une réécriture se prouve par comparaison avec l'ancien, sur les mêmes données, avant la bascule.
Questions fréquentes
Faut-il avoir le code source pour faire du code to specs ?
Oui, et de préférence la copie de ce qui tourne en production, données comprises. Sans le code, on retombe sur la refonte à partir des écrans, avec tous ses angles morts. Si le code est chez un ancien prestataire, le récupérer est la première étape du projet.
Est-ce que ça marche sur n'importe quel langage d'origine ?
PHP, Java, .NET, VB, Access, Delphi, COBOL : le principe est le même. Le code est lu pour ce qu'il fait, pas pour ce qu'il est. Ce qui change, c'est le temps de lecture, et c'est justement ce que l'IA absorbe.
Pourquoi ne pas laisser l'IA réécrire directement le code ?
Parce qu'on obtiendrait un code neuf qui reproduit fidèlement les bugs de l'ancien, sans que personne ne sache lesquels. L'étape de validation des règles par le client est ce qui sépare une traduction d'une refonte. Elle est courte, et elle est le cœur de la valeur.
Combien de temps prend une refonte de ce type ?
Pour un outil métier de taille moyenne, comptez de trois à huit semaines entre le cadrage et la mise en production, dont une part importante de validation avec le client. Sur le site des sucreries, la bascule a eu lieu dix-neuf jours après le cadrage. Le facteur qui pèse le plus n'est pas la taille du code, c'est la disponibilité du client pour valider les règles.
Que devient l'ancien site pendant la transition ?
Il reste en ligne. Les deux versions tournent en parallèle sur les mêmes données le temps de comparer et de faire signer la recette. La bascule du nom de domaine est la dernière étape, jamais la première.
Pour aller plus loin
Cas client eRcane
Vingt ans de code réécrits sans cahier des charges, de J-11 à J+19.
Lire le cas clientLivrer une V1 avec l'IA sans vibe coding
La même exigence de règles validées, appliquée à un produit neuf.
Lire l'articleCTO interne ou externe
Qui pilote une refonte quand il n'y a pas de direction technique en interne.
Lire l'articleAudit gratuit d'une app existante
Un premier regard automatique sur l'hébergement, la sécurité et le SEO d'une URL.
Lancer l'audit