http://mag.welovesaas.com/index.php/2012/dossier-api-part1-les-api-au-coeur-de-linternet-de-demain/
Qu’est ce qu’une API?
Une API, pour Application Programming Interface, est une
interface de programmation qui permet à des développeurs tiers d’accéder
aux données et/ou fonctionnalités d’une application de façon contrôlée.
Prenons l’exemple de Twitter. Dans notre cas Twitter
est l’application qui propose une API. Twitter est un service à part
entière: les utilisateurs s’y inscrivent, postent des tweets, partagent
des liens, communiquent entre eux etc… Twitter a construit en interne
toutes les fonctionnalités (inscription, création de tweets, moteur de
recherche etc…) et stocke toutes les informations et données créées par
ses utilisateurs (les tweets, les recherches, les liens entre
utilisateurs…).
Mais Twitter s’est très rapidement positionné en tant que plateforme
et a voulu qu’un maximum de développeurs “extérieurs” (dit développeurs
tiers) puissent construire leurs propres applications basées sur les
fonctionnalités et données détenues par Twitter. Pourquoi? Notamment
pour accélérer l’adoption de son service mais nous reviendront plus tard
sur les avantages procurés par une API. Comme Twitter ne pouvait donner
un accès direct à toutes ces fonctionnalités et données sans contrôle
(pour des raisons évidentes de sécurité) le réseau social a mis
en place une API qui est l’interface de programmation permettant aux
développeurs d’y accéder de façon contrôlée.
L’API de Twitter est donc une sorte de boîte à outils
destinée aux développeurs leur permettant d’accéder aux données et
fonctionnalités de façon sécurisée et contrôlée.
Le cycle de fonctionnement est le suivant:
- une entreprise/une application veut mettre à disposition d’autres partenaires ses données/fonctionnalités
- elle construit donc une interface de programmation appelée API pour contrôler et sécuriser cette utilisation
- une fois l’API mise en place les développeurs tiers s’identifient,
demandent un accès et une fois leur compte crée ils peuvent faire usage
les outils mis à disposition pour utiliser ces données et
fonctionnalités dans leur propre application
Pour terminer sur l’exemple de Twitter, c’est grâce à son API que de
nombreux développeurs tiers ont pu, par exemple, construire ce qu’on
appelle des “clients Twitter” (comme TweetDeck). Grâce à des
applications comme TweetDeck vous pouvez consulter votre flux Twitter,
partager des tweets, répondre à d’autres membres via une application qui
n’est pas crée par Twitter. Ainsi vous pouvez être un utilisateur actif
de ce réseau social sans jamais aller sur le site ou l’une des
applications officielles Twitter. D’ailleurs près de 60% de l’activité
du site de microblogging se fait via son API.
Les API ne sont pas l’apanage des startups technologiques innovantes, de plus en plus d’entreprises plus “traditionnelles” ouvrent leurs données à l’extérieur via des API. c’est le cas par exemple de la sncf, ou encore du gouvernement qui ouvre depuis quelques temps des données de ses administrations.
Quelques définitions complémentaires
Vous devez vous en douter mais il n’existe pas qu’une sorte API, les
API adressent de nombreuses problématiques et existent sous différentes
formes. Voici quelques définitions utiles à connaître pour saisir cette
variété.
Les API privées/publiques: Les API servent à ouvrir
les données d’une entreprise de façon contrôlée, mais cela ne signifie
pas que toutes les API sont accessibles au public en libre service. Les
API privées sont des API dont l’accès reste réservé aux développeurs
internes ou aux partenaires sélectionnés. Dans ce cas l’API permet, par
exemple, aux différents pôles d’une entreprise de construire des
applications plus facilement (accès aux données normalisées,
autorisation et contrôle plus aisés) ou encore d’établir des ponts entre
une entreprise et ses fournisseurs.
L’API publique est au contraire une API qui expose les données et
fonctionnalités à tous les développeurs qui le désirent. Les exemples de
Twitter et de Facebook sont ici pertinents, leurs API sont ouvertes à
tout un chacun.
Les API en lecture/écriture: Les API en lecture sont
des API qui n’autorisent les développeurs tiers qu’à lire les données
récupérées. C’est par exemple le cas de l’API de velib, le célèbre
service parisien de vélos en libre accès, dont l’API permet de récupérer
l’ensemble des stations de velib de la capitale et pour chacune d’entre
elle le nombre de vélos à disposition.
Les API en écriture permettent non seulement de lire des données mais
aussi d’écrire de nouvelles données (ou de modifier celles existantes).
C’est le cas de Twitter puisque via son API vous pouvez diffuser de
nouveaux tweets, ou encore de Foursquare (un annuaire de bonnes
adresses) qui permet d’enregistrer de nouveaux points d’intérêt (nouveau
restaurant, attraction touristique) sur son service depuis son API.
Pour résumer une API en “lecture seule” propose un flux
unidirectionnel entre l’entreprise et le développeur (il ne peut
qu’accéder aux données du système) et l’API en lecture/écriture propose
un flux à double sens entre l’entreprise et le développeur (qui peut
venir ajouter/modifier des données).
Les API de données et de services: Comme nous
l’avons vu dans la définition, une API peut donner accès aux données
mais aussi aux fonctionnalités d’une entreprise. L’API de données est la
plus courante, elle garantit l’accès à des données sous différents
formats, au développeur ensuite de les traiter pour en faire ce qu’il
désire.
Les API de services donnent accès à des fonctionnalités complètes.
Imaginons que vous soyez développeur. Vous avez crée un réseau social,
une des fonctionnalité disponible est le partage de photos entre
membres. Vous avez sûrement besoin des fonctionnalités de base de
l’édition de photo (recadrage, redimensionnage etc…) mais vous n’allez
pas tout recréer de toute pièce.
Une possibilité est de faire appel à une API spécialisée qui s’occupe de tout ce travail. C’est le cas par exemple de SnipShot.
SnipShot a toute la technologie en interne pour faire de l’édition de
photo et propose ces fonctionnalités via son API. Ce qu’il vous reste à
faire est donc d’utiliser leur APi de service en fournissant en entrée
les photos qui doivent être traitées, elles passent aussitôt par la
technologie de SnipShot qui les traitent suivant vos demandes et vous
les renvoies finalisées. Au lieu de réinventer la roue vous utilisez les
fonctionnalités déjà éprouvées par un acteur spécialisé.
Il existe de nombreuses API de ce genre citons par exemple Twillio qui est spécialisé dans la voip (téléphonie par internet).
Une API peut donc non seulement mettre à disposition les données
d’une entreprise mais aussi sa technologie sans en exposer le
fonctionnement.
API gratuites/payantes. Enfin finissons ces
définitions avec la différences entre API payantes et gratuites. Les API
peuvent être monétisées (comme nous le verrons plus tard) auquel cas
les utilisateurs de l’API doivent payer pour accéder aux données et à
l’inverse les API gratuites garantissent un accès libre aux
données/fonctionnalités.
Les API au coeur de « l’app economy »
Le concept d’ouverture des données et d’interconnectivité sur
internet existe depuis longtemps, dès les années 90 certains sites
proposaient de tels protocoles (SOA)
mais c’est avec l’avènement du web 2.0, lors de la première moitié de
cette dernière décennie, que le concept d’API a vraiment commencé à
décoller. Les flickr, Youtube et autres Google Maps ont ouvert des API
qui ont rendu possible la création des mashups: des applications mixant
diverses API pour proposer des applications originales (Google Maps +
Flickr pour géolocaliser des photos).
Depuis le phénomène n’a eu de cesse d’accélérer, de plus plus d’entreprises et d’applications ouvrent leurs données via des API.
source http://www.slideshare.net/jmusser
La multiplication des API s’explique également par la
transition d’un web historiquement caractérisé par un ensemble de sites
et de pages liés entre eux par des liens hypertext à un écosystème
d’applications qui interagissent entre elles via des API et les plateformes, c’est ce qu’on appelle “l’app economy”.
Cette transition est la plus visible sur mobile, en effet depuis le
succès de l’appstore d’Apple des milliards d’applications mobiles ont
été crées par des développeurs. Ces applications ne sont pas accessibles
par un navigateur traditionnel ou mobile mais bien en téléchargeant une
application à part entière. Ces applications restent connectées à
internet et communiquent avec de nombreux services web via des API.
Mais ce phénomène “d’applications” ne se limite pas au mobile, sur le web “classique” l’ère des plateformes bat son plein.
Facebook est une plateforme qui possède ses applications dédiées,
Google possède sa marketplace d’applications tout comme Salesforce avec
force.com ou encore Amazon et Apple.
Cette “applification” du web se constate également dans nos usages de
tous les jours: vous vous inscrivez de plus en plus à des applications
web en connectant vos comptes Twitter, Facebook ou Google, vous publiez
vos photos sur Facebook qui sont aussitôt sauvegardées automatiquement
sur iCloud ou DropBox.
Même au niveau professionnel cette explosion d’interconnectivité se ressent:
vous pouvez centraliser toutes les demandes de vos clients qu’elles
proviennent de votre compte email, de vos comptes Facebook/Twitter pro,
de votre chat sur votre logiciel de CRM (comme Zendesk), votre logiciel
de seo se connecte et interagit avec votre google analytics (comme
myposeo) tout comme votre application de facturation qui se branche
directement à votre application de comptabilité. Les services web
deviennent de véritables applications interconnectées.
La multiplication des terminaux d’accès favorise également cette explosion d’applications.
On parlait du téléphone portable il y a quelques paragraphes. Les
utilisateurs doivent maintenant jongler entre leur smartphone, leur
tablette tactile mais aussi de plus en plus avec leur console de jeux
(via laquelle ils accèdent à des applications pour visualiser des
photos, écouter de la musique, regarder des films), leur télévision
connectée et bientôt avec leur voiture, leurs lunettes (les fameuses
Google Glasses) etc… Or pour chacun de ces supports les éditeurs doivent
proposer une application spécifique et dans le même temps l’utilisateur
demande à ce que l’expérience soit la plus fluide possible, que ses
données soient accessibles de n’importe quel terminal à n’importe quel
moment.
Dans ce nouveau paysages les API tiennent une place centrale car ce
sont elles qui permettent aux applications de communiquer entre elles.
Le nombre d’API disponibles explose et dans un avenir proche il
deviendra indispensable pour beaucoup de services d’en proposer une. Les API deviennent le système nerveux de toutes ces plateformes.
Quels avantages procurés par les API?
Dans cet environnement en pleine évolution dans lequel les connexions
entre applications, plateformes et terminaux explosent, les API
procurent aux entreprises qui en font usage de nombreux avantages.
Création d’un écosystème d’applications tierces
En proposant une API une entreprise peut favoriser son adoption par
des développeurs tiers. De cette utilisation peut découler énormément
d’innovation via des applications tierces. Si une API est appréciée par
la communauté des développeurs il se peut que de nombreuses applications
extérieures viennent en faire l’usage. C’est par exemple le cas des
plateformes principales telles que Twitter et Facebook pour lesquelles
les développeurs ont crée des millions d’applications parmi lesquelles
se trouvent de véritables pépites. Il n’est d’ailleurs pas rare de voir
Twitter et Facebook racheter des applications tierces et les intégrer en
interne par la suite.
Mais cet argument n’est pas uniquement vrai pour les plateformes
d’envergure mondiale. Prenons l’exemple du Velib parisien, via son api
il s’est crée bon nombre d’applications mobiles innovantes, de mashups
très originaux et utiles (avec google maps par exemple), sans compter
des applications qui en plus de leur propre service intègrent les
données Velib. Sans une API toutes ces applications parallèles
n’auraient pu voir le jour.
L’API est un véritable accélérateur d’innovation.
Etendu du reach, nouveau canal de distribution
Corollaire du point précédent plus votre service/vos données sont
intégrées à des applications tierces plus vous étendez votre reach. En
effet même si un utilisateur ne passe pas par l’application mobile
offcielle de velib le fait qu’il soit exposé à la marque via d’autres
applications est tout de même bénéfique pour la marque.
De même grâce à l’intégration des données sur de multiples
applications tierces une entreprise a l’opportunité de toucher des
marchés/utilisateurs qui n’auraient pas forcément été clients au premier
abord. Clairement les API constituent un nouveau canal de distribution
pour votre service et votre marque.
Source de revenus
Comme nous l’avons vu dans les définitions une API peut être soit
payante soit gratuite. Pour certaines entreprises leurs revenus
principaux proviennent de leurs API. C’est le cas notamment
d’entreprises qui ont construit une technologie qu’elles n’ont pas
forcément réussie à vendre en tant que service et qui au lieu de mettre
clef sous porte décident de vendre son utilisation à d’autres
développeurs sous forme d’API. Twillio, une API de VOIP (voice over IP)
entre par exemple dans cette catégorie.
Il existe plusieurs façon de monétiser une API, nous y reviendront plus tard dans une partie dédiée aux business model des API.
Comme moyen d’étendre sa présence sur les nouveaux terminaux connectés
Depuis quelques années on constate une explosion des terminaux
intelligents et connectés: smartphones, tablettes tactiles, consoles de
jeux, télévision etc… Il devient de plus en plus difficile pour un
éditeur de service web d’être présent sur toutes les plateformes à la
fois.
Créer une application par plateforme nécessite à chaque fois du
temps, de l’argent et des compétences qui n’existent pas forcément en
interne.
Une bonne stratégie consiste à laisser la communauté s’occuper du
portage sur différents terminaux grâce à l’utilisation d’une API. En
effet en exposant vos données et fonctionnalités via l’API les
développeurs peuvent créer les applications natives sur mobile ou sur
tout autre plateforme, et même si la communauté ne le fait pas
spontanément des partenaires (payants ou non) peuvent s’occuper du
portage.
Un bon exemple de cette stratégie est Netflix.
NetFlix est un service de vod (Video On Demand) permettant aux
utilisateurs de visualiser films et séries en streaming. Un des facteurs
de succès du service américain a été de proposer leur service sur de
nombreux terminaux différents. Quelque soit le terminal l’utilisateur
peut utiliser le service et consommer du contenu. Il est très difficile
pour NetFlix de s’occuper du portage de son service sur tous les
terminaux possibles, c’est pour cette raison que leur stratégie s’est
basée sur des API que les partenaires utilisent pour développer les
applications sur leur plateforme comme la xBox de Microsoft ou encore
les télévisions Samsung.
Pour les applications B2B: facilité d’intégration chez les clients
Les éditeurs B2B sont souvent confrontés à la demande des clients
d’intégrer leur application au système existant. Faire du sur mesure et
devoir intégrer spécifiquement une application pour chaque client n’est
pas une tâche facile et n’est forcément le coeur métier des éditeurs.
En proposant une API les éditeurs facilitent ce travail d’intégration
autant pour les entreprises clientes qui peuvent réaliser ces
connexions en interne que pour les partenaires SSII ou intégrateurs qui
serviraient d’intermédiaires.
Création de partenariats et de ponts entre applications
Comme nous l’avons vu dans la partie précédente concernant “l’app
économy” le besoin en interconnexions et en passerelles entre les
applications se fait de plus en plus fort.
Chaque application peut bénéficier de connexion avec les API d’autres
applications pour proposer davantage de valeurs à l’utilisateur final.
Prenons l’exemple de MyPoseo une application française de suivi de
mot-clefs qui en se connectant avec le compte Google analytics du client
permet de lui faire de la recommandation de mot-clefs pertinents. De JotForm,
une application de création de formulaires et questionnaires en ligne
qui s’interface avec DropBox pour permettre aux sondés d’envoyer des
fichiers directement sur le compte DropBox de l’entreprise. Ou encore de
Zendesk une application de CRM qui se connecte à tous vos flux email,
chat et autres réseaux sociaux pour centraliser et remonter toutes les
demandes de vos clients.
Ces connexions entre applications bénéficient non seulement aux
clients qui y trouvent plus de valeurs mais aussi aux éditeurs
d’applications qui enrichissent leurs fonctionnalités et étendent leur
service via d’autres applications.
Qui doit ouvrir une API?
Maintenant que nous avons vu ce qu’est une API et que le sens de
l’histoire va vers une multiplications de ces dernières, se pose
légitimement la question de savoir qui va être impacté. Quelles sont les entreprises/professionnels qui doivent se poser la question de l’ouverture d’une API?
Considérons tout d’abord les entreprises qui sont directement concernées par ce phénomène, à savoir les éditeurs de logiciels et d’applications.
Si vous êtes dans le monde de l’édition de services web alors la
réponse est clairement oui, vous devez vous pencher très sérieusement
sur la question de l’ouverture d’une API. Bien entendu il existe
différents degrés de priorités suivant le type d’application que vous
éditez:
- Les plateformes: les applications dont l’ambition
est de devenir une plateforme doivent mettre leur API au coeur de leur
stratégie. Exemples: Facebook, Twitter ou encore Salesforce avec
Sales.com, Google app marketplace pour des services B2B.
- Les applications du type Zendesk qui gagnent de la valeur en centralisant beaucoup de flux de données pour le client
doivent également proposer des API solides pour fédérer les
partenaires. Ex: les logiciels de CRM, les ERP, les logiciels de gestion
- Les applications qui ne centralisent pas d’autres applications mais
gagnent à être présent sur d’autres applications (distribution). Exemple
DropBox qu’un client va brancher à d’autres services car c’est son
outil de stockage principal.
- Les petits éditeurs d’applications qui en proposant une API
“minimale” peuvent distribuer leur application sur des places de marché.
Ex: l’éditeur français entreprise facile qui propose une place de
marché d’applications à destination des indépendants/tpe.
Mais les API ne sont pas des outils réservés aux
professionnels du logiciel, de nombreuses autres entreprises doivent se
pencher sur la question de l’ouverture de leurs données. En
effet comme nous l’avons vu au travers de quelques exemples, des
entreprises traditionnelles peuvent bénéficier de l’ouverture d’une API
pour fédérer une communauté de développeurs, bénéficier d’innovation
externe, étendre leur reach, distribuer leurs données à plus de clients
potentiels, faire connaître leur marque au delà de leur communication
classique etc… Quelques exemples d’entreprises qui bénéficient de cette
ouverture:
- Les entreprises de transports: même si en France
nous sommes plutôt en retard de ce point vue, de nombreuses entreprises
de transports dans le monde (metro, bus, train, avion etc…) ouvrent leur
données (horaires, incidents, réservation, achat etc…) ce qui entraine
une floraison d’applications tierces innovantes. La Sncf s’y est mise
dernièrement avec son projet d’opendata.
- Les administrations: sous la pression des citoyens
le mouvement de l’opendata fait son chemin. Les citoyens veulent savoir
ce que ces administrations font de leur argent en demandant un droit de
consultation des données.
- Les entreprises de télécommunication: tous les
grands opérateurs et entreprises de télécommunication proposent déjà des
API. ex: Orange en France, AT&T aux Etats Unis, Deutsch Telekom
etc…
- Les constructeurs de matériel électroniques: téléphone, télévision, automobile, consoles de jeux…
- etc..
A un niveau moindre il existe également des entreprises de taille
plus modeste qui ouvrent des API privées pour communiquer avec leurs
fournisseurs ou leurs clients.
Bien entendu il ne faut pas non plus tomber dans l’excès inverse et vouloir vendre le concept d’API à tout le monde.
Toutes les entreprises n’ont pas vocation à ouvrir leurs données. Pour
certaines cela n’a pas de sens, pour d’autres l’impact qu’aurait
l’ouverture d’une API serait trop faible par rapport à l’investissement.
Même pour ceux qui doivent proposer une API se pose la question de
leurs ambitions et de leurs moyens. Tous les éditeurs n’ont pas vocation
à devenir une plateforme à la Twitter ni même à fournir une API ultra
complète qui va être utilisée par des centaines de développeurs. Tout
est question de juste milieu. Il existe de nombreux enjeux quand à la
construction d’une API sur lesquels nous nous pencheront dans la partie
suivante.
Franz Durupt
@peultier
Laurent Joffrin
@Laurent_Joffrin
alexandre mathis
@alexandremathis
