Un autre volet de la modernisation informatique

On sait – même si nombre de responsables refusent d'affronter la réalité en face – combien l'informatique bancaire est handicapée par des composants obsolètes. En revanche, on pense moins souvent à une autre dimension dans laquelle l'héritage du passé impose ses contraintes inacceptables au XXI^ème siècle : les pratiques en vigueur dans les DSI des institutions financières traditionnelles.

Prenons l'exemple, anecdotique mais ô combien révélateur, de cette annonce de Lloyds Bank informant ses clients que, en raison d'une évolution apportée à ses systèmes, ils ne pourront réaliser aucun virement durant les petites heures du samedi 19 octobre. Certes, la population impactée par cette interruption de service est probablement très limitée, le choix du créneau correspondant vraisemblablement à une période d'usage habituel minimal et sa durée étant raisonnable (si tout se déroule comme prévu).

Cette pratique n'en est pour autant plus admissible pour une génération d'individus désormais accoutumée à une accessibilité permanente de leurs outils du quotidien. Il n'est pas seulement question de celles et ceux qui, peut-être de l'autre côté de la planète, auraient besoin d'exécuter un transfert d'urgence au milieu de la nuit, d'autant plus frustrés s'ils n'ont pas vu passer l'alerte. La seule publication de l'événement constitue aussi pour tous un rappel du retard technologique de l'établissement.

Et qu'est-ce qui justifie de suspendre de la sorte une fonction à l'occasion d'une mise à jour logicielle ? Dans bien des cas, le coupable est une conception ancienne des applications n'autorisant pas les remplacements « à chaud ». Mais il existe aussi un facteur comportemental, un réflexe qui conduit à perpétuer des usages qui n'ont plus de raison d'être. On peut soupçonner celui-ci d'être à l'œuvre ici puisque la modification portait sur la plate-forme de « faster payments », par nature relativement récente.

Quoi qu'il en soit, quelque part dans la chaîne de décision, quelqu'un a confirmé qu'il n'était pas très grave d'interrompre un service, pourtant critique, pendant quelques heures, soit que ses subordonnés ait affirmé qu'il n'y avait pas d'autre option, soit parce que c'est la méthode qui a toujours été employée. Dans cet état d'esprit, rien ne sera jamais fait en vue d'envisager une autre manière de faire… comme celle que montrent tous les jours les startups de la FinTech (et d'autres secteurs, incidemment).

Il faudrait encore noter que ces travaux de nuit représentent un risque pour le système d'information : outre la nécessité de faire intervenir des collaborateurs en dehors des heures normales de travail, dans l'hypothèse d'un incident imprévu, les experts requis pour le diagnostiquer et le traiter ne seront peut-être pas disponibles et un petit problème peut alors rapidement déboucher sur une catastrophe. Les mécanismes de déploiement transparents, par palier, sont aujourd'hui la norme et ils assurent à la fois une expérience optimale pour les clients et une meilleure réponse quand survient une anomalie.