Au cours d'un atelier auquel je participais il y a quelques jours, fut défendue l'idée qu'il est préférable pour une banque de partir d'une demande d'un client pour créer une API, plutôt que de créer une plate-forme ex-nihilo, sans savoir si elle sera utilisée (et utile). Je ne sais si cette vision est répandue, mais elle pourrait s'avérer risquée…
Certes, le principe proposé est directement inspiré d'une bonne pratique fondamentale de l'innovation : ne jamais s'aventurer dans la création d'un nouveau produit, processus, modèle d'affaires… sans avoir au préalable identifié et qualifié le besoin qu'il vise à satisfaire (qui, notons-le, n'est pas nécessairement exprimé par un client). Il est même possible que la solution développée s'appuie sur une API, ne serait-ce que parce que cela représente souvent le meilleur moyen de partager un service entre deux acteurs.
Pour autant, ce raisonnement ne devrait pas (et, pratiquement, ne peut pas) être appliqué à une démarche d'ouverture de la banque (« open banking ») et à la mise en place concomitante d'un catalogue d'API permettant à des tiers d'accéder simplement à ses données et services. Une première raison à cette injonction est son point de départ : il ne s'agit pas là de créer une innovation, l'objectif visé est uniquement d'offrir à des « clients » un moyen plus moderne et plus efficace d'utiliser les « produits » existants.
La question ne se pose donc pas réellement de savoir s'il existe un besoin puisque l'objet des API mises à disposition est déjà adopté et consommé, par d'autres voies. Et s'il subsiste une interrogation quant à la pertinence de mettre en œuvre un accès programmatique (qui pourrait être aussi considérée comme la recherche d'une attente à combler), elle dénote malheureusement une incompréhension de l'inéluctabilité de la transition vers un univers « digital » dans lequel tous les fournisseurs dialogueront par voies électroniques et tous les services devront être facilement intégrables.
Je pourrais également évoquer l'importance critique, aujourd'hui, pour garantir l'agilité et la flexibilité de la banque face à l'accélération permanente des changements qui l'affectent, d'asseoir le Système d'Information sur une généralisation de l'approche par API à toutes les fonctions qu'il assure, sans exception (comme l'impose notamment Jeff Bezos aux équipes de développement logiciel d'Amazon). Après tout, ce précepte n'est ni plus ni moins que l'état de l'art de l'architecture informatique.
Bien entendu, dans des entreprises historiques qui ont accumulé, au fil des ans, un patrimoine applicatif conséquent, il n'est pas envisageable d'exposer tous ses services sous forme d'API du jour au lendemain, comme est capable de le faire un nouvel entrant tel que Starling Bank. Une démarche progressive est donc inévitable, ce qui suppose de définir des priorités qui, elles, pourront être utilement guidées par les attentes des parties prenantes (dont celles du régulateur, par exemple avec la DSP2).
Mais la cible ultime est parfaitement claire : à terme, la totalité de la banque devra être accessible par l'intermédiaire d'API afin de s'inscrire dans les futurs modèles ouverts, tout comme il est désormais devenu (presque) inconcevable que tous les produits et services destinés à ses clients ne soient pas disponibles dans ses applications mobiles. Attendre une demande explicite de la part d'utilisateurs potentiels avant d'engager les efforts, c'est prendre le risque de disparaître du paysage des services financiers de demain.
Certes, le principe proposé est directement inspiré d'une bonne pratique fondamentale de l'innovation : ne jamais s'aventurer dans la création d'un nouveau produit, processus, modèle d'affaires… sans avoir au préalable identifié et qualifié le besoin qu'il vise à satisfaire (qui, notons-le, n'est pas nécessairement exprimé par un client). Il est même possible que la solution développée s'appuie sur une API, ne serait-ce que parce que cela représente souvent le meilleur moyen de partager un service entre deux acteurs.
Pour autant, ce raisonnement ne devrait pas (et, pratiquement, ne peut pas) être appliqué à une démarche d'ouverture de la banque (« open banking ») et à la mise en place concomitante d'un catalogue d'API permettant à des tiers d'accéder simplement à ses données et services. Une première raison à cette injonction est son point de départ : il ne s'agit pas là de créer une innovation, l'objectif visé est uniquement d'offrir à des « clients » un moyen plus moderne et plus efficace d'utiliser les « produits » existants.
La question ne se pose donc pas réellement de savoir s'il existe un besoin puisque l'objet des API mises à disposition est déjà adopté et consommé, par d'autres voies. Et s'il subsiste une interrogation quant à la pertinence de mettre en œuvre un accès programmatique (qui pourrait être aussi considérée comme la recherche d'une attente à combler), elle dénote malheureusement une incompréhension de l'inéluctabilité de la transition vers un univers « digital » dans lequel tous les fournisseurs dialogueront par voies électroniques et tous les services devront être facilement intégrables.
Je pourrais également évoquer l'importance critique, aujourd'hui, pour garantir l'agilité et la flexibilité de la banque face à l'accélération permanente des changements qui l'affectent, d'asseoir le Système d'Information sur une généralisation de l'approche par API à toutes les fonctions qu'il assure, sans exception (comme l'impose notamment Jeff Bezos aux équipes de développement logiciel d'Amazon). Après tout, ce précepte n'est ni plus ni moins que l'état de l'art de l'architecture informatique.
Bien entendu, dans des entreprises historiques qui ont accumulé, au fil des ans, un patrimoine applicatif conséquent, il n'est pas envisageable d'exposer tous ses services sous forme d'API du jour au lendemain, comme est capable de le faire un nouvel entrant tel que Starling Bank. Une démarche progressive est donc inévitable, ce qui suppose de définir des priorités qui, elles, pourront être utilement guidées par les attentes des parties prenantes (dont celles du régulateur, par exemple avec la DSP2).
Mais la cible ultime est parfaitement claire : à terme, la totalité de la banque devra être accessible par l'intermédiaire d'API afin de s'inscrire dans les futurs modèles ouverts, tout comme il est désormais devenu (presque) inconcevable que tous les produits et services destinés à ses clients ne soient pas disponibles dans ses applications mobiles. Attendre une demande explicite de la part d'utilisateurs potentiels avant d'engager les efforts, c'est prendre le risque de disparaître du paysage des services financiers de demain.
Aucun commentaire:
Enregistrer un commentaire
Afin de lutter contre le spam, les commentaires ne sont ouverts qu'aux personnes identifiées et sont soumis à modération (je suis sincèrement désolé pour le désagrément causé…)