Architecte mainframe ↔ .NET
Pont entre z/OS, AS/400 et l'écosystème Microsoft .NET Core / Azure
Loading...
Loading...
Migration d'applications COBOL mainframe ou AS/400 vers .NET Core 8, sous méthodologie ATLAS. Parité fonctionnelle prouvée, registre interne de discordances classées.
Chaque phase regroupe une ou plusieurs des dix étapes ATLAS. Aucune phase ne démarre tant que la précédente n'a pas livré son artefact validé. La méthodologie ATLAS rend la migration AS/400 prévisible et auditable.
Comprendre le patrimoine COBOL : programmes, copybooks, JCL. Reconstituer une analyse fonctionnelle exploitable. Définir périmètre, contraintes, critères de réussite.
Figer la référence : transactions enregistrées, fichiers VSAM, états imprimés. Cartographier sous-systèmes, bases DB2/IMS, intégrations CICS.
Concevoir l'architecture .NET Core 8 cible : monolithe modulaire ou microservices, base SQL Server ou Azure SQL, hébergement Azure ou on-premise. Préparer les tests de caractérisation.
Traduire COBOL → C# pattern par pattern : COPY → classes C#, PERFORM → méthodes, PIC S9(n)V9(n) → decimal. Migration incrémentale, audit de parité signé sur chaque lot.
Mise en service progressive (strangler fig), coexistence mainframe ↔ .NET dont la durée est définie au cadrage selon profil de risque, bascule transactionnelle par lot, transfert d'exploitation à l'équipe cliente.
Les outils de conversion automatique de code legacy produisent du code qui compile, mais qui reste illisible et non maintenable : les patterns d'origine sont recopiés tels quels, sans idiomatisation, avec des dépendances à une runtime propriétaire. Mis en production sans re-caractérisation complète, ce code n'est ni fiable ni évolutif. La traduction automatique de bout en bout n'est pas une méthode de modernisation — c'est un transfert de dette.
Notre méthode est inverse. ATLAS repose sur plusieurs lectures du code legacy, menées selon plusieurs angles : flux de données, règles métier, dépendances, cas limites. L'IA intervient ici comme accélérateur de compréhension — pour déchiffrer des décennies de logique métier accumulée, rétro-documenter des branches non commentées, expliciter l'intention derrière le code. Elle ne décide pas et ne traduit pas : elle éclaire le travail de l'architecte, qui conçoit ensuite l'architecture cible (cloud, base de données, services) et pilote la migration pattern par pattern, sous audit de parité.
Cette compréhension exige encore des humains qui connaissent les langages legacy. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite des développeurs mainframe et legacy, la Tunisie conserve un vivier de développeurs expérimentés (COBOL, Delphi, PowerBuilder, RPG…). Couplés à des architectes et développeurs modernes formés à la méthode ATLAS, ils assurent la continuité entre l'intention métier d'origine et le système cible.
Le choix de .NET Core comme cible de migration COBOL s'impose dans trois situations typiques. Quand votre SI repose déjà sur l'écosystème Microsoft — Azure, Dynamics 365, Power Platform, SQL Server dominant. Quand vos équipes internes maîtrisent mieux C# que Java, ou quand vos intégrateurs habituels sont orientés Microsoft. Quand vous cherchez à consolider des workloads sur Azure avec les services managés Microsoft (Azure SQL Database, Azure App Service, Azure Functions, Azure Container Apps).
Les parcs COBOL candidats à une migration vers .NET se trouvent chez les banques régionales et caisses mutualistes attachées à Microsoft, les administrations centrales et territoriales standardisées sur l'écosystème Microsoft, les assureurs dotés de Dynamics 365, et les acteurs industriels et retail qui utilisent SQL Server comme référence. Pour ces organisations, migrer vers Java imposerait un changement d'écosystème non souhaité — .NET reste la continuité naturelle.
Techniquement, .NET Core 8 est désormais au niveau de Java 21 sur la performance, la maturité et la disponibilité d'outillage. L'avantage décisif de .NET sur Java dans le cadre d'une migration COBOL : le type decimal natif en C# qui colle parfaitement aux PIC S9(n)V9(n) et aux COMP-3 du COBOL, sans nécessiter une bibliothèque tierce comme BigDecimal en Java. Cette proximité simplifie le mapping arithmétique, qui représente souvent 40 pour cent des calculs dans un parc COBOL financier. Voir COBOL vers Java pour la comparaison détaillée.
.NET Core 8, C#, SQL Server ou PostgreSQL, Azure
Écosystème Microsoft dominant, Azure comme plateforme cible, SQL Server déjà en production. Choix par défaut pour les DSI Microsoft-first.
Souveraineté technologique recherchée, souhait d'éviter Azure SQL Database, déploiement conteneurisé agnostique (Azure, AWS, on-premise). Adapté au secteur public européen.
Écosystème Java déjà dominant dans le SI, compétences Java internes fortes. Voir COBOL vers Java.
Architecture serverless, volumes modérés, priorité à la vélocité d'évolution. Voir COBOL vers TypeScript.
Une migration COBOL vers .NET Core se structure par lots fonctionnels successifs, dont la cadence est définie au cadrage selon le volume et la criticité. La cellule type combine un architecte legacy .NET capable de traduire les concepts mainframe vers l'écosystème Microsoft, un tech lead C# senior, des développeurs .NET idéalement avec un passé Java ou Pascal pour comprendre le typage strict, des ingénieurs QA spécialisés en tests de caractérisation, un DBA SQL Server ou PostgreSQL pour la migration des données VSAM/DB2, et une direction de livraison. La composition et l'effectif ne sont pas fixés à l'avance : ils sont déterminés à l'issue du POC et du cadrage, une fois le travail réel mesuré.
Sous-estimer la migration des bases VSAM et DB2 vers SQL Server ou PostgreSQL. Les curseurs bidirectionnels, les locks optimistes et les accès positionnés VSAM n'ont pas d'équivalent direct en SQL relationnel.
Cartographie exhaustive des accès données dès l'Intake. Les accès positionnés VSAM deviennent des requêtes indexées avec ORDER BY explicite, les curseurs sont remplacés par des itérations avec pagination, les locks optimistes sont portés sur le pattern RowVersion/Concurrency Token .NET. Tests de parité sur les cas limites (record unique, record absent, index composite).
Traduire les PIC S9(n)V9(n) COBOL avec le type double ou float en C#. Les erreurs d'arrondi financier sont garanties.
Mapping systématique PIC S9(n)V9(n) et COMP-3 vers le type decimal natif C# — précision exacte jusqu'à 28 chiffres significatifs, comportement déterministe. Pas de bibliothèque tierce. Tests unitaires sur overflow, underflow et division avec rounding mode explicite.
Reproduire l'architecture monolithique COBOL en C# sans saisir l'occasion de découper en services. Le résultat est une application .NET qui hérite de la dette architecturale COBOL.
Découpage par bounded context métier lors de la phase d'architecture cible. Les programmes COBOL liés sont regroupés en services .NET cohérents, les COPY communs deviennent des librairies partagées NuGet internes. Cette refactorisation structurelle est séparée de la parité fonctionnelle — une phase distincte après bascule.
Oublier les transactions CICS pseudo-conversationnelles. En COBOL-CICS, chaque interaction utilisateur est une transaction courte avec état persistant entre écrans. Le pattern naïf en .NET ne reproduit pas cette sémantique.
Migration vers ASP.NET Core avec Session State distribué (Redis ou SQL Server selon criticité). Les commarea CICS deviennent des DTO sérialisés. Les flows conversationnels sont réécrits en workflow stateless avec state conservé entre requêtes. Tests de charge pour valider la performance sous volume équivalent au legacy.
Déclarer la migration terminée avant d'avoir validé les workflows métier complets en production avec les vrais jeux de données et les vrais utilisateurs.
Principe E7 — validation navigateur et workflow obligatoire avant livraison. Voir la méthodologie ATLAS pour les 10 étapes complètes. Runs parallèles COBOL/.NET pendant quatre à huit semaines avant bascule officielle, avec reconciliation quotidienne des écarts.
Plusieurs profils distincts, mobilisés sur la durée du programme. Reproduire cette cellule en interne est rarement réaliste — la pénurie des compétences legacy et la profondeur d'expertise ATLAS rendent l'externalisation structurellement plus rapide et moins risquée.
Pont entre z/OS, AS/400 et l'écosystème Microsoft .NET Core / Azure
.NET Core 8, C#, Entity Framework, patterns de migration COBOL→.NET
Idéalement avec passé COBOL pour la traduction pattern par pattern
Migration des schémas DB2/IMS/VSAM vers SQL Server ou Azure SQL
Azure, conteneurs, CI/CD Azure DevOps, observabilité Application Insights
Bench de tests, comparaison legacy/cible, validation des audits ATLAS
Plusieurs POC internes couvrant des périmètres représentatifs (banque, assurance, fiscal souverain, CRM, facturation). Patterns COBOL vers .NET validés, ratio observé huit lignes COBOL pour une ligne .NET, parité arithmétique assurée via mapping decimal.
Oui si votre SI est Microsoft-first et/ou si vos équipes maîtrisent C#. Le type decimal natif en C# facilite le mapping PIC S9(n)V9(n) et COMP-3 par rapport à Java BigDecimal. Pour un COBOL bancaire ou assurantiel classique, .NET et Java sont aujourd'hui équivalents en performance et maturité. Le choix se fait sur l'écosystème existant et les compétences internes. Voir COBOL vers Java pour le comparatif.
Oui. .NET Core 8 est cross-platform et s'exécute sur Linux, macOS, Windows, en conteneurs Docker, sur Kubernetes (AKS, EKS, GKE, on-premise), et sur tous les clouds. Vous pouvez donc migrer COBOL vers .NET sans vous lier à Azure si la souveraineté ou la politique cloud de votre entreprise l'exige. SQL Server est également disponible sur Linux, ou remplaçable par PostgreSQL avec adaptations mineures.
Les JCL sont réécrits en batch .NET avec plusieurs options selon le contexte. Pour des batchs simples : Console apps .NET orchestrées par un scheduler (Azure Scheduler, Kubernetes CronJobs, Quartz.NET). Pour des batchs complexes avec étapes, restart, checkpoint : framework Spring-like comme Quartz ou Hangfire. Pour des traitements massivement parallèles : Azure Batch ou Durable Functions. Les paramètres JCL deviennent des arguments de ligne de commande ou de la configuration YAML/JSON.
Partiellement. Azure Mainframe Migration (et les outils équivalents comme Micro Focus, Asysco) peuvent convertir du COBOL vers du code .NET ou Java, mais la sortie est rarement maintenable en l'état : code généré verbeux, patterns COBOL préservés au lieu d'être idiomatisés en .NET, dépendances lourdes sur une runtime propriétaire. Ces outils accélèrent la conversion initiale mais ne remplacent pas la phase de caractérisation ni l'audit de parité. Notre méthodologie ATLAS intègre ces outils comme accélérateurs quand pertinent, sans les considérer comme une solution clé en main.
Pour un programme de cinquante mille lignes COBOL mainframe en co-delivery nearshore qualité, comptez 100 000 à 400 000 euros selon complexité, tests de parité et documentation inclus. Pour cinq cent mille lignes, budget pluriannuel un à quatre millions d'euros selon complexité (références marché : Gartner / Forrester 1.5-4 USD/LOC). Le coût dépend du modèle d'engagement — voir les modèles de delivery pour les formats contractuels (forfait, centre de développement, BOT).
La coexistence est structurée par des passerelles. Azure API Management ou Azure Service Bus servent de pont entre les deux systèmes. Les transactions critiques continuent sur COBOL tant qu'elles ne sont pas migrées, les nouvelles transactions sont implémentées directement en .NET, les routes sont basculées flux par flux. La durée de coexistence est définie au cadrage selon le profil de risque et le rythme de bascule par lot — la double maintenance prolongée doit être anticipée dans le plan de transfert. Voir expertise Legacy to Cloud pour les patterns détaillés.
Trois manières de démarrer — du diagnostic gratuit à la cellule complète. Notre approche COBOL → .NET Core 8 est documentée, chiffrée et applicable dès la première rencontre.