Stratégies de cloud hybride pour les applications COBOL dans les secteurs réglementés

Le COBOL gère encore environ 95 % des transactions aux distributeurs automatiques de billets, 80 % des transactions en point de vente physique et constitue le cœur du système d'exploitation de la plupart des grandes banques, compagnies d'assurance et agences gouvernementales du monde entier. Les organisations qui utilisent ce code sont également soumises aux réglementations les plus strictes du secteur technologique : RGPD, DORA, HIPAA, PCI-DSS, Bâle III et les réglementations sectorielles appliquées par la FCA, l'OCC, l'APRA et des dizaines d'autres autorités nationales. Lorsqu'elles envisagent de migrer leurs charges de travail vers le cloud, la question n'est pas uniquement technique. Elle est également d'ordre juridique et contractuel, et doit être justifiée auprès d'un auditeur externe dans un délai précis.

Le cloud hybride, qui consiste à conserver certaines charges de travail sur site tout en migrant d'autres vers une infrastructure cloud, n'est pas un compromis pour les organisations réglementées utilisant COBOL. Il s'agit souvent de la solution architecturale optimale. Les exigences de résidence des données du RGPD et de ses équivalents nationaux peuvent interdire légalement le transfert de certaines données hors d'une juridiction spécifique. Les exigences de résilience opérationnelle de la DORA imposent de démontrer que les fonctions financières critiques peuvent résister aux interruptions de service du fournisseur de cloud. Les exigences d'intégrité des calculs pour les fonds propres réglementaires de Bâle III exigent que certains calculs soient reproductibles, auditables et inviolables, des propriétés plus faciles à démontrer lorsque le calcul est effectué sur une infrastructure contrôlée par l'organisation.

Le défi réside dans le fait que l'architecture de cloud hybride pour le COBOL réglementé est plus contrainte que ne le reconnaissent les recommandations générales en matière de cloud hybride. Votre stratégie d'intégration de cloud hybride établit un équilibre essentiel entre innovation et stabilité lors de la migration du mainframe vers le cloud. Cet équilibre est pertinent en principe. Cependant, elle omet l'architecture technique et de conformité spécifique requise pour définir la frontière entre l'environnement sur site et le cloud de manière à satisfaire les exigences réglementaires, préserver la continuité opérationnelle et créer une voie de migration plutôt qu'une séparation définitive.

Ce guide explique comment chaque cadre réglementaire majeur influence la décision relative aux limites hybrides, les quatre modèles architecturaux adaptés aux environnements COBOL réglementés, les modes de défaillance en matière de conformité que les architectures hybrides introduisent si elles ne sont pas conçues à cet effet, et ce que les auditeurs examinent réellement lorsqu'ils analysent un environnement COBOL hybride.

Comment la réglementation façonne la frontière hybride

Pour une organisation soumise à la réglementation, la décision la plus cruciale en matière d'architecture de cloud hybride ne consiste pas à choisir un fournisseur de cloud ni à déterminer quelles charges de travail migrer en premier. Il s'agit plutôt de définir les limites de la conformité : quelles données et quels traitements doivent rester sur site, et lesquels peuvent être transférés vers une infrastructure cloud sans enfreindre la réglementation ?

Chaque cadre réglementaire majeur impose des exigences différentes à cette limite :

Règlement	Juridiction	Contrainte hybride primaire	Ce qui doit rester sur place
RGPD / nFADP	UE, Suisse	Résidence des données pour les données personnelles des résidents de l'UE/EEE	Tout système COBOL traitant des données personnelles de l'UE sans décision d'adéquation pour la région cloud cible
DORA	Services financiers de l'UE	Résilience opérationnelle ; gestion des risques liés aux tiers pour les fournisseurs de TIC	Les fonctions critiques ou importantes doivent disposer de stratégies de sortie ; des limites de risque de concentration s’appliquent.
HIPAA	Soins de santé aux États-Unis	Les informations de santé protégées (PHI) ne peuvent être traitées par un fournisseur de cloud sans accord de partenariat commercial (BAA) ; exigences de chiffrement	Les données de santé électroniques protégées (ePHI) en transit et au repos sur n'importe quel serveur cloud nécessitent des contrôles documentés.
PCI-DSS v4.0	Global (paiements par carte)	L'environnement de données des titulaires de cartes doit être isolé du réseau.	Systèmes de traitement CHD ; gestion des clés de chiffrement
Bâle III/IV	Mondial (banque)	Les calculs de capital réglementaire doivent être reproductibles et vérifiables.	Moteurs de calcul où l'auditabilité est démontrée par le biais du contrôle de l'infrastructure
FCA / PRA (Royaume-Uni)	Services financiers britanniques	Résilience opérationnelle ; les services essentiels à l’entreprise doivent pouvoir supporter les chocs.	Cela dépend de la démonstration du SLA ; le cloud n’est pas exclu, mais doit être prouvé.
OCC (secteur bancaire américain)	Banques nationales américaines	Gestion des risques liés aux fournisseurs ; vérification préalable des tiers	Pas d'interdiction pure et simple, mais évaluation des risques de concentration et élaboration de plans de sortie obligatoires.

