DataCulture et ApiCulture

Pour tous ceux qui, comme moi-même, on fait l’apologie des données, de leur ouverture, de leur modèle et de leur format, le curseur a donc toujours été placé sur le primat des données, ce qui se traduit par des expressions du type « Data Driven … », « Ressources Oriented … », « Web of Data », « LinkedData, etc.

Dans cette vision et ce soin tout particulier apporté aux données – que j’appelle Dataware – c’est une forme d’autonomisation de la gestion des données qui est prônée, et qui conduit à utiliser tout un spectre sémantique de la “libération des données”. Il fallait, et il faut toujours, libérer les données des bases de données relationnelles, libérer les données des logiciels qui encapsulent la sémantique des données , etc.

La Data seront libérées si et seulement si elles sont autonomes au sens sémantique du terme, c’est à dire auto-descriptives via les liens typés qu’elles tissent entre elles. Il y a un fond « encyclopédique », au sens simondonien, dans cette démarche.

Dans ce contexte, l’apparition des API à été vécu à la fois comme la preuve de l’importance des données (mieux exposées grâce aux APIs on pouvait faire des mashups ) mais, en même temps, cette étape des API devait être transitoire jusqu’à la libération complète des données car, continuer à parler d’interface, c’était admettre qu’on était toujours contraints dans l’accès aux données (voir ma note sur les données mises à nue). Seulement voilà, non seulement les APIs sont restées mais en plus elles ont une croissance exponentielle.

Quand on a commencé à parler d’API RDF (expression antinomique s’il en est) un grand trouble s’est installé dans ce qui allait devenir la “communauté OpenData”. L’essentiel du trouble venant de la polysémie des utilisations du mot “interface”. Bien qu’utilisé dans des contextes et des significations différentes, ce terme assez générique a ici toute son importance : les API de Twitter sont des interfaces, les écrans que nous regardons et les claviers que nous touchons sont des interfaces hommes / machines, les classes et librairies des langages de développement sont également des interfaces, etc.

Les APIs dont je parle ici sont des interfaces pour des communications d’automates à automates telles les APIs publiées par les acteurs de l’économie du web ; celles de Twitter, Google, Amazon, et les milliers d’autres que recense l’annuaire des APIs de programmable web :

Pendant que le monde des OpenAPI ( “Open” parce que “publié ouvertement”, et non parce que gratuit) était en ébullition, le monde de l’OpenData publiait un autre annuaire, celui des corpus de données qui ne cessent d’augmenter le LinkedData, de 2007 (12 jeux de données) à 2012 (295 jeux de données) :

Les initiatives des différences puissances publiques pour s’inscrire dans une démarche OpenData se sont faites dans une relative confusion : la plupart des données publiées n’entraient ni dans une logique OpenAPI, ni dans une logique LinkedData en proposant souvent des documents bureautiques incompréhensibles ou inexploitables par les automates. L’openData a viré à la bureautiques ouverte.

Ou en est-on a présent ? Et posons même la question de manière plus tranchée : vaut-il mieux ouvrir ses données (“raw data now”) ou bien ouvrir ses API ? OpenData ou OpenAPI ?

Les faits ont tranché : il y un phénomène massif d’OpenAPI , là où les OpenData n’ont qu’un succès d’estime. Les deux ne sont d’ailleurs pas antinomiques : faire de l’OpenAPI est sûrement une des meilleures façon de faire de l’Opendata. La finalité reste la même – publier des données – mais, avec les APIs, l’emphase est mise sur leur interface et donc sur les manières de communiquer avec et d’interagir avec ses données.

Dans une démarche orientée API, la démarche de conception se focalise sur les actions possibles sur les données, ce qu’explique l’excellent article API-first de Evan et Fiona qui décrivent l’intérêt de penser d’abord à l’API dans le développement d’une application Web. Mais toutes les organisations qui désirent ouvrir leurs données ne peuvent pas facilement penser de cette manière, surtout les institutions qui ont des fonctions d’archivage et de catalogage.

