Moderniser un SI legacy : stratégies de migration progressive

La modernisation commence par un état des lieux qui croise trois dimensions pour chaque composant du patrimoine : sa valeur métier — ce qu'il fait gagne-t-il ou coûte-t-il à l'entreprise ? —, son état technique — dette, obsolescence des socles, disponibilité des compétences — et son rythme d'évolution requis. Ce croisement évite les deux erreurs symétriques : moderniser en priorité ce qui est techniquement vétuste mais stable et peu sollicité, ou laisser en l'état un composant sain en apparence mais qui freine chaque évolution métier. La priorité va aux composants à la fois stratégiques et bloquants ; un système ancien, stable et isolé peut légitimement attendre.

Quatre grandes stratégies structurent le champ des possibles. L'encapsulation : exposer le système existant derrière des API modernes sans toucher à son cœur — rapide et peu risquée, elle débloque les intégrations mais ne réduit pas la dette. Le refactoring ciblé : réécrire les seules parties qui concentrent les évolutions et les incidents, en conservant le reste. Le strangler fig : construire progressivement le nouveau système autour de l'ancien, en migrant les flux capacité par capacité jusqu'à extinction du legacy — la stratégie de référence pour les transformations d'envergure, car chaque étape est limitée et réversible. Le replatforming enfin : adopter un progiciel ou une solution cloud standard, pertinent quand le domaine n'est pas différenciant et que le métier peut s'aligner sur le standard. Le point essentiel : ces stratégies se combinent, et le bon niveau de décision est le composant, jamais le SI entier.

Trois disciplines font la différence entre une migration maîtrisée et une migration subie. Le filet de sécurité d'abord : avant de modifier un système mal documenté, le caractériser par des tests qui capturent son comportement observable — la technique dite du « golden master » rend comparables l'ancien et le nouveau sur des jeux de données réels. Les données ensuite, vrai cœur du risque : prévoir des phases de double alimentation ou de synchronisation, comparer systématiquement les résultats des deux systèmes pendant la cohabitation, et ne basculer qu'à l'aune d'écarts mesurés et expliqués. La réversibilité enfin : chaque étape doit pouvoir être annulée sans drame ; une bascule sans retour possible est un pari, pas un plan. Ce sont ces précautions, plus que le choix de la cible technologique, qui déterminent l'issue.

Une modernisation d'envergure se déroule sur des trimestres, parfois des années, et son principal ennemi est l'essoufflement : l'équipe de la « nouvelle plateforme » s'épuise à courir après un existant qui continue d'évoluer. Deux règles y répondent. D'une part, geler autant que possible les évolutions fonctionnelles du périmètre en cours de migration, en les redirigeant vers le nouveau système. D'autre part, découper la trajectoire en jalons dont chacun apporte une valeur propre — une intégration débloquée, un coût de licence supprimé, un délai de mise sur le marché réduit — afin que le programme se justifie à chaque étape et non à la seule arrivée.