Les ouvertures problématiques des « api »

Les mode d’ouverture du « Web 2.0 » reposent sur des accès contrôlés. Le passage des sites web à la notion de plate-forme (tel que l’entend O’Reilly) entraîne une confusion entre les notions de disponibilité, d’ouverture, de stockage et de distribution des données. Le texte s’explique de ces modes d’ouvertures contrôlées d’une façon ambiguë. Il s’agit de saisir des « opportunités » commerciales tout en ne produisant pas un système fermé :

Sans données, les outils ne servent à rien ; sans logiciels, les données sont ingérables. La gestion des licences et le contrôle des api – points cruciaux de l’ère précédente – n’avaient plus lieu d’être dans la mesure où les logiciels n’avaient plus besoin d’être distribués mais seulement utilisés et où sans la capacité de collecter et de gérer des données, le logiciel n’est que de peu d’utilité. En fait, la valeur d’un logiciel est proportionnelle à l’échelle et au dynamisme des données qu’il permet de gérer. […]

Dans l’univers de l’Internet, on a déjà pu voir pu un certain nombre de cas dans lesquels le contrôle des données amène dans un premier temps la domination du marché puis le profit. […] Puisque nous avons vu que l’avantage stratégique du contrôle des api n’avait plus vraiment de sens sur le Web, cela signifie que l’élément de domination des marchés se trouve dans les données. C’est d’autant plus vrai lorsqu’elles sont difficiles à créer et lorsqu’elles sont susceptibles de bénéficer de rendements croissants grâce à l’effet réseau²⁶¹.

La citation fait mention des api, dont Tim O’Reilly ne nie pas l’importance, mais préconise de ne pas les utiliser pour enfermer (« lock in ») les utilisateurs. Dans les faits, la plupart des services cités dans l’article reposent sur les « contrôles des protocoles » pour capitaliser ce qui était ou devrait être librement accessible. Cette invisibilité des protocoles d’échange est problématique. D’une part elle masque les enjeux financiers en concurrence pour la domination du Web, et d’autre part elle empêche de comprendre les enjeux techniques. Dès lors, il est intéressant d’étudier comment fonctionnent ces protocoles contrôlés — les api — afin de comprendre leurs spécificités techniques, leurs tenants et aboutissants. L’analyse développée ci-dessous concerne essentiellement les api « propriétaires » (d’entreprises ou d’organismes privés), ce qui représente la majorité des cas. Des alternatives sont abordées en conclusion de cette partie.

Une api (« Application Programming Interface ») est une interface de programmation qui permet de mettre en relation un programme avec un autre. Une api a pour objet de faciliter le travail d’un programmeur en lui fournissant une « bibliothèque » (library) de fonctions permettant de gérer ou d’enrichir un service Web (exemple « l’api de Twitter »). Ces outils permettent au développeur informatique de réutiliser des données et des fonctions provenant d’un site particulier dans un autre projet. L’api est une base de travail qui ouvre de nouvelles possibilités. On ne va plus coder son site de façon autonome, mais le penser en termes de relations. La plupart des sites dominants (tels que Amazon, Twitter, Facebook ou Google Maps) disposent de bases de données gigantesques et inaccessibles intégralement. Ce que l’on perçoit habituellement d’une base de données, c’est une interface (site web), c’est-à-dire que ce qui est affiché à l’écran est un « habillage des données²⁶² » qui facilite leur manipulation par l’emploi d’éléments graphiques. L’interface sert d’intermédiaire entre l’utilisateur et la base de données. L’api, par définition, ne dispose pas de « vues » différentes. On n’utilise et on n’affiche l’api qu’à partir de langages de programmation. On ne peut pas afficher de manière stylisée du xml dans un navigateur web, ou plutôt, l’afficher revient à voir le code. Le code source n’est pas immédiatement visible²⁶³, et ne donne en aucun cas accès à l’ensemble des données de la base. Les fonctions de l’api nécessitent des codes sources spécifiques, et ne renvoient que des données « brutes » (structurées et balisées), c’est-à-dire délestées de toute mise en forme graphique.

