Chargement...
ATLAS est la méthodologie propriétaire d'Access International pour moderniser les applications legacy — COBOL, Delphi, BizTalk, mainframe. Elle structure chaque programme autour de dix étapes, neuf principes directeurs et six pôles d'équipe, pour livrer avec parité fonctionnelle prouvée et discordances tracées.
Trois anti-patterns structurels reviennent dans les programmes qui dérivent. ATLAS les neutralise par conception, avant qu'ils ne s'invitent dans l'exécution.
Position courante : profiter de la migration pour restructurer le code.
Deux changements simultanés rendent les régressions indiscernables — écart de migration ou écart de refonte ? Les délais de résolution sont multipliés.
Position courante : les tests seront produits une fois le code cible opérationnel.
Sans référence de comportement, la parité fonctionnelle n'est plus mesurable. La validation devient une opinion, pas un livrable.
Position courante : les écarts ponctuels seront documentés ultérieurement.
Les discordances non qualifiées se manifestent en production. L'effort de correction se déplace vers le client, au moment le plus coûteux.
Chaque principe répond à un risque structurel observé sur nos programmes de migration.
ATLAS n'accélère pas la migration. Elle en sécurise l'atterrissage — parité prouvée, discordances tracées, livraison conforme.
Explorer la méthodologie →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 famille dispose de son catalogue de patterns, 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
Java, .NET Core, TypeScript, Python
Préservation des règles métier accumulées, disponibilité de l'expertise COBOL, réécriture sans rupture de service.
Delphi Object Pascal, PowerBuilder, Uniface, client/serveur
.NET Core, TypeScript, Java
Composants propriétaires, bases embarquées, interfaces natives Windows à reconstituer.
BizTalk Server, IBM Z, AS/400 RPG
Azure Logic Apps, AWS, conteneurs Kubernetes
Orchestration d'échanges critiques, contrats d'interface, transactions distribuées.
L'échec d'une migration legacy est rarement technique. Il est le plus souvent organisationnel : expertise métier absente, arbitrages différés, gouvernance floue. Les six pôles ATLAS éliminent ces angles morts.
Conception de la cible, arbitrages technologiques, contraintes non-fonctionnelles.
Pilotage de la migration pattern par pattern, revues de code, standards.
Traduction du code, tests unitaires, documentation des patterns récurrents.
Tests de caractérisation, audits de parité, automatisation de la non-régression.
Validation fonctionnelle, arbitrage des discordances, priorisation des règles.
Gouvernance, gates kill/go, reporting au client et au prime contractor.
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 de discordances signé 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.
Nous auditons la faisabilité, le coût et la trajectoire de migration. Un échange de trente minutes suffit à identifier les risques structurels.