Les interfaces de programmation (API) et les systèmes de logiciels comme services (SaaS) permettent à nos systèmes techniques de discuter entre eux, aux données et aux programmes de se croiser, de s’alimenter, de se féconder les uns les autres… Aller faire un tour à la 3e édition des API days qui se tenaient récemment à Paris était l’occasion de tenter de saisir, derrière le discours très commercial et technique qu’on pouvait y entendre, les ambitions et les questions éthiques que se posent les développeurs et ingénieurs qui interconnectent nos systèmes techniques. Décodage…

Vers une économie basée sur les API

Cyril Vart du cabinet de conseil en transformation numérique Faber Novel est venu présenter la dernière édition de Gafanomics, une étude annuelle, dont la première édition analysait les facteurs clés de succès des Gafa. Cette nouvelle édition, s’intéresse, elle, à en comprendre les stratégies : « comment obtenir un avantage compétitif dans une économie en réseau ? »

Pour Cyril Vart, si l’économie numérique est distribuée d’une manière globale, c’est parce que l’infrastructure construite par les grandes entreprises du numérique est basée sur les API. Nous sommes entrés dans une « économie des API », une économie basée sur la distribution de services web interconnectés. Les Gafa (Google, Amazon, Facebook, Apple…) ont construit des infrastructures basées sur des API qui leur ont donné un avantage compétitif global. Si les Natu (Netflix, Airbnb, Tesla, Uber…), ces licornes (ces startups valorisées à plus d’un milliard de dollars), croissent encore plus rapidement que les Gafa, c’est parce qu’elles ont utilisé les infrastructures des Gafa pour croître plus vite et plus rapidement que leurs prédécesseurs.

Comme l’expliquent Marc Andreessen et Venkatesh Rao dans Breaking Smart, dans cette nouvelle économie les entreprises sont organisées en réseau et utilisent les connexions et les interactions comme une source de connaissance et de performance. « Dans un monde connecté, les 3 choses les plus désirables sont les connexions, les connexions et les connexions », clame Andreessen. Pour Vart, « les Gafa ne créent pas des modèles d’affaires traditionnels, mais des graphes, des réseaux ouverts auxquels d’autres entreprises peuvent accéder ». Plus de la moitié des « licornes » utilisent les infrastructures des Gafa, leur permettant de se connecter à des réseaux qui leur donnent immédiatement un avantage compétitif. Ils accèdent aux magasins d’applications leur permettant de se passer d’inventer leurs solutions de distribution, aux services de gestion d’infrastructures dans les nuages d’Amazon (les fameux Amazon Web Services, l’infrastructure à la demande d’Amazon), utilisent les solutions de paiements mises en place par Google Wallet et Apple Pay… Autant de solutions qui leur permettent de se focaliser sur leur proposition de valeur et de se concentrer sur l’efficacité de leurs services et produits, sans avoir à se préoccuper des infrastructures…

Pour FaberNovel, pour que les entreprises développent un avantage compétitif dans cette économie des API, elles doivent acquérir des « superpouvoirs ».

Le premier consiste à développer des entreprises « magnétiques », capables de détecter, d’organiser, de gérer et d’agréger de très petites unités de valeur. Dans l’économie traditionnelle, pour le groupe hôtelier Accord par exemple, l’unité de valeur est l’hôtel dont il faut remplir les multiples chambres. Pour Airbnb, l’unité est la chambre… et encore, Airbnb n’a aucun lieu à gérer directement, toute son économie repose sur son logiciel permettant d’interconnecter les utilisateurs entre eux. L’unité de valeur de l’économie des API c’est l’interconnexion elle-même, à l’image de IFTTT, qui permet de se connecter à plus de 200 services web différents ou de Walgreens, cette entreprise qui a développé une API pour l’impression de photos, qui en quelques années a récupéré 40 % du business de la photo numérique et qui a vu naître quelques 200 applications depuis ses services web.

Le second superpouvoir c’est « l’entreprise en temps réel », c’est-à-dire le fait qu’une entreprise sache s’adapter très rapidement. Dans l’économie traditionnelle, le temps entre la décision et la production pouvait être très long à l’image de celui nécessaire entre la conception d’une voiture et la sortie d’usine des premiers modèles. Dans l’économie numérique, ce temps n’existe plus. Les évolutions se font en temps réel, en continu, à la volée, à l’image de Google Analytics, le service de mesure d’audience du web qui permet de faire évoluer sa productivité par l’analyse en temps réel de son audience.

