Chargement...
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 de discordances signé.
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.
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.
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 officiel : cause, impact métier, décision. Les discordances acceptables sont documentées avec justification ; les discordances bloquantes sont corrigées ou compensées avant livraison. Le registre est signé 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 de discordances signé, 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, Accenture) 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.
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.