Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

En tant que consommateurs de services numériques, nous ne les percevons pas. Et pourtant, les API (Application Programming Interface) sont la pierre angulaire sur laquelle repose le succès de nombreux projets et entreprises numériques, tels que WeChat, Google Maps, Uber Eats, ou encore AWS.

Les API sont un protocole de communication entre deux services numériques, autrement dit elles permettent à deux applications de s’envoyer des informations et de les exploiter. L’intérêt principal de ce protocole de communication est qu’il facilite l’intégration d’un service numérique au sein d’un autre service numérique, ce qui prend tout son sens lorsque l’on sait qu’une entreprise SaaS moyenne utilise un nombre médian de 15 intégrations produit.

Par exemple, lorsqu’un usager d’Uber commande une course, l’application souhaite calculer et exposer le temps de trajet estimé à cet usager, et plutôt que de réaliser le calcul elle-même, elle fait appel à une API qui exploite les données de circulation de Google Maps. C’est comme si Uber demandait à Google de calculer le trajet pour lui, et affichait la réponse à l’utilisateur. Le client n’a donc pas quitté une seule fois Uber lors de ce calcul.

Les API ne sont pas aussi récentes qu’il n’y paraît (le terme a été utilisé pour la 1ère fois en 1968), mais leur popularisation s’est accélérée à partir des années 2000, à l’ère d’internet et des applications mobile. Par la suite, la crise sanitaire, en ce qu’elle a accéléré la digitalisation des entreprises, a été un catalyseur supplémentaire de l’API economy : plus de US$2 milliards ont été investis dans des entreprises d’API dans le monde en 2020, contre $0.5 million en 2017.

Quand on évoque les API et les entreprises qui les développent, en réalité on met le doigt sur deux stratégies potentielles et radicalement différentes. D’une part, certaines API sont développées « comme une fonctionnalité supplémentaire permettant à une société B2C d'étendre l'empire d'un produit déjà existant », explique Romain Huet, Head of Developer Relations chez Stripe (une plateforme d’API spécialisée dans le paiement). Dans ce cas, un microservice unique est développé en interne puis proposé à des clients développeurs, par exemple un service d’assurance ou de calcul des frais de transport est intégré sur un site d’e-commerce.

D’autre part, de plus en plus d’entreprises vont plus loin et misent sur une stratégie API-first : elles proposent des boîtes à outils multi-services qui permettent à leurs clients de développer leur application ou leur site très rapidement. Ces entreprises API-first fournissent l’infrastructure de base de tous leurs microservices et ces micro-services communiquent entre eux, si bien que « les développeurs (clients) n'ont plus besoin de tout coder de A à Z et peuvent ainsi se concentrer sur le cœur du produit qu'ils sont en train de développer », estime Romain Huet. Finalement, grâce à ces briques de construction, les entreprises API-first promettent à leurs clients d’assurer l’évolutivité, la résilience, la scalabilité et la modularité de leur application ou de leur site, et d’un point de vue macro-économique elles réduisent le coût des produits minimum viables donc les barrières à l’entrée pour les start-up.

Stripe a construit son succès sur une stratégie API-first

Stripe est une fintech américaine BtoB qui permet à ses entreprises clientes de recevoir des paiements en ligne grâce à des APIs. A sa création en 2010, l’entreprise avait identifié un besoin chez les développeurs d’application mobile pour des services de paiement. Aujourd’hui, elle sert des millions d’entreprises de toute taille, des start-up aux grandes entreprises, et propose des services de plus en plus variés : paiement en ligne, terminaux de paiement physiques, gestion des abonnements, factures en ligne, création de cartes virtuelles et physiques, gestion de la fraude, ou encore des dons vers des technologies d’élimination du carbone. En échange, les entreprises clientes paient une commission sur chaque transaction effectuée via Stripe.

Stripe s’est appuyé sur deux principaux piliers pour démarquer son offre. D’une part, l’entreprise a construit une offre et un parcours d’utilisation centrés sur les attentes des développeurs. On note notamment une rubrique sur le site dédiée aux développeurs, et qui leur donne accès à des informations claires sur le fonctionnement de l’API, à des exemples de code et d’application, à des guides d’utilisation, etc. D’autre part, Stripe s’engage à assurer la rétrocompatibilité de son API, une particularité qui paraît anodine mais qui est pourtant essentielle dans la mesure où une API qui évolue sans rester compatible aux lignes de code initiales de ses entreprises clientes les condamnent à des efforts d’adaptation faramineux. Cette stratégie semble payer puisque Stripe dispose de 19% des parts du marché mondial de traitement des paiements (derrière PayPal à 54%) et l’entreprise a été valorisée à $115 milliards d’euros.

Les APIs ne concernent pas uniquement le monde des start up et du numérique

Si l’idée d’une “API economy” dans laquelle de nouveaux entrants_ digital native_ apportent de la valeur à des développeurs d’autres entreprises numériques a fait son chemin, on oublie trop souvent que les API ne concernent pas uniquement des géants ou start-up du numérique.

