Systèmes centraux mainframe, COBOL et modernisation du legacy bancaire : audit, conseil, formation et assistance technique pour la banque

Un patrimoine technique au cœur de l'activité bancaire

Les plateformes et les langages en jeu

Un système central bancaire est l'ensemble des applications qui tiennent les comptes, exécutent les opérations, calculent les intérêts, gèrent les crédits et alimentent les autres systèmes. Dans beaucoup d'établissements, il repose sur un mainframe IBM Z sous z/OS. Les transactions en ligne passent par CICS ou IMS, les données sont stockées dans Db2, IMS ou ADABAS, et les traitements de nuit, dits batchs, sont orchestrés par des JCL. Les programmes sont écrits en COBOL, en PL/I ou en assembleur ; certains ont été générés à partir d'un atelier de génie logiciel comme PACBase. D'autres établissements, souvent de taille intermédiaire, exploitent IBM i (System i, AS/400) avec des programmes en RPG.

À ces plateformes s'ajoutent les progiciels de cœur de banque, dont certains sont présents dans le catalogue comme outils du thème, et les couches d'ouverture qui exposent les transactions à d'autres applications, comme z/OS Connect. Optédif n'est ni partenaire ni revendeur de ces éditeurs ; les marques appartiennent à leurs titulaires. Le sujet qui nous occupe n'est pas le choix d'un produit : c'est la maîtrise de l'existant, de sa dette technique et de sa transformation.

Pourquoi le legacy est un sujet de direction

Ces systèmes sont fiables parce qu'ils ont été éprouvés, mais trois fragilités reviennent. La première est la connaissance : la documentation est partielle, les règles de gestion sont dans le code, et les personnes qui les connaissent sont proches de la retraite ou déjà parties. La deuxième est la dépendance : un changement sur un programme peut toucher une chaîne de nuit, un échange interbancaire ou un état réglementaire, sans que personne n'ait la cartographie complète. La troisième est la rareté du marché des compétences, qui rend les remplacements longs.

La modernisation ne consiste donc pas à choisir une technique, mais à décider, application par application, ce qu'on conserve, ce qu'on ouvre par des interfaces, ce qu'on réhéberge, ce qu'on réécrit et ce qu'on remplace, en tenant compte du risque pour la continuité de service.

Le cadre réglementaire applicable

DORA et les systèmes hérités

Le règlement (UE) 2022/2554 (DORA), applicable depuis le 17 janvier 2025, traite expressément des systèmes hérités. Son article 8, paragraphe 7, demande aux entités financières autres que les microentreprises de conduire, au moins une fois par an, une évaluation spécifique du risque TIC pour tous les systèmes TIC hérités, et en tout état de cause avant et après la connexion de technologies, d'applications ou de systèmes. La Q&R de l'EIOPA sur cette question lit la notion de connexion largement : elle inclut les interfaces et les changements qui créent de nouvelles interdépendances. Pour une banque, exposer une transaction centrale à une application mobile est donc un événement qui appelle une évaluation.

Le même règlement exige un cadre de gestion du risque TIC approuvé par l'organe de direction, une cartographie des actifs et de leurs dépendances, des sauvegardes et des plans de reprise, et, pour les prestataires, un registre d'informations, des clauses contractuelles minimales et une stratégie de sortie pour les fonctions critiques ou importantes. L'AMF en présente les blocs, et l'ACPR en contrôle l'application pour les établissements de crédit et de paiement.

Contrôle interne et externalisation

L'arrêté du 3 novembre 2014 relatif au contrôle interne des entreprises du secteur de la banque, des services de paiement et des services d'investissement soumises au contrôle de l'ACPR reste le texte français de référence. Son article 10 définit les activités externalisées, confiées à un tiers de manière durable et à titre habituel, et distingue parmi elles les prestations de services ou autres tâches opérationnelles essentielles ou importantes. Lorsqu'un contrat relève de cette seconde catégorie, l'entreprise doit en informer l'ACPR, le suivre dans un registre et couvrir l'activité par son contrôle interne. Les orientations de l'ABE (Autorité bancaire européenne) sur l'externalisation (EBA/GL/2019/02) complètent le dispositif pour les prestations non TIC, DORA régissant les prestations TIC. Le texte est publié sur Légifrance ; l'article 10 a été modifié par un arrêté du 29 juillet 2026.

La conséquence pour un projet de modernisation est simple : confier l'exploitation, la maintenance ou une migration à un tiers peut constituer une externalisation essentielle ou importante, avec contrat écrit, droit d'accès de l'ACPR et plan de sortie. Le conseil, l'audit à blanc et la formation, eux, ne sont en principe pas visés, sous réserve d'une appréciation au cas par cas par l'établissement.

Secret bancaire et protection des données

Les établissements de crédit et leurs salariés sont tenus au secret professionnel par l'article L. 511-33 du code monétaire et financier. Cet article prévoit des cas de communication, parmi lesquels les contrats de prestations de services conclus avec un tiers en vue de lui confier des fonctions opérationnelles importantes, dans la limite de ce qui est nécessaire. Le rapport du Haut Comité juridique de la Place financière de Paris de 2020, publié sur le site de la Banque de France, en analyse la portée pour la sous-traitance. S'y ajoute le règlement (UE) 2016/679, qui impose la sécurité des traitements. Un système central contient les données les plus sensibles de l'établissement : l'accès d'un intervenant extérieur y est décidé par l'établissement, jamais par défaut.

Moderniser sans interrompre le service

Les trajectoires de modernisation

