Moderniser un SI legacy en 9 mois

Je partage un retour d'expérience sur une mission de 9 mois qui m'a appris autant qu'elle a stressé le COMEX qui m'a recruté. Le contexte : une ETI industrielle dont la gestion des commandes et la facturation reposaient sur un monolithe .NET écrit il y a une quinzaine d'années, lui-même branché sur des batchs Cobol pour les stocks. Personne n'osait y toucher. Deux développeurs sur trois qui connaissaient le code étaient partis en retraite. Le moindre changement réglementaire prenait des mois, et la direction vivait dans la peur d'une panne un jour de clôture. J'ai écarté le big-bang d'emblée. Réécrire l'ensemble, c'était dix-huit mois de tunnel et un risque de continuité que je n'avais pas le droit de prendre. J'ai donc proposé un strangler fig : on enveloppe le monolithe derrière une façade d'API, et on en extrait les fonctions une par une, en commençant par celles qui combinent forte valeur métier et risque maîtrisé. La facturation TVA en premier, parce qu'elle bougeait souvent. Les stocks Cobol en dernier, parce qu'ils étaient stables. Au COMEX, je n'ai pas parlé d'architecture. J'ai parlé du jour où le système tomberait sans personne pour le relever, et du coût d'un retard de facturation. Le budget est passé en une séance. Le vrai piège n'était pas technique. C'étaient les règles métier non écrites, planquées dans des conditions vieilles de dix ans, qu'un seul comptable connaissait encore. On a passé six semaines à les exhumer avant d'oser couper quoi que ce soit. Résultats : sept domaines sur neuf migrés, délai de mise en production divisé par quatre, plus aucune dépendance aux deux retraités rappelés en renfort. Ce que je referais autrement : j'ai sous-investi dans la reprise de données au départ. La logique applicative était propre, mais les écarts historiques en base nous ont coûté un mois. Aujourd'hui je commence par auditer la donnée, pas le code. Et vous, comment avez-vous géré l'extraction des règles métier invisibles ?