Créer un écosystème ouvert ?

Les grands acteurs de l’Internet font souvent le “pari de la confiance” en proposant des API ouvertes, accessibles depuis le Web. Ces APIs permettent à d’autres acteurs, entreprises ou développeurs indépendants, d’innover en les exploitant, et d’inventer de nouveaux modèles économiques.

On peut citer en exemple les plateformes suivantes : Google Maps API, Facebook Graph API, SalesForce AppExchange, 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 :

  • Créer des revenus directs, en les facturant. Exemple : Google Maps devient payant pour plus de 1M de transactions /an.
  • Étendre une communauté, et donc recruter des utilisateurs. Exemple : grâce aux applications dérivées de sa plateforme, Twitter a atteint 200M d’utilisateurs et fait figure de grand du Web.
  • Faire émerger de nouveaux usages pour sa plateforme et donc faire évoluer son modèle de revenu. Exemple : En 2009, Apple a constaté que les développeurs d’applications souhaitaient vendre non seulement des applications, mais aussi des contenus pour leurs applications. Le modèle de l’AppStore a donc évolué pour intégrer cette possibilité.

Les 3 modèles d’écosystème

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.

L’outillage destiné aux développeurs

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 :

  • Niveau 1 “zéro outillage” : les développeurs écrivent leur code dans l’environnement  de leur choix, puis font appel à la plateforme pour le tester. Exemple : Google Maps API.
  • Niveau 2 “IDE” : on fournit un environnement de développement, souvent sous la forme de PlugIn Eclipse, pour donner un peu de productivité aux développeurs : coloration syntaxique, autocomplétion, bouton de publication, etc. Exemple : Flash Builder.
  • Niveau 3 “Emulateur” : en plus de l’environnement de développement, on fournit un émulateur aux développeurs. Exemples : Google App Engine, iPhone.

Là encore, le niveau 3 représente un investissement beaucoup plus conséquent que le 1 ou le 2.

Le lancement de la communauté

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.

Comment démarrer ?

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 :

  • Banque : ouvrir la liste des opérations de chaque client en les sécurisant via le protocole OAuth
  • Opérateurs télécoms et fournisseurs d’énergie : ouvrir les encours de consommation de chaque client en les sécurisant via OAuth
  • Médias & culture : ouvrir les programmes de télévision/radio/musées/salles de cinéma
  • Industriels : ouvrir les catalogues produits
  • Administration : ouvrir les données publiques à la manière de data.gov

Alors, quand pensez-vous lancer votre écosystème ouvert ?

2 commentaires sur “Créer un écosystème ouvert ?”

  • En tant que particulier, j'attends aussi de tous mes fournisseurs (banque, télécoms, énergie, assurance, etc.) d'avantage de services accessibles par API, et de les consolider dans un même portail pour par exemple: - un changement de coordonnées postal, téléphonique, ou bancaire - la liste de mes factures - la liste de mes contrats souscrits Mais comment inciter tous ces fournisseurs à exposer leurs services ? Faut-il standardiser ces services ? et à quand un portail composite pour les services aux particuliers ?
  • En principe, mon.service-public.fr doit jouer ce rôle de portail composite pour les services aux particuliers. Sinon, il a plusieurs initiatives de systèmes d'agrégation de documents/factures électronique pour les particuliers (ex : www.efolia.fr)
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha