Les interfaces de programmation d’applications (API) ouvertes furent l’un des sujets chauds de la conférence Sibos de cette année, qui a eu lieu à Genève, en Suisse. On y a notamment discuté du fait que leur introduction suscite des inquiétudes au sein de certaines institutions financières, mais crée également des occasions prometteuses pour les utilisateurs précoces. Les réglementations, telles que la Directive révisée sur les services de paiement (PSD2) en Europe, favorisent l’adoption des API ouvertes dans le secteur des services financiers. Ce billet de blogue explore quelques-unes des principales questions techniques abordées lors de Sibos.
Élaborer un dictionnaire et un modèle de données
Afin de s’assurer que les API ouvertes sont interopérables, c’est-à-dire qu’elles peuvent être utilisées efficacement par plusieurs parties, il est nécessaire d’élaborer un dictionnaire de données et un modèle de données qui conviennent à tous. Si la structure et les éléments de données ne sont pas normalisés et publiés, les développeurs n’ont aucun cadre de gestion standard sur lequel appuyer leur travail et chaque mise en œuvre d’API requiert un processus personnalisé. Il s’agit de l’une des principales considérations techniques que la communauté bancaire doit résoudre afin d’assurer la rapidité du développement des applications et du rendement du capital investi.
Une fois qu’une organisation a convenu d’un dictionnaire et d’un modèle de données, elle doit répondre à quelques questions. Par exemple, qui sera responsable du modèle de données et de sa mise à jour? Quelle structure devrait être utilisée pour les messages d’appel des API? La norme ISO 20022, déjà largement utilisée par la communauté bancaire, est perçue comme un bon point de départ pour élaborer le dictionnaire et le modèle de données. Cependant, elle est probablement trop astreignante pour être utile à la définition de la structure de ces messages. Doit-on donc avoir recours à une nouvelle norme réglementaire?
Parvenir à un équilibre entre la convivialité et la sécurité
L’équilibre entre la convivialité et la sécurité constitue un autre enjeu technique clé. Pourquoi Uber est-elle un succès? Entre autres, parce que son modèle est convivial. L’histoire a démontré que les consommateurs choisissent toujours l’option la plus simple. Par conséquent, pour que les API soient efficaces, elles doivent être simples et faciles à utiliser.
Parallèlement, au fil de la croissance des cybermenaces, il est impératif de renforcer la sécurité au sein de la nouvelle économie des API ouvertes. Il est possible de le faire en intégrant des mécanismes de sécurité complets aux applications, en adoptant un modèle de gestion fédérée des identités et en connectant les services d’entreprise à la fonction de paiement, ce qui permet de contourner les interventions manuelles, les ouvertures de session, les mots de passe, etc. La biométrie, qui comprend le balayage des empreintes digitales et de l’iris, continuera également d’évoluer afin de sécuriser l’accès des utilisateurs aux appareils mobiles.
Choisir la plateforme API appropriée
Les API ne sont pas uniquement utilisées pour permettre aux tiers d’accéder aux applications de base. La plateforme API d’une banque doit être en mesure d’effectuer la répartition des charges ainsi que de surveiller et de gérer les accès et l’utilisation. Par exemple, lorsqu’il est question de l’utilisation des services par les consommateurs, il est difficile de prédire les volumes futurs et de déterminer les moments où la charge atteindra son niveau maximal. Il est donc essentiel de s’assurer que le système peut s’ajuster à la hausse et à la baisse afin d’offrir des réponses instantanées ou quasi instantanées, quel que soit le nombre d’utilisateurs simultanés. Si l’application n’est pas accessible au moment où les consommateurs tentent de l’utiliser, ils se tourneront immédiatement vers un autre service et n’utiliseront probablement plus cette application si cet autre service leur procure une expérience positive. Par conséquent, l’application doit être rapide, conviviale et accessible 24 heures sur 24, 7 jours sur 7.
Comment les banques devraient-elles réagir?
Une étude récemment publiée par CGI, intitulée Perturbations liées aux technologies dans le secteur des services financiers, démontre une croissance des attentes à la fois chez les particuliers et les entreprises envers leurs fournisseurs de services bancaires. À mesure que la transformation numérique continuera de s’accélérer à l’échelle mondiale, les entreprises et les particuliers commenceront à réévaluer leurs relations actuelles avec les banques et envisageront de faire appel à de nouveaux types de fournisseurs, tels que les entreprises de technologies financières. La concurrence sur le marché des services financiers sera donc de plus en plus féroce.
Habituellement, les utilisateurs précoces des nouvelles technologies n’obtiennent pas d’avantages considérables par rapport à leurs concurrents. Toutefois, dans le cas de l’économie émergente des API ouvertes, les institutions financières qui tirent parti de ces outils dès maintenant seront en position idéale pour devancer les retardataires et augmenter considérablement leurs parts de marché. Bien que les API ouvertes ne soient pas la seule façon de s’adapter à l’intensification de la concurrence, elles constituent un moteur pour les banques qui souhaitent réaliser une véritable transformation numérique offrant des avantages concrets à leurs clients, les particuliers comme les entreprises. Qu’il s’agisse d’offrir un nouveau service pour aider les personnes bien nanties à prendre des décisions d’investissement éclairées, ou de permettre aux entreprises d’intégrer leurs services bancaires à leur chaîne d’approvisionnement, les utilisateurs précoces des API ouvertes en sortiront gagnants, et se trouveront probablement loin devant leurs concurrents.
Pour en savoir davantage au sujet de l’économie des API ouvertes, lisez l’étude technique de CGI : « How Banks Can Create Value from the Rise of the Open API Economy in Financial Services »*. N’hésitez pas à communiquer avec moi pour en discuter.
*en anglais