On rencontre cinq trajectoires. Conserver une application stable, en la documentant et en renforçant son exploitation. L'ouvrir par des interfaces pour qu'elle serve les canaux modernes sans la modifier. La réhéberger sur une autre plateforme avec peu de changement de code. La réécrire, à l'identique fonctionnel ou avec une refonte. La remplacer par un progiciel, ce qui suppose de reprendre l'historique et d'adapter les processus. Aucune n'est bonne en soi : le choix dépend de la criticité de l'application, de son état, des compétences et du calendrier réglementaire.

Des outils aident à décider et à conduire le changement : analyse statique et cartographie des dépendances, débogage et édition de programmes, outils de migration, assistants de génération de code, conteneurs sur la plateforme centrale. Ils réduisent l'effort de lecture, mais ils ne remplacent ni la connaissance fonctionnelle ni la recette.

La transmission des savoir-faire

La transmission est un chantier à part entière. Elle commence par identifier les applications dont la connaissance est concentrée sur une ou deux personnes, puis par documenter les règles de gestion, les chaînes de traitement, les cas particuliers et les procédures d'incident. Elle se poursuit par des binômes entre expérimentés et plus jeunes, sur des tâches réelles, et par une relecture des documents par ceux qui les ont écrits. Elle suppose du temps dégagé : un départ annoncé six mois à l'avance laisse rarement la marge nécessaire. Nous concevons ces plans, nous en réalisons une partie au forfait sous forme de documentation relue par l'expert, et nous formons les équipes qui reprennent le périmètre.

Les risques d'une migration

Une migration porte des risques connus : perte ou altération de données lors de la reprise de l'historique, écarts de calcul entre l'ancien et le nouveau traitement, dépassement de la fenêtre de traitement de nuit, dépendances oubliées avec un échange interbancaire ou un état réglementaire, bascule sans retour arrière possible, perte de compétences pendant la période de fonctionnement en double. Les parades sont classiques et doivent être écrites avant le démarrage : migration par lots, rapprochement systématique des résultats sur des jeux de données représentatifs, fonctionnement en parallèle, critères de décision pour la bascule et pour le retour arrière, répétitions générales, communication aux métiers. Aucune méthode n'élimine le risque ; elle le rend visible et décidable.

Prestataires et accès aux environnements

Un prestataire de modernisation est un prestataire TIC

Dès qu'un prestataire exploite, maintient, migre ou héberge des applications, il entre dans la catégorie des prestataires de services TIC de DORA. L'établissement doit alors l'inscrire au registre d'informations, qu'il remet chaque année à l'ACPR, évaluer sa chaîne de sous-traitance, prévoir les clauses contractuelles exigées par le règlement délégué (UE) 2024/1773 et organiser la sortie. Pour les prestations qui soutiennent une fonction critique ou importante, ces exigences s'appliquent avec toute leur force. Selon le rapport annuel 2025 de l'ACPR, près de 200 incidents majeurs ont été notifiés en 2025, dont environ 60 % impliquaient un prestataire informatique : le sujet n'est pas théorique.

Accès à la production et aux données

Un intervenant extérieur n'a pas de raison d'accéder aux données de clients pour auditer, concevoir ou former. Pour développer, tester ou migrer, les bonnes pratiques sont les mêmes partout : environnements de développement et de recette séparés de la production, jeux de données anonymisés ou fictifs, comptes nominatifs, principe du moindre privilège, comptes à privilèges encadrés, traçabilité des actions, séparation des tâches, chartes de sécurité signées. Quand l'intervention en production est inévitable, elle est décidée par l'établissement, limitée dans le temps et contrôlée par ses équipes.

Ce que nous faisons, et ce que nous ne faisons pas

Ce que nous faisons

Nous auditons le patrimoine applicatif et sa dette technique à partir d'extraits de code, de JCL et de documents. Nous conseillons sur la trajectoire de modernisation et sur la transmission des savoir-faire. Nous concevons des architectures cibles et des plans de migration avec leurs stratégies de recette et de retour arrière. Nous migrons des lots et déployons des outils dans des environnements de développement et de recette. Nous apportons une assistance technique en développement COBOL, en systèmes z/OS et en bases Db2, sous la responsabilité et l'encadrement d'Optédif, avec des livrables définis, au forfait ou en récurrent. Sur les prestations qui touchent aux données de clients, nous respectons le secret bancaire, la confidentialité et les accès définis par l'établissement. Nos livrables sont traçables, argumentés et présentables à la direction, à l'audit interne ou à l'ACPR.

La formation, en intra-entreprise, vient en complément : lecture de programmes, méthodes de maintenance, exploitation, passage de relais entre générations.

Ce que nous ne faisons pas

• Nous ne mettons pas de personnel à disposition : nos intervenants restent sous l'autorité d'Optédif, sur des livrables définis. L'établissement conserve la responsabilité de ses fonctions de contrôle et de ses décisions.
• Nous n'exploitons pas vos systèmes à votre place et nous n'accédons pas à la production ni aux données de clients sans cadre contractuel préalable.
• Nous ne prononçons aucune conformité à DORA ni à l'arrêté du 3 novembre 2014 : nous préparons des dossiers que votre établissement présente.
• Nous ne choisissons pas un éditeur ou une solution à votre place, et nous ne promettons aucun résultat de migration.
• Nos formations ne valent pas certification d'éditeur.

Références officielles

Le règlement (UE) 2022/2554 et ses actes délégués sont publiés sur EUR-Lex. L'arrêté du 3 novembre 2014 est consultable sur Légifrance, le secret bancaire à l'article L. 511-33 du code monétaire et financier. Les orientations de l'ABE sur l'externalisation sont publiées sur le site de l'ABE.