Les banques restent fidèles à Cobol, plus performant que Java

Les banques restent fidèles à Cobol, plus performant que Java Bill Curtis, actuellement directeur du CISQ, est l'un de ceux qui ont piloté le modèle de développement CMM. (crédit : CISQ) Bill Curtis, actuellement directeur du CISQ, est l'un de ceux qui ont piloté le modèle de développement CMM. (crédit : CISQ) Selon Bill Curtis, l'un des gourous de la qualité logicielle et pionnier du modèle de développement CMM, Cobol est plus sûr et plus performant que des langages plus récents. Pour Bill Curtis, connu pour avoir piloté le modèle de développement CMM (capability maturity model), les banques vont conserver leurs applications Cobol monolithiques parce que celles-ci ne présentent pas les mêmes problèmes de sécurité et de performance que Java. Et cela, malgré les pannes importantes subies au cours des derniers mois, par exemple en avril dernier à la Llyods Banking Group et, en mars, à la Royal Bank of Scotland, cette dernière ayant coûté des centaines de milliers de livres sterling au groupe bancaire. Des critiques avaient alors visé le système informatique jugé dépassé. Bill Curtis, aujourd'hui directeur du CISQ, Consortium for IT Software Quality(*), est également responsable technique (chief scientist) de la société Cast, qui est spécialisée dans l'analyse et la mesure des applications. Il a expliqué à notre confrère de Computerworld UK Derek du Preez que si les banques rencontraient régulièrement des problèmes avec leurs systèmes Cobol, c'était parce que ces programmes n'étaient pas morcelés en modules plus petits, structure qui réduit le nombre d'anomalies. « Les programmes Cobol sont extrêmement complexes, la taille moyenne d'un module est de 600 lignes de code, alors que celle d'un composant Java est en moyenne de 30 lignes », a rappelé Bill Curtis à nos confrères en remettant en mémoire que de nombreuses applications Cobol ont été conçues avant que l'on s'oriente résolument vers la modularité. « Avec Cobol, il y a une forte corrélation entre la taille du système et la densité des défauts. C'est exponentiel. » Plus le système est grand, plus il y a de défaut sur cent lignes. On ne retrouve pas cela avec Java et les autres langages modernes, note le responsable technique. La différence, c'est que la modularité casse cette corrélation parce que les composants sont plus petits. Ce serait un cauchemar de tout réécrire en Java Pour Bill Curtis, cette situation représente un problème pour les banques parce que la plupart de leurs systèmes exploitent des « monstres Cobol sur mainframe », mais que ce serait désastreux de les redévelopper en Java. « Si vous essayez de tout réécrire de cette façon, ce sera un cauchemar. Cela peut se faire, mais en traversant une période où le taux de défauts va monter en flèche », assure Bill Curtis. Selon lui, les vieux systèmes Cobol, en dépit des problèmes qu'ils présentent, sont en fait plus sûrs et plus performants quand on les compare aux langages modernes tels que Java. Il donne deux raisons à cela. Cela tient d'une part au fait que les systèmes Cobol ne sont pas exposés à Internet, et d'autre part, à un déficit de compétences au sein de la communauté de développeurs Java. « Il y a un langage qui présente un taux de sécurité supérieur à n'importe quel autre langage et c'est Cobol », affirme le responsable scientifique. Pourquoi ? Non seulement parce qu'il fonctionne sur des mainframes moins exposés au web, mais aussi parce qu'ils ont été passés au crible par des générations d'informaticiens dans une industrie où la sécurité reste la question centrale, souligne le directeur du CISQ. « L'autre chose que nous savons sur ces programmes, c'est que, comparés à Java, ils sont vraiment très performants. Java présente toutes sortes de problèmes de performance alors que les systèmes Cobol sont très rapides. » Les banques les ont peaufinés pendant des années pour qu'ils s'exécutent de façon très efficace : haut débit, rythme de transactions élevé, environnements mainframe. « Certains langages plus récents ne sont pas ajustés de cette façon. Selon nos données, certaines applications Java présentent de nombreux problème de performance », note-t-il. Une partie de ceux-ci peuvent être dus à la structure du langage, mais d'autres, selon Bill Curtis, viennent du fait que les personnes qui développent en Java ne sont pas toujours les mieux formées. Analyser le code pour mieux le comprendre Quoi qu'il en soit, pour maîtriser les pannes et les défauts, les banques devraient analyser leur code pour savoir exactement comment il fonctionne, estime Bill Curtis. Le problème du secteur de la finance, c'est que ses systèmes ont été conçus il y a de nombreuses années et que nombre d'entre eux sont utilisés avec une connaissance réduite sur les raisons qui ont conduit à les développer de cette façon. « Ces programmes sont vieux, dépassés, et ceux qui les ont construits sont probablement morts. Et comme de bien entendu, il n'y a pas de documentation. Ils sont monstrueusement complexes, très difficiles à maintenir et à comprendre », rappelle Bill Curtis. « Ce qu'il faut, c'est en analyser le code », ajoute-t-il. Cast et d'autres fournisseurs le font, ajoute-t-il. « Il faut vraiment en connaître la structure. C'est constitué de différentes choses intégrées ensemble pour former ce qu'on appelle une application. Je serai très surpris si le groupe bancaire RBS ne faisait pas cela. En fonction de ce que donne l'analyse, on peut alors cibler certaines parties et en réécrire certains éléments. » (*) Le Consortium for IT Software Quality a été créé en 2009 par Paul Nielsen, CEO du Software Engineering Institute de l'Université Carnegie Mellon, et Richard Mark Soley, chairman et CEO de l'Object Management Group, avec l'objectif de permettre à l'industrie IT de s'entendre sur un système qui puisse mesurer de façon cohérente les caractéristiques des logiciels fournis aux entreprises. Article de La Rédaction avec IDG News Service SUR LE MÊME SUJET (COBOL) Forum Teratec 2014 : Le HPC mobilise en France et en Europe Atos a réussi son OPA sur Bull Forum Teratec 2014 : les serveurs HPC couplant ARM64 et K20 arrivent Watson tellement rapide qu'il répond aux questions pas encore posées Total choisit SuSE Linux pour son supercalculateur COMMENTAIRES DE L'ARTICLE22 le 24/07/2014 à 14h20 par Visiteur4374 : La vrai question n'est pas un problème de language, mais dans la capacité des équipes à répondre du point de vue architecture technique et fonctionnelle à des besoins métiers qui ont été exprimés et nécessaires aux développements des activités de l'entreprise.... Tout le reste ce n'est que des points de vue de personnes qui ont des intérêts divers Signaler un abus le 01/07/2014 à 14h43 par Arsene Lupin (Membre) : Comme beaucoup de commentateurs l'ont relevé, la question cruciale n'est pas celle du langage de programmation. D'abord, dire que "Cobol est plus sûr que Java" ne signifie absolument rien. Plus sûr de quel point de vue ? Le langage n'est qu'un outil: si les développements Cobol sont jugés généralement plus fiables que ceux réalisés en Java, c'est surtout parce que les premiers bénéficient de dizaines d'années de production, et qu'on hésite à y toucher. Forcément, à force de corriger des bugs sans rajouter de fonctionnalités... Quand à la performance... si Java est jugé moins performant que Cobol c'est surtout parce qu'il est interprété, mais que représente le temps d'interprétation pour un programme de gestion qui passe surtout du temps à attendre des I/O ? Le problème c'est surtout que les développeurs Cobol sont en voie de disparition: c'est pour cela que le patrimoine applicatif Cobol évolue peu, et c'est surtout pour ça qu'il faudrait le faire évoluer. Personnellement, je m'étonne que les DSI ne se lancent pas dans une réécriture progressive de leurs applications mainframe, en en profitant pour remplacer des applications 3270 monolithiques par des services aux interfaces bien définies. Et sans oublier de remplacer des sources Pacbase ou Cobol un peu figés dans leurs jus par des développement Java, Scala ou autre langages modernes, plus à même d'être maintenus par les nouvelles générations de développeurs. La fiabilité sera le résultat de la rigueur dans le développement et de la complétude des recettes. Signaler un abus le 30/06/2014 à 20h31 par Visiteur4298 : Combien de programmes COBOL ont été attaqués par des virus? 0, et JAVA des millions, pour une banque ça suffit pour rester COBOL. Signaler un abus le 14/09/2013 à 00h13 par Visiteur2804 : question performance, le c a fait ses preuves. Tous le logiciels embarqués, les DBMS, les OS. Question modularité, le c à fait ses preuves. Et c'est pas difficile de trouver des developpeurs C ! Signaler un abus le 17/07/2013 à 10h07 par Visiteur2454 : En fait, Java est tout à fait pertinent pour la construction de référentiel de donnée (type coeur de SI). Non, le vrai problème n'est pas le langage, ce sont les ressources. En effet, que faire d'une centaine de programmeurs Cobol à 5 ans de la retraite. On ne réapprend pas tout si proche de la fin. Finalement, les banques ne gardent pas le COBOL parce qu'il est plus performant mais surtout parce qu'il est là ! Le reste, ce ne sont que des guerres de religion... Pour infos, la NASA a éteint sont dernier mainframe il y a déjà un petit moment ! Signaler un abus le 15/07/2013 à 19h55 par Visiteur2439 : le cobol est un langage de developpement parmi des dizaines d'autres. Il possede ses avantages, inconvénients et limites comme les autres langages. Il est verbeux, solide, structuré, rapide, multiplateforme. Pour ce qu'il ne sait pas faire ou mal, on peut l'interfacer à d'autres langages, routines... Pour ce qui est du traitement des fichiers XML, le cobol n'a pas attendu son arrivée pour pouvoir traiter en entrée et sortie de simples fichiers ASCII que sont ces fichiers XML. Signaler un abus le 22/06/2013 à 15h49 par Visiteur2171 : Cet article traite fondamentalement de l'évolution de logiciels anciens dans un SI qui doit évoluer et n'apporte rien de nouveau que l'application de généralités au cas particulier de Cobol et des banques. Rien de nouveau à ce qu'un langage optimisé nativement pour les mainframes et l'accès au SGBDR soit plus performant qu'un langage généraliste fonctionnant dans une machine virtuelle. Rien de nouveau à ce que la modularité permette de faire un logiciel plus facile à corriger. Rien de nouveau à ce que la réécriture d'un logiciel de grande taille soit couteux. Rien de nouveau à ce que l'écriture d'un logiciel de grande taille soit toujours porteur d'une phase de stabilisation où il faudra intégrer les corrections et règles oubliées en spécifications. Phase d'autant plus importante que le domaine couvert est grand. Rien de nouveau à ce que la rétro-analyse de l'existant soit nécessaire lorsqu'il n'est plus maitrisé pour pouvoir le transposer de langage et le faire évoluer fonctionnellement. Je remercie Bill Curtis pour nous rappeler tout cela ainsi que l'aide que peut apporter une société dans laquelle il est impliqué (ce qui est bien normal). Je m'étonne toujours des réactions épidermiques dès que l'on aborde les langages de programmation. Et je m'excuse de ramener le débat à un ensemble de platitudes que le début du titre "les banques restent fidèles à Cobol" laissait entrevoir et je loue l'astuce de plume qui avec "Cobol, plus performant que Java" a su mettre du piment à la lecture de l'article. Signaler un abus le 21/06/2013 à 18h44 par Visiteur2169 : Le problème aujourd'hui c'est que la grande majorité des informaticiens développeurs ne programme pas correctement et le résultat c'est que les applications sont piratées à tour de bras, j'ai commencé en 1969 en cobol, le problème en programmation ce n'est pas de connaître le langage mais c'est apprendre la logique pour développer des projets et obtenir des résultats. Signaler un abus le 21/06/2013 à 11h58 par Visiteur2160 : L’effort aujourd’hui est mis sur l’agilité. Ce n'est pas une question d'informaticien, il faut savoir que ce mouvement est porté aussi (voir surtout) par les cabinets les grands cabinets de conseils anglo-saxons. En fait il y a deux enjeux financiers pour l’informatique ce qu'elle coûte et ce qu'elle rapporte. Ce qu’elle coûte c’est une affaire d’épicier ("ils sont vraiment très performants (les pgm Cobol)" se rapporte aux coûts ) mais l’agilité se rapporte au chiffre d’affaires et à sa préservation… C’est ce mouvement qui a conduit à soit des architectures de type SOA (du sol au plafond) soit des progiciels. A se tromper de bataille, on perd la guerre. Au fait combien d'entreprises du CAC sont "Cobol" Total, 200 M€ CA pas de cobol du SAP... Signaler un abus le 21/06/2013 à 09h35 par Ranafout (Membre) : @Visiteur 2144: COBOL n'est pas idéal pour les banques non plus. Sauf pour celles qui ont 20ans de retards et qui sont enclavée dans un marché national. Il y a de moins en moins de problèmes moderne pour lesquels cobol apporte une solution. Gestion des de code page multiple pour gérer les différents langages: Une banque international doit savoir traiter et restituer des noms et adresses correctement. C'est ingérable avec un langage qui travaille directement sur les zones mémoire. Les nouvelles interfaces d'échange sont basé sur XML. Ingérable en Cobol. etc... Dans tous les cas, l'utilisation d'un langage ou un autre n'a plus aucune importance aujourd'hui. L'architecture des services est la clé pour que le logiciel soit conçu par morceau interchangeable. Signaler un abus le 20/06/2013 à 19h44 par Visiteur2144 : @Visiteur2135 : "A part le graphisme, avec COBOL je peux tout faire à l'inverse d'autres langages. J'ai commencé en 1971 avec COBOL, j'ai connu d'autres langages, et je peux vous confirmer qu'il est le MEILLEUR" Hallucinant de croire qu'un informaticien est capable d'écrire ça... COBOL excelle sans conteste dans le type de problème pour lequel il a été conçu. Si COBOL était LE meilleur langage de tous les temps et pour tout faire, on l'utiliserait justement pour tout faire... Pourquoi croyez-vous que le C ait été créé ? Imaginez-vous par exemple UNIX écrit en COBOL ? Imaginez que tous les ingénieurs raisonnent comme vous venez de le faire... Imaginez un mécanicien dire qu'il a essayé les clés plates mais qu'il considère les clés à pipe comme les meilleures... L'ingénierie, dans le logiciel comme dans toute autre discipline, implique d'appliquer les bonnes solutions aux bons problèmes. COBOL est parfait pour les banques, son principal défaut est malheureusement le manque de développeurs COBOL qui s'accroit... Signaler un abus le 20/06/2013 à 18h15 par Visiteur2142 : Nous sommes en train de "chasser" les applications cobol de notre banque comme s'il s'agissait d'un virus.. me dire que cobol est sur oui c'est vrai.. mais c'est pas rapide à generer des ecrans, des rapports laser, des écrans graphique....des web services etc etc Signaler un abus le 20/06/2013 à 13h00 par yt75 (Membre) : La bêtise de l'informatique est surtout de croire que l'aspect langage (et format, syntaxe) est fondamental. Important certes bien sûr, mais ce qui fait marcher les choses cela reste beaucoup plus la mise en place d'espace d'identifiants ou codes partagés. cf "initiative iscn" Signaler un abus le 20/06/2013 à 12h40 par Visiteur2135 : A part le graphisme, avec COBOL je peux tout faire à l'inverse d'autres langages. J'ai commencé en 1971 avec COBOL, j'ai connu d'autres langages, et je peux vous confirmer qu'il est le MEILLEUR Signaler un abus le 20/06/2013 à 12h34 par Visiteur2134 : ouai enfin...... y a autre chose que Java, en info. surtout avec le volume d'infos et de traitements qu'il y a à faire, faut proscrire java des banques. de plus, avec la régularité des failles de la JVM c'est pas non plus indiqué Signaler un abus le 20/06/2013 à 11h13 par Visiteur2132 : Et oui, à ce tarif il y aura bientôt plus que du SAP (ou autre progiciel) dans les banques/assurances, mais ce type sera à la retraite à ce moment là, non! Le métier à plus besoin d'agilité que de performance, mais c'est vrai; amazone, google, facebook c'est que tu cobol sur mainframe .... Signaler un abus le 19/06/2013 à 14h27 par Visiteur2116 : "Ces programmes sont vieux, dépassés, et ceux qui les ont construits sont probablement morts" En effet, mort de rire. J'ai développé des systèmes de transaction et d'opérations pour une banque et je ne suis pas mort (46 ans) ! Signaler un abus le 19/06/2013 à 14h15 par Visiteur2114 : Il faudrait surtout que l'informatique sorte un peu de son syndrome paroxystique du cordonnier toujours le plus mal chaussé. gg "iscn initiative" Signaler un abus le 19/06/2013 à 13h44 par Visiteur2113 : Curtis, c'est pas le mec qui jouait dans "Les Mystères de l'Ouest" ??? Parce qu'à ce niveau de bêtise, il faut être un clown... Avc un sommet : "Ces programmes sont vieux, dépassés, et ceux qui les ont construits sont probablement morts" Morts de rire, je pense... Signaler un abus le 19/06/2013 à 13h40 par Visiteur2112 : Une vision juste pragmatique et réaliste. Signaler un abus le 19/06/2013 à 11h40 par Ranafout (Membre) : Il est rare de voir autant de bêtises dans un article! Aujourd'hui la technologie et le logiciel doit devenir interchangeable et non plus un investissement. Pensez en terme de réécriture ou donner de l'importance à tel ou tel langage est une hérésie. Signaler un abus le 19/06/2013 à 10h18 par Visiteur2108 : "Bill Curtis, actuellement directeur du CISQ, est l'un de ceux qui a piloté le modèle de développement CMM" Qui ONT piloté !