Clement vouillon

API, applications tierces: pourquoi les sites internet ont besoin d’ouvrir leurs données.

Posted on January 23, 2010 by clement

Tweet

Aujourd’hui je me lance dans un post un peu spécial qui traitera des écosystèmes d’applications (ou applications tierces) développées grâce aux API. Il est monnaie courante que les sites internet ouvrent “leurs données” aux développeurs externes et les laissent programmer de multiples services gravitant autours d’eux. Ouvrir son service et ses données est devenu un enjeu stratégique, je vous propose donc un petit état des lieux.

Qu’est qu’une api?

Le terme API, issu du monde logiciel, signifie Application Programming Interface. En résumé il s’agit d’une interface entre les logiciels et le monde extérieur. Un programme est en général prévu pour exécuter tout un tas d’opérations et d’actions (c’est son but principal) mais il doit aussi dans certains cas permettre aux autres logiciels d’interagir avec lui et lui-même d’interagir avec des données et d’autres programmes du monde extérieur. C’est ici qu’interviennent les API qui sont des librairies de fonctions et d’appels fixant les règles de communication avec le logiciel. Ainsi sans dévoiler tout votre code vous donnez la possibilité au monde extérieur de communiquer avec vous mais d’une façon que vous contrôlez. Avant de perdre définitivement ceux qui se demandent déjà ou est le rapport avec les services web, j’ajoute que cette pratique « software » s’applique tout à fait aux sites internet qui sont de plus en plus nombreux à proposer leur API. D’ailleurs vous connaissez surement des API comme celle de google maps qui a révolutionné le monde de la cartographie sur internet en permettant à tout un chacun de disposer de ses propres cartes ou encore celle de flickr à l’origine d’innombrables mashups. C’est grâce à elles que les sites ne sont plus totalement cloisonnés.

Rien ne vaut une belle comparaison pour comprendre un concept un peu technique, je vous livre celle faîte en 2000 dans un article de David Oreinstein , je me permets sa reprise en Français, tout le crédit lui revenant.

Imaginez que vous ayez 3 voisins : « Closed » Carl, « Open source » Oscar et « API » Annie. Ils sont comparables à des applications, comme avec n’importe quel voisin vous avez parfois des interactions comme discuter, emprunter des objets… Il s’agit de l’équivalent de la communication entre applications. Imaginons maintenant que vous ayez besoin d’emprunter une machine à tondre la pelouse à l’un de vos voisins :

• « Closed » Carl : Il ne vous rendra tout simplement aucun service, il tond sa pelouse à l’abri derrière sa barrière de 2 mètres de haut. Non seulement vous ne pouvez rien lui demander mais vous ne pouvez même pas traverser sa propriété, n’essayez pas il n’y a pas de porte à sa clôture. Une application comme Carl ne donne accès à aucune partie de son code et ne propose pas d’API.

• « Open source Oscar ». Tout le contraire de Carl. Il est tellement ouvert qu’il vous laissera librement arpenter sa pelouse quand vous voulez et il vous laissera même bricoler sa propre tondeuse pour qu’elle réponde au mieux à vos besoins. Une application comme Oscar propose son code en open source et ainsi la possibilité de le modifier à votre guise.

• « API »Annie. Elle vous laissera emprunter sa tondeuse si vous le lui demandez d’une façon correcte (en appelant la method « GetMower » ). Vous ne pouvez pas rentrer chez elle sans permission ni bricoler sa tondeuse, mais vous pouvez l’utiliser comme bon vous semble. Les applications comme Annie gardent leur code fermé mais proposent le dialogue via ses API.

J’espère n’avoir perdu personne en route avec cette comparaison mais elle illustre assez bien les concepts derrières la notion d’API, vous pouvez également consulter cet article très clair sur le sujet.

Beaucoup de sites proposent maintenant leur interface de communication, les services internet se décloisonnent de plus en plus, donnant la possibilité aux développeurs de créer des applications communiquant avec plusieurs services en même temps. Cet effort résulte dans la création d’écosystèmes d’applications tierces qui viennent compléter et souvent même améliorer le service de base. Mais il ne faut pas croire que la notion d’API est récente (relativement à l’âge du web ), après avoir emprunté une tondeuse à gazon je vous propose de sortir vos pioches et truelles pour un peu d’archéologie.

History of violence

De tout temps l’homme… et de tout temps des services internet se sont ouverts vers l’extérieur et leur communauté:

1999-2003 : Ebay et Amazon. E-commerce et enchères

