D’une donnée brute à une donnée enrichie

Posted on

Cet article va tenter de décrire mes étapes pour exploiter certaines données géographiques mises à disposition par Keolis Rennes et le Service d’Information Géographique (SIG) de Rennes métropole.

Le pitch

Mon besoin était de m’appuyer sur l’empreinte du réseau de transports de bus dans la métropole pour déterminer le tracé précis entre deux arrêts de bus consécutifs sur une ligne donnée, et d’en calculer la longeur.

Un peu de naïveté ne fait pas de mal

Ma première idée fut de me tourner vers le portail de Keolis. En effet, il me semblait naturel d’y trouver les données des itinéraires même si je ne m’attendais pas à ce qu’elles soient publiées via leur API. Sur ce point, j’avais raison, l’API ne s’intéresse qu’aux données de l’état du réseau.

Keolis propose aussi quelques jeux de données statiques téléchargeables directement. Malheureusement, hormis les données graphiques des pictogrammes des lignes, Keolis ne publie que le GTFS qui représente les informations de transits, mais pas les données géographiques.

La première étape fit donc choux blanc.

Bon sang, mais c’est bien sûr !

Puisque Keolis ne fournissait pas les données dont j’avais besoin, je me suis tourné vers le grand service libre de données géographiques : OpenStreetMap. En effet, OSM est très actif et il me semblait probable d’y trouver ce que je cherchais.

J’atterris donc rapidement sur le wiki d’OSM listant les jeux couvrants le réseau de transport en commun sur la métropole. Mais là trois obstacles se dressèrent devant moi :

  • L’ensemble du réseau n’est pas couvert
  • Certains itinéraires sont incomplets
  • Les données sont moins directement exploitables que je n’aurais espérer

En revanche, un des grands intérêts d’OSM est qu’il est mis à jour régulièrement, même lorsque des travaux prennent place durablement, modifiant le tracé d’une ligne de bus.

Le problème des itinéraires incomplets pourrait se résoudre simplement en éditant OSM. Malheureusement, même si cette tâche est désormais facilitée depuis un simple navigateur grâce aux outils d’OSM, ils ne peuvent pas résoudre des cas plus compliqués tels que celui illustré ci-dessous :

osm_ligne67

Voir directement la source

 

Si vous le notez bien, la ligne 67 quitte la voie centrale pour rejoindre l’avenue Maginot, avant de tourner au nord par le pont de Strasbourg. Or, le tracé est interrompu le long de cette avenue, la ligne 67 ne la parcourant qu’en partie. Les outils de bases d’OSM ne permettent pas de choisir un segment me semble-t-il. Techniquement, c’est dû au fait que l’entité qui représente l’avenue Maginot est considérée comme une ligne continue. D’ailleurs, on remarque aussi que la ligne 67 semble venir d’abord de l’avenue Maginot, mais ce n’est pas le cas. En fait, la sorte de V à l’envers est aussi un segment d’un seul tenant et l’éditeur qui l’a sélectionné n’a pas pu faire autrement que de le prendre entièrement, même sa section ouest qui n’est pas utilisé en réalité par la ligne 67.

Mes compétences en édition OSM sont trop limitées pour savoir si il est possible de créer le lien manquant. J’ai tenté ma chance avec l’éditeur avancé JOSM mais sans succès.

D’autre part, le format d’export des données est bien particulier. Il définit essentiellement un graphe de noeuds et de relations entre ces noeuds. Je dois admettre n’avoir pas poussé mes recherches pour en tirer les informations sous une forme qui me semblait utilisable pour mes besoins.

Le SIG à la rescousse

Le SIG de Rennes métropole est un service prolifique puisqu’il publie à lui seul près de 30% des données ouvertes proposées sur le portail. Au sein de cette forêt de jeux de données, j’ai pu trouver celui qui me semblait être précisément ce dont j’avais besoin : “Données géographiques du réseau STAR“.

Ce lot données contient les couches géographiques (géodonnées) décrivant le réseau de transport en commun de Rennes Métropole.

Le lot de données contient :
– les itinéraires des lignes principales
– les arrêts physiques
– les arrêts logiques
– la correspondance entre les arrêts physiques et les itinéraires de ligne (fichier CSV)

Les arrêts physiques sont des points à la localisation des arrêts de bus sur les trottoirs. Les arrêts logiques sont des points sur les lignes et représentants les arrêts physiques de la ligne dans les deux sens. Une image vaut mieux qu’un long discours :

Vert: lignes, orange : arrêts logiques, bleus : arrêts physiques

Vert: lignes, orange : arrêts logiques, bleus : arrêts physiques

Les arrêts logiques sont décrits comme étant positionnés sur la ligne. Il me semblait donc évident que la combinaison “lignes + arrêts logiques” allaient enfin répondre à mes besoins. En effet, mon objectif initial était de pouvoir couper les lignes en segments dont les extrémités seraient deux arrêts logiques sur cette ligne.

Sauf que tout n’est jamais si simple…

Ma première action fût de choisir les données au format shapefile. Ce format contient les données géographiques et peut aisément se charger dans la base de données spatiales PostGIS via les outils fournis :

Cette commande a crée une table “star_arret_physique” dans ma base de données spatiales “rennes_sig”. Voici la définition de cette table :

Pour les données d’itinéraires :

Qui produit la description suivante :

Il suffit d’exécuter la même commande sur les données de lignes et on se retrouve alors avec une base de données prêtes à être exploitée. Enfin presque. Si vous regardez bien la déclaration des deux tables, il n’existe pas de clés communes entre elles. La table des arrêts logiques n’offre aucune relation directe avec les itinéraires. Il faut en fait utiliser une table pivot constituée depuis un simple fichier CSV : star_ap_iti. Ce fichier CSV relie les arrêts physiques aux itinéraires.

L’import se passe différement. D’abord créez une table pour recevoir les données :

Puis copiez les données depuis un shell psql :

Maintenant que les données sont dans la base, nous pouvons effectuer les requêtes pour lier les arrêts logiques aux lignes.

L’idée est simple, nous parcourons la table des arrêts physiques pour obtenir les arrêts logiques associés. Puis nous procédons à une jointure avec la table créée précédemment en utilisant le code de l’arrêt physique comme pivot. Finalement, nous ordonnançons les résultats par itinéraire et position de l’arrêt sur cet itinéraire. Ci-dessous un petit extrait des données que nous obtenons :

A ce moment là, je dois avouer, je voulais crier victoire. En effet, il me semblait que j’avais enfin le lien entre les arrêts, les itinéraires la géolocalisation des arrêts et, cerise sur le gâteau, l’ordonnancement des arrêts.

Sauf que tout n’est jamais si simple (bis)…

J’ai en effet rapidement été confronté à un problème. Prenons un exemple simple, la ligne C4 et l’arrêt (logique) Pont de Strasbourg :

line4_zoom1

A une échelle assez grande, on se dit que l’arrêt est effectivement sur la ligne. Mais en zoomant, on se rend compte que non :

line4_zoom16

