L'essentiel sur la modernisation core banking
Un core banking COBOL/IBM Z age de 20 a 40 ans supporte encore 95 % des transactions bancaires mondiales. Mais le cout MIPS a triple en 10 ans, les developpeurs COBOL partent a la retraite, et chaque nouvelle fonctionnalite necessite 12 a 24 mois de delivery — un handicap mortel face aux neobanques.
La migration ne peut pas se faire en big-bang. Le strangler fig pattern — cohabitation controlee entre legacy et nouveaux microservices via une API gateway — est la seule approche validee en production sur des portefeuilles de plusieurs centaines de milliers de comptes. Nehos applique cette methode avec synchronisation CDC (Debezium + Kafka) entre IBM Z et les nouvelles bases Postgres/MongoDB.
Cas client banque regionale (120 000 clients, 38 ans de COBOL) : 18 mois de programme, zero incident de production lors des bascules, -74 % de time-to-market sur les nouveaux produits apres la migration, conformite DORA atteinte, economies run estimees a 3000 k€ sur 5 ans par rapport au maintien mainframe.
Le chantier est aussi humain que technique : formation des equipes internes sur Java/Go, recrutement cible, knowledge transfer des seniors COBOL. Nehos integre ce volet RH dans le programme des le mois 1.
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 deja mise en oeuvre sur des coeurs bancaires en production.
Adapté à toute taille de structure
Le paradoxe du core banking legacy est bien documente : les systemes COBOL sur IBM Z ou Unisys ClearPath qui font tourner les banques europeennes depuis les annees 1980 sont a la fois les actifs les plus critiques et les plus couteux a maintenir. Le cout du MIPS (Million d'Instructions Par Seconde) sur mainframe IBM Z a augmente de 200 a 300 % entre 2012 et 2024 selon les donnees de Gartner, pendant que le prix du compute cloud decreissait de 80 %. L'equation economique du mainframe s'est inversee. Sur le plan humain, la crise est deja la. L'age moyen des developpeurs COBOL actifs en France est superieur a 52 ans selon les estimations de l'APEC. Les ecoles 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 documentees, de traitements batch JCL critiques et de logiques metier enfouies dans des fichiers VSAM que personne n'ose toucher. Le bus factor est de 1 ou 2 sur la majorite 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 fonctionnalite en deux semaines, une banque traditionnelle dont les regles metier sont codees en COBOL et les interfaces exposees via CICS ou MQ Series a besoin de 12 a 24 mois pour livrer une evolution comparable. La conformite reglementaire aggrave le probleme : chaque evolution 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 journee sur une stack moderne. La conformite DORA (Digital Operational Resilience Act, applicable aux etablissements financiers de l'UE depuis janvier 2025) ajoute une couche de complexite : les banques doivent desormais documenter leur capacite de resilience operationnelle, tester leurs scenarii de reprise apres incident (TLPT — Threat-Led Penetration Testing), et notifier leurs incidents IT significatifs sous 4 heures au regulateur. Un mainframe IBM Z — systeme hautement fiable mais opaque, peu instrumentable et dont les runbooks de reprise sont rarement documentes selon les standards DORA — est devenu un risque de conformite autant qu'un risque operationnel. La tentation du big-bang — tout remplacer d'un coup — a deja conduit plusieurs banques au desastre. TSB Bank au Royaume-Uni (2018) : migration ratee 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 prevu et coutee 1 Md$ de plus que le budget initial. Ces echecs 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 operationnel catastrophique.
La methode Nehos pour la modernisation core banking repose sur trois principes non negociables : 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 donnees pendant toute la periode de cohabitation. La premiere etape 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/ecrivains, analyse des interfaces CICS, MQ Series et SWIFT. Cet audit produit une carte des dependances et une classification des composants par risque et complexite de migration. Les bounded contexts metiers — comptes, paiements, credits, epargne, referentiel client — sont identifies et priorises selon leur valeur pour le time-to-market et leur complexite technique. Le strangler fig pattern est ensuite mis en place domaine par domaine. Concretement : une API gateway (Kong Enterprise ou AWS API Gateway) est positionnee 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 donnees pendant la cohabitation est assuree 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 etat en coherence eventuelle — ou en coherence forte pour les operations financieres 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 donnees cibles sont Postgres (comptes, credits) et Kafka (event log immuable). L'architecture est cloud-native — deployee sur Kubernetes (EKS, GKE ou OVHcloud Managed Kubernetes selon les contraintes de souverainete) — avec des pipelines CI/CD GitHub Actions ou GitLab CI, du TDD, du contract testing (Pact) et du chaos engineering (LitmusChaos) systematiques. La conformite DORA est integree a la demarche des le design : chaque microservice est instrumente avec OpenTelemetry (traces, metriques, logs), les runbooks de reprise sont rediges et testes, les TLPT sont planifies avec le RSSI et la conformite. La detection d'incidents et la notification reglementaire sont automatisees via des alertes PagerDuty/Opsgenie avec workflows de notification au regulateur. 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 developpeurs Java/Go aux specificites du domaine bancaire (comptabilite, reglementation), et peut accompagner le recrutement de profils specialises core banking (Temenos, Finastra, Thought Machine alumni). Ce transfert de connaissance est souvent le facteur le plus sous-estime — et le plus determinant — du succes d'un programme de modernisation.
-74 %
de time-to-market sur les nouveaux produits bancaires apres migration du core banking (banque regionale 120 k clients, 2025) — de 18 mois a 4,6 mois en moyenne
3000 k€
d'economies run estimees sur 5 ans par rapport au maintien du mainframe IBM Z (licences MIPS, maintenance, COBOL developers) — banque regionale 120 k clients
0
incident de production lors des 14 bascules de trafic realisees sur le programme de migration (zero downtime valide en production sur les modules comptes, paiements et referentiel client)
18 mois
duree du programme complet de modernisation core banking (audit initial + migration 4 domaines + decommissioning mainframe + conformite DORA) sur le cas client de reference
#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 :