La majorité des usages des api se situent du côté de la consultation d’informations. Si l’on compare l’api avec une voiture, on pourrait dire que le conducteur n’a pas à connaître le fonctionnement mécanique d’un moteur pour conduire le véhicule. Le fonctionnement complexe du moteur, des arbres de transmission de mouvement, etc. lui est masqué sous une coque. Le conducteur ne voit qu’une interface composée d’un volant, de pédales (accélérateur, embrayage, frein), de manettes (clignotants, phares, boîte de vitesse) et de boutons (avertisseur, anti-brouillard, klaxon, etc.). La partie effectivement active est toujours accessible physiquement (bien que cela soit de moins en moins vrai) mais elle se dérobe au regard [ Fig. 127 ]. Fig. 127 On pourra penser ici aux surcouches d’électronique sur le mécanique des voitures contemporaines, comme l’aide au freinage.

Une api c’est donc un automate à qui l’on donne un ordre (une instruction), et qui va l’exécuter chez un prestataire externe sans qu’on puisse connaître sa façon d’organiser et de traiter l’information. À partir d’un minimum de connaissances en informatique, la facilité d’accès aux api permet au développeur de ne pas se soucier de la façon dont fonctionne effectivement l’application distante pour pouvoir l’utiliser dans un programme. L’api éloigne donc le programmeur d’un code trop complexe et fait écran avec les fonctions des langages de programmation dits standardisés. Les fonctions d’une api sont des médiations vers des calculs inaccessibles et invisibles. L’api est un intermédiaire qui voile. Elle propose un jeu de fonctions standardisées dont seuls les paramètres et les valeurs retournées sont connues. Elle masque les opérations effectuées et n’apparaît que par les données qu’elle renvoie. Chaque site web proposant une api produit ainsi un langage formel qui lui est propre. Même si des récurrences peuvent apparaître, cette fragmentation des standards en logiques propriétaires fait courir le risque d’un Web à péages. Cette démocratisation relative est un mode d’ouverture destiné à limiter la force des acteurs « secondaires » du Web.

L’ouverture problématique des api (qui est aussi celle du « Web 2.0 » ) consiste à fournir un service gratuit et facile d’accès pour constituer une audience qui, une fois devenue massive, va être économisée. Les services autrefois gratuits deviennent payants, et leur caractère désormais indispensable (commode) fait que l’on ne peut pas ne pas les payer sans conséquences. La gratuité des api n’est qu’apparente, la plupart restreignent le volume d’usage. L’api est un « intermédiaire intelligent » (« intelligent broker » ), un gestionnaire aveugle qui ne s’ouvre qu’avec de l’argent. Pour Tim O’Reilly, « la valeur d’un logiciel est proportionnelle à l’échelle et au dynamisme des données qu’il permet de gérer²⁶⁴ ». Si l’on entend ici valeur au sens de valeur économique²⁶⁵, il est compréhensible que les éditeurs d’api cherchent à limiter l’accès aux données pour amortir les coûts de maintenance de serveurs. Chaque programme accédant à l’api peut en effet effectuer des centaines de requêtes à la seconde. Le succès de l’api de Twitter a contraint les responsables à restreindre l’accès à leur api. Par exemple, Twitter autorise par heure 150 requêtes anonymes²⁶⁶ ou 350 requêtes « authentifiées²⁶⁷ ». Les volumes peuvent évoluer dans le temps sans préavis.

En octobre 2011, Google Maps [ Fig. 129 ] Fig. 129 (de loin l’api la plus utilisée au monde) devint ainsi payant au-delà de 25 000 chargements/jour²⁶⁸ avec un forfait de 4$ pour 1000 requêtes, et proposa en complément une licence annuelle de 10 000$ permettant d’accéder à des fonctions supplémentaires. Ces changement de politiques tarifaires peuvent représenter un surcoût fatal pour des sites à fort trafic ne dégageant pas de revenus conséquents (comme les sites à but non-commercial).

