Pourquoi ? Parce que, dans la plupart des cas, les API ont été implémentées comme une couche supplémentaire aux systèmes existants. Cela donne lieu à un certain nombre de problèmes qui peuvent coûter de l'argent aux entreprises et saper la confiance de leurs clients et partenaires qui comptent sur leurs systèmes. Laissez-nous vous expliquer pourquoi les API doivent au contraire être traitées comme des « citoyens de première classe » pour créer des architectures à la fois fonctionnelles et évolutives.

De mauvaises fondations…

Les API sont apparues comme la solution pour moderniser les systèmes bancaires face à un double phénomène : d'une part, la montée en puissance des nouvelles technologies qui renforce les attentes des consommateurs, et d'autre part un environnement réglementaire en constante mutation qui introduit de nouveaux impératifs et simultanément de nouvelles formes de concurrence. On pense en particulier à la DSP2 (Directive Européenne sur les Services De Paiement 2) qui exige des banques européennes qu’elles créent des API d’Open Banking afin d’ouvrir les données de leurs clients (relatives aux paiements, aux comptes, aux prêts…) à d'autres banques et fintechs, et ainsi rendre le secteur bancaire plus ouvert et transparent. D’après l’Observatoire de l’Open Banking de KPMG, plus les banques deviennent rapidement compliant, plus elles ont de chance de passer du statut de « conformes » à celui de « compétitives », en adaptant l’approche API ouvertes à des cas d’usage excédant le cadre de la DSP2, voire « d’innovantes » en créant de nouveaux services novateurs (nouveaux canaux de distribution, monétisation d’outils statistiques, services de type banking-as-a-service…).

En raison de ces deux phénomènes, le système bancaire est devenu une hydre à deux têtes : d’un côté, des banques traditionnelles aux infrastructures vieillissantes et aux processus longs et inefficaces, et de l’autre, des fintechs proposant des services financiers plus performants et économiques grâce à des solutions web et mobile innovantes.

En effet, les banques classiques ont longtemps été des organisations cloisonnées, composées de différents départements semblables à des silos qui utilisent un patchwork de systèmes disparates pour répondre à leurs différents objectifs. Dans un effort pour abstraire les flux de travaux et se libérer des processus papiers, elles ont introduit une variété de solutions logicielles distinctes qui mises bout à bout permettent de compléter des processus métiers. Les disruptions qui demeurent donnent lieu à des workflows digitalement incomplets, où les ruptures nécessitent l’intervention humaine. Ce n’est pas tout, ils requièrent également un codage important de la part du service informatique. Malgré les efforts de ce dernier, ils ne s'intègrent pas bien aux systèmes existants, de sorte qu’ils ne communiquent pas automatiquement entre eux.

C’est là qu’interviennent les API. Elles portaient la promesse d’intégrer ces systèmes et services disparates en plateformes unifiées où ils peuvent s’échanger des données et réaliser un ensemble de routines en lien avec des systèmes extérieurs.

… et une mauvaise logique d’implémentation

Dans cette logique, les API sont mises en place comme une couche supplémentaire aux systèmes existants. Comme ces derniers fonctionnaient déjà avant l’introduction des API, quand les développeur les testent ils ne passent pas par les API. La conséquence ? Un certain nombre de problèmes de performance ne sont pas détectés car les bons contrôles ne sont pas réalisés sur les API : problèmes de volumétrie, de tenue de la charge d’utilisateurs, de régression de la performance après un certain nombre d’itérations, etc., qui engendrent des erreurs et de la lenteur et donc des surcoûts au TCO (Total Cost of Ownership).

Par effet domino, les API peu performantes empêchent d’autres API de l’intégration de répondre correctement. Tous ces facteurs augmentent les délais d’exécution et dégradent l’expérience utilisateur (UX), minant ainsi la confiance des clients et partenaires qui comptent sur ces systèmes.

Mais ça ne s’arrête pas là. Les failles de sécurité causées par les tests de produits réalisés sans passer par les API sont sans aucun doute plus alarmantes. En divisant les systèmes en applications autonomes, modulaires et réutilisables, l’approche API multiplie en effet les « endpoints » ou points d’accès confrontés au risque de cyberattaques. L’exposition et le caractère critique des API, du fait qu’elles manipulent des données sensibles (personnelles, bancaires…), rendent absolument nécessaire l’adoption de protocoles de sécurité afin d’assurer qu'aucune menace ne passera inaperçue. Ces tests ne seront correctement réalisés que si les API sont considérées comme un élément central des architectures bancaires.

