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.

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

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.

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

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.

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

Prochaine réunion le 20 novembre

Posted on

Bonjour à tous,

La prochaine réunion du collectif aura lieu mercredi 20 novembre 2013, à 18h30 à l’Annexe (20 rue d’Isly, 2e étage).

Lors de cette rencontre informelle, nous parlerons des projets en cours, de nos envies, autour de l’open data et de la réutilisation de données.

Ouvert à tous, vous êtes les bienvenus !

A bientôt, Léa

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

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 !

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

Prochaines rencontres du collectif

Posted on

Bonjour !

En juin, le CODRennes participe à plusieurs évènements autour des données et de l’innovation. Voici les prochains rendez-vous où vous pouvez nous retrouver :

L’open data et la bibliothèque

Depuis bientôt un an, plusieurs bénévoles du collectif travaillent autour des données (fournies, collectées ou imaginées) des bibliothèques de Rennes.

Le 27 juin, à 18h30 à la Cantine Numérique, nous vous proposons une rencontre pour présenter les différents projets que nous menons, une réunion de travail et d’échange entre la bibliothèque et le collectif, à laquelle tout le monde peut participer.

Au programme :

  • présentation du collectif et de ses actions
  • présentation de la bibliothèque, de ses projets, son système d’information
  • présentation et démonstration des projets sur lesquels travaille le collectif autour des données de la bibliothèque (cartographie de la bibli, récupération des données du catalogue, maquettes d’applications possibles)
  • échanges et questionnements autour de ces projets

Intéressé par l’open data, par les bibliothèques et le numérique ? N’hésitez pas à nous rejoindre !

Tu imagines ? Construis !

Le collectif participe à deux ateliers lors de l’évènement Tu imagines ? Construis ! qui aura lieu du 28 au 30 juin à l’EESAB (école des Beaux-Arts) de Rennes.

Data+ est une série d’ateliers visant à collecter des données en open data et de les connecter avec des objets afin de pouvoir les présenter de manière simple. Les ateliers ont lieu le vendredi, samedi et dimanche après midi, et sont co-animés par Florian, membre du CODRennes. Info et inscription

Biblio Remix est une expérimentation visant à réinventer la bibliothèque et proposer de nouveaux services. Plusieurs membres du collectif participeront à la session du dimanche. Info et inscription

Si vous souhaitez plus d’infos, n’hésitez pas à nous contacter.

A très bientôt !

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

Une cartographie des livres en bibliothèque

Posted on

Bonjour !

Tout d’abord, toutes nos excuses pour le peu de mouvements sur ce blog, et l’absence d’évènements grand public autour de l’open data sur Rennes. Ces évènements vont prochainement revenir, et seront bien sûr annoncés ici et via la Cantine Numérique.

Cependant, ce n’est pas pour autant que les membres du collectif se tournent les pouces : nous travaillons sur différents projets et nous essayons de donner régulièrement des nouvelles et des réflexions sur ce blog, comme le fait par exemple Sylvain sur son travail d’extraction des données du catalogue des Bibliothèques de Rennes (voir ses deux articles ici et ).

C’est également un retour d’expérience que je vous propose aujourd’hui, et qui portera aussi sur la bibliothèque… eh oui, c’est un sujet qui passionne plusieurs membres du collectif, d’autant plus que nos interlocuteurs sont très ouverts sur le sujet et acceptent volontiers de discuter de leurs données avec nous. Cet article est donc un récit de nos essais, nos réflexions et nos bidouillages sur notre nouveau projet.

Une carte de la bibliothèque des Champs Libres

La bibliothèque des Champs Libres à Rennes s’étend sur six étages et dispose de plus de 200 000 documents en libre accès. Notre idée de départ était de cartographier la bibliothèque afin de pouvoir repérer l’emplacement de chaque livre. Par exemple, après une recherche dans le catalogue, pouvoir indiquer au lecteur que l’ouvrage se trouve non seulement aux Champs Libres, mais à tel étage, et pourquoi pas dans telle étagère, tel rayon ?

3d

Un beau dimanche du mois de mars, quatre membres du CODRennes se sont donc retrouvés aux pieds de la bibliothèque. Papier et crayons en main, nous avons rapidement défini l’objectif : cartographier le quatrième étage (Littérature) de la bibliothèque afin d’indiquer précisément où se trouvaient chaque tranche de cote.

La cote est un système de classification des ouvrages, que l’on retrouve par exemple sur la tranche des livres. La classification de Dewey est la plus utilisée, et propose de diviser le fonds de la bibliothèque en dix classes, elles-mêmes subdivisées, etc.
Ce système est noté avec des chiffres, par exemple : 641.5 -> Livres de cuisine. Plus d’informations sur Wikipédia

Nous n’avions pas réfléchi au préalable à une méthode particulière pour notre prise de notes : nous nous sommes simplement réparti l’espace afin de travailler chacun sur une partie de l’étage.

A la fin de l’opération (cela a été assez rapide : un peu moins d’une heure), nous nous sommes retrouvés pour comparer les données collectées. Nous avons constaté que nous avions tous adopté à peu près la même méthode, qui nous semblait la plus logique. Dans un second temps, nous sommes revenus sur cette méthode, afin de la rendre la plus claire possible, compatible avec la partie technique (entrer les informations dans une base de données) et surtout reproductible pour les autres étages.

