La qualité des API, enjeu (discret mais) majeur de transformation numérique

Dans une optique de transformation numérique en profondeur, beaucoup s'intéressent aux API comme moyen de la réussir sans friction ni problème d'interopérabilité. Mais développer des interfaces logicielles sans réflexion structurelle est-il efficace ou bien vaut-il mieux adopter une réelle stratégie d'API à plus long terme ? C'est un sujet crucial car la qualité de l'architecture initiale sera garante de l'homogénéité et de la cohérence de tous les projets qui y seront rattachés.

Lorsque les entreprises veulent mettre en place des API, au-delà de l’intégration d’éléments issus de systèmes différents, elles considèrent essentiellement celles qui vont intégrer par essence une valeur ajoutée monétisable qui leur permettra de générer des revenus supplémentaires. Ce sont les API orientées métier. A titre d’exemple, la majeure partie des 18 milliards de bénéfices annoncés l'an dernier par un célèbre moteur de recherche provient de la mise à disposition de ce type d'API que tout un écosystème de start-ups et d’entreprises emploie pour élaborer ses propres services. 

Comment définir la bonne API pour que celle-ci puisse générer de la rentabilité ?

Avant de se rêver un nouveau Gafam, il est donc important de se poser la question essentielle de la qualité de l’interface que l’on veut mettre en place. En effet, une excellente qualité d’API est désormais primordiale, que ce soit pour générer suffisamment de revenus mais également pour pouvoir être vendue.

Le secteur du crédit illustre parfaitement cette problématique. Pour proposer une offre directe à un consommateur final, une entreprise Fintech va mettre en place une API. Sans une réflexion préalable avancée, elle va se rendre compte qu’elle ne dispose pas des compétences nécessaires pour effectuer le calcul des risques inhérents au métier du crédit. Il va donc lui falloir se rapprocher d’une banque et ainsi prévoir d’intégrer une autre interface – celle de la banque – à sa propre API, et ainsi être obligé de partager les revenus ainsi générés. Et si l’API de calcul de risque change, alors il va falloir modifier sa propre API pour être en capacité de l’interfacer de nouveau avec sa propre API. Autant d’erreurs qui vont, au final, coûter du temps et de l’argent à l’entreprise.

Il est donc essentiel de réfléchir dès le début au design de l’API que l’on veut créer afin d’être en capacité d’intégrer rapidement, et de manière fluide, d’autres API si nécessaire. Comme pour une construction en Lego, il s’agit de choisir en premier les pièces qui permettront de construire l’objet à réaliser. Il en est de même pour ces interfaces : penser préalablement le design d’une API, c’est avant tout « préparer ses briques », ce que l’on appellera ici les API élémentaires. Forte de ces interfaces élémentaires, l’entreprise aura ensuite tout le loisir de défaire ses API complexes et d’en recomposer d’autres, très rapidement, très facilement et dans des délais très réduits.

La souplesse des API élémentaires, la base de services supplémentaires

Dans un monde qui s’accélère, les entreprises n’ont pas le loisir de prendre tout leur temps pour développer un nouveau service. Il s’agit d’une réelle course de vitesse entre concurrents à l’échelle mondiale. Si une entreprise a l'idée d’un nouveau service mais qu’elle met 6 mois à le développer, elle risque de voir un concurrent plus rapide à créer ce service, prendre le marché et réduire à néant les efforts et investissements engagés jusque-là. 

De la même façon, certaines entreprises lancent des services pour une période courte, à l’occasion d’événements spécifiques et inscrits dans le temps, comme un service spécial Jeux Olympiques, ou spécial Tour de France... Concevoir, dans des délais plus ou moins réduits, une API spécifique pour ces services horodatés et courts, supposerait un investissement humain important pour une rentabilité assez réduite au final

L’utilisation des API élémentaires va permettre de pallier ce genre d’inconvénient, à l’instar des Lego dont on parlait plus haut et qui permettent de fabriquer un SUV, puis de changer d’avis et de construire un coupé sport très rapidement. Si l’entreprise a pris soin de créer de solides API élémentaires dès le début, et qu’elle se trompe en lançant un service ou si la tendance change rapidement, elle n’a qu’à réorganiser ses API élémentaires pour bâtir une nouvelle interface dans des temps records. Sans cela, l’entreprise devrait repartir de zéro pour reconstruire une API complexe, ce qui lui prendrait énormément de temps et l’empêcherait de proposer le service voulu plus tôt que ses concurrents.

La qualité des API est un vecteur de revenus

Aujourd’hui, les entreprises qui souhaitent monétiser leurs interfaces ont deux options possibles : soit de façon indirecte comme le cas d’un consommateur qui souhaite souscrire un crédit via une API, la banque va se rémunérer alors sur le crédit que proposera l’interface ; soit elle propose une rémunération à l’usage, par exemple lorsqu'un consommateur consulte son agence de voyage et que celle-ci paye à la plateforme un « droit d’utilisation » de l’API. 

Dans ces deux cas, il apparaît donc essentiel de bien définir son API dès sa création afin d’optimiser ses revenus. D’où la nécessité de bâtir dès le démarrage des API élémentaires solides et bien construites, qui permettront ensuite de développer des combinaisons infinies d’API complexes sans avoir à tout refaire. Si ces interfaces élémentaires sont bien conçues, elles sont facilement exploitables, duplicables et réorganisables comme autant de pièces d’un puzzle numérique. Les concepteurs et utilisateurs des logiciels et fonctions tierces préféreront cette API de qualité, efficace, sécurisée et rapide aux autres présentes sur le marché. 

Flexibilité, souplesse et adaptabilité : les clés d’une transformation numérique réussie et pérenne

Il ne s’agit donc pas de se lancer dans la construction d’une interface pour que cela se traduise par une réelle transformation numérique et pour lancer un service. Il faut penser, à l’instar des joueurs d’échecs, plusieurs coups à l’avance. Lorsqu’une entreprise démarre ce processus profond, elle doit d’abord créer la base du développement de ses futurs services, même ceux qu’elle n’a pas encore imaginés : ces API élémentaires seront le matériau de tous les services ultérieurs, comme les briques standardisées d’un jeu de construction.

Ensuite, à chaque fois qu’elle voudra lancer un nouveau service – parce que le marché change, parce qu’une fonction est obsolète... -, l’entreprise n’aura qu’à défaire son API complexe et recomposer une nouvelle interface avec les API élémentaires qu’elle aura créées au début. Elle gagnera ainsi en flexibilité et en adaptabilité … et donc en revenus.