API : de l’artisanat à l’industrialisation (1/2)
Twitter, Facebook, Uber… tous les jours vous utilisez des APIs, peut-être sans le savoir : Programmable Web en recense plus de 16 000. Pour faire le point sur les APIs et leur rôle dans la transformation digitale de l’économie, nous avons rencontré Mehdi Medjaoui fondateur d’API Days (voir notre compte-rendu sur API Days Paris) et co-fondateur de OAuth.io.
À quoi servent les API ? Comment évolue le marché? Quel changement culturel représente l’ouverture des APIs ? Nous aborderons tous ces sujets dans la première partie de cette interview.
Quelle est ta définition d’une API ? À quoi ça sert ?
Une API c’est une interface logicielle qui permet à deux sites web, deux applications ou deux objets connectés de communiquer et d’interagir de manière automatisée et programmable. Cela permet d’automatiser les interactions entre logiciels.
Les APIs existent depuis plus de 20 ans, pourquoi cet engouement aujourd’hui? Comment ont-elles évolué ?
Les premières APIs étaient des APIs logicielles destinées à interagir avec le système d’exploitation. Elles permettaient aux programmes d’interagir ensemble, mais n’étaient pas connectées sur Internet. Depuis l’arrivée du Web, l’API permet à deux programmes qui ne se connaissent pas d’interagir ensemble à travers le réseau. La grande révolution des APIs, c’est d’avoir un fonctionnement en “double aveugle” : elles sont conçues et publiées sans connaître leur utilisation finale, et consommées sans connaître tout de leur producteur. C’est le Web et son ouverture qui ont permis cette révolution. Aujourd’hui d’ailleurs quand on parle d’APIs, il s’agit principalement de Web API : l’API Twitter, Facebook, Uber… Il existe encore des API logicielles, mais la tendance du marché et de l’industrie des APIs est orientée sur les APIs web qui ont un modèle d’affaire lié au technologies cloud et SaaS (Software-as-a-service).
En quoi les APIs sont nécessaires à l’automatisation ?
Le principal enjeu de l’automatisation, selon moi, c’est d’économiser des ressources en faisant réaliser par le logiciel des tâches jusque là accomplies par des humains. L’inconvénient de l’automatisation, si elle est mal faite, c’est qu’on risque aussi d’automatiser les erreurs :
L’erreur est humaine, mais pour provoquer une vraie catastrophe, il faut un ordinateur
(Loi de Murphy, observation de Turnaucka).
Comme les APIs proposent des interfaces pour communiquer de façon automatisée, il est essentiel de comprendre exactement les tenants et les aboutissants pour chaque partie : quelles données offre le fournisseur, pour quel usage? Et inversement, celui qui fournit un service via une API doit savoir ce qui sera utilisé en sortie de l’API. Comme le fournisseur n’a plus d’information après la sortie de l’APIs, il faut pouvoir cadrer les choses, permettre une automatisation contrôlée. Publier des interfaces aux limites bien définies, et consommer des interfaces sécurisées et stables : c’est que j’appelle le digital supply chain management.
La RATP qui ouvre l’accès à ses données via une API, c’est la preuve que le sujet est dans l’air du temps ?
La SNCF propose également son API, le gouvernement ouvre api.gouv.fr et centralise les API des administrations, France Connect offre un login unique pour toutes les administrations… donc oui, l’heure est aux APIs ! Pour en revenir à la RATP, cela répond à des impératifs d’ouverture, et d’adaptation aux changements rapides de l’écosystème. Comme il y a plus d’experts, de développeurs et de partenaires à l’extérieur de l’entreprise, il faut aujourd’hui fonctionner en entreprise étendue, c’est une question de survie. Toute la question est de savoir à quel degré on s’ouvre : comme tout organisme vivant trop ouverte l’entreprise meurt, trop fermée elle n’évolue pas. On parle beaucoup des start-ups qui menacent les grandes entreprises, mais en réalité c’est une question de vitesse : “Ce ne sont pas les petits qui mangent les gros, mais ce sont les rapides qui mangent les lents.”
Les APIs permettent en interne d’avoir une certaine agilité de développement, et en externe de bénéficier pleinement des réseaux de ses partenaires pour gagner en vélocité sur leur cycles d’innovation, ouverte notamment. C’est pour cela que des sociétés comme la RATP ouvrent leur APIs aujourd’hui.
Est-ce que cela ne va pas à l’encontre de la culture du secret pratiquée durant des décennies par les entreprises ?
Pendant des années, Gartner et tous les autres ont professé que la donnée était le nouveau pétrole, à protéger jalousement et à garder comme avantage concurrentiel. Aujourd’hui les entreprises doivent donc entreprendre un changement culturel profond et comprendre que partager leurs données avec un écosystème sous contrôle, c’est les enrichir plus que jamais et à grande échelle. Ce qu’ont pu faire des sociétés comme Google avec Adwords ou GoogleMaps ou bien Facebook, Salesforce, Ebay/Paypal etc… Car ce n’est pas la donnée qui est en jeu, mais son asymétrie : ce qui compte, c’est de disposer d’une donnée plus précise que le marché. Penser son entreprise et ses produits en tant que plateforme, via l’ouverture d’APIs bien managées permet d’accumuler de la donnée pour de mieux comprendre le marché grâce à de meilleurs algorithmes, de meilleurs outils de pricing, d’identifier de nouveaux modèles d’affaire et à terme d’améliorer sa compétitivité. Qui plus est, récolter de la donnée coûte cher. Ouvrir des APIs permet d’utiliser tout l’écosystème pour capturer des données en coopération.
En quoi la donnée est un facteur de compétitivité ?
Nous sommes dans une économie où le leader du marché emporte tout. Prenez l’exemple d’AWS ou de Stripe, la façon dont les appstores fonctionnent, ou les classements des moteurs de recherche… il y a une concentration sur les premiers. Qui veut être en seconde page de recherche Google ? Dans ce contexte, le moindre gain de compétitivité qui vous fait passer devant votre concurrent peut faire toute la différence. Dans un monde plat (Friedman), connecté, tout le monde n’est qu’à une URL de son prochain client ou partenaire, le coût marginal de production de contenu digital tendant vers 0, il n’y a plus de barrière à l’innovation et à la disruption. A l’instar des startups, avec la démocratisation de l’infrastructure et du savoir, n’importe qui peut lancer un produit avec un capital relativement faible. La différence se fait sur l’obsession du design du produit, sur la capacité à comprendre le client, à innover et à exécuter sa prise de position stratégique. Je pense que les APIs sont la pierre angulaire de ce nouveau marché.
Pourquoi un événement dédié aux API ?
Plus on automatise, plus on multiplie les succès ou potentiellement les catastrophes ! Comme le disait Bernard Stiegler lors des APIDays l’an dernier, automatiser demande de remettre de l’esprit, de l’intelligence dans le process. C’est aussi le propos de Paul Graham, l’un des investisseurs les plus influents de la Silicon Valley (pionnier du mouvement des accélérateurs de start-up avec Ycombinator). Alors que le but final d’une startup est d’automatiser un process business à l’échelle en acquérant des clients à coût marginal nul, il préconise pour l’exercice de refaire à l’occasion certaines étapes du processus manuellement (Do things that don’t scale). Cela permet ré-assimiler le mécanisme et de le ré-automatiser avec plus de productivité et d’intelligence par rapport au processus commercial.
Et les APIs alors? Et bien à l’ère du numérique, le but ultime des APIs est d’automatiser les processes business, les processes IT et les processes consommateurs via des interfaces programmables.
Dans ce contexte, APIDays est issu du groupe API-Craft, qui visait à ramener une notion d’artisanat au coeur des API : une API doit être pensée prototypée, craftée, testée, améliorée avant d’être passée à la phase industrielle, deployée dans le monde entier pour des centaines de milliers d’applications clientes. Car plus le logiciel s’industrialise (API, containers, déploiements en continu…), plus il faut apporter d’intelligence, de design et de métier lors de la phase de conception afin que l’infrastructure et son design puisse évoluer d’une manière résiliente, sans casser ou régresser. D’où l’idée de cette conférence, qui a pour objectif de sensibiliser à l’importance du design et de la documentation d’APIs, qui sont des éléments critiques de la phase d’automatisation. L’automatisation ne peut être un succès qu’au dessus d’une couche d’intelligence bien pensée.
Est-ce que la documentation est une façon d’assurer le succès de son API ?
Deux courants de pensée s’opposent sur ce sujet. Pour certains, la documentation est un bug : un jeu vidéo ou un produit bien conçu peut être pris en main facilement, sans documentation et telle doit être une API, intuitive.Mais d’un autre côté, comme dans un contexte d’automatisation, nous avons besoin de documentation. Il faut que les utilisateurs comprennent exactement le modèle de l’API, et son fonctionnement, sa logique, ses paramètres spécifiques. Personnellement, je pense que l’API doit être assez simple et explicite pour être prise en main facilement sans documentation. Mais quand on passe à l’intégration, la documentation doit permettre de se projeter dans le produit, et de comprendre ce qui peut être accompli avec l’API. Aujourd’hui beaucoup d’experts API pensent qu’une API n’est bonne que par la qualité de sa documentation. Croire que son API est auto-descriptive est une erreur. Comme l’a écrit Bernard Werber :
Entre ce que je pense, ce que je veux dire, ce que je crois dire, ce que je dis, ce que vous avez envie d’entendre, ce que vous entendez, ce que vous comprenez… il y a dix possibilités qu’on ait des difficultés à communiquer. Mais essayons quand même…
Une API, c’est exactement ça ! Il y a énormément de biais d’interprétation possibles, et la documentation sert à réduire ces biais. Pour en savoir plus sur la documentation d’APIs nous avons sorti un rapport sur le sujet à votre disposition au téléchargement gratuit.
Dans la prochaine partie de cette interview, nous aborderons les tendances actuelles des API, les technologies, les microservices, l’automatisation et enfin les défis posés par l’IoT.