API : et si Twitter se trompait ?

Twitter a changé ses règles. Si vous n’utilisez que l’application Twitter “officielle” sur votre mobile et le site sur votre ordinateur, vous n’aurez peut-être rien remarqué.

Mais si vous êtes un développeur qui travaille avec l’API Twitter, pour vous tout a changé : clairement, la question se pose de savoir si vous êtes encore le bienvenu.

Twitter comme Facebook ont commencé comme un rêve de développeur : une API ouverte, une base sur laquelle n’importe qui pouvait bâtir une application et contribuer à enrichir l’écosystème. C’est ce qui a permis à Zynga de construire un business de plusieurs centaines de millions de dollars sur l’API Facebook, un business qui a constitué jusqu’à 19% des revenus de Facebook.

Le problème, c’est que ça a aussi permis à Tumblr et Instagram de bâtir des réseaux concurrents à celui de Twitter en permettant aux nouveaux inscrits de retrouver leurs contacts sur le site. C’est ce qui a permis à de nombreux clients tiers comme TweetDeck (qui a fini par être racheté par Twitter) de proposer un meilleur service que l’originel et de “voler” l’audience de Twitter.

Facebook a choisi la publicité comme principale source de monétisation depuis longtemps, et est parvenu à relativement bien gérer son API de sorte qu’on puisse l’utiliser pour bâtir des applications rentables comme celles de Zynga mais qu’on ne puisse vraiment lancer un concurrent direct de Facebook. Twitter, par contre, s’est longtemps cherché un  modèle de monétisation rentable. Les nouvelles règles très strictes d’utilisation de l’API semblent avoir un but : s’assurer que tout le monde utilise Twitter via les canaux officiels et ainsi n’échappe pas à la publicité.

Ca semble évident, d’un point de vue économique, de réunir tous les utilisateurs dans un environnement clos et de les bombarder de publicité. Mais c’est un modèle sans imagination, une solution facile adoptée par tout le monde, un peu décevante de la part des esprits les plus brillants de la Silicon Valley. Et puis il faut bien comprendre une chose : l’investissement publicitaire global représente certes une somme colossale, mais il ne connaît pas la croissance exponentielle des startups californiennes. Toutes ne devraient pas compter uniquement sur la publicité pour se financer ou bien elles finiront par se battre entre elles pour les miettes d’un gâteau qui ne pourra pas nourrir tout le monde.

Une autre voie possible ?

Nous parlions la semaine dernière des sites qu’on appelle le “nouveau web” et de leur probable adoption de la publicité native. Le fait est que, quand on se positionne comme média et pas comme réseau social (et on peut arguer que c’est ce qu’est Twitter avant tout), la publicité est en effet une source de revenus naturelle et logique. Mais quand on est une plateforme, riche d’un “interest graph” comme Twitter, il y a autre chose à faire.

App.net a été pensé comme un réseau social sans publicité, et le succès de sa campagne Kickstarter a montré qu’il y avait une demande. Le fait est que lorsque, comme Facebook et Twitter, on devient un média qui doit vendre de la publicité, l’expérience utilisateur n’est plus la préoccupation numéro 1 des développeurs : il faut avant tout vendre des espaces. Au final, c’est prendre le risque de subir le même sort que Myspace : se noyer dans la pub.

App.net veut résoudre ce problème en proposant un service doublement payant : l’utilisateur paye pour y accéder, et les développeurs payent pour accéder à l’API. On doute que le grand public choisisse jamais d’utiliser un réseau social payant en masse, mais il y a une troisième voie : proposer un service gratuit, financé entièrement en faisant payer l’accès à la plateforme. De cette façon, l’expérience utilisateur reste au coeur du business model, puisque le but de tout le monde est le développement de bonnes applications.

Il n’y a peut-être pas autant d’argent dans ce modèle pour l’instant que dans la publicité, mais il pourrait s’imposer pour certains réseaux sociaux de niche. Après tout, la plateforme payante est un business model qui a plutôt bien fonctionné pour le Playstation Network, l’API Google Maps ou l’App Store d’Apple. Pourquoi pas pour un site ?