Donnée brute ou donnée contextualisée ?

La mission gouvernementale Etalab lance une consultation autour de l’évolution du portail data.gouv.fr. Vous êtes invités à contribuer à cette démarche de co-design. C’est aussi l’occasion de repenser plus globalement la conception des portails open data… A quoi et à qui servent-ils ? Comment doit-on présenter les données ? Je vous propose une série de billets sur ce thème. Le premier traite de la donnée elle-même et de la tension entre donnée brute et donnée contextualisée…

1 – Un cas pratique : la fréquentation des musées

J’ai récemment animé un atelier de sensibilisation à l’open data pour les acteurs culturels d’une collectivité. A cette occasion, j’ai repéré un jeu de données disponible sur le portail gouvernemental. Ce fichier propose les chiffres de la fréquentation des musées de France, de 2006 à 2010. Je vous invite à télécharger celui qui concerne la région Bretagne (pour plus de facilité, je vous propose aussi une copie d’écran ci-dessous, que vous pouvez agrandir en cliquant).

(cliquer pour l'agrandir) - fréquentation des musées de France, source Ministère de la Culture sur data.gouv.fr

La fréquentation des musées de France, source Ministère de la Culture sur data.gouv.fr (cliquer pour agrandir l’image)

Le tableau présente les chiffres de fréquentation pour chaque « musée de France » situé dans la région. On a donc le nom du musée (ex. « musée des beaux-arts »), une ville, puis les chiffres de fréquentation répartis en 2 colonnes « total » et « grat ». On peut raisonnablement supposer qu’il s’agit des entrées gratuites (mais rien ne le précise formellement, ni dans le fichier, ni dans la fiche de métadonnées). D’autres colonnes précisent l’évolution de la fréquentation d’une année sur l’autre.

Le code couleur est expliqué en pied de page du fichier. La couleur noire représente des « données confidentielles », avec la mention « contacter le chef d’établissement », les autres couleurs viennent apporter des éléments de contexte sur la fréquentation de tel ou tel musée. En l’occurence il y est surtout question d’évènements exceptionnels susceptibles d’expliquer le chiffre de fréquentation : fermeture ou réouverture d’un musée, exposition temporaire ayant entraîné une fréquentation exceptionnelle, …

Plus intéressant, la première colonne du tableau contient un numéro de référence, qui **semble** être un identifiant unique accordé à chaque musée de France.

2 – La tension « brutification » vs. contextualisation

La lecture de ce fichier permet d’illustrer la tension entre deux tendances qui s’expriment aujourd’hui dans le monde de l’open data.

La première tendance est liée à une demande de « brutification ». Je reprends ici le terme évoqué par Samuel Goeta et Jérôme Denis pour décrire l’une des actions qui se déroulent dans les coulisses de l’open data (le thème de la thèse de Samuel à Telecom Paris Tech).

Pour permettre la mise en place d’un ensemble de services sur le portail open data, il faudrait que la donnée proposée soit la plus brute possible (et je parle bien là d’une donnée brute techniquement, pas en termes sociologiques).

Parmi ces « services » on peut citer par exemple la pré-visualisation des jeux de données sans avoir à ouvrir le fichier (une fonctionnalité très utile et déjà mis en oeuvre ailleurs), la datavisualisation ou représentation cartographique par défaut (un exemple ici), ou enfin même les API (des interfaces de programmation qui font aujourd’hui cruellement défaut dans la plupart des portails, à quelques exceptions près). Sans même parler d’un pas vers le web des données et le Linked Data, une attente forte des acteurs du web sémantique.

Reprenons le fichier sur la fréquentation des musées : pour proposer tous ces services il faudrait donc faire un travail *supplémentaire* de brutification : retirer les codes couleurs, ignorer les colonnes qui proposent une donnée recalculée (le taux d’évolution d’une année sur l’autre, les totaux, …) et plus globalement retirer tout ce qui concerne la mise en forme du fichier. On pourrait d’autre part mieux utiliser des données qui y figurent déjà, ainsi le fameux numéro de référence.

J’ai trouvé sur le portail un autre fichier qui fournit des informations complémentaires sur les musées de France : leur adresse postale, le site web, les horaires et jours d’ouverture. Problème : ce fichier ne propose aucun identifiant unique. On a là une occasion manquée de permettre une mise en relation et un enrichissement de deux fichiers (open data 1 – web sémantique 0).

La donnée proposée ici n’est donc pas tout à fait « brute » … mais elle n’est pas tout à fait contextualisée non plus !

La seconde demande qui émerge – et qui de prime abord peut sembler contradictoire avec la brutification – est liée à la contextualisation de la donnée.

J’ai déjà eu l’occasion ici de parler de l’importance d’une lecture critique des données. Si l’on considère le fichier sur la fréquentation des musées, ce besoin de contextualisation apparaît rapidement : qu’est-ce qu’un « musée de France » ? comment les données de fréquentation sont-elles collectées ? quel est l’usage initial des données ? qui la collecte et pour quoi faire ? Et enfin, la meilleure : pourquoi certaines données sont-elles considérées comme « confidentielles » (celles dont les cases portent la couleur noire) ?

La réponse à bon nombre de ces questions se trouve sur le site du Ministère de la Culture (précision importante : j’ai trouvé cela via Google, pas depuis la fiche de métadonnées). On y apprend qu’un service du ministère publie annuellement un très intéressant document de 75 pages, appelé « MuséoStat« . J’ai ainsi pu comprendre que le terme « musée de France » correspond à une appellation officielle (accordée et retirée par les services du ministère), que les variations de fréquentation sont très souvent liées à des expositions temporaires (d’où l’importance des annotations colorées), que la notion de gratuité a elle aussi une définition officielle précise, …

Le document reproduit aussi le questionnaire envoyé aux différents responsables de musée, questionnaire très détaillé puisqu’il précise aussi le mode de mesure de la fréquentation (comptage manuel, automatisée, estimation, …). Enfin, on peut apercevoir en fin de questionnaire une case à cocher par les répondants : « acceptez-vous que ces chiffres soient diffusés ? ». Voilà donc l’origine de cette formule un peu ambigüe de « données confidentielles » !

Cette demande de contextualisation me semble tout aussi pertinente que la demande de brutification du jeu de données. On doit pouvoir y répondre en repensant profondément la manière de documenter les jeux de données – c’est à la fois le rôle des métadonnées mais aussi plus globalement la fonction éditoriale des portails open data.

3 – Sortir de l’opposition « qualité vs. quantité » des données

Le fichier de la fréquentation des musées ne représente bien sûr pas à lui seul la diversité et la richesse des jeux de données disponibles, sur data.gouv.fr ou ailleurs … Mais cet exemple illustre quand même je pense la situation actuelle : des données ni tout à fait brutes, ni tout à fait contextualisées.

La particularité du ni-ni est qu’il ne satisfait ni ceux qui attendent des services plus poussés (API, Linked Data pour les développeurs), ni ceux qui militent pour une meilleure appropriation des données par tous (façon Infolab) – bien qu’ils ne faillent pas opposer les uns et les autres.

Dans le débat qui va s’ouvrir sur les fonctions des portails open data, il y a à mon avis un écueil majeur à éviter : réduire cela à une opposition « qualité vs. quantité » des jeux de données.

La qualité ne peut s’évaluer qu’à l’aune de l’objectif : un développeur, un chercheur ou un associatif qui veut évaluer la fréquentation des musées de sa région ont tous besoin de fichiers de qualité.

C’est la manière dont ils expriment ce besoin qui diffère (notre tension brutification / contextualisation). Il nous faut donc à la fois de la qualité ET de la quantité…

4 – De qui est-ce le travail ?

Reste la question du rôle de chaque acteur impliqué : qui doit assurer ces tâches de brutification et de contextualisation ? Est-ce la mission du service détenteur de la donnée ou du service qui met en oeuvre le portail, en l’occurence Etalab ? Les réutilisateurs  enrichissent eux-aussi les jeux de données, par exemple en reliant deux fichiers via des identifiants, peut-on imaginer qu’un portail officiel puisse héberger, ou faire un lien vers le fruit de leur travail ?

On voit qu’à partir d’une question précise – quelles fonctions pour les portails open data ? – on en arrive à interroger le périmètre même des portails et des organisations qui les mettent en oeuvre…

8 réflexions au sujet de « Donnée brute ou donnée contextualisée ? »

  1. Pourquoi devrait-on faire un choix entre la donnée brute et la donnée contextualisée ? Ne serait-il pas plus simple, méthodologiquement, de reverser la matière brute en première intention puis de fournir (en même temps ou plus tard, éventuellement après un « datashaping » collaboratif) la matière contextualisée ?

  2. Article intéressant ! Je vais me permettre d’ajouter quelques remarques, qui vont certainement sonner comme celles d’un développeur, mais, heh, c’est que nous sommes les premiers à râler contre les documents inexploitables – et les plus prompts à les considérer comme tel, même avec toute la bonne volonté avec laquelle nous abordons parfois les choses (mais pas toujours, nous sommes trop passionnés).

    De mon point de vue, donc, les soucis sont dans le format des données d’un côté, et les meta-données de l’autre. Le format est ce qui se rapproche le plus de la brutification. La contextualisation, elle, des méta-données.

    Quand tu écris « et je parle bien là d’une donnée brute techniquement, pas en termes sociologiques », c’est bien du format dont tu veux parler, je pense. La « brutification », au sens de « rendre brut la donnée », pour moi, revient à retirer ce qui n’entre pas dans l’open-data : données personnelles, commentaires et outils relatifs à l’usage qui est fait des données, et autres formatages cosmétiques. En tout cas, la notion seule de « brutification » me semble soit trop vague, soit trop spécifique pour couvrir correctement cette notion très importante d’avoir un format réutilisable (car « propre » techniquement).

    Ce format réutilisable est un élément crucial pour un usage d’exploitation des données. Il doit suivre une norme (de préférence commune et partagée, mais c’est du détail), et surtout, respecter cette norme. Cette norme doit être documentée. Par exemple, le format GTFS est documenté, et permet la réutilisation des données.

    Sans ça, il est impossible d’effectuer des traitements automatiques. Les développeurs sont alors obligés de « normaliser » les documents, ce qui rajoute une étape dans le processus, une étape manuelle, puisque si des corrections peuvent parfois être automatisées, il faut bien, à un moment, passer une validation par l’oeil humain.

    C’est donc un service dont je suis demandeur, pour un portail Open-Data. Cependant, c’est un travail qui peut venir du portail lui-même, ou de ses fournisseurs de données. Voire, comme tu le suggères, que ce soit un travail d’une partie de la communauté – mais nous reviendrons très vite à cette question : jusqu’où la communauté doit-elle aller dans le _travail_ ?

    La seconde partie me semble absolument nécessaire et complémentaire, et non pas en contradiction : la contextualisation. C’est fournir des informations sur les données : c’est bien là le rôle des meta-données.

    Je vais généraliser : il y a deux ensembles de meta-données dont j’ai besoin aujourd’hui. Celles qui correspondent à une contextualisation simple des données : la légende, des descriptions textuelles, bref, de la *sémantique*. Elles permettent de comprendre les données et d’en faire une analyse pertinente (dont tu parles fort bien dans ton autre billet).

    Puis il y a celles qui permettent de décrire la *publication* même de ces données : quand, quelle version, par qui, de la part de qui, pour quelle durée/période de validité (des données de transports peuvent être « périmée »), licence, etc.

    En plus de ces meta-données de publication évidentes pour la plupart, il y en a d’autres qui touchent au coeur de l’automatisation de l’exploitation : les URLs, les droits d’accès, le format, la fragmentation en plusieurs fichiers, les identifiants uniques, etc.
    Et c’est sur ces méta-données là que je suis aujourd’hui le plus critique : il n’y en a pas, ou quasiment pas.

    Les urls des document changent, empêchant de faire un « ping » simple et rapide pour toujours obtenir la dernière version à jour. Il n’existe pas d’API des meta-données, pour savoir combien de documents, dans quelles catégories, à quelle date. Quand ils existent, les droits d’accès peuvent être prévus pour une authentification via un formulaire et une session, dans le navigateur, mais se révéler finalement gênante pour l’automatisation. La fragmentation entre plusieurs fichiers peut devenir un grave problème, s’il n’y a pas d’identifiant unique, ou de documentation permettant de faire les liens. Etc. etc.

    Alors, quand tu dis « La seconde demande qui émerge – et qui de prime abord peut sembler contradictoire avec la brutification – est liée à la contextualisation de la donnée », même si je peux concevoir que cela semble contradictoire, je répondrais que c’est pourtant tout à fait normal !

    Là encore, je pense que c’est aux portails de fournir des meta-données. Tu notes d’ailleurs un exemple intéressant : « (précision importante : j’ai trouvé cela via Google, pas depuis la fiche de métadonnées) ». Par un moteur de recherche, pour un document ça va, pour 50, 100, et pour les mises à jour, c’est un travail de fourmis !

    En conclusion je citerais ceci : « Cette demande de contextualisation me semble tout aussi pertinente que la demande de brutification du jeu de données. On doit pouvoir y répondre en repensant profondément la manière de documenter les jeux de données ».

    C’est exactement ça. Aujourd’hui, la quantité s’impose par elle-même, au risque de tomber dans de l’open-data gadget si seul un petit nombre de documents est disponible. La qualité, quant à elle, est une nécessité pour le développement des usages de ces données. C’est particulièrement visible avec le travail effectué avec COD-Rennes pour les données de la bibliothèque : sans cette qualité, rien ne peut se faire de façon pérenne. Et je comprends une entreprise qui ne voudra pas s’investir sur le sujet si rien n’est pérenne !

    Alors des pistes de réflexion et des propositions pour améliorer cette façon de documenter, il y en a. J’en ai plusieurs personnellement (et j’ai un post-it pour me dire d’écrire tout ça et de le publier), et je pense qu’il serait intéressant de s’inspirer – entre autre chose mais pas que évidement – des « forges » du monde du développement logiciel. Il y a des bonnes pratiques à reprendre, car tant la gestion des sources que la gestion des publications est un problème critique pour la diffusion des logiciels. Et ce sont des choses qui se retrouvent avec les données.

    • Et sans oublier que les données évoluent et que si elles ne sont pas un minimum ‘normalisées’ la livraison d’une nouvelle version d’un jeu de données peut rendre caduque une architecture technique basée dessus.

      L’API répond à cette problématique mais une API ne fournit pas une donnée brute, elle ne renvoie que ce qu’on a défini. Son usage est donc simplificateur mais limité.

      En XML, il est possible (voir fortement conseillé) de définir une DTD, celle-ci permettant de donner la structure du contenu et donc son architecture. Les fichiers XML peuvent aussi intégrer des méta-données comme tu le mentionnes. Peut-être qu’il faudrait proposer un gabarit de méta à intégrer automatiquement dans chaque fichier XML.

  3. Sans revenir sur ce qu’explique très bien, l’une des difficultés lors de discussions sur la donnée telle qu’elle a été mesurée/acquise et son format de publication est que, souvent, ces deux notions sont intimement liées mais par des raccourcis malencontreux la syntaxe prend souvent le pas sur la sémantique.

    Par exemple, tu pourras souvent entendre parler de RDF pour sérialiser des données. Or RDF offre une syntaxe, une structure et un langage mais sémantiquement, en lui même, n’a pas de grande valeur ajoutée. Il en aura uniquement lorsqu’il est le support d’une ontologie qu’il peut décrire. Malheureusement, par raccourci, l’on ne parlera que de RDF. Ce qui ne veut pas dire grand chose puisqu’aucun contexte n’est précisé.

    Il est ainsi intéressant de noter que dbpedia propose une ontologie plutôt simpliste qui reprend les différents éléments sémantiques de Wikipedia (http://wiki.dbpedia.org/Ontology). Cette approche naive a permis de simplifier la couverture de wikipedia par dbpedia. Les ontologies spécialisées sont souvent plus nettes et précises (cf http://musicontology.com/). Malheureusement, à force de spécialiser, une ontologie peut se révéler trop contraignante.

    Bref, même avec les bons outils de sérialization et ceux de sémantiques, décrire et porter une donnée n’est jamais simple et requiert une grande connaissance du contexte. Si l’opendata doit se diriger vers ce niveau de rigueur et de valeur ajoutée, il faudra se montrer patient car c’est un métier à part entière. C’est pourquoi beaucoup pousse pour que dans un premier temps la donnée soit publiée dans une forme « brute », qu’elle soit disponible même si, sans contextualization, elle en devient quasi inutilisable.

    • Merci pour vos commentaires, toujours très riches et plein d’idées !

      Sur l’analogie avec les « forges » de développeurs – qui me semble une piste très féconde -, j’ai repéré deux billets qui traitent de l’usage de GitHub pour publier et améliorer les data en mode collaboratif : http://t.co/15Pck7j11M et https://t.co/24SPkAHIcM

      Simon

  4. Ping : Faire de l’archiviste le maillon fort de l’open data | Papiers et poussières

Les commentaires sont fermés.