Conséquences pratiques pour les charges de travail COBOL :

Un programme COBOL batch traitant des données de comptes clients de l'UE ne peut être migré vers une région cloud située hors de l'UE/EEE que si le fournisseur de services cloud a obtenu une décision d'adéquation ou si des garanties appropriées (clauses contractuelles types) sont en place. Ce même programme, traitant uniquement des données opérationnelles internes, bénéficie d'une flexibilité bien plus grande.

Avant de définir la limite hybride, chaque organisation réglementée doit procéder à une classification des données de son portefeuille COBOL : quels programmes traitent des données personnelles, des données de titulaires de cartes, des informations de santé protégées (ISP) et quels programmes effectuent des calculs de capital réglementaire ? Cette classification détermine quels programmes peuvent migrer librement et lesquels doivent rester en deçà de la limite de conformité, indépendamment des préférences techniques.

Le problème de conformité COBOL dont personne ne parle

Les programmes COBOL présentent des risques de non-conformité spécifiques à ce langage et à son époque, risques que les directives génériques de conformité au cloud ne prennent pas en compte. Ces risques existent déjà sur site et deviennent des problèmes de visibilité dans un environnement hybride où l'auditeur s'attend à observer des contrôles de part et d'autre de la frontière.

Lacunes dans la journalisation des transactions. Les programmes COBOL écrivent généralement dans des fichiers et des bases de données sans journalisation native des transactions. Par défaut, une mise à jour VSAM KSDS en COBOL ne génère pas d'enregistrement immuable indiquant qui a modifié quoi, quand et de quelle valeur à quelle autre. Dans un environnement réglementé, il s'agit d'une lacune de conformité. Migrer un programme présentant cette lacune vers un environnement hybride où le cloud dispose d'une journalisation des transactions moderne ne fait qu'accentuer cette lacune, au lieu de la masquer.

Identifiants et clés de chiffrement codés en dur. Les applications COBOL héritées sont souvent dépourvues de fonctionnalités modernes telles que le contrôle d'accès basé sur les rôles, la surveillance en temps réel et les protocoles de chiffrement, ce qui les rend vulnérables aux cybermenaces sophistiquées. L'analyse statique des programmes COBOL révèle régulièrement la présence de clés codées en dur, de mots de passe dans la mémoire de travail (WORKING-STORAGE) et de chaînes de connexion intégrées au code source. Dans un environnement hybride soumis aux exigences de gestion des clés PCI-DSS ou aux contrôles de chiffrement HIPAA, ces vulnérabilités doivent être corrigées avant la migration, et non après.

Reproductibilité des calculs. L'arithmétique décimale compacte (COMP-3) de COBOL présente des caractéristiques spécifiques de précision et d'arrondi. Un calcul de fonds propres réglementaires fonctionnant correctement sous z/OS peut donner des résultats différents sous Linux en raison des différences de gestion des décimales par le compilateur. L'écart peut se limiter à quelques centimes par transaction, voire avoir un impact significatif sur un ratio de fonds propres. Dans les environnements hybrides répartissant les composants de calcul entre différentes plateformes, l'équivalence numérique doit être validée explicitement.

Quatre modèles architecturaux hybrides pour le COBOL régulé

Les différentes charges de travail réglementées requièrent différentes architectures hybrides. Il n'existe pas de modèle universel, mais ces quatre architectures couvrent l'éventail des situations que rencontrent la plupart des organisations réglementées.

Modèle 1 : Passerelle API de conformité

Idéal pour : Les organisations où la logique métier COBOL doit rester sur site pour des raisons réglementaires, mais où les applications modernes, les analyses et les services destinés aux clients peuvent être transférés vers le cloud.

