Un patrimoine applicatif ne se réécrit pas. Il se déplace.

Elle suppose de figer les évolutions métier pendant deux ans, de reconstituer des règles que plus personne ne sait énoncer, et de basculer un jour d'un système à l'autre en espérant n'avoir rien oublié.

Nous procédons autrement : par paliers, en gardant le service en production à chaque étape.

Montée de version du socle — passer les briques historiques aux dernières versions supportées, traiter les incompatibilités, moderniser les interfaces sans changer le comportement métier.

Modernisation de la couche de données — mise à niveau des bases, réécriture des traitements les plus coûteux, optimisation des chaînes existantes.

Interfaçage avec l'écosystème neuf — exposer le patrimoine derrière des services pour qu'il dialogue avec les applications récentes, plutôt que de l'isoler en attendant sa disparition.

Mise aux normes réglementaires — traçabilité, sécurité des données, calculs de risques implémentés dans les modules au fil de la modernisation.

Ce que cela donne

Sur un patrimoine de gestion de crédit d'un groupe bancaire, le système historique est resté disponible pendant l'intégralité des phases de bascule, bases de données comprises — avec, au passage, une réduction sensible des temps de réponse.

Lire la réalisation : faire passer un patrimoine de gestion de crédit à la génération suivante