À 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…
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…
Bonjour,
RépondreSupprimerVous soulignez régulièrement l'impotence des banques à faire évoluer leur système d'information pour s'adapter au monde moderne et aux attentes des utilisateurs exigeants et impatients que nous sommes tous. C'est vrai, et ce sera vrai encore pour un bon moment.
La raison principale, me semble t'il, c'est que le cœur de métier de la banque est en train, et ce depuis plusieurs années, de devenir essentiellement informatique, et dans quelques années, il sera quasiment uniquement informatique (ah je sais que je vais froisser du monde, mais on verra bien qui aura raison...).
Quel chamboulement, l'informatique n'est encore considérée que comme un moyen dans les banques, et généralement sous-considéré ou mal-considéré !
Or, dans les dirigeants des grandes banques, on ne trouve aucun informaticien en haut de la pile. Comment peuvent-ils prendre de bonnes décisions ? Comment engager des changements en profondeur sur plusieurs années sans aucune expérience de ce qu'est un système un informatique forcément tentaculaire, gérant des millions de comptes, des tas de règles de conformité, des évolutions technologiques perpétuelles, et j'en passe. Et surtout comment comprendre ce qui motive les hommes qui le crée et le font marcher. Le grand vide !
Tout au mieux ces dirigeants se font aider de consultants qui eux mêmes sont rarement (très rarement voir jamais) des vrais informaticien de métier.
Dans ce contexte, Difficile de mener à bien une transformation.
Penser que c'est un problème d'agilité est à mon avis une erreur. L'agilité est très facile tant qu'il n'y a pas un historique de code phénoménal à gérer. Ainsi toutes les start-up sont agiles de facto. Mais lorsque la start-up devient grande société et se met à gérer un système informatique devenu très complexe en raison du nombre de cas à gérer, de l'explosion du nombre de clients, alors, l'agilité se réduit mécaniquement car les risques encourus en cas d'erreur se multiplient jusqu’à mettre l'entreprise en péril.
Demain, de nouvelles banques apparaitront, créés par développeurs tout simplement. Et comme toute grande boites numérique (de Google à facebook en passant par stripe, et prenez n'importe laquelle), le créateur est à la base un informaticien.
Car dans la banque, à la différence de l’industrie (Pétrole, transport, etc), il n'y a que du numérique à gérer, jamais un non informaticien le fera mieux qu'un informaticien.
C'est çà la pilule que la banque doit avaler...