smart solutions for smarter enterprises

Open Banking : 3 clefs pour réussir l’ouverture du SI bancaire

Par Djeme MAHAMAT, architecte Innovation & Industrialisation chez Sentelis. Avec la collaboration de Yasser Rougi, Mathieu Dutertre, Laurent Baumard et Jérôme Besson.

La nouvelle directive européenne sur les services de paiement (DSP2) est entrée en vigueur en janvier dernier. Elle a été voulue par le législateur pour stimuler la concurrence en favorisant la création de services bancaires à forte valeur ajoutée pour les clients par des acteurs autres que les acteurs historiques du secteur. DSP2 pousse les banques traditionnelles à s’ouvrir plus que jamais à leur écosystème, ce qui pourrait transformer profondément leur positionnement actuel en les muant en fournisseur de services bancaires pour des acteurs tiers tels que des FinTechs.

DSP2 pose un cadre législatif pour trois grands cas d’usages : l’agrégation de comptes bancaires, l’initiation de paiement et la fourniture de carte de paiement. L’agrégation de comptes bancaires donne la possibilité aux fournisseurs de services de paiement accrédités de connecter plusieurs comptes via API (Application Programming Interface) afin d’offrir une vision consolidée ou une nouvelle expérience utilisateur aux clients. Les fournisseurs de service de paiement pourront également accéder aux informations de virement des clients ou initier des virements depuis le compte des clients. Il sera aussi possible pour les acteurs de paiement d’interroger les banques de leurs clients pour savoir si ces derniers possèdent suffisamment de fonds dans le cadre d’une transaction.

Pour tirer parti de cette règlementation plutôt que de la subir, le système d’information des banques traditionnelles doit évoluer d’un système centré sur les applications vers un système centré sur les APIs. Autrement dit d’entreprise-centric à écosystème-centric. Les trois clefs essentielles pour réussir cette transformation et pour faire de l’ouverture de son SI bancaire un vecteur d’opportunités sont :

  • La mise en place des capacités technologiques pour motoriser la création et la mise sous-contrôle des APIs,
  • La mise en place d’une gouvernance API décentralisée qui favorise l’agilité et l’autonomie des équipes projets,
  • La mise en place d’un modèle de sécurité où le client est maitre de l’utilisation de ses données.

Clé n°1 : Des capacités technologiques qui mettent sous contrôle les APIs de l’entreprise

Le premier pas à faire pour « APIser » son SI est de mettre en place les capacités technologiques pour motoriser les APIs à l’échelle du système d’information. Différentes gammes de solutions sont nécessaires :

  • Une solution « API Management » pour mettre sous contrôle l’ensemble des APIs de l’entreprise,
  • Des « Frameworks Microservices » pour fabriquer des APIs ressources performantes et évolutives au niveau des systèmes existants (e.g. legacies/back-ends, référentiels) et émergents (e.g. data lake) ou encapsuler des services existants (e.g. services SOAP/XML),
  • Le « Cloud » pour garantir un haut niveau de services et maitriser les coûts d’exploitation face à l’explosion exponentielle potentielle des usages.

#Solution « API Management » pour mettre sous contrôle l’ensemble des APIs de la banque

Les solutions « API Management » permettent de gérer de façon industrielle le cycle de vie de l’API de leur production à leur consommation : accostage avec les systèmes fournisseurs d’APIs ressources (services JSON/REST), documentation et publication des API « as-a-product », gestion de quotas (e.g. limitation de trafic), gestion des souscriptions, analyse des usages et modèles économiques en cas de monétisation.

La bonne nouvelle est que la plupart des solutions éditeurs du marché sont assez matures sur les fonctions de gestion d’API. Mieux, certaines couvrent parfois d’autres périmètres fonctionnels tels que la fabrication des API ressources, la gestion des habilitations ou l’intégration inter-applicative.

Pour autant, une bonne stratégie d’implémentation consiste à s’appuyer sur un produit mature du marché en l’utilisant uniquement pour gérer le cycle de vie des façades API exposées aux consommateurs internes et externes ; en le complétant par des outils spécialisés pour gérer la fabrication des API ressources et la sécurité, voire en transition l’alignement technique et/ou fonctionnel avec des services existants, pour peu que ces derniers soient alignés avec la finalité de l’API souhaitée. A noter que pour les entreprises déjà dotées d’une plateforme d’intégration type ESB, il existe généralement des adapteurs protocolaires (XML/SOAP vers JSON/REST) qui permettent de valoriser les services existants dès lors que leurs signatures sont conformes avec le design de l’API façade souhaité.

#Framework Microservices pour fabriquer des backends API

