Core Banking : sortez du COBOL IBM Z sans tout couper
Des décennies de COBOL et de JCL, des mainframes dont le coût d'exploitation pèse sur le budget, un délai de mise sur le marché très long pour chaque nouveau produit. Une migration sans interruption de service est possible avec le pattern strangler fig. Nehos la conçoit et la pilote avec vos équipes.
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. 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. 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.
Continuité
Aucune interruption de service : chaque bascule est répétée et dotée d'un plan de retour arrière
Délai produit
Délai de mise sur le marché d'un nouveau produit, relevé avant la migration puis après chaque périmètre basculé
Coût d'exploitation
Coût d'exploitation du mainframe suivi par périmètre pour piloter le décommissionnement
#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. 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. 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.
#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.
#Exemple de situation
Ce qui suit est un exemple de situation pour illustrer la démarche, pas le récit d'un projet livré.
#Contexte
Une banque régionale mutualiste exploite un cœur bancaire COBOL/IBM Z vieux de plusieurs décennies. Les développeurs partent à la retraite, le coût d'exploitation pèse et chaque nouveau produit prend beaucoup de temps à lancer.
#Défi
Moderniser sans interrompre le service, sans big-bang, tout en tenant les exigences DORA et en transférant la connaissance des seniors COBOL aux équipes internes.
#Approche
Un audit du patrimoine existant, une architecture cible API-first, une migration progressive selon le pattern strangler fig avec synchronisation des données (CDC), des bascules répétées puis un décommissionnement partiel, avec un volet formation des équipes dès le début.
#Ce que nous mesurons
Les indicateurs de réussite sont fixés avec vous avant le lancement et relevés sur l'existant. On les suit pendant le pilote, puis on décide ensemble d'aller plus loin ou non, sur des mesures et non sur des promesses.
#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 & réponses
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. 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. Une architecture sur mesure (microservices Java/Go, Postgres, Kafka) offre une indépendance totale et un coût d'exploitation plus bas, mais exige une équipe d'ingénierie solide sur le long terme. Notre approche favorise le sur-mesure pour les domaines où la banque a un avantage concurrentiel, et l'intégration d'APIs SaaS spécialisées (KYC, conformité, scoring) pour les fonctions banalisées. Le bon choix se décide lors de l'audit, domaine par domaine. 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-estimé, et le plus urgent. Nehos intègre un chantier de transfert de connaissance dans ses programmes de modernisation : sessions de pair-programming entre seniors COBOL et nouvelles équipes, documentation des logiques métier en langage naturel avant refactoring, tests automatisés écrits avec l'aide des seniors pour capturer les cas limites. En parallèle, nous pouvons accompagner le recrutement de développeurs Java/Go à orientation fintech. La connaissance des seniors devient un actif de documentation unique pour la banque.
La durée dépend du périmètre. Une modernisation partielle, ciblant les domaines où le délai de mise sur le marché pèse le plus (paiements, référentiel client), se mène sur un horizon bien plus court qu'un programme complet de décommissionnement. 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 quand elles surviennent en cours de migration.
Les économies dépendent de votre contrat mainframe, de la part de MIPS décommissionnable et du rythme de migration. Nous les modélisons lors de l'audit, domaine par domaine, avec des hypothèses prudentes. En pratique, une première vague de décommissionnement est possible dès la fin de la migration du premier domaine, ce qui permet de financer en partie la suite du programme. Voir notre analyse TCO mainframe vs cloud-native.