Exotech.biz

Web, Technology & life by Bastien Labelle

Aller au contenu | Aller au menu | Aller à la recherche

Buffer.me, un beau mashup YouTube

Youtube est un des sites les plus fréquentés de la planète. Google dépense d'ailleurs un million de dollars par jour (oui, vous avez bien lu) en termes d'infrastructure matérielle, bande passante, etc. C'est peut-être d'ailleurs pour cela qu'ils ne souhaitent pas trop investir en recrutant un bon UI/UX designer, et que Youtube est un des sites web 2.0 les plus moches.

Recherche de Paolo Nutini sur Buffer.me

Heureusement, Youtube bénéficie d'une API complète, ce qui implique qu'il est possible de construire des webapps et des mashups basés sur le contenu de Youtube. Buffer.me est une application riche basée sur l'API de Youtube. Elle a été réalisée faite par un designer (dont je ne connais malheureusement pas le nom) afin d'améliorer l'expérience utilisateur de Youtube en proposant une interface faite entièrement en flash.

Encore en beta privée, la beauté de l'interface et les jolis effets font cependant oublier ses défauts de jeunesse. Espérons qu'à l'avenir il soit possible d'intégrer les fonctions spécifiques à son compte, comme l'ajout de favoris ou encore les fonctionnalités sociales qui permettent de partager du contenu.

Quelle stratégie pour la monétisation des API gratuites?

Je m'interrogeais il y a quelques temps sur la viabilité des services web gratuits. Avec le lancement de FireEagle cette nuit, et le lancement de BOSS, l'API de recherche de Yahoo il y a de cela quelques semaines, ma réflexion a eu le temps de mûrir un peu.

J'étais persuadé lors du dernier billet que de grandes sociétés telles que Yahoo pouvaient se permettre de lancer un service web en grande pompe sans se soucier de la contrepartie financière, le tout étant compensé par d'autres services fournis par l'entreprise, comme un moteur de recherche ou un webmail. Mais Yahoo est une société, et a pour but de faire de l'argent, et être rentable, et quid des start-ups qui ont beaucoup moins de moyens?

Comment donc monétiser un service web gratuit?

La première solution, à court terme, serait de monétiser indirectement l'API via la publicité. Il ne s'agit pas de faire de la publicité sur une autre partie du site, mais de donner un moyen pour l'application exploitant l'API de se monétiser. C'est d'ailleurs ce que semble faire Yahoo, qui devrait permettre d'intégrer un système de publicité afin que tout le monde soit gagnant (sauf peut-être les annonceurs, mais c'est une autre histoire).

La deuxième solution quant à elle viserait plutôt le long terme, et n'est rien d'autre que le rachat. En effet, fournir une API permet de gagner des parts de marchés en fournissant les données aux "concurrents". Prenons le cas de BOSS. Yahoo va gagner des parts de marché en fournissant une API de recherche exploitée par des mashups. Si l'un d'eux commence à devenir un concurrent sérieux ou vraiment innovant, alors il y a de fortes chances de voir une acquisition de la part de Yahoo.

La troisième possibilité vient quant à elle trouver une solution au problème récurrent des API, je veux bien entendu parler de la scalabilité. Le modèle est très connu, il s'agit du modèle Freemium. On en parle chez GigaOM récemment en évoquant une éventuelle solution pour Twitter, mais il me semble que Google table déjà sur ce modèle avec ses différentes API. Il s'agit de limiter les accès à une ressource, et de faire payer au delà de cette limite les gros consommateurs.

Voilà donc trois manières de monétiser une API. Il est encore trop tôt pour pouvoir dire que telle façon a plus souvent marché qu'une autre, mais la mode étant le pay as you consume, j'imagine volontiers que la troisième solution, basée sur le modèle freemium et la tarification en fonction de la consommation devrait s'imposer, les autres solutions n'étant peut-être pas adaptées à toutes les entreprises.

Quand les Web Services Amazon provoquent le chaos du Web 2.0

Au premier abord, les Web Services d'Amazon qui couvrent des services liés au cloud computing, notamment Platform as a Service (EC2) ou encore Infrastructure as a Service (S3), sont très avantageux pour de nombreuses start-ups. En effets, ces derniers permettent de bénéficier d'infrastructures haute disponibilité à moindre coût, étant donné que la facturation se fait en fonction de la consommation.

Amazon Web Services

