John Musser connaît les API. En tant que fondateur de Programmable Web, John a rencontré des milliers d'API et de nombreux business modèles. Il a récemment partagé son expérience dans une keynote à la conférence API Strategy 2013.
La question qu'on lui pose le plus fréquemment sur les API est "comment gagnez-vous de l'argent avec ?". La réponse dépend du pourquoi... "pourquoi voulez-vous une API ?". Il y a beaucoup de raisons d'avoir une API et cela correspond au premier des cinq secrets des API qu'il présente dans sa keynote, "une stratégie d'API n'est pas un business modèle d'API". Une stratégie d'API correspond au "pourquoi" vous voulez une API et le modèle de business au "comment" vous gagnez de l'argent avec.
Si on regarde en 2005, au début des API et de la période où Google Maps a décollé, il y avait quatre types de base pour les business modèles d'API : "libre", "le développeur paie", "le développeur est payé" et "indirect". Aujourd’hui, en 2013, il y a toujours les mêmes quatre types de business modèles d'API de base mais chaque type s'est étendu dans une variété et des manières différentes de fournir et de monétiser ses API. Le second secret de John est que "la plupart des API ont plus d'un type de retour sur investissement".
Dans la suite de son discours, John décrit en profondeur chacun des modèles de business de base, en commençant par le "libre". Contrairement à la pensée commune, le "libre" n'est pas le modèle de business d'API le plus important. John cite Facebook comme exemple, ainsi que les API du gouvernement et du secteur public, mais ces API libres ne sont qu'une "infime partie" de tous les modèles de business d'API.
La catégorie suivante décrite par John est "le développeur paie" où les développeurs d'applications paient pour les services rendus par l'API. Cela comprend de nombreuses sous-catégories comme "pay as you go" dans laquelle les développeurs paient uniquement pour les services et les ressources qu'ils consomment réellement. L'exemple de John est ici les Web Services d'Amazon qui stipulent dans leur plan de tarification : "Payez uniquement pour ce que vous utilisez. Il n'y a pas de frais minimum". Une seconde sous-catégorie est le modèle "à plusieurs niveaux" offert par des sociétés comme Mailchimp qui fournissent un prix plus bas lorsque vous consommez un volume plus important de leurs services. "Freemium" est un modèle bien connu où les fonctionnalités de base sont fournies gratuitement mais pour une somme supplémentaire vous pouvez ajouter des services comme des API supplémentaires, des SLA plus importantes, un manager de compte, etc. John cite Compete et Google Maps comme des exemples de modèles freemium. Le tarif "Unit-based" est encore une autre sous-catégorie comme l'offre de Sprint où les différentes fonctionnalités de l'API engendrent des charges différentes. Le dernier exemple de "développeur paie" est le concept familier pour les utilisateurs d'API de "frais de transaction" où un pourcentage de la transaction est facturé. John cite PayPayl, Stripe et Chargify comme exemples de ce modèle.
L'inverse du "développeur paie" est le modèle de business "le développeur est payé", c'est la catégorie suivante décrite par John. Cette catégorie a plein d'autres sous-catégories comme le modèle "de partage des revenus d'affiliation" proposé par le programme d'affiliation d'Amazon où les développeurs sont payés en partage de revenus pour les références clients. John donne l'exemple de mysimon.com et howstuffworks.com, des sites de comparaison qui utilisent l'API shopping.com pour soutenir les comparaisons de produits et gagner des parts de revenus des taux de clics. John précise que le partage de revenu d'affiliation n'est pas un "petit business". Expedia tire 90% de ses revenus d'un réseau d'affiliation en utilisant les API Expedia qui représentent 2 milliards de dollars par an. Enfin, il y a un modèle "de revenus partagés récurrents" utilisé par les sociétés comme rdio.com, où les affiliés qui proviennent de nouveaux clients pour des achats d'abonnements sont payés une part du chiffre d'affaires pour toute la durée de vie du client.
Le troisième secret pour les modèles de business d'API est "vous devez bâtir votre modèle de business dans votre API". C'est le plus grand secret que John veut livrer à son public pour qu'il l'exploite. Par exemple, le programme d'affiliation d'Amazon était une extension naturelle de son modèle de distribution.
En dehors des quatre modèles de business initiaux, John évoque maintenant la catégorie "Indirecte" dont il pense qu'elle représente la manière la plus intéressante de monétiser les API. La première sous-catégorie est "l'acquisition de contenu". Des business comme eBay et Twitter ont besoin d'acquérir rapidement du contenu afin de se développer. Ils utilisent ainsi des API pour faciliter l'acquisition de contenu. Les API d'eBay permettent aux utilisateurs puissants de créer des annonces de masse dans la place de marché. Twitter dérive et distribue des contenus presque exclusivement à travers des API et des applications tierces. "La dissémination de contenu" est la prochaine sous-catégorie, le New York Times a par exemple beaucoup de contenu et utilise des API pour syndiquer le contenu vers les partenaires.
La vente incitative en SaaS est un autre modèle de business de la catégorie "Indirecte". Salesforce.com offre des API d'accès à ses plates-formes, mais uniquement aux sociétés qui paient la licence entreprise. Salesforce.com sait que l'intégration d'API est importante et l'utilise pour inciter les clients à souscrire des abonnements plus importants. John caractérise les API comme "la glue de tous les SaaS". L'intégration ajoute de la valeur aux applications SaaS et fournit un facteur de rigidité qui réduit considérablement le taux de désabonnement. Le secret numéro quatre de John pour les modèles de business d'API est que "les modèles de business d'API ne sont pas de taille unique".
Le dernier modèle de business que John présente est le modèle d'"utilisation interne" où les sociétés utilisent des API pour supporter leur propre business. NPR a développé des API pour livrer du contenu aux sites web, applications iPad et mobiles. Plus de 99% du trafic de l'API Evernote vient des applications iPad, des applications mobiles et des applications partenaires. Et Netflix utilise ses API pour supporter la diffusion de contenu à plus de 800 types de dispositifs différents. Ainsi le cinquième et dernier secret d'API est "l'utilisation interne peut être le cas d'utilisation le plus important de tous".
A propos de l'auteur
Saul Caganoff est le CTO de Sixtree, un cabinet australien de conseil en intégration de systèmes. Il a une grande expérience en tant qu'architecte et ingénieur dans des projets majeurs d'intégration et de développement logiciels en Australie, aux Etats-Unis et en Asie. Sur le plan profesionnel Saul s'intéresse à l'architecture à tous les niveaux (entreprise, applications et solutions), aux systèmes distribués, aux applications composites, au cloud computing et aux API pour le cloud.