We make data porn : Les portails sont inefficaces

Chaque portail Open-Data est différent. Je ne parle pas, bien entendu, du design, mais de la manière dont les données sont présentées et proposées. Certains mettent l’accent sur la sémantique, d’autres sur les outils de recherche, d’autres encore sur les API… mais ne passent-ils pas à coté de quelque chose de plus important ?

Quel public ?

Comme toujours, revenons aux fondamentaux : à qui s’adresse un portail Open-Data ? Ou plus précisément, demandons-nous quelle est la typologie des consommateurs d’Open-Data.

Observateurs

En premier lieu, nous avons ceux qui s’intéressent aux données, sans pour autant les analyser avec une extrême précision, et qui ne créent pas d’applications les utilisant. Ce qui les intéresse, ce sont généralement des données basiques : comptes rendus de délibération, statistiques, montant des financements… appelons-les les «observateurs». Il ne font qu’observer les données, ne les réutilisent pas vraiment, et n’en créent pas non plus. ils n’ont pas vraiment besoin de formats de fichiers spécifiques, tout ce qu’ils peuvent ouvrir et lire directement leur convient. La licence, elle non plus, n’est pas vraiment importante pour eux : ils ne réutilisent pas vraiment la donnée, au mieux, ils citent qu’ils ont vu telle ou telle donnée sur tel portail.

Analystes

Nous avons en suite les «analystes». Non seulement ils utilisent en général des données plus précises, mais ils croisent ces données et en créent de nouvelles. Ils réutilisent les données à des fins de recherche ou d’analyses. Ce qui les intéresse, ce sont généralement des données précises d’ordre socio-économiques, démographiques ou géographiques. Ils ont besoin à la fois de croiser les données entre elles (par exemple : population des différents quartiers, types de logement et dépenses publiques par quartiers) mais aussi de les replacer temporellement et géographiquement des unes par rapport aux autres. Ils utilisent pour se faire des applications spécifiques de visualisation de données (ou dataviz) qui nécessitent des formats spécifiques, et se préoccupent des licences, car ils croisent souvent plusieurs jeux de données provenant de diverses sources, parfois commerciales, et ont aussi parfois besoin de pouvoir redistribuer les données valorisées sous forme commerciale. Plus que consommateurs, ils sont aussi producteurs de données.

Développeurs

Le dernier type, mais non le moindre, sont évidemment les «développeurs». Ces gens là, ce qui les intéresse c’est, pour ainsi dire, tout ce qui peut être traité par un algorithme, plus exactement, tout ce qui, en étant traité par divers algorithmes, peut aboutir à une application. Ils s’intéressent à tout : données, métadonnées, licences, formats de fichiers, mais aussi version, précision des données, fréquence de mise à jour… Leur but n’est pas de créer des applications pour créer des applications, mais de créer des applications qui permettent de rendre service aux utilisateurs, et parfois d’en faire un business. Dans cette catégorie d’utilisateurs, j’inclue une sous-catégorie : les libristes. Ceux là, en plus de vouloir des données pour développer, ils veulent des données libres qu’ils puissent réinjecter dans d’autres bases de données libres, comme OpenStreetMap. À ces braves gens, il leur faut des données dans des formats standards directement utilisables par leurs applications, des API statiques et temps réel, des licences bien définies et libres de préférence (on en reparlera dans un prochain billet), des moyens de contrôler – depuis leurs applications, ça va sans dire – la fraîcheur des données, rien que ça. Ils ne font pas que consommer des données, ils en produisent eux aussi. Lorsqu’ils nettoient un fichier de données par exemple, ou qu’ils en croisent plusieurs pour les vérifier et en uniformiser la syntaxe (rappelez-vous : les données sont toujours fausses !) ou qu’ils traduisent un fichier de données d’un format vers un autre (rappelez-vous : les formats de fichiers sont mauvais !) ils créent de la donnée et, lorsque cette donnée était, à la base, libre, en général ils sont enclins à redistribuer librement cette nouvelle donnée à leur tour.

