Migration COBOL Vers C# : Guide UK 2026

COBOL reste le socle d’une part considérable des logiciels qui tournent dans les banques, les assureurs, les organismes publics et les grands distributeurs britanniques. Une bonne partie traite de l’argent, et une bonne partie fonctionne depuis bien avant que les développeurs qui la maintiennent aujourd’hui aient rejoint l’organisation. À mesure que l’expertise COBOL part à la retraite, la pression pour moderniser croît d’année en année, et une migration COBOL vers C# est l’une des voies que les organisations britanniques envisagent le plus souvent.

Pour les organisations déjà investies dans l’écosystème Microsoft, C# sur .NET est l’une des cibles de migration les plus solides disponibles. C’est un langage moderne, à typage statique et orienté objet, il s’exécute de façon multiplateforme sur .NET 8 et versions ultérieures, et il possède une caractéristique qui le rend particulièrement adapté à COBOL : un type decimal natif conçu pour l’arithmétique financière exacte.

Ce guide explique ce qu’implique réellement une migration COBOL vers C#, les approches à la disposition des entreprises britanniques, ce qu’elle coûte et comment en maîtriser le risque.

TL;DR

• C# est la cible de migration COBOL la mieux adaptée aux organisations déjà sur .NET ou Azure, et son type decimal 128 bits natif se projette directement sur les champs COBOL en décimal condensé (packed decimal), sans bibliothèque tierce
• Les trois grandes approches (conversion automatisée, réécriture parallèle et migration incrémentale « strangler fig ») présentent des profils de risque et de coût différents ; la plupart des entreprises britanniques adoptent une approche hybride
• Une migration de taille moyenne coûte généralement de 200 000 £ à 800 000 £ et prend un à deux ans ; sous-estimer le périmètre est la cause d’échec la plus fréquente
• Les outils de conversion automatisée produisent du C# structurellement correct, mais pas un système fini ; la couche d’accès aux données, les tests et la validation métier restent un travail manuel, quels que soient les outils

Pourquoi C# est une cible solide pour la migration COBOL

C# n’est pas la seule destination sensée pour COBOL. Python, Java, Go, C++ et Rust sont tous valables selon le contexte. C# se distingue pour des raisons précises :

Précision decimal native. C’est de loin l’argument technique le plus fort en faveur de C#. Les champs financiers COBOL utilisent le décimal condensé (COMP-3) et les clauses numériques PIC 9, qui représentent des valeurs exactes en base 10. Le type decimal intégré de C# est un type 128 bits à précision fixe en base 10, conçu spécifiquement pour les calculs financiers et monétaires. Les champs décimaux COBOL s’y projettent directement, préservant une arithmétique exacte sans surprise d’arrondi et sans bibliothèque externe. Java atteint la même exactitude avec BigDecimal, mais seulement au prix d’une API objet plus verbeuse ; les langages qui reposent sur la virgule flottante binaire (double en Java, float64 en Go, f64 en Rust) conviennent mal à l’argent sans travail supplémentaire.

L’écosystème .NET. De nombreuses entreprises britanniques exploitent déjà Windows Server, SQL Server, Active Directory et Azure. Pour ces organisations, migrer COBOL vers C# maintient le système modernisé au sein d’un écosystème que leurs équipes exploitent, supervisent et sécurisent déjà. L’accès aux données se projette proprement sur ADO.NET, Entity Framework Core ou Dapper.

Runtime moderne et multiplateforme. Le .NET moderne n’est pas réservé à Windows. Le code C# 12 se compile et s’exécute sur .NET 8 ou version ultérieure (une version Long Term Support) sous Windows, Linux et macOS, et se déploie naturellement en conteneur sur Azure, AWS ou GCP. Migrer vers C# ne vous enferme plus dans un seul système d’exploitation.