L’architecture Microservices permet de construire des systèmes logiciels modulaires, robustes et évolutifs. Cela semble adapté pour créer des API ressources de zéro ou par adaptation d’un système monolithique existant comme le Mainframe. Les Framework Microservices outillent ce paradigme et offrent des piles logicielles complètes pour développer et opérer des applications existantes, notamment les back-end cœur de métier, sous forme de microservices.

#Le cloud pour garantir les SLAs et maîtriser les coûts d’usage
Pour supporter les solutions logicielles citées plus haut (gestion des APIs et fabrication des API ressources/microservices), il faut également disposer d’une plateforme d’exécution élastique et hautement scalable. Cette plateforme doit être hybride, c’est-à-dire qu’elle doit pouvoir distribuer et exécuter les différents composants logiciels (e.g. API gateway) sur des data centers privés mais aussi dans des Cloud publics (e.g. Amazon Web Services, Microsoft Azure, Google Cloud). Pour cela les produits éditeurs à utiliser et les développements spécifiques à réaliser doivent être conteneurisables et respecter les exigences des applications « Cloud Native ».

Clé n°2 : Une gouvernance API décentralisée pour favoriser l’agilité et l’autonomisation des équipes projets

APiser le SI bancaire pour délivrer la « Bank-As-A-Service » et au-delà la « Bank-As-A-Platform » passe aussi par la mise en place d’un cadre de fonctionnement qui favorise l’agilité et l’autonomisation des équipes projets (producteurs d’API ressources et consommateurs d’API façades). Pour ce faire, il faut que le développement et la gestion des APIs (ressources & façades) soient décentralisés au sein des projets ; et la construction et la gestion du socle technologique sous-jacent pour supporter ces APIs soit à contrario centralisée au sein d’une équipe transverse, opérateur de la plateforme API.
La Plateforme API doit s’articuler autour de 3 piliers :

  • Un socle technologique pensé comme une plateforme d’entreprise,
  • Une gouvernance collaborative (socle API & APIs),
  • Un support opérationnel réactif et de proximité avec les équipes projets.

# Un socle technologique API pensé dans une logique de « Plateforme Entreprise »

Dans les modèles de gestion des socles d’intégration traditionnels comme l’Entreprise Service Bus, tous les développements et l’exploitation des médiations de l’entreprise sont classiquement gérés par une seule équipe centralisée, type « Integration Factory » où « Integration Shared Services Center». Un type de modèle clairement inadapté pour l’API car il est impossible pour une seule équipe de gérer un nombre exponentiel d’APIs sur tous les périmètres métier de l’organisation. Une approche pragmatique consiste à penser et gouverner son socle technologique API, non plus justement comme un socle, mais comme une plateforme d’entreprise c’est-à-dire :

  • inspirée des architectures et modes de fonctionnement des plateformes numériques, donc offrant : une forte autonomie à ses utilisateurs finaux (équipe projet agile/squad, micro-factory…), une minimisation de l’effort d’usage (logique No Code/Low Code, automatisation DevOps) en particulier via une « self-service experience » avancée et des mécanismes de contrôle automatisés de son utilisation (respects des règles d’usage),
  • conçue pour supporter plusieurs typologies d’usages : production d’API privées en interne et à l’externe du SI ; production d’API pour des partenaires avec des niveaux de confiance variés ; production d’API pour le grand public et l’écosystème ouvert (Open API) ; consommation d’API tierces,
  • proposée aux projets comme un service géré : les projets sont autonomes et responsables des usages qu’ils réalisent sur la plateforme, et une équipe transverse est responsable de la délivrance et du maintien du socle API sous-jacent.

#Une gouvernance collaborative (socle API & APIs)

L’identification des services à offrir par le socle, leur priorisation et leur activation doivent être calés sur le portefeuille des usages en visibilité pour les servir de façon efficace et efficiente. Ce cadrage des besoins utilisateurs et de l’expérience qu’ils souhaitent vivre avec le socle API est fondamental :

  • dans la définition du cadre de gouvernance et d’architecture API (Règles & responsabilités métier/IT sur la chaine de valeur API, documentation, politiques de monétisation, …, normes & standards à respecter, sémantique applicable, méthode de conception recommandée selon la finalité de l’API, etc.),
  • dans les choix IT à opérer, que ces derniers s’orientent vers une solution d’API « on-premise » minimaliste ou « off-premise » dans le Cloud offrant toutes les fonctions à l’état de l’art « out-of-the box », en mode self-service, « Low code/no Code » et « Managed Services ».

La gouvernance ne doit pas être IT-Centric, mais équilibrée entre les exigences réglementaires PSD2, et éclairée au-delà par la stratégie métier en matière d’API économie, de « Bank-As-A-Service » (accès à l’ensemble des ressources de la banque via des APIs) et de « Bank-As-A-Platform » (fédération, portage, commercialisation et monétisation de ressources développées par tiers – APIs & Apps enrichissant la proposition de valeur de la Banque). Elle doit de fait être collaborative entre l’ensemble des parties prenantes métiers (Risques & Conformités, Relation Client, Vente & Marketing), IT (Etude & Développement, Sécurité, Production & Réseau), Métier/IT (e.g. Chief Data Officer) et tierce partie (Partenaire, développeur, complémenteur).

