Demain samedi aura lieu à la cantine le premier Open Data Camp. On y parlera confidentialité des données, formats d'échanges, cas d'utilisation et peut être aussi... politique. Car depuis l'ouverture de data.gov aux US, données et transparence font bon ménage. L'arrivée de Tim Berners Lee dans le projet Anglais a été également un événement important dans l'ouverture des données gouvernementales. Et si on aurait pu craindre à un simple effet d'annonce, force est de constater que ces projets, leur écosystème et les communautés qu'ils fédèrent se développent. 6 mois après l'ouverture du premier data.gov, je vous propose un petit tour d'horizon des différents modèles en place.
Le modèle Néo-Zélandais
data.govt.nz contient à ce jour 200 datasets (sources de données). Il s'agit d'un annuaire faisant des liens vers des fichiers présents sur d'autres sites gouvernementaux. Pour chaque fiche l'on retrouve donc un lien, le format de données, une brève description, quelques mots clés et la date d'ajout. A noter que le site est actuellement en beta, il s'agit donc d'un prototype amené à évoluer. La version définitive est programmé pour l'été 2010 et d'ici là un effort sera effectué sur le formatage de ces données par les agences. On regrette le manque transparence sur la licence des données et l'obligation de rentrer en contact avec chaque agence.
Le modèle Australien
data.australia.gov.au met à disposition un catalogue de 210 datasets. Même si la majorité des données sont encore hébergées dans des agences distantes, il semble que certains fichiers ai été centralisés. Les fiches sont ici à la fois plus riches et plus clairs ce qui rend la navigation dans les datasets bien plus agréable. On notera que les données sont sous licence Creative Commons (CC-BY), licence clairement affichée sur chaque fiche. Là encore nous sommes en version beta.
Le modèle Américain
data.gov est le premier portail à avoir centralisé des données gouvernementales. Ouvert avec 47 datasets en mai dernier, le site en contient aujourd'hui 1081. Outre les fonctionnalités de base que l'on peut attendre, l'on retrouve pour chaque dataset plusieurs notes attribuées par les utilisateurs ainsi qu'un document technique qui décrit la nature des données (ce qui en augmente grandement l'accessibilité). Même si le terrain était déjà propice à l'exploitation de ces données (avec la présence de la Sunlight Foundation), on constate les efforts de communication et de community management. C'est ainsi que de nombreuses visualisations ont été crée par des associations, des universités ou des entreprises privées et que les données sont aujourd'hui en cours de standardisation.
Le modèle Anglais
data.gov.uk a fait beaucoup parlé de lui en annonçant l'arrivée de Tim Bernes Lee, inventeur du World Wide Web. Le site est actuellement en beta privée et ouvrira ses portes en Janvier avec plus de 1100 datasets (un effort a été réalisé sur la santé et les transports). Le site sera particulièrement communautaire en proposant de partager ses idées et ses applications, de les commenter et de les noter. Mais le plus marquant est la dimension technologique de ce projet. En ouvrant dors et déjà un endpoint SPARQL, point d'accès pour le LinkedData, la data.gov anglais donne la possibilité d'accéder aux données gouvernementales comme à une seule base de données ouverte. L'objectif est de rendre toutes les données accessibles dans ce format d'ici Juin 2011, le tout dans une licence proche du Creative Common.
Faut-il s'inspirer du modèle Américain ? Faut-il adopter l'approche technologique Anglaise ? Quels sont les acteurs à réunir autour de ce projet ? Quels sont les bénéfices à court, moyen, long termes ? Beaucoup de questions passionnantes qui seront surement posées et discutées demain à la cantine et qui je l'espère donneront de la matière au projet français.
Si vous voulez approfondir le sujet des données gouvernementales ReadWriteWeb tient à jour un pearltree de plus 50 sources couvrant les aspects politiques, stratégiques et techniques.
_
_
13 décembre 2009 à 18:03
Très bel événement!
Les ressources de l’Open Data Camp sont disponibles ici.
15 décembre 2009 à 12:22
J’ai 28 ans, je crée ma boîte et ça me donne un point de vue particulier sur la gestion des données par l’Etat.
Déjà, il n’y a pas UNE mais DES administrations qui n’utilisent pas les mêmes codes et ne communiquent pas entre elles.
Exemple 1: des nomenclatures hétérogènes et incomplètes
le code de mon activité est différent pour INPI et l’INSEE, ce qui empêche tout croisement de données, sans parler des lacunes de ces nomenclatures, particulièrement quand il s’agit du web: une seule case existe pour l’INSEE: Portail internet…
Vivement qu’on puisse ajouter des tags sur son activité.
Exemple 2: des bases de données en doublon.
pour modifier les statuts de ma SARL, je dois
- informer le greffe du tribunal de commerce (environ 200€)
- informer le Centre des Impôts (375€)
- publier une annonce légale (entre 75 et 250€)
Ces informations se font par dépôt d’imprimés, ensuite un simple champ sera corrigé dans chacune des bases de données respectives.
Bref, la mise à jour des données est couteuse et est réalisée en doublon avec les risques d’erreur de saisie toujours possibles.
Les 3 sources sont exploitées diffusent la même information…c’est absurde, coûteux et pas pertinent en matière de gestion des données.
Vivement qu’on inter-connecte tout ça. Quitte à être fiché autant ne pas l’être plusieurs fois.
Exemple3 : Des identifiants en pagaille
n° d’identification/SIREN
n° de gestion
n° de dépôt
SIRET
N° de bordereau d’enregistrement au CDI
Code NAF
référence INSEE
n° de déclaration CFE/URSAAF
n°de TVA intra-communautaire
Vivement un identifiant unique
La publication des données, c’est bien, mais leur exploitation ne sera pas facile.
Ca va, je n’étais pas trop hors-sujet?
15 décembre 2009 à 14:29
Salut Romain, complètement dans le sujet !
Le data.gov US n’a pas résolu les problèmes que tu mentionnes mais la question s’est posée aux groupes qui essayent actuellement de standardiser tout ça. Grâce au web sémantique ils ont ainsi crée des IDs qui utilisent l’argument « sameAs » afin de pouvoir effectuer des « disambiguation » et donc croiser ces élements. Les tags n’aident pas vraiment ;)
Ta problématique n°2 a elle aussi été rencontré outre atlantique. Ils ont identifié de nombreux doublons dans les datasets. Là encore ils ont du effectuer des ajustements manuels.
Pour ce qui est des identifiants en pagaille, tu ne crois pas si bien dire. Les datasets sont en général très peu documenté et il est difficile d’explorer leur contenu. Que signifie le code OQDC22 du dataset trans_data_48 ? :/ Là encore pas d’autre solution que l’aller demander directement aux agences et c’est long…
Du coup ta conclusion est tout à fait pertinente: « La publication des données, c’est bien, mais leur exploitation ne sera pas facile. »
Je rajouterai: « Mais c’est faisable » :)
15 décembre 2009 à 14:31
A noté que les Anglais sont au courant de ces problématiques et c’est une des raisons pour laquelle ils ont internalisé dès le début la structuration des datasets.