Développement

Les dangers des API dites “ouvertes”

• Bookmarks: 7


Twitter et son API

L’un des facteurs clés de la réussite de Twitter fut probablement son API ou interface de programmation qui permettait à qui le souhaitait de développer une application basée sur les données de ce service. On a ainsi vu fleurir toute une série de sites web qui apportaient à Twitter les fonctions qui lui manquaient ou encore des logiciels qui permettaient d’utiliser le service depuis son ordinateur ou encore son smartphone. Cette forme d’ouverture a donc contribué au succès du service de microblogging.

Les années passant, les créateurs de ce réseau ont probablement compris tout l’intérêt qu’il pouvait tirer de ce bouillonnement d’applications. Twitter a pu profiter de tout un travail de recherche et développement autour de son service quasi-gratuitement.Il ne lui restait plus qu’à racheter les meilleurs projets.

Le temps et l’obligation de dégager des revenus, ont poussé Twitter à mettre la pression sur les services web périphériques en allant même jusqu’à intégrer des fonctions qui étaient auparavant réalisées par des services externes comme le “raccourcissement” des adresses web. Petit à petit, l’utilisation de l’API devient plus restrictive, mais aussi payante. On voit ici que Twitter contrôle son environnement économique au travers de son API.

API ouverte = protocole ouvert ?

J’ai longtemps cru que l’API de Twitter, documentée et a priori utilisable par qui le souhaitait, pouvait être considérée comme “acceptable”. De fait, il s’agit d’une erreur comme peuvent désormais le constater les développeurs d’applications Twitter. C’était oublier que rien n’est immuable et que ce qui est donné un jour peut être repris le lendemain. L’API de Twitter n’est pas conçue de façon collaborative, mais elle est la propriété de Twitter qui peut en faire ce que bon lui semble.

Comme le dit un développeur Dave Winer : « L’erreur que nous avons tous faite avec Twitter, moi compris, était de croire qu’une API propriétaire pouvait se comporter comme un protocole ouvert ».

L’exemple de Twitter est à mettre aussi en avant lorsque l’on parle de cloud computing et d’API. Dans le débat que j’ai animé sur Solutions Linux entre Jean-Pierre Laisne et Fançois Tonic sur les standards pour l’open cloud, cette problématique avait bien été mise en avant. Le géant de ce secteur Amazon publie également une API pour ses services. Une API qui est devenue de fait “un standard du marché” largement utilisé. Amazon contrôle ainsi son marché et ses “partenaires” et donc ses utilisateurs y compris au travers de bon nombre de solutions open source.

La comparaison a cependant une limite, Amazon vend les services que l’on peut utiliser au travers de son API, alors que Twitter vend l’accès à l’API. Les sources de revenus pour ces deux services ne sont pas positionnées de la même façon. Ce qui rend à mon sens la situation de Twitter bien plus risquée pour les utilisateurs.

Une API ouverte fournie par une entreprise doit donc être étudiée sous l’angle des sources de revenus de celui qui la fournit. Si la source de revenu passe par l’API elle-même, il devient dangereux de baser son propre développement sur cette dernière. Les règles risquant de changer trop brutalement et forcément en faveur de celui qui la fournit. Une arme a double-tranchant cependant, car elle pourrait aussi se retourner contre celui qui la manie…

[Source]

Philippe SCOFFONI

7 recommended
bookmark icon
Mastodon