Système informatique intégré ou Best-of-breed : les banques face à un choix crucial

Créé le

20.03.2018

-

Mis à jour le

03.04.2018

Dans la perspective de l'open banking, imaginer à terme un système d’information bancaire en « pétales de marguerite », éclaté entre divers web services et autres API, est une approche organisationnelle qui ne va pas sans certains risques opérationnels.

La révolution digitale touche de plus en plus le monde de la banque. Les acteurs historiques du secteur ne peuvent plus ignorer l’intrusion des « néobanques » dans leur pré carré : en 4 ans, le Compte Nickel a séduit plus de 800 000 clients français et le britannique Revolut, plus jeune encore, en revendique déjà 1,5 million, dont plus de 200 000 en France. Les Systèmes d’information (SI) bancaires doivent s’adapter à la fragmentation croissante de la chaîne de valeur, la question étant de savoir comment. Adopter un modèle « best of breed », autrement dit aller chercher brique par brique les meilleures solutions disponibles, peut sembler séduisant, à l’heure où d’innombrables FinTechs se lancent chacune sur un créneau très précis. La banque découvre la logique qui a prévalu avec l’essor du web : le fait de s’appuyer sur des tiers, de devenir partenaires d’acteurs hier concurrents, afin d’offrir une nouvelle offre à ses clients. Le SI des banques s’ouvre de plus en plus, pour faire de la co-innovation avec des acteurs de la FinTech ou, de manière plus contrainte, pour des logiques de conformité (par exemple, la directive DSP2, qui favorise les agrégateurs de comptes).

Le best of breed : séduisant mais pas sans danger

Mais imaginer un SI bancaire en « pétales de marguerite », éclaté entre divers web services et autres API, est une approche organisationnelle jusqu’au-boutiste qui ne va pas sans générer certains risques opérationnels. C’est d’abord l’évolutivité d’une telle solution qui est en question : comment conserver la cohérence de l’ensemble au fil des modifications réglementaires ou des nouveautés produits ? Que les mises à jour ne soient pas implémentées correctement à travers toutes les briques utilisées, et c’est le bon dénouement de certaines opérations qui sera remis en cause. Une décentralisation informatique trop poussée laisse aussi planer le risque de failles de sécurité potentiellement plus nombreuses. Prenons l’exemple de la réglementation RGPD : la banque reste responsable de ses données, y compris lorsqu’elle doit les fournir contre son gré à un agrégateur. Quelles sont les conséquences si la banque s’appuie sur des FinTechs certes innovantes mais pas nécessairement aussi expérimentées qu’elle en matière de sécurité ?

Il faut également se poser la question du coût total d’utilisation à long terme de telles solutions : non seulement la multiplicité des liens conduira à des coûts de maintenance plus élevés, mais des coûts additionnels peuvent surgir au fil du temps. L’externalisation déjà ancienne de la chaîne titres à des « usines » spécialisées sur le marché français est un exemple intéressant. Le bien-fondé de la démarche – une mutualisation des coûts – n’est pas en cause, mais les offres, très standardisées et émanant de prestataires bancaires plutôt que d’éditeurs de logiciels, ont peu évolué. On s’aperçoit ainsi que les banques clientes ont dû reconstruire en interne des applicatifs complémentaires (calcul de performance, gestion de portefeuille, etc.). À quel coût ?

L’intégration est source de plus de standardisation

Surtout, une organisation « best of breed » risque de se traduire par une perte d’automatisation et une moindre connaissance des processus complets. Dès qu’une opération n’est pas standard ou qu’il faudra l’annuler ou la modifier, la contrepassation manuelle prendra le dessus, avec un risque additionnel d’erreur humaine. Est-ce vraiment le sens de l’histoire ? L’ouverture des systèmes bancaires est une réalité, mais la question est de savoir où positionner le curseur. L’idée est sans doute de conserver une solution-cœur intégrée assez large, reposant sur un modèle de données solide, comprenant les opérations, les paiements, les titres et les crédits, autrement dit la partie où la standardisation est source d’économies. Elle permettra aussi de conserver l’intégration d’un processus métier : gérer un crédit, c’est gérer tous les événements de la vie administrative du crédit, les paiements qui y sont liés, le collatéral et son risque. Une telle solution peut être logée sur les systèmes de la banque ou confiée à un éditeur expert en mode SaaS ou BPaaS [1] , permettant de jouer la carte de la mutualisation et de bénéficier de ses innovations liées à son métier d’éditeur.

Services internes vs services orientés client

Les services « face clients » se prêtent beaucoup plus à l’ajout de solutions tierces. Ici, c’est la notion d’ergonomie et d’expérience client qui prime, au moment où il s’agit de procéder à une identification en ligne, de permettre une expérience de co-browsing (par exemple, Unblu) entre le conseiller et le client ou de réaliser une simulation. Cela ne signifie pas que le back-office soit imperméable à toute ouverture. L’épargne européenne est par exemple accessible, via une FinTech comme Raisin ou la comparaison des performances et du risque d’un portefeuille avec IBO.

Maximiser l’automatisation pour abaisser les coûts, tout en personnalisant de plus en plus la relation avec le client sont deux enjeux antagonistes pour la banque d’aujourd’hui. Un cerveau bien structuré et ouvert sur l’extérieur y répond sans doute mieux qu’un réseau neuronal pur.

 

1 Software as a Service ; Business Process as a Service.

À retrouver dans la revue
Revue Banque Nº819
Notes :
1 Software as a Service ; Business Process as a Service.