Migration du core banking d'une néobanque européenne

Contexte

Cette néobanque européenne, créée en 2016, avait bâti son core banking sur un mainframe IBM z15 acquis lors d’une absorption d’une banque traditionnelle plus ancienne. La décision stratégique avait du sens à l’époque : hériter d’un SI bancaire éprouvé pour accélérer l’obtention des agréments réglementaires.

En 2024, la situation avait évolué. L’établissement employait 140 développeurs, dont exactement 2 capables de maintenir le code COBOL. La dépendance à un prestataire externe pour toute évolution du core mainframe freinait les cycles de delivery. Et le contrat de maintenance IBM représentait 28% du budget IT annuel.

La direction technique a engagé une revue stratégique et conclu qu’une migration progressive vers AWS était économiquement et opérationnellement justifiée — à condition de ne prendre aucun risque sur la cohérence comptable.

Défi

La difficulté principale n’était pas technique au sens classique. C’était la fidelité comportementale. Les 12 000 lignes de COBOL accumulées depuis 2016 contenaient des règles métier documentées nulle part : des arrondis bancaires spécifiques, des cas limites de traitement des dates, des comportements différents selon le type de compte.

Toute divergence entre le comportement de l’ancien batch et du nouveau aurait des conséquences réglementaires immédiates (rapports prudentiels faux, rejets dans les systèmes de clearing).

La contrainte opérationnelle : le batch comptable nocturne ne pouvait être interrompu plus de 15 minutes supplémentaires par rapport à sa plage habituelle. Zero downtime n’était pas un objectif marketing, c’était une contrainte réglementaire.

Approche

Phase 1 — Audit et cartographie (6 semaines). Extraction automatisée de toutes les dépendances via IBM Application Discovery. Identification de 340 programmes COBOL, dont 73 “critiques” (participant au grand livre comptable). Documentation systématique des règles métier implicites.

Phase 2 — Shadow mode (12 semaines). Mise en place d’un pipeline Kafka qui capturait tous les événements du batch mainframe et les rejouait en parallèle sur un nouveau service Java/Spring en AWS. Les résultats des deux systèmes étaient comparés ligne à ligne via un reconciliation service.

# Exemple de commande de réconciliation quotidienne
./reconcile.sh --date=$(date +%Y%m%d) \
  --mainframe-extract=s3://legacy-exports/ \
  --new-service=https://batch.internal/report \
  --tolerance=0.01

Les 8 premières semaines de shadow mode ont révélé 47 divergences. Chacune a été analysée, documentée, et corrigée dans le service Java.

Phase 3 — Migration progressive (16 semaines). Bascule par type de compte : d’abord les comptes d’épargne (risque le plus faible), puis les comptes courants, enfin les comptes professionnels. À chaque étape, 2 semaines d’observation avec rollback possible en 15 minutes.

Phase 4 — Extinction mainframe (4 semaines). Archivage des COBOL sources, rétention du LPAR pendant 90 jours, puis arrêt définitif du contrat de maintenance.

Résultats

Au-delà des chiffres, le résultat le plus important est organisationnel : les 140 développeurs de l’équipe peuvent désormais travailler sur l’ensemble du SI bancaire, sans dépendance à une compétence externalisée rare. Le time-to-market d’une nouvelle fonctionnalité comptable est passé de 8 semaines à 3 jours.

[À COMPLÉTER PAR ABDERRAHMANE] — KPIs supplémentaires et détails spécifiques à valider avec le client