Les défis de l’interconnexion des systèmes (1/2) : l’économie des API

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…

apidays01

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.

APIdays 2015. Tapis Rouge. Paris. 8 décembre 2015 : Cyril Vart
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.

APIdays 2015. Tapis Rouge. Paris. 8 décembre 2015 : Mark Boyd.
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.

openbankproject
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 ?

À lire aussi sur internetactu.net

5 commentaires

  1. Merci , article très intéressant et comme toujours avec une mise en perspective éclairante.  » 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. « -> j’aurais adoré voir ce raisonnement déroulé en direct, les slides ne sont pas très explicites.

  2. C’est difficile de conjecturer sur la progression du nombre d’APIs disponibles et utiles, et donc difficile de prédire un avenir où on pourra tout sous-traiter à des APIs. Certains vont disparaître, d’autres seront rendus obsolètes. Au minimum il y a le coût des serveurs. Parfois l’API requiert des données mises à jour, comme Yelp. Parfois aussi l’API est retiré pour des questions de droits ou de stratégie. Il est aussi possible, quoique moins probable, que la méthode d’accès à l’API (par exemple XML-RPC) ne soit plus compatible avec le dernier framework logiciel à la mode. Autant de raisons pour réduire l’éventail des APIs disponibles, le tout dans un éco-système où les besoins changent régulièrement.

    Autre problème : je travaille régulièrement à partir d’APIs. Quand on fait une appli mobile qui manipule de la vidéo ou du son, on ne peut pas se permettre d’empiler des APIs, et ce à cause de la vitesse limitée du réseau, et dans certains cas du coût des serveurs intermédiaires. Je ne suis pas sûr que ce problème soit résolu à moyen-terme, car tandis que le réseau est de plus en plus rapide, le volume des images/vidéos/sons augmente tout autant.
    Le son (notamment la voix) et les images, c’est une grosse partie des APIs.

  3. @Sophie : sur l’interconnexion des différentes API, les explications de Saul Caganoff étaient assez techniques (et j’avoue n’avoir pas tout compris du fait du niveau technique). Par contre, une autre présentation t’aurait intéressé, que je n’ai pas exploité dans mes articles. Celle d’Isabelle Reusa de la Réunion des musées nationaux (RMN), qui revenait sur le lancement d’une plateforme par la RMN, légitimement controversée, puisque la RMN exploite les images d’oeuvres dans le domaine public (ce que beaucoup, nomment avec raison le copyfraud, même si c’est également l’une des principales activités de la RMN). La RMN dispose d’un énorme fond d’images numériques d’oeuvres provenant de plus de 1000 musées français. Ils ont créé un site pour vendre ces images et les mettre à disposition ainsi que des API pour les distribuer.

    Isabelle Reusa, en charge de ce projet, posait des questions intéressantes sur l’accès pour la recherche et l’éducation, sur l’intégration de données dans le site de la RMN, sur la diffusion des images et la réutilisation (avec les métadonnées)… Ces réflexions ont donné naissance à deux sites distinct : l’un pour la vente et l’autre pour la distribution (exemple avec la Gare Saint Lazare par Monet dans une mise à disposition sous deux versions différentes pour des usages différents – un et deux – depuis les mêmes données et web services). Le développement a permis d’enrichir les données, de les réorganiser, d’améliorer les images… Le service à ouvert il y a un mois ou deux… Reste à voir quels nouveaux usages et quels modèles économiques cette mise à disposition va permettre de faire émerger. La RMN travaille avec des musées désormais pour que ceux-ci puissent réutiliser les images des oeuvres qu’ils accueillent.

    @Hadrien : oui, la question de la documentation des accès, des stratégies que tu évoques est essentielle. A ce que j’en ai compris de nets progrès ont été fait pour améliorer le dialogue entre fournisseurs de services et développeurs, même si c’est encore loin d’être parfait. La documentation des interfaces est souvent imparfaite… Et cela semble un vrai enjeu de les améliorer. Effectivement, beaucoup ont tout de même pointé les limites d’une intégration multicouche, plus difficile à réaliser qu’à clamer.

  4. On peut imaginer, au vu de cette intéressante mise en perspective, que le futur verra naître – grâce notamment aux prouesses de la programmation – le Grand Agrégateur (il agrège les agrégateurs d’agrégateurs, etc.). Interconnecte tous les domaines, fluidifie toutes les transactions, etc. Sorte de Big Friend omniscient, votre SVA – Seul Véritable Ami. Il connaît presque tout de vous, de vos contacts, et est simple d’utilisation (contrairement à aujourd’hui où il faut jongler, s’essoufler entre des applis de faible durée de vie, toujours changeantes). Espérons que SVA ne soit pas doué de mauvaises intentions à votre égard…

    Mais bon, on n’y est pas encore.

  5. Pouvez-vous apporter quelques précisions sur les « 40% du business de la photo numérique » récupérés par Walgreen grâce à l’ouverture de leur API ?

    Il s’agit du business de l’impression de photos numériques ?
    Quelle est la source ?

    Merci d’avance.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *