Les interfaces de programmation permettent à des services de s’échanger des données entre eux. Elles peuvent permettre à un site web d’utiliser le moteur de reconnaissance d’image d’une autre société pour l’intégrer à son service de stockage d’image par exemple ou à une librairie en ligne de publier sur votre profil Facebook ou Twitter le livre que vous venez de lui acheter. Stade suprême de l’intégration des services ou porte ouverte à la publicisation sans contrôle de soi, les API ont un rôle de plus en plus important dans le web d’aujourd’hui.

Pour mieux comprendre le rôle et le fonctionnement des interfaces de programmation (API pour Application Programming Interface), le mieux est de le demander à des gens qui les utilisent. Karl Dubost responsable des relations avec les développeurs chez Opera, Johann Daigremont à la tête du département des communications sociales aux Bell Labs d’Alcatel-Lucent, et Alexandre Assouad, concepteur de projets chez FaberNovel, avec leurs expériences différentes, reviennent sur le rôle, le fonctionnement et les enjeux des API, qui structurent déjà l’internet de demain.

InternetActu.net : Qu’est-ce qu’une API, concrètement ?

Karl Dubost : Une API est une interface. Un protocole de communication pour accéder à un service. De la même façon que dans un logiciel de base de données tu as un vocabulaire pour accéder aux données et faire une requête, l’API permet de construire des interrogations par une interface normalisée.

Selon les services Web, les API offrent un certain nombre de fonctionnalités. Celles-ci également évoluent au cours du temps. Dans le cas de Facebook, le lieu pour découvrir ses APIs est le site des développeurs. Facebook a plus d’une API. Ils en ont pour explorer le graphe, pour s’authentifier, etc. Comme c’est un service, les développeurs doivent identifier leurs éventuelles applications afin que Facebook puisse d’abord contrôler la façon dont l’API est utilisée et ensuite éviter les dépassements de ressources (requête trop fréquente par exemple).

Image : le site des développeurs de Facebook.

Johann Daigremont : Une API permet à deux programmes de s’échanger des données. Le premier utilise l’API offerte par le deuxième pour bénéficier de ses services et données. L’API définit un langage commun entre les deux programmes. L’ensemble des grands acteurs du web propose désormais leurs services via leurs API. Au lieu de rester fermés, ces acteurs ont en effet décidé de s’ouvrir pour être capable d’offrir des modalités de développement accessibles et bénéficier des millions de développeurs de la toile (on appelle cela le crowdsourcing) : comme permettre de développer des quizz ou des jeux en utilisant les interfaces sociales de Facebook par exemple.

L’API décrit des fonctions et des méthodes pour accéder à certaines propriétés de certains sites comme Facebook, Twitter, MySpace… Ces interfaces de programmation permettent à un développeur d’interagir avec le système. Il y a différents types d’interfaces. Certaines ne permettent que de faire des interrogations (on peut chercher de l’information), d’autres permettent d’écrire de l’information (on peut par exemple « écrire » un statut pour une personne). La description des API, est basée sur des requêtes HTTP et du XML, permettant d’utiliser un langage très simple pour les lire et les interroger.

Le site web GoogleApps/APi permet de voir la liste des interfaces de programmation de Google disponibles. Celles de Facebook sont documentées dans le répertoire et dans le site dédié aux développeurs.

Alexandre Assouad : Facebook est un exemple un peu complexe et particulier. On peut distinguer deux grands types d’API : celles qui permettent de créer des services dans Facebook (comme d’y créer Farmville, le célèbre jeu) et les API d’authentification qui permettent de ramener le graphe social d’un utilisateur dans un autre service (notamment via l’API Facebook Connect).

L’API Facebook Connect a créé un cercle vertueux pour améliorer l’expérience utilisateur en permettant d’intégrer une expérience sociale à n’importe quel site. L’API génère du trafic qui transite par Facebook et enrichit le flux des utilisateurs.

InternetActu.net : Qu’est-ce qu’on fait avec les API Facebook ? Quelles sont les API les plus utilisées ? A quoi servent-elles ?