L’api s’inscrit de plein pied dans la notion « d’avantage concurrentiel²⁶⁹ ». Les données renvoyées par l’api ne sont pertinentes que si elles sont « à jour ». La mise à jour des données les transforme en informations, au sens où la valeur d’une information dépend directement de son temps d’accès. La valeur de l’api tient dans cette volonté d’inscrire les programmes dans une « actualisation » accélérée. Les « conditions d’utilisation » de l’api du site de géolocalisation Foursquare²⁷⁰ indiquent par exemple que :

Vous pouvez mettre en cache les données que vous recevez […] mais vous devriez essayer de maintenir les données à jour et vous devez supprimer toutes les anciennes données. Cette permission ne vous donne aucun droit sur les données mises en cache. […] Vous de devez pas mettre en cache ou stocker toute information géographique […] pendant plus de 30 jours sans actualisation. Vous ne devez pas mettre en cache des informations concernant les « check-ins » d’un utilisateur pendant plus de 24 heures sans actualisation²⁷¹.

Au-delà de l’instabilité financière, il est fréquent que des fonctions soient supprimées, rajoutées ou modifiées, ou que l’adresse générale d’accès aux fonctions (l’url) soit déplacée. Cela peut entraîner une indisponibilité du site ou de l’application faisant appel à l’api. En ce sens, une api est davantage du côté de la compatibilité que de l’interopérabilité. L’interopérabilité suppose que l’on connaisse la totalité de l’interface, ce qui nécessite généralement d’utiliser des codes sources ouverts (dont on peut parcourir librement le contenu). Elle permet de savoir quand, pourquoi et comment un programme peut interagir avec un autre. La compatibilité est une notion plus vague. Elle décrit la faculté d’un outil à fonctionner dans un environnement précis dont toutes les caractéristiques sont respectées. Les modalités d’accès à l’api peuvent changer régulièrement, et ne permettent donc pas une stabilité des procédés d’échanges. Une fois qu’un site utilise une api propriétaire, il peut à tout moment se retrouver amputé de composants. Les api entendent se rendre indispensables pour certaines tâches car il est difficile de trouver des données correctement structurées en dehors d’organismes privés. Les api Google sont utilisées chaque jour par plus de quatre milliards de requêtes²⁷², et créent sur le Web une grande situation de dépendance par l’imposition de protocoles centralisés. Si le centre vient à faire défaut, l’ensemble du système est menacé. Le développeur faisant appel à l’api doit se tenir régulièrement au courant des changements [ Fig. 130 ] Fig. 130 alors qu’un programme interopérable assure un fonctionnement continu sur une durée la plus longue possible. En raison de son manque d’interopérabilité et de son inscription dans l’instant présent, l’api inscrit les programmes qui l’utilisent dans une obsolescence sinon « programmée », du moins probable.

Parce qu’elle masque les fonctions au travers d’une syntaxe simplifiée, l’api ne permet pas d’assurer parfaitement des passages de données d’un programme à un autre. Elle a davantage à voir avec une fluidification des échanges qu’avec une traduction des données. Un autre risque possible de cette centralisation est donc l’homogénéisation des interfaces en ligne. La commodité d’accès aux api entraîne l’apparition de « modèles de conception²⁷³ » de sites web. Il est désormais courant qu’un développeur conçoive la structure de son site web en terme de modules, briques de codes et fonctionnalités des api (on parle alors d’application web à base d’api, en anglais : « api-centric web application »). Le fait que l’exécution des fonctions soit déportée en dehors des objets dans lesquels les données apparaissent permet une abstraction du contexte. Les fonctions sont applicables à n’importe quel type de terminal : ordinateur, tablette, téléphone, etc. L’abstraction et la centralisation de l’api assure une communication unifiée²⁷⁴. Ce type de plate-forme n’est pas forcément destiné à des usages externes. Ainsi, le service de micro-messages Twitter a revu en 2010 son « architecture » autour d’une api lui permettant de distribuer ses propres données sur toutes les plate-formes disponibles²⁷⁵. Twitter possède une api interne, qui est plus complète que celle proposée aux développeurs tiers.

