Les APIs et leurs enjeux business

API: acronyme de Application Programming Interface. Une API est le moyen de rendre les logiciels "faciles à brancher et à partager" avec d’autres programmes.

Une API est simplement un groupe de règles (que l’on peut aussi appeler une convention, ou un accord …​) que les programmeurs suivent lorsqu’ils écrivent la partie de leur code qui est en charge de communiquer avec d’autres logiciels. Ces règles sont ensuite publiées (sur une page Web par exemple), afin que toute personne ayant besoin de se connecter au programme puisse apprendre quelles règles suivre.

Une API est-elle simplement un moyen d’écrire du code pour s’interfacer avec d’autres programmes? Oui. Pourquoi les API suscitent-elles tant d’enthousiasme alors? Avoir des conventions sur la façon d’écrire un logiciel pour que quelqu’un puisse le brancher à son propre logiciel est une chose. APIs comme un aspect de la conception de logiciels est un sujet classique en informatique, mais nous ne sommes pas concernés par cela ici.

Les API que nous allons discuter concernent la communication entre des ordinateurs distants, dans un contexte professionnel. Pour mieux comprendre leur pertinence commerciale, il est utile de rappeler un bref historique des API:

Les entreprises qui ont besoin d’échanger des données n’ont rien de nouveau. Fabricants, détaillants, banques, …​ ils ont besoin d’échanger des informations à intervalles réguliers.

Envoi de factures, réception de reçus pour la marchandise et de nombreux autres documents administratifs générés dans le cours des affaires.

Ces reçus, factures …​ peuvent être imprimés et envoyés par la poste (cette solution existe toujours bien sûr).

Avec l’évolution de l’informatique dans les années 1970 et 1980, un nouveau système d’échange de données et de documents est apparu: l’échange d’informations par ordinateur : l’Échange de données informatisé (EDI).

EDI n’est pas un échange de pièces jointes dans les emails ou via un transfert de fichiers sur un site web, car les emails et les sites n’existaient pas à l’époque! (Les courriels et le Web ont été adoptés par les entreprises à la fin des années 1990).

Au lieu de cela, l’échange de données via EDI consistait à utiliser des outils électroniques de transmission par l’équivalent d’une ligne téléphonique (comme le fax mais encore plus compliqué). Ce système d’EDI était complexe et lourd pour les raisons suivantes :

Pour résumer : les EDI sont fragmentés, compliqués à mettre en œuvre, lents à évoluer, chers, et limitent la communication à un «club» de partenaires qui ont accepté de l’utiliser.

Les EDIs existent toujours, en particulier dans les grandes industries B2B comme le transport, mais elles ont perdu en popularité dans l’économie en général parce que …​ les API sont arrivées.

À la fin des années 1990 et au début des années 2000, Internet et le World Wide Web se sont considérablement développés. De plus en plus de serveurs dans différentes parties du monde ont besoin d’échanger des données entre eux, ce qui nécessite d’utiliser des interfaces plus pratiques que les EDI.

Il devenait de plus en plus commode de définir des conventions simples et universelles que tout le monde pouvait apprendre et suivre pour standardiser ces échanges, gratuitement et facilement. C’est ce que font les web API. Elles sont aussi souvent appelées:

Une web API étend la logique des API que nous avons vues au début de ce document, à la communication logicielle via le web. Pour rappel, une API est une convention suivie lors de l’écriture d’un logiciel, rendant ce logiciel disponible pour d’autres logiciels.

Une web API est une API qui permet à deux logiciels de communiquer via Internet. Ils n’ont pas besoin d’être installés sur le même ordinateur.

Deux conventions d’API web populaires ont émergé dans les années 1990 et ont rivalisé en terme d’adoption :

Les API REST sont finalement devenues les plus répandues, car elles utilisent les mêmes principes simples que les pages Web utilisent pour être transférées sur Internet (le protocole "http" que vous voyez dans les adresses de pages web). C’est pourquoi les API sont souvent appelées API REST, présentées dans cette vidéo pédagogique.

En 2000-2010, il est devenu de plus en plus facile et naturel d’adopter la convention REST pour mettre son logiciel et ses données à la disposition d’un autre ordinateur via Internet. Cette évolution simple pour faciliter l’interopérabilité a eu des effets immenses :

Une API transforme un logiciel fermé en quelque chose qui peut être branché sur n’importe quel autre ordinateur ou objet, à condition qu’il soit connecté à Internet.

Par exemple, les API ont été un facteur clé de succès pour SalesForce au début des années 2000. SalesForce, créé en 1999, a réalisé un chiffre d’affaires de 8,39 milliards de dollars en 2017 :

Salesforce prend une commission sur les ventes réalisées par ces applications tierces hébergées sur Force.com, mais plus important encore, la plate-forme crée un écosystème d’applications et de développeurs autour des produits Salesforce, ce qui rend difficile pour une entreprise cliente de passer à un produit différent.

Grâce à l’API, il est désormais plus facile d’ajouter des blocs logiciels et de créer de nouvelles applications, même si ces blocs logiciels proviennent de différents pays ou industries.

À titre d’exemple extrême : la police australienne de Victoria a déployé un projet de reconnaissance des véhicules volés grâce à la reconnaissance vidéo des plaques d’immatriculation des voitures circulant dans la rue (les véhicules volés se voient immédiatement reconnaître leurs plaques d’immatriculation). C’est un projet de 86 000 000 $.

Un individu a répliqué ce projet avec seulement 57 lignes de code et une webcam. Comment? Simplement parce qu’il a pu utiliser un logiciel existant pour la reconnaissance de plaques d’immatriculation, disponible en tant qu’API, au lieu de le re-développer par lui-même.

Un autre exemple significatif est l’application imaginée par Pieter Levels: un service mondial de livraison de bagages, porte à porte, conçu sans une ligne de code:

Ce service est conçu en organisant plusieurs sous-services, qui se coordonnent en communiquant via leurs APIs.

Comment la communication entre services est-elle possible, en pratique ? Qui "orchestre" ces services? Pieter Levels utilise Zappier, un service dont le rôle est de faire communiquer ces APIs entre elles.

Au-delà de ces exemples frappants, le leçons à tirer sont:

Les entreprises et les organisations publiques possèdent de nombreuses bases de données d’un grand intérêt commercial. L’utilisation de ces ensembles de données peut être gratuite (quand l’utilisateur est développe un projet à but non lucratif par exemple) ou monétisée si l’utilisateur est une entreprise.

Sans APIs, les ensembles de données peuvent être rendus disponibles publiquement sous forme de docs (par exemple, tableurs Excel) à télécharger mais ce n’est pas pratique (essayez de télécharger quelque chose comme all_train_schedules_2000_to_2017.xls!).

Prenons l’exemple d’une entreprise de transport comme la SNCF française qui trouve intéressant de publier les noms des gares, les horaires des trains, les informations en temps réel sur le trafic ferroviaire, etc. car elle pourrait être utilisée par d’autres entreprises pour construire de nouveaux services: comment faire?

L'Open data désigne ce mouvement pour rendre les jeux de données accessibles à un large public, et les API web ont été un ingrédient technologique clé dans ce mouvement.

Une entreprise peut créer ses propres APIs pour "projeter" ses services plus loin et plus fort que par la simple interface "page web". Comment faire?

Ici il faut brainstormer, avec deux repères à garder en tête. Ces deux repères ou "balises" sont exemplifiées par ce qu’a vécu Pieter Levels, un entrepreneur hollandais qui se spécialise dans la création de plateformes web au service des personnes qui travaillent à distance ("remote workers"). Il a créé:

Pieter Levels a mis en place des APIs pour que des utilisateurs puissent accéder ("consommer") ces deux services, avec des résultats bien différents:

La capture d’écran ci-dessous résume le contraste entre les deux situations : bien que dans les deux cas il s’agisse d’ouvrir ses données via une API, le résultat est opposé :

Il faut donc une appréciation fine des usages que l’ouverture d’une API permettra de stimuler. Un des effets les plus vertueux est celui d’une "caisse de résonance" : en réutilisant notre contenu pour leurs propres objectifs , les utilisateurs de l’API vont sans le vouloir faire la promotion de notre contenu, ce qui en renforce l’efficacité.

Pour découvrir de nouvelles API, ou pour faciliter la découverte de vos API, allez sur https://apilist.fun/, https://apislist.com/ ou https://publicapis.io. En effectuant une recherche sur ces sites, vous trouverez des APIs fournissant des services commerciaux, ou des APIs d’un genre amusant ou absurde.

Pourtant, de nombreuses API publiques ne sont pas listées sur ces sites. Dans ce cas, une recherche google du type "info dont j’ai besoin + API" est aussi un bon moyen de savoir si l’API que vous recherchez existe. Intéressé-e par les observations d’oiseaux? Il y a une API pour ça.

Les API sont devenus essentielles à l’économie. En conséquence, un grand nombre de services associés aux API ont été développés pour répondre à tous les besoins des entreprises qui les utilisent :

Mehdi Medjaoui et APIscene publient un panorama mis à jour et interactif des entreprises actives dans l’écosystème des APIs:

(ou téléchargez la version haute résolution de ce poster ici)

Retrouvez le site complet : ici.

Clement Levallois

Découvrez mes autres cours et projets : https://www.clementlevallois.net

Ou contactez-moi via Twitter: @seinecle