Cela pose une difficulté, puisque pour calculer la distance entre deux arrêts le long d’une ligne, les outils proposés par PostGIS nécessitent que les points soient contenus par la ligne. Du coup, il est impossible d’appliquer une requête simple.

La solution est de projetter le point représentant l’arrêt sur l’itinéraire via la fonction ST_ClosestPoint, et en reprenant la requête ci-dessus :

La table résultante est l’ensemble des points projetés sur les lignes du réseau.

Une fois cette étape atteinte, il suffit de dérouler l’algorithme pour découper chaque ligne par couple de points et mesurer la longueur du segment. Cela parait simple mais, une fois traduit en SQL, c’est beaucoup moins amusant à lire :

J’avais prévenu, c’est assez hideux mais ça fait le job. Enfin presque…

Sauf que tout n’est jamais si simple (ter)…

Lorsque l’on exécute cette requête, on obtient l’erreur suivante :

En effet, les lignes fournies dans le shapefile par le SIG de Rennes métropole sont en fait des multi-lignes. La plupart peuvent être combinées en lignes continues, mais pas toutes. Or, PostGIS ne sait traiter, dans certaines de ces fonctions, que des lignes continues.

J’aurais pu essayer de charger les données initialement ainsi :

Notez le -S dans la ligne de commande. Mais on obtient alors une erreur confirmant que certaines lignes ne peuvent pas être considérées comme continues :

Un exemple de représentation sur l’itinéraire 6 :

multilines

 

La seule solution que j’ai trouvé est de filtrer les itinéraires que je ne peux pas  combiner en des lignes continues afin de ne pas les traiter du tout. Pour ce faire, il faut modifier la requête géante comme suit :

Notez la présence des appels à la fonction ST_LineMerge qui combine une géométrie à plusieurs lignes en une seule. Malheureusement, cette fonction ne peut pas faire de miracle sur des cas comme celui de la ligne 6.

Et voilà ! J’avais enfin une table décrivant les segments des itinéraires entre chaque arrêts les parcourant. Pfiou !

Conclusion

L’objectif de cet article est de montrer qu’une donnée brute est parfois difficile à utiliser, principalement dans le cadre d’une automatisation de son traitement. Mais l’intérêt réside aussi pour moi dans la réflexion que cela provoque. C’est comme un casse-tête géant.

Malgré cela, je dois admettre que je ne m’attendais pas à autant de complication pour un besoin qui me paraissait plutôt simple. Je ne critique pas la donnée disponible, en revanche il me semble important de voir à quel point ces écueils peuvent ralentir, voir même bloquer l’innovation qui est souvent espérée des données publiques.

Je ne suis pas certain que les agents publics doivent porter la responsabilité de fournir une donnée enrichie comme il en résulterait de mon travail ci-dessus. A mon sens, cela les ferait sortir du cadre de l’opendata. En revanche, cela laisse une porte grande ouverte à celles et ceux qui souhaiteraient se positionner sur l’aggrégation et l’enrichissement des données brutes (comme le font l’IGN ou DataPublica d’une certaine façon).

 

Remerciements

Le SIG de Rennes métropole évidemment qui a toujours été à l’écoute de mes plaintes.


Bonnes pratiques du code dans le cycle de vie des données

Posted on

Devrions-nous considérer les données comme du code informatique ? Devrions-nous leur appliquer une gestion similaire ? Je me suis posé ces questions récemment souhaitant appliquer les mêmes bonnes pratiques à des données qu’à mon code, à savoir :

  • Historisation des modifications, et son corrolaire, réversibilité des changements
  • Annotation des modifications
  • Concurrence d’accès et de modifications
  • Identification d’une suite de changements

La phrase bien connue “Data is code” (les données sont du code informatique) offre un raccourci assez grossier mais intéressant à ce sujet. Si l’on peut considérer la donnée comme du code, pourquoi ne pas lui appliquer les mêmes pratiques ?

Journal des modifications, aka changelog

Une donnée est un fait, c’est la racine même du mot, si un changement s’opère sur celle-ci et qu’un nouveau fait en résulte, il peut sembler pertinent de tracer alors les raisons et les mécanismes de cette évolution.

Prenons un exemple. Je travail avec les informations du SIG de Rennes metropole concernant les données géographiques du réseau de transport en commun de Keolis sur la métropole. Les données fournies représentent un fait, celui de l’empreinte du réseau à l’instant de la création du jeu. Il est évident que l’information décrite par ces données évolue, amenant le SIG à publier des mises à jours.

Or, la publication ne s’accompagne pas d’explication sur ce qui a changé, ni pour quelles raisons. Je crois que c’est dommageable dans le sens où l’utilisateur doit alors faire la comparaison entre deux versions pour tenter de déterminer, a minima, l’étendu des modifications.

Notons ici que je ne pointe pas du doigt le SIG qui propose des données structurées et très faciles de réutilisation. Ce constant s’applique à tous les jeux de données que j’ai pu voir sur Rennes ou ailleurs.

Pourquoi est-ce un problème ? Mon utilisation des données du SIG est essentiellement programmatique. Après un téléchargement d’un jeu de données, je le stocke dans une base de données relationnelle pour les manipuler via le langage programmatique SQL. Si une donnée change, elle peut avoir un effet important sur le résultat de mes requêtes. Parfois un changement est attendu (une correction apportée par le SIG), parfois il peut casser mon applicatif et ne peut donc pas être utiliser sans travail supplémentaire. Si le SIG exprimait avec précision les modifications apportées dans une mise à jour, il me serait aisé de savoir si oui ou non je dois la récupérer et ce à quoi je dois porter attention. Il s’agit d’un gain de temps non négligeable mais aussi une sécurité dans mon process de développement.

Revenons à la notion de “Data is code“. En tant que développeur, la bonne pratique est de fournir ce que l’on nomme un changelog qui se traduit littéralement par “journal des modifications“. Dans la pratique, il s’agit généralement d’un fichier texte ou d’une page HTML avec une structure simple :

Voir, par exemple, celui-du logiciel Jenkins.

Ce format à la double propriété d’historiser les changements et d’offrir une vue rapide et efficace des modifications apportées lors d’une publication.

Un changelog peut aussi être accompagné de notes de livraison plus poussées qui offrent le raisonnement derrière les changements ainsi que le cheminement à suivre pour mettre à jour. Un bel exemple de telles notes peut se trouver dans le projet Django. Même sans connaitre le projet, on peut apprécier la richesse du document produit.

Un peu pour l’humain, un peu pour la machine

Bien qu’un changelog soit utile, il n’est pas suffisant pour une automatisation du cycle de vie des modifications. Dit autrement, le changelog vise l’humain mais pas la machine. De part son format peu structuré et basé sur le langage naturel, il n’est pas propice à une automatisation. Il manque une pièce au puzzle.

