mercredi 16 novembre 2011

Un nouveau métier : distributeur d'API

Du petit commerçant au distributeur

De nombreuses web-api fleurissent quotidiennement sur le net, il est aujourd'hui possible de construire des applications sophistiquées en agrégeant uniquement des fonctionnalités distantes.

Dans ce contexte, un distributeur d'api propose à ses clients un accès à des web-services conçus et hébergés par des tiers.

L'utilisation, par une équipe de développement, de nombreux fournisseurs d'api est l'équivalent de la tournée des commerçants de centre-ville : il faut du temps pour les sélectionner et si l'un de vos fournisseurs habituels n'a pas le produit recherché, il vous faut changer le menu.

A l'inverse, Le passage dans l'hypermarché (physique ou virtuel) vous permet de retrouver rapidement à un seul endroit l'intégralité des produits dont vous avez besoin.

Quels sont les avantages de la notion de distributeur dans le cadre de l'utilisation d'api ?

Tout d'abord, le site du distributeur permet d'avoir sous les yeux à un seul endroit un vaste ensemble de fonctionnalités sans avoir à parcourir Internet pour découvrir les offres correspondant à ses besoins.

La gestion se simplifie : une seule facture détaille les différentes consommations, un tableau de bord unique permet de mesurer et visualiser de manière cohérente les différents usages.
De la même manière, il n'y a qu'une seule gestion des accès et des autorisations, ce qui facilite grandement la mise en oeuvre et l'exploitation des applications.


Amener de la valeur ajoutée
Pour justifier son existence et au delà de la facilité d'accès aux fonctionnalités, le distributeur doit amener de la valeur ajoutée à l'ensemble des api proposées. Il peut, notamment, harmoniser les modes d'appel des services en proposant des conventions d'utilisation identiques pour toutes les api et masquer les différences techniques entre les différents fournisseurs.
En traitant tous les appels avant de les aiguiller vers le fournisseur final, le distributeur peut aussi dynamiquement convertir des formats de données et éviter ce travail au client.

Gain de temps
L'un des apports majeur du distributeur d'api est d'amener un gain de temps sur l'intégration des différentes fonctionnalités.

L'harmonisation des conventions techniques a pour effet une diminution importante des temps d'intégration. En effet, le développeur n'a plus besoin de se plonger dans les arcanes des systèmes de chaque fournisseur mais au contraire utilise un seul jeu de conventions cohérent.

Le distributeur doit aussi proposer des facilités sur les aspects multitenants.
Le client ne doit pas avoir à gérer les multiples aspects de configuration, de copie des données pour gérer ses environnements de test, de préproduction, de production. Le gain de temps est, sur ce sujet, également considérable.

Interactions
La position d'intermédiaire entre le client et le fournisseur du service final permet d'ajouter très simplement des mécanismes d'interaction entre les services. Lorsqu'une api est utilisée, un évènement est généré. Ce dernier peut être signalé par le biais d'un "webhook" (une url) à un autre
service ou à l'application cliente.

Interlocuteur unique
L'équipe de développement du client ne s'adresse plus qu'à une seule équipe de support, avec des engagements identiques, sur l'ensemble des apis du catalogue. Plus de temps à passer à traquer les messages des différents fournisseurs avec chacun leur temps de réactivité et leur délai propre.
Sur ce point également, la centralisation entraîne un gain de productivité.

Des services orientés client et non pas produit.

Chaque fournisseur d'api présente (ou devrait présenter) une documentation indiquant comment utiliser son produit (son api) de manière claire et pédagogique. Malheureusement, le format, la langue et les technologies utilisées dans les exemples peuvent être très différentes d'un fournisseur à un autre.
Un distributeur s'attachera à faciliter globalement l'agrégation des api à ses clients en fournissant de l'information et du support personnalisés.

La meilleure offre au meilleur prix
La nature désincarnée du produit permet au distributeur de changer dynamiquement le fournisseur d'un service en fonction du contexte de l'appel.
Par exemple, si l'on considère un service d'envoi de SMS, pour une qualité de service donné, le distributeur choisira le fournisseur en fonction du pays et du réseau du destinataire du message pour obtenir le prix le plus avantageux.
Le client peut ainsi utiliser le fournisseur le plus adéquat de manière totalement transparente.
La même approche permet aussi d'utiliser des fournisseurs proposant des SLA différentes pour un même service rendu. Typiquement, avoir des SLA différentes pour les environnements de développement et de production, peut amener des économies substantielles.

Dépendance et réversibilité
L'une des objections principales que l'on pourra présenter à l'encontre du distributeur est la génération d'une dépendence unique beaucoup plus critique que dans l'accès aux différents fournisseurs de manière
individuelle.

