Quels sont, selon vous, les principaux enjeux à prendre en compte dans le développement des API qui permettront d’accéder aux comptes des clients et d’initier des virements, dans le cadre de la DSP 2 ?
Les
Les standards techniques réglementaires de la DSP 2 laissent ouverte la possibilité pour une banque de proposer aux agrégateurs la solution de l’« accès direct » via l’espace de banque en ligne du client, sorte de « web scraping avec authentification ». Pourquoi préférer le recours à une API ?
Indépendamment de l’aspect réglementaire, l’API est un standard reconnu et utilisé par tous sur internet. Dans une logique d’open banking plus large – la DSP 2 n’en est qu’une des facettes –, elle permet d’être plus facilement interopérable avec les acteurs externes. Par ailleurs, nous utilisons déjà beaucoup les API en interne, pour faire évoluer nos propres SI et les rendre plus agiles. Les services de l’application mobile des clients font par exemple intervenir des API. Nous avons plusieurs centaines de ces API internes, appelées quelques millions de fois par jour. Nous disposons donc déjà de compétences fortes sur le sujet. Le choix de l’API pour communiquer avec des tiers extérieurs à la banque nous a semblé la solution naturelle.
Comment définiriez-vous une API lorsqu’elle est utilisée en interne ?
Une API permet un accès simple et unique aux fonctionnalités du SI. Historiquement, chaque application dispose d’une interface d’accès à ses fonctionnalités. Avec l’API, cet accès est unique et standard, qu’il passe par le canal de l’espace du client, ou par celui du conseiller…
Allez-vous mettre en place une solution d’accès direct en plus de l’API ?
L’accès direct existe déjà puisque les agrégateurs font aujourd’hui appel à la technique du web scraping pour accéder directement à l’information. On ne l’interdira pas en solution de repli. Mais la solution de l’API sera nécessairement beaucoup plus fiable, sécurisée et performante. C’est elle qui a été choisie au niveau français.
Le périmètre de la DSP 2 s’arrête aux comptes de paiement. Que se passe-t-il sur les autres comptes, comme ceux d’épargne ? Pourrait-on étendre l’API ?
La DSP 2 standardise les API uniquement sur l’accès aux comptes de paiement. Sur le reste du périmètre, le web scraping continuera. À chaque établissement de décider, ensuite, s’il souhaite ouvrir des API aux autres données.
Est-ce faisable techniquement sur le portail que vous êtes en train de mettre en place ?
Il n’y a aucune difficulté en termes de faisabilité technique. Mais ce sera à chaque enseigne de décider si cette ouverture entre dans sa vision stratégique.
En tant qu’agrégateur, vous allez devoir utiliser les API d’autres banques, voire d’autres standards d’API existant en Europe. Est-ce une difficulté ?
L’adaptation aux API des autres banques françaises se fera sans surprise, car elles répondront au même standard. Mais même si elles différaient de ce standard, elles resteraient plus simples à utiliser que le recours au web scraping, qui nécessite des développements à chaque évolution des espaces de banque en ligne.
Les API d’accès au compte et d’initiation de paiement devront être validées par l’autorité compétente avant leur entrée en application. Quel est le calendrier prévu ?
La mise en œuvre de ces aspects de la DSP 2 devra avoir lieu au plus tard en septembre 2019. Nous n’attendrons pas cette date et nous les publierons d’ici la fin de l’année. Les modalités et critères de validation de l’API ne sont pas décrits dans les textes, il appartient à l’ACPR de les définir. La durée de validation des API est de 6 mois. En tout état de cause, nous respecterons le standard édicté par STET dans le cadre des travaux interbancaires, et nous aurons les mêmes exigences de robustesse que pour nos API internes. Par ailleurs, dès juin 2018, nous commencerons à mettre en place notre portail d’API.
Quel type d’API pourra-t-on trouver sur ce portail ?
Cela renvoie à notre vision de l’open banking, à savoir l’opportunité de créer de nouveaux types de business models. Il s’agit d’aller au-delà de notre modèle traditionnel qui consiste à distribuer nos propres produits et services à nos propres clients via nos propres canaux. On distingue trois nouveaux modèles :
- « bank-as-a-service » : la banque met à la disposition d’acteurs tiers des produits et services. L’accès aux comptes par les agrégateurs ou encore Apple Pay en sont des exemples ;
- « bank-as-a-platform » : la banque distribue sur ses propres canaux les offres de partenaires externes. C’est le modèle d’Amazon qui a ouvert son site aux offres d’e-commerçants extérieurs, tout en continuant de distribuer ses propres produits. Pour nous, il peut s’agir de proposer des offres de FinTechs aux clients de la banque, par exemple sur le coaching budgétaire ou le cashback ;
- « marketplace » : la banque propose à de nouveaux acteurs bancaires comme des néobanques par exemple, des produits complémentaires à leur offre propre, souvent limitée à un compte et un moyen de paiement. Ces solutions peuvent être offertes en marque blanche ou non, et inclure le bénéfice de la licence bancaire ou non.
Qui décide de la nature des partenariats noués ?
L’équipe IT pour les activités de banque de détail en France travaille sur un socle commun pour l’ensemble de ces modèles. C’est via ce socle que seront exposées les API correspondantes. Mais c’est à chaque enseigne (Société Générale, Crédit du Nord…) de choisir les partenaires qu’elle souhaite, les services à ouvrir vers l’extérieur, le business model associé, que ce soit sous forme d’abonnement, de facturation au nombre d’appels de l’API…
En quoi consiste plus concrètement ce socle commun ?
Le portail que nous construisons prévoit un parcours client pour les développeurs externes qui voudront utiliser nos API. Il comprendra un « bac à sable » pour leurs tests, une documentation très claire de chaque API et un accès sécurisé pour y accéder.
En quoi consiste ce bac à sable ?
Dans un premier temps, un développeur peut avoir accès au contenu de l’API même sans être authentifié, via une documentation simple et claire. Puis il peut la découvrir dans un environnement sécurisé, avec des données désensibilisées, après s’être identifié. Cela lui permet de tester des usages. Pour accéder à l’API en production, il devra passer par une authentification plus forte, comprenant notamment la vérification de l’agrément dans le cas des API liées à la DSP 2.
Echanger avec les développeurs d’entreprises de petite taille comme les FinTechs ne peut-il pas s’avérer délicat pour une grande banque ?
Nous avons déjà recours à des API en interne, les différentes équipes amenées à les utiliser ne se connaissant pas nécessairement très bien. Nous avons donc pu identifier quelques bonnes pratiques. La documentation doit être rédigée dans un langage compréhensible de tous : les définitions doivent être explicites et standard, sans jargon propre à la banque. Il est également bon de donner un exemple d’appel de l’API sous certains paramètres de test. L’enjeu est que les FinTechs soient autonomes dans leur utilisation du bac à sable.
Le langage de développement informatique utilisé est-il discriminant ?
Non, il importe peu. Cette indépendance du langage sous-jacent est d’ailleurs une force de l’API. Un développeur pourra l’appeler en entrant dans l’interface les paramètres qu’il souhaite et il aura la réponse, qu’importe si la fonction appelée est un progiciel d’ancienne génération ou une application récente open source.
Peut-on utiliser une API sans être développeur ?
Oui, c’est possible. Prenez l’exemple de l’API de Google Maps : son utilisation ne nécessite pas de connaissance informatique particulière. En revanche, une API est utilisée dans un certain contexte, un site, une application… sur lequel il faut savoir agir.
Dans le modèle de « bank-as-a-platform », vous serez amené à appeler les API de tiers. Qu’en attendez-vous ?
Ces API devront permettre un parcours client fluide entre nos canaux et l’infrastructure de nos partenaires. Les services devront être disponibles en temps réel et en permanence. Le fonctionnement sera le même que pour notre portail. D’ailleurs, pour appeler l’API d’un tiers, il faudra parfois permettre à ce même tiers d’accéder à certaines de nos données, là encore via une API. Le modèle est symétrique.