Le troisième superpouvoir, c’est « l’entreprise infinie ». Dans l’économie industrielle, la production limite la capacité du nombre d’utilisateurs que l’on peut toucher : il faut produire un objet par utilisateur. Dans l’économie numérique, toucher un ou des millions d’utilisateurs n’a pas d’impact : acquérir un nouvel utilisateur ne coûte rien. Toucher de nouveaux marchés nécessite seulement de brancher ses API sur ceux-ci, comme le fait Uber en tissant des partenariats avec TripAdvisor, United Airlines ou Starbucks pour que leurs clients puissent commander une voiture avec chauffeur depuis leurs applications… Pour accéder à des moyens de paiements, désormais, il suffit d’utiliser une API, comme celle que propose Stripe.
 
Le quatrième superpouvoir consiste à créer des entreprises « intimes », qui reposent sur la personnalisation, comme une nouvelle forme d’hospitalité. Les services web permettent de savoir qui sont ses utilisateurs et permettent de façonner pour chacun une expérience différente selon les services qu’on leur propose. Alors que nous utilisons tous les mêmes systèmes d’exploitation sur nos smartphones, après 30 minutes d’usage, plus personne ne dispose de la même configuration, selon les applications que nous y installons et les configurations que nous leur donnons, et ce, même si l’essentiel de celles qu’on installe est souvent un peu les mêmes.

Image : Cyril Vart sur la scène des APIdays, photographié par Benjamin Boccas.

Pour FaberNovel, il faut utiliser le levier des réseaux, des API, pour développer ces superpouvoirs. Ce sont eux qui donnent un avantage compétitif, qui permettent de développer son modèle d’affaires. « La valeur d’un graphe n’est pas statique, il repose sur son activité ».

Reste qu’utiliser ces services ne suffit pas au succès ni ne vous transforme pour autant en licorne, pourrait-on remarquer. L’essentiel des startups d’aujourd’hui use des mêmes outils, sans parvenir à trouver toujours un avantage compétitif décisif. Si l’analyse est séduisante, la recette n’est peut-être pas si magique qu’elle le dit.

L’interconnexion n’est pas si simple

Nombre d’ateliers et de présentations des APIdays étaient là pour nous rappeler que l’interconnexion « totale » n’était pas si simple. Beaucoup de conférences étaient dédiées à comment résoudre des problèmes, comment interconnecter les langages de programmation utilisés, les API entre elles. Comment gérer la sécurité, les évolutions des API, les liens entre les applications, les services tiers… Comment créer des architectures fonctionnelles et évolutives, clairement documentées…

Pour l’Australien Saul Caganoff de Sixtree, à l’heure du web programmable, la grande question est de savoir comment automatiser les processus d’affaires avec les API (voir sa présentation). Pouvons-nous assembler, « composer » des entreprises depuis des services web, comme on bâtit une structure depuis des briques de Lego ?

A l’heure où toutes les solutions sont disponibles sous forme d’API, que ce soit pour gérer l’infrastructure (le stockage, le calcul, le management…), les commodités (les lieux, les profils des utilisateurs, le paiement, la sécurité…), les fonctions (les ventes, le marketing…) et ce dans une toujours plus large gamme d’industries (la santé, l’éducation, la chaîne d’approvisionnement…), la valeur des modèles d’affaires dépend de plus en plus de la façon dont on intègre et opère ensemble ces différents éléments. Peut-on construire un processus de bout en bout ? Peut-on créer une entreprise totalement depuis des API ?

Et bien ce n’est pas encore si simple, explique le développeur, malgré la grande diversité de services disponibles (voir la liste maintenue par BVP ou celle de Programmable Web). L’intégration de toutes ces solutions est délicate, notamment parce que chaque solution de logiciel comme service est construite comme une île, un silo. Si de nombreuses solutions d’intégration existent, elles ne sont pas si évidentes à mettre en oeuvre. Et le développeur de prendre un exemple fictif en tentant de construire les services d’une librairie depuis une multitude de web services, pour remplir toutes les fonctions dont le libraire aurait besoin : les ventes, la relation client, l’expédition… Si chacune fonctionne bien, toute la difficulté est encore de les coordonner entre elles.  