Typage statique et outillage. Le typage statique fort de C# attrape des catégories entières d’erreurs à la compilation, ce qui compte lorsqu’on traduit une logique métier vieille de plusieurs décennies. Visual Studio, Rider et le CLI .NET offrent un support mature pour le débogage, le profilage et le refactoring.

Disponibilité des développeurs. C# figure systématiquement parmi les langages d’entreprise les plus utilisés au Royaume-Uni, si bien que le vivier pour le recrutement et la maintenance à long terme est profond.

Comprendre ce dont vous partez

Les systèmes COBOL dans le contexte des entreprises britanniques se répartissent généralement en quelques catégories, et le caractère de la migration change avec chacune :

Systèmes de traitement par lots. La charge de travail COBOL classique : de grands volumes d’enregistrements lus depuis des fichiers, traités séquentiellement, puis réécrits. Ces systèmes sont en général les plus simples à migrer et se projettent bien sur des services d’arrière-plan C# et des I/O en flux.

Systèmes de traitement transactionnel. Le traitement transactionnel en ligne, souvent piloté par CICS ou IMS sur des mainframes IBM. Ce sont eux qui présentent le plus de risque, car les limites de transaction, le comportement de rollback et la gestion des connexions doivent tous être soigneusement projetés sur des équivalents .NET.

Systèmes de génération de rapports. Le reporting COBOL est couramment migré vers des pipelines C# qui produisent des formats modernes : PDF, Excel ou tableaux de bord web.

Couches d’interface et de middleware. Les programmes COBOL placés entre des systèmes plus anciens et des bases de données deviennent souvent des services C# dans l’architecture modernisée.

Les constructions COBOL qui exigent une vraie traduction

Une migration sûre dépend de la traduction de la sémantique COBOL, et non d’une substitution de texte ligne par ligne. Parmi les constructions qui exigent une projection véritable :

• Les plages PERFORM deviennent des appels de méthodes C#, avec des paragraphes et des sections décomposés en méthodes.
• EVALUATE / WHEN se projette sur des instructions switch C# ou du pattern matching.
• Les noms de condition de 88-level deviennent des propriétés booléennes ou des méthodes utilitaires.
• MOVE CORRESPONDING, REDEFINES et OCCURS exigent une projection soignée sur des champs typés, des unions d’intention, et des tableaux ou collections.
• Les clauses PIC se projettent sur le type C# approprié : string pour l’alphanumérique, short / int / long pour les entiers dimensionnés, et decimal pour les champs en décimal condensé avec préservation de la précision.
• Les directives COPY et REPLACE (copybooks) doivent être résolues avant ou pendant l’analyse syntaxique, y compris les copybooks imbriqués.
• EXEC SQL (DB2), EXEC CICS et l’accès aux fichiers VSAM n’ont pas d’équivalent C# clé en main et sont les parties les plus susceptibles de nécessiter une refonte délibérée vers ADO.NET / Entity Framework Core et des patterns de services modernes.
• L’encodage EBCDIC et les dispositions d’enregistrement à largeur fixe nécessitent une conversion explicite vers Unicode et des modèles typés.

Approches de migration

Il existe trois grandes approches, chacune avec un profil de risque et de coût différent.

1. Conversion automatisée

L’outillage analyse COBOL et génère du C# équivalent. Bien menée, la sortie est du C# 12 structurellement correct avec des namespaces, des classes et une projection decimal correcte. Menée naïvement, elle produit une seule classe bourrée de méthodes statiques, plus difficile à maintenir que le COBOL d’origine.

Idéale pour : les grandes bases de code où la priorité est d’éliminer rapidement la dépendance à COBOL, suivie d’un refactoring incrémental.

Risque : aucun outil ne produit un système fini et prêt pour la production. Le SQL embarqué, les interactions CICS et les appels dynamiques nécessitent encore des décisions humaines.