Les programmes COBOL restent sur le mainframe. Une fine couche API, généralement exécutée sur une infrastructure proche du cloud ou au sein du réseau privé de l'organisation, expose les fonctionnalités COBOL via des points de terminaison REST ou gRPC. Les applications cloud appellent ces points de terminaison. Le programme COBOL lui-même ne bouge jamais ; seule son interface est déplacée.

Cloud Region (permitted)          Compliance Boundary          On-Premises (required)
┌─────────────────────┐              │              ┌──────────────────────────┐
│  New cloud-native   │              │              │  COBOL programs          │
│  applications       │──── API ─────┤──────────────│  (regulated processing)  │
│                     │    call      │              │                          │
│  Analytics          │              │              │  VSAM files (PHI/CHD)    │
│  platforms          │              │              │                          │
│                     │              │              │  Audit logs              │
└─────────────────────┘              │              └──────────────────────────┘

Avantage en matière de conformité : les données réglementées ne franchissent jamais la frontière. La passerelle API gère l’authentification, l’autorisation et la journalisation à ce niveau, assurant ainsi une traçabilité complète que le programme COBOL lui-même ne génère pas nécessairement. Le cloud ne traite jamais directement les données réglementées.

Exigence opérationnelle : La couche API doit être conçue pour gérer le modèle synchrone requête-réponse de COBOL. Les traitements par lots COBOL de longue durée nécessitent des modèles asynchrones avec des mécanismes de rappel ou d’interrogation plutôt que des appels API synchrones sujets à expiration.

Modèle 2 : Hiérarchisation des données selon la sensibilité réglementaire

Idéal pour : Les organisations disposant de données réglementées et non réglementées dans le même environnement COBOL, où les données réglementées peuvent être séparées des données opérationnelles.

Les données transactionnelles soumises à des exigences réglementaires, les données personnelles, les données des titulaires de cartes et les informations de santé protégées (ISP) restent sur site. Les données agrégées, anonymisées ou opérationnelles non soumises à des restrictions réglementaires sont transférées vers le stockage et le traitement dans le cloud. Les programmes COBOL générant des résultats réglementés continuent de s'exécuter sur le mainframe. Les programmes de reporting exploitant les données agrégées s'exécutent dans le cloud.

Exigence de mise en œuvre critique : l’étape d’agrégation et d’anonymisation doit être auditable. Le processus de transformation des données réglementées en données non réglementées pour leur transmission vers le cloud doit lui-même être journalisé, testé et soumis à ses propres contrôles. Un processus de dépersonnalisation défaillant dans certaines conditions d’entrée peut produire des données cloud permettant de réidentifier involontairement des personnes, ce qui constitue une violation du RGPD causée par une architecture conçue pour l’empêcher.

Modèle 3 : Validation en double exécution

Idéal pour : Les organisations migrant des charges de travail COBOL qui effectuent des calculs réglementés, où l'équivalence fonctionnelle entre les anciens et les nouveaux systèmes doit être démontrée à un organisme de réglementation avant la mise en service.

Le programme COBOL d'origine continue de s'exécuter sur le système central, traitant des données en temps réel. Une implémentation parallèle, migrée vers une nouvelle plateforme ou repensée, s'exécute simultanément sur une infrastructure cloud, traitant les mêmes données d'entrée. Les résultats sont comparés en temps réel. Les anomalies sont signalées, analysées et résolues avant que l'implémentation cloud ne soit certifiée comme système de référence.

Valeur de conformité : La double exécution satisfait à l’exigence d’équivalence démontrable imposée par les organismes de réglementation aux modifications apportées aux systèmes effectuant des calculs réglementaires. L’organisme peut présenter à l’auditeur un enregistrement de N mois de fonctionnement en parallèle, le processus de rapprochement appliqué aux écarts et la preuve que le nouveau système produit des résultats sensiblement identiques dans toutes les conditions d’entrée testées.

Coût opérationnel : L’exploitation de deux systèmes en parallèle est onéreuse. Le fonctionnement en double système est une solution transitoire, et non une architecture permanente. Le calendrier de validation et de basculement doit être précisé dans le plan de projet et validé par l’autorité de réglementation compétente lorsque l’approbation préalable est requise (comme c’est le cas dans le cadre de la DORA pour les modifications apportées aux fonctions critiques).

Modèle 4 : Fig. étrangleur avec limite de conformité

Idéal pour : Les organisations qui développent de nouvelles capacités dans le cloud tout en maintenant sur site des charges de travail COBOL réglementées à long terme, avec un chemin de migration défini pour chaque charge de travail à mesure que la certification est obtenue.

