Question subsidaire sur la réutilisation des données Star

Posted on

Ce billet est un petit ajout que je me suis surpris à faire à la fin de l’article : Réutiliser des données du réseau Star.

Combien ça coûte un développeur ?

Question complètement annexe, mais je me suis surpris à calculer un “coût” pour mes développements. Bien entendu, j’ai tout fait en bénévole, sur mon temps libre, et je ne compte absolument pas demander de l’argent pour ça.

Mais quand même, par curiosité, je vous propose de jouer le jeu avec moi.

Coût du temps passé

Pour rappel, j’ai donc passé 12h sur l’API elle-même, 16h sur les données téléchargées, et 20h à faire une API moderne RESTFull. En arrondissant les angles, et sans trop compter les multiples moments de réflexions entre deux voyages en bus/métro/train/marche à pied/réflexion le matin en me rasant, j’arrive à 48h de travail.

Coût du temps restant

Pour donner une autre représentation de ce temps, sachez que mon coût horaire moyen tourne entre 50 et 75€ brut, soit entre 2400 et 3600€. Je pense que je peux coûter bien plus cher (surtout si je prends des tarifs parisiens), mais c’est à peu près ce que j’avais calculé pour vivre sereinement à Rennes en débutant comme freelance.

J’estime que pour finir mon travail, 30h supplémentaires sont nécessaires, soit entre 1500 et 2250€. Cela correspond à :

  • Finaliser l’API RESTFull en ajoutant entre autre les métros et les bus
  • Optimiser le traitement et l’analyse des données à télécharger
  • Installer le tout sur un serveur disponible au public
  • Écrire plus de documentation

Pour un total entre 3900 et 5850€, avec 78h de travail pour l’ensemble (passé et restant).

Coût de la gestion et des frais divers

Je propose de rajouter :

  • De la gestion de projet (discussion avec le client, réunion, etc.) soit 20% de temps en plus à 50€ de l’heure, soit 780€.
  • Des frais de gestions divers et variés, remboursement de transports éventuels, et quelques menus frais pour 5% du temps à 50€ de l’heure, soit 195€.
  • Du bug-fixing. Le sujet est relativement simple au final, les bugs déjà pris en compte en bonne partie dans le temps de travail, mais par sécurité, j’ajoute une maintenance corrective de 10% du temps au tarif horaire normal, soit entre 390 et 585€.

Le total final d’une livraison stable correspond donc à : 5265 à 7410€. Et ça, c’est pour le travail d’un seul et un unique homme. Cela devrait prendre entre 2 et 3 semaines de temps réel.

Les coûts invisibles ou non pris en compte

Tous ces calculs sa basent sur l’existant, et donc, cela ne prend pas en compte :

  • Le développement pour l’accès aux données temps réel entre l’API et le système réel Kéolis (j’ai déjà une API pour ça, cela fausse donc le temps passé sur cette partie là, qui est pour le moment de 12h).
  • La mise en forme des données à télécharger, qui peut cependant être mis à part (puisque nécessaire quel que soit le projet derrière).

Et pour l’hébergement ?

Pour ajouter une petite note supplémentaire, je pourrais estimer rapidement le coût en hébergement serveur. Considérant une architecture assez standard : une BDD, un serveur Web, un serveur Proxy/Cache. Mettons que chacune soit un serveur de taille honorable, entre 1500 et 2000€/an.

Cela fait entre 4500 et 6000€ par an pour une plateforme “premier pas”. Si je veux assurer un peu plus, j’ajouterais bien quelques parts de plus (chez Gandi.net évidement), pour arriver plutôt vers 2500€/an, pour finir donc à 7500€ par an pour l’hébergement.

Conclusion

Peut-être que je devrais monter un projet sur Ulule.fr, pour développer une API qui ne serait pas qu’en lecture seule (comme aujourd’hui). Peut-être qu’il y a un business-model à imaginer avec ces données. Peut-être…

Honnêtement, je n’en sais rien, je n’ai pas les réponses à ces questions. Je sais juste que ce que je fais, je le fais bénévolement, et que je sais ce que ça représente. Je serais curieux de savoir ce que ça représente pour quelqu’un comme Yan Bonnel, dont l’application est – oui, j’insiste – une vrai petite merveille.

Et tout ceci n’est qu’une goutte d’eau.


Réutiliser des données du réseau Star

Posted on

