eRcane : vingt ans de code
réécrits sans cahier des charges.
Les specs sont sorties du code.

Un tableau de bord que toute une filière consulte en campagne

De juillet à décembre, les deux sucreries de La Réunion broient la canne de toute l'île. Le site d'eRcane affiche leur production au fil de la journée : une page publique avec le cumul de campagne et les tonnages de chaque usine, et une zone réservée aux professionnels, atelier par atelier, alimentée par des fichiers de mesures que les usines déposent sur le serveur toutes les minutes.

Le site faisait le travail depuis 2006. Mais son code, enrichi par couches pendant près de vingt ans, n'était plus documenté nulle part. Les seuils d'alerte, les formats d'affichage, la logique qui signale des données périmées : tout existait, mais uniquement dans le code. Et la campagne suivante redémarrait dans quelques semaines.

Réécrire un legacy, c'est d'abord savoir ce qu'il fait

Les refontes de legacy échouent presque toujours au même endroit. On repart des écrans, on refait plus joli, et on découvre en production que trois règles invisibles ont disparu : un arrondi, un cas limite, une alerte qui ne se déclenchait que dans une situation précise. Personne ne les avait spécifiées, parce que personne ne savait qu'elles existaient.

L'alternative classique, lire le code ligne à ligne et le documenter à la main, coûte le prix du projet avant d'avoir écrit quoi que ce soit. C'est là que notre méthode change la donne : l'IA lit vingt ans de code en quelques heures et en sort les règles en langage clair. Le client les valide une par une. Chaque règle validée devient un test. La réécriture peut alors se faire dans n'importe quel langage, avec une preuve automatique qu'elle respecte l'existant.

L'IA ne décide pas ce qui est une règle et ce qui est un bug hérité. Elle propose, le client tranche. C'est ce qui sépare une extraction de specs d'une simple lecture de code.

Huit étapes, de J-11 à J+19

J0 est la réunion de cadrage. Tout se compte à partir de là.

1. 1

   Écrans statiques et specs du nouveau · J-11

   Avant tout engagement, quinze écrans cliquables avec des données de démonstration, deux documents de specs pour ce qui n'existait pas encore (comptes utilisateurs, back-office, mobile) et un plan de tests de vingt-trois cas. Le client navigue dedans comme dans le futur site.

2. 2

   Accord de principe du client · J-4

   « Dans l'ensemble, ça me convient. » Les ajustements de forme sont notés pour la réunion de cadrage, le fond est validé.

3. 3

   Réunion de cadrage · J0

   Ajustements d'affichage, confirmation des sources de données, modèle de comptes. Tout ce qui s'y décide est reporté dans les specs avant le premier commit.

4. 4

   Code to specs : analyse du code d'origine et extraction des règles · J+3

   Une copie du site en production, et deux livrables. D'abord une analyse structurée : comment les données circulent, où vivent les valeurs métier, quelle dette on hérite, ce qui doit absolument être conservé. Ensuite les règles elles-mêmes : 34 règles métier, nommées, écrites en français, avec leurs critères d'acceptation et la référence du code dont chacune vient. Douze pour la page publique, vingt-deux pour la zone professionnelle. C'est ce document, et pas le code, que le client relit et valide.

   

5. 5

   Réécriture en Go, une règle égale un test · J+4

   Chaque règle validée a son test, nommé d'après elle, avec un cas par critère d'acceptation. Les fichiers de mesures réels du site d'origine servent de jeux d'essai. Le lendemain, la première sucrerie redémarrait sa campagne.

6. 6

   Version en ligne entre les mains du client · J+7

   Trois jours après le premier commit, le client teste sur un environnement en ligne, avec les vrais fichiers envoyés en parallèle aux deux serveurs. Les retours arrivent au fil de l'eau et sont intégrés dans la journée.

7. 7

   Comparaison page par page, mesure par mesure · J+7 à J+18

   L'ancien site et le nouveau, côte à côte, alimentés par les mêmes fichiers. Chaque page de la zone professionnelle est relue en repérant ce qui manque et ce qui est en trop. Une réécriture ne se prouve pas par la confiance, elle se prouve par la comparaison.

8. 8

   PV de recette, puis bascule du domaine · J+18 et J+19

   PV de recette signé. Le lendemain, le nom de domaine pointe vers le nouveau site. L'ancien reste en ligne le temps que tout le monde ait basculé, en pleine campagne, sans interruption de service.

Ce que contient la nouvelle version

• La page publique : cumul de campagne, cartes des deux sucreries, historique annuel, date des dernières données.
• La zone professionnelle en onze pages, une par atelier, avec les seuils d'alerte repris à l'identique du site d'origine.
• De vrais comptes utilisateurs, individuels ou partagés selon le profil, gérés par le client dans un back-office dédié.
• Une lecture des fichiers qui ne casse jamais : fichier absent, tronqué ou valeur invalide, la mesure affiche un tiret et le reste du site continue.
• Un indicateur de fraîcheur qui signale des données non actualisées, discret hors campagne, visible en campagne.
• Mise à jour automatique sans rechargement, position de lecture conservée, et une version mobile qui garde les deux usines côte à côte.

Le format des fichiers entrants n'a pas bougé d'une virgule. Ils sont produits par les usines, et un changement de ce côté-là aurait fait porter le risque au client. Le nouveau site s'est adapté à eux, pas l'inverse.

Des choix qui ne sortent pas d'un prompt

• Les mesures sont lues par leur libellé, plus par leur numéro de ligne. Une mesure ajoutée ou déplacée dans un fichier ne décale plus rien, et une mesure inconnue est simplement ignorée.
• Aucune page cassée par un fichier défaillant. Absent, tronqué, en cours de dépôt, valeur non numérique : chaque cas a son test et son comportement défini.
• Les dates sont celles des usines, pas celles du serveur. La fraîcheur des données se calcule sur l'heure d'export inscrite dans le fichier, à l'heure de La Réunion.
• Sessions signées, mots de passe jamais stockés en clair, limitation des tentatives, HTTPS forcé, et une zone professionnelle que les moteurs de recherche n'indexent pas.
• Les jeux d'essai sont les vrais fichiers du site d'origine. Les tests ne vérifient pas un comportement imaginé, ils vérifient celui que la filière utilisait déjà.

Aucun de ces choix n'a été pris pendant la génération du code. Ils viennent de l'analyse de l'existant et des specs, et le développement assisté les applique partout sans les rediscuter.

Trois enseignements transposables

Pour aller plus loin