Les nouvelles fonctionnalités et les interfaces client sont conçues dès le départ comme des services natifs du cloud. Les charges de travail COBOL réglementées restent sur site et accessibles via une passerelle API. Progressivement, chaque programme COBOL est certifié pour le déploiement dans le cloud, après validation en deux étapes, obtention des pré-approbations réglementaires le cas échéant et migration vers le cloud. L'infrastructure mainframe est ainsi réduite au fur et à mesure que chaque programme obtient sa certification de conformité.

Pourquoi cette approche est-elle efficace pour les organisations soumises à la réglementation ? Elle permet une modernisation rapide des charges de travail non réglementées tout en appliquant la rigueur nécessaire aux charges de travail réglementées. Le périmètre de conformité est clairement défini, auditable et évolue dans un seul sens. L’organisation peut ainsi démontrer aux autorités de réglementation que chaque charge de travail dans le cloud a fait l’objet d’un processus de certification défini et que chaque charge de travail sur site dispose d’une feuille de route de certification.

Questions posées par les auditeurs sur les environnements COBOL hybrides

La conformité n'est pas un état, mais un processus démontrable. La question n'est pas de savoir si votre architecture hybride est conforme, mais si vous pouvez le prouver à une personne dont le métier est de déceler les problèmes.

Voici les questions que se posent les auditeurs des principaux organismes de réglementation dans le contexte des environnements COBOL hybrides, et les éléments de preuve qui permettent d'y répondre :

Où ces données sont-elles stockées et sous quelles juridictions ? Documents requis : une cartographie des données à jour indiquant chaque base de données, fichier VSAM, table DB2 et stockage d’objets cloud, avec la juridiction, la classification et les contrôles en vigueur. Les programmes COBOL qui écrivent dans les ensembles de données doivent figurer sur cette cartographie, leurs résultats étant classés.

« Veuillez me fournir l’historique complet de cette transaction. » Il est nécessaire de fournir une trace de bout en bout, depuis le lancement de la transaction jusqu’au programme COBOL qui a traité les données, en passant par tous les systèmes ayant accédé aux données. Si le programme COBOL ne génère pas ses propres enregistrements d’audit, l’infrastructure sous-jacente doit compenser cette limitation ; cette fonctionnalité doit être explicitement intégrée dès la conception et non présumée.

« Que se passe-t-il pour vos fonctions critiques si votre fournisseur de cloud subit une panne ? » Obligatoire (DORA) : scénarios de résilience opérationnelle documentés, RPO et RTO testés pour les fonctions critiques et preuve que les systèmes sur site peuvent fonctionner indépendamment des dépendances du cloud pendant la durée spécifiée dans la politique de résilience de l'organisation.

« Comment savez-vous que le système migré produit les mêmes résultats que le système d'origine ? » Éléments requis : l'enregistrement de réconciliation des deux exécutions, la couverture des cas de test et, pour les charges de travail sensibles aux calculs, une analyse d'équivalence numérique.

« Qui peut accéder aux données réglementées côté cloud, et quelles approbations régissent cet accès ? » Documents requis : documentation de la politique IAM, enregistrements de gestion des accès privilégiés et preuve que les contrôles d'accès côté cloud sont au moins aussi restrictifs que ceux côté local.

Un cadre décisionnel pour le positionnement de la frontière hybride

Tous les programmes COBOL ne se situent pas du même côté de la frontière hybride. Cette liste de contrôle détermine le placement de chaque charge de travail :

Passer au cloud sans contrainte réglementaire :