L’outil de migration COBOL vers C# de Mecanik illustre ce à quoi ressemble une bonne conversion automatisée. Il exécute une pipeline de compilation complète (analyseur lexical, analyseur syntaxique, analyseur sémantique, générateur de code) plutôt qu’une substitution de texte, décompose les sections et paragraphes COBOL en méthodes C#, projette les champs COMP-3 sur le type decimal natif, résout les directives COPY / REPLACE y compris les copybooks imbriqués, et produit un Migration Report qui signale chaque EXEC SQL, EXEC CICS et CALL dynamique nécessitant une attention manuelle. Il gère aussi les détails pratiques, comme le préfixage des identifiants entrant en collision avec des mots réservés de C# et la conversion des noms de style ACCOUNT-RECORD en PascalCase.

2. Réécriture parallèle

Le système C# est construit en parallèle du système COBOL existant. Les deux fonctionnent sur les mêmes entrées, et les sorties sont validées l’une contre l’autre jusqu’à ce que le système C# soit conforme, moment auquel COBOL est mis hors service.

Idéale pour : les systèmes critiques où la continuité ne peut être mise en péril, comme les paiements, la paie et les prestations sociales.

Risque : faire tourner deux systèmes en parallèle double le coût d’exploitation pendant la migration et exige un rapprochement rigoureux.

3. Migration incrémentale (Strangler Fig)

Les programmes COBOL individuels sont remplacés un à un par des équivalents C#. Le système devient hybride puis, à terme, purement C#.

Idéale pour : les grands systèmes COBOL monolithiques où une réécriture complète est irréaliste. Elle permet à l’équipe d’apprendre et d’itérer tout en maintenant l’activité en marche.

Risque : l’état hybride peut persister plus longtemps que prévu, et il exige une conception soignée des interfaces entre les composants COBOL et C#.

Pour la plupart des migrations d’entreprises britanniques, l’approche strangler fig combinée à une conversion automatisée sélective pour les sections riches en code répétitif offre le meilleur équilibre entre risque et vélocité.

Coûts d’une migration COBOL vers C# au Royaume-Uni

Le coût dépend fortement de la taille de la base de code, de sa complexité et de l’approche. Fourchettes indicatives pour des projets d’entreprises britanniques :

Ces chiffres couvrent l’analyse, la migration, les tests et le support de mise en production. Ils excluent les coûts d’exploitation continus, la formation et le travail d’intégration en aval qui surgit souvent en cours de projet.

Le service de migration COBOL vers C# de Mecanik est spécialisé dans les migrations d’entreprises britanniques et couvre l’évaluation, la conversion, l’implémentation de la couche d’accès aux données Entity Framework et les tests de parité des sorties. Pour les organisations qui pèsent plusieurs langages cibles, le panorama de la migration COBOL présente l’éventail complet des options, dont Python, Java, Go, C++ et Rust, et le guide de migration COBOL vers Python traite la cible alternative la plus populaire avec la même profondeur que celui-ci.

Pour les migrations où le COBOL tourne sur IBM z/OS ou une infrastructure similaire, le service de migration de mainframe legacy de Mecanik couvre le décommissionnement de l’infrastructure aux côtés de la migration du code.

Risques clés et comment les maîtriser

Les migrations COBOL vers C# dérapent ou échouent pour des raisons prévisibles :

Logique métier non documentée. Les systèmes COBOL portent souvent 30 à 40 ans de règles métier enfouies dans le code sans aucune documentation externe. Découvrir et documenter cette logique est la partie la plus chronophage et la plus risquée de toute migration.

Dépendances aux formats de données. Le décimal condensé (COMP-3), l’encodage EBCDIC et les dispositions à largeur fixe n’ont pas d’équivalent C# automatique. Le type decimal de C# règle proprement le volet arithmétique, mais chaque champ doit tout de même être projeté et testé avec des données réelles avant la bascule.

La couche d’accès aux données. Convertir la logique COBOL est souvent plus facile que remplacer son accès aux données. EXEC SQL contre DB2 et la gestion des fichiers VSAM doivent être reconçus vers ADO.NET, Entity Framework Core ou Dapper, et c’est fréquemment le poste de travail unique le plus lourd.

