L’Open-Data, c’est avant tout des données. Dans un monde parfait, ces données seraient toujours à jour, vérifiées et croisées avec les autres jeux de données, seulement voilà : nous ne vivons pas dans un monde parfait !
En tant que développeur devant utiliser des jeux de données issus de l’Open-Data, comment s’en sortir avec des données probablement fausses, incomplètes ou non unifiées ? Pourquoi les données doivent être considérées comme «toujours fausses» ? pour quelles raisons le sont-elles presque toujours ?

Ce premier article de la série «We make data porn» va tenter de répondre à ces questions.

Pourquoi les données sont fausses ?

Je ne dis pas que les gestionnaires de jeux de données sont incompétents, mais qu’il relève du tour de force d’obtenir des données cohérentes avec les processus de publication couramment utilisés.

Les collectivités n’ouvrent pas des données en claquant des doigts. L’ouverture de données mobilise un certain nombre de personnes qui prennent le temps d’effectuer un certain nombre d’étapes préalables à la publication, parmi lesquelles :

  • Décider de quelles données ouvrir
  • Déterminer où se trouvent les données brutes (quels services, quelles modalités d’extraction…)
  • Extraire les données
  • Re-formater les données suivant leur type
  • Publier les données

Ces étapes sont les plus communes, certaines collectivités en sautent certaines ou en rajoutent d’autres, mais, généralement, c’est ce processus qui est suivi.

Le problème c’est que ce processus ne permet pas, en l’état, de produire des données de qualité. Voici ce qui manque :

  • Déterminer les jeux de données de base qui seront communs aux autres jeux de données. Par exemple: «point adresse», «limites administratives», «dénomination des voies», «liste des établissements publics»…
  • Définir un référentiel commun concernant les données : types de projection géographique utilisée pour les coordonnées, format des adresses et numéros de téléphone, jeu de caractères utilisé, identifiant unique pour chaque donnée permettant le croisement entre jeux de données.
  • Mettre en place les méthodologies internes afin de faciliter le recueil des données.
  • Développer ou faire développer des outils qui permettront de vérifier, croiser et formater les données de manière automatisées (ou semi-automatisées)

Au lieu de cela, à l’instar de la Ville de Paris, les collectivités se posent des questions en terme de «rapidité» d’ouverture, ou «d’objectifs chiffrés» ou, peut-être pire, de «pourquoi ouvrir telle ou telle donnée» comme lors de l’atelier 1 des rencontres régionales Open-Data PACA auquel j’ai participé le 10 juillet 2012.

En résumé :

Au lieu de se préoccuper de créer un référentiel et des méthodologies facilitant le croisement, le formatage et la vérification des données, ce qui permettrait de produire des données fiables et immédiatement exploitables, les gestionnaires en sont déjà à vouloir sortir des données en nombre et en volume conséquent, peu importe si elles sont inexploitables, incomplètes ou… fausses.

Que faudrait-il faire ?

Avant de chercher à sortir un plus gros projet Open-Data que le voisin, il convient de se poser les bonnes questions. Voici les premières à se poser :

  • Quelles données de base sont communes à toutes les autres que je possède ?
    Des adresses, des listes de lieux, des annuaires, des limites de «juridiction», des organigrammes…
    Ce sont ces données qu’il faut ouvrir en priorité, car toutes les autres ou presque les utilisent comme référence.
  • Est-ce que je possède réellement toutes les données de base ? si la réponse est non : Est-ce qu’une autre collectivité les a publié par ailleurs ou serait susceptible de les publier ?
    Il est rare qu’un Office du Tourisme possède, dans on référentiel de données, la listes des voies et limites administratives. Ces données sont pourtant utiles pour permettre une géolocalisation aisée des établissements d’hébergement par exemple. Ce sont des données qui sont par contre facilement ouvrables par les communes, agglomérations, départements ou régions.
  • Pourquoi ne pas ouvrir ces données ? (et non pas «Pourquoi les ouvrir ?»)
    Si, clairement, aucun problème juridique ou sécuritaire ne risque de surgir à cause de l’ouverture de ces données, surtout s’il est possible de les récupérer par ailleurs (car publiées sur des sites web ou plaquettes par exemple), il n’y a pas de raison de ne pas publier ces données dans un jeu de données ouvertes. Ne présumez jamais de l’(in)utilité d’un jeu de de données : ce sont les utilisateurs et les développeurs qui détermineront ça.
  • Ais-je besoin d’aide pour l’ouverture de ces données ? Est-ce que j’ai toutes les compétences nécessaires en interne ?
    Si oui : parfait ! allez-y ! Dans le cas contraire, il vous est possible de demander de l’aide à un autre collectivité qui a déjà effectué ce processus d’ouverture : elle vous orientera et vous dirigera vers des professionnels. N’hésitez pas non plus à consulter la communauté, il y a certainement une association de libristes près de vous qui sera à même de vous aider à commencer.

