Cobol / mainframe : les projets de modernisation peuvent-ils réussir ?
La mort du mainframe, et du Cobol, est annoncée chaque année depuis 25 ans. En automne 2024, Rocket Software, avec le cabinet Forrester, avait mené une étude auprès de 300 responsables IA, surtout aux Etats-Unis autour du mainframe et de la modernisation des applications. Résultat : le refactoring d'apps mainframe échouent souvent dès les premières tentatives. Le constat est sévère : 90 % des tentatives de réécriture échouent et 50 % des répondants affirment que les échecs successifs freinent ou ont freiné toute tentative de transformation de l'IT et des assets techniques. Plusieurs causes sont cités par l'étude :- un manque de compétences mainframe, Cobol et sur toutes les couches liées- complexité de l'environnement legacy et une stratégie trop complexeModerniser un environnement mainframe / cobol / système z est tout sauf facile. Dire le contraire c'est méconnaître la réalité ou alors il s'agit de petits projets non critiques. Et encore, ces projets peuvent être lancés si les équipes savent ce qu'il y a réellement dans la boîte car parfois la documentation technique n'existe pas, aucune cartographie des couches et des applications existe, etc. Au lieu de tenter une modernisation profonde, elle consiste à faire cohabiter le mainframe / cobol avec des environnements modernes. Une approche hybride est le plus souvent déployée, une minorité d'entreprises décide de déprovisionner le mainframe et une partie des applications liées. Réécrire les applications ? C'est souvent un saut vers l'inconnu et le chantier peut se révéler particulièrement complexe. Et les échecs sont nombreux. Redévelopper de zéro ? Toujours possible mais c'est long, difficile et hasardeux, surtout si le fonctionnement du legacy est mal compris et que la cartographie de l'application n'est pas fiable, ni complète. Une application Cobol (ou autre) peut avoir des dizaines, voire, des centaines de dépendances avec d'autres services et applicatifs. Parmi les défis avant toute modernisation :- comprendre (réellement) son système legecy- avoir les bonnes compétences- penser aux données, aux modèles de données : bref, quid de la migration des données, des bases, des tables, etc. ?- Quels risques pésent sur le bon fonctionnement de l'entreprise ?- définir un budget et une planning réaliste : une modernisation peut coûter très cher et durer plusieurs années. Une vision long terme est cruciale.- avoir une architecture de modernisation claire et définie avant de lancer le chantier et ne pas en changer tous les 6 moisFin mars, Juan Lucas Barbier (un expert en modernisation et en systèmes mainframe) a raconté comment un projet de modernisation s'est crashé après 2 ans d'efforts. Le constat est sévère mais doit faire réflêchir : un DSI qui part et met à jour son CV, 2 années perdues et 70 millions $ dépensés pour pas grand chose... Barbier a vu trop de responsables IT et de dirigeants dire qu'ils vont tout moderniser, enterrer le mainframe et déployer une belle transformation numérique. Il rappelle un simple chiffre : 70 % des projets de modernisation du legacy échouent lamentablement. Les conséquences sont parfois catastrophiques :- 40 % de surcoût qui pèsent sur le budget IT et bloquent d'autres chantiers et investissements- à peine 50 % des promesses de modernisation sont réellement réalisésIl rappelle un fait que nous répétons sans cesse depuis 20 ans à Programmez! : le mainframe et Cobol oui c'est moche, peu intéressant mais ils fonctionnement. Les transactions bancaires reposent sur ces systèmes. Des millions de lignes de code sont écrites chaque année pour maintenir et mettre à jour les apps Cobol.Mais pourquoi autant d'échecs ? Barbier tire, de son expérience, 3 remarques :- certains consultants, dirigeants et DSI disent : ce n'est que du code... Puis il découvrent la plomberie : les règles métiers, les dépendances, tout ce qui n'est pas documenté et parfois des applications que personne ne sait à quoi elles servent mais elles sont là- le syndrome du PowerPoint vs réalité : le remède (= la modernisation) peut être pire que la maladie (= mainframe / cobol)- on fonce et on casse tout : le risque est de détruire des systèmes qui fonctionnement parfaitement. Une approche plus douce serait préférable pour migrer certains assets et garder ce qui fonctionneBarbier n'est pas contre la modernisation mais pour lui, les entreprises qui réussissent la modernisation savent faire des compromis : si le core code fonctionne parfaitement, il ne faut pas y toucher. Le focus est mis sur l'intégration, les API, migrer ce qui est migrable sans casse. Tous les changements doivent être mesurés : le fameux ROI. Vous savez quoi ? Ce constat peut être à toutes applications PHP, Java, C#, C++ qui sont là depuis 10, 15, 20 ans...Catégorie actualité: TechnologiesCOBOL, modernisationImage actualité AMP:
La mort du mainframe, et du Cobol, est annoncée chaque année depuis 25 ans. En automne 2024, Rocket Software, avec le cabinet Forrester, avait mené une étude auprès de 300 responsables IA, surtout aux Etats-Unis autour du mainframe et de la modernisation des applications. Résultat : le refactoring d'apps mainframe échouent souvent dès les premières tentatives. Le constat est sévère : 90 % des tentatives de réécriture échouent et 50 % des répondants affirment que les échecs successifs freinent ou ont freiné toute tentative de transformation de l'IT et des assets techniques.
Plusieurs causes sont cités par l'étude :
- un manque de compétences mainframe, Cobol et sur toutes les couches liées
- complexité de l'environnement legacy et une stratégie trop complexe
Moderniser un environnement mainframe / cobol / système z est tout sauf facile. Dire le contraire c'est méconnaître la réalité ou alors il s'agit de petits projets non critiques. Et encore, ces projets peuvent être lancés si les équipes savent ce qu'il y a réellement dans la boîte car parfois la documentation technique n'existe pas, aucune cartographie des couches et des applications existe, etc.
Au lieu de tenter une modernisation profonde, elle consiste à faire cohabiter le mainframe / cobol avec des environnements modernes. Une approche hybride est le plus souvent déployée, une minorité d'entreprises décide de déprovisionner le mainframe et une partie des applications liées.
Réécrire les applications ? C'est souvent un saut vers l'inconnu et le chantier peut se révéler particulièrement complexe. Et les échecs sont nombreux. Redévelopper de zéro ? Toujours possible mais c'est long, difficile et hasardeux, surtout si le fonctionnement du legacy est mal compris et que la cartographie de l'application n'est pas fiable, ni complète. Une application Cobol (ou autre) peut avoir des dizaines, voire, des centaines de dépendances avec d'autres services et applicatifs.
Parmi les défis avant toute modernisation :
- comprendre (réellement) son système legecy
- avoir les bonnes compétences
- penser aux données, aux modèles de données : bref, quid de la migration des données, des bases, des tables, etc. ?
- Quels risques pésent sur le bon fonctionnement de l'entreprise ?
- définir un budget et une planning réaliste : une modernisation peut coûter très cher et durer plusieurs années. Une vision long terme est cruciale.
- avoir une architecture de modernisation claire et définie avant de lancer le chantier et ne pas en changer tous les 6 mois
Fin mars, Juan Lucas Barbier (un expert en modernisation et en systèmes mainframe) a raconté comment un projet de modernisation s'est crashé après 2 ans d'efforts. Le constat est sévère mais doit faire réflêchir : un DSI qui part et met à jour son CV, 2 années perdues et 70 millions $ dépensés pour pas grand chose... Barbier a vu trop de responsables IT et de dirigeants dire qu'ils vont tout moderniser, enterrer le mainframe et déployer une belle transformation numérique. Il rappelle un simple chiffre : 70 % des projets de modernisation du legacy échouent lamentablement.
Les conséquences sont parfois catastrophiques :
- 40 % de surcoût qui pèsent sur le budget IT et bloquent d'autres chantiers et investissements
- à peine 50 % des promesses de modernisation sont réellement réalisés
Il rappelle un fait que nous répétons sans cesse depuis 20 ans à Programmez! : le mainframe et Cobol oui c'est moche, peu intéressant mais ils fonctionnement. Les transactions bancaires reposent sur ces systèmes. Des millions de lignes de code sont écrites chaque année pour maintenir et mettre à jour les apps Cobol.
Mais pourquoi autant d'échecs ? Barbier tire, de son expérience, 3 remarques :
- certains consultants, dirigeants et DSI disent : ce n'est que du code... Puis il découvrent la plomberie : les règles métiers, les dépendances, tout ce qui n'est pas documenté et parfois des applications que personne ne sait à quoi elles servent mais elles sont là
- le syndrome du PowerPoint vs réalité : le remède (= la modernisation) peut être pire que la maladie (= mainframe / cobol)
- on fonce et on casse tout : le risque est de détruire des systèmes qui fonctionnement parfaitement. Une approche plus douce serait préférable pour migrer certains assets et garder ce qui fonctionne
Barbier n'est pas contre la modernisation mais pour lui, les entreprises qui réussissent la modernisation savent faire des compromis : si le core code fonctionne parfaitement, il ne faut pas y toucher. Le focus est mis sur l'intégration, les API, migrer ce qui est migrable sans casse. Tous les changements doivent être mesurés : le fameux ROI.
Vous savez quoi ? Ce constat peut être à toutes applications PHP, Java, C#, C++ qui sont là depuis 10, 15, 20 ans...