Une carte et des données

D’un côté, nous avons tracé un rapide schéma représentant l’étage vu du dessus, avec ses étagères et ses points de repère (porte d’entrée, poteaux, bornes informatiques).

Sans titre 4

D’autre part, il nous fallait représenter le contenu d’une étagère. Mais qu’est-ce qu’une étagère au fait ? C’est un meuble qui a deux faces, ces deux faces sont découpées en rayons et en colonnes, ce qui forme des cases.

Jelizawjeta_P._Bookshelf_1

Finalement, une étagère ressemble beaucoup à un tableau. Le plus simple est donc de ranger nos données sur papier dans des tableaux. Dans chaque case, nous avons indiqué les cotes que nous trouvions dans les cases des étagères.

Pour relier les tableaux à la carte, chaque étagère a un numéro, et ses deux faces s’appellent A et B.

Sans titre 3

Sur place, plusieurs questions se sont posées : jusqu’à quel niveau de détail est-il raisonnable d’aller ? (profondeur des cotes, position exacte du livre dans l’étagère, voire dans la case) Comment indiquer que plusieurs cotes différentes sont présentes dans une case ? Comment indiquer au contraire qu’une même cote s’étend sur des rayons, voire des étagères entières ? Comment gérer les cas spécifiques, les sélections, les périodiques, les BDs ?

Dans un premier temps, nous avons choisi de mettre de côté la Mezzanine (étage ados) et le rez-de-chaussée (étage enfants) car la disposition et la structure des rayonnages sont trop différents de ceux des autres étages.

Une première feuille de route pour cartographier

Lors d’une deuxième session, nous sommes retournés à la Bibliothèque pour tenter de cartographier les étagères de l’ensemble des étages. Le but n’était cette fois pas de relever les cotes, mais simplement de situer les étagères, et de noter combien de rayons et de colonnes chacune contenait.

cartobibli3

Nombre du bas : numérotation – nombre du haut : nombre de rayons en hauteur – longueur en petits carreaux : nombre de colonnes.

Nous avons entré ensuite ces informations dans un tableur, ce qui nous a permis d’arriver aux chiffres suivants : sur les cinq étages supérieurs de la bibliothèque se trouvent 135 étagères, soit environ 1000 rayons et un total de plus de 4000 cases !

A partir de ce premiers tableau, nous pouvons facilement générer et imprimer les tableaux vierges qui, associés à une carte de l’étage, vont permettre de continuer la collecte des cotes sur les autres étages de la bibliothèque. Avis aux bonnes volontés, si on organisait un atelier ? :)

Des idées d’applications

Au delà de l’idée de représenter de manière originale le plan des étages de la bibliothèque (tout est à inventer : un plan de métro ? des continents ? en 3D ?), nous avons envisagé la possibilité de représenter les informations de façon dynamique.

Par exemple, à la suite d’une recherche sur le catalogue, l’utilisateur apprend que le document qu’il cherche se trouve dans la bibliothèque des Champs Libres ou une bibliothèque de quartier. On peut alors imaginer lui suggérer la façon de s’y rendre, en transports en commun, puis lui indiquer exactement le chemin à parcourir sur place et dans les rayonnages pour trouver son bonheur.

maq

Ces informations pourraient également donner lieu à des jeux de piste, des statistiques…

Et ensuite ?

Ce petit projet est une très bonne expérimentation du principe de crowdsourcing, c’est à dire que les habitants peuvent aller directement chercher et construire les données. Il est facilement reproductible dans d’autres bibliothèques, d’autres lieux…

De notre côté, le travail n’est pas fini : nous souhaitons aller jusqu’au bout de l’idée et proposer des prototypes de représentations des données ou d’applications. Il nous reste donc plusieurs étapes :

  • Finir de collecter les cotes sur les autres étages
  • Entrer ces informations dans une base de données structurée
  • Relier les cotes entrées avec la classification Dewey afin de pouvoir manipuler des thématiques compréhensibles et non plus des chiffres (d’ailleurs, nous cherchons toujours une version brute des quatre premiers niveaux Dewey, en xml ou csv par exemple, si un de nos lecteurs a ça sous la main :) )
  • Concevoir et réaliser des visualisations avec ces données, en nous appuyant sur les idées et besoins des utilisateurs des bibli, mais aussi des bibliothécaires eux-mêmes
  • Renouveler l’expérience dans les autres bibliothèques de Rennes ?

Voilà pour un premier aperçu de nos préoccupations actuelles. Un évènement public sera organisé dans les prochains mois, et permettra aux personnes intéressées de voir l’avancement des projets et d’échanger avec nous et nos interlocuteurs à la Bibliothèque.

D’autre part, si vous souhaitez dès maintenant faire des remarques, poser des questions, ou nous aider sur les tâches listées ci-dessus, n’hésitez pas ! Toutes les idées sont les bienvenues, en nous contactant ou en laissant un commentaire ici-même.

A bientôt,

Léa

Sylvain (dit « l’Ingénieur »), Florian (Database Guru) et Benoît (let’s design this, fools)

 

Schémas et maquettes : Collectif Open Data Rennes, CC-BY.
Photo d’étagère : Jelizawjeta P., CC-BY, sur Wikimedia Commons

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

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).

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

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.

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

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.

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.