Le secteur bancaire témoigne par exemple de cette porosité vers les secteurs traditionnels : la directive européenne DSP2 entrée en vigueur en 2018 oblige les banques basées dans l'UE à passer à l'open banking, plus précisément à exposer leurs services et données via des API, afin que des partenaires, des fintech ou même des concurrents puissent apporter une valeur ajoutée à leurs clients. Concrètement, cette impulsion réglementaire permettra notamment à l’API des services de gestion d’épargne (Yomoni, Cashbee, eToro) d’accéder à l’API des agrégateurs de comptes (Bankin, Tink, Plaid), eux-mêmes en lien avec l’API de la banque, et ainsi de permettre à l’utilisateur du service de gestion d’épargne d’optimiser son portefeuille en direct.

D’autres secteurs s’intéressent aux API non pas pour des raisons réglementaires mais pour poursuivre des objectifs de disruption ou d’interopérabilité. La plateforme Skywise développée par Airbus illustre ces ambitions. Dans l'aviation, les données opérationnelles et de vol critiques sont souvent enfermées dans des silos. En tant que fournisseur de la plupart des compagnies aériennes, Airbus a souhaité prendre part à la digitalisation de son écosystème et a lancé avec Palantir une plateforme de données basée sur une API, Skywise, pour aider les compagnies aériennes à réduire les problèmes de maintenance et à prévenir les retards techniques. A ce jour, la plateforme permet de suivre 9,000 avions exploités par 130 compagnies aériennes, et elle est consultée par plus de 17,000 utilisateurs uniques chaque mois.

Devenir API-first implique des bouleversements organisationnels majeurs

Certes, devenir API-first permet de réduire drastiquement les coûts de développement et le temps de road-to-market d’un nouveau produit ou service numérique. Néanmoins, cela implique aussi de repenser entièrement son organisation interne, à la fois l’organisation des équipes et la place donnée aux développeurs dans l’entreprise, ce qui peut s’avérer complexe à implémenter.

D’une part, traditionnellement, les équipes de développement travaillent à partir d’un cahier des charges lorsqu’elles développent une application. Un passage à une stratégie API-first impose de créer des équipes multidisciplinaires, centrées autour de services ou d’API. Ce changement de paradigme a pour conséquence de modifier structurellement les processus d’organisation et les responsabilités au sein de l’entreprise, et en ce sens il bouleverse la pyramide managériale. Les APIs étant libres d’accès au moins en interne, ces équipes centrées autour d’un service ou d’une API peuvent librement utiliser le travail des autres équipes pour développer et faire évoluer leur produit de façon autonome. Est - ce la fin du cahier des charges pour une grande partie d’entre elles ? Le cas d’Amazon souligne la nécessité d’adapter l’organisation des équipes : en 2002, Jeff Bezos a décrété que toutes les équipes chargées des produits devraient exposer leurs données et leurs fonctionnalités au moyen d'API, dans le but de promouvoir l'autonomie et l'agilité des équipes. On voit bien que ce passage à une stratégie API-first a pour conséquence de rendre, par défaut, l’entreprise plus agile et autonome : chaque projet ou idée qui émerge peut s’appuyer sur le travail du reste des équipes pour accélérer ou supporter ses développements.

D’autre part, les développeurs d’une organisation API-first sont remis au premier plan, ils ne sont plus des “fonctions supports” mais deviennent des “équipes business” à part entière. En effet, leur objectif n’est plus seulement de développer le meilleur produit (par exemple devenir plateforme d’assurance la plus performante du marché), mais aussi et surtout que l’API soit utilisée par un maximum de développeurs d’organisations tierces (si l’on reprend notre exemple, que le service d’assurance soit utilisé par un maximum de développeurs travaillant dans des plateformes d’e-commerce tierces). Un tel virage organisationnel suppose de donner les moyens aux développeurs internes d’accompagner la communauté de développeurs partenaires et de co-construire avec eux un produit adapté à leurs attentes. Ce changement de position pour les équipes de développement transforme les développeurs en porteurs de savoir capables de soutenir et d'accélérer le modèle d’affaires de l’entreprise.

Ce qu'il faut retenir - par Raphael Khalifa, IT Transformation Director chez Fabernovel.

• En plus d’être une stratégie de refonte de l’architecture technique de l’entreprise, la stratégie API-First est un vrai bouleversement business sur la façon de distribuer la valeur créée par les équipes.
• Cette façon de voir la proposition de valeur de l’entreprise implique un profond bouleversement, tant en interne, dans l’organisation, les processus et la façon d’aborder les équipes techniques, qu’en externe, dans les produits proposés par l’entreprise.
• Ainsi, toute entreprise adoptant une stratégie API-First devient une Software Company, et son informatique passe d’une fonction supportant à l’activité à un différentiateur stratégique, dégageant de la valeur.