C’est là où entre en jeu les systèmes de gestion de versions. Sans entrer dans les détails, ces systèmes permettent de répondre aux exigences de développement logicielles mentionnées plus haut. Subversion, git et mecurial sont les plus connues dans le logiciel libre. Grâce à ces outils, un développeur peut ainsi effectuer des modifications locales puis les enregistrer et, potentiellement, les mettre à disposition. En interne, le logiciel conserve des meta-informations telles que la date de l’enregistrement, le nom du développeur, la raison de l’enregistrement, etc. Mais surtout, il n’enregistre que la variation entre la version précédente et la nouvelle. Un enregistrement s’appelle généralement une révision ou un changeset (lot de modifications).

L’intérêt ici, hormis la bonne pratique logicielle, est de pouvoir automatiser certaines tâches, en tant que réutilisateur, en s’appuyant sur ces outils pour reconstruire n’importe quelle état depuis une version donnée. Simplement en appliquant chaque lots de modifications les uns après les autres.

Cela peut se révéler très utile dans le cadre de la consommation de données. En effet, prenons un simple fichier au format CSV par exemple. Il serait très facile de voir les différences d’une version à l’autre simplement en parcourant le journal des modifications proposés par l’outil. Mais aussi de simplifier les tâches de mise à jour puisqu’on pourrait utiliser l’outil pour récupérer uniquement les différences depuis la dernière publication.

Prenons ainsi le fichier représentant la France au format GeoJSON et disponible sur la plateforme github. On peut inspecter l’historique de cette ressource ainsi qu’un changement en particulier.

Un autre effet intéressant des outils de gestion de versions est qu’il très facile pour un réutilisateur de faire sa propre modification et de la proposer au producteur qui peut ainsi la rejetter ou l’intégrer de manière naturelle et formalisée. Grâce à aux plateformes telles que github, il est aussi aisé d’annoter un changement pour le discuter.

Comment y parvenir ?

Les apports des changelogs et de la gestion de version sont indéniables dans le monde du logiciel, libre notamment. Si on part du principe que la donnée numérique possède des propriétés proches du code informatique, on peut s’attendre à utiliser les mêmes outils et bonnes pratiques. Mais cela requiert une évolution du travail des agents publics ainsi que de la plateforme hébergeant leurs données.

Malheureusement, le second aspect requiert de la formation,une feuille de route et du budget. En ces temps de crise économique, l’Open Data est-il une prioriété de la collectivité ou de l’état ? Rien n’est moin sûr.

En revanche, la création d’un changelog simple et mis à disposition sur les portails ne demandent pas beaucoup d’effort, puisqu’il s’agit pour les agents de lister au fur et à mesure les modifications qu’ils apportent ainsi que les raisons de ces changements dans un fichier texte.

Espérons donc que les mentalités et méthodes de travail évoluent chez les producteurs de données. Il me semble que cela est nécessaire pour rendre l’usage de leurs données plus naturelles et efficaces par les réutilisateurs. Cela enrichirait aussi le dialogue entre réutilisateurs d’une donnée.


Keolis Rennes démarre une labellisation d’applications utilisants ses données ouvertes

Posted on

En 2010, Kéolis Rennes, l’opérateur de transport public de Rennes métropole publiait ses premières données de transports sous licences open data. En 2012, des données temps réels étaient mises à disposition sous les mêmes conditions. Ce printemps, Kéolis Rennes récidive en proposant une démarche inédite de labellisation d’applications basées sur l’ensemble de leurs données.

Cette labellisation a pour objectif d’offrir de la visibilité à certaines applications et, par conséquent, une crédibilité institutionnelle. Pour Kéolis Rennes, l’idée est de conserver un lien étroit avec les éditeurs d’applications afin d’assurer un certain niveau de qualité au bénéfice des usagers.

Même si il semble que les critères soient à affiner, il s’agit d’une belle initiative que nous saluons.


Nouveau départ pour l’Open Data à Rennes Métropole ?

Posted on

Cela n’aura échappé à personne : nous sortons des élections municipales avec des changements de maires pour certaines municipalités de Rennes métropole. Concernant Rennes même, l’équipe semble être dans la continuité de la précédente, et il nous faut désormais attendre le changement de pilotage de la métropole courant avril.

De tous ces mouvements, qu’est-ce que l’open-data peut attendre ?

Un peu d’histoire…

Même si les avis divergent sur le vrai point de départ de l’open-data à Rennes, il semblerait que tout se soit passé début 2010. Si l’on regarde du côté des anglo-saxons, nous n’étions alors pas en retard, plutôt le contraire. Comme quoi, Rennes peut effectivement sentir un mouvement innovant et y investir sans tergiverser : bravo à l’équipe qui a porté le projet à l’époque !

Au printemps 2010, Rennes sortait son portail de données ouvertes et, dans le même temps, Keolis (la société ayant la délégation de service concernant les transports en commun de Rennes métropole) sortait aussi son portail. À l’automne de la même année, la métropole lançait son concours d’applications et organisait une conférence internationale autour du sujet des données publiques.

Bref, en l’espace d’une année, Rennes métropole installait l’open-data dans le paysage de la démocratie locale, tout en se positionnant sur le terrain de l’innovation numérique et sociale et, par la même occasion, lançait l’open-data en France.

Le concours passé, une deuxième phase s’installa : celle de la discussion entre Rennes métropole et les développeurs d’applications. Cette étape fut riche en rencontres et discussions. Néanmoins, force est de constater que la production, en termes d’applications concrètes et pertinentes pour les usagers, n’a pas été au rendez-vous.

Finalement, c’est en 2012 (un an plus tard) que le collectif Open-Data Rennes a été créé sous l’impulsion de Léa avec pour objectif de fédérer la communauté de réutilisateurs de données et de tenter d’animer le territoire autour de l’open-data.

Où en sommes-nous ?

Quatre ans plus tard, où en sommes-nous sur le sujet de l’open-data à Rennes métropole ? Objectivement, pas beaucoup plus loin qu’en fin 2011. Le mouvement rennais s’est graduellement calmé pour finalement pratiquement s’arrêter. Question légitime : pourquoi ?

S’il serait malheureux de pointer telle ou telle direction pour redémarrer, tentons d’abord de brosser un portrait lucide du mouvement.

Une politique publique nationale longue à décanter

Etalab, la mission gouvernementale chargée de l’ouverture des données publiques à l’échelon national, a vu le jour en 2011, un délai raisonnable. Mais, dans un premier temps, il s’agissait surtout de poser cette première pierre fondatrice de l’open-data à un niveau étatique. Le vrai travail de fond d’Etalab a pris encore deux ans, avec la nouvelle mouture du portail, plus riche et plus fonctionnel ; ainsi qu’avec le traitement de sujets plus complexes et sensibles, comme ceux de la santé.

Pendant le même temps, un ensemble d’acteurs territoriaux se sont associés afin de mutualiser les discours et coordonner les efforts. Ils ont officialisé leur statuts en 2013 au sein de l’association Open Data France. A priori, cet effort n’est pas là pour créer un rapport de force avec la mission Etalab, mais plutôt pour la compléter par un retour local mieux organisé.

Ces structures sont fondatrices et structurantes mais, dans la temporalité de l’Internet et du numérique, elles ont été longues à décanter, et leur apport concret n’est pas toujours évident à mesurer.

