Une start-up doit-elle forcément avoir une API ?
La semaine prochaine, j’animerai un panel à APIdays Paris. Il sera consacré aux investissements capital risque dans les APIs. Dans ce contexte, plusieurs réflexions me sont venues à l’esprit et il me semblait intéressant de vous les partager. Selon les situations, les APIs peuvent incarner des enjeux assez différents.
Dans le cadre d’une startup — j’entends par-là une entreprise ayant pour objectif de générer une croissance mensuelle à deux chiffres, avec un modèle réplicable d’un marché à l’autre — les APIs peuvent être un enjeu stratégique pour générer de la croissance. Dans d’autres cas cependant, les APIs sont un projet certes fondamental, mais passant après toutes les urgences liées à “scalabilité” (on dit “adaptabilité en français). Laissez-moi vous expliquer.
Le but de l’investisseur en capital risque est de prendre des participations dans des pépites pouvant à terme devenir de gigantesques machines à cash. Alors demandez-vous, qu’est-ce qu’ont en commun la plupart des grands succès du secteur technologique : Apple, Amazon, Facebook, Über, etc. ?
Simple : ce sont des plateformes. Ces boîtes ont créé des écosystèmes autour d’elles, qui viennent renforcer leur position et les transformer en pieuvre du web. Les tentacules sont partout. Ceci est rendu possible par les APIs que ces sociétés mettent à disposition.
Des meutes de développeurs peuvent ainsi construire sur ces plateformes. Les avantages sont multiples. En mode non-exhaustif : (i) on externalise le risque, Apple ne perd jamais d’argent si une application n’a pas d’utilisateurs, Amazon non plus, etc. et (ii) l’innovation est optimisée, car des équipes de startup bâtissent avec leurs idées toutes fraîches, sans avoir à être ralenties par l’organisation d’une grosse boite, sclérosée par sa taille.
La plateforme peut alors observer ce qui est bâti sur son écosystème, et selon les cas, racheter le produit ou l’équipe, ou juste copier-coller la fonctionnalité, un peu cruel mais efficace.
Bref, être une plateforme semble être une condition clé pour devenir un géant. Pourtant, lorsque l’on se penche sur certains succès, force est de constater que les APIs peuvent parfois être laissées de côté, au moins pour un temps.
Un bon exemple est Eventbrite : cette startup est valorisée à un milliard de dollars et fait donc partie du cercle très fermé des “licornes”. Cependant, ce service n’est pas reconnu comme générant sa valeur depuis ses APIs : seuls 15% des revenus seraient liés aux APIs, et encore, pas forcément de façon directe.
Pour nous parler de cela, nous avions d’ailleurs eu la chance d’accueillir Renaud Visage à APIdays Paris, l’année dernière. Il est co-fondateur d’Eventbrite et en est le directeur technique.
Il nous avait rappelé qu’Eventbrite avait sorti son API deux ans après son lancement, soit en 2008. Cette interface eut un succès intéressant, mais le choix fut fait de ne pas “eat your own dog food”. Ce qui signifie : les équipes techniques travaillant sur le produit n’utilisaient pas elles-mêmes des APIs.
Le but de l’investisseur en capital risque est de prendre des participations dans des pépites pouvant à terme devenir de gigantesques machines à cash. Alors demandez-vous, qu’est-ce qu’ont en commun la plupart des grands succès du secteur technologique : Apple, Amazon, Facebook, Über, etc. ?
Simple : ce sont des plateformes. Ces boîtes ont créé des écosystèmes autour d’elles, qui viennent renforcer leur position et les transformer en pieuvre du web. Les tentacules sont partout. Ceci est rendu possible par les APIs que ces sociétés mettent à disposition.
Des meutes de développeurs peuvent ainsi construire sur ces plateformes. Les avantages sont multiples. En mode non-exhaustif : (i) on externalise le risque, Apple ne perd jamais d’argent si une application n’a pas d’utilisateurs, Amazon non plus, etc. et (ii) l’innovation est optimisée, car des équipes de startup bâtissent avec leurs idées toutes fraîches, sans avoir à être ralenties par l’organisation d’une grosse boite, sclérosée par sa taille.
La plateforme peut alors observer ce qui est bâti sur son écosystème, et selon les cas, racheter le produit ou l’équipe, ou juste copier-coller la fonctionnalité, un peu cruel mais efficace.
Bref, être une plateforme semble être une condition clé pour devenir un géant. Pourtant, lorsque l’on se penche sur certains succès, force est de constater que les APIs peuvent parfois être laissées de côté, au moins pour un temps.
Un bon exemple est Eventbrite : cette startup est valorisée à un milliard de dollars et fait donc partie du cercle très fermé des “licornes”. Cependant, ce service n’est pas reconnu comme générant sa valeur depuis ses APIs : seuls 15% des revenus seraient liés aux APIs, et encore, pas forcément de façon directe.
Pour nous parler de cela, nous avions d’ailleurs eu la chance d’accueillir Renaud Visage à APIdays Paris, l’année dernière. Il est co-fondateur d’Eventbrite et en est le directeur technique.
Il nous avait rappelé qu’Eventbrite avait sorti son API deux ans après son lancement, soit en 2008. Cette interface eut un succès intéressant, mais le choix fut fait de ne pas “eat your own dog food”. Ce qui signifie : les équipes techniques travaillant sur le produit n’utilisaient pas elles-mêmes des APIs.
En conséquence, une scission s’est peu à peu faite : le produit a évolué, sans que les APIs ne soient mises à jour. Résultat : le développeur voulant utiliser les APIs Eventbrite devait renoncer à mille nouveautés. Plus le fossé se creusait, plus il était dur de le combler.
Le cas emblématique de la boîte qui a évité ce piège est Amazon. Jeff Bezos avait un jour décidé qu’il virerait tout développeur n’utilisant pas une interface de service (j’avais raconté cette histoire en détails ici). Cela demande une discipline et une vision que peu de personnes peuvent avoir. Et parfois, l’urgence rend impossible cet effort, au moins en apparence.
Eventbrite a eu une croissance tellement gigantesque entre 2008 et maintenant, que mille autres sujets passaient avant les APIs. Il faut s’imaginer face à la question suivante : “est-ce que je travaille sur mes APIs ? Ou bien est-ce que je prends le risque que mon produit se crash ? Ou même qu’il se fasse doubler par un compétiteur au niveau des fonctionnalités ?” Pendant que l’on travaille à faire le net au niveau des APIs, il est en effet impossible d’innover et sortir des nouveautés sur le produit.
Le choix est cornélien : “je continue à bidouiller sur mon code spaghetti et j’absorbe la croissance autant que je peux ? Ou je me mets au clair pour absorber toute la croissance plus tard ?”
Quasi impossible de répondre à cette question de façon automatique. À chaque cas, il y a plusieurs solutions à agencer et c’est pour cette raison que des startups ayant du succès mettent de gros budgets pour recruter des profils sachant gérer ces problématiques complexes, à mi-chemin entre le business et la technique.
Eventbrite, on l’a compris, a choisi d’absorber la croissance, et de ne pas devenir comme son concurrent allemand Amiando, un produit dont plus personne n’entend parler, faute d’évolution. Du coup, ils sont aujourd’hui en position de leader et peuvent prendre le temps de mettre à jour l’arrière du décor pour un jour dominer l’univers.
Un autre exemple pour illustrer : Wunderlist est le produit phare de 6Wunderkinder, une startup assez iconique de la scène berlinoise. Cette application de “to do list” avait levé $19M en novembre 2013, avec un fonds US emblématique : Sequoia Capital. Lors de la levée, la startup avait annoncé qu’elle lancerait sa V3 début 2014, avec une API qui suivrait “sous peu”.
La V3 est bien sortie, mais avec six mois de retard, le 31 juillet. Quant à l’API, elle n’est toujours pas là. Wunderlist a des millions d’utilisateurs et une équipe très brillante qui a débauché un CTO star en janvier 2014, juste après la levée pour mettre en oeuvre cet agenda ambitieux. En effet, si Sequoia a investi, c’est parce qu’ils veulent que 6Wunderkinder devienne une boîte valant plusieurs milliards, donc il faut devenir une... plateforme. Sur les forums du service, on peut même percevoir la demande des développeurs voulant construire sur Wunderlist “Où qu’elle est votre API ? Pas là ? Mais elle arrive quand ?”.
Répondre à la question “quand” n’est jamais évident. Typiquement, migrer vers une base de code orientée services est un projet très complexe, impliquant beaucoup de décideurs. Si la startup n’a pas eu la discipline d’évaluer et mesurer le temps que les développeurs passent sur les différentes tâches, il est impossible de donner une vraie date de livraison. La tentation est toujours de parler en mois, car cela sonne mieux que les années. En réalité, cela peut facilement prendre 2-3 ans, ce qui est une éternité dans secteur internet, où les croissances mensuelles à deux chiffres sont monnaie courante, ce qui signifie que vous pouvez vous faire rattraper par un compétiteur.
L’API est donc quelque chose qu’il faut absolument avoir si l’on a de grandes ambitions. Mais ce n’est pas forcément la cause directe du succès. Par contre, c’est un facteur massif lorsqu’il s’agit de “scaler” ce qui est la définition d’une startup qui réussit et passe à l’âge adulte.
Les problématiques techniques sont si complexes, qu’il est souvent impossible d’évaluer exactement le temps que prendra la transition d’un bloc de code monolithique vers un système distribué, orienté services.
L’investisseur cherchant les pépites doit donc lui-même arbitrer ces questions et tâcher de sentir si la startup pourra encaisser la charge en cas de succès. La vie est toujours une question de compromis et les réponses varient sans cesse. Nous parlerons donc de ces problématiques fascinantes à APIdays, avec Raffi Kamber d’Alven et Nicolas Debock de Balderton Capital. Pourquoi "fascinantes" ? Tout simplement parce que s'il n'y a pas de solution miracle ou de recette fonctionnant à tous les coups, cela signifie que gérer ces questions est un art. Je tweeterai la vidéo si vous n’y êtes pas et que cela vous intéresse.