Alors que leur transformation « digitale » prend une dimension critique, nombre de banques prennent finalement conscience du handicap que constitue leur cœur de système informatique historique. Hélas, certaines, telles que la filiale coréenne de Standard Chartered, croient pouvoir évacuer le problème grâce à une approche superficielle.
La même promesse, totalement vaine, continue donc de séduire, depuis au moins 20 ans : il « suffirait » de déployer le produit magique de tel ou tel éditeur (ici il s'agit d'OpenLegacy) pour transmuter, à moindre frais et sans impact majeur sur l'existant, les vieilles applications monolithiques en services applicatifs unitaires, dorénavant exposés sous la forme d'API, adaptés aux architectures modernes. Et, depuis aussi longtemps, il faut brandir sans cesse les mêmes arguments afin d'abattre les illusions.
En effet, fondamentalement, plaquer des interfaces conformes à l'état de l'art contemporain sur des composants datant généralement de 30 ou 40 ans ne permet pas et ne permettra jamais de rajeunir ces derniers ni d'éliminer leurs défauts intrinsèques, liés à leur âge canonique. L'opération alchimique dont rêvent les DSI embarrassés par le fardeau de l'héritage (« legacy ») n'existe simplement pas et ceux qui prétendent le contraire omettent soigneusement de considérer les difficultés dans leur ensemble.
Ainsi, l'idée qu'il serait possible de convertir un logiciel des années 80 en une batterie de fonctions élémentaires composables à volonté (pour, par exemple, intégration dans une application mobile destinée aux clients) se heurte-t-elle à une série d'obstacles plus insurmontables les uns que les autres. Le premier est structurel : la conception d'origine, pour des usages figés, en agence et dans les back-offices, ne fournit pas la modularité nécessaire et doit être dangereusement dénaturée pour, a minima, la simuler.
Ensuite, surgit l'inévitable question de la temporalité. La banque d'autrefois opérait et opère toujours dans un mode asynchrone, par l'intermédiaire de traitements quotidiens par lots. Or que vaudrait, en 2021, une entreprise prétendument « digitale » incapable de fonctionner à 100% en temps réel ? Là encore, la seule solution envisageable consistera en artifices techniques, introduisant un décalage entre la perception des utilisateurs et la situation reflétée dans les systèmes, ce qui n'est évidemment pas sans risques.
Autre sujet d'inquiétude sensible : la performance. Les usages numériques ont radicalement changé en quelques décennies et les anciens composants n'ont jamais été prévus pour supporter les niveaux de sollicitation aujourd'hui habituels, engendrés par exemple par les accès directs des clients. Quand bien même ils pourraient s'accommoder de la charge, le surcroît de puissance informatique requis entraînerait des coûts inacceptables, d'autant qu'il porte sur des infrastructures onéreuses (« mainframes »).
Je passerai rapidement sur les enjeux de sécurité soulevés par une ouverture, certes réduite mais factuelle, d'une partie normalement « enfouie » du système d'information. Au bout du compte, il faut revenir à la raison : les outils de pseudo-modernisation du cœur bancaire ne doivent être adoptés qu'avec la plus grande prudence, pour des besoins tactiques et précisément circonscrits. Quant à la vraie transformation « digitale », elle ne pourra pas faire l'économie d'une remise à plat complète des fondations.
Aucun commentaire:
Enregistrer un commentaire
Afin de lutter contre le spam, les commentaires ne sont ouverts qu'aux personnes identifiées et sont soumis à modération (je suis sincèrement désolé pour le désagrément causé…)