Moderniser une application WinDev avec des agents : REA et méthode clean-room

Le 15 octobre 2026, la documentation d'installation de REA contient une phrase qu'une DSI doit lire avant toute réécriture : « For clean-room separation, use an implementation environment with filesystem and network restrictions that prevent reading or fetching REA, the target and analysis output […] »¹. Elle s'applique directement au patrimoine WinDev dont le projet source a disparu.

Deux situations très différentes

Si vous avez le projet WinDev, vous n'avez pas besoin de REA. Depuis la version 25, l'atelier sait enregistrer en texte lisible le code et les caractéristiques principales des fenêtres, et notre méthode part de là : extraire les règles métier avec l'IA, puis migrer sans big bang. Le code WLangage reste la meilleure source de vérité disponible.

Le cas qui nous occupe ici est l'autre : un sous-traitant parti avec les sources, un poste de développeur effacé, un projet resté sur une version introuvable. Il reste l'exécutable déployé, la base HFSQL et des utilisateurs. Pour ce patrimoine, la matière publique est mince. Au 15 octobre 2026, ni le README ni la documentation de REA ne mentionnent WinDev ou le WLangage parmi les cibles². Personne n'a publié de retour de rétro-ingénierie par agents sur un exécutable WinDev. Toute promesse de résultat serait une invention : on procède par preuve de concept, sur une application et un périmètre fonctionnel limité.

Ce que REA peut apporter

REA pilote Hopper, Ghidra ou IDA sur un binaire natif et renvoie pseudocode, assembleur, chaînes, symboles et références, avec les limites de chaque conclusion². Ce que ces outils tirent d'une application WinDev, aucune source publique ne le dit : la manière dont l'atelier compile et empaquette une application n'est pas documentée dans nos sources, et seule une preuve de concept sur votre exécutable le montrera. Les écrans et les données, eux, se lisent sans décompiler : recoupés, ils permettent déjà de reconstituer une partie des règles de gestion.

La base HFSQL reste la pièce la plus riche. Le schéma, les contraintes que le code faisait respecter sans les déclarer et les valeurs réelles disent beaucoup du métier ; la démarche de migration est décrite dans HFSQL vers PostgreSQL. Le livrable de cette phase est une spécification relue par les utilisateurs, avec la liste des zones que ni le binaire ni les données n'ont éclairées.

La séparation clean-room, appliquée à des agents

Une méthode clean-room sépare deux équipes : l'une analyse et rédige une spécification débarrassée de tout code protégé, l'autre réimplémente à partir de cette seule spécification. Quand un même agent lit le pseudocode puis écrit la nouvelle application, les deux rôles fusionnent et la barrière disparaît. Le détail juridique est rassemblé dans clean-room ou reverse engineering.

La documentation de REA tire la conséquence technique. Restreindre REA à un profil d'agent contrôle quelles sessions découvrent ses outils, mais laisse le shell, les fichiers et le réseau accessibles : un agent sous le même compte système peut lancer REA par npx et lire les sorties d'analyse. L'environnement de réimplémentation doit donc empêcher l'accès à REA, à la cible et aux résultats, et « A separate account or container must enforce those restrictions »¹. En pratique : un compte ou un conteneur pour l'analyse, un autre pour la réécriture, et la spécification comme seul objet qui franchit la frontière, versionnée avec son historique.

Pour votre propre application, la question de la contrefaçon se pose moins que pour le logiciel d'un tiers, à une condition : en être titulaire. Une application développée par un prestataire ne vous appartient, au sens des droits patrimoniaux, que si ces droits vous ont été cédés par écrit, selon le formalisme de l'article L131-3 du Code de la propriété intellectuelle. Vérifiez le contrat. La séparation garde son intérêt : elle oblige à écrire la spécification, et cette spécification nourrit les tests.

Prouver que la nouvelle application fait la même chose

L'exécutable d'origine tourne encore : c'est votre meilleur atout. Il produit les sorties de référence d'un golden master inversé, où un LLM propose des entrées et seule l'application WinDev fournit les résultats attendus. La réécriture, menée dans la logique Software Factory 10x, doit les reproduire, bugs historiques compris, jusqu'à ce que le métier décide de les corriger.

Le confinement, non négociable

REA n'isole pas l'analyse. Sa politique de sécurité indique : « Opening an untrusted binary delegates parsing and analysis to the selected local provider with that user's permissions »³. Un exécutable interne connu s'analyse sur un poste dédié ; tout binaire récupéré d'une source incertaine s'ouvre en machine virtuelle ou en conteneur jetable, voir REA n'est pas un sandbox.

Questions fréquentes

Peut-on récupérer le source WLangage d'un exécutable WinDev ?

Ne comptez pas dessus : aucune source publique ne montre qu'un outil le restitue. On rétro-documente un comportement à partir du binaire, des écrans et des données.

REA prend-il en charge WinDev ?

Pas dans ses cibles documentées au 15 octobre 2026. Il peut piloter un décompilateur sur l'exécutable, sans connaissance particulière du WLangage.

Peut-on décompiler sa propre application WinDev ?

Le droit européen autorise l'acquéreur légitime à décompiler dans la mesure nécessaire à la correction d'erreurs affectant le fonctionnement, et dans le respect des conditions contractuelles, l'éditeur pouvant se réserver cette correction (CJUE, C-13/20 Top System, 6 octobre 2021)⁴. Il protège aussi l'observation du fonctionnement. Si l'application a été écrite par un prestataire, vérifiez d'abord que ses droits vous ont été cédés. Le contrat de licence de l'atelier et les bibliothèques de l'éditeur ajoutent leurs propres conditions : faites-les relire par votre juriste.

Comment sécuriser la réécriture ?

Par un golden master alimenté par l'application d'origine et par une séparation documentée entre l'équipe qui analyse et celle qui réécrit.

Une preuve de concept sur une application WinDev sans source commence par trois décisions : périmètre, environnement d'analyse confiné, premiers écrans rétro-documentés. Nos équipes la mènent avec la Software Factory.

Sources

1. morluto/rea, docs/installation.md, section « Limit REA to one project or agent profile », github.com, consulté le 15 octobre 2026.
2. morluto/rea, README, tableau « What you can analyze », github.com/morluto/rea, consulté le 15 octobre 2026.
3. morluto/rea, SECURITY.md, section « Security boundary », github.com, consulté le 15 octobre 2026.
4. CJUE, 6 octobre 2021, Top System, C-13/20, curia.europa.eu.