Cette dépendance n'est pas aussi forte qu'on pourrait le croire au premier abord.

Tout d'abord, d'un point de vue technique, il n'y a pas (obligatoirement) de point centralisateur pour traiter toutes les requêtes des clients avant de les redistribuer vers les fournisseurs de services. L'architecture la plus commune se rapproche plutôt des CDN, tel Akamai, où les points d'accès sont distribués au plus près des fournisseurs d'accès pour être le plus proche possible des
utilisateurs. De la même manière, le distributeur va placer ses web-services chez les hébergeurs à côté des applications clientes pour diminuer au maximum les temps de transit. Cette multiplication des points d'accès chez les différents entreprises d'hébergement induit, de plus, un mécanisme de résilience
naturel en cas de défaillance de l'un d'eux.
Même si des éditeurs persistaient à revendre eux-mêmes l'accès à leurs api, ils ne pourraient pas bénéficier de l'ensemble des points d'accès placés chez les hébergeurs par les distributeurs. L'effort serait trop grand pour chaque acteur individuellement.

D'un point de vue contractuel ensuite, il est assez facile de prévoir des clauses de réversibilité si le distributeur venait à être en difficulté.
La nature de la prestation du distributeur permet de pouvoir aisément mettre à disposition des clients une "appliance" embarquant toutes les fonctionnalités d'accès aux services à la manière d'un proxy.
Ainsi le client pourra gérer son propre point d'accès et conserver tous les avantages de l'intermédiation si le distributeur venait à faire défaut.

Mode direct, mode indirect
L'arrivée massive de web-api en tout genre est en train de bouleverser l'approche du développement. Ce changement technique implique également de grandes modifications dans l'approche commerciale.

La revente d'utilisation d'api permet une intermédiation purement virtuelle organisée autour de services en ligne. Cette démarche se rapproche plus de l'activité classique de la grande distribution que du VAR traditionnel :

- catalogue : linéaire de la grande surface, tout est disponible au même
  endroit
