Quelque part au sein d'une grande banque, une équipe d'ingénieurs a récemment terminé de traduire deux millions de lignes de COBOL en Java — une migration qui a duré quatorze mois, passé toutes les suites de tests et mis en production dans les délais, pour que l'équipe de sécurité découvre dès la première semaine que les numéros de carte de crédit, les numéros de sécurité sociale et les soldes de comptes circulaient sans protection à travers des points de terminaison API, un pipeline Kafka et un lac de données analytiques que l'architecture mainframe d'origine n'avait jamais exposés.
La modernisation a réussi, mais la protection des données non, et ce scénario se reproduit bien plus souvent que la plupart des entreprises ne voudraient l'admettre.
Les dépenses en modernisation des mainframes s'accélèrent, mais la conversation reste massivement centrée sur la traduction de code, l'infrastructure cloud et la réduction des coûts, tandis que la sécurité des données — le facteur unique qui détermine si un projet de modernisation crée des risques ou les élimine — reçoit rarement l'attention qu'elle mérite jusqu'à ce que quelque chose se brise.
Le problème de périmètre que crée la modernisation
Les mainframes patrimoniaux n'ont jamais été conçus pour être sécurisés au sens moderne du terme ; ils ont été conçus pour être inaccessibles. Les environnements IBM z/OS s'appuyaient sur l'isolation physique, les contrôles d'accès RACF et la simple obscurité de leur architecture pour protéger les données sensibles, et pendant des décennies, les données sont restées à l'intérieur du périmètre parce qu'il n'y avait nulle part ailleurs où aller.
La modernisation change fondamentalement cette équation, car dès qu'une organisation migre une application COBOL vers le cloud ou réplique des tables DB2 dans un entrepôt de données, les données sensibles commencent à franchir des frontières de confiance qui n'avaient jamais existé auparavant, et chaque nouveau point d'intégration — qu'il s'agisse d'un appel API, d'un pipeline de données ou d'une plateforme d'analyse en aval — devient une surface d'attaque que le modèle de sécurité d'origine n'a jamais été conçu pour protéger.
Le défi est amplifié par l'ancienneté de ces systèmes — le code COBOL est étroitement couplé à une logique métier que personne ne documente pleinement, les développeurs qui l'ont écrit prennent leur retraite, et pratiquement toutes les entreprises exploitant un mainframe partagent la même politique : ne pas installer d'agents, ne pas modifier le code de production, ne pas risquer de perturber les charges de travail qui traitent des transactions critiques.
Pourquoi la traduction de code seule ne suffit pas
Les outils de traduction de code assistés par l'IA ont accéléré le processus de migration — ce qui prenait autrefois des années peut désormais être accompli en quelques mois — mais traduire du COBOL en Java ou en Python ne traduit pas les contrôles de sécurité qui protégeaient les données lorsqu'elles résidaient à l'intérieur du mainframe. Dans un déploiement z/OS typique, le chiffrement est géré au niveau matériel via des processeurs cryptographiques dédiés, le contrôle d'accès est appliqué via RACF ou ACF2, et les données ne sortent jamais sans passer par des processus batch étroitement contrôlés.
Lorsque ces mêmes données migrent vers un environnement cloud natif, cependant, le modèle de protection change entièrement : les données sont désormais distribuées sur plusieurs services, régions et fournisseurs, et le périmètre de conformité sous PCI DSS, HIPAA et RGPD s'étend à chaque système qui touche les données sensibles après qu'elles quittent z/OS. Sans une stratégie de protection des données conçue avant le début de la migration, les organisations constateront qu'elles n'ont pas tant modernisé leur sécurité qu'elles ont migré leur risque.
Protéger les données sans toucher au mainframe
Les approches les plus pratiques pour sécuriser les données pendant et après la modernisation opèrent au niveau de la couche réseau plutôt qu'au niveau de la couche applicative, et cette distinction est importante car modifier des applications COBOL patrimoniales est rarement viable et installer des agents sur des mainframes de production introduit un risque opérationnel inacceptable. Les solutions de protection des données sans agent interceptent les données au fur et à mesure qu'elles circulent entre le mainframe et les systèmes en aval — en tokenisant, masquant ou chiffrant les champs sensibles en temps réel sans modification du code mainframe, des schémas de base de données ou des flux de travail existants — et les meilleures solutions de mise à niveau et de modernisation des mainframes intègrent désormais ce type de sécurité inline comme composant central plutôt que comme une réflexion après coup.
La tokenisation, en particulier, s'est imposée comme la méthode privilégiée pour les entreprises opérant dans des environnements mainframe. Les tokens préservant le format maintiennent la structure de données que les contrôles de validation patrimoniaux attendent — comme la vérification Luhn pour les numéros de carte de crédit — tout en éliminant la relation mathématique entre le token et la valeur d'origine, ce qui signifie que les tokens peuvent circuler à travers les pipelines cloud, les plateformes d'analyse et les intégrations tierces sans exposer de données sensibles ni briser les systèmes en aval qui dépendent de formats cohérents.
Ce que les entreprises doivent évaluer avant de migrer
Les organisations planifiant des programmes de modernisation de mainframes doivent évaluer leur posture de sécurité des données avant que la première charge de travail ne soit déplacée — en particulier, où résident les données sensibles dans les bases de données mainframe et les magasins de données applicatifs, quels chemins de migration exposeront ces données à de nouveaux environnements, et comment la protection persistera une fois que les données auront atteint le cloud. Les entreprises qui réussissent leur modernisation traitent la sécurité des données comme une contrainte de conception dès le premier jour, et non comme une case de conformité cochée rétroactivement, tandis que celles qui échouent ont tendance à découvrir — souvent trop tard — qu'elles ont construit une version plus rapide, moins chère et globalement plus vulnérable de ce qu'elles possédaient déjà.
