En installant l'application blackberry proposée par Twitter j'ai tout de suite pensé aux nombreuses starts up comme ubertwitter ou encore seesmic qui avaient investis sur des applications équivalentes et qui devaient maintenant penser que le futur de leur application pour ces appareils venait d'être chamboulé par l'arrivée de l'application officielle.
Ce cas n'est pas un cas isolé et beaucoup de starts up internet ont fait le choix de s'appuyer sur des API comme celles de Google ou encore celles de Twitter. En règle générale tout va bien jusqu'à l'arrivée du fournisseur de l'API lui même qui a plusieurs avantages par rapport aux utilisateurs de l'API :
-la base utilisateurs
-la légitimité de passer des partenariats (comme Twitter avec RIM)
-des fonctionnalités que lui seul peut proposer
-sa marque beaucoup plus forte
-le fait d'arriver après les autres mais de contrôler la bataille (avec l'API)
-de pouvoir tuer tous ses concurrents en coupant l'API ou en la réduisant
Tous ces éléments font que monter un business uniquement sur une API est risqué et que du jour au lendemain le produit peut ne plus exister...
Imaginez 30 secondes si Google changeait les règles d'utilisation de l'API Google Maps? Quoiqu'il en soit ce risque est à prendre en considération si vous travaillez sur un produit basé sur des API tierces.
9 Commentaires
S’appuyer sur une API est risqué, mais il ne faut pas trop pessimiste non plus. Il est vrai que Twitter peut couper son API du jour au lendemain, mais ils y perdront surement une grosse masse d’utilisateurs, tant les façons d’utiliser le service sont nombreuses.
C’est encore plus le cas pour Google Maps. Couper l’API en cas de faillite OK, mais le faire volontairement pour tuer la concurrence serait du suicide tant le nombre de service basés dessus est vase et diversifié. Google ne pourrait jamais couvrir toutes les utilisations de l’API, et l’éteindre reviendrait à se tirer une balle dans le pied, en perdant la confiance des développeurs sur laquelle l’entreprise à en partie basé sa croissance.
Le risque que l’on prend quand on utilise une API est à mon avis plus lié à la santé de l’entreprise qu’à une crainte de voir l’entreprise fermer cette API.
Pour le cas de Seesmic, c’est plus risqué dans le sens ou ne s’appuie pas sur l’API, elle est à 100% construite par dessus, sans aucune façon de rebondir en cas de coupure. Mais si LLM est pote avec les fondateurs de Twitter, il aura des infos à l’avance …. ou pas ^^
Ça fait peur quand on y pense. Mais j’imagine que l’API crée un genre d’écosystème que le fournisseur de l’API ne peut pas ignorer. Si Google enlevait son API Google Maps, ça foutrait un sérieux bordel autant pour les webmestres que Google qui aurait une grogne incroyable à gérer!
Je compare ça à l’aligator qui se fait nettoyer les dents par des oiseaux. Il pourrait manger les oiseaux, mais il ne le fait pas parce que ça lui rapporte plus en bout de ligne.
Mais comme dans tous, il ne faut pas mettre tous ses oeufs dans le même panier…
A l’inverse, un service qui dépend trop des utilisations qui sont faites via son API est aussi à la merci de ces usages. Le taux de désaffection d’un Twitter ou d’un Googple Maps serait très élevé si jamais il n’était plus possible de passer par son outil préféré ou s’il n’était plus disponible sur son site de référence.
La balance ne penche pas nécessairement du côté de l’éditeur…
Je pense que c’est aussi aux utilisateurs de l’API d’être assez malin pour la combiner avec d’autres APIs d’autres services pour justement créer un nouveau service innovant ! Et si par exemple on utilise l’API google maps, pourquoi ne pas prévoir au début du dev. le scénario cata, en dev. dès le départ un switch possible vers Bing Maps ou Yahoo Maps par exemple….
Ou encore celle de Mappy… Mais cela coute bien cher de développer et de maintenir pour 4 API différentes non?
Twitter viens d’acquérir Tweetie, un client pour twitter parmis les plus populaires.
Cette news arrivant le lendemain de la mise a dispo du client officiel twitter pour blackberry…
Ton article résonne d’autant plus.
Il est très difficile de concevoir a mes yeux un business model 100% dépendant d’un tiers. c’est accepter de ne pas avoir la maitrise complète…
Un peut comme pour un producteur, de n’avoir qu’un seul client, impensable…
Mais si je peut comprendre des entrepreneurs qui “tentent”, je comprend bien moins les investisseurs.
Ou alors, la stratégie de rachat est le seul vrai objectif… mais combien de rachat pour de prétendant ?!
L’analyse était donc bonne ;)
S’appuyer sur une API peut être risqué pour une entreprise http://bit.ly/aytAHy
This comment was originally posted on Twitter
S’appuyer sur une API peut être risqué pour une entreprise : http://bit.ly/9esfKx
This comment was originally posted on Twitter
One Trackback
[...] de son écosystème d’applications tiercesSouvenez vous il y a quelques temps j'évoquais le risque de monter un business uniquement sur des API d'une seule société (Twitter, Google Maps…). Et bien cela va peut être le cas pour ceux qui [...]