API Days Berlin, ou comment le monde devient programmable

Les Berlinois se sont arrangés pour condenser plus de dix événements tech sur une même semaine. Comme je l’ai déjà écrit, Paris pourrait vraiment s’inspirer de cette aptitude à s'unir et communiquer d’une seule voix. La semaine a donc débuté avec deux événements majeurs : Next Berlin et API Days. 

Next Berlin est organisé par Sinnerschrader, une grande agence de Hambourg. L’événement est donc très orienté communication, media et investisseurs. Une sorte de petit LeWeb très intéressant pour découvrir le marché du digital allemand. J’y étais l’année dernière mais en l’occurrence, j’ai dû m’en tenir à un autre événement très dense : API Days. 

Cet événement 100% dédié aux APIs avait déjà eu lieu à Paris, Madrid ou San Francisco, mais ce fut la première édition berlinoise. En rassemblant plus de 250 développeurs et architectes, l’idée est de fédérer les acteurs d'un écosystème en plein boom. Le site Programmableweb recense déjà plus de 11,000 APIs publiques, qui ne représentent que la partie émergée de l’iceberg. Beaucoup d’APIs sont en effet privées ou réservées aux partenaires. 

L’adage dit que si en l'an 2000, tout business devait lancer un site web, en 2014 tout business doit proposer une API. Avoir une API n’est néanmoins pas une fin en soi. API Days tâche donc de fournir les outils pour y voir clair et comprendre les possibilités réelles. Je vais ici tâcher d’y développer les perspectives présentées, même si je ne serai pas exhaustif. 

Derrière une API, il doit toujours y avoir une vision guidant le business. Sans simplifier à outrance, on peut dégager deux grands enjeux, selon la taille de l’entreprise souhaitant capitaliser sur les APIs. 

La start-up fait ainsi souvent appel aux APIs pour se lancer plus rapidement, et ne pas perdre de temps en réinventant la roue. Je discutais récemment avec le CTO de Front : cette jeune application permet de gérer les e-mails de façon collaborative. 

Techniquement, pour lancer ce produit, il s’agissait de recréer un Gmail collaboratif à destination de l’entreprise. Il est impossible de d’atteindre un tel objectif en quelque mois si l’on part de zéro. L’équipe a donc utilisé plus de dix APIs différentes, pour construire un service 100 % opérationnel en moins de six mois.

Les APIs peuvent alors être vues comme des "briques technologiques", du lego à assembler selon ses besoins. Le gain se fait tant sur la rapidité d’implémentation, que sur la qualité du service consommé.
Il peut s’agir d’e-mail, de paiement, d’information de contacts, d’hébergement, etc. On profite directement d’un service robuste et éprouvé. C'est la perspective "startup". 

Pour la grande entreprise, l’enjeu est souvent différent. L’objectif premier ne sera pas toujours d’aller plus vite, mais plutôt de rationaliser son architecture. Comme je l’ai écrit dans ma dernière chronique, le cloud pour les grandes entreprises est largement un mythe. 

La révolution API dans les grands groupes ne commence donc pas en consommant des APIs externes, mais s’instille plutôt par des APIs internes, dont la SOA constitue la première étape. Les grandes entreprises consomment donc la partie immergée de l’iceberg, celle représentant environ 5 à 10 fois le nombre d’APIs publiques (soit <50,000…), selon une estimation de 3Scale. 

Ce qui est interne peut ensuite devenir externe : on expose alors une API au public pour générer de la valeur - le but est de devenir une plateforme, monétiser, etc. Dans ce second temps, l’API devient alors un produit à part entière. 

On rejoint ici le coeur du message de mon intervention, où j’expliquais l’importance de traiter son API comme un produit. 

Les implications sont multiples, mais en résumé : il faut une approche “product management” qui englobe l’ensemble des problématiques marketing, vente, technique, design, etc. Pour produire une API externe, il est nécessaire d’adopter une perspective d’ensemble et de ne pas s’en tenir à un point de vue uniquement technique ou marketing. 

En conséquence, il faut soit s’appuyer sur équipe technique très impliquée qui n’oublie jamais l’expérience de l’utilisateur final (le développeur) ; soit s’appuyer sur une personne synthétisant ces différents rôles. C'est le "API Product Manager". Cela peut paraître évident, mais les écueils sont ultra-courants. Pour illustrer mon propos, voici un scénario de ratage typique. 

D’abord un Product Manager rédige des spécifications fonctionnelles pour l’API sans rien comprendre aux implications techniques “on veut si, puis ça pour le client”. Ensuite l’équipe technique pond une API en prenant des décisions unilatérales quant au design, puis fournit une documentation plus proche de la machine que de l’humain. Au final, le tout est envoyé au département marketing qui n’aura ni les connaissances, ni les ressources nécessaires pour mettre au point une communication claire. À ce tableau, ajoutez les équipes Sales qui découvrent au fil de l’eau que ce qu’elles vendent quelque chose qui n’existera en fait pas. 

Ce type de “fail" est courant, mais peut être évité si l’équipe API est petite, intelligente et très efficace. Dans tout autre configuration, il faudra que quelqu'un soit en charge, avec pour rôle d’incarner la vision globale et synthétique. Cette personne devra avoir des compétences dans tous les domaines précités, pour ainsi être légitime auprès des différentes équipes à gérer. Cela signifie en particulier qu’elle est une excellente “manager” qui n’aboie pas des ordres aux développeurs, une façon assurée de démotiver les troupes ou de faire accoucher d’un produit de piètre qualité. 

À cette vision haut niveau vient se greffer les questions opérationnelles. Le champ étant entièrement nouveau, les discussions sont multiples. Les débats vont bon train. D’un côté, des choix sont faits pour composer avec la réalité : les API REST sont donc rarement REST au sens strict du terme. 

De l’autre, certains développeurs militent pour l’Hypermedia, que l’on peut définir comme une prolongation de l’esprit REST. Ces derniers sont assez convaincants, mais ne représentent pas forcément une grande organisation ayant fait ce choix, ce qui sape leur légitimité auprès de l’audience “enterprise”. 

Une API Hypermedia sera en effet plus intuitive et facile à prendre en main, car elle peut se “découvrir”, un peu comme lorsque l’on navigue sur un site web. Cette découverte se fait par des liens retournés avec chaque requête, et génère donc des échanges plus verbeux, donc moins efficaces. 

Face à ce débat, on retrouve à nouveau la division petit VS gros. Les startups sont plutôt REST ou Hypermedia, tandis que le monde de l’entreprise s’incarne essentiellement dans des interfaces SOAP. Celles-ci permettent un meilleur contrôle des ressources exposées, et sont donc préférées par les entités voulant faire primer la sécurité, au détriment de la facilité d’utilisation. 

Mon but ici n'était pas d'être exhaustif, ou d'expliquer en profondeur, mais de donner un panorama d'une tendance qui emporte tout sur son passage. Les APIs libèrent le potentiel de l'internet, et il est donc vital de prendre le temps d'en comprendre les concepts clés. La prochaine édition d'API Days aura lieu à Barcelone, fin mai. La suivante se tiendra à San Francisco en juin, et sera consacrée entièrement à l'automobile connectée. 

Si vous désirez mieux comprendre les APIs, je ne peux que recommander l'excellent guide publié par Zapier.