Attentes de performance. Un traitement par lots COBOL qui liquide 10 millions d’enregistrements du jour au lendemain fixe une barre qu’une réécriture C# naïve peut ne pas atteindre. Le profilage, l’optimisation et parfois des changements d’architecture sont nécessaires.

Couverture des tests de non-régression. Le seul moyen fiable de prouver que la sortie C# correspond à celle de COBOL est un test de non-régression complet avec des données réelles (anonymisées lorsque nécessaire). Bâtir cette suite de tests avant le début de la migration n’est pas optionnel.

Risque de bascule. Le passage à C# en production est le moment le plus risqué. Un plan de bascule détaillé, avec des procédures de rollback et des contrôles de rapprochement, est impératif.

Points clés à retenir

• C# est la cible de migration COBOL la plus solide pour les organisations sur l’écosystème .NET ou Azure, en grande partie parce que son type decimal 128 bits natif se projette directement sur les champs COBOL en décimal condensé avec une précision exacte et sans bibliothèque externe.
• Les trois grandes approches sont la conversion automatisée, la réécriture parallèle et la migration incrémentale ; la plupart des projets d’entreprises britanniques utilisent l’approche strangler fig avec une automatisation sélective.
• Les coûts vont d’environ 80 000 £ pour les petits systèmes à des programmes de plusieurs millions de livres pour les décommissionnements complets de mainframe.
• Les plus grands risques sont la logique métier non documentée, les dépendances aux formats de données et la refonte de la couche d’accès aux données. Traiter ces trois points avant le début de la migration est essentiel.

Foire aux questions (FAQ)

Pourquoi migrer de COBOL vers C# plutôt que vers Java ou Python ? Choisissez C# lorsque votre organisation tourne sur l’écosystème .NET ou sur une infrastructure Windows et Azure. Son type decimal natif convient particulièrement bien aux champs financiers de COBOL. Java est le choix naturel pour les équipes sur la JVM, et Python convient aux organisations qui privilégient la lisibilité et l’intégration de l’IA.

Qu’est-ce qui rend le type decimal de C# meilleur pour la migration COBOL ? Le decimal de C# est un type 128 bits, en base 10, à précision fixe, conçu pour les calculs financiers, si bien que les champs décimaux COBOL COMP-3 et PIC 9 s’y projettent directement, avec une arithmétique exacte et sans bibliothèque tierce. Les langages qui utilisent la virgule flottante binaire pour les nombres demandent un travail supplémentaire pour reproduire le comportement décimal de COBOL.

Le code C# migré s’exécute-t-il sur Linux, ou seulement sur Windows ? Il s’exécute sur les deux. C# 12 cible .NET 8 ou version ultérieure, qui est multiplateforme sous Windows, Linux et macOS, et se déploie comme une application standard ou un conteneur sur Azure, AWS ou GCP.

La logique COBOL peut-elle être convertie automatiquement en C# ? Oui, avec de l’outillage. Un bon convertisseur produit du C# structurellement correct avec une structure de classes appropriée et une projection decimal, mais il signale le SQL embarqué, les interactions CICS et les appels dynamiques pour un travail manuel plutôt que de deviner. La couche d’accès aux données et la validation métier restent des tâches humaines.

Qu’advient-il des formats de données COBOL comme COMP-3 et EBCDIC ? Les champs COMP-3 se projettent proprement sur le type decimal de C#. Le texte EBCDIC et les dispositions à largeur fixe nécessitent une conversion explicite vers Unicode et des modèles typés, et chaque structure devrait être testée contre des données réelles avant toute mise en production.

Combien de temps prend une migration COBOL vers C# ? Les systèmes petits et bien documentés prennent trois à neuf mois. Les systèmes d’entreprise de taille moyenne s’étalent sur douze à vingt-quatre mois. Les grands programmes de mainframe peuvent prendre trois à cinq ans pour un décommissionnement complet.