Le Service des transports en commun de l’agglomération rennaise, que je vais appeler le réseau Star, a commencé à ouvrir ses données vers le 1er Mars 2010. En tant que membre du collectif et usager quotidien du métro et des bus de Rennes, ces données m’intéressent. En tant que développeur (web, mais pas que), c’est plutôt le transport de ces données qui m’intéresse.

Et c’est ce dont je suis venu vous parler aujourd’hui : comment ces données se retrouvent dans nos téléphones, dans les applications de développeurs indépendants, voire le plus souvent complètement bénévoles (oui, je pense à l’excellente application Android de Yan Bonnel (et le compte twitter associé @TransportRennes)). Plus exactement, je vais vous parler de ma propre expérience, cela devrait vous donner un aperçu du travail que cela représente, et des difficultés rencontrées.

Si vous n’êtes pas développeur, j’essaie dans la suite de l’article de rester dans la vulgarisation, j’espère donc rester assez accessible. Mon but est de transmettre mes impressions sur mon expérience avec les données, en ajoutant le temps que cela m’a pris. N’hésitez pas à poser des questions en commentaire !

Où sont les données ?

Première question à se poser : où sont les données ? Non, la réponse n’est pas si simple que ça, parce que les données ne sont pas à un seul et même endroit. Le bon point, c’est que les données sont référencées à la même adresse : sur le site officiel data.keolis-rennes.fr. Mais il y a les données à télécharger, et les données de l’API.

Télécharger n’est pas encore réutiliser

Celles à télécharger sont dans un format normalisé par Google : le format GTFS. C’est une bonne et une mauvaise nouvelle. La bonne, c’est que c’est un format ouvert et relativement bien documenté, donc après quelques heures de lecture de la documentation, un développeur peut comprendre comment interpréter les fichiers. Si vous savez vous servir d’un tableur, vous pouvez ouvrir ces fichiers aussi (avec le mode CSV), et vous en sortir avec quelques bons filtres.

La mauvaise nouvelle, c’est que ce format est vu du point de vue du transporteur. C’est à dire que si vous cherchez à adopter le point de vue d’un usager, vous n’allez pas arriver bien loin. Ce qui est un peu dommage, parce que le but de ces données, quand même, c’est d’être finalement présentées par le développeur aux usagers. Orienter la structure des données vers la vision des usagers, c’est faciliter le travail des développeurs (sauf si vous voulez développer un système pour le transporteur).

Bon, pour comprendre, rien ne vaut un exemple : un usager voudra savoir si une ligne de bus peut l’emmener de l’arrêt de bus A à l’arrêt de bus B. Il regarde la fiche d’une ligne, et voit que c’est possible, parce que la fiche lui donne toute la liste des arrêts, dans l’ordre.

Le format GTFS n’a pas de concept de “fiche de voyage type”. Il propose l’ensemble des voyages complets (chacun part à telle heure, termine à telle heure, et passe par A, B, C, D, E, etc. dans un ordre précis). Mais il ne permet pas facilement de savoir quels sont les arrêts de bus d’une ligne.

C’est tout à fait logique du point de vue du transporteur, mais c’est un vrai casse-tête pour le développeur qui veut présenter l’information aux voyageurs.

En bonus point, nonobstant une qualité générale plutôt bonne, il y a des incohérences dans les données fournis dans ces fichiers par Keolis.

Deux trajets peuvent indiquer la même direction dans le même sens (c’est à dire qu’ils viennent par le même côté de la ligne, et dans le même ordre), mais ils ne partent pas toujours du même endroit. Pourtant, si vous lisez la seule donnée disponible à ce sujet, vous allez faire comme moi : vous tromper et obtenir une fausse analyse des données.

Un autre soucis que j’ai remarqué : pour un usager, globalement, un bus a trois types de journées de circulation. Les journées de la semaine (lundi au vendredi), le Samedi, et enfin le Dimanche et jour férié. Il y a un fichier pour ça dans le format GTFS, mais il est très mal exploité par Kéolis. Il n’y a pas de service type pour 5 jours, un pour le samedi, un pour le dimanche et jours fériés, et d’autres pour les cas spécifiques. À la place, il y a plusieurs fois le même service par jour de circulation. Cela créé des “faux” doublons dans la base, et si vous recherchez la performance, il faut, là encore, faire un travail long et coûteux supplémentaire.

Heureusement, vous pouvez quand même déterminer quels sont les trajets types en poussant vos analyses avec de gros traitements un petit peu plus lourd (à programmer et à exécuter). Autant vous dire que ce n’est pas pour nous rendre la tâche facile.