• Le programme ne traite aucune donnée personnelle de personnes physiques relevant des juridictions soumises au RGPD/nFADP.
• Le programme ne traite aucune donnée de titulaire de carte (exclusion du champ d'application PCI-DSS confirmée).
• Le programme ne traite aucune information de santé protégée (exclusion du champ d'application de la loi HIPAA confirmée).
• Le programme n'effectue pas les calculs qui servent d'intrants aux ratios de fonds propres réglementaires.
• Le programme ne contient aucune information d'identification ni clé de chiffrement codée en dur dans le code source.
• Les résultats du programme ne sont soumis à aucune exigence de résidence des données dans aucune juridiction.

Nécessite une conception de conformité avant la migration vers le cloud :

• Le programme génère ou traite des données personnelles, analyse d'impact sur les données complète
• Le programme est conforme à la norme PCI-DSS ; questionnaire d’auto-évaluation/certificat de conformité complet pour l’environnement cloud.
• Le programme effectue les calculs de capital réglementaire et l'analyse complète d'équivalence numérique.
• Le programme ne génère pas de journal d'audit ; il est nécessaire de concevoir des contrôles compensatoires avant la migration.
• Le programme contient des clés codées en dur ; corrigez-les avant de l'exposer au réseau cloud.

Doit rester sur place jusqu'à l'obtention de l'approbation réglementaire préalable :

• Le programme est classé comme fonction critique ou importante en vertu de la DORA
• Le programme est soumis aux exigences de résilience opérationnelle de la FCA/PRA en tant que service commercial important
• L’autorité de régulation a expressément exigé une notification ou une approbation préalable pour les modifications apportées au système (pratique courante dans les systèmes bancaires centraux).

Comment SMART TS XL Prend en charge la planification d'architectures hybrides pour COBOL réglementé.

Les décisions décrites dans ce guide – définition du périmètre de conformité, identification des programmes traitant des données réglementées, des exigences de correction de sécurité et des fonctions de calcul nécessitant une validation d'équivalence – requièrent une connaissance structurelle précise de chaque programme du portefeuille COBOL. Cette connaissance ne peut être déduite de la documentation. Dans les environnements COBOL réglementés, la documentation existante a généralement été rédigée pour un système modifié à de nombreuses reprises sans mise à jour documentaire correspondante.

SMART TS XL's analyse de code statique L'analyse révèle les schémas de sécurité et de conformité du code source COBOL qui déterminent de quel côté de la frontière hybride appartient chaque programme : identifiants codés en dur dans WORKING-STORAGE, gestion des clés de chiffrement, génération (ou absence) des journaux d'audit et schémas de calcul ayant une incidence sur le capital réglementaire. Ces constats étayent le travail de conception de la conformité qui doit précéder le placement de la frontière hybride pour les charges de travail réglementées.

La cartographie des dépendances applicatives révèle quels programmes partagent des données avec quels autres, ainsi que les schémas d'accès aux données entre programmes. Ces schémas déterminent si le déploiement d'un programme dans le cloud crée un flux de données réglementé et imprévu au-delà de la frontière entre les environnements hybrides. Un programme COBOL qui semble traiter uniquement des données opérationnelles peut lire un fichier VSAM contenant également des données personnelles écrites par un autre programme. La cartographie des dépendances rend ces relations de partage de données visibles avant même le tracé de la frontière hybride.

La capacité d'analyse d'impact rend les changements de limites vérifiables : lorsqu'un programme passe d'un environnement sur site à un environnement cloud, l'analyse d'impact recense tous les autres programmes affectés par ce déplacement, les appelants, les consommateurs d'ensembles de données, les flux de tâches JCL , fournissant ainsi la portée du changement comme preuve pour l'organisme de réglementation et comme base pour le programme de tests d'équivalence.

La fonction de recherche d'entreprise permet d'interroger l'inventaire de conformité dans l'ensemble du programme hybride : trouvez en quelques secondes tous les programmes traitant un type de données spécifique, tous les programmes accédant à un cluster VSAM spécifique, tous les fichiers source COBOL contenant un modèle spécifique, et ce, sur des millions de lignes. Pour une organisation réglementée qui doit démontrer à un auditeur que tous les programmes concernés ont été identifiés et évalués, cet inventaire interrogeable constitue la preuve qui remplace l'attestation manuelle.

L'organisme de réglementation ne se soucie pas de votre calendrier de migration.

Le cloud hybride n'est pas une solution temporaire pour les organisations réglementées utilisant COBOL. Pour nombre d'entre elles, il s'agit d'un modèle opérationnel permanent, non pas en raison de limitations techniques, mais parce que le cadre réglementaire régissant leurs données et leurs fonctions exige un contrôle sur site permanent de certaines charges de travail. La question pertinente n'est pas « comment abandonner le mainframe », mais « quelles charges de travail peuvent migrer vers le cloud, selon quelle architecture de conformité, et avec quelles preuves que la frontière est correctement maîtrisée ».

Les architectures hybrides offrent aux entreprises la flexibilité de conserver leurs composants existants sur site tout en permettant l'intégration avec le cloud. Pour les secteurs réglementés, cette flexibilité est essentielle pour certaines catégories de charges de travail. Les entreprises qui réussissent avec les architectures COBOL hybrides sont celles qui définissent explicitement le périmètre de conformité, l'instrumentent dès le départ pour l'auditabilité et considèrent la production de preuves réglementaires comme une exigence architecturale et non comme une simple formalité documentaire.