Comment s’assurer de la qualité des APIs dans le cadre des travaux d’open banking ?

De plus en plus d'articles font le bilan concernant la disponibilité des API des banques au regard de la DSP 2.  Un intéressant point de situation est ainsi réalisé par le Journal du Net. La phrase clé de l'article est que "quantité n'est pas gage de qualité", mais cela mérite quelques explications. (Et encore sur la quantité on peut aussi s'interroger, car DBS à l'heure actuelle dispose d'un portail avec plus de 200 APIs, tandis que les banques françaises pour le moment ne dépassent pas la dizaine).

Quel Usage ?

Lorsque la qualité n'est pas au rendez-vous, c’est sûrement dans le cas où les banques ont pris le sujet sous l'angle réglementaire (DSP 2) ou sous l'angle technologique (il faut des APIs). On en oublie du coup une composante essentielle qui est l'usage : qui les utilise ? pourquoi ? quelle valeur est ainsi générée ? Le fait de voir les APIs sous le prisme de la contrainte réglementaire, empêche souvent de voir la valeur ajoutée qu’elle peuvent pourtant apporter.

Il est donc plutôt préférable de faire partir la conception d’un usage spécifique bien identifié. C’est une bonne garantie pour proposer une solution pertinente sur le marché, et par conséquent pour le succès du projet. Pour y parvenir le meilleur moyen est d’identifier un ou plusieurs utilisateurs potentiels et de réfléchir concrètement à un de leurs besoins existants ( en faisant attention de ne pas tomber dans le piège du «  sur mesure », car l’idée est bien de développer à terme une seule API utilisable par tous). A noter aussi que le client potentiel ne pourra pas toujours formuler un besoin précis et que la démarche de "co-construction" prend alors tout son sens ici.

Je rencontre beaucoup d’opérationnels du côté des équipes techniques qui travaillent sur ces sujets et qui sont désemparés, car ils se retrouvent à aller à la recherche de la personne du métier qui voudra bien les aider à lancer ou faire avancer le projet. Le constat est que l'importance et la valeur ajoutée des APIs ne sont pas toujours suffisamment mises en valeur par les directions générales et au sein des stratégies des banques. Et que par conséquent côté métier on voit les projets d’open banking comme faisant partie du périmètre de l’IT. Le résultat est que les travaux ont du mal à aboutir.

Pour ceux qui ont pris le sujet sous le bon angle d’approche, ils découvrent au contraire un monde fascinant où ils se retrouvent à dessiner de nouveaux usages avec leurs clients. Les équipes que j’ai rencontrées dans ce cas sont passionnées par leur projet, car elles se rendent compte que les usages qu’elles sont en train de construire sont totalement nouveaux par rapport aux métiers traditionnels de la banque et pourraient présager d’un radieux avenir pour l’open banking.

Enfin, partir de l’usage permet non seulement de faire avancer plus efficacement les sujets des APIs, mais contribue aussi à poser les bases d’une nouvelle organisation orientée usages et utilisateurs, qui se concrétise souvent par la constitution "d'équipes produits". En effet, disposer simplement d’une équipe API, open banking ou DSP 2 ne permet pas de mettre en avant le client ou l'utilisateur final et donc à terme de répondre efficacement au besoin. Si l'open banking s'impose comme un nouveau modèle pour la banque, il faudra alors revoir aussi en profondeur l'organisation actuelle qui ne sera plus adaptée.

La DX : Developer Experience

Un autre aspect à prendre en compte pour développer une API de qualité, c’est la Developer Experience (DX).

Fournisseur d’API est un métier totalement nouveau à appréhender, et il va aussi falloir du temps pour s’y former. Ce qui fait la force d’un acteur dans ce modèle n’est pas tant la notoriété de la marque grand public, mais la qualité du service qu’il propose (la fiabilité, la sécurité, la résilience, le SLA...), et surtout ce qu’on appelle la DX, la « developer experience » (en parallèle avec la UX, la « user experience »). C’est ce qui favorise l’adoption ou non du service. Au-delà de la forme de présentation, c’est la facilité avec laquelle le développeur va appréhender le service qui rentre en jeu : est-il simple d’accès, la documentation est-elle claire, est-ce que je la comprends, est-ce qu’il y a du jargon spécifique et surtout est-ce que j’ai besoin de support au-delà de la documentation disponible.

Tout comme l’enjeu pour une entreprise est de séduire les clients, l’enjeu pour les API est de séduire le développeur. Il est impossible de forcer un développeur de passer par son API, tout comme il est impossible de forcer quelqu’un à devenir son client en dehors d’une situation de monopole. Plus les banques attendent de faire face au problème, moins il y a de chances que l’API rencontre l’adoption, car le marché commence déjà à être saturé. C’est particulièrement vrai pour des API spécialistes, comme le paiement, où Stripe et PayPal sont déjà des acteurs de référence.

Et demain ?

Sans le prisme de l’usage et de la Developer Experience en tête il est en effet difficile de faire des API "bien conçues". Il existe alors un risque qu’au moment du bilan sur l’open banking, au lieu de donner aux APIs toute la dimension stratégique qu’elles méritent, les banques s’arrêtent à ce premier effort déjà fourni, car par manque de qualité, l’adoption pourrait être limitée et enverrait de mauvais signaux. Effectivement des APIs  mal conçues, ne vont pas rencontrer d’utilisateurs et pousseraient hâtivement les banques à en conclure qu'il ne faut pas s’attarder plus que ça sur le sujet en attendant la prochaine réglementation qui les oblige à aller plus loin. Et pourtant le risque « à ne pas faire » et ne pas percevoir toute la portée stratégique du sujet est élevé...

Pour aller plus loin :

Conférences et formations :

Bankless Banking : de nouvelles fondations pour la banque

Partie 2 : L'ouverture nécessaire de la banque, vers l'open banking

  • Les API au cœur d'un nouveau positionnement
  • L'open banking à l'origine d'opportunités stratégiques

Articles :