Chargement...
Méthodologie propriétaire
ATLAS en 10 étapes : la modernisation legacy prévisible
La majorité des programmes de modernisation legacy dérivent pour des raisons organisationnelles, pas techniques. ATLAS structure ces programmes en dix étapes documentées, avec gates kill/go entre chaque phase. Le résultat : des chantiers qui atterrissent au budget, à la date et au périmètre prévus.
Méthodologie · 5 min·5 minutes de lecture
10
étapes avec livrables contractuels
9
principes directeurs
×2-3
productivité via vibe coding
Pourquoi les migrations legacy dérivent
Trois anti-patterns structurels reviennent dans les programmes qui ne tiennent pas leurs engagements.
Le premier est le refactoring pendant la migration. Restructurer le code en même temps qu'on le migre rend chaque régression indiscernable : écart de migration ou écart de refonte ? Les délais de résolution sont multipliés par trois, quatre, parfois dix.
Le deuxième est la couverture de tests insuffisante avant migration. Sans référence de comportement, la parité fonctionnelle n'est plus mesurable. La validation devient une opinion, pas un livrable.
Le troisième est l'absence de traçabilité des discordances. Les écarts ponctuels sont documentés « plus tard », puis se manifestent en production, au moment le plus coûteux et le moins acceptable.
ATLAS neutralise ces trois pièges par conception.
Le cadre ATLAS : 10 étapes, 9 principes
ATLAS est notre cadre opérationnel construit sur 27 ans d'expérience de migrations COBOL, Delphi, PowerBuilder et BizTalk. Il est structuré en dix étapes séquentielles, chacune avec un livrable identifié, un critère de sortie et une porte de validation (gate kill/go).
E1 Intake : cadrage du périmètre et des critères de réussite. E2 Discovery : compréhension approfondie du code legacy. E2b Spécification fonctionnelle : reconstitution d'une analyse lisible. E2e Capture de l'existant : fixation d'une référence de vérité. E3 Mapping des dépendances. E4 Architecture cible. E4b Tests pré-migration : écriture de la suite de tests de caractérisation. E5 Migration : traduction pattern par pattern. E6 Validation de parité. E7 Livraison avec registre de discordances signé.
Aucune étape ne démarre tant que la précédente n'est pas validée. Les neuf principes directeurs (tests d'abord, runs parallèles, strangler fig, audit de fidélité, etc.) imprègnent chaque décision.
L'étape critique : la capture de l'existant (E2e)
Si une seule étape devait résumer ATLAS, ce serait E2e. C'est le moment où l'on fige une référence de vérité du système actuel avant tout changement.
Concrètement : les écrans produits sont capturés en haute fidélité, les rapports sont exportés en jeux de données, les transactions critiques sont rejouées et enregistrées avec leurs effets. Cette base devient la suite de tests de caractérisation qui permettra, à la fin de la migration, de prouver formellement la parité fonctionnelle.
Les équipes qui sautent cette étape se retrouvent en validation finale à devoir prouver quelque chose qu'elles ne peuvent plus mesurer — le comportement attendu n'a jamais été fixé. ATLAS rend cette capture obligatoire, documentée, et signée par le comité programme avant d'ouvrir E3.
Un cas anonymisé : 35 000+ jours-personnes, 36 mois
Sur un programme de modernisation mainframe pour un organisme du secteur public nord-américain, Access a opéré une cellule multi-volets en co-delivery avec un prime contractor local. Méthodologie ATLAS appliquée à la lettre.
La phase E2e a mobilisé 5 ingénieurs pendant 3 mois pour figer la référence de vérité sur les transactions critiques. Cette capture a produit la suite de tests de caractérisation qui a ensuite été exécutée chaque nuit sur le legacy et sur le code cible migré.
Résultat : en fin de programme, la parité fonctionnelle a été prouvée quantitativement sur des milliers de scénarios. Les 47 discordances identifiées ont été arbitrées par le comité programme et documentées dans un registre signé contractuellement.
Pourquoi ATLAS est-elle propriétaire
ATLAS n'est pas une méthodologie publique qu'Access International suivrait comme d'autres. C'est un cadre que nous avons construit, industrialisé et affiné sur 27 ans de chantiers legacy. Il inclut nos bibliothèques de patterns de migration par famille (COBOL, Delphi, BizTalk), nos catalogues de discordances récurrentes, nos gabarits de tests de caractérisation, et nos rituels de gouvernance éprouvés.
Chaque client signe un programme ATLAS dans le sens où il achète à la fois la cellule humaine, la méthode et le patrimoine méthodologique qui va avec. Ce qui l'autorise à poursuivre les évolutions en interne après livraison, équipé de la même rigueur que nous. Voir les quatre modèles de delivery pour comprendre comment ATLAS s'opérationnalise en régie, en forfait ou en centre de services.
Questions fréquentes
Ce que les décideurs demandent sur ce sujet.
Combien de temps dure un programme ATLAS ?+
La durée dépend du volume de code, de la complexité fonctionnelle et du modèle de delivery. Un POC court de 2 à 6 semaines permet de mesurer la productivité réelle avant d'engager le programme complet. Les programmes pluriannuels typiques sur mainframe COBOL durent 24 à 48 mois, découpés en sous-systèmes livrés incrémentalement.
ATLAS est-elle compatible avec une organisation prime contractor ?+
Oui, fréquemment. Le prime (CGI, Capgemini, Cofomo, Accenture) porte la relation client et la gouvernance. Access opère la cellule ATLAS en sous-traitance ou partenariat. Nos livrables, rituels et outillages s'intègrent à la méthodologie du prime, auxquels ATLAS ajoute les garanties de parité et le registre de discordances.
Peut-on migrer par sous-système sans tout refondre d'un coup ?+
Oui, c'est même recommandé via la stratégie strangler fig (principe P5). Le legacy continue de tourner pendant qu'on migre sous-système par sous-système. Chaque module migré entre en production indépendamment avec runs parallèles legacy/cible. Aucun client n'est obligé d'un big-bang.
Que se passe-t-il en cas de sortie de contrat anticipée ?+
Tout programme ATLAS est livré avec documentation exhaustive, registre de discordances signé et suite de tests automatisés transférés. Les patterns migrés et les outils sont la propriété du client. En cas de sortie, le client dispose d'un matériel suffisant pour poursuivre en interne ou avec un autre prestataire.
Votre programme ressemble à ce cas de figure ?
Nous cadrons chaque programme à l'Intake, avec un chiffrage transparent. Un POC court de quelques semaines peut être livré avant d'engager le programme complet.
Parlons de votre programme →