Rendons à César ce qui appartient à César

Plutôt qu’une surcouche, une réflexion après coup, les API doivent être traitées comme des « citoyens de première classe », c’est-à-dire des produits à part entière et non seulement des intégrations subsumées dans d’autres systèmes. Afin que leur efficacité et leur sécurité devienne une priorité, dans une architecture API-first tout projet de développement doit garder en tête l’objectif final de la consommation des API.

Dès lors, les API deviennent les pierres angulaires des systèmes informatiques. Interconnectées et omni-canales, c’est-à-dire appelables à tout moment et par n’importe quel chemin, elles constituent les maillons d’un réseau. Au contraire, les monolithes sont des culs-de-sac, des nœuds terminaux car on peut les appeler mais ils n’effectuent aucun appel vers l’extérieur, ils ne rebondissent pas. Pour permettre aux données de se déplacer de systèmes en systèmes, les API se doivent d’être efficaces, rapides et hautement sécurisées, et cela ne peut marcher que si elles sont traitées comme des first-class citizens.

En plus de s’intégrer facilement aux autres systèmes, les API permettent de créer des architectures modulaires où les capacités des organisations sont décomposées en microservices, c’est-à-dire des services individuels, autonomes et faiblement couplés. Les composants de la plateforme peuvent alors être ajoutés ou remplacés à la manière du « drag and drop » (ou glisser-déposer) pour accueillir de nouvelles fonctionnalités au fil du développement du business et de l’introduction des dernières technologies. Au lieu de développer un nouveau code chaque fois que de nouvelles connexions entre applications sont nécessaires, les équipes techniques peuvent en établir plus rapidement en tirant parti des API existantes.

Cette approche change également la façon dont les institutions bancaires gèrent leurs processus d'affaires. Les flux de travail deviennent automatisés et natifs : en remplaçant les interventions humaines par du selfcare, ils améliorent la conductivité entre le front et le back-office et rendent les parcours clients plus complets.

Lire aussi : Pour une selfcarisation front to back

Bonne nouvelle, la plateforme Basikon est API-first !

Plus qu’API-first, API-second ou API-third, elle est même API-only ! Maintenant que vous avez tout lu vous aurez compris que les API, qui en constituent la colonne vertébrale, sont présentes à toutes les étapes des processus métier et des parcours client : vérification d’identité, open banking, credit scoring, génération de contrats, e-signature, initiation et collecte de paiements sécurisés, génération des écritures comptables... Le monitoring de la performance et de l’exposition de la plateforme, API comprises, permet de garantir la robustesse, la rapidité et la sécurité de l’ensemble de l’intégration.

Et ça ne s’arrête pas là. La plateforme Basikon est également hautement personnalisable pour deux raisons. Tout d’abord, en plus d’un portefeuille exhaustif d'API « standard », il est possible de créer d’autres API de façon ad hoc afin de coller parfaitement aux besoins de chaque client et à leurs spécificités dans leur façon de distribuer les crédits : c’est l’API-as-a-service ! Ensuite, les workflows étant 100% configurables, ils sont capables de gérer tous les types de financement et de s’adapter à tous les cas d’usage (banque, leasing, crédit conso, finance auto, wholesale, revolving, garantie, affacturage, Buy Now Pay Later, Revenue-Based Finance, microfinance…). Grâce à la technologie low code, ils s’adaptent à l’évolution de votre business model sans codage supplémentaire : les chefs de projet peuvent établir leurs propres règles et effectuer des ajustements à mesure que l’organisation croît et que son offre se diversifie.

Lire aussi : Lancer votre offre Buy Now Pay Later est possible avec Basikon

Plateforme de Revenue-Based Financing (RBF) : to make or not to make ? (and buy)

Pour en apprendre plus sur la plateforme API-first de Basikon et comment sa fiabilité, son agilité et sa sécurité permettront d’offrir une expérience fluide et sans couture à vos utilisateurs internes, vos clients et vos partenaires, demandez une démo ici.