La faute à qui ? Un peu à GTFS, mais l’utilisation par Kéolis n’est vraiment pas optimale (même si je veux bien croire qu’il y a un effort fourni, j’ai pu en discuter rapidement avec l’ingénieur qui travaille sur le sujet pour Kéolis).

API mon amour

Une autre partie des données est disponible via une API. Ce qui est bien, car cela permet d’obtenir des données en temps réel : prochain passage, disponibilité des vélos, etc. Le soucis, de mon point de vue (d’usager et de développeur), c’est que cette API n’est ni complète ni bien documentée.

Attention, je ne critique pas ici ni l’intention ni l’ouverture des données via une API. C’est une bonne idée et je remercie Rennes, Star et Kéolis de proposer cette API. Mais en tant que développeur, je suis souvent frustré par ce que j’ai à ma disposition.

J’ai d’ailleurs écrit un petit article sur un sujet bien précis au sujet des API : “Pour qui sont les API ?”. Cet article fait suite à la rencontre qui s’est tenue à la Cantine Numérique Rennaise en décembre dernier. Lors de cette rencontre, j’ai présenté mon travail à quelques autres développeurs sur les données.

Travailler avec les données.

Une fois les données en main (façon de parler), j’ai beaucoup travaillé à les rendre réutilisables (pour moi entre autres). Tout d’abord j’ai commencé par l’API, en proposant un client python (pour développeur). Sur la douzaines d’heures que cela représente, je me suis confronté à plusieurs problèmes :

  • L’API est mal documentée. Certes il y a toutes les méthodes appelables, mais la présentation des paramètres, leur usage, etc. est très peu voire parfois pas du tout expliqué. J’ai dû passer plusieurs heures à comprendre comment faire certains appels, pourtant relativement simples une fois le tout posé à plat. Pour l’exemple, ma documentation du client pour Le Velo Star, et la documentation de la méthode principale côté API Kéolis.
  • Détail supplémentaire, la langue de la documentation est un mélange entre l’anglais et le français, ce que je trouve pour le moins surprenant, et ne me donne pas confiance en ce que je lis.
  • L’API ne retourne pas d’erreur lorsqu’il ne peut pas y avoir de contenu. Ce n’est pas normal : si je demande la ligne de bus 7814, je demande une ligne qui n’existe pas, mais l’API ne m’informe pas de mon erreur. Cela peut paraître anecdotique, mais cela induit, encore une fois, un manque de confiance dans les résultats obtenus.
  • En fonction du format de sortie demandé (JSON ou XML), les données ne sont pas toujours identiques. J’ai eu l’occasion de remonter une erreur sur l’API temps réel pour le bus (et elle a été corrigée). C’est inquiétant, parce qu’une API en laquelle on ne peut pas avoir confiance nuit à la qualité générale. S’il y a une erreur sur un cas, rien ne dit qu’il n’y en a pas pour d’autres.
  • Quelques soucis de latences, d’autres soucis avec les formats, les paramètres, la clé de l’application qui passe en clair dans l’url, etc. mais ça devient vraiment très technique.

Mais mon plus gros problème a été le suivant : L’API ne dispose pas de toutes les données. Il faut coupler les appels avec une analyse et un traitement des données à télécharger. Autant dire qu’il est impossible de se reposer naïvement sur une seule source de données.

Objectifs et réalisations

À l’origine je souhaitais simplement tester l’API, comprendre son fonctionnement, et pourquoi pas, proposer un client en python complet, pour que d’autres développeurs puissent, sereinement, reposer toute leur application sur ce client. Lorsque je me suis rendu compte que toutes les données n’étaient pas dans l’API, et qu’une bonne partie devaient être récupérer dans le flux GTFS, je me suis posé quelques questions.

Et j’ai foncé tête baissée dans un WE (environ 16h sur deux jours) de développement de scripts, d’analyses, de traitements et de formatages des données. J’ai ensuite continué quelques jours de plus (environ 20h de plus) à développer un concept d’API REST autour des données complètes (pour information, c’était mi-Décembre 2012).

En un peu moins d’une semaine de travail (aux 35h et des poussières), j’ai obtenu une API qui présente les données statiques du réseau de bus de Rennes, avec ses arrêts de bus, ses lignes, ses trajets et ses heures de passage, le tout avec des données liées les unes aux autres, une structure plus à plat et plus facile à comprendre.

Bref, quelque part, j’ai refait le travail de Kéolis avec ses propres données. Et je ne sais pas quoi en faire.

La motivation après le premier effort

