La difficulté d’une application externalisée

J’ai souvent pensé que fournir une API aux développeurs pouvait comporter des risques de stabilité pour le service web qui la propose. Le cas typique d’une application tierce mal conçue peu devenir vite un trouble pour l’application web principale. Il semblerai que ce soit le cas de Twitter actuellement.

Nous apprenons sur l’un des billets du blog de Twitter la raison des récentes arrêt de service.

Nous avons trouvé une utilisation de l’API qui consomme trop de nos ressources dédiées à Jabber. Cette activité avait pour effet de surcharger notre base de données, ayant pour conséquence les pages d’erreurs et les lenteurs que la plupart des utilisateurs ont rencontré. [..] Nous allons observer les clients de messagerie instantané avec grande attention.

Twitter est l’un de ces projets qui ont prit le parti d’externaliser le développement de ses applications par d’autres personnes. C’est la tendance actuelle des services web sociaux lié à la publication. Je pense qu’en effet c’est la bonne méthode lorsqu’on décide de lancer un nouveau service. Cependant si l’application comporte des erreurs de conception, et si l’API n’est pas capable de bien gérer ces anomalies, arrive alors les pannes de serveur, surcharge, indisponibilité.

Ces incohérences se détectent progressivement, c’est la vie d’un service de le faire évoluer me direz-vous. Mais si ces incohérences prennent un certain temps pour les détecter, et que pendant ce temps là, les utilisateurs en sont frustrés, alors en découle mécontentement et donne au service une mauvaise image.

A l’évidence, c’est une donnée à prendre en compte si vous souhaitez un jour monter une startup en bootstrapping avec comme projet principal, un service web et son API, en laissant à d’autres le soin de développer pour vous les applications.

5 réponses “La difficulté d’une application externalisée”

  1. Stellaire :

    24 May 08 at 11:41 am

    J’suis partagé…

    D’une part je suis d’accord avec toi, ouvrir son API et permettre aux fans de développer leurs applis est potentiellement dangereux ET dans le cas de Twitter ça s’avère être presque catastrophique (et paradoxalement ce service n’aurait eu aucune chance sans ça).

    D’autre part je suis contre ton analyse parce que même si elle est juste pour twitter, je ne pense pas qu’on puisse trouver d’autres exemples de services connaissant de vraies graves perturbations (comme twitter) à cause d’outils développés par les utilisateurs.

  2. Rémian :

    24 May 08 at 12:16 pm

    Stellaire, tu as raison nous avons peu d’exemple de services connaissant de grave perturbations hormis Twitter.
    Mais je tiens à préciser que Twitter existent sous la forme d’une galaxie d’applications tierces. Rien ne nous empêche de penser qu’un autre service serait confrontés aux mêmes désagréments avec autant d’applications tierces.

  3. Red@ :

    24 May 08 at 12:33 pm

    tout a fait d’accord mais n’es pas les applications externes qui ont fait le succés de ces meme services…?

    il faut faire un choix .. séduire de plus en plus de monde sans savoir servir les clients … ou se contenter de ceux qu’on a déja et oeuvrer a leur confort … Choix cornélien .

  4. Denis :

    24 May 08 at 05:21 pm

    Tiens, Flickr a bloqué l’accès à son api pour l’application http://www.eternalstorms.at/flickery/ , très bien conçu au demeurant.
    La raison avancée est une trop grande consommation de ressources mais certains pensent surtout que c’est bloqué parce que l’application permet de se soustraire en grande partie du site (et donc il n’y a plus de pubs à afficher).

  5. Rémian :

    24 May 08 at 05:47 pm

    Denis, merci pour cette info. Très intéressant de savoir que Flickr soit capable de refuser une application tierce.


A vous de commenter