Architecte mainframe ↔ AWS
Pont entre z/OS, AS/400 ou Unisys et l'écosystème AWS, choix 5R par sous-système, design coexistence strangler fig
Loading...
Loading...
Migration d'applications mainframe (IBM z/OS, AS/400, Unisys) vers AWS : services managés, conteneurs, événements et bases relationnelles. Capture de l'existant, tests de caractérisation, migration pattern par pattern, audit de parité, registre de discordances. Approche cible AWS avec les patterns 5R (Rehost, Replatform, Refactor, Rebuild, Replace).
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 automatique du parc via AWS Mainframe Modernization Discovery, IBM ADDI ou outils dédiés. Classification de chaque programme par fréquence d'exécution, criticité et dépendances. Archivage ou suppression des programmes dormants (réduction de périmètre 20-40%). Cartographie complète : COBOL, PL/I, CICS, JCL, copybooks, DB2/VSAM, fichiers d'échange.
Arbitrage 5R par sous-système : Replatform via Micro Focus pour critique 24/7 sans réécriture, Refactor via Blu Age pour programmes stables migrables en Java moderne, Rebuild manuel pour stratégique, Replace par SaaS/managés pour commodisables. Architecture AWS cible : EKS/ECS, RDS/Aurora, Step Functions, EventBridge, Lambda. Stratégie FinOps (instance choice, reserved/savings, tagging Cost Explorer).
Tests de caractérisation écrits en amont sur le mainframe : exports figés batch, snapshots transactionnels, jeux certifiés. Migration pattern par pattern : COPY → classes Java, PERFORM → méthodes, PIC S9(n)V9(n) → BigDecimal, JCL → Step Functions, CICS → microservices REST. Build infrastructure AWS via Terraform/CDK. CI/CD CodePipeline.
Runs parallèles mainframe / AWS sur 4 à 8 semaines avec comparaison automatique des sorties. Audit de parité par sous-système, registre interne de discordances classées CRITIQUE / ADAPTATION / COSMÉTIQUE selon grille interne. Coexistence par sous-système avec strangler fig pattern derrière façade API. AWS DMS pour réplication continue DB2 → RDS.
Bascule transactionnelle par sous-système, décommissionnement mainframe planifié sous 3 mois après validation parité. Coexistence bornée par un plan de sortie daté. Suivi FinOps continu (Cost Explorer, tags), optimisation post-prod (autoscaling, savings plans). Transfert d'exploitation à l'équipe cliente avec documentation et 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.
Les mainframes IBM (z/OS, anciens System/360, AS/400, plus tard IBM i, et systèmes Unisys) restent la colonne vertébrale de pans entiers du SI dans la banque, l'assurance, le secteur public et l'administration fiscale. Ils exécutent encore aujourd'hui des transactions critiques 24/7 avec des niveaux de fiabilité difficiles à atteindre sur des architectures plus modernes. Mais l'écart se creuse sur plusieurs fronts : expertise COBOL et CICS qui se raréfie sur le marché du travail, coûts de licence IBM difficiles à justifier face à des cibles cloud, vélocité de livraison ralentie par la chaîne d'outils mainframe historique, et intégration limitée avec les écosystèmes API modernes. Pour les organisations engagées dans une stratégie cloud globale, la question n'est plus si moderniser mais comment et à quel rythme.
AWS s'impose comme cible de modernisation mainframe pour trois raisons. Premièrement, AWS Mainframe Modernization est une offre dédiée qui intègre Blu Age (refactoring automatique COBOL vers Java) et Micro Focus (replatforming COBOL natif sur AWS), couvrant le spectre complet des patterns 5R. Deuxièmement, l'écosystème AWS offre les briques managées nécessaires : RDS / Aurora pour les bases, EKS / ECS pour les conteneurs, Step Functions pour orchestrer le batch, EventBridge pour les événements, Lambda pour les fonctions ponctuelles. Troisièmement, AWS répond aux exigences de souveraineté et de conformité dans plusieurs régions critiques (régions souveraines, conformité FedRAMP, ISO 27001, HIPAA selon le secteur). Notre expertise Legacy to Cloud traite ces migrations, encadrée par la méthodologie ATLAS.
Une migration mainframe ne se traite pas avec un pattern unique. La méthodologie ATLAS impose un arbitrage par sous-système entre les patterns 5R. Rehost (lift and shift via émulation) est rarement satisfaisant car il déplace la dette sans la résoudre. Replatform via AWS Mainframe Modernization (Micro Focus) garde le code COBOL mais le fait tourner sur AWS — utile pour les programmes stables et critiques où la réécriture serait risquée. Refactor via Blu Age convertit automatiquement le COBOL en Java moderne — adapté aux programmes mature avec une logique métier claire. Rebuild (réécriture manuelle) est réservé aux composants stratégiques où le métier doit être repensé. Replace s'applique aux fonctions commodisables (référentiels, reporting, batch standards) qui peuvent être remplacées par des SaaS ou services AWS managés.
Mainframe IBM z/OS, AS/400, Unisys, OpenVMS — applications COBOL, PL/I, CICS, JCL, batch
AWS — EKS / ECS, RDS PostgreSQL ou Aurora, EventBridge, Step Functions, S3, Lambda, AWS Mainframe Modernization (Blu Age, Micro Focus)
Programme COBOL stable avec logique métier claire, sans dépendance lourde à des constructions mainframe non portables. Conversion automatique vers Java moderne, code maintenable, équipes Java disponibles ou formables. Pattern privilégié pour la majorité des programmes transactionnels.
Programme COBOL critique 24/7 où la réécriture serait risquée. Le code COBOL est conservé tel quel et exécuté sur des conteneurs AWS via Micro Focus Enterprise Server. Migration plus rapide, dette technique non résolue mais mainframe libéré.
Composants stratégiques où le métier doit être repensé, ou cas où les outils automatiques produisent du code peu maintenable. Plus long et plus coûteux mais qualité finale supérieure. Notre méthodologie ATLAS couvre spécifiquement cet arbitrage.
Composants commodisables : référentiels client (CRM SaaS), reporting (Power BI, Tableau, QuickSight), batch standards (Step Functions, EventBridge). Pertinent pour libérer le mainframe des fonctions non-différenciantes.
Un programme de migration mainframe vers AWS se structure par vagues fonctionnelles successives, dont la cadence est définie au cadrage selon la taille du parc et la stratégie 5R retenue. La cellule type combine un architecte mainframe-AWS, un tech lead AWS, des développeurs COBOL/Java ou COBOL/Python, des ingénieurs cloud AWS, un ingénieur QA spécialisé tests de parité, un chef de projet. 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é ; les parcs très importants se structurent en plusieurs vagues étalées dans le temps.
Sous-estimer la discovery initiale. Un parc mainframe mature comporte souvent des programmes inactifs, des copybooks orphelins et des chaînes batch que personne ne sait expliquer. Migrer à l'identique reproduit la dette.
Discovery systématique avec extraction automatique du parc (AWS Mainframe Modernization Discovery, IBM ADDI ou outils dédiés), classification de chaque programme par fréquence d'exécution, criticité et dépendances. Les programmes dormants sont archivés ou supprimés, réduisant le périmètre de migration de 20 à 40 %. Voir la méthodologie ATLAS.
Reproduire les constructions mainframe spécifiques sans les adapter. L'arithmétique décimale COBOL (PIC S9(n)V9(n)), les fichiers VSAM, les COPY hierarchiques, les REDEFINES n'ont pas d'équivalents directs en Java ou Python.
Patterns de traduction documentés : PIC S9(n)V9(n) → BigDecimal, VSAM → tables RDS avec indexation adaptée, COPY → classes ou modules, REDEFINES → discriminator pattern. Chaque traduction est validée par tests de caractérisation avant industrialisation. Le registre des discordances classifie chaque adaptation comme CRITIQUE, ADAPTATION ou COSMÉTIQUE.
Négliger les fenêtres batch et la gestion de la cohérence transactionnelle. Le mainframe garantit des invariants forts (transactions ACID, ordonnancement strict des batchs) qu'AWS reproduit différemment.
Conception explicite de la cohérence : Step Functions pour l'orchestration batch avec gestion des erreurs et reprises, transactions distribuées via Saga pattern quand nécessaire, jeux de tests de non-régression sur les invariants critiques (équilibre comptable, séquence des événements, idempotence). Aucune mise en production sans validation des invariants par le métier.
Ignorer le coût AWS à l'échelle. Le POC tourne pour quelques centaines d'euros par mois ; à pleine charge, un parc transactionnel mal architecturé peut atteindre des dizaines de milliers d'euros mensuels.
Stratégie FinOps dès la conception : choix d'instance, autoscaling, reserved instances ou savings plans, optimisation Lambda, tiering S3, archivage Glacier pour les données froides. Estimation mensuelle revue à chaque jalon avec validation budget. Tableaux de bord AWS Cost Explorer + tags par sous-système pour traçabilité.
Laisser mainframe et AWS coexister sans plan de sortie. Une coexistence non datée transforme la migration en double-run permanent, ce qui consomme plus que la migration initiale.
Plan de bascule daté par sous-système. Chaque sous-système suit un cycle court : migration, double run de quatre à huit semaines avec comparaison automatique, puis décommissionnement mainframe après validation. La coexistence du parc complet est encadrée par un plan de sortie daté — jalons et critères de sortie validés en gouvernance programme — pour éviter qu'elle ne s'éternise en double-run permanent.
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, AS/400 ou Unisys et l'écosystème AWS, choix 5R par sous-système, design coexistence strangler fig
AWS Mainframe Modernization (Blu Age + Micro Focus), EKS/ECS, RDS/Aurora, Step Functions, EventBridge, Lambda
Patterns de traduction PIC/COMP-3 → BigDecimal, CICS → REST, JCL → Step Functions, idéalement avec passé COBOL
Infrastructure as Code (Terraform, CDK), CI/CD CodePipeline, observabilité CloudWatch + X-Ray, sécurité IAM, networking VPC
Migration via AWS DMS, mapping schéma DB2, traduction SQL/PL → PL/pgSQL, audit parité données
Bench de tests de caractérisation, runs parallèles automatisés, registre de discordances classifié CRITIQUE/ADAPTATION/COSMÉTIQUE
Estimation mensuelle par sous-système, tags Cost Explorer, savings plans / reserved instances, tiering S3 / Glacier, optimisation Lambda
Pilotage vagues fonctionnelles, gouvernance programme, plan de décommissionnement mainframe daté
Cela dépend essentiellement du nombre de programmes, de la criticité et du pattern 5R retenu. ATLAS livre par vagues fonctionnelles successives plutôt que sur un plan monolithique : chaque vague est définie avec vous au cadrage, livrée avec parité validée, avant d'attaquer la suivante. Les sous-systèmes non critiques sont migrés en premier, les sous-systèmes critiques 24/7 en dernier. Un POC sur le code réel du client mesure la productivité effective et chiffre le programme complet de façon fiable.
Les deux outils répondent à des besoins distincts. Blu Age effectue un refactoring automatique du COBOL vers Java moderne, ce qui élimine la dette technique mais demande une équipe Java capable de maintenir le code généré. Pertinent pour les programmes stables avec logique métier claire, où la maintenance long terme en Java est l'objectif. Micro Focus replatforming garde le code COBOL et l'exécute sur conteneurs AWS via Enterprise Server. Migration plus rapide, le mainframe est libéré, mais la dette technique COBOL persiste. Pertinent pour les programmes critiques 24/7 où la réécriture serait risquée. Beaucoup de programmes mixent les deux selon les sous-systèmes.
DB2 z/OS se traduit naturellement en RDS PostgreSQL ou Aurora PostgreSQL, avec un mapping de schéma et une migration de données via AWS DMS. La syntaxe SQL est largement compatible mais les procédures stockées DB2 SQL/PL nécessitent une réécriture en PL/pgSQL ou en Java côté application. Les fichiers VSAM sont plus complexes : ils n'ont pas d'équivalent direct dans le cloud. Selon l'usage, ils sont migrés vers des tables RDS avec indexation adaptée, vers DynamoDB pour des accès clé-valeur très rapides, ou vers des stockages objet (S3) pour les fichiers historiques rarement accédés. Le choix se fait au cas par cas.
Les transactions CICS sont reconstruites en microservices REST déployés sur EKS ou ECS, ou en fonctions Lambda pour les transactions ponctuelles à faible volume. Les invariants transactionnels CICS (ACID local, isolation, idempotence) sont reproduits explicitement avec des transactions distribuées (Saga pattern) quand plusieurs services sont impliqués. La phase de discovery cartographie chaque transaction CICS, classifie sa criticité et son volume, et choisit le pattern cible adapté. Les tests de caractérisation valident la parité avant chaque mise en production.
Trois patterns selon le cas. Pour les bases en lecture seule depuis AWS pendant la transition, AWS DMS réplique en continu DB2 vers RDS avec une latence de l'ordre de la seconde. Pour les bases en écriture des deux côtés (rare), un bus d'événements (Kafka ou EventBridge) synchronise les modifications avec gestion des conflits métier. Pour les fonctions migrées progressivement, le strangler fig pattern fait cohabiter mainframe et AWS derrière une façade API qui route selon le périmètre déjà migré. La coexistence est planifiée pour ne pas dépasser deux à trois ans.
Cinq gains typiques constatés sur les programmes mainframe vers cloud que nous accompagnons (que la cible soit AWS, Azure ou autre). Premièrement, la libération des coûts de licence mainframe et de maintenance hardware, qui se mesure en millions d'euros annuels sur les gros parcs. Deuxièmement, l'élasticité de la charge : on adapte la capacité au volume sans surdimensionner. Troisièmement, l'observabilité native (CloudWatch, X-Ray) qui réduit le délai d'analyse d'incident. Quatrièmement, la vélocité de livraison débloquée par la chaîne CI/CD AWS et les services managés. Enfin, la capacité d'extension : data lake, machine learning, intégration API moderne deviennent accessibles sans contrainte mainframe.
Trois manières de démarrer — du POC AWS Mainframe Modernization au programme pluriannuel complet. Notre approche couvre les 5 patterns 5R avec arbitrage explicite par sous-système, registre interne de discordances classées, et plafond de coexistence mainframe-AWS à 24-36 mois.