Quel est l’enjeu des API pour le secteur bancaire ?
Les API, en tant que « portes » permettant à deux programmes de communiquer et de s’échanger des données, sont utilisées depuis une trentaine d’années. La nouveauté est qu’aujourd’hui, elles s’ouvrent, ce qui permet d’exposer de manière sécurisée le système d’information (SI) de la banque à un écosystème de développeurs tiers. En effet, à partir du moment où l’on propose d’accéder à ses données bancaires sur Internet, on s’expose au « screen scraping », c’est-à-dire une forme de « piratage » des informations. C’est avec cet objectif de sécurité que le Crédit Agricole a pris l’initiative, il y a quatre ans, de mettre en place le CA Store, permettant à un écosystème de développeurs – la coopérative des « digiculteurs » – de développer des applications en utilisant les API ouvertes et sécurisées de la banque, tout en répondant à des idées des clients.
Est-ce une forme d’« open banking » ?
Oui, on peut appeler cela ainsi, ou encore « bank as a platform ». Nous étions précurseurs par rapport à ce qu’impose aujourd’hui la DSP 2. Il est d’ailleurs intéressant de voir que, pour une fois, c’est la recherche de sécurité qui, au lieu de freiner l’innovation, la stimule.
En quoi les API ouvertes sécurisent-elles davantage les données bancaires ?
Nous nous appuyons sur un chiffrement classique propre au web auquel nous avons ajouté plusieurs niveaux de sécurité. Tout d’abord, un triple jeton sécurisé, l’un donné au développeur référencé comme partenaire, l’autre à l’application elle-même, validée par nos services, et enfin, un au client. Les trois jetons doivent être activés pour que l’API réponde. Ensuite, pour limiter les conséquences en cas d’attaque, nous avons fait le choix d’anonymiser les données transmises par l’API. Le client se connecte à travers un pseudonyme et on ne peut pas remonter à son identité à partir des données.
Cela ne bloque-t-il pas certains usages ?
On pense souvent que l’anonymisation empêche d’offrir des services bancaires. Personnellement, je ne me connecte pas à ma banque pour savoir comment je m’appelle ! C’est ce principe qu’il faut appliquer. Il nous faut faire l’effort de regarder les questions différemment mais jusqu’à présent, nous n’avons jamais été bloqués. L’envoi du RIB a été une des applications les plus problématiques à anonymiser mais nous avons résolu le problème en considérant que l’enjeu était d’exposer une demande de RIB et non pas d’obtenir le document lui-même : l’API permet donc de l’envoyer sur l’adresse mail officiellement enregistrée en amont par le client.
Pourriez-vous citer quelques applications phares ?
Sur la soixantaine d’applications que compte le CA Store, cinq ou six sont de vrais succès. Parmi elles, l’application appelée InfosCompte a été l’une des premières applications à être disponible sur l’Apple Watch et à utiliser l’identification biométrique d’Apple et même la première au monde à être présente sur l’Apple TV, trois semaines après sa sortie. Une autre application – actuellement mise à jour – permet de réconcilier les dépenses de santé avec les remboursements pour mieux piloter son budget santé.
Comment est régie votre relation avec les programmeurs ?
Les digiculteurs signent un contrat de développement avec le CA Store. Nous en avons une vingtaine, représentant environ 300 développeurs. Cette R&D ouverte, cette « open innovation », nous permet d’être plus rapides et plus réactifs face aux demandes des clients. Elle ne se limite pas aux API ouvertes d’ailleurs : notre écosystème de partenaires inclut aussi de grandes entreprises comme PSA, SNCF, IBM ou Microsoft, avec qui nous travaillons notamment via des hackathons.
Quel lien faites-vous entre les concepts d’open innovation et d’open bank ?
Une open API est un des outils de l’open innovation permettant aux projets nécessitant une connexion au SI de la banque de se réaliser. Permettre cette ouverture relève de l’« open bank ».
Quel mode de rémunération a été choisi pour l’utilisation de ces API ?
Elles sont disponibles à titre gratuit pour nos partenaires digiculteurs qui s’engagent à fournir à leur tour gratuitement les applications à nos clients. Nous rémunérons les développeurs en fonction de l’usage fait de leur application.
Monétiser les API serait pourtant une source de revenus pour les banques…
C’est beaucoup trop tôt. Nous sommes pour l’instant dans une démarche partenariale. Si cette collaboration avec les développeurs fonctionne, nous pourrons nous poser la question.
Que va changer la DSP 2 ?
Aujourd’hui, nous sommes la seule banque à proposer des API ouvertes. Demain, d’autres suivront. La DSP 2 permet de donner un cadre unique pour les interfaces et les contrats, ce qui simplifiera les interactions au sein de l’écosystème. La DSP 2 vise la création d’un standard européen. Nous discutons d’ailleurs entre banques françaises pour faire remonter nos exigences au niveau européen.
Le screen scraping n’est pas explicitement interdit par la DSP 2. Est-ce regrettable ?
C’est une pratique utilisée par certains agrégateurs qui devra être régulée à l’avenir. C’est un vrai sujet de sécurité pour nos clients car leurs données sont exfiltrées par des robots et la banque n’a plus la maîtrise : qui consomme ces données ? Où sont-elles stockées ? Comment sont-elles utilisées ? D’où l’importance du contrat de développement qui permet à la banque de garder la gouvernance de son système d’information. Mais je pense aussi que cette régulation du screen scraping ne pourra être mise en œuvre qu’à partir du moment où les banques proposeront des API ouvertes, sécurisées et normalisées.
Au-delà des comptes de paiement, il serait question que les comptes épargne soient concernés par l’exigence d’ouverture de la DSP 2. Qu’en pensez-vous ?
Le débat de la profondeur de la couverture fonctionnelle offerte par l’API n’est pas tranché. Peut-être la réponse pourrait-elle être laissée à la discrétion de chaque banque. Pour réduire la tentation du screen scraping des agrégateurs, il faut pouvoir proposer des chemins sécurisés les plus larges possibles.
L’open banking est-il donc inéluctable ?
À partir du moment où la banque a proposé ses services sur Internet, elle s’est ouverte. Désormais, soit on sécurise les outils de cette ouverture via les API ouvertes et l’« open innovation » maîtrisée, soit on perd le contrôle.