Beaucoup de sites web incorporent des api sans même le savoir. Citons pour exemple les outils dits sociaux comme le bouton like de Facebook [ Fig. 131 ]. Fig. 131 Ce dernier, en tant qu’il est un objet visuel exportable via une petite ligne de code, est ce qu’on appelle un « widget » (de l’anglais window gadget : fenêtre manipulable). Dans ce cas, on parle de « widget de site », c’est-à-dire d’un élément facilement ajoutable par le propriétaire d’un site web. Les widgets ont été popularisés par les blogs (qui désignent à la base des journaux personnels) en raison de leur facilité d’implantation. Il suffit en effet de copier-coller un code pour afficher des blocs dynamiques faisant appel à des données internes (un calendrier, une calculatrice) ou externes (le lecteur de vidéo YouTube, la météo, des flux rss, etc.) [ Fig. 115 ]. Fig. 133 Les widgets utilisent généralement des api pour agréger les données dans des blocs automatisés. Dans le widget, je n’ai plus accès au code source simplifié du langage formel de l’api, mais uniquement à une fenêtre que je peux parfois paramétrer via des éléments graphiques. Si en eux-mêmes les widgets ne sont pas reliables à des environnements forcément fermés, leur facilité d’accès fait courir le risque d’une uniformisation des interfaces en ligne, qui tendent à se ressembler.

Les api, en tant qu’elles sont avant tout un mode d’accès à des données, c’est-à-dire des techniques, peuvent être indifféremment reliées à des bases de données ouvertes (libres) ou fermées (propriétaires). On retrouve ainsi des api au code source ouvert dans des « systèmes de gestion de contenus » (« cms » ) comme WordPress, des kits de composants logiciels (« frameworks ») comme Symphony, Zend Framework, Cakephp, des librairies de code comme jQuery ou Mootools. Une base de publication open source peut en effet proposer des contenus qui seront eux seront soumis à droits d’auteur. Alors que le besoin se fait de plus en plus sentir d’avoir accès à des données librement utilisables (donc pratiquables), on constate que les api servent très majoritairement à établir des écluses dont on peut faire varier le débit (de données) en fonction de la demande. Les exemples de sites produisant en grand nombre des données et les laissant accessibles via des api non-restrictives sont rares. Citons pour exemple le site de cartographie contributive OpenStreetMap qui « n’est pas une carte, mais une base de données cartographiques qui permet de faire des cartes²⁷⁶ ». Il permet à n’importe qui de contribuer à la création de cartes placées sous licence libre²⁷⁷. Il est intéressant de comparer la manière dont OpenStreetMap et Google Maps organisent le partage et l’emploi de leurs données. Google passe des accords locaux avec des fournisseurs de contenus, et interdit logiquement de copier, d’exporter ou modifier les données accessibles par son api²⁷⁸. À l’inverse, OpenStreetMap propose une api gratuite et limitée en volume pour des raisons techniques et financières : « Bien qu’OpenStreetMap soit un ensemble de données ouvertes, nous ne pouvons pas fournir d’api libre de frais pour les développeurs tiers²⁷⁹. » Le volume d’échange de données est limité, mais OpenStreetMap ne va pas faire payer au-delà des volumes indiqués. Le site va juste bloquer l’accès à ses api tant qu’aucun accord n’est trouvé. Pour remédier en amont à ce problème, OpenStreetMap propose de recourir à des sites miroirs, qui recopient les données afin d’alléger les serveurs principaux et prennent le relais en cas d’indisponibilité ponctuelle. Plus encore, n’importe quel serveur personnel peut héberger des données issues d’OpenStreetMap. L’api OpenStreetMap peut elle aussi être téléchargée et hébergée n’importe où, ce qui permet des possibilités potentiellement infinies. On peut ainsi imaginer un réseau autonome qui pourrait diffuser des cartes suivant des protocoles d’échange simplifiés ou complétés. L’ouverture de l’api et des codes sources permet de varier les typologies de rendu. En témoigne le site http://www.openwhatevermap.org [ Fig. 135 ] Fig. 135 qui propose une mosaïque impossible à reproduire par des api propriétaires. OpenStreetMap, que Tim O’Reilly pourrait ranger dans le « Web 2.0 » (participatif, plate-forme, api, etc.) est donc radicalement opposé à Google Maps. Le succès de l’api Google Maps s’explique par la clarté de sa documentation, par sa (supposée) plus grande base de données ainsi que par sa connexion aux autres services de Google. « L’avantage concurrentiel » (Tim O’Reilly) tient moins ici de la qualité des données que de la volonté d’installer insidieusement l’idée d’une relation de confiance et de sérieux par l’emploi d’une stratégie de marque. OpenStreetMap fait retour du « Web 2.0 » vers l’Internet, vers un décentrement des échanges et des contenus. Si les données de ce dernier peuvent être appelées depuis un serveur principal, elles peuvent aussi à tout moment être exportées et redistribuées librement.

