De nombreuses institutions bancaires doivent renouveler leur architecture informatique, sous peine de ne plus être pris en charge sur format mobile.

En effet, les banques ont longtemps fonctionné avec le code informatique d’origine tombé aujourd’hui dans l’oubli car ce langage est maîtrisé par de moins en moins de personnes.

Les banques de détail avaient au départ des missions relativement simples : en se rendant dans sa banque on pouvait ouvrir un compte, sécuriser un placement ou encaisser des chèques, etc.

Aujourd’hui, la technologie et les besoins des consommateurs ayant évolué, c’est sur son smartphone qu’on doit pourvoir piloter toutes sortes d’opérations, le tout de façon sécurisée (et automatisée).

Une migration de tous les dangers

Dernièrement la banque TSB a tenté de migrer plus de 1,3 milliards de données clients et a connu un crash sans précèdent. Les clients se sont retrouvés dans l’incapacité d’accéder à leur compte en ligne (voire ont eu accès à des relevés qui n’étaient pas les leurs).

Il faut reconnaître que les migrations informatiques se font rarement sans accroc. Dans le domaine bancaire les systèmes d’information ont été construits il y a parfois 60 ans (à l’époque de l’apparition des langages Cobol et Fortran) et les mises à jour peuvent se révéler très compliquées.

Des anciens systèmes d’information centralisés

A l’époque où ont été développées ces infrastructures financières, tout partait d’ordinateurs centraux. Il faut pouvoir imaginer des gros systèmes d’exploitation confinés dans des pièces en surchauffe portant de doux noms tels que DEC VAX, IBM MVS ou Dexcom.

Ces systèmes d’information étaient très robustes, bâtis pour durer dans le temps. Cobol (COmmon Business-Oriented Language) était le langage de programmation commun à tout le système et fonctionnait parfaitement pour remplir les tâches nécessaires de l’époque.

Le COBOL représente une porte ouverte à un nombre importants de bugs
Non-enseigné et incompris, le Dark Code (ou Cobol) est-il sur le point de disparaître ?

Certains programmeurs appellent ce code historique du « dark code » car bon nombre d’ingénieurs de l’époque sont décédés ou sont à la retraite. Rajouté à cela, le Cobol n’est plus enseigné à l’école et de moins en moins de professionnels sont en capacité de le corriger, ou même de le comprendre.

Dans le cas de la banque TSB, il semble probable que le transfert de données s’est fait de façon compilée comme il est possible de le faire grâce au RPA (automatisation des processus robotiques).

Une simple incompatibilité ou incompréhension peut rapidement déclencher une cascade de bugs pouvant devenir catastrophique. N’étant pas en capacité de comprendre le Cobol, l’équipe technique a dû lancer le processus de transfert de données en croisant les doigts.

 

Pourquoi alors ne pas se débarrasser une fois pour toute du Cobol?

Ce langage, créé en 1959, est toujours utilisé, partout dans le monde. Ce qui signifie que des bugs provoqués par une équipe impuissante face à un code indéchiffrable pour eux, peuvent se reproduire régulièrement.

Lorsque le système d’information de la banque finlandaise Sampo Pakki a été intégré à celui de sa maison mère, la banque danoise Danske Bank, de nombreux dysfonctionnements, aux conséquences importantes, ont ainsi eu lieu.

Et pourtant, le Cobol est utilisé en Europe, aux États-Unis et en Asie.

Pourquoi ?

C’est un système fiable.

La raison de ce succès est la nature du code lui-même. Il est écrit dans un langage très structuré et facile à lire, éloigné du code rédigé par les machines ou de certains assemblages de code que l’on trouve communément aujourd’hui.

On doit le Cobol à Grace Hopper, une contre-amiral dans la US Navy. C’est elle qui a développé le premier langage informatique en anglais appelé FLOW-MATIC. Elle a ensuite mis sa patte dans l’élaboration du Cobol puis du Fortran. Le système bancaire actuel lui doit beaucoup.

Grace Hopper, conceptrice du premier compilateur et du langage COBOL

Grace Hopper, conceptrice du premier compilateur et du language Cobol en 1951

Les programmeurs habitués à des langages très concis comme le C n’aiment pas trop le Cobol qu’ils jugent trop bavard. Mais cette façon de détailler le code peut avoir des avantages.

En effet, le Cobol contient ses propres commentaires : on peut facilement reprendre un code écrit quarante ans plus tôt et comprendre ce que l’ingénieur a voulu faire.

Des millions de lignes de code

L’autre raison qui fait que les codes historiques sont encore en place est d’ordre économique. Les systèmes d’information bâtis sur des codes anciens représentent des centaines de millions de lignes de codes représentant des milliers d’heures de travail. Devant l’ampleur de la tâche, il est difficile de décider de tout détricoter simplement.

D’autant plus que les institutions bancaires sont très nerveuses à l’idée de ré-écrire leurs logiciels sans comprendre au préalable comment l’ancien a été construit. 

Les ordinateurs exécutent des instructions sans avoir conscience de la finalité et du contexte du processus. Suite au basculement vers une nouvelle plateforme informatique et aux problèmes d’incompatibilité entre logiciels qui en ont découlé, la banque d’épargne belge Argenta a ainsi connu une paralysie de ses services en ligne.

En réalité, le langage Cobol n’est en soit pas le problème. Ce qui pose difficulté c’est son intégration et son interaction avec des codes plus récents tels que Java.

Peut-être sera-t’il possible à terme de designer un nouveau langage informatique capable de communiquer avec tous les codes, même les plus anciens.

Mais pour cela, il faut d’abord comprendre les anciens codes informatiques.

Vers une renaissance des « vieux » codes

Certaines banques sont en train de repenser la formation proposée à leurs équipes informatique et envisagent sérieusement d’intégrer l’apprentissage du Cobol, du Fortran et d’autres langages oubliés afin d’améliorer le processus d’intégration du nouveau code avec les anciens langages informatiques.

Devant la pénurie d’experts en Cobol, de nombreuses initiatives voient en effet le jour pour former de nouveaux professionnels. La société Micro Focus a par exemple mis en place un programme de développement de l’enseignement du Cobol.

A terme, le Cobol devrait évoluer dans une version actualisée. Une communauté de programmeurs travaille sur la version GnuCOBOL.

Ce nouveau Cobol pourrait permettre d’être utilisé dans la Blockchain ou comme une clé de cryptage des données, à condition que les ingénieurs soient prêts à investir le temps nécessaire à son apprentissage.

Si le GnuCOBOL pouvait répondre aux besoins bancaires contemporains tout en permettant d’aider à une meilleure interaction entre les codes historiques et les codes récents, il pourrait connaître un grand succès !

Déposer un commentaire

Inscrivez-vous à notre newsletter