ATLAS. Le cadre qui rend la modernisation legacy prévisible.

ATLAS est le cadre opérationnel d'Access International pour moderniser les applications legacy avec parité prouvée. Elle structure le programme en dix étapes, neuf principes directeurs et six pôles d'équipe. Elle couvre trois familles legacy : COBOL, Delphi et middleware de type BizTalk.

ATLAS impose la parité fonctionnelle avant toute refonte : le code cible doit d'abord reproduire exactement le comportement du legacy, mesuré par des tests de caractérisation écrits en amont. Les discordances sont tracées dans un registre officiel, pondérées et validées ou compensées avant mise en service.

ATLAS couvre trois familles : COBOL (mainframe z/OS, AS/400, Unisys) vers Java, .NET Core, TypeScript ou Python ; Delphi et environnements 4GL vers .NET Core ou TypeScript ; middleware BizTalk et mainframe moderne vers Azure Logic Apps ou AWS.

La durée dépend du volume de code, de la complexité fonctionnelle et du modèle de delivery choisi (AT, CDR, CDC ou CDS). Chaque programme est cadré à l'étape Intake avec un chiffrage par pattern et un plan de livraison par sous-système.

Nous ne publions pas de grille tarifaire. Le chiffrage est construit à l'étape Intake à partir du volume de code, de la complexité fonctionnelle, du modèle de delivery et du niveau de parité visé. Un POC court de quelques semaines permet de mesurer la productivité réelle par pattern avant d'engager le programme complet, avec un chiffrage pluriannuel fondé sur des mesures, pas sur des suppositions.

Tout programme ATLAS est livré avec documentation exhaustive, registre interne de discordances classées et suite de tests automatisés transférés au client. Les patterns migrés et les outils employés sont la propriété du client. En cas de sortie anticipée, le client dispose d'un matériel suffisant pour reprendre le chantier en interne ou avec un autre prestataire, sans black box.

Le transfert est planifié dès l'étape Discovery. Concrètement : pair-programming systématique sur les patterns récurrents, revues de code partagées, bibliothèque documentée des patterns migrés, ateliers mensuels avec les équipes client. À la livraison, le client a une équipe interne autonome sur le socle livré.

Oui. La stratégie strangler fig permet de migrer sous-système par sous-système pendant que le reste du legacy continue de tourner. Chaque module migré est mis en production indépendamment, avec runs parallèles legacy / cible. Aucun client n'est obligé de tout migrer d'un coup.

Un POC court de type Intake + Discovery + migration d'un sous-système représentatif est facturé au coût direct (quelques semaines de cellule). Il s'intègre au chiffrage global si le programme est engagé. S'il est arrêté, le client repart avec les livrables du POC et peut les réutiliser.

Oui. Nous opérons fréquemment en co-delivery : le prime contractor porte la relation client, la gouvernance et la responsabilité contractuelle ; Access opère la cellule ATLAS en sous-traitance ou en partenariat. Les livrables, rituels et outillages restent cohérents avec la méthodologie du prime, auxquels s'ajoute notre cadre ATLAS.

Chaque discordance identifiée entre legacy et cible est tracée dans un registre officiel avec : nature, impact métier, proposition de résolution ou de compensation. Le comité programme (client + Access) arbitre et signe le registre. Les discordances acceptables sont documentées ; les bloquantes sont corrigées avant mise en production.

La suite de tests de caractérisation livrée lors de la validation de parité couvre la grande majorité des comportements métier. Toute régression détectée en production au-delà du périmètre testé est analysée conjointement : si elle relève d'un cas non couvert par le registre, elle est traitée en maintenance évolutive ; si elle entre dans le périmètre garanti, elle est corrigée sous SLA.

La méthodologie ATLAS structure toute modernisation legacy en 10 phases avec gates kill/go entre chaque. E1 Intake — périmètre, contraintes, critères de succès. E2 Discovery — analyse de code en profondeur, cartographie des intentions métier. E2b Spécification fonctionnelle — analyse lisible reconstituée depuis le code existant. E2e Capture de l'existant — référence de vérité figée. E3 Mapping des dépendances — graphe exhaustif des interactions système. E4 Architecture cible — mapping technologique, ADR. E4b Tests pré-migration — suite de caractérisation écrite avant tout code cible. E5 Migration — traduction pattern par pattern avec traçabilité ligne-à-ligne. E6 Validation de parité — preuve d'équivalence fonctionnelle sur jeux de données réels. E7 Livraison — mise en service, documentation, registre interne de discordances classées. Le framework s'adapte à la gouvernance client (Scrum, SAFe, PRINCE2). Voir la méthodologie ATLAS pour le playbook opérationnel complet.

Le pattern strangler-fig (nommé d'après le figuier étrangleur, qui pousse autour d'un arbre hôte jusqu'à ce que l'hôte ne soit plus nécessaire) est l'approche par défaut d'ATLAS pour la modernisation legacy. Au lieu d'une réécriture big-bang, les sous-systèmes migrent un à la fois : un nouveau module est construit, testé, déployé, et le trafic est routé du legacy vers le nouveau système, pendant que le reste du legacy continue de tourner. Après assez d'itérations, le legacy est entièrement remplacé — mais le programme n'a jamais de moment de bascule unique à haut risque. Les avantages : tout sous-système livré entre en production indépendamment, les gates kill/go entre modules permettent de pauser sans perte de travail, et les runs parallèles valident la parité sur le trafic de production réel avant bascule finale. L'approche strangler-fig est le principe 5 de la méthodologie ATLAS. Voir la méthodologie ATLAS pour les détails opérationnels.