On peut – comme je le fais souvent – considérer la mise à disposition des données comme une démarche de catalogage où ce qui prime est la richesse et la complétude des données qui elles-même peuvent se coupler et se compléter avec d’autres jeux de données publiées (la vision LinkedData). Mais dans un cas, celui des institutions publiques pour aller vite, on parle de catalogage des données (OpenData), là ou dans l’autre on parlera plutôt de catalogage des requêtes (OpenAPI).

Comme on peut le voir, je ne cherche pas à opposer ces deux démarches. Une institution qui publie ses données et son catalogue a généralement du mal à se représenter les types de requêtes qui seront faites sur leur corpus de données. Ne sachant pas a priori comment optimiser son système de publication en fonction de certains types de requêtes, elle va donc privilégier un mode d’accès générique et le plus ouvert possible à tout type de requête (un langage de requête plutôt que des requêtes préfabriquées), y compris des requêtes complexes, ce qui va forcer a  avoir une attention particulière à la modélisation des données qui doit être la plus descriptive possible grâce aux liens  entre les données ; c’est là que les normes du web sémantique s’imposent.

Pour ceux qui n’ont pas une approche de type catalogue de données, la priorité n’est pas la donnée seule, mais la gestion des actions et des accès aux données. Dans ce cas là on préférera donc faire un catalogue des actions sur les données plutôt que des données en tant que telles.

Une organisation œuvrant dans l’économie marchande va passer systématiquement par une approche OpenAPI plutôt que par une approche Opendata car, non content de maîtriser ses données, elle souhaite surtout garder la maîtrise des accès aux données ( “j’ouvre à ma manière et je peux modifier ou supprimer l’accès comme et quand je le veux”), c’est la raison pour laquelle le grand public entend souvent parler des APIs lorsque les conditions d’utilisation changent et provoquent des remous comme par exemple récemment avec la version 1.1 de l’ API de Twitter.

Autre élément déterminant dans la distinction entre une démarche OpenAPI et une démarche OpenData : la nature des données. Si les données sont des vérités éternelles au sens encyclopédique du terme, on peut dire qu’elles ne changent pas (mêmes si elles peuvent toujours être enrichies), alors une démarche OpenData est à privilégier. Si en revanche les données auxquelles on veut donner accès changent dans le temps (comme par exemple un statut sur un réseau social, un objet communiquant avec un capteur, etc. ) alors une approche OpenAPI sera plus adaptée.

On mesure souvent le succès d’une API au nombre de requêtes auxquelles elle répond ( à son trafic ), mais la plupart de ces requêtes interrogent un nombre réduit de données ; ce qui justifie le nombre des requêtes est que les données changent avec une grande fréquence. C’est donc la durée de vie des données et leur cycle de mise à jour qui suscite de nouvelles requêtes .

En ce qui concerne les institutions publiques, la recommandation serait donc la suivante :

  • Pour les institutions d’archivage et de conservation, privilégier l’aspect OpenData (des initiatives OpenApi devraient toutefois être développées en parallèle si l’on souhaite participer à l’économie marchande) ;
  • Pour les institutions d’enseignement et de recherche il y a un là un bel équilibre à trouver entre OpenData et OpenAPI ;
  • Pour les institutions administratives , privilégier l’aspect OpenAPI.

Pour le reste de l’économie c’est l’OpenAPI qui prime pour ceux dont l’activité ou le modèle d’affaire est dé-corrélé des aspects que j’ai ici qualifié d’encyclopédiques.

J’espère que ces quelques réflexions pourront contribuer au débat et être utiles aux projets d’ouverture des données.

Bonjour,
merci de cet article. Le titre est intéressant mais vous ne développez pas cette notion de « dataculture » sur laquelle je travaille également et qui comme le terme de « culture » voudrait l’indique renvoie selon moi non pas des formes automatisées mais à celles générées par les utilisateurs.
Bonne continuation

