L'état consternant de l'informatique bancaire

Il est souvent difficile de comprendre l'état réel dans lequel se trouve l'informatique bancaire et peu de personnes, même en interne, réalisent l'étendue de son inadéquation avec les enjeux d'aujourd'hui. Une information apparemment anecdotique à propos de l'américaine KeyBank nous procure l'occasion d'apporter un éclairage sur le sujet.

Classé vingt-quatrième aux États-Unis, l'établissement, sans être géant, est de taille respectable, avec ses 1 200 agences et 18 000 employés au service d'une clientèle diversifiée de particuliers, d'entreprises, des plus petites au plus importantes, et d'investisseurs. L'objet de mon attention ici est la déclaration de son responsable de l'automatisation robotique des processus (RPA), qui veut renforcer son équipe cette année, pour atteindre 120 à 130 personnes – ce qui, au vu du marché de cette catégorie de produits, est probablement représentatif du secteur, au-delà du cas d'espèce.

Le principe de ces outils consiste à faciliter la création, le déploiement et l'exploitation de robots logiciels capables de simuler et reproduire les gestes et activités d'un être humain dans ses interactions avec une ou plusieurs applications. Ils sont de la sorte mis en œuvre pour prendre en charge, plus rapidement et plus efficacement, les tâches répétitives. Au fil de leur sophistication, notamment à travers l'introduction de facultés d'intelligence artificielle, ils appréhendent des fonctions de plus en plus élaborées.

Que nous apprend donc le niveau d'efforts que consacre KeyBank à ce genre d'approche ? En premier lieu, il renseigne sur la situation de ses opérations. Avec une douzaine d'équipes de 10 spécialistes chargés du développement et de l'exécution d'automates, on peut aisément supposer que le périmètre à couvrir comprend vraisemblablement plusieurs centaines de processus susceptibles d'optimisation, dans une mesure suffisante pour justifier une intervention relativement coûteuse.

En se projetant à l'échelle de l'organisation, on peut ainsi estimer que, pour l'essentiel, la banque, puisqu'elle doit recourir aux RPA afin d'éliminer les carences qui requièrent actuellement des traitements manuels, fonctionne sur la base d'une architecture en silos, découpée par applications plus ou moins indépendantes les unes des autres, sans alignement clair avec les processus en vigueur ni avec la manière dont les utilisateurs, collaborateurs et clients, exploitent ses services… c'est-à-dire obsolète.

Plus gênant encore, la solution adoptée expose directement KeyBank (et toutes les institutions financières qui suivent un chemin similaire) à la paralysie létale que j'évoquais autrefois sous un angle seulement théorique. Imaginez en effet le parc applicatif dans quelques années, après le passage des professionnels du RPA sur la plupart des processus et sur les logiciels qui les propulsent. Imaginez les dépendances qui auront été créées entre tous ces composants et avec le moteur de robotisation… Il sera impossible de remplacer quoi que ce soit sans craindre de voir l'édifice s'effondrer.

Étonnamment, les coupables d'une erreur si grossière et fondamentale sont fréquemment les mêmes qui vantent les vertus de l'agilité et de la flexibilité, qu'elles affirment sans sourciller introduire au cœur de leur modèle opérationnel. Or ces qualités, indispensables à la survie dans le monde « digital » contemporain, en constante évolution, nécessitant de s'adapter au mieux à chaque client individuel, sont absolument incompatibles avec une approche industrielle des RPA. Comment peut-on ne pas le voir immédiatement ?