Au début j’étais très motivé. Le sujet me passionne toujours autant aujourd’hui, mais après une semaine de développement, je ne suis plus trop sûr de vouloir continuer.

Parce que si mon objectif de base est à peu près atteint (un client python fonctionnel, bien que largement améliorable), je sens bien qu’il y a beaucoup plus que ça à faire. Et une partie de mon travail d’analyse et de réflexion, je ne suis pas complètement certain que c’est à moi de le faire.

Je m’explique.

Je pense qu’il faut un juste milieu. D’un côté il y a une API et des données à télécharger. De l’autre il y a des développeurs. Je veux bien travailler pour créer des outils pratiques pour les développeurs : client python, php, java, ou que sais-je encore. Je veux bien travailler pour rendre la vie plus facile aux développeurs, avec des outils d’analyses des requêtes, un vérificateur, etc.

Mais je ne veux pas refaire le travail de Kéolis, c’est à dire, refaire une API complète. Peut-être que je vais y venir quand même. Peut-être que d’autres développeurs vont trouver l’idée intéressante finalement, et je les invite à me contacter. Peut-être que, dans tout ça, il y a quelque chose “en plus” à faire, que je n’ai pas vu, pas compris, pas utilisé.

Le premier effort était super, et mes résultats sont très satisfaisants. Aujourd’hui, ma motivation fait défaut face à ce que je considère comme un service à moitié rendu – et je me demande si cela ne soulève pas non plus la question de cette notion de “service rendu” – et des attentes que cela provoque !

J’ai beaucoup d’autres choses à dire sur ces données, notamment sur ce que l’on peut faire avec, ce dont je n’ai pas parlé ici. Mais pour le moment, j’en suis là, avec mes interrogations d’usager et de développeur. Avec mon temps libre vaguement réduit et mes différents projets.

Le mieux peut-être maintenant, c’est de faire comme je le disais le 19 décembre dernier en introduction : discutons !

Edit : Petite annexe sur le “coût” de développement.


Dataviz et relations entre les données : attention aux pièges

Posted on

Parfois, vous tombez sur un joli diagramme qui vous explique en quoi deux éléments apparemment sans relation sont liés par une obscure courbe de tendances identiques.

Ce fut le cas récemment sur Twitter, où j’ai découvert cette visualisation : Internet Explorer vs Murder Rate (US). Alors oui, j’ai souri trois secondes, le temps de me rendre compte que cette dataviz était une tromperie – pour la blague, certes, mais quand même.

Une question d’échelle(s) et de référentiel(s)

Pour comprendre le souci, j’ai fait le petit calcul suivant : si 18000 meurtres (ce qui n’est pas un taux, au passage mais un nombre arbitraire) représentent 90% (comme pour l’axe de valeur du taux pour IE), alors que représentent 14000 meurtres ? Sur le diagramme, 30%, mais avec le calcul suivant : 90* 14000 / 18000 = 70 : un écart de 40% se serait donc glissé dans ce diagramme ?

Le premier problème donc, c’est d’avoir deux axes qui ne sont pas réellement en relation. Pour résoudre ce premier problème, je vous propose le diagramme suivant :

IE vs Meurtre aux US (échelle de % identique)Tout de suite, ce n’est plus tout à fait la même chose. Vous pouvez constater que la courbe des meurtres aux USA n’a pas tout à fait la même tête que la descente des parts de marché d’Internet Explorer (il chute plus vite que le taux de meurtres).

Pour obtenir ce diagramme, j’ai évalué (un peu à la louche je l’admets) le nombre de meurtre et le % d’IE, j’ai ensuite transformé en pourcentage (selon la formule précédemment citée) pour obtenir le taux de meurtres à la place des chiffres (18000, etc.).

Mais cette dataviz aussi est incorrecte ! Parce qu’elle essaye de comparer deux choses qui n’ont rien à voir pour commencer. Certes, l’échelle est plus intéressante, mais ne permet toujours pas de répondre à la question de la relation entre les deux données.

D’ailleurs, chose amusante, si je demande à mon tableur de représenter les deux échelles sur deux axes différents, voici ce que j’obtiens : IE vs Meurtre aux US (échelles de % différentes)

Comparer ce qui est comparable

Lorsque vous étiez à l’école un professeur a dû vous expliquer que comparer des Poires et des Pommes, ça ne donnait pas de très bon résultat (à propos des comparaisons de fractions, de mémoire). Et là, c’est exactement la même chose !

