Modernisation Legacy en banque tier 1

Contexte

Un établissement financier tier-1 européen exécute ses processus de calcul financier critique (risque, trésorerie, valorisation) sur un core Oracle avec une logique en PL/SQL, un grid IBM Spectrum Symphony et des systèmes de marché tels que Murex et Algorithmics. C'est une exploitation 24/7 : il n'existe aucune fenêtre pendant laquelle le système peut s'arrêter.

Le core s'était développé pendant des années sous forme de monolithes PL/SQL difficiles à faire évoluer, avec des déploiements manuels et des processus dont le temps d'exécution ne tenait plus dans les fenêtres métier. L'objectif était de réduire ces temps et de moderniser la manière de livrer le logiciel sans toucher à la disponibilité.

Le défi

Trois contraintes ont marqué le projet :

• Des processus de calcul financier critique aux temps insoutenables, qui bloquaient des opérations métier.
• Des monolithes Oracle avec du PL/SQL critique fortement couplé, sans possibilité de changer une pièce sans mettre l'ensemble en risque.
• Une exploitation 24/7 et des intégrations avec Murex et Algorithmics qui devaient rester intactes pendant toute la transition.

Approche par phases

La modernisation a été exécutée comme une succession de phases contrôlées, chacune avec validation et capacité de retour arrière.

1. 01

   Diagnostic du code et du grid

   Identification du PL/SQL qui concentrait le temps de calcul et de l'utilisation réelle des ressources du grid.

2. 02

   Refactorisation et découplage

   Réécriture du PL/SQL critique et séparation progressive des monolithes Oracle en composants déployables de manière indépendante.

3. 03

   Pipeline DevOps et GitOps

   Automatisation des déploiements : chaque changement versionné, testé et promu de façon reproductible.

4. 04

   Migration par phases sans downtime

   Mise en production composant par composant, en maintenant les intégrations avec Murex et Algorithmics et l'exploitation 24/7.

Architecture et stratégie

Le principe a été le même que celui que nous appliquons sur les autres projets de banque tier-1 : étendre et découpler plutôt que remplacer. Le grid Symphony et le core Oracle restent en place ; ce qui change, c'est la façon dont le travail est réparti (utilisation du grid) et dont le logiciel est livré (pipeline automatisé au lieu de déploiements manuels).

Résultats mesurables

Résultats validés en production :

Chiffres agrégés et anonymisés dans le cadre d'un accord de confidentialité. Source : projets de Vermont Solutions.

Enseignements transposables

• Sur un core 24/7, la migration par phases avec capacité de retour arrière n'est pas optionnelle : c'est la seule façon d'avancer sans exposer le métier.
• Automatiser la livraison (DevOps + GitOps) réduit les erreurs et rend chaque déploiement prévisible et auditable.
• Mesurer l'utilisation réelle du grid avant de l'étendre évite des investissements inutiles : la marge était dans la répartition, pas dans le matériel.

Cadre réglementaire

Le calcul du risque dans la banque tier-1 relève de la supervision ; la modernisation a été conçue pour renforcer les preuves de contrôle.

• Bâle III/IV : calculs de capital et de risque dans les fenêtres exigées.
• DORA (art. 28) : traçabilité des changements, résilience opérationnelle et gestion des prestataires tiers TIC.
• BCBS 239 : agrégation des données de risque avec des processus documentés et reproductibles.

Questions fréquentes

Contenus associés

• Service : modernisation des systèmes legacy →
• Service : HPC et Grid Computing →
• Produit : add-on pour IBM Spectrum Symphony →
• Cas client : extension dynamique du GRID vers le cloud dans la banque →