De plus en plus d’entreprises lancent leur API sur le marché. Plus ou moins riches ou innovantes en terme de services, découvrons les véritables enjeux et avantages de leur fonctionnement.
L’idée de ce sujet m’est venue suite à la conférence organisée par Viadeo en juin dernier, dans le cadre du lancement de son API. L’occasion d’inviter quelques early adopters ainsi que des experts en la matière.
Qu’est-ce qu’une API ?
C’est du code. Mais encore ? C’est un réseau de revendeurs de vos contenus. Les Application Programming Interface sont considérées comme un nouveau canal de distribution. Une entreprise met à disposition une interface, qui va permettre de faire interagir son service avec un service tiers. “Cette fonctionnalité est en passe de devenir rapidement la norme de l’expérience en ligne” d’après Viadeo.
Un cas concret que tout le monde connaît est le bouton “like” de facebook, que l’on retrouve un peu partout, et qui permet d’utiliser les fonctionnalités de facebook sans même se rendre en premier lieu sur leur site.
Les avantages que procure la mise à disposition d’une API
En gros, l’éditeur ouvre ses services à moindre effort et à moindre coût. Il touche beaucoup plus de monde et rallonge l’expérience de ses utilisateurs sur ses services. Et pour l’utilisateur, c’est souvent gratuit. Prenons l’exemple des Google maps insérées ici et là. Il s’agit d’une offre donnant-donnant qui permet à Google de proposer un service de géolocalisation, et aux utilisateurs de faciliter leur accès aux clients curieux.
Qu’est-ce que cela peut changer d’un point de vue business ?
Tout ! “Ne pas avoir d’API aujourd’hui c’est comme ne pas avoir de site internet au début du web” nous révèle le directeur marketing de 3Scale, une société qui accompagne les entreprises dans le déploiement de leurs API. Il s’agit également d’un vecteur d’innovation. Concevoir une API, c’est réfléchir à la forme que pourrait prendre son offre, proposée chez des partenaires extérieurs.
Pour l’instant ces plateformes sont surtout proposées par les réseaux sociaux qui ont la force de regrouper un grand nombre d’utilisateurs et de données. Par conséquent, leurs contenus représentent une mine d’or pour les sites de e-commerce, recrutement et autres. Mais de plus en plus d’acteurs du web comprennent l’intérêt de ce nouveau mode de distribution de l’information. Certains se tournent également vers la monétisation d’une offre en fonction du nombre de visites ou d’utilisations du service.
Avec ces informations, il ne vous reste plus qu’à imaginer votre propre API avec des objectifs clairs, un service innovant et des clients potentiels. Une démarche de distribution classique finalement !
Crédits image: ebay partner workblog
5 réponses
Bonjour,
il me semble que vous confondez API et webservice. Le bouton “J’aime” de Facebook est un webservice via iframe dans la majorité des cas et il n’implique pas du tout l’API Facebook. Google propose une API pour interagir finement avec le webservice Google Maps mais ce n’est pas obligatoire non plus.
On peut débattre de la limite exacte entre webservice et API, et de la définition de chacun, mais globalement :
– le webservice est une fonctionnalité affichée sur un site A mais proposée par un site B. C’est quelque chose de visible par les internautes, d’affiché à l’écran, comme un widget Google Maps par exemple.
– on désigne par API le mécanisme invisible pour l’internaute qui permet une interaction fine entre un site A et un site B. Typiquement, le site A envoie au site B une information (ou une requête) qui lui est spécifique, qui en retour va lui donner une réponse sur-mesure.
Exemples:
1) Le webservice sans API : pour le bouton Facebook, les webmasters peuvent choisir parmi certains paramètres pour personnaliser son apparence mais ça s’arrête là, on ne lui fournit rien de spécifique. C’est un webservice qui n’a pas d’API.
2) Le webservice personnalisé via une API : Pour Google Maps en revanche, on peut fournir une adresse spécifique à l’API Google, et le webservice est personnalisé en conséquence et affiche l’adresse sur un plan.
3) L’API sans webservice : avec l’API de Google Translate, on peut faire traduire des texte à Google mais ensuite, c’est au webmaster de gérer complètement la façon d’afficher le résultat de la traduction. C’est donc une API sans webservice.
Pour information, dans la grande majorité des cas, les API sont consommées côté serveur et ne sont pas liées à un webservice. Lorsque l’on explique le concept d’API, il ne faut donc pas l’assimiler aux webservices, car ils sont indépendants. Une API n’a rien de visuel, seuls les développeurs sont amenés à l’utiliser. Désolé, ça ne facilite pas les explications !
Et lorsque les personnes que vous citez disent que les API sont l’avenir du web, ils ne pensent sans doute pas aux webservices, donc attention au contre-sens 🙂
En espérant avoir éclairé la lanterne de certains ou certaines sur ces concepts barbares ^^
Il est vrai que ces API fleurissent un peu partout de jour en jour et pour cause : elles sont bien pratiques !
En revanche de là à dire que ne pas en avoir de nos jours, c’est comme ne pas avoir de site au début d’Internet; je m’interroge : quelle autorité, crédibilité pourrait avoir un Coca-Cola à proposer une API ? Quel intérêt ? J’ose imaginer qu’il s’agit d’une citation tronquée, d’une mauvaise interprétation de ma part ou alors je veux bien qu’on me fasse une petite démo 😉
Dans tous les cas bon article que j’ai pris plaisir à lire !
Pour Facebook, le bouton “j’aime” n’est pas un webservice, mais un plug-in, plus précisément un social plug-in.
Il y a donc matière à débat !
Bonjour Aurélie,
l’appelation “social plug-in” a été inventée par Facebook me semble-t-il, elle n’est pas standard dans le monde des devs 🙂 On parle plutôt de widget.
Ceci dit, oui il y a débat, surtout que ma définition de webservice n’est pas académique. En théorie, un webservice n’implique pas forcément de servir quelque chose de visuel, et une API est en réalité une composante d’un webservice. Et webservice est souvent connoté “échanges SOAP” ou autres, ce qui fait que des puristes hésiteront à dire qu’un widget est un webservice. Pour ma part, étant donné que le bouton “j’aime” est une fonctionnalité inter-site servie sur HTTP, ça ne me pose pas de problème de dire que c’est un webservice.
Bref, dans la vie de tous les jours, il me semble que beaucoup ont en tête la définition simple de webservice que j’ai donnée en premier, même si c’est une simplification abusive.
Merci pour vos commentaires qui me prouvent que j’étais bien loin de cerner le sujet après une seule conférence et quelques recherches.
Après discussion avec un collègue, je m’aperçois que chacun utilise le terme « API » un peu à sa façon. Il peut avoir plusieurs sens en fonction de celui qui vous livre la définition. Il est difficile de trancher.
De plus, les définitions se déforment, évoluent au cours du temps. Un peu comme le terme de « geek » qui avait une signification, totalement transformée aujourd’hui.
Pour en revenir aux entreprises qui mettent à disposition leurs API, le vrai challenge sera d’être clair sur ce qu’ils mettent à disposition : des données, des fonctionnalités, des adaptations possibles, etc…
En d’autres termes : vulgariser une offre compréhensible à l’origine par la seule population des développeurs.