Applications legacy sans code source : comprendre avant de réécrire

Le 14 avril 2026, un compte GitHub nommé morluto crée le dépôt de REA (Reverse Engineer Anything), un serveur MCP qui donne à un agent de code les outils d'un rétro-ingénieur. Six mois plus tard, le 23 octobre, le dépôt compte 369 860 étoiles¹. Pour une DSI qui porte une application critique dont le code source est perdu, incomplet ou illisible, la question devient concrète : peut-on enfin comprendre ce binaire assez bien pour le réécrire ?

Le point de départ réaliste

Sans source, vous disposez d'un exécutable, d'une base de données et d'utilisateurs qui savent ce que l'application fait au quotidien. Personne ne ressuscitera le code d'origine : un compilateur jette les noms, les commentaires et une bonne part de la structure. Votre objectif est plus modeste et plus utile : rétro-documenter les règles métier assez précisément pour qu'une équipe les réimplémente sur une stack moderne, puis prouve que la nouvelle application se comporte comme l'ancienne.

Ce travail existait avant les agents. Il demandait un expert du désassemblage, des semaines de lecture et un budget que peu de directions acceptaient pour une application « qui marche ». La plupart des parcs ont donc vieilli en l'état.

Ce que les agents changent à la première lecture

REA ne décompile rien lui-même. Il orchestre des outils existants et rend leurs résultats à l'agent avec les preuves et les limites de chaque conclusion. Sur un binaire natif, il pilote Hopper, Ghidra ou IDA et renvoie pseudocode, assembleur, chaînes, symboles et références. Sur une application .NET ou JavaScript/Electron, il lit les fichiers sans exécuter l'application². Le coût de la première lecture d'un binaire s'effondre : ce qui prenait des jours à un spécialiste tient dans une session d'agent supervisée.

La couverture reste partielle. Le 11 octobre, sur une application Electron de 100 Mo, REA 6.4.0 a bien compté les fenêtres et les ponts exposés, mais il a annoncé zéro script preload alors que l'application en chargeait deux³. Les inconnues que l'outil déclare doivent donc rester visibles dans votre documentation : notre méthode de lecture est décrite dans lire une sortie REA, et les plafonds mesurés dans les limites réelles de REA.

Une méthode en quatre temps

Le cluster WinDev de SFEIR déroule la méthode complète pour un cas où le code est disponible : extraire les règles métier avec l'IA, choisir la cible et migrer sans big bang, migrer les données et sécuriser par un golden master inversé. Sans source, seule la première étape change : la rétro-documentation part du binaire et des données au lieu du code.

Vous rétro-documentez les règles depuis l'exécutable, les écrans et les données. Vous les faites relire par les utilisateurs, qui connaissent les cas limites mieux que n'importe quel décompilateur. Vous capturez les sorties de l'application d'origine sur des entrées représentatives : l'ancien binaire devient l'oracle de vos tests de golden master. Puis la réécriture avance brique par brique, chaque brique validée contre cet oracle.

Chaque stack a ses pièges. Les données enfermées dans un format maison se traitent à part, voir rétro-documenter un format propriétaire. Les pages dédiées couvrent Visual Basic 6, Delphi, PowerBuilder et NSDK et WinDev quand le source manque. Si l'éditeur a disparu, commencez par le plan de sauvetage.

Le confinement et le droit

Ouvrir un binaire avec REA revient à le faire analyser par Ghidra ou Hopper avec vos droits d'utilisateur. La politique de sécurité du projet l'écrit : « This is not a sandbox »⁴. Pour une application interne connue, l'analyse statique sur un poste de travail reste raisonnable ; tout exécutable d'origine incertaine s'ouvre dans une machine virtuelle ou un conteneur jetable, voir REA n'est pas un sandbox.

Le droit européen distingue trois régimes, à ne pas confondre. L'observation, l'étude et le test du fonctionnement, pendant une utilisation autorisée, ne demandent pas de décompiler (III de l'article L122-6-1). La correction d'erreurs par l'acquéreur légitime peut justifier une décompilation, dans la mesure nécessaire et sous réserve du contrat, l'éditeur pouvant se la réserver (article 5 de la directive, arrêt Top System, I de l'article L122-6-1). L'interopérabilité ouvre la décompilation sous trois conditions (IV). Si l'application a été développée par un prestataire, vérifiez aussi que ses droits vous ont été cédés par écrit. Les nuances sont rassemblées dans clean-room ou reverse engineering et décompiler pour interopérer, à faire valider par votre juriste.

Questions fréquentes

Peut-on retrouver le code source perdu ?

Rarement. Un décompilateur rend du pseudocode, pas le source d'origine. Certaines technologies interprétées (p-code Visual Basic, PowerBuilder) conservent davantage d'informations que le code natif, mais le livrable utile reste une spécification du comportement.

Combien de temps prend une rétro-documentation ?

La première lecture par agent se compte en heures. La validation des règles avec les utilisateurs et la constitution du golden master forment l'essentiel du travail, et leur durée dépend de la taille fonctionnelle de l'application.

Quelle garantie de complétude ?

Aucune automatique. Les inconnues déclarées par l'outil se traitent une par une, et le golden master révèle les règles oubliées quand la nouvelle application diverge de l'ancienne sur un cas réel.

Faut-il des compétences de rétro-ingénierie en interne ?

Il faut au moins une personne capable de vérifier ce que l'agent affirme, de relire un pseudocode et de distinguer une conclusion inférée d'une conclusion prouvée. L'agent accélère la lecture, et c'est cette personne qui valide.

Pour une modernisation legacy, la rétro-documentation est le premier livrable : elle vaut même si vous décidez ensuite de garder l'application en l'état. Nos équipes la mènent dans la logique de la Software Factory, du binaire à la bascule.

Sources

1. morluto/rea, dépôt GitHub, métadonnées (date de création, étoiles) via l'API GitHub, github.com/morluto/rea, consulté le 23 octobre 2026.
2. morluto/rea, README, tableau « What you can analyze », github.com/morluto/rea, consulté le 16 octobre 2026.
3. Ishank Choudhary, I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App, hackernoon.com, 14 octobre 2026.
4. morluto/rea, SECURITY.md, section « Security boundary », github.com, consulté le 16 octobre 2026.