RBS rafistole ses systèmes informatiques

La semaine passée, RBS a conclu un accord avec les autorités financières britanniques aux termes duquel elle paiera un total de 56 M£ d'amendes (en plus de celle de 3,5 M£ infligée en Irlande) dans le cadre de l'incident informatique majeur qui, à l'été 2012, a privé ses millions de clients de tout accès à leur argent pendant plusieurs jours.
Après les effets désastreux de cette affaire sur l'image de la banque et les plus de 70 M£ versés aux clients (et à quelques non clients), en compensation des désagréments qu'ils ont subis, la facture continue donc toujours à s'alourdir… Mais, s'il faut en croire le rapport ^[PDF] que vient de publier l'établissement, ces montants ne sont, en réalité, qu'une goutte d'eau en comparaison des efforts consentis pour tenter de remettre à flot ses systèmes informatiques vieillissants.
Ce sont ainsi 750 M£ qui sont investis sur 3 ans, uniquement pour garantir la sécurité et la résilience des infrastructures et applications existantes et minimiser le risque qu'une catastrophe du même ordre que celle de 2012 n'ait un impact aussi dramatique sur les clients. Et le détail de quelques grands chantiers engagés – au-delà de l'amélioration et de la rationalisation des services, dont notamment les paiements internationaux et les accès mobiles – montre à quel point la situation est désespérée…
Il y a tout d'abord la mise en place d'une « banque miroir ». Derrière ce concept se cache une idée simple : une copie à l'identique des principaux composants informatiques – traitements des transactions par carte, consultation des soldes de compte et des dernières opérations… – est mise en œuvre et maintenue en permanence, capable de prendre rapidement le relais en cas d'indisponibilité des systèmes primaires. Dans une reconnaissance pathétique de son incapacité à assurer une fiabilité satisfaisante, RBS surenchérit donc dans la complexité.

Deuxième axe prioritaire des initiatives engagées, la banque vise à simplifier ses traitements « batch » (c'est-à-dire toutes ces opérations qui sont enregistrées et mises en attente au fur et à mesure de leur arrivée et sont exécutés par lots, généralement la nuit, pour plus d'efficacité). A une ère où le monde fonctionne de plus en plus en temps réel (y compris les paiements, au Royaume-Uni), il est particulièrement triste qu'une entreprise en soit encore à tenter de rendre plus fiables ses systèmes datant d'une époque révolue.
Pourtant, le plus grave n'est pas directement dans ces chantiers, dont il est difficile de contester qu'ils sont hélas indispensables. Ce qui met réellement en danger l'avenir de RBS – tout aussi inévitablement – est la diversion créée : non seulement les efforts et les investissements consentis pour la résilience sont détournés des projets de rénovation qui auraient du être entrepris depuis longtemps mais ils constitueront aussi des facteurs de paralysie lorsqu'il faudra envisager le remplacement des systèmes en place (pas question de « jeter » ce qui vient de coûter des millions !).
Il serait facile, de la part des autres banques historiques, de rejeter les causes de cette descente aux enfers sur les erreurs passées de RBS, dont, en particulier, la réduction de ses budgets informatiques dans le sillage de la crise financière de 2008. Ce serait cependant une erreur car elles sont (presque) toutes dans une situation identique, même si l'absence d'incident d'ampleur ne permet pas d'en prendre une totale mesure. Les « rafistolages » des vieux systèmes y sont la norme, tandis que les modernisations vitales y prennent un retard inquiétant…