Concernant les banques traditionnelles, les SI ont été construits dans les années 1980 sur un modèle de traitement en batchs transactionnels fonctionnant la nuit lorsque les machines sont inoccupées. Ceci permettait des économies de puissance machine. Cela signifie que les achats effectués, les prélèvements et virements reçus dans la journée ne sont visibles sur le compte du client que le lendemain matin. Tous les nombreux développements réalisés depuis lors sont venus se superposer à cette structure initiale. Ceux-ci ont dû être codés en langage ancien, compatible avec le cœur. Logiquement, cela rend la modernisation des fondations du SI quasi impossibles, étant donné tous les étages construits successivement au-dessus d’elles. Par ailleurs, le langage informatique utilisé représente une contrainte de maîtrise car les ressources qui arrivent sur le marché n’apprennent plus le langage Cobol et certaines banques sont contraintes de rappeler des retraités pour comprendre certaines chaînes.
C’est bien le problème car la demande du consommateur réside aujourd’hui dans l’instantanéité : la volonté d’accéder au contenu de Netflix dès l’instant qu’on a souscrit, les efforts immenses déployés par Amazon pour le livrer en un jour ouvré… Si les banques ont su répondre à ses attentes, par exemple avec l’instant payment, ces développements sont réalisés dans une architecture SI qui ne les facilite pas. En effet, le core n’étant pas conçu pour le temps réel, le développement est rendu plus long, plus complexe et plus coûteux. D’autre part, les SI anciens n’étaient pas construits en briques mais d’un seul tenant, ce qui implique qu’une modification dans le code nécessite de vérifier la cohérence de l’ensemble.
À l’inverse, les SI plus récents sont conçus pour agréger des API permettant de construire de nouvelles briques aisément et d’en faire évoluer d’autres, sans remettre en cause l’intégrité de l’ensemble. Par ailleurs, ils sont construits pour le temps réel. Cela permet l’instant payment mais aussi d’avoir un suivi des opérations en temps réel offrant ainsi une valeur ajoutée pour le client, mais également pour la banque (notamment dans la prévention des incidents).
L’agilité et la maîtrise du SI
Dès les années 1990, les impératifs économiques ont poussé les institutions bancaires à filialiser une partie de leurs systèmes d’information. L’IT était considéré comme une simple fonction support dont les coûts devaient être contenus, d’où la mutualisation. Nous ne nous étendrons pas sur les modalités de cette filialisation, que nous avons développées dans notre article « Remettre le SI au cœur de la banque » publié en octobre 2018
Nous avons parfois expérimenté des aberrations au cours des projets menés avec des banques : une attente de 2 ans pour un changement de paramétrage du SI, un coût de 200 k€ pour une extraction de données. En effet, la banque et sa filiale ou son prestataire extérieur se retrouvent en situation de codépendance en dehors de toute logique de marché, tout en ayant perdu l’aspect collaboratif nécessaire pour fonctionner efficacement. Arkéa faisait exception par sa capacité à fournir des prestations bancaires en marque blanche.
L’agilité est la grande victime de ce mode de fonctionnement puisque les projets de développement sont contraints par, à la fois, un ordre de réalisation, des budgets élevés et des délais de livraison qui ne permettent plus de suivre les attentes des clients. Les développements réglementaires restant prioritaires, le temps disponible pour les développements marketing notamment est très réduit.
Malgré tout, il y a un besoin d’agilité évident imposé par des réglementations dont les délais sont très courts et selon des modalités qui ne sont pas toujours compatibles avec les capacités des SI.
Les néobanques
Même s’il est déraisonnable de mettre sur le même plan les contraintes des néobanques et celles des banques traditionnelles, tant leurs contraintes divergent en termes de périmètre de services proposés (avec les réglementations afférentes), de nombre de clients et des volumes de flux, force est de constater que leur création récente a permis à certaines de construire un SI sur des fondations modernes qui dénotent en termes d’agilité. Les SI plus récents ont été conçus dans l’esprit des dernières réglementations (notamment DSP2), et ils admettent par construction l’ajout d’API. Leur structure par briques indépendantes permet d’intégrer les évolutions réglementaires plus simplement puisque les modifications sur une brique n’impactent pas le SI tout entier.
Pour schématiser à l’extrême, il est plus aisé de mettre une maison moderne aux normes environnementales qu’un château médiéval.
Quel avenir pour les SI anciens ?
Pour reprendre la théorie comportementaliste de Joule et Beauvois dans leur best-seller « Petit traité de manipulation à l'usage des honnêtes gens »
Malgré tout, force est de constater que les banques ont montré leurs capacités, en dépit de l’architecture de leurs SI, à développer des services en temps réel comme l’instant payment, déjà évoqué. Elles suivent une stratégie de rénovation par pan du SI qui produit des premiers résultats en termes d’amélioration du time-to-market. Reste que le cœur risque de demeurer ancien et difficile à rénover sans interruption de service majeure. C’est pour cela que Germain Michou-Tonning (voir Encadré) prévoit plutôt des rachats de nouveaux SI, notamment ceux de néobanques qui sont déjà fonctionnels.
Mais au-delà du SI lui-même, c’est aussi l’organisation de l’IT qui est à revoir. En effet, la digitalisation renforcée par le confinement donne à l’IT une place au cœur du métier de banquier puisqu’elle est à l’interface de la majorité des contacts avec le client. Or la filialisation a repoussé l’IT hors de la banque même si elle reste dans le groupe. Pour faire une analogie avec l’automobile, les chaînes de montage sont parfois partagées par plusieurs marques, toutefois personne ne les a encore sous-traitées entièrement.
