Loading...
Access International porte les applications legacy vers le cloud. Nos programmes s'appuient sur la méthodologie ATLAS : dix étapes, neuf principes directeurs, trois familles legacy. Chaque migration est livrée avec un registre interne de discordances classées.
Chaque famille legacy dispose de son catalogue de patterns de migration, de sa bibliothèque de tests de caractérisation et de son référentiel de discordances connues.
Mainframe IBM z/OS, AS/400, Unisys, cobols ouverts
Traduction pattern par pattern, capture de l'état avant migration, suite de tests de caractérisation en amont, audit de parité après portage.
Java 21, .NET Core 8, TypeScript, Python
Delphi Object Pascal, PowerBuilder, Uniface, client/serveur
Reconstitution des interfaces natives Windows, portage des bases embarquées, réécriture des composants propriétaires, parité UI auditée.
.NET Core 8, TypeScript, React, Angular
BizTalk Server 2010 / 2016 / 2020
Cartographie des orchestrations, des maps XSLT et des pipelines, reconstruction sur Logic Apps, Functions et Service Bus, contrats d'interface préservés.
Azure Logic Apps, Azure Functions, Service Bus
IBM Z, AS/400 RPG, CICS
Modernisation incrémentale avec pattern strangler fig, coexistence legacy / cible pendant la transition, bascule transactionnelle par lot. Voir notre page dédiée AS/400 / IBM i 7.5/7.6.
Azure, AWS, conteneurs Kubernetes
La suite de tests caractérise le legacy avant qu'on touche au code cible.
Legacy et cible tournent en parallèle pendant la transition, comparaison continue.
On migre sous-système par sous-système, sans big-bang.
La fidélité fonctionnelle n'est pas un souhait, c'est un livrable mesurable.
Avant livraison, toutes les discordances sont tracées et décidées.
On fige une référence de vérité du système actuel avant de migrer.
Chaque étape a un livrable identifié, un critère de sortie et une porte de validation (gate kill/go). Aucune étape ne démarre tant que la précédente n'est pas validée.
Cadrage du périmètre, contraintes, critères de réussite.
Compréhension approfondie du code legacy, cartographie des intentions métier.
Reconstitution d'une analyse fonctionnelle à partir du code existant.
Fixation d'une référence de vérité : écrans, rapports, jeux de données, transactions.
Cartographie exhaustive des interactions système, fichiers, bases, interfaces.
Conception de la destination technologique : cloud, langage cible, patterns.
Suite de tests de caractérisation avant de toucher au code cible.
Traduction du code pattern par pattern, traçabilité ligne à ligne.
Preuve d'équivalence fonctionnelle entre le legacy et le cible.
Mise en service, documentation, transfert d'exploitation, registre de discordances.
Chaque trajectoire de migration a sa page dédiée : défis spécifiques, approche ATLAS, technologies cibles et FAQ.
COBOL (mainframe IBM z/OS, AS/400, Unisys, GnuCOBOL) → Java 21, Spring Boot, PostgreSQL, Kafka
COBOL (mainframe IBM z/OS, AS/400, Unisys) → .NET Core 8, C#, SQL Server ou PostgreSQL, Azure
COBOL batch (mainframe, AS/400) → TypeScript, Node.js, PostgreSQL, conteneurs
COBOL batch (calcul, reporting, analytique, actuariat) → Python 3, pandas, NumPy, PostgreSQL ou Databricks
Delphi (Object Pascal, VCL, FireDAC) → .NET Core 8, C#, WinForms ou Avalonia, SQL Server
Delphi (client-serveur, VCL) → TypeScript, React ou Angular, Node.js, PostgreSQL
Delphi (Object Pascal, VCL, FireDAC, dbExpress, composants tiers) → Java 21, Spring Boot, JPA, PostgreSQL, REST API, frontend SPA ou JavaFX
PowerBuilder (PowerScript, DataWindow, PBL, Appeon PowerServer) → .NET Core 8 ou Java 21 ou TypeScript, PostgreSQL ou SQL Server, REST API, frontend SPA ou WinForms selon contexte
Mainframe IBM z/OS, CICS, DB2, VSAM → Azure (AKS, App Service, SQL Database, Service Bus)
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)
AS/400 (IBM i, RPG, DB2/400, CL) → Java, .NET Core, TypeScript, PostgreSQL, conteneurs
BizTalk Server 2010 / 2016 / 2020 → Azure Logic Apps, Azure Functions, Service Bus, API Management
La durée dépend du volume de code, de la complexité fonctionnelle et du modèle de delivery choisi. Les chantiers ATLAS sont cadrés à l'étape Intake avec un chiffrage par pattern. La migration est segmentée par sous-système pour maintenir la continuité de service.
Nous produisons une suite de tests de caractérisation qui exécute le legacy et le cible sur les mêmes jeux de données. Chaque écart est documenté, pondéré et soumis au comité de programme pour validation ou compensation. Le rapport de parité est un livrable contractuel.
Chaque discordance est tracée dans un registre interne : cause, impact métier, décision, classification (CRITIQUE / ADAPTATION / COSMÉTIQUE). Les discordances acceptables sont documentées avec justification ; les discordances bloquantes sont corrigées ou compensées avant livraison. Le registre est tenu en interne par Access et partagé avec le client.
Oui, nous livrons régulièrement des POC de migration en quelques semaines pour valider la trajectoire technologique, la productivité par pattern et le chiffrage. Le POC réutilise exactement les outils, méthodes et gabarits du programme complet.
Nos équipes migrent 500 à 1 500 lignes de COBOL par personne-jour selon la complexité des patterns, accélérées par Claude Code et Copilot. Productivité x2-3 vs méthodes manuelles classiques. POC court permet de mesurer la productivité réelle sur le code spécifique du client avant engagement du programme complet.
Le legacy continue de tourner pendant qu'on migre sous-système par sous-système vers la cible. Chaque module migré entre en production indépendamment, avec runs parallèles legacy/cible et comparaison automatique. Aucun big-bang. Aucune interruption de service. Principe P5 d'ATLAS.
Oui. Tous les livrables ATLAS (code, tests, documentation, registre interne de discordances classées, patterns) sont la propriété du client. Pas de black box. En cas de sortie anticipée, le client dispose de tout le matériel pour poursuivre en interne ou avec un autre prestataire.
Fréquemment. Le prime (CGI, Capgemini, Cofomo) porte la relation client et la gouvernance, Access opère la cellule ATLAS depuis Tunis ou Paris en sous-traitance ou partenariat. Nos livrables et rituels s'intègrent à leurs méthodologies. ATLAS ajoute les garanties de parité et le registre de discordances.
Coexistence legacy/cible avec runs parallèles. Bascule transactionnelle par lot après audit de parité. Ciblage prioritaire des transactions non-critiques d'abord, puis critiques avec fallback automatique. CI/CD réversible (principe P4 ATLAS) : tout déploiement peut être annulé en minutes.
Oui si demandé. Nous pouvons maintenir le legacy en parallèle du chantier de migration (fix bugs critiques, évolutions mineures), via modèle AT ou CDS. Cela évite au client de gérer deux prestataires pendant la transition.
L'IA ne remplace pas un mainframe — elle accélère le travail pour moderniser hors du mainframe. Les mainframes (IBM Z, AS/400, Unisys) exploitent des charges business-critiques chiffrées en millions de transactions par heure, avec une latence déterministe et des décennies de règles métier accumulées. Aucun agent IA ne sait aujourd'hui écrire du code production greenfield à cette échelle de complexité sans supervision. Ce que l'IA change : elle rend la modernisation legacy 2x à 3x plus rapide en lisant du COBOL ou du RPG, en extrayant l'intention métier, en générant les tests de caractérisation et en proposant des patterns cibles sous revue humaine. La combinaison de l'engineering augmenté par IA + d'une méthodologie structurée (ATLAS) + de la validation par run parallèle rend la modernisation mainframe économiquement rationnelle là où elle ne l'était pas il y a cinq ans. Voir l'expertise Legacy to Cloud et la méthodologie ATLAS.
La taxonomie classique distingue quatre types de migration, chacun avec un profil d'effort et de risque différent. (1) Migration de stockage — déplacer les données d'un système de stockage à un autre (SAN vers blob cloud, NAS on-premise vers S3) sans changer de format ni de schéma. Risque le plus faible. (2) Migration de base de données — passer d'une base à une autre (Oracle vers PostgreSQL, DB2 vers Azure SQL) souvent avec transformations de schéma. Risque moyen, demande un mapping rigoureux des types de données. (3) Migration applicative — déplacer une stack applicative complète (lift-and-shift, replatform ou refactor). Risque plus élevé parce que la logique métier se déplace avec les données. (4) Migration de processus métier — ré-ingénierie des workflows en plus du déplacement des données et applications, typiquement lors d'une modernisation majeure. Effort le plus élevé, retour le plus important. La plupart des programmes entreprise combinent les quatre. Voir l'expertise Legacy to Cloud.
Nous auditons la faisabilité, le coût et la trajectoire. Un POC de migration peut être livré en quelques semaines avant d'engager le programme complet.