Que faire avec ces données «fausses» ?

Le gestionnaire des données que vous cherchez à utiliser n’a pas suivi ces recommandations, et vous vous retrouvez avec des jeux de données inutilisables ? pas de panique ! il reste encore un espoir. Si, au contraire, vous pensez que les données sont propres, il faudra quand même considérer ces données comme fausses car les traitements automatiques sont rarement fiables à 100%.

Convertir et re-formater.

Si aucun fichier directement exploitable (csv, xml) n’est disponible, téléchargez donc le format tableur et convertissez-le en CSV ou XML.

Dans tous les cas, essayez de parcourir les données afin de visualiser les champs et avoir une idée de ce qui s’y trouve. Identifiez les champs qui risquent de poser problème. Par exemple, si les adresses sont décomposées en numéro, type de voie, nom de la voie, complément d’adresse, code postal et ville, vérifiez que le nom de la voie ne commence pas par « rue »… ou que le code postal n’ait pas été stocké dans un champ numérique ce qui risquerait d’être problématique pour les 9 premiers départements car faisant disparaître le zéro du début, de même vérifiez les numéros de téléphone qui comporterons parfois des notes (tarif à la minute, ou heures d’appel préférées) ou qu’ils ne soient pas également stockés dans un champ numérique.

Il n’est pas rare de retrouver, au milieu d’un jeu de données, un caractère mal encodé. C’est souvent ce caractère qui vous fera perdre des heures de travail. Dans le doute, il est toujours utile de vérifier et éventuellement reconvertir les données, champ par champ, avant de les inclure dans une base de données. Utilisez mbstring en PHP ou iconv.

Identifiez la colonne qui stocke l’identifiant unique d’un point ou d’une adresse ou créez vous même cet identifiant s’il n’est pas présent.

Vérifiez qu’il n’y ait pas de «trou» : coordonnées géographiques ou adresse manquante.

Enfin, re-formatez les chaînes, numéros de téléphone et autres coordonnées géographiques afin d’avoir des données au format homogène avant de stocker vos données dans une base.

Croiser les données

Il n’est plus rare aujourd’hui d’avoir le «point adresse» dans un jeu de données. Cherchez bien, ce type de données peut porter plusieurs noms comme «Adresses postales» ou «Index des rues». Cela vous sera particulièrement utile si vous cherchez à faire du calcul d’itinéraire. En effet, si vous utilisez une liste de points d’intérêt issus de l’Open-Data, il est rare que la géolocalisation des points représente la géolocalisation de l’entrée et représente plus souvent plus ou moins le centre du bâtiment. Effectuer un calcul d’itinéraire en se basant sur ce point risque de vous amener à une entrée de service, ou à un mur… mieux vaut utiliser la géolocalisation de l’adresse. Comme vous aurez certainement re-formaté votre fichiers de points d’intérêt et de point adresse, vous pourrez plus facilement croiser ces données pour retrouver la géolocalisation de l’entrée. Attention toutefois : certaines adresses ne correspondront pas à cause d’erreurs de typographie ou de conventions d’écriture différentes. Exemple, la «rue du docteur Guy de Chauliac» pourra être écrite «rue Chauliac», «rue Gui de Chauliac» ou avec une erreur de type de voie «Avenue de Chauliac»…

