Reprendre un logiciel dont on n'a plus le code source

Le scénario revient plus souvent qu'on pense. Un logiciel maison fait rouler une partie de l'entreprise depuis des années. La personne qui l'a écrit n'est plus là. Le code source est introuvable, ou personne ne sait s'il correspond à ce qui tourne réellement en production.

La bonne nouvelle : le logiciel qui tourne contient déjà l'essentiel de ce qu'il faut savoir. Vos données et vos règles métier sont récupérables même sans le code d'origine. Ce qui est perdu, c'est le confort — pas le projet.

Voici ce qui se récupère, ce qui ne se récupère pas, et par où commencer.

Ce qui n'est pas perdu

Trois choses survivent presque toujours à la disparition du code source.

Vos données. Elles vivent dans une base de données ou dans des fichiers, et elles sont lisibles. C'est le patrimoine le plus précieux et le plus durable — souvent dix ans ou plus d'historique d'opérations.

Le comportement du logiciel. Il est observable. On peut l'utiliser, tracer ce qu'il fait, comparer ses entrées et ses sorties. Un calcul de prix de revient dont personne ne connaît la formule peut être reconstitué en l'observant sur assez de cas réels.

La connaissance de vos employés. Les personnes qui s'en servent tous les jours savent ce qu'il fait, où il se trompe, et quels contournements elles ont inventés. Ces contournements sont d'ailleurs la meilleure carte des lacunes du système.

Ce qui est réellement perdu

Soyons francs sur le coût.

L'intention derrière les décisions. Le code raconte ce que fait le logiciel, jamais pourquoi. Quand une règle bizarre existe, on ne sait plus si elle corrige un cas réel ou si c'est un bogue devenu coutume. Il faut trancher au cas par cas, avec vous.

Les cas rares. Le traitement de fin d'année, la facturation d'un client particulier, l'exception réclamée par un employé parti depuis. Ces cas-là ne se manifestent que lorsqu'ils surviennent, parfois des mois plus tard.

La vitesse. Reprendre sans source demande une phase d'observation avant de pouvoir modifier quoi que ce soit en confiance. C'est du vrai travail, et il doit être dans l'estimation.

Par où commencer : sécuriser avant d'analyser

L'erreur la plus coûteuse est de commencer par le code. La première urgence est ailleurs.

1. Mettre les données à l'abri

Avant toute chose : une copie complète, testée, restaurable. Beaucoup d'entreprises découvrent à ce moment-là que leur sauvegarde ne fonctionne plus depuis des mois, ou qu'elle sauvegarde le mauvais dossier. Tant que cette étape n'est pas faite, tout le reste est du risque.

2. Documenter ce qui existe

Où tourne le logiciel, sur quel serveur, sous quel compte, avec quelles dépendances. Qui a les accès. Ce qui se passe s'il s'arrête un mardi matin. Cette carte prend quelques jours et vaut souvent plus que le code lui-même.

3. Comprendre le modèle de données

C'est là qu'est la vraie logique métier. La façon dont une commande est reliée à ses pièces, ses bons de travail et ses achats en dit plus long sur l'entreprise que n'importe quelle documentation. Le modèle de données est aussi ce qui migre, quelle que soit la suite.

4. Décider seulement là

Continuer la maintenance ou planifier la refonte : cette décision ne se prend qu'une fois les trois premières étapes faites. La prendre avant, c'est deviner.

Faut-il tout jeter et repartir de zéro ?

Presque jamais du premier coup, et c'est la question que l'on nous pose le plus.

Réécrire de zéro paraît séduisant : on repart propre, sans dette. Mais on repart aussi sans les dix ans de cas particuliers que l'ancien système a fini par absorber. Ce sont précisément ces cas qui font qu'il fonctionne encore. Une réécriture complète les redécouvre un par un, en production, sous pression.

L'approche progressive est presque toujours meilleure. On stabilise, on comprend, puis on remplace par tranches — en gardant les règles qui ont fait leurs preuves. Chaque tranche remplacée réduit le risque au lieu de le concentrer sur une date de bascule.

Il existe des exceptions. Quand la technologie n'est plus supportée du tout, quand la sécurité est compromise, ou quand le coût d'hébergement de l'ancien système dépasse celui d'un neuf, la refonte complète devient le choix rationnel.

Le langage n'est pas le vrai problème

DOS, Access, WinDev, VB6, Flash, .NET ancien : la question « avez-vous les compétences dans cette technologie ? » arrive toujours, et elle est moins déterminante qu'on croit.

Ce qui compte, c'est la capacité à lire un système inconnu et à en extraire la logique. Un développeur chevronné qui n'a jamais touché à WinDev comprendra un système WinDev plus vite qu'un spécialiste WinDev qui n'a jamais fait de reprise.

Nous avons modernisé un ERP manufacturier qui tournait sous DOS vers un système web complet, et remis en ligne des jeux pédagogiques bâtis en Flash après la fin du support. Dans les deux cas, la difficulté n'était pas le langage : c'était de reconstituer les règles sans documentation.

Combien de temps, combien ça coûte

Une reprise se chiffre comme un projet de petite à moyenne envergure, soit de 15 000 $ à 35 000 $ pour une reprise ciblée, davantage si elle mène à une refonte progressive.

La phase d'observation initiale — sécuriser, cartographier, comprendre le modèle de données — se compte en semaines, pas en mois. C'est le meilleur investissement du projet : c'est elle qui transforme une inconnue en devis fiable.

Côté délai, les principes de la livraison par tranches s'appliquent intégralement, avec une nuance : sur une reprise, la première tranche est souvent défensive. On commence par arrêter l'hémorragie, pas par ajouter des fonctions.

Les trois signaux d'urgence

Si l'un de ces trois éléments est vrai chez vous, la reprise n'est plus un projet à planifier un jour — c'est un risque à traiter maintenant :

1. Personne ne sait redémarrer le système s'il s'arrête.
2. La sauvegarde n'a jamais été testée en restauration.
3. Une seule personne comprend encore comment il fonctionne, et elle approche de la retraite ou du départ.

Ces trois situations n'ont pas de solution progressive : elles exigent une intervention avant le prochain incident.

En résumé

Perdre le code source d'un logiciel qui fonctionne n'est pas fatal. Vos données, le comportement observable du système et la mémoire de vos employés suffisent à reconstituer l'essentiel. Ce qui coûte, c'est le temps d'observation — et il est bien moins cher que la réécriture à l'aveugle.

Si vous êtes dans cette situation, écrivez-nous. On regarde ce que vous avez, on vous dit honnêtement ce qui est récupérable, et vous décidez ensuite. Notre méthode de reprise est détaillée si vous voulez d'abord voir comment on travaille.