Reverse engineering

Comment ça marche

Le reverse engineering, c’est partir d’un résultat ou d’un objet fini pour remonter à son fonctionnement. Un logiciel dont on a perdu la documentation, un fichier dont on ne connaît pas le format, une feuille de calcul pleine de formules que plus personne n’explique, un processus que seul un ancien connaissait. On analyse, on teste, on infère, on documente.

L’IA y est redoutablement efficace. Un agent de code lit un programme de dix mille lignes et en produit une explication structurée. Un modèle déduit le format d’un fichier à partir de quelques exemples. Un tableur hérité se transforme en spécification lisible. Le cadre est celui de la propriété : sur ce qui est à l’entreprise, pas de problème ; sur ce qui est à d’autres, le droit s’applique, et on vérifie avant.

Un exemple concret

1. Le problème : un tableur de 40 onglets calcule tous les devis depuis 12 ans. Son auteur est parti. Personne n’ose le toucher, et il donne parfois des résultats que nul ne sait expliquer.
2. L’analyse : un agent de code lit toutes les formules, trace les dépendances entre onglets, et produit un document : les entrées, les règles de calcul, les constantes cachées, les cas particuliers.
3. Les découvertes : trois onglets morts, une remise codée en dur pour un client disparu, une formule qui arrondit dans le mauvais sens sur un type de produit, et deux règles que le service commercial croyait différentes.
4. La spécification : le document, relu et corrigé par le directeur commercial, devient la spécification officielle de la tarification. Trente pages lisibles, au lieu de 40 onglets opaques.
5. La suite : un nouvel outil est construit à partir de la spécification, avec des tests qui reproduisent les devis passés. Le tableur est archivé.

Douze ans de savoir-faire implicite sont devenus un document. L’analyse a pris trois jours ; le tableur était intouchable depuis trois ans.

Ce que ça change pour une équipe

• L’hérité n’est plus intouchable. Code, tableurs, fichiers, processus : ce que personne ne comprenait plus s’explique et se documente.
• Le savoir implicite devient explicite. Les règles enfouies dans des formules ou des habitudes deviennent des spécifications.
• Le remplacement devient possible. On ne remplace que ce qu’on comprend. L’analyse est la première étape.
• Les anomalies apparaissent. Une remise oubliée, un arrondi faux : l’analyse les trouve, souvent après des années.

Les limites et les erreurs fréquentes

• Analyser ce qui n’est pas à vous sans vérifier. Un logiciel tiers, un format propriétaire, un site concurrent : le droit s’applique, et parfois interdit.
• Prendre l’explication de l’IA pour la vérité. Elle infère ; elle peut se tromper sur un cas rare. La spécification produite se vérifie sur des cas réels.
• Reproduire au lieu de comprendre. Copier le fonctionnement bug par bug, remise oubliée comprise. L’analyse sert à décider ce qu’on garde.
• Jeter l’ancien trop vite. Le tableur hérité reste la référence pour tester le nouvel outil. On l’archive, on ne le supprime pas.