La conférence I Love APIs 2015 organisée du 12 au 14 octobre à San José par Apigee a livré aux fournisseurs plusieurs pistes leur permettant d’intéresser les développeurs à leurs API. À commencer par une simplification de leur prise en charge. Kevin Kohut d'Accenture et d'autres intervenants ont ainsi expliqué que, pour intéresser les développeurs, les API, ces modules de tierces parties qui permettent d’accéder à des données et à des services, devaient être de bonne qualité. Kevin Kohut a donné un tas de conseils pour rendre ces API plus attractives, passant en revue les choses les plus et les moins importantes pour les développeurs. « Les développeurs ne se soucient pas de votre modèle d'affaires. Ils ne se préoccupent pas de la façon dont vous gagnez de l'argent », a-t-il déclaré. « Ils se moquent également de savoir si les services de l'API ont été écrits en Java, Node.js, Python, Ruby, PHP ou en C# », a-t-il ajouté.

Selon Kevin Kohut, le point essentiel est de ne pas obliger les développeurs à franchir un tas d’étapes pour accéder aux services délivrés par l’API. Les développeurs ne veulent pas avoir à gérer les processus complexes d'inscription ou devoir tout connaître des processus d'affaires du fournisseur pour utiliser leurs API. « Même si le modèle d'affaires est compliqué, le fournisseur doit arriver à le traduire dans une interface d’API moderne ». Ils ne veulent pas, non plus, avoir à traiter avec le marketing, les commerciaux, ou lire 30 pages sur la licence.

Des API RESTful pour travailler simplement

Alors, que veulent les développeurs ? « Ils veulent des API RESTful conformes aux standards, des exemples utiles en rapport avec l’usage réel de l’API, une approche claire de ce qu’elles font, et un système de monétisation simple », a déclaré Kevin Kohut. Pour être encore plus concret, il a placé côte à côte le menu, simple, d’un restaurant tex-mex de la chaîne de fastfood Chipotle – qui arrive en France - et le menu plus élaboré d’un restaurant classique. « Chez Chipotle, les clients peuvent obtenir exactement ce qu'ils veulent », a-t-il déclaré. Et il a conseillé aux fournisseurs d'API d’offrir aux développeurs « une expérience aussi facile et agréable que possible ». Selon lui, cette logique devrait s’appliquer aussi bien aux propres développeurs de l’entreprise qu’aux développeurs externes.

Pour sa part, Kevin Toms, développeur évangéliste du fournisseur de systèmes d'éclairage sans fil Philips Hue, a fait remarquer que si les fournisseurs avaient des API, les développeurs les utiliseraient. « Pourquoi devraient-ils les utiliser ? Qu’est-ce qu’ils peuvent en tirer ? », a-t-il demandé. Philips Hue propose un système d'éclairage coloré interconnecté, contrôlé par une API. « Les gens qui vendent des apps pour le système Hue se font effectivement pas mal d’argent. Les fournisseurs doivent penser à un business model pour les développeurs », a-t-il ajouté. « La commercialisation et les débouchés sont importants, et je pense qu’il faut soutenir en permanence les développeurs sur ce plan là » a-t-il encore déclaré. Cela implique par exemple de leur donner accès à une bonne documentation en ligne, de leur proposer des outils et de répondre à leurs questions. Les hackathons peuvent être utiles. « Mais les fournisseurs ne devraient pas livrer des produits qui sont en concurrence avec ceux de leurs développeurs », a ajouté Kevin Toms. « Les développeurs sont vos alliés. Ils rendent votre produit plus intéressant ».

L'API doit être considéré comme un produit 

Pearson, le groupe éditorial spécialisé dans l'édition éducative dont une partie est diffusée en ligne, a commencé son premier programme d’API en 2010. « Ça a été un succès », a déclaré Allen Rodgers, son directeur. Le programme actuel, appelé Learning Studio, permet aux utilisateurs de suivre des cours en ligne. « Les clients intègrent divers systèmes back-end pour offrir une vision globale à l’étudiant », a-t-il ajouté. L’éditeur a suggéré aux fournisseurs de démarrer avec un petit système. « Comme nous le disons aux fournisseurs, il est beaucoup plus facile d'ajouter des fonctionnalités que d’en supprimer ». Selon lui, leur proposition de valeur doit être attrayante et ils doivent rester souples. « Cela revient aussi à dire qu’ils ne peuvent pas se tromper », a-t-il déclaré. « Si les développeurs ne comprennent pas les termes réels et s’il n’y pas d’échantillon de code et d’applications, ils risquent de ne pas revenir », a déclaré Allen Rodgers pour finalement conclure : « Il faut considérer l’API comme un produit ».