DORA : ce que ça change pour vos systèmes mainframe en 2026
Le règlement DORA s'applique depuis janvier 2025. Pour les banques qui tournent encore sur z/OS, voici les chantiers réels.
Le DORA — Digital Operational Resilience Act, règlement (UE) 2022/2554 — n’est plus une projection. Depuis le 17 janvier 2025, il s’applique à toutes les institutions financières de l’Union européenne. Pour les DSI bancaires, la question n’est plus “est-ce que ça nous concerne ?” mais “comment notre core mainframe répond aux exigences article par article ?”
Beaucoup d’établissements ont abordé DORA sous l’angle des processus et de la gouvernance. C’est juste mais incomplet. Le vrai chantier est technique — et il passe inévitablement par le mainframe.
Les trois piliers DORA qui touchent directement le mainframe
1. ICT Risk Management (Articles 5–16)
L’article 9 exige une cartographie exhaustive des actifs informationnels et de leurs dépendances. Pour un SI mainframe bancaire, cela signifie documenter chaque programme COBOL, chaque base DB2, chaque fichier VSAM qui participe à un processus critique. Dans la réalité, peu d’établissements ont cette cartographie à jour.
La difficulté spécifique au mainframe : les dépendances implicites. Un programme COBOL peut appeler dynamiquement un autre programme via un CALL avec une variable, sans que le nom du module appelé soit connu statiquement. Les outils d’analyse statique traditionnels ratent ces cas. Il faut des outils mainframe-aware (CA Endevor, IBM Application Discovery) couplés à une analyse d’impact outillée.
CALL WS-MODULE-NAME USING WS-INPUT WS-OUTPUT.Cette ligne anodine peut invoquer 200 modules différents selon le contexte métier. La cartographier pour DORA n’est pas trivial.
2. Digital Operational Resilience Testing (Articles 24–27)
DORA impose des tests de résilience réguliers, y compris des threat-led penetration tests (TLPT) pour les entités significatives. Pour le mainframe, cela soulève des questions pratiques :
- Comment tester la résilience d’un batch COBOL critique sans risquer la production ? La réponse standard est un environnement de non-production fidèle — mais les licences LPAR mainframe coûtent cher, et beaucoup d’établissements n’ont pas d’environnement de test au niveau de capacité de la production.
- Comment simuler une défaillance partielle d’IMS ou de CICS ? Les scenarii de chaos engineering, très répandus sur Kubernetes, n’ont pas d’équivalent direct sur z/OS.
La solution pragmatique pour 2026 : combiner les tests de reprise après incident (RTO/RPO) mainframe existants avec une documentation formelle conforme DORA, et documenter précisément les limites des tests.
3. ICT Third-Party Risk (Articles 28–44)
Si votre mainframe est géré par un prestataire (IBM, Broadcom, Atos, TCS), DORA vous impose désormais des clauses contractuelles spécifiques avec vos fournisseurs ICT critiques. Les accords de sous-traitance existants devront être mis à jour.
Point de vigilance : les contrats de maintenance COBOL ou DB2 signés il y a 10 ans ne contiennent pas les clauses de résiliabilité, d’audit droit-d’accès et d’exit strategy exigées par l’article 30.
Ce que ça implique concrètement
Pour les équipes mainframe, DORA n’est pas qu’un sujet juridique. C’est un accélérateur de modernisation déguisé. Les exigences de documentation, de testabilité et de résilience sont beaucoup plus faciles à satisfaire sur une architecture cloud-native instrumentée (métriques, traces, logs) que sur un SI mainframe monolithique des années 1990.
Le paradoxe : certains établissements vont dépenser plus pour documenter leur conformité DORA mainframe que ce qu’aurait coûté une migration partielle vers une architecture moderne et intrinsèquement conforme.
Par où commencer ?
- Inventaire des applications critiques — identifier les programmes COBOL qui participent aux processus classés “critiques” selon votre DORA risk assessment interne. Ce périmètre est généralement plus restreint qu’on ne le croit.
- Analyse de dépendances outillée — utiliser IBM Application Discovery (ou équivalent) pour cartographier les appels dynamiques, les fichiers partagés, les appels batch/OLTP.
- Alignement RTO/RPO avec DORA — vos obligations de continuité DORA doivent être traduites en exigences concrètes sur les jobs JCL, les procédures de restart, les fenêtres de reprise.
- Revue des contrats fournisseurs — anticiper la mise à jour des contrats ICT fournisseurs avant les délais DORA.
Un audit DORA de votre périmètre mainframe, c’est exactement ce que couvre la phase A de ma méthode. Prenez 30 minutes pour en parler.