Architecte mainframe ↔ Azure
Pont entre z/OS, CICS, DB2 et l'écosystème Azure, design de la coexistence strangler fig, arbitrage de trajectoire par sous-système
Loading...
Loading...
Modernisation d'applications mainframe IBM z/OS vers Microsoft Azure, via la stratégie strangler fig et la méthodologie ATLAS.
Chaque phase regroupe une ou plusieurs des dix étapes ATLAS. Aucune phase ne démarre tant que la précédente n'a pas livré son artefact validé. La méthodologie ATLAS rend la migration AS/400 prévisible et auditable.
Extraction du parc via Azure Mainframe Migration, IBM ADDI ou outils dédiés. Classification de chaque programme par fréquence, criticité et dépendances. Cartographie complète : COBOL, CICS, JCL, copybooks, DB2/VSAM.
Arbitrage de trajectoire par sous-système (rehost émulateur, replatform, refactor cloud-native). Architecture Azure : AKS, App Service, Azure SQL, Service Bus, Functions. Cadrage réglementaire (DORA, Solvency II, homologations) et zones souveraines. Stratégie FinOps.
Tests de caractérisation écrits en amont sur le mainframe. Migration pattern par pattern : COPY → classes, PERFORM → méthodes, PIC S9(n)V9(n) → BigDecimal, CICS → microservices REST. Build de l'infrastructure Azure via Bicep/Terraform.
Runs parallèles mainframe / Azure avec comparaison automatique des sorties. Audit de parité par sous-système, registre interne de discordances classées. Coexistence derrière façade API, double écriture DB2 → Azure SQL via Database Migration Service.
Bascule transactionnelle par sous-système, décommissionnement mainframe planifié après validation de parité. Coexistence bornée par un plan de sortie daté. Suivi FinOps continu, transfert d'exploitation à l'équipe cliente avec runbooks.
Les outils de conversion automatique de code legacy produisent du code qui compile, mais qui reste illisible et non maintenable : les patterns d'origine sont recopiés tels quels, sans idiomatisation, avec des dépendances à une runtime propriétaire. Mis en production sans re-caractérisation complète, ce code n'est ni fiable ni évolutif. La traduction automatique de bout en bout n'est pas une méthode de modernisation — c'est un transfert de dette.
Notre méthode est inverse. ATLAS repose sur plusieurs lectures du code legacy, menées selon plusieurs angles : flux de données, règles métier, dépendances, cas limites. L'IA intervient ici comme accélérateur de compréhension — pour déchiffrer des décennies de logique métier accumulée, rétro-documenter des branches non commentées, expliciter l'intention derrière le code. Elle ne décide pas et ne traduit pas : elle éclaire le travail de l'architecte, qui conçoit ensuite l'architecture cible (cloud, base de données, services) et pilote la migration pattern par pattern, sous audit de parité.
Cette compréhension exige encore des humains qui connaissent les langages legacy. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite des développeurs mainframe et legacy, la Tunisie conserve un vivier de développeurs expérimentés (COBOL, Delphi, PowerBuilder, RPG…). Couplés à des architectes et développeurs modernes formés à la méthode ATLAS, ils assurent la continuité entre l'intention métier d'origine et le système cible.
Le mainframe IBM Z reste la colonne vertébrale transactionnelle des grandes banques, assurances, administrations centrales et caisses de protection sociale. Les volumes traités sont impressionnants : un mainframe Z en production absorbe couramment plusieurs milliers de transactions par seconde avec une disponibilité supérieure à 99,999 pour cent. La question n'est donc pas de savoir si le mainframe fonctionne — il fonctionne très bien — mais de savoir à quel coût il fonctionne encore.
Les signaux qui déclenchent la modernisation vers Azure : coût annuel de licence et d'infrastructure mainframe qui pèse sur le budget IT (souvent entre deux et vingt millions d'euros par an pour une grande entreprise), raréfaction des ingénieurs COBOL et z/OS qui oblige à former en continu, fin de support prévisible de certaines versions de DB2 z/OS ou CICS, et standardisation du SI global vers l'écosystème Microsoft Azure. Notre méthodologie ATLAS est conçue pour rendre cette transition prévisible, sur plusieurs années sans arrêt de service.
Le choix d'Azure s'impose chez les DSI déjà engagées dans l'écosystème Microsoft (Active Directory, Office 365, Dynamics 365, Power Platform, SQL Server). Microsoft propose par ailleurs Azure Mainframe Migration comme service dédié, et un partenariat technique avec Micro Focus et Raincode pour la conversion COBOL. Si votre écosystème principal est AWS, regardez le parcours Mainframe vers AWS. L'essentiel : choisir le cloud qui correspond à votre SI global, pas le cloud à la mode.
Écosystème Microsoft dominant, volonté de managed services Azure, migration progressive en strangler fig. Choix par défaut recommandé par Microsoft.
Compétences Java internes fortes, souhait de portabilité cloud. Code Java déployable sur Azure mais potentiellement sur d'autres clouds. Voir COBOL vers Java.
Écosystème Microsoft à tous les niveaux, mutualisation des compétences C#. Voir COBOL vers .NET Core.
Écosystème AWS dominant. Voir Mainframe vers AWS.
Urgence budgétaire, besoin de sortir du mainframe IBM sans refonte immédiate. Approche lift-and-shift qui préserve le code COBOL sur cloud mais ne modernise pas réellement.
Un programme de modernisation mainframe IBM Z vers Azure se structure par vagues fonctionnelles successives, dont la cadence est définie au cadrage selon le volume et la criticité. La cellule type démarre avec un architecte mainframe-cloud senior, un tech lead Azure, des développeurs COBOL-Java/.NET, un DBA DB2-SQL Server, un ingénieur réseau cloud, un QA spécialisé tests de parité, et une direction de livraison. La composition et l'effectif ne sont pas fixés à l'avance : ils sont déterminés à l'issue du POC et du cadrage, une fois le travail réel mesuré ; un parc mainframe de grande entreprise se modernise en plusieurs vagues étalées dans le temps.
Lancer un programme de modernisation mainframe en big-bang. Les échecs de ce type de programme — rupture de service, dépassement budgétaire, abandon — sont fréquents : Gartner prévoit que plus de 70 % des projets de sortie de mainframe lancés en 2026 n'atteindront pas les bénéfices visés, notamment par surestimation des outils d'IA générative.
Stratégie strangler fig obligatoire. On migre sous-système par sous-système, les transactions les moins critiques d'abord, les transactions critiques en dernier. La coexistence mainframe-Azure dure plusieurs années pendant la transition. Notre méthodologie ATLAS cadre explicitement cette progression incrémentale.
Sous-estimer la migration des données VSAM et DB2 vers Azure SQL. Les volumes sont typiquement massifs (téraoctets), les formats binaires EBCDIC compliquent les conversions, et les règles d'intégrité ne sont pas toujours portables.
Phase dédiée data migration avec outils spécialisés (Azure Database Migration Service, IBM Data Replication, Oracle GoldenGate selon contexte). Double écriture mainframe-Azure pendant la période de coexistence pour garantir la cohérence. Tests de parité quotidiens sur les volumes production avec reconciliation automatisée.
Ne pas prévoir la reproduction des mécanismes CICS (pseudo-conversationnel, commarea, temp storage, transient data). Le pattern naïf microservices ne reproduit pas la sémantique CICS.
Architecture cloud avec Azure App Service ou AKS plus Redis ou Azure SQL pour le state distribué. Les commarea deviennent des DTO typés, les transactions pseudo-conversationnelles deviennent des workflows stateless, les temp storages deviennent du cache Redis. Migration vers Azure Service Bus pour le messaging asynchrone qui remplace les MQ mainframe.
Ignorer les contraintes réglementaires sectorielles (banque : DORA, ACPR ; assurance : Solvency II ; administration : homologations sécurité). Un mainframe est souvent homologué, un environnement cloud doit l'être aussi.
Phase de cadrage réglementaire intégrée à l'architecture cible. Azure est déjà certifié pour la plupart des régulations européennes (RGPD, DORA, ISO 27001, SOC 2). Les zones souveraines Azure (France Central, Germany West Central) répondent aux exigences de localisation. Homologation progressive transaction par transaction documentée dans le registre.
Laisser la coexistence mainframe-Azure traîner indéfiniment. Chaque mois de coexistence additionnel cumule les coûts des deux plateformes et complexifie la gouvernance.
Plan de décommissionnement du mainframe daté dès le démarrage du programme. Chaque transaction migrée déclenche la décommission programmée de son équivalent mainframe après une période de double run de trois à six mois. Cible trois à cinq ans maximum pour la décommission totale du mainframe, au-delà la double maintenance devient un anti-pattern.
Plusieurs profils distincts, mobilisés sur la durée du programme. Reproduire cette cellule en interne est rarement réaliste — la pénurie des compétences legacy et la profondeur d'expertise ATLAS rendent l'externalisation structurellement plus rapide et moins risquée.
Pont entre z/OS, CICS, DB2 et l'écosystème Azure, design de la coexistence strangler fig, arbitrage de trajectoire par sous-système
Azure Mainframe Migration, AKS, App Service, Azure SQL, Service Bus, Functions, observabilité Azure Monitor
Patterns de traduction PIC/COMP-3 → BigDecimal, CICS → REST, JCL → orchestration, idéalement avec un passé COBOL
Infrastructure as Code (Bicep, Terraform), CI/CD Azure DevOps, sécurité Entra ID, networking VNet
Migration via Azure Database Migration Service, mapping de schéma DB2, double écriture, audit de parité données
Bench de tests de caractérisation, runs parallèles automatisés, registre de discordances classifié
Estimation mensuelle par sous-système, cadrage réglementaire (DORA, Solvency II, homologations), zones souveraines Azure
Pilotage des vagues fonctionnelles, gouvernance programme, plan de décommissionnement mainframe daté
POC internes validant les patterns de transformation mainframe (COBOL, JCL, CICS, VSAM, DB2) vers stack cloud cible (.NET Core ou Java sur Azure AKS, Azure SQL, Azure Service Bus). Approche strangler fig appliquée sur des périmètres représentatifs.
La modernisation se livre par vagues fonctionnelles successives plutôt que sur un plan monolithique : la cadence est définie au cadrage selon le volume et la criticité. Les transactions non critiques sont migrées en premier, les transactions critiques (paiements, comptabilité centrale) en dernier. La coexistence mainframe-Azure dure toute la durée du programme. L'objectif est la décommission totale du mainframe à la fin, pas uniquement son allégement.
Oui, c'est le rehosting sur émulateur (Micro Focus Enterprise Server, TmaxSoft OpenFrame). Le code COBOL tourne sur des VMs Azure. Avantages : migration rapide, faible effort initial, préservation du code existant. Inconvénients : pas de modernisation réelle (dette technique préservée), dépendance à un éditeur tiers, coûts de licence émulateur souvent élevés. Nous considérons cette approche comme un palier temporaire utile pour sortir rapidement du hardware IBM, mais pas comme une cible finale. La vraie modernisation vient dans un second temps avec réécriture en Java, .NET Core ou TypeScript.
C'est un accélérateur utile mais pas une solution clé en main. Azure Mainframe Migration propose outils d'analyse, partenariats (Micro Focus, Raincode, Astadia, TmaxSoft), et services managés adaptés aux workloads mainframe. Ces outils peuvent convertir du COBOL vers Java ou .NET automatiquement, mais la sortie nécessite un travail de caractérisation, d'audit de parité et de refactoring significatif. Notre méthodologie ATLAS intègre ces outils comme accélérateurs quand pertinent, sans les considérer comme une fin en soi.
Azure permet une élasticité native que le mainframe n'offre pas à ce prix. Les pics de fin de mois sont absorbés par l'auto-scaling AKS ou App Service, avec montée automatique et descente en creux. L'arrêté comptable annuel peut être traité par un cluster dédié temporaire. Cette élasticité génère des économies significatives par rapport au mainframe dimensionné pour le pic et sous-utilisé le reste du temps. Économie typique : 30 à 50 pour cent sur le TCO à horizon 3 ans après modernisation complète.
Budget pluriannuel typique : trois à quarante millions d'euros selon la taille du parc (un à dix millions de lignes COBOL), conformément aux benchmarks marché 2026 ($3M-$45M range typique migration mainframe → cloud). Co-delivery nearshore qualité permet de réduire le coût de 30 à 50 pour cent par rapport à un programme full onshore. La réduction de TCO observée est de 30 à 50 pour cent sur trois ans (chiffre marché établi, cas publics : Infosys insurance NA 60%, Deloitte insurer EU 80%). L'amortissement se fait généralement en deux à trois ans après décommission complète du mainframe. Voir les modèles de delivery pour les formats contractuels adaptés aux grands programmes pluriannuels.
Trois risques majeurs : fatigue organisationnelle (les équipes fatiguent sur un programme long), changement de priorités direction (budget, stratégie), obsolescence technologique cible (les technologies cibles évoluent en cinq ans). Atténuations : jalons contractuels pour valider chaque palier, livraisons incrémentales avec valeur métier visible chaque année, architecture cible modulaire qui peut être révisée sans remettre en cause les fondations. Notre expérience : les programmes qui livrent de la valeur visible chaque année aboutissent, ceux qui promettent un big-bang à cinq ans dérapent.
Cela dépend de la stratégie de migration et du périmètre. Trois trajectoires avec des profils de coût très différents : lift-and-shift (rehost sur VMs Azure avec émulateurs) est le moins cher à court terme — 3 à 6 mois et quelques centaines de milliers d'euros — mais préserve toute la dette legacy. Replatform (passage à Azure SQL, App Service, Container Apps, en gardant l'essentiel du code) dure 6 à 18 mois et coûte 1 à 5 M€. Refactor (modernisation cloud-native microservices en Java ou .NET sur AKS, avec la méthodologie ATLAS) est le plus cher à l'investissement — 12 à 36 mois et 3 à 15 M€ pour des parcs mainframe typiques — mais c'est aussi le plus rentable parce qu'il élimine les licences et débloque l'évolution. La plupart des clients combinent les trois : lift-and-shift pour les systèmes non critiques, refactor pour le cœur stratégique. Voir le parcours mainframe IBM vers Azure.
Trois manières de démarrer — du POC Azure Mainframe Migration au programme pluriannuel complet. Notre approche est incrémentale, en strangler fig, avec registre interne de discordances classées et plan de décommissionnement daté.