Si vous souhaitez vous baser sur OpenStreetMap pour effectuer un calcul d’itinéraires, il sera toujours une bonne idée de croiser le point adresse avec OSM, en repositionnant chaque point adresse sur la voie à laquelle il se réfère. Il sera aussi opportun de vérifier la projection utilisée pour les coordonnées, ces dernières étant parfois différentes, et de stocker les coordonnées initiales du point d’intérêt ainsi que celles du point correspondant à son adresse en base de données. Pour cette activité, les outils comme PostGIS, osm2pgsql ou omosis vous seront d’une grande aide.

Enfin, il n’est pas rare de retrouver les mêmes points ou informations référencés dans plusieurs jeux de données différents, il conviendra d’éviter les doublons en vérifiant, avant inclusion, si l’identifiant unique de chaque point ou entrée n’a pas déjà été stocké, et le cas échéant, en complétant les données.

Dans tous les cas, c’est un travail minutieux qui ne peut être vraiment totalement automatisé : il faudra toujours vérifier le résultat de vos scripts en visualisant les données, dans un tableau ou sur une carte.

Proposer des corrections

Même si bien souvent rien ne vous y oblige, pensez à vous même et aux autres et proposez des corrections ou, du moins, signalez les erreurs que vous rencontrerez. La plus part des portails Open-Data disposent d’un formulaire de contact ou de signalement d’erreur, et les personnes qui pilotent ces projets sont souvent très ouvertes aux suggestions et critiques. Pensez aussi à fournir des fichiers exploitables ou à proposer vos outils.

Conclusion

Vous l’aurez compris, les données ne sont pas réellement toujours fausses, mais il faut les considérer comme telles car si certains portails Open-Data brillent par la propreté de leurs données, ce n’est pas le cas de tous. Cependant, il ne faut pas juger trop hâtivement les portails dont les données ne sont pas très propres : pour une collectivité, il est rare de disposer de spécialistes de la donnée en interne. Il est aussi rare que le processus d’ouverture soit totalement désintéressé : c’est souvent l’occasion pour une marie ou une région de briller par l’innovation, hélas parfois au détriment de la qualité… néanmoins, cela reste bénéfique car, même si elles sont globalement de mauvaise qualité, les données ont le mérite d’avoir été publiées et le processus d’ouverture entamé, et nul doute que ces mêmes données seront de plus en plus propres, croisées, et complètes.

