Parcours de modernisation

Porter un parc COBOL vers .NET Core 8 sans rupture de service.

Q: Faut-il choisir .NET Core plutôt que Java pour un COBOL financier ?

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.

Q: Peut-on déployer .NET Core ailleurs que sur Azure ?

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.

Q: Comment migrer les JCL COBOL vers .NET ?

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.

Q: Les outils comme Microsoft Azure Mainframe Migration peuvent-ils automatiser la migration ?

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.

Q: Combien coûte une migration COBOL vers .NET Core ?

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).

Q: Comment gérer la coexistence COBOL / .NET pendant la transition ?

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.

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.

Chiffres clés

240 Md

lignes de COBOL encore en production dans le monde

Reuters / IBM 2022

8:1

ratio de réécriture COBOL vers .NET Core moderne

Par lots

livraison incrémentale, durée définie au cadrage

Méthodologie ATLAS appliquée

Du cadrage au déploiement, cinq phases structuré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.

01Phase 1
Cadrage
Étapes ATLAS
E1 Intake · E2 Discovery · E2b Spécification fonctionnelle
Comprendre le patrimoine COBOL : programmes, copybooks, JCL. Reconstituer une analyse fonctionnelle exploitable. Définir périmètre, contraintes, critères de réussite.
Livrable de phase
Inventaire patrimoine + spec fonctionnelle + chiffrage
02Phase 2
Capture & dépendances
Étapes ATLAS
E2e Capture · E3 Mapping des dépendances
Figer la référence : transactions enregistrées, fichiers VSAM, états imprimés. Cartographier sous-systèmes, bases DB2/IMS, intégrations CICS.
Livrable de phase
Bench de transactions de référence + carto complète
03Phase 3
Architecture cible
Étapes ATLAS
E4 Architecture cible · E4b Tests pré-migration
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.
Livrable de phase
Architecture cible signée + suite de tests
04Phase 4
Migration & parité
Étapes ATLAS
E5 Migration · E6 Validation parité
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.
Livrable de phase
Code .NET + audit de parité par sous-système
05Phase 5
Déploiement & transfert
Étapes ATLAS
E7 Livraison
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.
Livrable de phase
Application en production + équipe cliente autonome

Voir la méthodologie ATLAS complète →

Au cœur de la méthode ATLAS

L'IA pour comprendre le COBOL, pas pour le traduire.

Les convertisseurs COBOL vers C# reproduisent la structure des programmes source dans des classes statiques et des GOTO émulés par des machines à états. Le résultat s'exécute sur .NET, mais dépend souvent d'une runtime propriétaire éditeur qui recrée le comportement COBOL : la dépendance mainframe est remplacée par une dépendance licence. 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 d'origine, menées selon plusieurs angles. Ici, ce que nous relisons en priorité : les traitements par lots pilotés par JCL, les accès fichiers indexés à porter vers SQL Server ou PostgreSQL, et les conversions de type COMP-3 vers decimal. L'IA intervient comme accélérateur de compréhension, pour déchiffrer des années 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 et pilote la migration pattern par pattern, sous audit de parité.

Cette compréhension exige encore des humains qui connaissent les technologies d'origine. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite sur ces compétences, la Tunisie conserve des développeurs COBOL expérimentés, couplés à des architectes .NET et Azure. Ensemble, ils assurent la continuité entre l'intention métier d'origine et le système cible.

Qui est concerné

Contexte métier et enjeux de modernisation.

Quand .NET Core s'impose face à COBOL

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 secteurs concernés

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.

Ce que .NET Core apporte par rapport à Java

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.

Plateforme source

COBOL (mainframe IBM z/OS, AS/400, Unisys)

IBM z/OS↗AS/400↗Unisys↗COBOL↗

Cible technologique

.NET Core 8, C#, SQL Server ou PostgreSQL, Azure

.NET Core 8↗PostgreSQL↗SQL Server↗Azure↗C#↗

Alternatives technologiques

Comparer les trajectoires cibles.

.NET Core 8 + C# + SQL Server + Azure

Écosystème Microsoft dominant, Azure comme plateforme cible, SQL Server déjà en production. Choix par défaut pour les DSI Microsoft-first.