Surprise (ou non ?), ces structures reproduisent le schéma administratif classique : un échelon national, des échelons locaux, et une certaine opacité. On assiste encore à une approche centralisée, où l’administration ne s’appuie pas sur les citoyens mais continue de rester dans son entre-soi.

Pour l’exemple, il suffit de regarder la liste des membres d’Open Data France : seuls LiberTIC et la Fing représentent la société civile, mais sans droit d’éligibilité au CA.

Soyons positifs malgré tout : la coordination de la mission Etalab avec les collectivités territoriales est essentielle à la construction d’une politique d’ouverture des données publiques réussie ; et la démarche de concertation faite sur le terrain avec les acteurs de l’open-data français, à l’occasion de la refonte du portail data.gouv.fr a été très appréciée – le résultat n’est d’ailleurs pas décevant !

Une politique locale brouillonne et sans moyens

Rennes métropole soutient l’open-data depuis début 2010, et ne l’a jamais retiré de ses programmes. Malgré cela, il est difficile d’y voir clair dans la politique publique mise en œuvre. Alors que la métropole organisait des rencontres autour de différents sujets de l’open-data durant les deux premières années, les choses semblent stagner depuis : quelques sorties de données intéressantes (temps réel des transports en commun, agenda des événements culturels, etc.), mais il ne semble toujours pas exister de ligne précise quant au développement des données ouvertes, ou quant à un calendrier public sur lequel travailler.

Bref, quel est le canevas d’ouverture des données publiques de la métropole ? Nul ne semble vraiment le savoir, ou du moins, ce n’est pas une donnée publique. Autre question : quels sont les moyens mis en œuvre ?

À Rennes métropole, aucun poste n’a été semble-t-il créé pour s’occuper du rôle de data scientist (un urbaniste de la donnée pourrait-on dire). Ironiquement, le budget alloué à l’open-data n’apparaît pas dans les données budgétaires (ouvertes) de la métropole. Faute de moyens, les données culturelles sont liées à un partenariat avec Infolocale, où l’ouverture reste toujours la grande absente pour les réutilisateurs (et est-ce vraiment de l’open-data ?).

Alors que faire ?

Nous pouvons espérer que la nouvelle équipe saura comprendre l’importance de l’ouverture des données publiques et mettra les moyens derrière le discours. Aujourd’hui, le dossier open-data dépend de la communication et de l’événementiel (tout un symbole), plutôt que du développement territorial ou de la coordination générale des services – ce qui serait sans doute plus sa place. Les récentes élections seront peut-être l’occasion de changer cela ?

Une attente trop forte ?

Il existe plusieurs stimuli derrière l’ouverture des données publiques :

  • Démocratique : Ouvrir la porte sur l’information publique à la citoyenneté. Un objectif de transparence défendu, par exemple, par l’association Regards Citoyens et plusieurs partis politiques dans plusieurs villes aux dernières élections.
  • Économique : La donnée brute peut-être transformée et corrélée pour devenir information avec une valeur économique intéressante.
  • Juridico-légal : Moyen de contrôle de décision publique (une ZAC respecte-t-elle par exemple certains critères d’urbanisme ?)

Les attentes furent fortes et comme souvent, sur ce qui touche au numérique, la loupe que l’Internet pose sur un sujet peut parfois déformer la réalité. En l’occurrence, le discours de révolution opéré par l’ouverture des données était, au mieux optimiste, au pire totalement hors de proportion. La révolution n’est pas dans l’open-data. Il semblerait que le réveil ait été rude. L’open-data porte en lui tout ce qu’il faut pour devenir essentiel à l’économie ainsi que comme agent d’une démocratie moins crainte, mais le retour sur investissement ne sera peut-être pas aussi simple à détourer.

Par ailleurs, l’open-data ne reste qu’un moyen de communication : partout en France, les données ouvertes sont choisies avec soin. La création d’une politique volontariste visant à normaliser les jeux de données ou à travailler à plusieurs pour proposer des contenus de qualité égale entre producteurs n’est que très récente, en plus d’être rare. Cela serait pourtant le bon moyen pour tirer l’open-data administratif de son marasme actuel : “S’il n’y a pas de réutilisation, pourquoi ouvrir des données ?” entend-t-on dans les couloirs. Tout simplement parce que les données ne sont pas d’une qualité suffisante, unifiées ou d’un intérêt invitant à les exploiter ? L’initiative en cours autour des données culturelles de Rennes Métropole est très intéressante à suivre, car menée avec une politique volontariste, destinée à unifier les données ; et il faut encourager ces approches, qui apportent un changement positif aussi pour les agents du service public.

Une communauté segmentée

L’open-data, comme bien des mouvements liés au libre, est fortement porté par des acteurs de la société civile. Il ne s’agit pas toujours de militantisme, mais plutôt d’actes politiques, au sens originel “d’agir dans la vie de la société”.

Mais, peut-on parler d’une communauté ? Probablement pas. C’est une force mais aussi une limitation. Un atout car il n’existe pas de guerres intestines, pas de volonté de contrôle par une personne, avec un agenda personnel. Les mouvements citoyens sur le sujet sont donc plutôt constructeurs et de bonne volonté. Mais de part leur segmentation, ils n’ont finalement qu’une capacité limitée pour activer les bon leviers.

C’est tout le paradoxe de l’open-data, mouvement qui prône la transparence et l’ouverture démocratique, mais qui se réalise de manière très classique par des acteurs territoriaux et nationaux retombant rapidement dans le “nous possédons l’information, nous vous la distribuerons à notre bon vouloir”. Finalement, la société civile en revient donc souvent à des rapports de forces plutôt qu’à une collégialité sur le fond. Par ailleurs, l’absence de coordination nationale pour les collectifs et associations manque encore aujourd’hui.

La donnée est technique, le citoyen ne l’est pas

Une erreur frappante quand il s’agit d’open-data est à quel point le discours reste technique. Après une longue période autour des licences, le sujet a pu enfin se porter sur la donnée elle-même. Malheureusement, il semblerait que nous ne réussissions pas sur Rennes à dépasser ce cadre.

Pourtant, dans le même temps, il existe une volonté et une attente d’appropriation par le citoyen des données publiques. Or la donnée est un sujet hautement technique, dont le citoyen ne peut pas faire grand chose, sauf à être expert ou amateur éclairé sur le domaine – cela se ressent aussi au sein de l’association. La réconciliation entre la valeur finale portée par une donnée et l’usager est encore à proposer.

Ne serait-il pas pertinent que Rennes discute désormais d’usages qui pourraient, peut-être, trouver une réponse partielle dans la donnée publique ? L’usage déterminerait alors les données à ouvrir, inversant le processus actuel.

À qui parler ? Comment communiquer ? La démocratie participative à l’épreuve…

L’open-data stimule l’échange entre les acteurs publics et la société civile. Il semble néanmoins que les premiers n’aient pas encore ni les outils ni la culture adéquate – du moins pas de manière institutionnalisée.