Voici les deux types de données ici présentées :

  • Une quantité fixe : le nombre de meurtres.
  • Un ratio : la part de marché d’Internet Explorer.

Autant dire que ces deux données ne peuvent pas être comparée telle qu’elles sont ! Si quelqu’un cherche à savoir s’il y a une relation entre le nombre de meurtres et la part d’IE, il faudrait d’abord transformer un peu tout ça en quelque chose de comparable.

Qu’est-ce qui est comparable ?

Il y a un tas de façon de comparer deux données différentes, mais je ne suis pas sûr que toutes soient pertinentes. Je vais essayer d’en présenter une et nous verrons ensuite si ça veut dire quelque chose.

Tout d’abord, je reviens aux données sur IE : ce sont des parts de marché. En gros, c’est le pourcentage de gens utilisant le logiciel. Il est plutôt difficile de trouver le même genre de comparaison pour les meurtres : faut-il prendre le nombre total de décès comme référence ? Le nombre de personnes que cela représente par rapport à la population globale ?

Tout dépend ce que l’on cherche à savoir : est-ce que la proportion de décès par meurtre a augmenté ? Ou est-ce que la proportion de meurtres a augmenté par rapport à la population totale ?

Je vais choisir de faire une comparaison avec la population totale, ce qui m’arrange plutôt bien, puisque sur Wikipédia il y a quelques statistiques à ce sujet : Classement des pays par taux d’homicide volontaire. Je sais, il y a plus drôle comme données, mais je fais avec ce que j’ai sous la main.

En outre, je ne vais pas comparer les deux données : je vais faire le ratio entre chaque valeur à la même année. Si la tendance est la même entre les deux, alors je dois obtenir une ligne droite : si le ratio est différent, cela implique qu’une valeur change plus qu’une autre (en plus ou en moins).

Ratio part de marché IE / nombre de meurtre pour 100 000 habitants

Et voilà ! J’annonce fièrement que… et bien rien en fait. J’ai seulement tracé un diagramme avec une ligne qui plonge, mais ça ne veut rien dire du tout en réalité.

Tout ceci ne prouve rien

Vous avez vu mon précédent diagramme, et vous vous êtes dit : “c’est la preuve qu’il n’y a aucun rapport entre les données !”.

En fait, ce n’est pas vrai. Plus précisément : ceci ne permet pas d’affirmer ou d’infirmer la relation. Ce n’est pas vraiment pertinent.

Si vous regardez bien, j’ai placé l’échelle du ratio à droite, qui va de 13% à 15.5%. En somme, 2.5 points séparent le maximum du minimum. Je n’ai pas non plus affiché la valeur de chaque ratio. Tout ce que vous pouvez voir c’est une ligne qui plonge. Que se serait-il passé si j’avais choisi une autre échelle, allant, par exemple, de 0 à 100% ? Vous auriez vu plutôt une ligne droite – ce qui aurait alors indiqué exactement le message inverse de mon diagramme !

C’est là qu’est le piège : lorsque vous choisissez des échelles et des représentations, vous orientez la vision de l’observateur vers le message qui vous intéresse, que vous en soyez conscient ou non. Au passage, le premier observateur, c’est vous-même !

Il faut faire attention : même en essayant de comparer ce qui peut l’être a priori, vous pouvez avoir des surprises.

Attention aux visualisations

Le but n’était pas de démontrer que la blague d’origine n’est qu’une (bonne) blague : tout le monde doit pouvoir s’en rendre compte en réfléchissant un peu.

Non, mon but ici était plutôt ceci :

  • Faire comprendre qu’une visualisation de données, c’est sortir de la donnée brute et aller vers de l’analyse.
  • Montrer que les relations entre les données sont très complexes à démontrer.

Ce n’est pas vraiment une surprise pour les connaisseurs et les analystes en la matière, mais c’est un piège très fréquent, et dans lequel il est facile de tomber. C’est l’un des problèmes le plus fréquent d’ailleurs lorsque vous regardez les sites d’informations ou la TV : des visualisations avec des données de types et d’origines très différents, des échelles trompeuses, etc.

En outre, il faut rester vigilant : parfois, nous voyons des relations entre les données parce que nous voulons les y trouver (nous sommes le premier observateur). Pourtant, un travail de fond et des analyses supplémentaires sont toujours nécessaires pour trouver et décortiquer les relations entre les données.

C’est, à mon avis, un argument important pour favoriser la culture de la donnée, et une plus large éducation et sensibilisation du public (dès l’enfance), aux visualisations et aux traitements des données.


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.