Parcours de modernisation

Moderniser un parc mainframe vers Amazon Web Services avec parité fonctionnelle prouvée.

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).

Chiffres clés

5 patterns

5R AWS appliqués par sous-système (Rehost, Replatform, Refactor, Rebuild, Replace) — arbitrage explicite ATLAS

20-40%

réduction typique du périmètre via Discovery (programmes dormants, copybooks orphelins archivés)

Par vagues

livraison incrémentale, cadence définie au cadrage

Méthodologie ATLAS appliquée

Du cadrage au déploiement, cinq phases structurées.

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.

01Phase 1
Cadrage & Discovery automatique
Étapes ATLAS
E1 Intake · E2 Discovery · E2b Spécification fonctionnelle
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.
Livrable de phase
Inventaire parc + cartographie dépendances + périmètre réduit signé
02Phase 2
Arbitrage 5R & architecture cible AWS
Étapes ATLAS
E3 Mapping dépendances · E4 Architecture cible
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).
Livrable de phase
Plan 5R signé + architecture AWS + budget mensuel estimé
03Phase 3
Migration & tests de caractérisation
Étapes ATLAS
E4b Tests pré-migration · E5 Migration
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.
Livrable de phase
Code cible + suite tests caractérisation + infra AWS as code
04Phase 4
Coexistence strangler fig & audit parité
Étapes ATLAS
E6 Validation parité
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.
Livrable de phase
Registre interne de discordances classées + parité prouvée par sous-système
05Phase 5
Décommissionnement & FinOps
Étapes ATLAS
E7 Livraison
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.
Livrable de phase
Sous-systèmes en production AWS + mainframe décommissionné + équipe cliente autonome + tableaux FinOps

Voir la méthodologie ATLAS complète →

Au cœur de la méthode ATLAS

L'IA pour comprendre le mainframe, pas pour le traduire.

Les offres de modernisation mainframe automatisée proposent deux voies : le replatforming, qui réhéberge le code en conservant sa structure et sa dette, et la refactorisation automatique, qui génère du code cible non idiomatique. Les deux repoussent la question de l'architecture au lieu de la traiter, et la facture d'exploitation cloud arrive avant les bénéfices. 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 d'origine, menées selon plusieurs angles. Ici, ce que nous relisons en priorité : les traitements batch et transactionnels à séparer avant tout choix de service AWS, et les formats de données propriétaires à normaliser en amont de la migration. L'IA intervient comme accélérateur de compréhension, pour déchiffrer des années 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 et pilote la migration pattern par pattern, sous audit de parité.

Cette compréhension exige encore des humains qui connaissent les technologies d'origine. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite sur ces compétences, la Tunisie conserve des développeurs mainframe (COBOL, PL/I, JCL) expérimentés, couplés à des architectes AWS. Ensemble, ils assurent la continuité entre l'intention métier d'origine et le système cible.

Qui est concerné

Contexte métier et enjeux de modernisation.

Mainframe IBM : un patrimoine critique encore largement déployé

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.

Pourquoi AWS comme cible : trois lectures

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.

Patterns 5R : choisir le bon par sous-système

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.

Plateforme source

Mainframe IBM z/OS, AS/400, Unisys, OpenVMS — applications COBOL, PL/I, CICS, JCL, batch

IBM z/OS↗AS/400↗Unisys↗COBOL↗CICS↗

Cible technologique

AWS — EKS / ECS, RDS PostgreSQL ou Aurora, EventBridge, Step Functions, S3, Lambda, AWS Mainframe Modernization (Blu Age, Micro Focus)

PostgreSQL↗

Alternatives technologiques

Comparer les trajectoires cibles.

AWS Mainframe Modernization (Blu Age refactoring)

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.

AWS Mainframe Modernization (Micro Focus replatforming)

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é.

Réécriture manuelle (Refactor / Rebuild)

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.

Replace par SaaS ou services managés

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.

Repère de cadrage

Durée et équipe type pour ce parcours.

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.

Défis

Cartographier un parc mainframe pluri-décennal accumulé sans documentation exhaustive : COBOL, PL/I, CICS, JCL, copybooks, fichiers VSAM ou DB2.
Replacer les traitements batch mainframe (JCL) par des workflows AWS Step Functions ou orchestrations EKS, sans rupture des fenêtres opérationnelles.
Migrer les bases DB2 ou VSAM vers RDS PostgreSQL ou Aurora avec préservation des invariants métier et des performances transactionnelles.
Réécrire la logique transactionnelle CICS en microservices conteneurisés (EKS) ou fonctions managées (Lambda) selon le pattern adapté.
Garantir la parité fonctionnelle stricte avec un registre interne de discordances classées avant chaque mise en production.

