Éditeur disparu, code source perdu : plan de sauvetage d'une application critique

Le scénario arrive plus souvent qu'on ne l'avoue : l'éditeur a fermé ou a été absorbé, le prestataire qui maintenait l'application est parti, et personne ne retrouve le code source. L'application tourne encore, elle facture, planifie ou paie. Depuis octobre 2026, des outils comme REA rendent la rétro-documentation d'un binaire plus accessible. Ils n'interviennent qu'au troisième temps du plan.

Premier temps : stabiliser

Avant de penser réécriture, gagnez du temps. Figez l'environnement qui fait tourner l'application dans une image reproductible : système d'exploitation, bibliothèques, pilotes, base de données, paramètres. Sauvegardez les données et vérifiez la restauration sur une machine de test. Notez ce qui fait tomber l'application et ce qui la relève, avec les gens qui l'exploitent au quotidien : ces gestes sont souvent la seule documentation vivante.

Repérez les dépendances qui vont casser : un système d'exploitation qui arrive en fin de support, une licence de base de données à renouveler, un certificat qui expire, un service externe appelé par l'application. Chacune fixe une date butoir au plan.

Deuxième temps : récupérer ce qui existe

Le code source a rarement disparu partout. Cherchez dans les sauvegardes anciennes, sur les postes d'anciens développeurs, dans des dépôts oubliés, chez l'ancien prestataire, dans les archives de projet. Relisez le contrat : un séquestre de code source (escrow) a peut-être été prévu, précisément pour ce cas, avec des conditions de libération en cas de défaillance de l'éditeur. Récupérez aussi la documentation utilisateur, les cahiers de recette, les exports de paramétrage : tout ce qui décrit le comportement attendu.

Même un source partiel ou ancien change la suite : un agent lit un code incomplet bien mieux qu'un binaire, et l'écart entre l'ancienne version du source et le binaire en production se mesure.

Troisième temps : rétro-documenter

Quand le binaire est tout ce qui reste, rétro-documentez les règles métier à partir de l'exécutable, des écrans et des données. REA pilote Hopper, Ghidra ou IDA sur un exécutable natif et lit statiquement les applications .NET ou JavaScript/Electron, en renvoyant ses conclusions avec leurs preuves et leurs limites¹. La base de données et les fichiers d'échange se traitent avec la méthode décrite dans rétro-documenter un format propriétaire. L'objectif reste une spécification assez complète pour réécrire, relue par les utilisateurs, avec la liste des zones restées obscures.

Ouvrez l'exécutable dans un environnement isolé : la politique de sécurité de REA précise que l'ouverture d'un binaire « delegates parsing and analysis to the selected local provider with that user's permissions »², voir REA n'est pas un sandbox.

Côté droit, l'acquéreur légitime d'un programme peut le décompiler pour en corriger les erreurs, a jugé la CJUE le 6 octobre 2021 (Top System, C-13/20), dans la mesure nécessaire et dans le respect des conditions du contrat, l'éditeur pouvant se réserver cette correction (I de l'article L122-6-1)³. Votre licence, l'éventuel repreneur des droits de l'éditeur et l'usage que vous ferez de la spécification sont autant de points à soumettre à votre juriste ; le hub clean-room ou reverse engineering rassemble les principaux.

Quatrième temps : réécrire sous golden master

L'application d'origine tourne encore : elle devient l'oracle des tests. Un golden master capture ses sorties sur des entrées représentatives, et la nouvelle application doit les reproduire avant chaque bascule de brique. La méthode complète est détaillée dans le hub legacy.

Le cas de l'éditeur racheté

Parfois l'éditeur n'a pas disparu : il a été racheté et la politique commerciale a changé. Nouvelle redevance, fin de support d'une version, hausse de tarif. Le cas de PC SOFT, l'éditeur de WinDev, en donne un exemple détaillé dans redevance WinDev et rachat de PC SOFT. Les options diffèrent du cas précédent (négocier, geler, migrer), mais la rétro-documentation sécurise chacune : elle chiffre ce que représenterait une sortie.

Questions fréquentes

Peut-on sauver une application sans code source ?

Oui, en rétro-documentant son comportement et en la réécrivant, l'application d'origine servant de référence pour les tests. Le code d'origine, lui, ne revient pas.

Qu'est-ce qu'un séquestre de code source ?

Un dépôt du code source auprès d'un tiers, prévu au contrat, libéré au client selon des conditions définies, par exemple la défaillance de l'éditeur. Vérifiez qu'il existe, qu'il a été mis à jour et comment le déclencher.

Par quoi commencer ?

Par la stabilisation : environnement figé, sauvegardes restaurées, dates butoirs identifiées. La réécriture se prépare ensuite, sans urgence imposée par une panne.

Combien de temps pour réécrire ?

Cela dépend de la taille fonctionnelle et de la qualité de la rétro-documentation. Stabiliser d'abord donne le temps de l'estimer sur pièces.

Nos équipes interviennent sur ces sauvetages avec la Software Factory : stabilisation, rétro-documentation, golden master, réécriture par briques.

Sources

1. morluto/rea, README, tableau « What you can analyze », github.com/morluto/rea, consulté le 19 octobre 2026.
2. morluto/rea, SECURITY.md, section « Security boundary », github.com, consulté le 19 octobre 2026.
3. CJUE, 6 octobre 2021, Top System, C-13/20, curia.europa.eu.