Refactorer une application COBOL : méthodes, outils et bonnes pratiques en 2025
Refactorer une application COBOL reste un vrai sujet pour beaucoup d’entreprises. Ces bases de code vieillissantes tournent encore dans des systèmes critiques, mais deviennent difficiles à maintenir, à faire évoluer ou à transmettre.
Manque de développeurs formés, environnement vieillissant, logique métier enfouie dans des blocs de code parfois illisibles… La question du refactoring se pose tôt ou tard. Et elle n’est pas théorique.
Ainsi, refactorer du vieux COBOL, ce n’est pas faire du neuf pour faire joli. C’est garantir la continuité, préparer les évolutions, et limiter les risques. Pas de promesse magique ici, juste un tour d’horizon des approches possibles, des outils qui tiennent la route, et des bonnes pratiques pour aborder ce type de projet sans se brûler les ailes.
Ce qui complique vraiment le refactoring COBOL
On ne parle pas ici de simples scripts à remettre au goût du jour. Ce sont souvent des systèmes en production depuis 30 ou 40 ans, construits par strates, avec très peu de documentation.
Refactorer ce genre de base pose plusieurs problèmes bien concrets :
Le code est dense, ancien, et parfois écrit avec des conventions maison.
La logique métier n’est pas toujours visible. Elle est parfois répartie sur des milliers de lignes.
Il n’y a pas ou peu de tests. Et ceux qui existent ne sont pas automatisés.
Les performances sont souvent optimisées au cordeau. Le moindre changement peut casser l’équilibre.
Les développeurs COBOL disponibles sont rares, surtout ceux capables de dialoguer avec les stacks plus récentes.
Ce n’est donc pas juste un problème technique. C’est une équation complète entre code, performance, connaissance et continuité de service.
Trois approches concrètes de refactoring
Il n’y a pas une seule bonne manière de moderniser du COBOL. Voici trois stratégies possibles, souvent combinées dans les projets réels.
1. La traduction automatisée (COBOL vers Java)
Certains outils permettent de convertir du code COBOL en Java de manière automatique. NACA, par exemple, est un convertisseur open-source qui traite des bases de plusieurs millions de lignes.
Un bloc de ce type :
01 WS-EMPLOYEE.
05 WS-NAME PIC X(20).
05 WS-AGE PIC 9(2).
donne en sortie :
public class Employee {
private String name;
private int age;
// Getters and setters...
}
C’est rapide, parfois bluffant, mais le résultat est rarement exploitable tel quel. Le code généré garde une structure très proche du COBOL d’origine : pas orienté objet, peu lisible, difficile à maintenir.
La traduction automatique peut être une première étape, mais elle demande toujours un vrai travail de reprise derrière.
2. Réécriture progressive
Une autre option consiste à faire évoluer le système pas à pas. Cela commence souvent par une mise à jour vers une version plus récente de COBOL (par exemple COBOL 2002, qui permet de structurer le code de manière orientée objet).
Ensuite, les modules sont isolés, réécrits au fur et à mesure, testés et intégrés dans un système plus moderne.
C’est plus lent, mais plus maîtrisé. Et ça permet de valider chaque étape sans remettre en cause l’ensemble.
3. Refonte complète
Parfois, aucune des approches précédentes ne suffit. Le code est trop ancien, trop complexe, ou tout simplement plus adapté aux usages d’aujourd’hui.
Dans ces cas-là, une refonte complète est envisagée. Le système est reconçu en repartant des besoins métiers.
C’est long, risqué, et coûteux, mais c’est aussi l’occasion de faire un vrai saut technologique.
Outils pour refactorer une application COBOL en 2025
Plusieurs outils peuvent accélérer ou fiabiliser un projet de refactoring, même s’ils ne font jamais le travail à votre place.
NACA : convertisseur COBOL / Java open-source, très utilisé dans les grands comptes.
isCobol Evolve (Veryant) : permet d’exécuter du COBOL directement sur la JVM.
SonarQube (avec plugins adaptés) : utile pour analyser la qualité du code COBOL et identifier les zones à risques.
IBM watsonx for z : outil d’IA générative qui assiste l’analyse, la documentation et la modernisation des applications mainframe.
Ce ne sont pas des solutions clés en main, mais bien des leviers à intégrer dans une vraie démarche d’architecture et de refonte.
Bonnes pratiques pour refactorer une application COBOL
Avant de refactorer une application COBOL, il est essentiel de cartographier les modules critiques et d’évaluer leur dépendance métier. Quelques principes simples à garder en tête quand on s’attaque à un projet de cette envergure :
- Faire un audit sérieux de la base existante : dépendances, modules critiques, règles métier implicites.
- Mettre en place des tests (même a posteriori) pour sécuriser les refactorings.
- Travailler par incréments : ne jamais refondre tout un bloc d’un seul coup.
- Documenter tout ce qui peut l’être, surtout ce que l’équipe découvre en lisant le code.
- Mesurer les performances à chaque étape. Ce qui était rapide en COBOL ne l’est pas toujours en Java.
- Anticiper les problèmes de sécurité (authentification, accès aux données, audit des traitements, etc.).
- Préparer le transfert de connaissances, surtout si les développeurs COBOL en place approchent de la retraite.
Et côté budget ? Délai ? Réalité terrain ?
Un projet de refonte COBOL, ce n’est jamais un petit chantier. Mais c’est rarement une option. Quand ça commence à coûter trop cher à maintenir, ou que ça bloque des évolutions métier, il faut agir.
Pour une base de 500 000 à 1 million de lignes, les estimations réalistes tournent autour de 1 à 3 ans de projet, selon l’approche choisie (progressive ou complète) et la qualité du code existant.
Les coûts ? Ils varient largement, mais on est souvent sur une fourchette entre 500 000 € et plusieurs millions d’euros pour un SI complet.
C’est exactement ce qu’on fait aujourd’hui pour plusieurs grands comptes dans la banque, l’assurance ou la logistique.
Ce sont des systèmes critiques, en production depuis 30 ans, que l’on fait évoluer par blocs, sans jamais casser l’existant.
Résultat : une meilleure maintenabilité, un onboarding simplifié pour les équipes de dev modernes, et des performances conservées. Découvrez nos études de cas récentes :
Conclusion
Refactorer une application COBOL, c’est d’abord comprendre ce qu’on a, avant de décider comment le faire évoluer intelligemment.. C’est aussi ce que font déjà les entreprises qui veulent garder le contrôle sur leurs systèmes tout en préparant les années à venir.
Ce n’est pas forcément simple. Ni rapide. Mais c’est réaliste, quand on s’y prend bien, qu’on avance par étapes, et qu’on travaille avec des personnes qui connaissent ce type de code de l’intérieur.
Contact
Votre base COBOL est devenue difficile à faire évoluer ?
On intervient régulièrement sur des projets de refonte COBOL, avec un objectif clair : faire évoluer le système sans risquer de casser ce qui fonctionne.
Que vous envisagiez une transition vers Java, une évolution progressive ou une modernisation partielle, on peut vous aider à poser un cadre technique solide, clarifier les options possibles et avancer par étapes.
Prenez contact, on voit ensemble ce qu’il est possible de faire sur votre périmètre.