L'informatique est un boulet pour les banques

À l'occasion de la publication ^[PDF] de ses résultats du troisième trimestre 2019, marqués par une perte conséquente, le groupe Nordea souligne plus particulièrement la contribution structurelle de son informatique à sa mauvaise performance. Une autre manière d'appréhender le besoin de changement dans ce domaine…
Les montants en jeu, présentés à la page 17 du rapport, sont impressionnants : au total, ce sont 735 millions d'euros de charges directement liées à l'IT qui sont provisionnés, répartis (dans des proportions non précisées) entre, d'une part, des projets interrompus ou des fonctions développées mais non utilisées et, d'autre part, la prise de conscience que la durée de vie d'une bonne partie des systèmes existants est en baisse, ce qui réduit d'autant leur valeur résiduelle et la réalisation des bénéfices qui en étaient attendus.
Ce que révèlent ces commentaires est une réalité dont la plupart des grandes banques voudraient nous faire croire, à travers leurs prétentions de transformation, qu'elles l'ont laissée derrière elles. Pourtant, les méthodes traditionnelles de création logicielle, à base de chantiers pharaoniques engloutissant des budgets colossaux et s'étalant sur plusieurs années, restent la norme, tout au plus décorées des apparences des approches modernes (en en réutilisant les artefacts, sans s'imprégner de leur sens profond).
Pour Nordea, un exemple nous est donné par son changement de cœur. Bien que, en apparence, le projet se déroule conformément aux plans, il n'en souffre certainement pas moins des défauts identifiés : entre son lancement en 2015 et aujourd'hui, plusieurs mois encore avant qu'il n'entre en production, la situation de la banque a évolué et ce qu'elle bâtit n'est plus tout à fait adapté à ses besoins, avec, probablement, des fonctions désormais inutiles et d'autres, non prévues, devenant indispensables.
Voilà le meilleur plaidoyer pour une véritable stratégie d'agilité dans la banque, qui ne devrait d'ailleurs par se limiter à son informatique. Dans un monde en mutation permanente, les nouvelles réalisations ne peuvent s'envisager que sous la forme d'une succession rapide d'étapes, chacune étant consacrée à la construction d'un composant plus ou moins autonome. Ainsi, les risques d'obsolescence (immédiate ou à court terme), à défaut d'être écartés, peuvent être circonscrits à un périmètre maîtrisable.
Cependant, la leçon est amère quand elle vient de Nordea, qui était justement pionnière, il y a une quinzaine d'années, dans la mise en place d'une architecture modulaire pour l'ensemble de ses systèmes. Les gourous contemporains des « micro-services » n'hésiteront pas à affirmer que ce sont les principes mis en œuvre à l'époque qui sont en cause (en sous-entendant que les leurs sont infiniment meilleurs). Ils ont tort : c'est plutôt la difficulté à maintenir une discipline rigoureuse dans la démarche qui l'a menée à l'effondrement. Et le même danger guette toujours les équipes informatiques.
Ainsi aboutit-on à un jeu de recommandations indissociables, seules susceptibles de garantir l'efficacité de la DSI : outre l'exigence d'agilité, qui concerne à la fois l'organisation de la production logicielle et les systèmes développés eux-mêmes (et qui ne souffre aucune superficialité), les mécanismes, les processus et la gouvernance mis en place pour maintenir le Système d'Information (modulaire, donc) sous contrôle, toujours cohérent et en ligne avec la stratégie de l'entreprise, sont au moins aussi critiques…