Vers la fin des années 90 et le début des années 2000 les géants de l’internet n’étaient pas encore  les réseaux sociaux ou les moteurs de recherche mais les sites d’enchères et de e-Commerce. EBay et Amazon se battaient déjà et cette époque a vue l’apparition des premières API qui seront massivement utilisées : l’API d’EbAy et les web services d’Amazon. Lancées respectivement en 2000 et 2002, elles constituent un pas important en autorisant l’accès à leur base de données produits, et ainsi à chacun de créer et personnaliser sa boutique en ligne. Les développeurs en font usage à des fins principalement « e-commerce » et les API proposent avant tout un accès aux caractéristiques des produits vendus, et autres fonctionnalités de paiement, recherche etc…. 5 ans après son lancement (2005) Ebay se targuait d’avoir plus de 15 000 développeurs extérieurs utilisant leur service. Quant à Amazon l’évolution de ce qu’ils appellent « web services » a été proprement phénoménale, fin 2007 plus de 330 000 développeurs étaient actifs et la branche services d’Amazon génère dorénavant une bonne centaine de millions de dollars. Ouvrir leurs données s’est clairement révélé être un pas décisif et stratégique dans leur développement, agrégeant une communauté de revendeurs très précieuse pour Ebay et se transformant en en gigantesque centre de services pour Amazon.

2004-2006 : La folie des mashup : Flickr et google

Même si les outils du web 2.0 existaient déjà (notamment les blogs) avant 2004 cette époque est le début du web social ( Myspace 2003) et surtout va connaître l’explosion des mashups. Les mashups sont des sites web faisant appel à plusieurs services web extérieurs, par exemple si vous combiniez Flickr et Googlemaps vous obteniez une géolocalisation de vos photos. De nombreux sites importants ont contribué durant cette période à l’effort d’ouverture des données, mais les deux figures emblématiques sont pour moi Flickr (API en 2004) et google maps (API en 2005). Flickr apportait un fort coté social (amis, partage de photos…) et google maps « l’interactivité » du web 2.0 avec de belles cartes dynamiques. Les API proposent dés lors plus de possibilités pour des applications funs et sociales, raison de l’explosion des mashups. Encore une fois les API ont permis à ces sites une forte adoption de la part de la communauté des internautes et la création de nombreux services innovants, même s’il ne s’agit pas du seul facteur de succès il n’y a pas de doutes quand à sa prépondérance.

2006-2009 : réseaux sociaux, réseaux sociaux, réseaux sociaux : Facebook et Twitter.

Ça n’aura échappé à personne mais durant les 2 à 3 dernières années la majorité du buzz sur la toile a concerné les maintenant familiers réseaux sociaux. Au duel fratricide Facebook/Myspace a succédé le sprint entre Facebook et Twitter pour la domination des « status update ». L’apport des API est crucial voir vital pour un réseau social, FB et TW ont mis à disposition les leurs début 2007 et leur positionnement sur ce sujet n’est pas forcément le même. Facebook laisse les développeurs créer leurs applications seulement sur la plateforme Facebook alors que Twitter laisse un peu plus de liberté en permettant à des sites complètements externes de se construire sur la base de leur API (on peut consommer de l’information Twitter sans jamais aller sur twitter.com alors que ce n’est pas vrai pour Facebook). L’échelle d’utilisation a également évolué puisque dorénavant ce sont de véritables systèmes économiques qui se sont mis en place, les applications Facebook générant des millions de dollars pour leurs développeurs. Pour un réseau social qui se veut ambitieux il est maintenant incontournable d’ouvrir un temps soit peu ses données, il s’agit non plus d’une proposition différentiante mais tout simplement d’un standards.

Pourquoi proposer son API?

A la vue de cette chronologie nous pouvons tirer quelques enseignements sur les avantages de proposer une API de qualité :

• Une source de revenus : les moyens de monétiser son API sont nombreux, le meilleur exemple étant Amazon avec ses multiples services in the Cloud. D’autres sites font payer les gros utilisateurs, sur un modèle freemium : les appels au service sont facturés au-delà d’un certains nombre.
• Création d’un écosystème autour de sa plateforme : tous les marchants autours d’ebay et d’amazon, les multiples mashup pour flickr et google maps, les milliers d’applications Facebook et les centaines de services gravitant autours de Twitter, tous ces sites font vivre de véritables écosystèmes économiques et de services constituant une barrière à l’entrée face aux concurrents et une barrière de sortie pour les utilisateurs qui en bénéficient.
• Création d’une communauté de développeurs : dédiée à la plateforme cette communauté « invisible » est tout aussi importante pour le site que les utilisateurs “grand public”. D’eux dépendent la qualité de l’écosystème.
• Attire les marques. Les marques apprécient la possibilité d’engager la conversation avec ses clients et fans sur les réseaux sociaux via les applications tierces. Ce n’est pas forcément bon pour nous mais pour la plateforme il s’agit souvent d’un atout.
• Sérendipité /innovation : permettre à des milliers d’ingénieurs et de marketeurs de travailler et réfléchir sur son produit est un avantage sans prix. De nombreuses fonctionnalités et usages ont d’abord été des applications tierces avant  d’être intégrées/rachetées par les plateformes mères.