Le succès d'Amazon dans ce domaine n'est plus à faire, de nombreuses Startups utilisent notamment S3, je pense par exemple au service d'avatar décentralisé Gravatar, ou encore à Twitter qui l'utilise aussi pour ses avatars, mais aussi Pownce qui y gère tous ses fichiers, mais aussi certains blogs, comme Center Networks. Dans la nuit de dimanche à lundi, les Web Services d'Amazon ont connu un gros downtime, qui a provoqué l'indisponibilité des sites cités plus haut, mais aussi de nombreux autres.

Les raisons sont désormais révélées, il s'agissait en fait d'un problème de load-balancing. L'essentiel étant que tous les systèmes sont redevenus stables. Cependant, c'est la deuxième fois de l'année que les AWS connaissent un sérieux downtime.

On peut alors légitimement se demander si externaliser les services est judicieux ou non. A cette question, je répondrais sans hésitation oui. Pour plusieurs raisons. D'abord en termes de coût, bien évidemment, et c'est d'ailleurs le principal intérêt. Mais l'aspect compétences n'est pas non plus négligeable: derrière les AWS, il y a des experts en scalabilité. Prenons par exemple un service comme Twitter, qui a déjà beaucoup de mal à assurer en termes de scalabilité: Il connait beaucoup plus de downtimes qu'en a connu Amazon S3. En imaginant que les avatars ne soient pas externalisés, on peut facilement déduire que ce seraient de nouveaux problèmes à la charge d'une petite équipe.

Pour toutes ces raisons il me semble que les services qui tournent autour du cloud computing comme Amazon S3 sont malgré les downtime de très bonnes solutions. Qui dit que gérer ses propres serveurs va permettre d'éviter ces downtimes? L'administration système est après tout un métier à part entière!

PicsViewr, regardez les photos Flickr différement!

C'est quand je vois PicsViewr que je me dis que les API des différentes applications web peuvent devenir très intéressantes. Avec ses 7 modes de visionnage différents, c'est 7 expériences utilisateurs que vous pouvez tester. PicsViewr exploite en effet l'API de Flickr, certainement la plus belle communauté de photographes, mais aussi une des plus grosses base de données de photographies.

PicsViewr - Polaroïd Gallery

La majorité des modes de visionnage sont plus ou moins classique, faits à base de HTML, CSS, Javascript ou en full-Flash, mais je note qu'il y a certains modes très innovants, comme la vue en mode Polaroïd qui n'est pas sans rappeler certaines démos de Microsoft Surface, et également le Tiltviewer, qui reprend le nom et les bases du script portant le même nom. Il reste cependant quelques problèmes d'anti-aliasing pour que le tout soit parfait, mais l'expérience utilisateur est assez bluffante.

Un beau travail développé par des frenchies (ou un frenchie, à vrai dire, je ne sais pas). J'irais même jusqu'à dire que c'est certainement un des mashups Flickr les plus intéressants avec PicLens.

Note: mes photos sont visibles sur http://www.picsviewr.com/photos/bastienlabelle/

Quelles solutions pour la scalabilité des API?

L'API d'une application web permet aux développeurs de créer leurs propres programmes pour utiliser ou créer de nouveaux usages à l'application déjà existante. Nombreux sont les sites web qui en disposent, je pense notamment au pionnier Flickr, dont les mashups sont innombrables, à Delicious, qui permet de sauvegarder ses favoris via le site web mais aussi sur Firefox. Plus récemment, les services de micro-blogging comme Twitter ont grâce à leur API trouvé de nouveaux usages: Des mashups de recherche comme l'excellent Summize. Et il y a aussi Pownce, qui possède un client AIR très agréable.

Comme Rémian le remarque très bien sur son blog, fournir une API aux développeurs peut s'avérer parfois très dangereux, notamment dès lors qu'une application est mal codée, ou qu'elle abuse intentionnellement. Ces usages révèlent une faiblesse majeure et pourtant essentielle: le problème de la scalabilité, qui implique qu'une application ou un service doit pouvoir supporter une charge de traffic et de connexions très importantes.

Hacker 1992

Il y a d'abord une phase essentielle d'optimisation logicielle, qui implique le code, la base de données, mais aussi parfois le système d'exploitation: il est essentiel de gagner du temps à tout les niveaux, car le temps gagné implique que l'on peut faire bien des choses pendant ce temps libre, à commencer par répondre à plus de requêtes, et donc gagner en scalabilité.

Mais la vraie problématique se situe au niveau des serveurs. Faut-il plus de serveurs dès lors qu'on commence à être saturé? La plupart des administrateurs systèmes auront tendance à répondre que bien souvent ce n'est pas la faute aux serveurs, mais aux développeurs qui codent mal leurs applications. Et pourtant, une application a beau être bien codée, les serveurs arrivent souvent à saturation.