Approche ATLAS

Capture de l'existant : inventaire des programmes COBOL, copybooks, JCL, transactions CICS, bases DB2/VSAM, fichiers d'échange. Outils AWS Mainframe Modernization Discovery exploités si pertinents.
Tests de caractérisation écrits en amont sur le mainframe : exports figés des sorties batch, snapshots transactionnels, jeux de données certifiés référence.
Choix de pattern par sous-système : Replatform via AWS Mainframe Modernization (Blu Age automatic refactoring ou Micro Focus replatforming), Refactor manuel pour les programmes critiques, Replace pour les composants commodisables.
Migration pattern par pattern : COPY → classes Java ou Python, PERFORM → méthodes, PIC S9(n)V9(n) → BigDecimal, JCL → Step Functions, CICS → microservices REST.
Runs parallèles mainframe / AWS avec comparaison automatique des sorties, audit de parité, registre de discordances classifié (CRITIQUE / ADAPTATION / COSMÉTIQUE).
Coexistence par sous-système avec strangler fig pattern, bascule progressive, décommissionnement mainframe planifié.

Résultats attendus

Architecture cloud AWS moderne, managée, élastique, observable.
Suite de tests de non-régression automatisée, réutilisable pour les évolutions futures.
Registre des discordances signé pour chaque sous-système migré, archivé pour audit réglementaire.
Réduction de la dette technique mainframe, libération des coûts de licence et de maintenance.
Capacité d'extension (nouveaux services AWS, intégration data lake, exposition API) débloquée par l'architecture cible.

Pièges identifiés et réponse ATLAS

Ce que nous avons appris sur ce chemin de migration.

Piège 01

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.

Réponse ATLAS

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.

Piège 02

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.

Réponse ATLAS

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.

Piège 03

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.

Réponse ATLAS

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.

Piège 04

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.

Réponse ATLAS

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é.

Piège 05

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.

Réponse ATLAS

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.

Expertise associée

Legacy to Cloud

Voir les modules, services et cas d'usage.

Méthodologie propriétaire

Méthodologie ATLAS

10 étapes, 9 principes, parité prouvée.

Composition de la cellule

Une cellule spécialisée pour ce parcours de modernisation.

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.

Durée

Définie au cadrage selon parc et stratégie 5R

Volume

Déterminé à l'issue du POC et du cadrage

Profils

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

Tech Lead AWS

AWS Mainframe Modernization (Blu Age + Micro Focus), EKS/ECS, RDS/Aurora, Step Functions, EventBridge, Lambda

Développeurs COBOL → Java ou Python

Patterns de traduction PIC/COMP-3 → BigDecimal, CICS → REST, JCL → Step Functions, idéalement avec passé COBOL

Ingénieurs cloud AWS

Infrastructure as Code (Terraform, CDK), CI/CD CodePipeline, observabilité CloudWatch + X-Ray, sécurité IAM, networking VPC

DBA DB2/VSAM → RDS PostgreSQL

Migration via AWS DMS, mapping schéma DB2, traduction SQL/PL → PL/pgSQL, audit parité données

QA spécialisé tests de parité

Bench de tests de caractérisation, runs parallèles automatisés, registre de discordances classifié CRITIQUE/ADAPTATION/COSMÉTIQUE

Référent FinOps AWS

Estimation mensuelle par sous-système, tags Cost Explorer, savings plans / reserved instances, tiering S3 / Glacier, optimisation Lambda

Chef de projet

Pilotage vagues fonctionnelles, gouvernance programme, plan de décommissionnement mainframe daté

Questions fréquentes

Ce que les décideurs demandent sur ce parcours.

Combien de temps faut-il pour migrer un parc mainframe vers AWS ?+

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.

AWS Mainframe Modernization avec Blu Age ou Micro Focus, lequel choisir ?+

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.

Que deviennent les bases DB2 et les fichiers VSAM dans la migration ?+

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.

Comment gérer les transactions CICS pendant la migration ?+

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.

Comment maintenir la cohérence des données pendant la coexistence mainframe-AWS ?+

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.

Quels sont les gains opérationnels concrets après migration vers AWS ?+

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.

Vous évaluez une migration mainframe vers AWS ?

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.

POC AWS Mainframe Modernization (4-6 semaines) →Expertise Legacy to Cloud →Modèle Build-Operate-Transfer →

Réalisations