Cette typologie du public nous révèle les usages des données, mais aussi les besoins des consommateurs de données, ainsi que les interactions nécessaires. Grâce à cela, nous pourrons déterminer comment faire en sorte qu’un portail Open-Data remplisse pleinement ses fonctions.

Quels besoins ?

L’étude de la typologie des consommateurs de données nous révèle plusieurs besoins fondamentaux vis à vis de ces données, à savoir :

  • Rechercher des données, suivant des termes de recherche, mots clés, sémantique…
  • Visualiser les données, soit directement sur le portail (cas des données SIG), soit en ouvrant un fichier (cas des données tabulaires ou textuelles) via un logiciel commun ou répandu.
  • Utiliser les données, directement dans un outil de dataviz ou dans une application spécialement développée, voire même un tableur.
  • Remonter des données, soit valorisées par une analyse, soit nettoyées et croisées à l’occasion de leur intégration par exemple.
  • Mettre à jour les données téléchargées afin de maintenir une application à jour, ou compléter une analyse.
  • Identifier ce qu’il est possible de faire avec les données, de manière très simple. En effet, tout le monde n’est pas juriste ! Un lien vers le texte d’une licence ne suffit pas à éclairer l’utilisateur sur ces droits et devoirs.
  • Demander des données qui ne seraient pas dans le catalogue et signaler d’éventuelles erreurs.

Nous avons désormais tous les éléments en main pour savoir à quels besoin répondre : explorons les possibilités.

Répondre aux besoins

Les besoins listés plus haut sont relativement simples à satisfaire. Si nous faisions un parallèle, en considérant les jeux de données comme des articles de blog, on peut s’apercevoir qu’un outil de publication de contenu comme WordPress ou Drupal peuvent, sans modifications, répondre à la plus part des besoins. Ces outils permettent, pour chaque article/jeu de données :

  • d’ajouter des métadonnées (tags, catégories, licences…)
  • d’effectuer des recherches et des tris en fonction de mots clés, catégories, dates, auteur (ou producteur de donnée), métadonnées…
  • de permettre un dialogue avec la communauté grâce à la possibilité de poster des commentaires sur chaque article
  • d’associer des fichiers à chaque article

De plus grâce à des outils communautaires comme BuddyPress, il est simple de mettre en place un véritable portail communautaire.

Concrètement, un portail Open-Data ne devrait pas être trop éloigné, dans son aspect comme dans son fonctionnement, d’un simple blog. Sur chaque article correspondant à un jeu de données, on devrait voir apparaître les sections suivantes :

  • Description détaillée de la donnée avec éventuellement les modalités de recueil et l’explication des différents champs le cas échéant.
  • Zone listant les fichiers téléchargeables.
  • Éventuellement, pour les données SIG par exemple, si possible, une visionneuse (ou un lien vers une visionneuse) permettant directement de voir la donnée.
  • Une zone permettant d’identifier clairement qui est le producteur de la donnée et qui en détient les droits (il peut y avoir plusieurs sources de données sur un même portail)
  • Une zone indiquant la date de publication, et de mise à jour (avec un lien permettant de télécharger les versions précédentes, l’évolution de la donnée pouvant être, en elle même, une donnée à part entière)
  • Une zone indiquant quelle est la licence appliquée à la donnée ainsi qu’un résumé des droits qu’elle confère et des obligations qu’elle impose (ou un lien vers une page qui présente ce résumé) avec éventuellement une liste de licences compatibles. Vous pouvez prendre exemple sur cet article où, en colonne de droite, se trouve une section nommée «licence d’utilisation».
  • Une zone indiquant la catégorie (ou sous-catégorie) à laquelle le jeu de données se rattache
  • Une zone présentant des mots clés correspondant au jeu de données (avec éventuellement la possibilité pour l’utilisateur d’en proposer d’autres)
  • Une zone de commentaires propre à chaque jeu de données, permettant un échange simple et rationnel avec les utilisateurs.
  • Une zone de recherche, soit globale, soit avec des critères de tris par taxonomie (par catégorie, tag, licence…)

