[Dossier API part1] Les API au coeur de l’internet de demain

A partir d’aujourd’hui et pour les 4 semaines à venir nous allons vous proposer chaque vendredi un article décortiquant le passionnant et prometteur monde des API. 

Pourquoi un dossier traitant des API sur WeLoveSaaS? Car en testant de nombreuses applications sur de nombreux terminaux et en discutant avec les éditeurs nous nous sommes rendus compte de l’importance croissante qu’est en train de prendre le phénomène des API. Il est important dès maintenant de comprendre ce phénomène et les implications qui en découlent.

A qui s’adresse ce dossier? Cette série d’articles s’adresse autant aux professionnels utilisateurs de SaaS qu’aux éditeurs qui veulent comprendre ce que sont les API et ce qu’elles impliquent d’un point de vue business.

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:

1. une entreprise/une application veut mettre à disposition d’autres partenaires ses données/fonctionnalités
2. elle construit donc une interface de programmation appelée API pour contrôler et sécuriser cette utilisation
3. 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.

• Bio
• Latest Posts

Clément Vouillon

co-fondateur at WeLoveSaaS

Intéressé dés 2008 par le modèle SaaS, Clément a co-fondé cette année là edoboard.com une plateforme d’apprentissage disponible 100% en ligne. Après ce premier pied dans le monde du SaaS B2B il est à l’origine de l’aventure WeLoveSaaS avec Guilhem Bertholet.

Latest posts by Clément Vouillon (see all)

• Must have ou nice to have? De quel côté de la barrière se trouve votre application – 10 janvier 2013
• [API Hour] Les API au coeur des services d’interconnexion entre logiciels SaaS – 21 décembre 2012
• [news welovesaas] les fiches SaaS s’enrichissent – 20 décembre 2012