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

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.