Par exemple sur Rennes, nous nous retrouvons avec un forum pratiquement délaissé, et aucun canal officiel pour proposer l’accès à un jeu de donnée. Le dialogue existe mais sur un fil ténu. Il repose sur la bonne volonté de personnes au sein de l’organisme public (qui sont plusieurs à Rennes heureusement). Mais là encore, puisque la métropole n’a aucune politique ni aucun budget alloués sur le sujet, tout ceci est fragile.

Un collectif dispersé

Notre association est constituée d’une poignée de membres seulement, et l’activité général est très fluctuante. Nous avons eu une saison 2012/2013 riche, mais depuis la rentrée 2013 le collectif n’a pas réussi ni à lancer ni à porter beaucoup de sujets. Nous ne souhaitons pas forcément mener un projet complet, ni nous positionner comme fournisseur de services : nous avons fait le choix de nous positionner sur l’animation, la médiation et le dialogue. Parfois, nous créons un prototype, mais il ne sert qu’à porter une discussion avec différents acteurs. Nous ne souhaitons pas nous substituer ni pallier à l’absence de ce qui doit être une volonté politique des acteurs publics : nous n’en avons ni les moyens, ni la légitimité.

Ainsi, nous n’avons pas un projet clairement défini, et les efforts de chacun sont dilués dans le temps. Ajoutez à cela un manque de temps et une sensation de ne pas savoir comment interagir efficacement avec la métropole, et cela résulte dans une motivation en berne.

Un second souffle pour l’open-data rennais

Le tableau dressé n’est guère enthousiasmant et nous ne souhaitons pas tirer sur l’ambulance. L’open-data est un mouvement de fond qui a enfin laissé derrière lui les cheerleaders de tout ce qui est nouveau. Nous sommes entrés dans une phase qui va être longue, mais beaucoup plus constructive et productive sur le long terme.

Il est plus que temps que les acteurs de l’open-data se retrouvent, et proposent une stratégie et une gouvernance au niveau local de la donnée publique. Il existe plusieurs axes que le collectif estime envisageables :

  • Débloquer un budget et identifier un vrai rôle autour de ce sujet
  • Proposer une politique structurée au niveau métropolitain, avec les moyens d’une mise en œuvre
  • Améliorer le canal de communication entre services, mais aussi vers la société civile
  • Ouvrir la collaboration avec les autres collectivités (Nantes, Brest, Lorient…) ainsi que la région
  • Proposer un portail plus participatif comme le fait Etalab. Intégrer la communauté dans l’élaboration du cahier des charges de ce nouveau portail
  • Envisager le soutien d’efforts de crowd-sourcing
  • Engager les communautés numériques pour apporter le regard d’usages innovants

Le collectif espère une confirmation de l’engagement de Rennes métropole pour une politique de l’open-data, concrète et pérenne, et un renouveau de son activité locale et collaborative.


Bilan 2013 du Collectif OpenData Rennes et prémices 2014

Posted on

Le collectif open data rennais a connu une année bien contrastée en 2013. Plutôt riche jusqu’à début juillet puis une rentrée plus calme. Rappelons que le collectif s’est donné comme activité de jouer la carte du lien entre des acteurs publics du territoire rennais et des citoyens afin de les aider à mieux cerner les enjeux de l’ouverture des données publiques. L’idée est de proposer des moments de rencontres, de réflexions, de démonstrations autour des données, des usages et des questions qui les entourent. A ce titre, voici les grands moments de l’année 2013 pour le collectif.

Des rencontres…

Le collectif a organisé 7 rencontres sur l’année.

  • 3 rencontres informelles. Tenues souvent sur l’horaire de midi à la cantine numérique et sans un thème précis. Juste le plaisir de se retrouver et de dialoguer autour des sujets de l’open data.
  • une rencontre découverte du logiciel de la bibliothèque de Rennes Métropole aux champs libres. Nous remercions à ce titre les bibliothécaires de nous avoir acceuillis.
  • 2 sessions in-vivo dans les étages de la bibliothèque de Rennes Métropole afin de les cartographier.
  • une rencontre retour sur nos travaux autour de l’extraction du catalogue des bibliothèques de Rennes.

Nous aurions souhaité proposer plus de rencontres mais malheureusement, comme souvent, nous avons manqué de disponibilité.

Des réalisations…

Le collectif n’a pas pour vocation a produire des réalisations clés en main, mais se donne la liberté de poser un dialogue à partir d’un prototype. Cette année, nous nous sommes, assez fortuitement, concentrés autour de la bibliothèque et de son catalogue. A la fois dans sa localisation virtuelle mais aussi physique avec cette cartographie que nous avons initié. Cette dernière n’a malheureusement pas encore aboutie à ce que nous souhaiterions vraiment.

Par ailleurs, nous avons tenté aussi de relater nos travaux en alimentant ce blog. Il nous semble effectivement essentiel d’offrir une trace de notre méthodologie, nos difficultés, nos résultats.

Des évènements et des contributions…

Les membres du collectif ont participé a plusieurs évènements durant l’année 2013:

  • Hackathon sur le sujet de l’aéroport de Notre Dames des Landes
  • Opération libérons Brocas
  • Jardin numérique
  • Open data et économie
  • Codesign de https://www.data.gouv.fr
  • Groupe de travail de l’open data et la culture
  • Lancement des données culturelles à Rennes
  • Rencontre infolab

Le futur…

Le collectif souhaite continuer dans le sens d’une relais avec les acteurs publics curieux de découvrir l’open data de manière informelle et ludique. Dans ce cadre, nous espérons proposer une réunion trimestrielle sans thème précis mais offrant un temps et un espace pour que chacun puisse ouvrir ou pousser sa réflexion sur le sujet de l’ouverture des données publiques. D’autre part, nous allons tenter d’être réactif sur les données liées aux élections municipales et européennes qui nous arrivent bientôt.

Notons enfin que le collectif a réélu, lors de son AG début janvier 2014, son nouveau CA. Celui-ci a reconduit le bureau 2013 avec : Léa, présidente; Florian, trésorier et Sylvain, secrétaire. Bien entendu, le collecif est plus qu’heureux de voir l’arrivée de nouveaux membres. N’hésitez pas à nous contacter sur notre mailing-list.


La culture se libère à Rennes Métropole

Posted on

La culture à Rennes Métropole s’est ouverte en cette rentrée 2013 et plusieurs jeux de données ont été présentés lors d’un atelier-conférence autour de l’Open Data vendredi 11 octobre à la Cantine numérique Rennaise. Le collectif était présent et nous allons tenter de faire un petit résumé dans ce billet.

Les jeux de données proposés en accès libre sur le portail Open Data de Rennes Métropole proviennent de différents acteurs de la vie culturelle du territoire rennais : les bibilothèques, les musées, l’espace des sciences, les acteurs associatifs (Trans Musicales) et les acteurs privés (Ouest-France). Ils couvrent des données statistiques, des données dynamiques d’agenda, des données historiques, des données d’annuaires. Tâchons de les passer en revue succintement.

Données agenda