- support unifié : service après vente
- achat en gros auprès des fournisseurs et revente au détail
- gestion de la logistique (point d'accès au plus près du consommateur)
- notion de marque de distribution, gage de qualité

Ce glissement à venir du mode de vente direct au mode indirect pour les applications Saas et les api correspond à une meilleure redistribution des efforts. Aujourd'hui les éditeurs (et les startup en particuliers) doivent s'impliquer autant dans la R&D pour offrir des applications innovantes que dans
la commercialisation de leur produit pour générer les revenus indispensables au bon fonctionnement de l'entreprise. Pour de petites pme, il est difficile de progresser au même rythme sur tous les fronts. Pour des raisons de ressources, de culture, de maturité, l'une des activités se fait souvent au détriment de l'autre.

Si vous souhaitez prendre contact : http://www.faascape.com/contact/contact.html

Xavier Milliard

http://www.faascape.com

7 commentaires:

  1. Il manque un aspect important à cette analyse dans la prise en compte des besoins des clients : faciliter l'utilisation des APIs par le client dans son/ses langages de programmation.
    Le distributeur doit donc :
    - soit être ancré sur un langage de programmation particulier sur lequel il a une expertise et pour lequel il propose une forte intégration
    - soit être profondément acmeiste (voir http://acmeism.org) et proposer une très bonne intégration des APIs dans de multiples langages, chose que le fournisseur initial n'a peut-être pas pris en compte. Des spécifications acmeistes des APIs telles que SPORE (https://github.com/SPORE) peuvent aider pour cela.
    La valeur ajoutée du distributeur est alors la validation du fonctionnement avec divers langages, divers frameworks...

    RépondreSupprimer
  2. Vous avez tout à fait raison, la facilité de mise en oeuvre des apis est un élément essentiel.

    Votre analyse sur les deux approches relatives aux langages est intéressante.

    J'aurai personnellement tendance à préférer une voie neutre quand à l'utilisation d'un langage donné (et donc à encourager le distributeur à complémenter le travail de l'éditeur pour boucher les trous).

    D'une manière plus générale, il faut, me seble t-il, privilégier la simplicité plutôt que l'empilement de couches techniques et de librairies qui nuisent à :
    - la rapidité de l'intégration
    - la dépendance par rapport aux fournisseurs / distributeurs

    A ce titre des approches plus simples comme REST me séduisent plus que des frameworks complexes autour de SOAP.

    L'exemple de SPORE comme élément intermédiaire neutre est également un point intéressant qui pose la question des standards.

    RépondreSupprimer
  3. Ce modèle est intéressant ; espérons toutefois que les abus de l 'hyper-distribution de biens alimentaires ou de consommation ne soient pas propagés dans un tel modèle de distribution d'API :
    - rétro marges
    - difficultés pour les "petits" à se faire référencer dans les rayonnements. (Ce à quoi on pourrait objecter que la taille du rayonnement virtuel d'API a une longueur infinie, même si la mise en avant est aussi importante dans le monde virtuel que dans le monde physique).

    RépondreSupprimer
  4. Ce commentaire a été supprimé par l'auteur.

    RépondreSupprimer
  5. @Olivier Merci pour ce commentaire.

    Concernant la taille des fournisseurs, je pense qu'elle a moins d'importance
    que dans le monde physique (quoique ...). Il faut qu'un fournisseur puisse
    respecter les critères de qualités (SLA) requis par les distributeurs, mais les technologies cloud doivent théoriquement permettre à de petits acteurs de pouvoir faire évoluer leur plate forme sans investissement préalable donc avec plus de facilité que dans une chaine de production classique.
    Aujourd'hui les producteurs d'api (en grande majorité états-uniens ...) sont
    souvent de petite taille.

    Autre sujet de tracasserie, les questions de délais de paiement doivent nettement être diminués par les techniques paiement à l'usage, de compte prépayé, d'abonnement, ...

    Pour la question des marges arrières, je suis d'accord sur la nécessité
    d'éviter ce genre de pratique, mais de mon point de vue, c'est surtout une
    affaire d'état d'esprit.

    En résumé, il s'agit surtout d'un nouveau métier à inventer, modèlons le à
    notre guise ! Avis aux amateurs

    RépondreSupprimer
  6. Merci Xavier pour cet article très intéressant et clairement visionnaire.

    Je le qualifie de visionnaire car de mon point de vue même si le nombre d'APIs Web ouvertes ou publiques est en train de croître de manière extrêmement significative, la prolifération d'APIs Web est n'est pas encore une réalité (http://blog.programmableweb.com/2011/11/15/the-curious-case-of-the-unofficial-apis/?utm_source=twitterfeed&utm_medium=twitter&utm_campaign=Feed%3A+ProgrammableWeb+%28ProgrammableWeb%3A+Blog%29).

    Je pense donc que nous sommes encore loin du modèle de business que vous décrivez. Je pense qu'avant d'arriver à un modèle de revendeur d'API nous verrons apparaître d'abord des revendeurs/intégrateurs de différentes solutions SAAS.

    Par ailleurs je suis surpris du commentaire d'Olivier Mengué quant aux spécificités et problèmes de langage: les APIs Web dont la grande majorité aujourd'hui a un format REST XML ou REST JSON sont agnostique du point de vue langage de programation.
    Evidemment, fournir des SDK et autres librairies facilitant l'utilisation d'une API donnée dans un Framework particulier est un plus mais le langage de prog ne devrait globalement pas être un problème.

    Par rapport à la visibilité des petites APIs, je recommande définitivement à ces dernières de s'enregistrer sur ProgrammableWeb qui est le listing leader du marché en terme d'APIs publiques.

    RépondreSupprimer
  7. @Guillaume
    Merci de ce retour flatteur !
    Comme vous le signalez très justement, http://programmableweb.com est une ressource incontournable, à consulter régulièrement.

    Votre remarque sur la maturité de l'approche généralisée de l'usage des API est tout à fait juste mais les choses avancent très très vite et il est tout à fait possible (voire probable) de voir pas mal d'initiatives importantes sur ce sujet dans des délais relativement court (2012 ?)

    N'hésitons pas à évangéliser sur le sujet car c'est vraiment un moyen efficace pour une PME de diffuser des produits technologiques ou d'intégrer des fonctionnalités à son SI très rapidement et à peu de frais.
    Pour des entreprises de taille supérieure les apis permettent d'interagir simplement avec ses partenaires (clients, fournisseurs). D'ailleurs un billet à venir traitera de l'usage des api comme outil d'intermédiation.

    Concernant le commentaire d'Olivier, je comprends sa remarque car même si l'usage de REST est complètement indépendant des technologies de l'application cliente, il n'en reste pas moins qu'il faut utiliser les librairies de l'environnement pour manipuler les requêtes http, sérialiser JSON, etc.
    Même si ce n'est pas très compliqué cela rajoute un peu de difficulté et tout le monde rajoute une petite couche pour simplifier l'usage des requêtes REST au niveau métier.
    Tout est une délicate histoire d'équilibre entre la dépendance à une technologie, l'effort à produire, le coût de la maintenance, etc.

    Sur ces sujets, les distributeurs peuvent apporter un peu de valeur en proposant par exemple des sdk libres comme une mince couche intermédiaire.

    Mais attention parce que, comme me le rappelait un collègue, plus il y a de couches et plus il y a de fuites ;-)

    Xavier

    RépondreSupprimer