Karl Dubost : Je pense que l’API Facebook la plus utilisée est celle d’authentification. Car elle permet aux gens de pouvoir commenter et voir des amis ou des infos relatives aux pages Web sur tous les sites.

Elle n’est pas innocente non plus. Elle permet à Facebook de tracer toutes les navigations d’un utilisateur Facebook sur tous les sites Web avec des fonctions Facebook. C’est un véritable cheval de troie à l’échelle du Web. C’est bien pour cela que Google sort son +1.

Alexandre Assouad : L’API la plus utilisée de l’internet demeure Google Maps, qui fournit un service de cartographie gratuit. Il faut dire que dans le monde des interfaces de programmation, Google a un modèle spécial : il offre un plein accès à ses API. Ainsi, faire du géocodage d’adresse sur Google Maps est totalement illimité. Mais si on veut faire du géocoding d’adresse en dehors de Google Maps on est limité en terme de requête. Google favorise l’utilisation de son propre service, mais s’offre la possibilité de récupérer le contenu d’une Google Maps pour l’indexer.

Le souci c’est qu’il y a désormais une API pour tout. Le problème est de déterminer où s’arrête la définition de l’API. Celle-ci a tendance à devenir de plus en plus un widget qui est intégré sur une page : les petits widgets de Facebook (code en javascript que n’importe qui dépose sur son site web) peuvent être appelés des API, car ils permettent d’intégrer Facebook facilement, mais ce ne sont pas des API au sens le plus technique. Car, si en terme de fonctionnement c’est assez proche, en terme d’intégration, ce n’est pas la même chose. En tant que développeur, on a sa disposition du code pour manipuler les éléments que l’on veut obtenir et faire s’afficher.

InternetActu.net : Peut-on accéder à tout via les API ?

Johann Daigremont : Tout n’est pas ouvert. Les développeurs n’ont pas accès à tout. Facebook par exemple n’ouvre pas tout. D’abord, il faut montrer patte blanche. Il faut s’enregistrer comme développeur auprès de la plupart de ces structures avant qu’ils vous acceptent. Il existe par exemple un Service Level Agreement (SLA ou accord de niveau de service) qui définit un contrat d’utilisation entre une application tierce et le site web auquel l’application accède. Ces contrats listent les méthodes autorisées, la périodicité ou la quantité de données qui peuvent transiter entre les deux services. Tous les services ont ainsi des limites : par exemple, Twitter limite à 150 le nombre de requêtes par heure par une application externe, Facebook a mis en place des limitations dynamiques sur le nombre de requêtes par jour par une application en fonction de « l’affinité » montrée par les utilisateurs pour votre application.

Les formes de SLA sont variées : avec Apple ou la plupart des opérateurs de télécommunication, il faut faire parvenir un courrier, mais Facebook se contente d’une déclaration en ligne. Apple vérifie que les sources de l’application soient en conformité avec l’API utilisée.

Mais pour tous ces acteurs, l’approche est la même : attirer les développeurs en proposant des interfaces de programmation ouvertes pour que ceux-ci puissent construire des millions d’applications.

Ensuite, les utilisateurs ont également un rôle : l’application doit demander à la personne une autorisation à chercher les données dont elle besoin. Beaucoup de systèmes ont des API spécifiques. Mais il existe quelques protocoles communs comme OpenSocial, un consortium qui décrit les spécifications des interfaces et permettant d’utiliser la même interface de programmation pour interroger de nombreux services. Sur Facebook on dénombre plus de 500 000 applications. Mais par application, on parle de tout et de rien. L’essentiel est très simple et consiste seulement à permettre l’identification, comme c’est le cas avec OpenSocial.

Image : OpenSocial.

InternetActu.net : L’internet des API est-il un internet payant ou gratuit ?