Les agendas culturels rennais étaient des données depuis longtemps désirées, bien avant l’arrivée de l’opendata d’ailleurs. Aujourd’hui deux jeux sont offerts, l’un sous forme XML pour l’agenda des évènements organisés au Champs Libres, l’autre sous forme d’une API pour les évènements culturels dans la région ouest via le portal Infolocale de Ouest-France. Ce sont deux jeux pivots pour la diffusion de la culture rennaise. Notons toutefois qu’Infolocale ne proposent les évènements qu’à jour+1 au plus tard. Gageons que cette limite sera levée afin d’offrir un réel intérêt. Malheureusement, il semblerait que les barrières soient surtout internes à Ouest-France. Il est aussi important de comprendre qu’Ouest-France appose des conditions générales plus ou moins restrictives à la licence OdBL choisie pour la diffusion des données.

Données d’annuaires

Le catalogue des données ouvertes par Rennes Métropole héberge aussi un jeu intéressant provenant de tout le département, l’annuaire des acteurs du spectacle vivant. Ce fichier, au format CSV, est acommpagné d’un fichier texte présentant les informations libérées. Un vrai trésor pour découvrir l’ensemble des acteurs sur tout l’Ille et Vilaine. Il serait intéressant de croiser ce jeu avec le budget de Rennes pour voir si il existe un lien entre la vie des associations de la ville et les subventions allouées chaque année.

Données statistiques

Lorsqu’un acteur ne sait pas quelle donnée publier, il commence facilement par des données statistiques sur l’usage du service qu’il fournit. Loin d’être inintéressante, il s’agit là d’informations pertinentes pour mieux interpréter le rapport des citoyens avec leur environnement culturel. La bibliothèque des Champs Libres avait déjà publiée en 2012 des informations de fréquentation, depuis cet automne nous avons aussi accès aux données de prêts sur l’année depuis 2007. A noter aussi, un jeu d’essai de tous les documents sortis des bibliothèques municipales le 1er octobre 2013.

Le musée des beaux arts de Rennes propose aussi un fichier des prêts de ses oeuvres, bien que celui-ci ne représente qu’une toute partie du fond réellement disponible et prêté. Pour des raisons légales, le musée ne peut publier certaines de ces informations.

Données catalogues

Un jeu très sympathique est le catalogue de tous les artistes passés au festival des Trans Musicales depuis sa création en 1979. Ce jeu a nécessité un grand travail de mémoire de la part des membres historiques de l’association ainsi qu’un appel au public car l’information n’était pas toujours “sûre” (un groupe pouvait avoir été remplacé par un autre par exemple). Un jeu représentatif de l’histoire locale et internationale sur la scène musicale.

 

Au final, la couverture de ces données est d’une grande richesse et les acteurs présents lors de la rencontre de vendredi étaient tous motivés pour en proposer plus. On sent évidemment beaucoup de tatonnement mais une prise de conscience que la culture et l’opendata ne sont pas deux mondes étanches. Il existe des données liées aux services eux-mêmes qui peuvent en dire beaucoup sur leurs utilisations. Bien entendu, nous ne sommes pas ici dans de l’open content cher au mouvement Open GLAM mais ne boudons pas notre plaisir de voir ces acteurs importants faire un pas vers plus d’ouverture.

En guise de cerise sur le gâteau, nous avons eu la joie de présenter quelques travaux du collectif tels que Biblioviz et Kultu Rennes afin de démontrer qu’il était possible de produire des exemples et services sur les données culturelles. Finalement Romain Wenz de la BNF nous a proposé une passionnante revue du service http://data.bnf.fr/. La sémantisation des données et le linked data sont des objectifs à viser pour offrir une nouvelle dimension aux données brutes, mais ce travail requiert des ressources importantes. Il faudra se montrer patient et la communauté devra certainement faire ce travail de liaison à partir des données sources brutes.

Un bel automne pour les données à Rennes Métropole !


Explorer le catalogue des bibliothèques de Rennes Métropole

Posted on

Dans un précédent article, j’ai pu poser quelques bases pour enclencher la relation avec un acteur public dans le cadre de l’Open Data. Passons à présent à un peu de technique.

Sources de données

La première chose fut de déterminer ce sur quoi je pourrais travailler et comment y accéder. Rennes Métropole utilise depuis longtemps un SIGB tout-en-un. Ce logiciel gère à la fois le catalogue et la gestion des prêts. Nous souhaitions accéder au catalogue afin d’offrir à termes une API facilitant l’accès aux données du réseau des bibliothèques de Rennes Métropole.

Nous avons rapidement déchanté, non pas que l’accès aux données soit impossible, mais le seul point d’entrée du catalogue est son moteur de recherche public. En effet, aucun point d’accès programmatique déjà proposé par le SIGB. Ou plutôt si, mais il s’agit d’une option payante et donc d’un investissement dont les services des bibliothèques de Rennes Métropole n’ont jamais eu besoin.

Heureusement, ces mêmes services nous ont offert un beau soutient et fourni leur accord pour exploiter le catalogue via le moteur de recherche.

Au pied de la montagne

L’intérêt d’une API est qu’elle cible les machines plutôt que les humains. Par conséquent, elle n’expose que l’essentiel et, en principe, de manière structurée ce qui facilite grandement le travail d’exploration de la donnée de manière automatisée. A contrario, le moteur de recherche lui cible les humains et se soucie assez peu d’une systématisation de l’exploration.

Mon point de départ était donc celui-ci:

Page d'accueil du moteur de recherche

Page d’accueil du moteur de recherche

La première approche, naïve, fut de chercher toutes les oeuvres commençant par la lettre a puis par b, etc. Deux difficultés sont immédiatement apparues :

  • Débuter par des lettres et des chiffres serait il suffisant pour extraire l’ensemble des oeuvres ?
  • Le moteur de recherche limite le nombre de résultats à 32000 lors d’une recherche aussi large

Un affinage était nécessaire mais sans complexifier la tâche. J’ai donc décidé de chercher par auteur en tablant sur le fait qu’il pouvait facilement y avoir plus de 32000 oeuvres débutant par un motif donné, mais probablement pas 32000 auteurs. Par ailleurs, comme un auteur amène par lien hypertexte à ses oeuvres, je retombais sur mes pattes. L’indirection présente un coût de traitement comme je l’expliquerai plus loin mais se révèle simple à mettre en place. Par ailleurs, le motif n’est plus un unique caractères mais une série de deux: aa, ab, etc. Toujours afin d’éviter la limite des 32000. Malgré tout, il subsiste des recherches l’atteignant encore mais j’ai considéré que je pouvais, pour le moment, accepter une légère perte d’information.

Do you speak HTML?

Puisque je naviguais au sein des résultats du moteur de recherche, ma matière première était du code HTML. Celui-ci offre une structure mais bien plus limitée que le résultats d’une API spécifique. Malgré tout, le code HTML de la page de résultat possédait suffisamment d’indicateurs pour en extraire de la donnée pertinente: titre, méta-données, éditeur, côte, etc.

Notice

Notice

 