Les api, comme on l’a vu, participent d’une double opération d’ouverture et de fermeture. Les api propriétaires permettent de gérer des droits d’accès finement contrôlés et évolutifs. Dans le même temps, des systèmes ouverts comme OpenStreetMap permettent d’inventer des manipulations inédites de données décentralisables. Pour autant, il serait trop simple de penser que l’api ne serait appropriable que dans le cadre de fonctions ou de données non-propriétaires car un système aux codes sources libres n’est pas forcément manœuvrable. Les api propriétaires sont souvent mieux documentées (expliquées) que les api libres, car il y a une volonté de répandre leur utilisation afin de créer une situation où de l’économie est possible. De nombreux services web émergent ainsi en se basant sur ces briques facilement paramétrables, prêtes à l’emploi. Il s’agit de profiter de l’accès à des données, et plus généralement à des puissances de calcul inaccessibles jusqu’à peu. Il y a une excitation grisante à pouvoir profiter gratuitement (mais pas librement, ce point est trop vite oublié) de possibilités immédiatement et facilement accessibles. On va sélectionner dans des bibliothèques (« library ») ce dont on a besoin pour construire rapidement un service. Pour rester dans la terminologie du « Web 2.0 », on parle de mash-up (mixage) pour désigner une « application composite », c’est-à-dire constituée majoritairement de briques technologiques. On passe alors d’une logique où l’on cherchait à optimiser et à comprendre l’intégralité de son code source à un modèle où l’on fait avec ce qui existe sans chercher à tout comprendre ou maîtriser, ce qui pose de nombreux problèmes de sécurité car les codes ne sont pas vérifiés ou vérifiables. Si aucune création ne peut se faire ex nihilo, on peut malgré tout s’interroger sur ce design des programmes qui repose essentiellement sur du déjà là, sans le réinterroger.

Nous avons donc listé quatre grands risques découlant d’un usage d’une api : la pression financière, l’instabilité de son fonctionnement, l’homogénéisation des interfaces, et son invisibilité structurelle. La façon dont les codes sources nous paraissent sous forme d’interfaces visuelles similaires ne facilite pas la distinction entre ce qui relèverait (sous couvert d’ouverture) d’une fermeture, et ce qui serait du côté d’un décentrement effectif. Si les api propriétaires permettent de penser le Web en termes de modules par une structuration réfléchie des données, elles sont surtout un moyen invisible de contrôler ce qui peut sortir et ce qui peut entrer ; elles sont les nouveaux péages du Web. En sécurisant les interactions distantes, elles renforcent de fait l’idée de pôles d’attraction. La disponibilité des données n’est pas synonyme de mise à disposition. On ne peut pas réellement pratiquer des données qui sont régies par des « conditions d’utilisation » restrictives et susceptibles de changer sans préavis. Le fait même de parler d’utilisations qui seraient conditionnées nous éloigne d’une possibilité d’ouverture effective des programmes. Les api participent de « stratégies » d’ouverture, ce qui est tout à fait différent. Comme le note Michel de Certeau,

Le « propre » [de la stratégie] est une victoire du lieu sur le temps. Il permet de capitaliser des avantages acquis, de préparer des expansions futures et de se donner ainsi une indépendance par rapport à la variabilité des circonstances. C’est une maîtrise du temps par la fondation d’un lieu autonome²⁸⁰.