Johann Daigremont : En fait, les deux ! Les acteurs du web ouvrent souvent leurs services de manières modulaires : une première partie des méthodes offertes via l’API est accessible gratuitement, ce qui permet d’attirer un maximum de développeurs, une seconde partie est payante pour des méthodes plus avancées. La partie gratuite est souvent limitée avec des seuils de requête. La plupart des acteurs du web proposent une partie de leur API gratuitement ; les opérateurs de télécommunication, qui ont longtemps proposé des API payantes, évoluent et commencent à offrir des API pour ouvrir les capacités de leurs réseaux à des communautés de développeurs.

Alexandre Assouad : Il existe des API où il y a des limitations en terme de requêtes, car les fournir coûte cher. Il y a un coût des requêtes à la seconde, notamment sur les API de Twitter, Viadeo ou Linked-In, avec des taux maximaux de requête par heure. Sur Google également il y a des API avec des taux limités, et si vous souhaitez les dépasser (c’est-à-dire dépasser les 10 000 ou 20 000 requêtes jours), il faut payer. Il existe des API totalement payantes, mais le modèle est le plus souvent freemium, permettant aux développeurs de tester les services tout en étant limités en terme de volume.

InternetActu.net : On a l’impression que les API sont hors économie. Que les échanges B2B sont devenus un échange basé sur la confiance et la réciprocité ? Est-ce si juste ? Ou au contraire, est-ce la base de lourdes négociations de l’ombre comme l’ont montré les tensions entre Facebook et Google ?

Karl Dubost : Pas du tout. :)

Les API sont soient en accès libre, soient identifiées et même payantes, comme par exemple le service Amazon S3. Il n’y a aucune confiance, ni réciprocité. Lorsqu’une société te laisse mettre l’authentification Facebook « gratuitement » sur ton site, c’est pour mieux pomper les données des utilisateurs. À chaque fois que Google donne la possibilité aux gens de mettre une carte Google Map, c’est l’opportunité de tracer les gens et leurs intérêts avec la combinaison de recherche géographique et Doubleclick, la régie publicitaire de Google. Ce qui est en jeu, c’est la construction fine de profils marketing pour mieux vendre de la publicité.

Alexandre Assouad : Dès le début il y a eu les 2 modèles. Les modèles d’API existent depuis longtemps. La réservation de billets dématérialisés pour le train par exemple utilisait des API d’un prestataire payantes.

Plusieurs modèles existent entre le modèle gratuit et le modèle payant freemium (c’est-à-dire un modèle qui permet d’accéder à un service de base, gratuit, mais qui devient payant quand on veut augmenter l’accès au service que ce soit en terme de capacités ou de fonctionnalités). Dans le cas du modèle payant freemium, il s’agit d’une prestation avec des conventions en terme de qualité de service ou de réactivité par exemple.

C’est le modèle gratuit qui est plus récent et qui a pour but de créer un cercle vertueux entre les acteurs qui l’utilisent, afin que chacun y trouve son compte. Ce modèle gratuit est assez lié au crowdsourcing. Par exemple, l’API de Foursquare a été auto-entretenue par les utilisateurs. Les gens renseignaient des lieux qu’ils n’y trouvaient pas. Tant et si bien que l’API de géolocalisation de Foursquare est devenue très intéressante, car elle ne me propose plus une longitude et une latitude, mais des lieux et leurs noms…

Parfois, le crowdsourcing permet de fournir un service plus intéressant, de le développer parce que les gens créent le contenu et l’apportent sur la plateforme… On a donc des modèles économiques différents dans les API, mais aussi des types de services différents, qui expliquent que l’un est souvent payant et l’autre souvent gratuit.

Johann Daigremont : Ouvrir ses services à des tiers via une API n’est pas anodin. C’est au contraire une réelle stratégie économique choisie par celui qui fournit ce service. Cela permet d’attirer des communautés de développeurs et de bénéficier d’une masse critique que vous n’avez pas en interne dans votre entreprise pour apporter de nouvelles fonctionnalités, de nouvelles applications, auxquelles vous n’auriez pas pensées ou que vous n’auriez pu développer. Cela permet également de suivre vos utilisateurs dans leurs usages d’autres applications, ce qui permet de construire des profils utilisateurs plus complets, profils pouvant ensuite être revendus pour du marketing ciblé.