Il est assez évident que le code HTML généré par le moteur de recherche a été développé à une époque où les standards du web étaient encore balbutiants. En d’autres termes, il pique les yeux.

Heureusement, j’avais à ma disposition des outils programmatiques capables de lire chaque page HTML retournée par le moteur de recherche. Une fois ces pages décomposées, je pouvais extraire les données qui me semblaient utiles. Il a fallut du temps et de la patience néanmoins pour tout extraire. En effet, ce code HTML n’utilisant pas, ou peu, d’identifiants uniques au sein de sa structure, pointer vers les éléments contenant des données s’est révélé un peu plus compliqué. Il a été nécessaire de trouver un contournement se basant sur les informations à ma disposition:

  • Le label exposé, par exemple TITRE.
  • Puis chercher l’élément le juxtaposant pour en extraire l’information.

Voici un exemple tiré directement du résultat du moteur de recherche :

<table width="100%" cellspacing="3" cellpadding="0">
<tr><!-- next row for fieldtag=t -->
<td valign="top" width="20%"  class="bibInfoLabel">TITRE</td>
<td class="bibInfoData">
<strong>Nevermind / Nirvana, groupe voc. et instr.</strong>
</td>
</tr>
</table>

Cette approche a bien fonctionné. Le désavantage le plus notable est le surcoût lié au chargement et à la navigation au sein de tant d’éléments superflus à notre objectif final. Unitairement ce n’est pas un problème mais j’ai collecté quelques 600 000 notices…

Par ailleurs, comme je l’indiquais plus haut, le fait de devoir utiliser les auteurs comme point d’entrée du catalogue m’a obligé à consommer bien plus de pages HTML que si j’avais pu directement parcourir la liste exhaustives des oeuvres.

Vous avez bien un peu de temps ?

Comme indiqué ci-dessus, j’ai récolté environ 600 000 notices en un peu moins de trois jours. Un conseil, estimez à l’avance le nombre global de notices via le moteur de recherche. L’idée est que si vous avez un plafond vous pourrez potentiellement optimiser votre récolte afin d’en réduire la durée.

Quoiqu’il en soit, les performances de la récolte avaient plusieurs facteurs limitant :

  • Le moteur de recherche n’est probablement pas optimisé pour subir des recherches aussi larges et soutenues
  • J’ai tenté de distribuer la charge en multipliant les agents de récolte mais il semblerait que les services informatiques de Rennes aient placé des gardes fous (et ils ont bien raison) diminuant mes capacités
  • Il aurait été intéressant que je puisse essayer mes agents de récoltes depuis un serveur plus performant (dans ce bon vieux cloud) et déterminer si ma machine elle-même posait ses contraintes

Le principal désavantage à une récolte si longue est de ne pas pouvoir la rejouer chaque nuit afin de synchroniser les données le plus régulièrement possible, notamment en ce qui concerne les attributs de prêts (date de retour par exemple).

Stockage de masse

L’idée d’extraire l’ensemble des notices du catalogue est une étape mais, dans une optique Open Data, il fallait proposer cet ensemble de données de manière structurée au public afin d’éviter de devoir toujours passer par une collecte fastidieuse.

A l’heure actuelle, il n’est pas encore clair quel medium de distribution je choisirai mais il est évident que celui-ci devra faciliter l’exploration des données récoltées. Une base de donnée relationnelle, ou NoSQL, semblerait un bon candidat.

Par ailleurs, récemment j’ai pu découvrir le projet BibServer de l’OKFN sur le sujet des données bibliographiques et je dois avouer aimer leur approche. Il s’agit d’une application web assez simple proposant un moteur de recherche, mais aussi une API, sur des notices (des records). Le serveur ne stocke pas les notices dans une base de données traditionnelle, ni sur le système de fichier lui même mais directement dans un moteur de recherche qui les indexe et propose une interface de recherche très poussée et efficace. Cela répond bien aux origines de notre intérêt des données de bibliothèques, ouvrir l’accès aux données par une API. Tout cela en participant à un effort international sur le sujet.

D’autre part, le projet BibServer promeut un format d’encodage des données bibliographiques simple et flexible s’appuyant sur des méthodes et ontologies standardisées: le BibJSON. Ce format offre une souplesse intéressante dans la manipulation des données et donc de belles perspectives.

Parlez-vous bibliothécaire ?

L’un des aspects les plus enrichissant de travailler sur des données est d’en comprendre le contexte, le vocabulaire, le jargon. Et pour le coup, le milieu des médiathèques est passionnant mais néanmoins complexe. Il s’agit d’une vieille discipline qui s’est enrichi dans le temps et qui continue d’évoluer. La BnF propose par exemple une revue de la complexité du catalogage.

Un exemple simpliste mais illustratif est celui du nom d’un auteur. En général, les notices utilisent le format “Nom, Prénom” qui semble moins intuitif que “Prénom Nom”. Mais il s’agit d’une règle de la norme NF Z 44-061 publiée par l’AFNOR. Tout est donc codifié suivant des règles strictes. La difficulté réside dans l’automatisation du traitement des ces règles afin d’en extraire l’information désirée, et potentiellement les rendre plus consommables en dehors du modèle français de catalogage et d’indexation. Par exemple dans la liaison avec des sources externes telles que Wikipedia (via DBPedia), MusicbrainzIMDBGoodReads, etc.

Ainsi, dans le cas de l’album Nevermind du groupe Nirvana, on se rend compte que le titre affiché est : Nevermind / Nirvana, groupe voc. et instr. Or nous ne sommes pas intéressés par la seconde partie du titre, qui ne nous apporte pas grand chose pour une exploration générique du catalogue. La difficulté est que nous n’avons pas toujours un motif clair pour scinder le titre ou l’auteur en différentes composantes. Nous pourrions ainsi avoir Nevermind Nirvana, groupe voc. et instr: Comment déterminer le titre de la description qui l’accompagne de manière automatisée ? Notons que le catalogue s’est construit durant des dizaines d’années, bien avant que l’outil informatique existe, expliquant que les données puissent induire en erreur un outil informatique.

Un autre exemple découvert au fil de l’eau est celui de la traduction. Le moteur de recherche retourne les traducteurs comme des auteurs donc je les traitais de cette façon. Evidemment ceci n’a pas de sens. Il a fallu par conséquent ajouter une vérification que l’ “auteur” retourné était effectivement l’un des auteurs réels de l’oeuvre, pas un traducteur, exécutant, etc.

Bref, l’extraction systématique des données est une étape. L’exploration en sera une autre plus complexe.

Et la suite ?

A l’heure actuelle, les données et le code ne sont pas encore publics. Le code qui nous a permis d’extraire le catalogue le sera bientôt (après un sérieux nettoyage de fond). est désormais accessible. Quant aux données, nous attendons le retour officiel des bibliothèques de Rennes Métropole afin, par exemple, de spécifier la licence avec laquelle nous pourrions distribuer les données.

Edit. du 26/02/2013: Il semblerait que l’Etat porte un projet d’aides aux bibliothèques désireuses d’avancer vers le numérique (merci Léa du lien).