Pour Mark O’Neil (@TheMarkONeill) de Axway, à l’heure où tout communique via des API, il faut traiter celles-ci comme un produit et même comme le principal produit de son entreprise. L’important n’est plus le site web ou l’application… « Il faut faire de l’API First ! ». Les entreprises ne s’y trompent pas, d’ailleurs. Les plus avancées sur ces sujets recrutent désormais des gestionnaires de « produits API », chargés de construire et documenter ces plateformes de « self-services » ouverts aux développeurs et d’assurer la gestion du cycle de vie de ceux-ci.

Des services, des services… et encore des services

Pour Mark Boyd, qui a écrit une étude sur l’état des API bancaires, les gens n’ont pas besoin de banques ou de leurs sites, mais ils ont encore besoin de services bancaires. Ils ont besoin d’accéder à des services bancaires distribués, qui soient intégrés dans une multitude d’autres services.

Image : Mark Boyd sur la scène des APIdays, photographié par Benjamin Boccas.

Reste que si les services web bancaires se développent timidement, ceux-ci pour l’instant privilégient certains services au détriment d’autres… Aujourd’hui, l’essentiel des API bancaires est construit pour faciliter les échanges entre banques et seulement 20 % d’entre elles proposent des services pour le grand public. Nous sommes encore loin dans ce secteur d’avoir des magasins d’applications aussi riches et variés qu’on en trouve dans les magasins d’applications d’Apple par exemple.

Pourtant, certains s’y essayent. Ismael Chaib de Tesobe est l’un des responsables du projet Open Bank, qui vise à faire de la banque ouverte une réalité. Si en 2010, beaucoup se demandaient encore l’utilité d’avoir une API, d’ici 5 ans, toutes les banques en proposeront, estime le développeur. Confrontées à l’explosion des attentes des utilisateurs en terme de nouveaux services (notamment en solutions de paiement pair-à-pair par mobile par exemple ce que propose FidorBank), à l’explosion des compétiteurs (de sociétés qui ne sont pas des banques, mais qui proposent des services bancaires, comme Teller.io), au vieillissement de leurs infrastructures techniques (qui peinent à s’adapter aux changements) et aux nouvelles formes de régulation qui risquent d’imposer demain ces nouvelles formes d’échanges, les API apparaissent comme une solution, permettant de créer de nouveaux canaux de distribution, d’expérimenter et de développer de nouveaux modèles d’affaires.

Image : Open Bank Project.

La plupart des grandes banques se sont lancées dans des projets de plateformes API et elles sont de plus en plus nombreuses à proposer des applications, même si celles-ci sont encore peu ouvertes à d’autres services. Open Bank Project est une plateforme open source sécurisée qui propose un magasin d’application pour les banques, les développeurs et les usagers (voir ce qu’en disait Simon Redfern lors de Lift 2011). Parmi celles-ci, on trouve par exemple Savetastic qui extrait les informations de votre compte bancaire pour les comparer à des services équivalents et vous proposer des services plus économiques que ceux que vous utilisez. Ou Kinder Bank, une application pour les enfants qui permet de simplifier l’information de son compte bancaire.

C’est peut-être ce qui manquait encore dans les discours techniques de ces deux jours. Des exemples de services construits depuis des API plus que des démonstrations sur le foisonnement de l’interconnexion. Les rares services finaux qu’on aperçoit semblent finalement assez modestes, pas toujours très parlant aux utilisateurs. Pas tous, comme on le verra dans la suite du dossier. Mais on a tout de même un peu l’impression qu’entre les promesses de l’économie des API et ses réalités, il reste visiblement encore pas mal de choses à construire. Si la construction de services très imbriqués n’est pas si simples, beaucoup des nouveaux services proposés aux utilisateurs ne sont pas non plus très innovants et semblent finalement ne rien remplir d’autre que des fonctionnalités qui nous semblent à tous, utilisateurs, communes.

Hubert Guillaud

La seconde partie du dossier : Jusqu’où automatiser le monde ?