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.