.NET Core 8 + C# + PostgreSQL + Kubernetes

Souveraineté technologique recherchée, souhait d'éviter Azure SQL Database, déploiement conteneurisé agnostique (Azure, AWS, on-premise). Adapté au secteur public européen.

Java 21 + Spring Boot

Écosystème Java déjà dominant dans le SI, compétences Java internes fortes. Voir COBOL vers Java.

TypeScript + Node.js ou Cloudflare Workers

Architecture serverless, volumes modérés, priorité à la vélocité d'évolution. Voir COBOL vers TypeScript.

Repère de cadrage

Durée et équipe type pour ce parcours.

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é.

Défis

Porter les règles métier vers l'écosystème .NET tout en conservant leur comportement exact.
Migrer les bases VSAM ou DB2 vers SQL Server ou PostgreSQL sans perte de données.
Reproduire les particularités arithmétiques COBOL en .NET (decimal, COMP-3).

Approche ATLAS

Intake et cartographie du parc COBOL : programmes, COPY, fichiers, transactions CICS.
Suite de tests de caractérisation automatisée, comparaison legacy / cible.
Migration incrémentale par sous-système avec coexistence legacy / .NET pendant la transition.
Audit de parité avec registre des discordances avant mise en production.

Résultats attendus

Application .NET Core 8 portable, déployable sur Azure ou infrastructure on-premise.
Suite de tests de non-régression réutilisable pour les évolutions futures.
Documentation technique et fonctionnelle du code migré.

Pièges identifiés et réponse ATLAS

Ce que nous avons appris sur ce chemin de migration.

Piège 01

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.

Réponse ATLAS

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).

Piège 02

Traduire les PIC S9(n)V9(n) COBOL avec le type double ou float en C#. Les erreurs d'arrondi financier sont garanties.

Réponse ATLAS

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.

Piège 03

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.

Réponse ATLAS

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.

Piège 04

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.

Réponse ATLAS

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.

Piège 05

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.

Réponse ATLAS

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.

Expertise associée

Legacy to Cloud

Voir les modules, services et cas d'usage.

Méthodologie propriétaire

Méthodologie ATLAS

10 étapes, 9 principes, parité prouvée.

Composition de la cellule

Une cellule spécialisée pour ce parcours de modernisation.

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.

Durée

Définie au cadrage selon volume et criticité

Volume

Déterminé à l'issue du POC et du cadrage

Profils

Architecte mainframe ↔ .NET

Pont entre z/OS, AS/400 et l'écosystème Microsoft .NET Core / Azure

Tech Lead .NET

.NET Core 8, C#, Entity Framework, patterns de migration COBOL→.NET

Développeurs .NET

Idéalement avec passé COBOL pour la traduction pattern par pattern

DBA mainframe → SQL Server

Migration des schémas DB2/IMS/VSAM vers SQL Server ou Azure SQL

Ingénieur Azure & DevOps

Azure, conteneurs, CI/CD Azure DevOps, observabilité Application Insights

QA & parité fonctionnelle

Bench de tests, comparaison legacy/cible, validation des audits ATLAS

Retour d'expérience Access

Ce parcours en conditions réelles.

POC internes Access — multi-secteurs

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.

POC multi-secteurs · Ratio observé 8:1 COBOL→.NET · Parité arithmétique

Questions fréquentes

Ce que les décideurs demandent sur ce parcours.

Faut-il choisir .NET Core plutôt que Java pour un COBOL financier ?+

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.

Peut-on déployer .NET Core ailleurs que sur Azure ?+

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.

Comment migrer les JCL COBOL vers .NET ?+

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.

Les outils comme Microsoft Azure Mainframe Migration peuvent-ils automatiser la migration ?+

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.

Combien coûte une migration COBOL vers .NET Core ?+

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).

Comment gérer la coexistence COBOL / .NET pendant la transition ?+

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.

Vous évaluez une migration COBOL vers .NET Core ?

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.

Audit COBOL (4-6 semaines) →Expertise Legacy to Cloud →Modèle Build-Operate-Transfer →

Réalisations