Ça parait simple, mais bien peu de portails possèdent plus de la moitié de ces fonctionnalités…

Vérifions où nous en sommes par rapport à notre liste de besoins :

  • Rechercher des données, suivant des termes de recherche, mots clés, sémantique… → OK sauf sémantique
  • Visualiser les données → OK
  • Utiliser les données, directement dans un outil de dataviz ou dans une application spécialement développée. → OK mais pourrait être mieux
  • Remonter des données, soit valorisées par une analyse, soit nettoyées et croisées à l’occasion de leur intégration par exemple.
  • Mettre à jour les données téléchargées afin de maintenir une application à jour, ou compléter une analyse. → OK mais pourrait être mieux
  • Identifier ce qu’il est possible de faire avec les données, de manière très simple. → OK
  • Demander des données qui ne seraient pas dans le catalogue et signaler d’éventuelles erreurs. → On peut le faire en partie seulement

Plutôt pas mal, non ? Avec un outil existant, à peine customisé, on a déjà un portail qui tient la route. De plus, ces systèmes de publication peuvent générer automatiquement des flux RSS ou Atom permettant aux personnes intéressées de suivre la publication de nouveaux jeux de données sans devoir aller les rechercher à la main. Pour autant, tous les besoins ne sont pas satisfaits. Il nous reste, en résumé, à:

  • rajouter un peu de sémantique : des formats de fichiers dédiés existent pour cela;
  • permettre de dialoguer sur des jeux de données encore inexistants : un forum ferait parfaitement l’affaire. Ça tombe bien, nos outils de blog (WordPress ou Drupal) peuvent nous fournir cette fonctionnalité via des modules complémentaires (ou plugins).
  • permettre de proposer des jeux de données (le forum peut tout à fait remplir cette fonction, mais on peut faire encore mieux ; cf points suivants)
  • permettre de soumettre des corrections / remonter des données : c’est un besoin bien connu des développeurs de logiciels libres, ils ont même une solution pour ce «problème».
  • permettre la mise à jour des données directement depuis les applications, de même que récupérer d’anciennes versions de ces jeux de données : même chose que pour le point précédent, la communauté du logiciel libre a déjà une solution pour ça !

Métadonnées

On l’a vu, un outil de publication de contenu comme WordPress permettrait d’associer la fiche du jeu de données à des métadonnées diverses (tags, licence, catégorie) mais qu’en est-il des autres métadonnées ? Je parle des métadonnées INSPIRE et RDF.

Ces métadonnées ont, globalement, les mêmes buts :

  • décrire précisément les données ( identifiant, titre, description, langue, jeux de caractères, description du format de données…)
  • classifier les données dans des catégories plus ou moins unifiées (ce qui permet le croisement et la recherche sémantique globale sur plusieurs portails)
  • taguer les données

Les métadonnées INSPIRE concernent les données géographiques, et sont définies très précisément dans une norme. Je vous invite à lire le document explicatif de la norme INSPIRE et à voir un exemple de fichier de métadonnées INSPIRE sur le portail Open-Data de la région PACA  (note : il n’est nullement une obligation d’utiliser le format PDF, je dirais même qu’une bonne idée serait d’utiliser, en parallèle, un format XML permettant à une application d’intégrer automatiquement ces données… le mieux étant d’utiliser un format texte et un format XML).

Les métadonnées RDF (qui peuvent d’ailleurs intégrer le référentiel INSPIRE, RDF étant basé sur XML, et la norme n’imposant nullement un format plutôt qu’un autre), concernent globalement toutes les données, cependant, contrairement à INSPIRE, l’absence actuelle d’une réelle nomenclature commune ne permet pas de tirer tout le potentiel de ce format.

Les métadonnées peuvent être fournies sous plusieurs formats, comme sur le portail Open-Data de la Ville de Montpellier, où on trouve les métadonnées au format RDF, CSV et texte sur la fiche de chaque jeu de données.

