Leur legacy modernisé. Avec parité prouvée, discordances signées.

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.