Refactorer les workflows COBOL en mode DevOps : c’est possible (et c’est déjà en cours)
COBOL, mainframe, DevOps : trois mots qu’on n’aurait pas forcément mis dans la même phrase il y a encore dix ans. Et pourtant, c’est aujourd’hui une réalité dans de nombreuses boîtes.
Refactorer les workflows COBOL pour les adapter à une logique DevOps, c’est non seulement faisable, mais souvent indispensable pour tenir les délais, automatiser les tests et fiabiliser les livraisons.
Il ne s’agit pas de tout casser pour “faire comme les applis modernes”, mais plutôt de faire évoluer intelligemment ce qui existe déjà, pour y injecter les bons outils, au bon endroit.
Le vrai sujet : comment faire évoluer les pratiques sans perdre ce qui fonctionne ?
Quand on travaille sur un système COBOL mainframe, on hérite souvent de décennies d’historique. Le code tourne. Il est critique. Et il est souvent stable.
Mais ce qu’on attend aujourd’hui d’un système en production, c’est :
une capacité à livrer vite,
à tester sans tout faire à la main,
à tracer ce qui change,
et à impliquer plusieurs personnes sur une même base, sans se marcher dessus.
Refactorer les workflows COBOL, ça veut dire mettre tout ça en place, sans déstabiliser le cœur du système.
Git sur mainframe : c’est faisable, et même utile
Le contrôle de version est la base de tout workflow DevOps. Sur mainframe, ça demande juste une adaptation.
Pour gérer proprement des fichiers COBOL avec Git, il faut configurer l’encodage. Exemple :
# .gitattributes
*.cob zos-working-tree-encoding=ibm-1047
Cela permet à Git de manipuler les fichiers sans casser les caractères (EBCDIC oblige).
Et dès que Git est en place, on peut enchaîner :
gestion de branches par fonctionnalité,
pull requests,
revues de code,
CI déclenchée automatiquement.
Le plus gros frein, c’est souvent la méconnaissance. Une petite formation Git adaptée au contexte mainframe suffit pour faire décoller les usages.
Automatiser les tests COBOL : pas si compliqué
L’automatisation des tests sur du COBOL, ça existe.
Plusieurs approches sont possibles :
des frameworks comme COBOL Unit Test,
des scripts JCL pour exécuter des tests de non-régression,
et même, dans certains cas, des tests d’interface via Selenium.
Voici un test unitaire simple :
PROGRAM-ID. CALCULATOR-TEST.
PROCEDURE DIVISION.
PERFORM TEST-ADD
PERFORM TEST-SUBTRACT
STOP RUN.
TEST-ADD.
CALL 'CALCULATOR' USING ...
IF RESULT NOT = 8 DISPLAY 'fail' ELSE DISPLAY 'pass'.
TEST-SUBTRACT.
CALL 'CALCULATOR' USING ...
IF RESULT NOT = 6 DISPLAY 'fail' ELSE DISPLAY 'pass'.
Ce genre de test, déclenché automatiquement après chaque build, permet de repérer les régressions avant qu’elles n’arrivent en prod.
Jenkins : de la CI/CD, même pour le mainframe
Oui, on peut utiliser Jenkins dans un contexte mainframe.
Il suffit de configurer un agent qui communique avec le système (SSH, API, scripts JCL, etc.).
Un Jenkinsfile de base pourrait ressembler à ça :
pipeline {
agent any
stages {
stage('Compile') {
steps { sh 'cobc -x program.cob' }
}
stage('Test') {
steps { sh './program' }
}
stage('Deploy') {
steps { sh 'cp program /deploy/path' }
}
}
}
L’idée n’est pas de reproduire un pipeline Java à l’identique, mais d’avoir un enchaînement clair et automatique : build, test, livraison.
Intégrer COBOL aux systèmes modernes
Quand on veut exposer une appli COBOL au reste du monde, plusieurs approches existent :
Un WebServiceBridge écrit en Java, qui joue l’intermédiaire entre le programme COBOL et une API.
L’utilisation de Micro Focus Enterprise Server, pour générer des web services directement depuis des interfaces COBOL.
Le principe reste le même : ne pas réécrire la logique métier, mais l’encapsuler, pour la rendre accessible via des flux modernes.
Résistance au changement ? Oui, mais pas partout
Moderniser un environnement COBOL, ce n’est pas juste une question d’outils.
C’est souvent l’organisation qui bloque :
habitudes anciennes,
crainte de casser l’existant,
manque de visibilité sur ce que ça apporte vraiment.
Ce qui fonctionne bien :
démarrer petit (1 ou 2 workflows),
prouver la valeur (réduction des bugs, temps de déploiement divisé),
former les équipes sans les noyer sous les outils.
Un cas concret : passage au DevOps en environnement bancaire
Une grande banque européenne a entamé la refonte de ses workflows COBOL.
En mettant en place :
Git pour versionner le code,
des tests JCL automatisés,
Jenkins pour exécuter les pipelines,
… elle est passée de 2 semaines à 2 jours entre un correctif et sa mise en production. Et surtout, les développeurs ont gagné en lisibilité, en confiance, et en réactivité.
Cette modernisation des workflows COBOL, on la met en place quotidiennement dans des environnements mainframe sensibles, là où la stabilité ne peut pas être sacrifiée. Ces systèmes tournent depuis des décennies, et on les fait évoluer étape par étape en intégrant des outils modernes comme Git, Jenkins, automatisation des tests, tout en préservant les mécanismes métiers critiques. Découvrez nos interventions :
Conclusion
Refactorer les workflows COBOL, ce n’est pas faire du DevOps “comme chez les autres”.
C’est adapter les outils et les pratiques modernes à un environnement qui a ses propres contraintes — et ses propres atouts.
Git, Jenkins, tests automatisés, exposition en services web… tout cela est possible sur mainframe, à condition de s’y prendre intelligemment, avec méthode, et sans chercher à tout révolutionner d’un coup.
C’est une évolution technique, mais aussi une transition culturelle.
Et aujourd’hui, elle est déjà en cours.
Contact
Vous cherchez à refactorer vos workflows COBOL pour gagner en agilité ?
On intervient sur ce type de modernisation tous les jours : automatisation des tests, versioning Git, CI/CD mainframe…
Prenez contact, on peut vous aider à poser un cadre technique et à enclencher les premières briques sans casser ce qui fonctionne déjà.