Et j'aurais tendance à penser que la vraie solution passe par les offres de platform as a service du genre Google App Engine. C'est une solution qui semble avantageuse car elle est basée sur le pay as you consume, mais aussi techniquement, car ces offres sont basées sur des technologies de cloud computing qui favorisent un déploiement facile, du fait de l'utilisation des technologies de virtualisation.

Les récents problèmes rencontrés par les différents services, par ailleurs essentiellement ceux de micro-blogging, me poussent à penser que les offres de platform as a service devraient exploser dans les prochains mois à venir, un peu à l'image des offres d'infrastructure as a service de type Amazon S3, qui sont devenues incontournables ces derniers mois.

Note pour moi-même: penser à faire bientôt un dossier Cloud, IaaS, PaaS, SaaS pour ne pas perdre mes visiteurs ;)

Un service peut-il survivre seul?

Comme on peut le constater depuis ces derniers mois voir années, les services (j'entends par service une API) florissent à travers la toile. Les services web sont les coeurs de nos applications web actuelles. En effet, ils sont partout et sont très utiles. Grâce à eux, il est possible par exemple d'utiliser Twitter sur le site web, via IM ou encore via un client tiers tel que twhirl. En balayant un peu plus large, un blog dispose en quelque sorte d'un service grâce à son flux RSS qui permet au blog d'être consulté dans un agrégateur par exemple. Mais un service tout seul est-il viable?

API Diagram

Il existe des services qui sont payants. Ces services, comme Amazon S3 ou encore CloudFS, sont des services pay as you consume, ce qui veut dire que l'on paye selon le traffic que nous échangeons avec ce service. Les deux exemples cités permettent par exemple de bénéficier d'espace disque. Un autre exemple peut être l'API de Google Maps qui est payante pour les entreprises, au bénéfice entre autres d'un Google Maps vierge de toute publicité. Ces services sont donc rentables, à condition évidemment de trouver un tarif adéquat.

Mais les principaux services sont ceux qui sont gratuits. C'est le cas de Twitter, cité plus haut, mais aussi de la plupart des applications sociales comme Pownce, Jaiku, etc. Les applications web mainstream ne sont pas en manque, on le voit avec Facebook ou encore Flickr. Un service permet ici une multiplication des clients, mais aussi de créer des mashups entre services qui peuvent devenir très intéressants, comme par exemple Flickr Vision, qui permet de visualiser des photos géolocalisées sur une carte issue de l'API Google Maps.

Revenons à ma problématique, à savoir la viabilité de ces services. Vous aurez noté que chaque service gratuit que j'ai pu citer est toujours associé à un nom d'une application web plus ou moins connue. Celà implique que le service est toujours associé au nom d'une application web.

Néanmoins, j'ai pu observer récemment l'arrivée de nouveaux services web qui n'ont pas de site web qui les exploitent. Il semblerait que ce soit la voie que prend Yahoo, avec FireEagle pour la géolocalisation, ou encore Internet Location Platform, l'API de recherche de lieux et d'adresses. Mais Yahoo n'est pas seul, Reuters semble aussi emprunter la même voie avec son API sémantique OpenCalais.

Ces services présentent des avantages certains en termes d'exploitation, permettent de décentraliser des données tout en gardant une stabilité assurée car un fournisseur de services tel que Yahoo bénéficie évidemment d'une architecture testée et approuvée. Mais quid de la monétisation? Bien sûr, peut-être que pour un gros comme Yahoo, les services proposés sont rentabilisés via d'autres fonctionnalités du portail (Même si ces derniers temps chez Yahoo, c'est pas la grande joie), mais pour un service qui naitrait seul, il n'y a à mon avis aucun espoir de monétisation.

Les services sont bel et bien l'avenir de nos applications, à n'en pas douter, mais ne sont à mon avis pas une priorité, dans le sens où ils ne sont pas forcément monétisables. Ils sont essentiels en  termes d'architecture technique, mais le gros des efforts doit être fait au niveau de la première application qui exploitera ce service, car c'est elle qui sera monétisable. Facebook ne serait rien sans son API, et pourtant, son API seule n'aurait jamais connu un tel essor sans le site web qu'est Facebook. Un service seul est donc voué à l'échec, c'est d'ailleurs ce que je prédis pour les quelques uns que j'ai pu citer. A moins que quelqu'un trouve une idée révolutionnaire de monétisation d'un service gratuit, mais j'en doute...