Il me semble qu’on constate une réelle volonté des acteurs du web pour ouvrir les informations, même si la donnée est ce qui fait la richesse. Car c’est une ouverture intelligente. Il s’agit de développer des applications qui tirent partie de ces données, sans permettre pour autant de copier ou de pouvoir reconstruire la base de données à laquelle on accède.

InternetActu.net : Quelles sont les limites des API ? En les utilisant, les développeurs dépendent de règles qu’ils ne maîtrisent pas et qui peuvent changer au cours du temps, comme l’a récemment montré Google.

Alexandre Assouad : Ce que les développeurs attendent d’une API, c’est qu’elle soit normalisée, stable dans le temps. Pendant longtemps, il y a eu trop de changement dans les API de Facebook pour que les développeurs puissent suivre (et aussi sur leurs orientations en matière de vie privée) sans compter que Facebook communiquait assez peu en amont sur les modifications qu’ils apportaient. C’est effectivement le risque des API : en les utilisant, elles peuvent ne pas être toujours valides demain.

Google prévient assez en amont et versionne ses API. Sur Google Maps par exemple, il y a plusieurs versions d’API qui sont utilisables et maintenues. Ils communiquent sur leurs nouvelles API, ils avertissent des changements et ont une politique d’accompagnement dans le changement.

La différence entre Google et Facebook c’est qu’ils préviennent un peu plus tôt.

On constate également que Google change actuellement son fusil d’épaule : la stratégie est en train de se modifier et on trouve beaucoup plus d’API payantes qu’avant. Bien évidemment, quand cela devient payant, les développeurs cherchent à utiliser d’autres services, ce qui encourage d’autres alternatives. On trouve en Open Source des briques d’alternatives qui peuvent remplacer certaines API. L’open source a l’avantage de permettre une meilleure intégration : on peut les déployer sur ses propres serveurs, ce qui permet de s’affranchir des limitations en terme de requêtes.

Karl Dubost : De la même façon que dans le monde physique nous allons dans un restaurant parce qu’il propose un menu végétarien, il est fort probable que le service disparaisse ou soit modifié de manière conséquente si le propriétaire ou le cuisinier change. On doit alors se trouver un nouveau restaurant…

L’enjeu en ligne est de deux ordres. Les services sont souvent uniques ou peu nombreux (Facebook, Twitter, Google Maps…) et les APIs utilisées sont rarement normalisées. Si l’un des services ferme et que tout un développement s’appuyait sur les options de l’API, les développeurs sont marron. D’où le besoin de maîtriser l’indépendance de ses données.

InternetActu.net : Peut-on encore développer un site web sans se brancher sur des API ?

Alexandre Assouad : Bien sûr, un site peu exister sans API. Mais les API servent à améliorer les services ou ajouter des fonctionnalités. L’API on peut la voir de deux manières : soit elle enrichit et améliore l’expérience de l’utilisateur sur mon site, soit elle répond à un besoin technologique que je n’ai pas envie de réinventer. Il y a des API qui permettent d’intégrer de la reconnaissance d’image par exemple, ce qui permet au développeur d’un service de ne pas avoir à tout redévelopper alors que d’autres le font très bien. On peut profiter d’un écosystème existant. D’un autre côté, intégrer un Facebook Connect ou Twitter commence à entrer dans la norme…

Utiliser des API permet de se focaliser sur son corps de métiers, sans s’occuper des briques techniques qu’on utilise, un peu comme quand on sous-traite dans une entreprise. On peut clairement monter des services en développant très peu et en se basant sur plein d’API externes et en proposant un mixe de services très intéressants. Foursquare par exemple est assez proche d’un mashup d’API : une API de géolocalisation et une de partage avec ses relations… Ils ont recréé une base technique bien sûr, mais leur service aurait pu tout entier reposer sur des API existantes… En tout cas, on pourrait facilement créer un nouveau Foursquare avec des API existantes. C’est du Lego. Il faut juste que les briques tiennent et aient du sens.

