Twitter API, etc. Et plus près de nous, il existe des écosystèmes issus d’acteurs français : Mappy API, Netvibes UWA, Nabaztag API, etc.
Cette démarche permet la constitution d’un écosystème fécond, tant pour l'entreprise qui met à disposition les APIs, que pour celles qui les exploitent. Cette mise à disposition permet en particulier de :
Marc Andreessen (ancien fondateur de Netscape) distingue 3 types de plateformes ouvertes (voir ce billet) :
Niveau 1 "Access API" : ces plateformes permettent l’appel à un traitement métier sans fourniture d’interface homme/machine. Exemples : recherche de livres chez Amazon, geocoding chez Mappy.
Niveau 2 "Plug-In API" : Ces plateformes permettent d’intégrer une application à l’interface du fournisseur. Exemple : les applications Facebook, les Widgets Netvibes.
Niveau 3 "Runtime Environment" : Ces plateformes fournissent non seulement une API, une interface, mais aussi un environnement d’exécution. Exemple : les applications AppExchange ou l’iPhone.
Il est clair que l’investissement du fournisseur de l’API va croissant du niveau 1 au 3. Il est donc fréquent de commencer au niveau 1, avant d’envisager les niveaux supérieurs.
Le succès d’un écosystème ouvert est fortement dépendant de l'enthousiasme des développeurs. Pour les conquérir, il est crucial de leur fournir un langage facile à prendre en main et, si possible, des outils de productivité. Côté langage, il existe un large consensus autour des APIs REST/JavaScript, simples à prendre en main, et adaptées à des développeurs connaissant mal les langages objets. Exemples : API Google, Yahoo, Mappy, etc. Proposer un langage simple est particulièrement recommandé aux nouveaux entrants qui n’ont pas le pouvoir de persuasion d’Apple (qui a réussi à convaincre des milliers de développeurs de se former à ObjectiveC...).
Pour ce qui concerne l’outillage, on peut distinguer 3 niveaux d’offres :
Là encore, le niveau 3 représente un investissement beaucoup plus conséquent que le 1 ou le 2.
La publication d’une documentation claire, simple à prendre en main, et d’exemples de code réutilisables est incontournable pour satisfaire les développeurs. L’animation de la communauté passe aussi par la mise en oeuvre de forums de discussions et autres outils participatifs (par exemple, ZenDesk). Il peut être intéressant de se raccrocher à une communauté existante plutôt que d’en créer une à partir de rien. Par exemple, Android a recruté dans les communautés Java. Enfin, il est classique d’organiser un concours avec des prix à la clef, pour initier le mouvement communautaire. Voir par exemple, l’Android Developer Challenge.
Un dernier point est essentiel : le modèle d’accès aux APIs. Certaines plateformes nécessitent une inscription préalable à leur usage (c’était le cas pour Google Maps jusqu’à mai 2010). D’autres plateformes vont même jusqu’à valider les applications développées (c’est le cas de la très polémique validation par Apple des applications iPhone).
Je pense qu’imposer le minimum de contraintes aux développeurs est un signe très positif, à même de créer un climat de confiance, et d’élargir la communauté. La modération à postériori me parait être la meilleure pratique.
Il est relativement simple de démarrer avec une plateforme / un outillage de niveau 1. Par exemple, la Ville de Rennes a récemment lancé une expérimentation en ouvrant des API sur les données de ses transports publics. On pourra ensuite monter en puissance de manière itérative vers une plateforme de niveau 2/3 et un outillage plus avancé.
Je vous propose quelques pistes par secteurs d’activité. Ces pistes sont largement issues de mes envies en tant qu’utilisateur :
Alors, quand pensez-vous lancer votre écosystème ouvert ?