Quelqu'un veut-il embaucher un vieil homme qui connaît COBOL ?

Il y a sept ans, je citais le fait que 43 % du système financier mondial fonctionne avec un langage informatique que plus personne ne parle. Sept ans plus tard, PC Magazine (les PC existent-ils encore ?) reprenait ce thème avec le titre :

Le monde dépend d'un code vieux de 60 ans que personne ne connaît plus | PCMag

… et sous-titre :

Chaque jour, 3 000 milliards de dollars de transactions sont traitées par un langage de programmation vieux de 64 ans que presque personne ne connaît plus.

La chronique cite un rapport récent (2022) de l'International Journal of Advanced Research in Science, Communication and Technology (IJARSCT), qui affirme non seulement que 43 % de tous les systèmes bancaires utilisent encore COBOL, mais que 95 % de toutes les activités des guichets automatiques aux États-Unis, et 80 % de toutes les transactions par carte de crédit en personne sont gérées par de tels systèmes.

S’agit-il d’un point de défaillance potentiel critique qui est systémique dans le système… ou s’agit-il d’une infrastructure de base critique, fiable et sécurisée qui devrait rester intacte ?

Pour les innovateurs, ils détestent l’idée des mainframes, du vieux code, des systèmes existants et tout ce qui était antérieur à l’année dernière. Ils sont toujours tournés vers l’avenir, remplaçant l’ancien par le nouveau. Pour ceux qui sont réticents à prendre des risques, toute modification apportée aux systèmes de base crée un énorme potentiel d’échec. Les choses doivent donc rester les mêmes – maintenir le statu quo – dans la mesure du possible.

Il n’y a pas de bien ou de mal ici, sauf pour dire qu’il doit y avoir une convergence de vues. Les anciens systèmes créent autant de risques que les nouveaux. Si vous gérez les opérations de base mondiales du système financier sur un code que personne n’écrit ou ne comprend plus, cela représente un risque énorme. C'est pourquoi d'anciens programmeurs COBOL, retraités depuis des années, se présentent au siège de la banque au volant d'une Ferrari. Ils sont très bien payés pour entretenir les vieux trucs.

De même, si vous remplacez l’ancien code par du nouveau, cela crée des risques d’échec massifs, comme l’a appris la banque britannique TSB, mon exemple préféré d’échec de transformation informatique. La banque a mis à niveau ses systèmes informatiques en avril 2018 et n’a pas réussi à effectuer suffisamment de tests et d’analyses. Selon IT Pro, "cela a entraîné une perturbation importante des services bancaires du TSB dans les services bancaires en succursale, par téléphone, en ligne et mobiles. Toutes les succursales de la banque et une « partie importante » des 5,2 millions de clients de TSB ont été touchées. Il a fallu attendre décembre 2018 pour que les services de la banque reviennent à la normale… la conception, la construction et les tests de la plateforme par la banque… ont impliqué plus de 1 400 personnes et 70 fournisseurs. Cela a été décrit comme sans précédent et incroyablement compliqué… en février 2019, la banque a révélé que la catastrophe avait coûté 330 millions de livres sterling, dont 125 millions de livres sterling en indemnisation des clients, 122 millions de livres sterling pour le recrutement d'urgence, 49 millions de livres sterling en fraude et 49 millions de livres sterling en fraude. 33,5 millions de frais non perçus".

C’était avant les amendes réglementaires qui s’élevaient à près de 50 millions de livres sterling supplémentaires.

Ce débat est continu et constant : changer ou ne pas changer ? Prendre le risque ou éviter le risque ? L’évitement du risque crée-t-il le risque lui-même ?

C’est un débat qui se poursuivra jusqu’à ma mort. En attendant, si quelqu'un est intéressé, j'étais un très bon programmeur COBOL. Heureux d'y retourner et de me rafraîchir la mémoire, si cela me permet d'acheter une Ferrari.

Source - The Finanser