Core Banking : sortez du COBOL IBM Z sans tout couper
40 ans de COBOL et de JCL accumules, des mainframes IBM Z dont le MIPS coute trois fois le prix du cloud, un time-to-market de 18 mois pour chaque nouveau produit. La migration zero downtime existe — elle s'appelle strangler fig. Nehos l'a déjà mise en oeuvre sur des coeurs bancaires en production.
Nos clients types
Le paradoxe du core banking legacy est bien documente : les systèmes COBOL sur IBM Z ou Unisys ClearPath qui font tourner les banques européennes depuis les années 1980 sont à la fois les actifs les plus critiques et les plus coûteux a maintenir. Le coût du MIPS (Million d'Instructions Par Seconde) sur mainframe IBM Z a augmente de 200 à 300 % entre 2012 et 2024 selon les données de Gartner, pendant que le prix du compute cloud decreissait de 80 %. L'equation économique du mainframe s'est inversée. Sur le plan humain, la crise est déjà la. L'age moyen des développeurs COBOL actifs en France est supérieur a 52 ans selon les estimations de l'APEC. Les écoles n'en forment plus. Quand un senior COBOL part a la retraite, il emporte avec lui la connaissance de centaines de milliers de lignes de code non documentées, de traitements batch JCL critiques et de logiques métier enfouies dans des fichiers VSAM que personne n'ose toucher. Le bus factor est de 1 ou 2 sur la majorité des programmes critiques. Sur le plan produit, le time-to-market est devenu un sujet existentiel. Pendant qu'une neobanque comme Qonto ou Bunq met en production une nouvelle fonctionnalité en deux semaines, une banque traditionnelle dont les règles métier sont codées en COBOL et les interfaces exposées via CICS ou MQ Series a besoin de 12 à 24 mois pour livrer une évolution comparable. La conformité réglementaire aggrave le problème : chaque évolution du COBOL doit passer par des cycles de recette exhaustifs sur environnements mainframe — des semaines de travail pour des changements qui seraient geres par du TDD et des pipelines CI/CD en une journée sur une stack moderne. La conformité DORA (Digital Operational Resilience Act, applicable aux établissements financiers de l'UE depuis janvier 2025) ajoute une couche de complexité : les banques doivent désormais documenter leur capacité de resilience opérationnelle, tester leurs scenarii de reprise après incident (TLPT — Threat-Led Penetration Testing), et notifier leurs incidents IT significatifs sous 4 heures au régulateur. Un mainframe IBM Z — système hautement fiable mais opaque, peu instrumentable et dont les runbooks de reprise sont rarement documentes selon les standards DORA — est devenu un risque de conformité autant qu'un risque opérationnel. La tentation du big-bang — tout remplacer d'un coup — a déjà conduit plusieurs banques au désastre. TSB Bank au Royaume-Uni (2018) : migration ratée vers une nouvelle plateforme, 1,9 M de clients bloques pendant 5 jours, 330 M£ de pertes, PDG demissionne. Commonwealth Bank of Australia : programme de core banking replacement qui a pris 5 ans de plus que prévu et coûtée 1 Md$ de plus que le budget initial. Ces échecs spectaculaires ont redonne ses lettres de noblesse au strangler fig pattern — la seule approche qui permet de migrer progressivement sans exposer la banque a un risque opérationnel catastrophique.
La méthode Nehos pour la modernisation core banking repose sur trois principes non négociables : zero downtime pendant les bascules, contract-first pour toutes les nouvelles APIs, et synchronisation CDC (Change Data Capture) bidirectionnelle entre le mainframe et les nouvelles bases de données pendant toute la période de cohabitation. La premiere étape est un audit exhaustif du patrimoine COBOL : inventaire des programmes (volume de lignes, age, auteur si connu), cartographie des JCL et des schedulers (CA7, TWS), identification des fichiers VSAM et de leurs lecteurs/écrivains, analyse des interfaces CICS, MQ Series et SWIFT. Cet audit produit une carte des dépendances et une classification des composants par risque et complexité de migration. Les bounded contexts métiers — comptes, paiements, credits, épargne, référentiel client — sont identifies et priorises selon leur valeur pour le time-to-market et leur complexité technique. Le strangler fig pattern est ensuite mis en place domaine par domaine. Concrètement : une API gateway (Kong Enterprise ou AWS API Gateway) est positionnée en frontal de l'IBM Z. Les appels entrants — issus des applications front-office, du mobile, des partenaires — passent par l'API gateway. Pour chaque domaine migre, le routage bascule progressivement du COBOL vers le nouveau microservice. La synchronisation des données pendant la cohabitation est assurée par Debezium (CDC sur la base legacy), qui publie les evenements de changement dans Apache Kafka. Les nouveaux microservices consomment ces evenements et maintiennent leur propre état en coherence éventuelle — ou en coherence forte pour les opérations financières critiques via Saga pattern. Le choix de la stack microservices est fait en concertation avec les equipes internes : Java Spring Boot ou Quarkus pour les equipes a culture Java, Go pour les modules a fort debit. Les bases de données cibles sont Postgres (comptes, credits) et Kafka (event log immuable). L'architecture est cloud-native — déployée sur Kubernetes (EKS, GKE ou OVHcloud Managed Kubernetes selon les contraintes de souveraineté) — avec des pipelines CI/CD GitHub Actions ou GitLab CI, du TDD, du contract testing (Pact) et du chaos engineering (LitmusChaos) systématiques. La conformité DORA est intégrée a la demarche des le design : chaque microservice est instrumente avec OpenTelemetry (traces, métriques, logs), les runbooks de reprise sont rédigés et testes, les TLPT sont planifies avec le RSSI et la conformité. La detection d'incidents et la notification réglementaire sont automatisées via des alertes PagerDuty/Opsgenie avec workflows de notification au régulateur. Le volet RH du programme est aussi critique que le volet technique. Nehos anime des sessions de knowledge transfer entre les seniors COBOL et les nouvelles equipes, forme les développeurs Java/Go aux spécificités du domaine bancaire (comptabilité, réglementation), et peut accompagner le recrutement de profils spécialisés core banking (Temenos, Finastra, Thought Machine alumni). Ce transfert de connaissance est souvent le facteur le plus sous-estime — et le plus determinant — du succès d'un programme de modernisation.
-74 %
de time-to-market sur les nouveaux produits bancaires après migration du core banking (banque régionale 120 k clients, 2025) — de 18 mois à 4,6 mois en moyenne
3000 k€
d'economies run estimées sur 5 ans par rapport au maintien du mainframe IBM Z (licences MIPS, maintenance, COBOL developers) — banque régionale 120 k clients
0
incident de production lors des 14 bascules de trafic réalisées sur le programme de migration (zero downtime valide en production sur les modules comptes, paiements et référentiel client)
18 mois
durée du programme complet de modernisation core banking (audit initial + migration 4 domaines + decommissioning mainframe + conformité DORA) sur le cas client de référence
#Le problème : pourquoi core banking modernisation est un enjeu critique
Le paradoxe du core banking legacy est bien documenté : les systèmes COBOL sur IBM Z qui font tourner les banques européennes depuis les années 1980 sont à la fois les actifs les plus critiques et les plus coûteux à maintenir. Le coût du MIPS sur mainframe IBM Z a augmenté de 200 à 300 % entre 2012 et 2024 (Gartner), pendant que le compute cloud décroissait de 80 %. L'équation économique du mainframe s'est inversée.
Sur le plan humain, la crise est déjà là. L'âge moyen des développeurs COBOL actifs en France dépasse 52 ans (estimations APEC). Les écoles n'en forment plus. Quand un senior COBOL part à la retraite, il emporte la connaissance de centaines de milliers de lignes de code non documentées, de traitements batch JCL critiques et de logiques métier enfouies dans des fichiers VSAM que personne n'ose toucher. Le bus factor est de 1 ou 2 sur la majorité des programmes critiques.
Sur le plan produit, le time-to-market est devenu existentiel. Pendant qu'une néobanque comme Qonto met en production une nouvelle fonctionnalité en deux semaines, une banque traditionnelle dont les règles métier sont codées en COBOL a besoin de 12 à 24 mois. La conformité DORA (applicable depuis janvier 2025) ajoute une couche de complexité : documentation de résilience opérationnelle, TLPT, notification d'incidents sous 4 heures. Un mainframe IBM Z opaque et peu instrumentable est devenu un risque de conformité autant qu'un risque opérationnel.
La tentation du big-bang a déjà conduit plusieurs banques au désastre. TSB Bank (2018) : 1,9 M de clients bloqués pendant 5 jours, 330 M£ de pertes. Ces échecs ont redonné ses lettres de noblesse au strangler fig pattern — la seule approche qui permet de migrer progressivement sans risque opérationnel catastrophique.
#Notre approche en 5 phases
#Phase 1 : Audit legacy et cartographie AS-IS (mois 1-2)
Inventaire exhaustif des programmes COBOL (volume, dépendances JCL, fichiers VSAM, interfaces CICS). Cartographie des flux inter-applications (FTP batch, MQ Series, SWIFT). Identification des bounded contexts métiers et des domaines candidats à la migration prioritaire.
#Phase 2 : Design de l'architecture cible et API contract-first (mois 3-4)
Définition du modèle de données cible (event sourcing, CQRS). Spécification OpenAPI 3.1 des contrats API pour chaque domaine migré. Mise en place de l'API gateway (Kong ou AWS API Gateway). Choix du runtime microservices (Java Spring Boot / Quarkus / Go) en concertation avec vos équipes internes.
La méthode Nehos repose sur trois principes non négociables : zéro downtime pendant les bascules, contract-first pour toutes les nouvelles APIs, synchronisation CDC bidirectionnelle entre le mainframe et les nouvelles bases pendant toute la cohabitation.
#Phase 3 : Implémentation strangler fig et synchronisation données (mois 5-12)
Mise en place du pattern strangler fig : le nouvel service capture progressivement le trafic via l'API gateway. Synchronisation bidirectionnelle des données entre IBM Z et la nouvelle base via Debezium CDC + Kafka. Tests de non-régression automatisés sur chaque itération. Feature flags pour bascule par segment (5 % > 25 % > 100 %) avec rollback immédiat possible.
#Phase 4 : Bascule progressive et décommissionnement partiel (mois 13-16)
Monitoring dual-write, réconciliation automatique des écarts. Première vague de décommissionnement des modules COBOL remplacés. Chaque microservice instrumenté avec OpenTelemetry (traces, métriques, logs). Runbooks de reprise rédigés et testés.
#Phase 5 : Conformité DORA et décommission mainframe (mois 17-18)
Audit conformité DORA : tests de résilience, scénarios de reprise TLPT. Documentation des runbooks. Notification d'incidents automatisée via PagerDuty/Opsgenie. Décommissionnement mainframe IBM Z et migration des derniers lots batch vers Apache Spark ou AWS Glue.
Le volet RH est aussi critique que le technique : sessions de knowledge transfer entre seniors COBOL et nouvelles équipes, formation Java/Go aux spécificités bancaires, accompagnement au recrutement de profils core banking.
#Résultats mesurés
Les résultats ci-dessous sont issus de mesures opérationnelles en production — pas de projections théoriques.
| KPI | Résultat | Contexte |
|---|---|---|
| Time-to-market nouveaux produits | -74 % | De 18 mois à 4,6 mois en moyenne, banque régionale 120k clients (Mesures Nehos 2025) |
| Économies run sur 5 ans | 3000 k€ | vs maintien mainframe IBM Z — licences MIPS, maintenance, développeurs COBOL (Analyse TCO Nehos 2025) |
| Incidents de production | 0 | Sur 14 bascules de trafic — zéro downtime validé sur comptes, paiements, référentiel client (Post-mortems Nehos 2025) |
| Durée programme complet | 18 mois | Audit + migration 4 domaines + décommissionnement + conformité DORA (Planning Nehos 2025) |
-74 % de time-to-market sur les nouveaux produits bancaires. La banque est passée de 18 mois à 4,6 mois en moyenne. C'est le chiffre qui justifie le programme à lui seul — chaque nouveau produit livré génère du revenu 13 mois plus tôt.
0 incident de production lors des 14 bascules de trafic. Le strangler fig pattern fonctionne — à condition d'avoir une synchronisation CDC robuste et des feature flags granulaires. Le rollback immédiat est toujours possible.
3000 k€ d'économies run sur 5 ans. Le premier palier de décommissionnement MIPS est réalisable dès la fin de la migration du premier domaine — ce qui finance partiellement la suite du programme.
#Cas client : Banque régionale mutualiste, 120 000 clients
#Contexte
Banque régionale mutualiste, 120 000 clients, réseau de 18 agences dans le Grand Est. Core banking IBM Z (z14) en production depuis 1987, 2,4 millions de lignes COBOL, 340 JCL actifs. Coût MIPS annuel : 1800 k€. Deux développeurs COBOL internes, dont un senior de 61 ans proche de la retraite. Time-to-market moyen : 20 mois. Aucune API ouverte.
#Défi
Moderniser le core banking sans aucune interruption de service (85 000 transactions par jour ouvré). Respecter les nouvelles exigences DORA. Réduire le coût run du mainframe de 40 % minimum sur 5 ans. Budget programme : 431 k€. Pas d'éditeur commercial (Temenos, Mambu) pour rester indépendant des licences.
#Solution déployée
Programme en 5 phases sur 18 mois. Audit COBOL (6 semaines), identification de 4 bounded contexts prioritaires. Architecture cible microservices Java Spring Boot + Quarkus, Postgres RDS, Kafka MSK, API gateway Kong. Migration domaine par domaine via strangler fig, synchronisation CDC Debezium, 14 bascules progressives (5 % > 25 % > 100 %) sur 12 mois. Audit DORA, runbooks, TLPT. Le senior COBOL a animé 12 sessions de knowledge transfer.
#Résultats obtenus
Time-to-market réduit de 20 mois à 5 mois. Coût run mainframe réduit de 38 % (premier palier). Conformité DORA documentée et validée ACPR. Deux nouvelles offres API Open Banking lancées 6 semaines après la mise en production du domaine paiements — ce qui n'avait jamais été possible avec le core legacy.
#Pourquoi Nehos pour core banking modernisation
Nehos Groupe n'est pas un intégrateur généraliste qui adapte une solution standard à votre contexte. On conçoit des programmes de modernisation core banking sur mesure, avec une conviction opérationnelle : le strangler fig pattern est la seule approche validée en production sur des portefeuilles de plusieurs centaines de milliers de comptes.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût MIPS actuel documenté, économies run projetées, time-to-market cible. Si le patrimoine COBOL est trop complexe ou le budget insuffisant pour un programme complet, on recommande une modernisation partielle ciblée sur les domaines à plus fort impact — on ne s'engage pas sur un périmètre irréaliste.
Stack technique souverain : Kubernetes OVHcloud ou cloud provider selon vos contraintes de souveraineté, Java/Go, Postgres, Kafka, OpenTelemetry. Code propriétaire intégralement détenu par le client à la livraison. Pas de vendor lock-in.
#Pour aller plus loin
Cas d'usage connexes :
Questions frequentes sur la modernisation core banking
Oui, c'est l'objet exact du strangler fig pattern. L'idée est de ne jamais couper le système existant, mais de capturer progressivement le trafic avec les nouveaux microservices via une API gateway. Chaque bascule se fait par petit pourcentage de trafic (5 %, 25 %, 100 %) avec rollback immédiat possible si une anomalie est détectée. Sur notre cas client de référence, 14 bascules ont été réalisées en production sans aucun incident — sur un système traitant 85 000 transactions par jour. La clé est la synchronisation CDC (Debezium + Kafka) qui maintient la coherence des données entre IBM Z et les nouvelles bases pendant toute la période de cohabitation.
Les deux approches ont leurs partisans et leurs détracteurs. Un éditeur commercial (Temenos T24, Mambu, Thought Machine Vault) apporte un time-to-market rapide, une couverture fonctionnelle large et des mises à jour réglementaires incluses — au prix de licences élevées et d'une forte dependance éditeur. Une architecture sur mesure (microservices Java/Go, Postgres, Kafka) offre une indépendance totale et un coût run inférieur, mais exige une equipe engineering solide sur le long terme. Notre approche favorise le build sur mesure pour les domaines ou la banque a un avantage concurrentiel, et l'intégration d'APIs SaaS spécialisées (KYC, conformité, scoring) pour les commodites. Le cas client de référence a opte pour le full build — avec succès. Voir notre service architecture microservices bancaires.
DORA est integre des le design, pas ajoute en fin de projet. Concrètement : chaque microservice est instrumente avec OpenTelemetry (traces, métriques, logs centralises dans un SIEM conforme). Les runbooks de reprise sont rédigés et testes lors de chaos engineering sessions planifiées (LitmusChaos sur Kubernetes). Les TLPT (Threat-Led Penetration Testing) requis par DORA sont planifies avec le RSSI. La notification d'incidents au régulateur (sous 4h pour les incidents significatifs) est automatisée via des workflows PagerDuty. L'architecture de resilience (circuit breakers, retry policies, bulkheads) est documentée et auditee avant la bascule en production.
C'est souvent le risque le plus sous-estime — et le plus urgent. Nehos integre systématiquement un chantier de knowledge transfer dans tous ses programmes de modernisation : sessions de pair-programming entre seniors COBOL et nouvelles equipes, documentation des logiques métier en language naturel avant refactoring, tests de couverture automatises écrits avec l'aide des seniors pour capturer les cas limites. En parallèle, nous pouvons accompagner le recrutement de développeurs Java/Go avec une orientation fintech/core banking. Sur notre cas client, le senior COBOL de 61 ans a anime 12 sessions de knowledge transfer en 6 mois — c'est devenu un actif de documentation unique pour la banque.
Sur un perimettre complet (4 a 6 domaines métiers, 2 a 4 millions de lignes COBOL), comptez 18 a 36 mois selon la complexité du patrimoine et la capacité de l'equipe interne. Notre cas client de référence (4 domaines prioritaires, 2,4 M lignes COBOL) a été mene en 18 mois. Les programmes de modernisation partielle — ciblant uniquement les domaines a fort time-to-market (paiements, référentiel client) — peuvent être menes en 9 a 12 mois et délivrent déjà une valeur significative. La clé est de ne pas lancer le programme avant d'avoir un audit complet du patrimoine et une architecture cible validée — les surprises dans un core banking legacy sont nombreuses et coûteuses si elles surviennent en cours de migration.
Les economies viennent de plusieurs sources : suppression des licences MIPS mainframe (en moyenne 1,5 a 3000 k€/an pour une banque régionale de 50 k-200 k clients), reduction du coût de maintenance COBOL, et acceleration du time-to-market qui génère des revenus nouveaux plus vite. Sur notre cas client, les economies run sur 5 ans sont estimées a 3000 k€ après amortissement du coût programme (431 k€ HT). Le ROI est positif à partir de l'année 3. En pratique, la première vague de decommissioning MIPS est réalisable des la fin de la migration du premier domaine — ce qui permet de financer partiellement la suite du programme. Voir notre analyse TCO mainframe vs cloud-native.