Les bibliothèques de Rennes Métropole à l’heure de l’Open Data

Posted on

Depuis 2010, Rennes Métropole s’est lancée dans l’open data et a ouvert des données d’horizons variés. Un domaine reste malgré tout plutôt pauvre, c’est celui de la culture. Pourtant Rennes ne manque pas d’acteurs publics ou privés liés à la culture sous toutes ses formes. Le terreau est riche et fertile.

Un acteur a quand même commencé à proposer certains jeux de données, il s’agit de la bibliothèque des Champs Libres, avec ses statistiques de fréquentations par heure et par jour. Ces données sont intéressantes car elles permettent de percevoir la distribution des visites tout au long de l’année et peut-être en faire des corrélations (va-t-on plus à la bibliothèque lorsqu’il fait froid ? quand il pleut ? le printemps est-il plus propice à la lecture ? etc.). Le Collectif Open Data Rennes s’est d’ailleurs appuyé sur ces données pour en proposer un jeu de visualisations. La culture nourrit la culture.

Néanmoins, nous pensons qu’il y a plus à faire avec l’information qu’une bibliothèque peut générer et manipuler au quotidien: nombre de documents empruntés, retournés, en retard, emprunts par heure ou jour, quelle section d’une bibliothèque est la plus dévalisée. Bien entendu on peut ajouter aussi son catalogue, l’âme d’un tel lieu.

Une approche en douceur

Initialement, lorsque vous souhaitez travailler sur des données d’un acteur public, il est bon de faire un tour sur leur site afin de voir ce qui est accessible, même si ce n’est pas programmatiquement exploitable. Ainsi les Champs Libres possèdent une section évoquant l’histoire et les chiffres, notamment ceux liés à la bibliothèque.

Mais nous parlons d’open data, nous voulons des données structurées. Si aucun jeu de données ou d’API n’est proposés librement par l’acteur public en question, il est temps de prendre contact avec eux pour en discuter. La manière pour le faire dépend très largement de la politique d’ouverture de la commune et des institutions qui en dépendent, ainsi que de l’acteur lui même. Bien entendu, une sensibilisation à l’open data et à ses enjeux est un préalable important pour que l’acteur s’engage dans l’initiative. La prise de contact peut se faire par email mais il est probable qu’une entrevue de visu sera plus productive. Trouver le bon interlocuteur va requérir toute votre sagacité. Dans le cas de la Bibliothèque, ils étaient déjà engagés dans une démarche d’ouverture des statistiques, et nous avons eu la chance de les avoir rencontrés au travers de réunions sur le sujet à la Cantine Numérique Rennaise. Par ailleurs, Léa étant en très bon rapport avec des membres de la bibliothèque facilitant ainsi les premiers échanges.

Ne jamais hésiter à ouvrir la discussion, si vous trouvez le bon interlocuteur.

Un jeu de patience donnant/donnant

Dans le cas où l’acteur répond positivement à la demande d’ouverture de certaines de ses données, vous allez devoir vous armer de patience. En effet, l’existence d’une donnée ne signifie pas qu’elle soit facilement accessible ou exploitable. L’open data demande un effort et un processus qui peut se révéler complexe ou coûteux, au moins en temps.

Par ailleurs, afin de justifier ce surcoût, il est possible que l’acteur public ou privé propose d’abord un jeu de données simples afin de voir l’engouement à son égard. Cela peut faire bondir les défenseurs de l’open data qui estiment que les données ne doivent pas être prises en otage, mais le pragmatisme est de mise dans l’action publique. Par conséquent, un jeu de donnée basique attisant les appétits, il peut se révéler judicieux de montrer qu’il y a effectivement une attente réelle pour plus de données. Le collectif, sous l’impulsion de Léa, a ainsi proposé l’opération #biblioviz.

Une fois que la discussion est engagée, il convient alors de faire un état des lieux des données qu’une bibliothèque manipule et celles qui peuvent intéresser la collectivité, et enfin lesquelles entrent dans le cadre légal de l’open data.

Des contraintes à prévoir

Techniques

Les communes possèdent des fonds patrimoniaux bien antérieurs aux nouvelles technologies sans parler des mouvements d’ouvertures comme l’open data, l’open content, voire l’opensource et le logiciel libre (on parle de dizaines d’années pour les logiciels, et des centaines d’années pour certain bien du patrimoine). Ces considérations ne sont pas entrées en ligne de compte dans les appels d’offres de logiciels tels que les SIGB. Par conséquent, il est fort à parier que le logiciel équipant votre bibliothèque soit fermé (qu’il soit privateur ou privé, en tout cas non-libre d’accès). Cela pose des difficultés certaines pour l’ouverture des données, sans parler de requérir parfois une licence spécifique d’un montant substantiel. C’est le cas des bibliothèques des Rennes Métropole et ce qui a poussé le collectif à contourner cette contrainte en aspirant le catalogue via le moteur de recherche. Nous y reviendrons dans un prochain article.

Légales et politiques

La culture n’est pas un domaine simple lorsqu’il s’agit d’accéder à des données. Celles-ci sont gardées jalousement et/ou sont simplement trop complexes et coûteuses à rendre disponibles. Par ailleurs, la culture est le monde du droit : droit d’auteur, droits voisins, etc. Il peut se révéler très complexe pour un acteur de savoir comment l’open data s’inscrit dans ce contexte. Dans tous les cas, les acteurs de la culture se doivent d’être prudents avec les données, car il peut ne pas leur appartenir le droit de les mettre à disposition.

Compétences métier

Comme tout domaine, la bibliothèque a ses métiers, avec ses codes, ses règles, et son vocabulaire. Lorsque le Collectif a rencontré la Bibliothèque, il a d’abord fallu expliquer certain termes employés (rien que SIGB par exemple). De même, les données peuvent être classées et codifiées selon une norme spécifique à un métier. Cette contrainte est indéniablement une occasion de s’intéresser et de discuter du métier de la bibliothèque, et d’écouter ses acteurs et ses professionnels.

Demandeur mais aussi acteur

La démarche de l’open data doit se faire avec de la patience au ventre. Il est en effet indispensable de se remémorer que les acteurs publics ou privés, même lorsqu’ils sont moteurs, prendront le temps qu’il faut pour libérer leurs données. Il existe un temps incompressible dont il faut tenir compte, et prendre patience afin de respecter le planning des différents interlocuteurs.

Malgré tout, il est possible, comme avec le catalogue des bibliothèques, de déjà vous faire une idée des données que vous pourriez traiter et ainsi aiguiller votre interlocuteur.

L’opendata propose au citoyen un outil supplémentaire pour agir sur sa vie locale.

Conclusion

Les bibliothèques de Rennes Métropole semblent accueillir avec bienveillance l’idée d’un accès à leurs données. Mais pour des raisons de contraintes techniques liées à leur SIGB ainsi qu’à des impératifs liés à leur planning, il apparaît clair au Collectif qu’une partie du travail devra se faire par des moyens indirects tels que nous évoquions plus haut. Nous présenterons ce travail lors d’un prochain article.