[Reply]

Chère Laurence,

Ton commentaire m’a laissé perplexe parce que je ne savais pas comment l’interpréter. Il est toujours difficile de répondre à une remarque qui souligne ce que l’on a pas dit mais sans dire explicitement pourquoi cela a un lien avec ce qui est dit.

Sinon, c’est intéressant et en même temps troublant si on en vient à définir la culture comme ce qui n’est pas automatique ou automatisé. Sans vouloir polémiquer je pourrais dire que la culture est précisément une affaire de programmes et d’automatismes comportementaux.

Les enjeux culturels sont de plus en plus des épreuves pour arriver à vivre avec l’automate. AVEC et non à côté ou contre. Mais je sais que tu est sensibilisée à cela plus que moi grâce au travail que tu as fait sur les pratiques associées aux téléphones mobiles.

J’entends bien la notion de « pratiques » des utilisateurs au sens où les données dont nous parlons sont surtout produites et renseignées par les utilisateurs, et avec des comportements qui ne sont pas forcément prescrits par ceux qui ouvrent leur APIs (ahem…).

Mais la « culture des data » relève ici (dans cet article) plus des cultures de conception et d’architecture pour des transferts de données entre automates que des pratiques d’utilisateurs. Ce qui ne veut pas dire que les comportements des utilisateurs n’ont rien à voir dans cette histoire, nous sommes tous convaincus du contraire.

Un lien vers un de tes textes sur cette question ?

[Reply]

Merci d’avoir pris le temps de répondre. En effet c’était un petit commentaire spontané et un peu lapidaire d’une lectrice alléchée par le titre mais qui était restée sur sa faim. Dans mon corpus hashtagé #dataculture je renvoie de fait aux pratiques de « mise en culture » des data par les utilisateurs qui en sont créateurs veilleurs et interprètes sous des modalités diverses (dataviz, cartes, remix sonores etc.). Entre dataculture et culture des data, il y a donc co-extensivité : plutôt une bonne nouvelle:)

[Reply]

Bonjour Christian, merci pour cette note, elle m’a inspiré quelques commentaires ici : http://francart.fr/opendataversusapi/
A+

[Reply]

[…] avec un article de Christian Fauré qui montre que, dans une démarche d’ouverture, l’OpenData n’est pas la seule solution et que la création d’une API peut être plus légitime, selon le type de données et de […]

[…] transactions ciblés à la place d’échanges de fichiers. Comme le montre C.Faure dans cet article, exposer des API c’est exposer intelligemment les données de son […]

[…] Lors de la conférence APIdays qui s’est tenue les 3 et 4 décembre 2012 (merci à faberNovel et Webshell), j’ai profité de mon intervention pour revenir sur la distinction entre OpenAPI et OpenData, entre APIculture et DataCulture. […]

[…] Dans une démarche OpenData, le Fournisseur n‘anticipe pas les besoins de l’écosystème : exposer des données brutes n’impose aucune contrainte aux Éditeurs. Cette neutralité fonctionnelle, facilitantl’usage des données au sein de configurations multiples, différencie notamment l’OpenData de l’OpenAPI comme le montre C.Faure dans « DataCulture et ApiCulture ». […]

[…] avec un article de Christian Fauré qui montre que, dans une démarche d’ouverture, l’OpenData n’est pas la seule solution et que la création d’une API peut être plus légitime, selon le type de données et de […]

[…] l’a montré Christian Fauré dans son billet « DataCulture et APIculture », les principes du Linked Data et la mise en place d’Open API sont complémentaires et […]

[…] Un service SPARQL met à disposition toutes les données pour tout type de requête. C’est la différence entre open data et open API que décrit Christian […]

[…] avec un article de Christian Fauré qui montre que, dans une démarche d’ouverture, l’OpenData n’est pas la seule solution et que la création d’une API peut être plus légitime, selon le type de données et de […]

 

Répondre à Le marché des API WEB | Contribuez ! Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.