Karl Dubost : Oui on peut développer un site Web sans forcément utiliser l’API d’une autre société. La question est plutôt qu’elles sont les API que je peux utiliser tout en minimisant les risques pour mon business d’en être victime.

InternetActu.net : On a l’impression que désormais, la plupart des nouveaux services naissent du croisement des API, comme le montre ProgrammableWeb, une base de données d’API rachetée par Alcatel…

Johann Daigremont : Les Mashups permettent à un développeur d’utiliser plusieurs API et des les « composer » pour créer un service. Pages jaunes par exemple utilise les API de Google Maps avec une API de données sémantiques pour afficher sur une carte la liste des docteurs. C’est la une composition très classique. Le plus souvent les développeurs se contentent de combiner leurs propres données avec l’interface de Facebook.

Mais il existe beaucoup plus d’API que n’en recense Programmable Web.

Karl Dubost : Ce n’est pas forcément le cas de tous les services. Certains vont créer des protocoles originaux, d’autres vont réutiliser entièrement un autre protocole. Par exemple, le service de suivi de conférence Lanyrd ne propose un login que et exclusivement par Twitter (ce qui est cela dit un peu limité).

L’enjeu de la normalisation est bien plus intéressant. Il nous évite d’avoir à ouvrir des comptes sur X services pour pouvoir les utiliser, sans être non plus dépendant d’un service tiers spécifique…

InternetActu.net : On a un peu l’impression que le paysage qui se dessine ressemble à un internet des API, ouvert, dans les nuages, mais réservé aux développeurs et un web des applications, un monde clos, limité, réservé aux usagers ?

Karl Dubost : Une API est un point de communication pour une application. Ce n’est pas une opposition. Il y a des API fermées, d’autres ouvertes, etc. Il y a des applications libres et des applications fermées.

Alexandre Assouad : Sauf que les API ne sont pas si ouvertes que cela. Ce qui est vraiment ouvert, c’est le code en open source qu’on peut répliquer. Sur Google, l’API de Geocoding (qui permet d’associer des coordonnées géographiques à des adresses) me limite à 20 000 requêtes par jour : si je les atteints, pour l’instant, je ne peux plus rien faire. Par contre si j’intègre une brique open source pour intégrer ce géocoding sur mes propres serveurs, je ne suis pas limité. L’API permet une certaine ouverture, mais il n’est pas si ouvert… Si je ferme l’API, si je la modifie, je mets dans une situation difficile beaucoup de gens.

Cela dit, l’API est un monde fermé pour l’utilisateur final. C’est un monde réservé aux développeurs.

Sur Twitter par exemple, l’API permet de faire plus de choses que ne le propose le site. Il y a une dissymétrie entre le service disponible en ligne et ce que l’on peut faire via les API. L’écosystème lié aux API s’est beaucoup développé ce qui a permis de résoudre les problèmes de charge que connaissait le service qui tombait fréquemment. Ils ont développé des API plus solides et construit des services depuis celles-ci. Et l’API Twitter permet de faire plus que ne le propose le site : comme de rechercher en profondeur dans l’historique des comptes par exemple. Elle est devenue prépondérante par rapport au site. Elle permet à de très bons services d’exister, comme Tweetdeck.

Propos recueillis par mail et téléphone entre décembre 2010 et mai 2011 et assemblés par Hubert Guillaud.

Alexandre Assouad est concepteur de projets chez FaberNovel. Johann Daigremont est à la tête du département des communications sociales aux Bell Labs d’Alcatel-Lucent. Karl Dubost responsable des relations avec les développeurs chez Opera.

Le dossier “Comprendre Facebook” :

• 1ère partie : Le rôle social du bavardage
• Supplément : Interview, Judith Donath : Si Facebook est important c’est le signe que nos relations sont importantes
• 2e partie : Facebook technologie relationnelle
• Supplément : Comment étudier l’internet quand l’internet est partout ?
• 3e partie : L’internet des API, le web des applications
• Supplément : Interview, Comprendre les interfaces de programmation