# Un support opérationnel réactif et de proximité avec les équipes projets

La décentralisation des développements et la de gestion des APIs au sein des équipes projets/produits agiles nécessitent d’une part des efforts importants d’alignement entre les différentes APIs produites au sein de la banque, et d’autre part avec les standards API de l’écosystème (ex : standard Open API « STET PSD2 ») : c’est l’une des principales missions de l’API Gouvernance Office.
L’API Gouvernance Office (API G.O) est une instance transverse à l’entreprise, à cheval entre l’IT et les métiers, dont le rôle est de superviser et de réguler les usages API (privés à la banque mais aussi les API DSP2). L’API G.O doit être un facilitateur, un support pour les projets API dans leur tâches quotidiennes, l’API G.O assiste les projets dans les arbitrages, la conception et le développement des APIs. Il est également le garant :

  • Du maintien du cadre syntaxique et sémantique des APIs de la banque ;
  • Du catalogue des API ressources, API usages et API produits ;
  • De la feuille de route des APIs ;
  • De la sociabilisation et l’animation des communautés API internes et externes.

Pour aller plus loin sur « Comment mettre en place une API Gouvernance Office », consulter l’article « API à l’échelle » sur notre blog : http://www.sentelis.com/sentelab/lapi-a-lechelle/

Clé n°3 : Un modèle de sécurité où le client est maître de l’utilisation de ses données

Le troisième point à traiter, – et non le moindre – pour préparer sereinement l’ouverture de son SI bancaire, est la sécurité. Cette ouverture va augmenter de façon significative le nombre d’acteurs directs ou indirects avec lesquels la banque interagit. Ce qui a pour effet de pousser les banques à :

  • gérer finement les droits d’accès à leur données et services ;
  • être transparente sur la façon dont les données de leurs clients sont utilisées au sein des applications internes ou dans les applications des partenaires (Startups, agrégateurs, filiales, etc.) ;

#Gérer finement le contrôle d’accès et les habilitations des données et services bancaires

Avec DSP2, de plus en plus d’acteurs tiers proposeront aux clients de la banque des applications basées sur leurs données et avec leurs consentements. Les banques doivent donc habiliter de manière fine les consommateurs qu’ils soient internes ou externes : cette habilitation doit se faire au niveau « fonction » plutôt qu’on niveau « application ».
Les standards techniques tels que « OpenID Connect » et « OAuth2 » se sont imposés aujourd’hui pour le contrôle d’accès fins aux APIs, cependant, à eux seuls, ils sont insuffisants, il faut :

  • homogénéiser à l’échelle du SI la définition des habilitations fines sur les assets,
  • outiller les mécanismes de contrôle d’accès aux APIs et applications backends, notamment en complétant la plateforme API Management par des solutions complémentaires d’authentification et d’autorisation des APIs et microservices.

#Etre transparent vis-à-vis des clients, leur donner le contrôle sur leurs données

Dans une ère marquée par de multiples scandales sur le détournement de l’utilisation des données personnelles comme celui de « Facebook et Cambridge Analytica » mais également par l’entrée en vigueur de la directive européenne sur les données personnelles « GDPR », il parait difficile d’ouvrir son SI à l’écosystème sans être transparent vis-à-vis des clients sur l’utilisation de leurs données par la banque mais aussi par les tiers utilisant les APIs de la banque. Pour ce faire, les banques doivent mettre à disposition des clients, des services leur permettant de consulter et récupérer à tout moment, l’ensemble de leurs données dont la banque dispose ; de lister et révoquer à tout moment, les délégations d’autorisation accordées aux applications tierces pour agir en leur nom auprès des services et données exposés de la banque ; et de tracer et suivre l’ensemble des activités effectuées par les applications tierces pour le compte des clients.

Conclusion

La directive DSP2, au-delà de l’exigence réglementaire d’ouverture du SI bancaire sur un certain nombre de ses services financiers, est l’opportunité de se professionnaliser sur l’API, tant en termes de plateforme technologique que de gouvernance et d’amorcer le virage vers la « Bank-As-A-Service » et au-delà vers la « Bank-As-A-Platform ». Loin d’être une contrainte, c’est l’opportunité d’engager une nouvelle conversation, prémisse d’une collaboration gagnante-gagnante avec son écosystème. Qui plus est, traiter cette réglementation de façon tactique est une vue court-termiste, une réglementation pouvant toujours en cacher une autre, et au-delà c’est se priver d’une nouvelle source potentielle de revenu qu’offre l’API économie.

Laisser une réponse

*