5 commentaires :

  1. marilor

    Le

    Merci pour ce billet qui souligne l’importance d’adopter le point de vue des réutilisateurs – développeurs, notamment sur la rigueur, l’exactitude, la complétude des données, etc. Dans la même optique de réduction de l’effort d’appropriation des données ouvertes, les méta-données sont des infos précieuses pour guider les développeurs, apporter une documentation la plus claire et complète à chaque jeu de données. Hâte de lire tes prochains articles sur le sujet !

  2. François-Paul Servant

    Le

    Ce n’est que lorsqu’on se sert des données qu’on peut se rendre compte de leur mauvaise qualité – et qu’on a la motivation pour essayer de les améliorer. Il est donc naturel que des données qui ne servent pas soient fausses (et d’ailleurs, quelle importance ? :-) ) Or, des données qui ne sont pas publiées ne peuvent pas servir. Il faut donc publier les données pour que les utilisateurs potentiels puissent essayer de s’en servir, constater qu’elles laissent à désirer, et participer à leur amélioration (ne serait qu’en se plaignant auprès de qui les a publiées – ce qui est très positif, parce que le responsable des données en question est alors confronté à l’évidence de l’intérêt qu’on leur porte).

    Bref, je pense qu’il ne faut pas faire de la qualité un pré-requis pour la publication d’un jeu de données. C’est en les publiant qu’on met en place les conditions pour leur amélioration. Je l’ai constaté à plusieurs reprises en entreprise.

    Merci pour votre billet.

  3. Jean-François VIAL

    Le

    Désolé François Paul, mais je ne peux pas être d’accord avec vous… je ne serais jamais d’accord avec ceux qui sont partisans du «c’est pourrit, mais c’est mieux que rien, donc c’est OK !» (c’est ce vous nous dites, en substance).

    Vérifier les fichiers qu’on met en ligne, ça ne prends pas longtemps, et ça peut en faire gagner beaucoup au final, et pas qu’aux développeurs ! Si erreur il y a, il y a peut être moyen d’agir en amont pour corriger les sources d’erreurs, et donc gagner du temps lors des prochaines mises à jour par exemple… et nul besoin, pour corriger la grande majorité des erreurs, de se «servir» des données, il suffit d’un peu de bon sens et de logique. C’est vraiment à la portée de tous, je vous assure !

    Et puis vouloir faire du volume avec des données fausses, mal formatées ou incomplètes, donc inutilisables «parce que c’est mieux que rien» c’est pire que d’ouvrir des données tardivement… tout simplement parce que :

    • peu de développeurs vont prendre la peine de remonter des erreurs
    • le portail sera décrié (et à raison)
    • personne n’utilisera les données, donc pas d’applis, donc, aux yeux des décideurs, pas de ROI, donc une mise en péril du maintient du portail
    • ce n’est pas lorsqu’on a 200 jeux de données qu’il faut se poser la question de leur qualité
    • lorsqu’on a beaucoup jeux de données ouverts, il est en pratique presque impossible de les nettoyer

    Autant commencer par le début : se poser les bonnes questions pour démarrer dans de bonnes conditions et pérenniser le projet par une méthodologie simple et pragmatique.

  4. François-Paul Servant

    Le

    je ne dis pas qu’il ne faut pas se préoccuper de la qualité et de l’exploitabilité de ce qu’on publie. Si c’est complètement inexploitable, personne n’en tirera rien. Mais c’est dans et par l’utilisation qu’on peut juger de la qualité. Par ailleurs, personne ne tirera rien non plus de ce qui n’est pas publié. C’est en publiant – au mieux de ce dont on est capable à un moment donné – qu’on peut amorcer un processus qui conduit à l’amélioration de la qualité de ce qui est publié : parce qu’il se trouve alors des gens qui ont un intérêt dans l’exploitation des données en question – par exemple, une idée de business – et qui, pour satisfaire leur intérêt, pousseront à cette amélioration.

    Cordialement,

    fps

  5. Jean-François VIAL

    Le

    Vu le peu de ressources et de temps que demandent les quelques vérifications qui séparent une donnée inexploitable d’une donnée utilisable, autant effectuer ces vérifications dès le début. Je persiste à dire qu’il vaut mille fois mieux attendre un peu, et sortir des données correctes avec une vraie méthodologie, que de sortir n’importe quoi en vrac et d’attendre que les utilisateurs se plaignent pour agir.

    Pour une personne qui se plaint (et qui est en capacité d’attendre que le processus de correction se fasse, et il peut être très long si de bonnes pratiques ne sont pas mises en place dès le début) combien ne se plaignent pas ? Et il n’y a aucune corrélation entre la taille d’une entreprise (plus elle est «grosse» plus elle pourra attendre) et la qualité/pertinence des applications, je prendrais même peu de risque à dire que c’est inversement proportionnel… En publiant des données «sales», les responsables de la publication des données compromettent leur propre portail à moyen voire court terme.

    Évidemment que je préfère des données mal formatées que pas de données du tout mais, encore une fois, il est tellement simple de sortir des données propres du premier coup, qu’il me semble plutôt étrange et contre productif de se passer d’un minimum de nettoyage et de méthode.

Trackbacks/Pingbacks

  1.  We make data porn : Les données sont toujours fausses | partage&collaboratif | Scoop.it
  2.  sderrot | Pearltrees
  3.  OpenData | Pearltrees
  4.  We make data porn : Les données sont toujours fausses | L'Open Data fait son chemin | Scoop.it
  5.  We make data porn : Les données sont toujours fausses « Bylb0's Blog
  6.  We make data porn : Les données sont toujours fausses | e-administration | Scoop.it
  7.  We make data porn : Les données sont toujours fausses | Ouverture des données | Scoop.it
  8.  We make data porn : Les données sont toujours fausses | Musées & Open Data | Scoop.it
  9.  We make data porn : Les données sont toujours fausses | opendata-citoyens | Scoop.it

Écrire un commentaire

  • (ne sera pas publié ou utilisé pour vous envoyer du spam)
  • (liens en nofollow)