Attention tout de même, faire adopter son API n’est pas tache aisée et nécessite un vrai budget. L’API doit être bien construite, bien pensée et documentée. Les champs d’action des développeurs tiers bien définis afin de ne pas trop en donner mais sans excessivement les brider. Après la conception de celle-ci, l’adoption par les communautés de développeurs nécessite également un investissement important : attirer les meilleurs, construction et suivi de la communauté des programmeurs, incentive de celle-ci (peuvent ils tirer des revenus de leurs applications ? comment ?). Pas évident tout ça !

Enfin il faut réussir à maintenir son service en fonctionnement, ce qui n’est pas toujours évident. Par exemple Twitter connaît (de moins en moins) des downtime réguliers lorsque l’activité est trop forte, cela impacte non seulement Twitter mais aussi les centaines d’applications tierces qui reposent dessus ! Cette hantise des applications tierces de voir le service ralenti ou stoppé se matérialise via le site api status qui surveille en permanence l’état des principales api disponibles.

liste des API les plus utilisées:

• Facebook developers
• Twitter API
• Google search API
• Flickr API
• Ebay developers program
• Google maps API
• Paypal API
• Amazon API
• Bing API

Pour une liste beaucoup plus complète vous pouvez consulter cet article qui recense des centaines d’API.

Exemple de l’écosystème Twitter

Même si l’écosystème de Twitter tient plus de l’exception que de la règle il est intéressant de voir ce que qu’il représente en chiffres. Le Twitterverse c’est:

• applications tierces: 1000 en 2008, 2000 début 2009, plus de 10 000 fin 2009 (source) (le chiffre de 10 000 me paraît tout même suspect…)
• 50% des appels à l’API Twitter se font en dehors de Twitter.com
• Le nombre de visiteurs uniques sur Twitter.com est d’environ 20 millions mais selon une estimation (article Techcrunch) près de 40 millions de personnes accéderaient aux services de Twitter via les applications Tierces, soit deux fois plus que sur le site lui même!

On comprend donc pourquoi on parle de Twitterverse (l’univers de Twitter), en ouvrant ses données Twitter a permis à des milliers de développeurs d’en vivre et des milliers d’applications se créer sur ce qui est à la base un simple service de messagerie à 140 caractères!

Afin de vous représenter les champs d’actions de cet écosystème j’ai également crée cette mindmap catégorisant une centaine d’applications tierces Twitter, on peut vraiment constater la créativité et l’inventivité qu’apporte une communauté de milliers de développeurs.

Et après?

Sans faire appel aux arts divinatoires on peut parier que la prochaine ère sera celle du mobile. Twitter a rendu la géolocalisation possible dans son api, SimpleGeo et GeoApi, dont nous avons parlé ici, facilitent également cette tache. Les réseaux sociaux mobiles comme Gowalla, Foursquare ou Yelp s’ouvrent aux développeurs et les premières applications tierces sortent déjà en ce début 2010. Il n’y a pas que la géolocalisation pour le mobile, les services de micropaiements, de réalité augmentée complètent tout un arsenal de possibilités pour construire son application mobile de la réalisation à l’implémentation du paiement en utilisant uniquement des interfaces extérieures ! On ne peut pas encore mettre de noms sur les acteurs dominants de cette période mais gage que d’ici peu nous y verrons un peu plus clair !

En guise de conclusion je terminerai sur l’impact qu’à cette multiplication des api, d’un côté la circulation des données s’améliorent, on a l’impression d’avoir un web plus ouvert, des acteurs qui nous offrent la possibilité de développer plus rapidement et facilement des applications mobiles ou web, bref que la vie est belle. D’un autre côté les applications sont otages (consentantes certes) du moindre changement des conditions d’utilisation ou de l’humeur du méga boss. Il suffit que le réseau social intègre à ses services de bases certaines fonctionnalités pour que des applications se retrouvent au tapis, d’un revers de main.

[Edit du 24/01/2009]

Merci pour le partage de liens dans les commentaires, pour suivre l’actualité et des articles d’analyses concernant les API dirigez vous vers programmableweb.com référence dans le milieu. Et sur Twitter avec leur compte programmableweb ainsi que celui de John Musser .

Related posts:

• API et réseaux sociaux géolocalisés