Dans l’idéal, il serait utile de retrouver au moins les métadonnées au format RDF (et intégrant le référentiel INSPIRE lorsqu’il s’applique) et texte. Cela permet, outre le croisement de données et l’apport d’un minimum de sémantique, d’automatiser un minimum la récupération automatisée des fichiers de données. En effet, le format RDF permet d’inclure, dans un format directement exploitable par les applications, toutes les données nécessaires :

  • dates de publication et mise à jour
  • identifiants uniques
  • période de validité / mise à jour
  • URLs des fichiers représentant le jeu de données sous différents formats numériques.

Dans l’idéal, encore, les producteurs de données devraient se concerter afin de créer un référentiel commun de thématiques, cela permettrait une réelle interconnexion des jeux de données, et une relative uniformisation des recherches ; cette réflexion a d’ailleurs déjà commencée au sein du collectif OpenDataFrance (cf compte rendu de la première réunion du collectif).

Dépôt de données

Il existe une communauté rompue depuis des années à la publication de données ouvertes (et libres) : la communauté des développeurs. Pour publier des données (principalement du code source, des documentations… qui restent des données) et automatiser leur mise à jour, ou encore permettre la proposition de données ou de corrections, cette communauté, qui ne date pas d’hier, a déjà imaginé et mis en place tout l’arsenal nécessaire, des outils aux licences. Pourquoi ne pas utiliser ces outils et ces méthodes dans l’Open-Data ?

Pourquoi ne pas associer un dépôt Git à notre portail Open-Data ? Via Github par exemple ? Un dépôt permet de présenter les données de manière hiérarchisée, versionnée et dynamique. Pour faire simple, en déposant les données (les fichiers les contenant ainsi que les fichiers de métadonnées accompagné d’un fichier texte contenant la description du jeu de donnée) dans un tel dépôt, il est possible :

  • de permettre d’automatiser la récupération initiale et les mises à jour des données
  • de permettre la soumission directe de données complémentaires, valorisées ou re-formatées par les utilisateurs
  • de garder une trace des versions précédentes et d’y revenir à n’importe quel moment.

Pour celles et ceux qui n’auraient jamais mis le pointeur sur Github, ça ressemble à ça :

On peut y voir, sur le premier lien, tous les dépôts «appartenant» à Modulaweb et, pour chaque dépôt, il est possible de télécharger les données d’un coup. Un autre exemple : le dépôt du Bundestag. Oui, le parlement allemand à créé un dépôt, contenant rien de moins que toutes les lois du pays. Cerise sur le gâteau : sur Github, tant que les dépôts sont publics, ils sont gratuits. Le dépôt peut donc aussi servir de stockage pour les fichiers, ce qui permet des économies non négligeables concernant l’hébergement du portail qui n’a plus à stocker lui même les données…

Si vous ne deviez retenir qu’une chose à propos des dépôts de données, c’est que sont des outils qui facilitent la vie du producteur de données, de l’animateur du projet OpenData et de la communauté elle même tout en rationalisant et structurant les données.

Quelques compléments concernant les dépôts : un dépôt comme Github est gratuit et stocke les données. Vous n’avez même plus besoin de louer ou un serveur conséquent pour stocker vos jeux de données ! De même, un site peut être hébergé gratuitement via la plateforme Github ! les coûts récurrents d’un portail OpenData en sont minimisés d’autant.

Nous en avons fini avec notre portail idéal : il remplit, avec le dépôt sur Github, tous les besoins de tous les utilisateurs, et cela durablement, à moindre coût et moindre complexité.

Conclusion

Le portail Open-Data idéal est en fait l’association d’un blog à peine customisé, associé à un forum de discussion, le tout interconnecté avec un dépôt Github. Rien d’insurmontable, même pour une petite structure, tant coté prix que complexité de mise en œuvre ou même gestion au jour le jour.

Un commentaire à propos de “We make data porn : Les portails sont inefficaces

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>