Les API, cet outil au centre du concept d’open banking

Le concept d’API (Application Programming Interface) est utilisé depuis plus de 20 ans en informatique, mais nous pouvons en dater la naissance à la thèse de Roy Fielding en 2000, qui définit les usages et principes des API suivant le protocole REST. L’utilisation des API a véritablement explosé avec le développement du mobile.

Quand les programmes dialoguent entre eux

Littéralement « interfaces programmables pour applications », les API sont une évolution du web. Depuis 20 ans, les sites Internet se développent pour permettre aux individus d’échanger et aux entreprises de vendre leurs produits à des humains de manière électronique. Les API font la même chose, mais pour des programmes : plutôt que de n’avoir que des visiteurs humains dans votre « boutique » électronique, vous pouvez désormais accueillir des « bots » [1] et des applications web ou mobiles, dépassant les limites physiques d’un utilisateur humain visitant le système d’information (SI). Il y a 20 ans, une banque ne pouvait concevoir de continuer à se développer sans un site web, il y a 5 ans sans une application mobile, et désormais sans une API.

Début 2015, un article paru dans la Harvard Business Review [2] mentionnait que Salesforce générait 50 % de son revenu par des API, eBay 60 % et Expedia 90 %. La tendance sur les deux dernières années s’est accentuée. Concrètement, une API va par exemple permettre aux développeurs d’une entreprise de solliciter les bases de données de Salesforce sans passer par l’interface web pensée par l’éditeur de solutions de CRM : en utilisant l’API de Salesforce, ils pourront relativement facilement s’affranchir des limites du site web et développer des fonctionnalités sur-mesure. De même, Expedia met à la disposition de nombreuses agences de voyages (y compris en ligne) son SI – lui-même connecté aux systèmes de réservation des compagnies aériennes et des hôtels –, grâce aux API.

Des API pour qui ?

Si nous retenons des API leur caractère d’exposition de produit pour des programmes tiers, tout type d’acteur disposant d’un produit peut (doit ?) être intéressé à en développer :

• une banque pour exposer son système bancaire à ses applications et à des applications tierces, comme demandé par la DSP2 ;
• une Fintech de type agrégateur (comme les françaises Bankin et Linxo), qui peut retirer les informations bancaires d’un client – après avoir reçu sa délégation – depuis l’API d’une banque, et présenter ces mêmes informations à d’autres FinTechs, par exemple un robo advisor. La chaîne serait alors : {utilisateur d’application robo advisor} – {API du robo advisor } – {API de l’agrégateur} – {API de la banque}, chacun des chaînons ajoutant sa propre valeur ajoutée.

Aujourd’hui, les banques peuvent exposer leur SI par des API pour en monétiser le trafic non seulement à travers leurs applications, mais aussi à travers les applications développées par d’autres sociétés (généralement des FinTechs). Les banques peuvent également utiliser les API d’autres sociétés pour enrichir leur offre, en ligne avec l’expérience utilisateur (UX) que chacune souhaite développer, et ce en quelques semaines, là où un développement interne prendrait plusieurs trimestres. La course à la meilleure UX étant lancée avec l’arrivée de la génération des « millennials » [3] , les API jouent un rôle d’accélérateur dans la feuille de route des banques, devenue critique voire obligatoire pour continuer à captiver des utilisateurs (même plus âgés) désormais habitués aux expériences Netflix, Amazon, Skype et Google.

Comme pour le web en 1995 ou le mobile en 2005, plusieurs facteurs ont désormais amené les API sur le devant de la scène : une standardisation efficace dès 2000, la possibilité par les API de découpler le front-end du back-end (voir infra), et donc de réutiliser le même code pour deux canaux critiques (multi-canal), et surtout l’adoption massive du cloud permettant à des acteurs nouveaux comme les FinTechs de lancer, tester et développer leur base d’utilisateurs en moins d’un an.

L’API, pour une meilleure articulation entre back-end et front-end

Le back-end est la partie non visible du SI d’une société, par opposition au front-end qui regroupe le site web, les applications mobiles et autres interfaces d’accès au système. Les API marquent la frontière entre les deux et ce découplage permet aux utilisateurs du front-end de progresser sur l’expérience utilisateur indépendamment des évolutions du back-end. Ainsi, les API permettent d’exposer aux différents canaux du front-end les capacités de traitement du back-end. C’est un autre aspect de la révolution apportée par les API : une meilleure gouvernance informatique interne et externe.

