COBOL, l’amiante des langages de programmation modernes

COBOL : le langage qui a conquis l’entreprise

Le sigle COBOL (Common Business-Oriented Language), né à la fin des années 1950, est devenu le pilier des systèmes de traitement des transactions dans les entreprises et les administrations. Adopté massivement pour sa lisibilité et son orientation métier, il alimente encore aujourd’hui des applications critiques : cœurs bancaires, systèmes de paiement, distributeurs automatiques, et bases de prestations sociales. Par exemple, pendant la crise sanitaire de 2020, plusieurs États américains (comme le New Jersey et l’Ohio) ont fait appel à des développeurs COBOL pour maintenir et ajuster des systèmes d’indemnisation, illustrant l’emprise durable de ce langage sur l’infrastructure critique.

Les problèmes actuels liés à l’héritage COBOL

Malgré sa robustesse, l’usage massif de COBOL génère des difficultés opérationnelles et stratégiques. Les organisations affrontent une combinaison de contraintes techniques et humaines qui augmentent les risques et les coûts. Points clés :

• Pénurie de compétences : de nombreux développeurs COBOL approchent de la retraite et la formation de remplaçants est limitée.
• Dette technique : du code ancien, peu testé et mal documenté qui masque la logique métier.
• Dépendance aux mainframes : coûts d’exploitation, licences et personnels spécialisés.
• Risques de sécurité : patching et audits compliqués sur des environnements hérités.

Ces facteurs expliquent pourquoi même des acteurs modernes continuent de s’appuyer sur des systèmes COBOL malgré les contraintes.

Pourquoi le retirer est si dangereux et difficile

Remplacer ou réécrire un système COBOL, ce n’est pas seulement changer de langage : c’est risquer de perdre des décennies de règles métier encapsulées. Raisons principales :

• Volume et complexité : des millions de lignes de code avec des dépendances croisées et des traitements batch critiques.
• Manque de tests automatisés : les comportements attendus ne sont souvent vérifiés qu’en production.
• Connaissance métier tacite : des ajustements historiques compris seulement par quelques anciens.
• Coûts et interruptions : une réécriture complète prend des années et peut provoquer des pannes si elle est mal conduite.

Par exemple, une tentative de réécriture d’un noyau bancaire sans couverture de tests peut entraîner des erreurs de règlement affectant des milliers de clients.

Approches réalistes pour moderniser sans tout casser

Il existe des stratégies pragmatiques pour réduire la dépendance au COBOL tout en limitant les risques. Chaque option a ses avantages et ses inconvénients :

• Encapsulation/API : exposer la logique COBOL via des services REST pour permettre l’intégration progressive avec des systèmes modernes.
• Rehosting (lift-and-shift) : migrer des workloads vers des plateformes compatibles ou cloud sans réécriture complète.
• Refactoring incrémental : extraire des modules et les remplacer progressivement en appliquant le pattern « strangler ».
• Traduction automatique : utiliser des outils pour convertir du COBOL en languages modernes (avec revue humaine intensive).
• Réécriture ciblée : reconstruire uniquement les composants les plus problématiques, pas tout le système.

Des banques et des administrations ont combiné ces approches : par exemple, elles ont encapsulé les traitements critiques en API tout en refactorant les composants moins risqués.

Risques à anticiper et mesures de protection

Pour limiter l’impact lors d’une migration ou d’une maintenance, il faut instaurer des garde-fous techniques et organisationnels. Recommandations concrètes :

• Créer des suites de tests automatisés (unitaires, d’intégration, de non-régression) avant toute modification.
• Documenter et cartographier les flux métier et les dépendances du code existant.
• Former et recruter : combiner montée en compétence interne, recours à des experts seniors et recrutement de profils hybrides.
• Déployer par étapes : phases pilotes, validations, bascule progressive et plans de rollback clairs.
• Sécuriser les environnements : audits, patch management, et surveillance en production.

Ces mesures réduisent la probabilité d’incidents majeurs et facilitent la transition.

Perspectives et plan d’action pour les organisations

Plutôt que d’opter pour une solution radicale, la plupart des organisations gagnent à adopter une stratégie graduelle et mesurée. Un plan d’action recommandé :

• Évaluer : inventaire du code COBOL, criticité et coûts d’exploitation.
• Prioriser : identifier les composants à risques et ceux à conserver temporairement.
• Protéger : mettre en place des tests et sauvegardes robustes.
• Moderniser : appliquer encapsulation, rehosting et refactoring selon le cas.
• Soutenir : investir dans la formation, la documentation et la gouvernance.

En adoptant une démarche pragmatique — validation continue, preuve par petites étapes et protection des flux critiques — les organisations peuvent réduire progressivement leur dépendance au COBOL sans compromettre la continuité de service ni la sécurité financière.