Des livraisons manuelles
La mise en production repose sur des procédures écrites et sur la vigilance de quelques personnes. Une étape oubliée, et l’incident arrive en production.
DevOps & Mainframe z/OS
COBOL fait encore tourner vos traitements critiques ce matin. Le problème n’est pas le langage, c’est la chaîne de fabrication restée à l’écart des pratiques modernes. Danylog amène Git, l’intégration continue et les tests automatisés sur z/OS — progressivement, sans fragiliser l’existant.
Le constat
Pendant que les équipes web livrent plusieurs fois par jour, les équipes z/OS livrent encore à la main. Ces symptômes reviennent dans presque toutes les DSI que nous accompagnons.
La mise en production repose sur des procédures écrites et sur la vigilance de quelques personnes. Une étape oubliée, et l’incident arrive en production.
Endevor, Changeman ou IBM RTC fonctionnent, mais coûtent cher, isolent vos développeurs des pratiques modernes et rebutent les nouveaux arrivants.
La non-régression repose sur des campagnes manuelles longues. Résultat : on livre moins souvent, donc par lots plus gros, donc plus risqués.
Vos experts COBOL partent en retraite. Les profils qui arrivent ne connaissent ni les outils ni les habitudes, et n’ont aucune envie de les apprendre.
Les équipes open et les équipes mainframe ne partagent ni outils, ni vocabulaire, ni cycle de livraison. Chaque projet transverse en souffre.
Impossible de savoir combien de temps prend réellement une livraison, où sont les blocages, ni ce que coûte le processus actuel.
Ce que nous faisons
Nous ne remplaçons pas votre patrimoine COBOL : nous modernisons la façon dont il est développé, testé et livré. C’est un chantier d’outillage et de pratiques, pas de réécriture.
Notre principe est constant : la nouvelle chaîne se construit à côté de l’ancienne, se prouve sur un périmètre pilote, puis se généralise. Jamais de bascule brutale sur un système critique.
Comment ça se passe
L’ordre compte autant que le contenu. Commencer par l’outillage sans avoir compris la chaîne existante est la façon la plus sûre d’échouer.
Cartographie de la chaîne actuelle, mesure des temps réels, identification des forces et des points de fragilité. Le scénario de transformation se construit sur des faits, pas sur des convictions.
Mise en place d’une chaîne CI/CD parallèle sur un périmètre restreint. On prouve la faisabilité avant d’engager l’organisation.
Une ou deux équipes volontaires basculent réellement. Leurs retours corrigent l’outillage et les procédures avant la généralisation.
Extension progressive, formation des développeurs, indicateurs de suivi. La chaîne historique n’est débranchée qu’en dernier.
Une intervention en cours
Nous intervenons actuellement au sein de l’équipe Mainframe de la Direction des Systèmes d’Information d’un groupe d’assurance français, dont le système d’information sert 25 000 utilisateurs.
L’objectif : construire une chaîne CI/CD moderne pour les développements COBOL et z/OS, fondée sur Git et GitLab CI, en remplacement progressif d’IBM RTC. Rendre les développeurs autonomes et raccourcir les cycles de livraison.
Le projet a commencé par un rapport d’état sur la chaîne existante et une analyse critique du scénario de transformation envisagé — avant tout développement. C’est la méthode que nous recommandons systématiquement.
Pourquoi nous
Ce type de mission ne s’improvise pas. Danylog s’appuie sur seize ans d’ingénierie dans les systèmes d’information de grands comptes — banque, assurance, industrie — dont plusieurs projets de modernisation de chaîne Mainframe menés jusqu’en production.
BNP Paribas · LCL · Société Générale · Valeo · Groupama
Sortie de Changeman chez LCL, intégration continue des composants COBOL, qualité logicielle avec SonarQube, formation des équipes. Ce n’est pas une offre théorique.
Il n’est pas technique. Faire adopter Git à des développeurs qui livrent depuis vingt ans autrement demande de la pédagogie, pas de la contrainte.
z/OS, COBOL, JCL, Db2, CICS d’un côté ; Git, GitLab CI, Ansible, Docker, SonarQube de l’autre. Cette double culture est ce qui manque le plus dans ces projets.
Questions fréquentes
Oui, et c'est la seule façon acceptable de procéder. La nouvelle chaîne se construit en parallèle de l'existante, sur un périmètre pilote, puis la bascule se fait équipe par équipe. À aucun moment la chaîne historique n'est débranchée avant que la nouvelle ait fait ses preuves.
Oui, et c'est le vrai sujet du projet. La difficulté n'est jamais technique, elle est humaine : des équipes qui livrent depuis vingt ans avec Endevor ou Changeman n'adoptent pas Git parce qu'on le leur demande. L'accompagnement, la formation et le choix des équipes pilotes pèsent davantage que l'outillage.
Principalement Endevor, Changeman et IBM RTC vers Git et une intégration continue moderne — GitLab CI ou Jenkins. Nous avons mené ces migrations chez LCL et nous intervenons aujourd'hui sur un projet équivalent dans le secteur de l'assurance.
Git pour la gestion de code, IBM Dependency Based Build pour la compilation incrémentale, Zowe pour l'accès au mainframe depuis les outils modernes, GitLab CI ou Jenkins pour l'orchestration, SonarQube pour la qualité du code COBOL, UrbanCode Deploy ou Ansible pour le déploiement.
Une phase d'étude et de prototypage se compte en mois, une bascule complète en années. Nous recommandons de commencer par un audit de la chaîne existante et un scénario de transformation chiffré, avant tout engagement lourd.
Les deux. L'audit et le cadrage se prêtent bien au forfait. L'accompagnement de la transformation se fait plus naturellement en régie, aux côtés de vos équipes. Nous en discutons selon votre organisation et vos processus d'achat.
Votre projet
Décrivez-nous votre contexte : les outils en place, la taille de vos équipes de développement, et où vous en êtes dans votre réflexion. Nous revenons vers vous sous 48 heures ouvrées.
Si vous n’en êtes qu’au questionnement, un échange sans engagement est souvent le plus utile. Nous vous dirons franchement si le chantier est prématuré — c’est parfois le cas.
✉ contact@danylog.com · ◷ Réponse sous 48 h ouvrées
Nos autres expertises
Remplacer un tableur ou un progiciel inadapté par un outil conçu autour de vos processus.
Une application destinée à vos clients, vos partenaires ou vos équipes sur le terrain.
Centraliser vos données commerciales et automatiser le suivi de votre activité.