Prenons le cas d’une banque qui a développé son site web bancaire en 1995, puis ses premières applications mobiles en 2005. Dans de nombreux cas, les ressources aujourd’hui allouées au chaînon web travaillent indépendamment de celles (souvent externes) gérant le canal mobile, avec des sources de données couplées entre front-end et back-end (voir Schéma 1). Pour l’utilisateur, cela peut amener à des décalages – au moins temporels – entre les informations présentées sur l’application mobile et les autres canaux, parfois même des incohérences de données. Pour des utilisateurs désormais habitués au multi-canal, ceci n’est plus acceptable. L’autre inconvénient est d’ordre organisationnel : si l’effort est dupliqué dans le back-end, moins de ressources sont disponibles pour le front-end, le nerf de la guerre pour l’expérience utilisateur. La banque a alors du mal à tenir la corde dans la course à l’UX parfaite, aux contours toujours changeants.

API internes, partenaires ou externes?

Il existe plusieurs types d’API. Certaines – les plus nombreuses – sont développées pour l’interne et ne sont accessibles qu’aux développeurs de l’entreprise. Les banques françaises en ont quelques milliers chacune. Certaines sont ouvertes également à des partenaires signant une charte d’engagement visant à prévenir les cas d’abus comme des changements trop fréquents des spécifications de l’API côté fournisseur ou une utilisation frauduleuse des droits d’accès aux informations côté développeur. Enfin, elles peuvent être externes, c’est-à-dire ouvertes à tout développeur acceptant certaines conditions mais sans la lourdeur d’un contrat partenarial. Par le passé, la tendance était de produire des API internes s’ouvrant à l’externe puis, à la suite d’abus, se repliant sur un mode partenarial. Désormais, les API sont souvent conçues pour l’extérieur, de manière très sécurisée, et certaines fonctionnalités avancées sont réservées à des développeurs partenaires.

L’enjeu du moment, sous l’impulsion notamment de la DSP 2, est l’ouverture des API vers l’extérieur (en mode partenarial ou public). Ce qui ne veut pas dire que toutes les API ont pour vocation d’être exposées à l’extérieur : ouvrir une API demande un significatif travail en matière de documentation, qui doit être compréhensible par des usagers externes, de normes de sécurité et de capacité à monter en charge (leur « scalabilité »). On expose l’image de l’entreprise.

L’économie des API ouvertes

Il existe plus de 16 000 API externes [4] . Une fois que le développeur a contractualisé avec le fournisseur des API, il peut les utiliser comme sur une Place de marché, une sorte d’« Appstore » des API. Ainsi, une banque qui souhaite travailler l’expérience utilisateur sur une niche de marché sans reposer sur un core banking system en propre, peut désormais le faire en assemblant des API de fournisseurs tiers comme des briques de Lego. La plate-forme d’API « Open Bank Project » propose ces briques et est déjà utilisée par des banques européennes pour leurs hackathons par exemple.

L’API doit également être vue par son concepteur comme une nouvelle source de revenus. En effet, un développeur qui souhaite utiliser une API doit payer, souvent en fonction du nombre de connexions qu’il initie sur le système du fournisseur. Payer à l’usage permet à des start-up de tester un business model à peu de frais au début et de monter en charge progressivement. Généralement, le fournisseur de l’API prévoit également un mode « bac à sable » gratuit pour que le développeur puisse tester la faisabilité technique de son idée au tout début.

Utiliser une API est également avantageux en termes de sécurité, car cela évite le scraping, c’est-à-dire la connexion « sauvage » à partir de l’interface client, comme le font actuellement les agrégateurs de comptes avec la plupart des banques. L’API renforce la gouvernance de l’accès en jouant le rôle de guichet de contrôle. À ce stade toutefois, la DSP 2 n’oblige pas à avoir recours à une API pour accéder aux données clients.

Un standard européen pour les API ?

Comme pour le GSM qui a standardisé le mobile en 1991, HTTP pour les échanges sur Internet en 1997, REST pour les API en 2000, SEPA pour les paiements en 2008, les écosystèmes sont plus efficaces et ont une plus grande emprise lorsque les acteurs s’entendent sur des standards d’interface. Un standard minimum s’appuyant sur les standards techniques déjà en cours (REST, HTTP, Open API) est donc souhaitable pour transcrire les dispositions de la DSP2 et prévoir l’Instant Payment. L’Open Banking Working Group britannique semble bien avancé sur ce sujet et pourrait servir de bonne pratique pour le reste de l’Europe. Mais au-delà de la question de la standardisation, c’est bien celle de la prise de risque qui doit être au centre des discussions européennes : il n’est pas possible qu’une banque qui aurait l’obligation de partager ses informations avec des tiers reste entièrement responsable en cas d’abus. C’est là le vrai sujet des API pour les mois à venir.