Les dangers des API dites « ouvertes »

closeCet article a été publié il y a 11 ans 8 mois 1 jour, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Twitter annonce des règles plus « strictes » pour l’utilisation de son API ou interface de programmation sur laquelle sont basés de nombreux programmes et services web. Des changements qui mettent en évidence le piège que peuvent représenter les API « ouvertes » des grands services web.

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]

Le saviez-vous ?

Les protocoles et formats ouverts sont définis par des instances indépendantes d’une unique entreprise. Il s’agit en général de consortiums de nombreux acteurs économiques ou encore d’organisations à but non lucratif comme le World Wide Web Consortium qui définit par exemple le format ouvert HTML ou encore l’Internet Engineering Task Force qui définit les protocoles ouverts de l’internet comme le HTTP.

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

2 réponses

  1. Olivier dit :

    Pour avoir développé des services en utilisant les API d’Amazon, Twitter et Facebook, je peux dire que je suis entièrement d’accord avec l’article.

    – Utilisation de l’API d’Amazon : pour l’instant aucun problème, j’ai développé 1 fois il y a 1 an ou 2 des fonctionnalités et tout continue de fonctionner sans jamais y toucher.
    – Utilisation de l’API de Twitter : en +- 1 an, j’ai dû remodifier (recoder !) 2 fois mon code pour que mes fonctionnalités continuent à marcher… (entre les changements de formats des données et l’authentification obligatoire…)
    – Utilisation de l’API de Facebook : j’ai codé 1 fois et peu de temps après il fallait que je modifie ce que j’avais fait pour m’adapter à leurs changements… pour le moment j’ai laissé tombé, n’ayant pas d’utilité urgente de l’API Facebook. J’ai autre chose à faire que de m’adapter sans arrêt à leurs délires 😀

    Et Google+, ils se décident quand à sortir une API accessible en écriture ? Faudrait qu’ils se bougent s’ils veulent que des gens utilisent leur réseau social 🙂

  2. Max dit :

    En ce qui concerne Twitter le récent changement de l’API a clairement mit un frein à l’ouverture, il faut repartir de zéro sur presque toute les applications utilisant une API twitter. En ce qui concerne FB, là encore l’API c’est franchement n’importe quoi ce qui marche lundi ne fonctionne plus le mercredi un vrai casse tête. De toute manière les API vont être de plus en plus contrôlées, un mal necessaire diront certain pour éviter les abus