OpenData : un exemple simple pour évoquer l’évidence du concept

WIMT  est un mashup cartographique (une application web qui utilise un service 2.0 comme fond de carte pour y placer des données).

Développé à l’occasion du concours Challenge Mappy, WIMT rend compte sur une « Mappy Map » de la position des RER des lignes A et B en temps « semi-réel ».

Le résultat est très séduisant, où l’on voit évoluer le ballet des trains,  mais pourquoi parler de « temps semi-réel » ? Une explication s’impose (source : http://www.developpez.net/) :

« WIMT est capable de gèrer les horaires à la seconde près, malheureusement les informations récupérées sur le site Internet de la RATP ne mentionnent que les temps à la minute. « Du coup, il arrivait qu’un train se retrouve dans deux gares proches en même temps », raconte Vincent.

Il a fallu aux deux développeurs faire preuve d’astuce pour interpoler les temps de passage aux gares. Leur application Java remplissait les vides (par exemple, certains trains ne s’arrêtent pas à toutes les stations, le PDF ne mentionne donc pas l’heure à laquelle ils y passent), mais ce soucis de temps arrondi à la minute leur a demandé beaucoup de travail de correction.

En clair : les développeurs de WIMT ont réussi à donner forme à des données non prévues pour cela, et c’est un travail d’ingéniosité algorithmique qu’on ne peut que saluer.

Mais l’on comprend également que leur application ne rend pas compte de la position « réelle » (actualisée) des trains ;  uniquement de leur position théorique à partir des fiches horaires.

Les deux jeunes gens espèrent aujourd’hui obtenir des informations supplémentaires de la part de la RATP : les horaires à la seconde près, mais aussi les retards, les accidents, etc… « C’est techniquement faisable avec l’API de Mappy, il ne manque plus que leur collaboration, et celle de la SNCF aussi pour d’autres lignes. WIMT peut s’étendre à d’autres modes de transport : métro, trains, bus, etc… ».

La contrainte juridique est ici lourde. Un des développeurs  confie :

« Notre principal regret est qu’il n’existe pas encore de données de transport publiques en opendata a Paris (et même en France), permettant d’avoir le « vrai » temps réel ».

Du coup le choix des PDF comme sources s’imposait :

« les données collectées [n’étant ainsi] en aucun cas protégées par un copyright. Ce qui n’aurait pas été le cas en parsant le site ratp afin d’obtenir les données en temps réels. »

En clair : des données sur la position en temps réel des trains sont disponibles, ce sont des données relatives à des lignes de transports publics, ces derniers étant des services publics, et ces données sont détenues (dans ce cas) par des entreprise publiques.

Pour autant des développeurs qui auraient un peu de talent et d’imagination, seront pénalisés car ils ne pourront pas y avoir accès. Et de fait nous le sommes alors également, pénalisés, en creux, nous autres usagers de ces services publics.

Loin de moi l’idée de sous-entendre que la réponse au problème juridique posé, à supposer qu’il ne soit que juridique, devrait être simple. Simplement qu’on est en droit de s’interroger, en particulier quand on regarde ce qui se passe ici ou là.

Une recherche sur  « open data données de transports publics » ne laisse en effet aucun doute, sur le fait qu’il s’agit d’un sujet d’actualité (et plus largement cf. la fréquence du hashtag #opendata sur Twitter).

Quel est l’enjeu ? En France c’est Rennes Métropole qui semble avoir ouvert la voie de l’opendata pour les données publiques territoriales (à noter que le périmètre dépassera à terme les données de transports publics ).

L’opérateur technique local In-Cité a posé le constat suivant  (source : Regards Citoyens.org) :

Les collectivités locales ne seront pas capables de financer des applications web ou mobiles pour toutes les plateformes ou tous les usages. De plus, lorsqu’elles les financent, ces applications ne correspondent souvent pas aux usages attendus par les citoyens. Pourquoi donc ne pas laisser ces citoyens technophiles développer ces applications en leur fournissant les données ?

L’enjeu n’est donc pas uniquement idéologique comme le préfixe ‘open’ pourrait le laisser penser, mais renvoie bien à des questions d’innovation et des enjeux économiques. Qui plus est à une innovation tirée par les usagers.

Du coup, adossé à des enjeux de développement économique, et soutenu par les usagers (à la fois en R&D amont, mais aussi en raison d’évidents bénéfices en terme de praticité), le concept d’opendata pourrait bien alors, en tant que revendication pour plus de visibilité sur les données d’intérêt général, ouvrir des perspectives en matière sociétale, des plus intéressantes.

Derniers liens pour ne pas clore un aussi vaste sujet, et constater que la problématique soulevée ici déborde de loin les frontières de l’hexagone : la ville de Londres permet dors et déjà aux développeurs d’obtenir pour  leurs applications des données étendues relatives à ses transports publics (on parle d’interroger des APIs : ici c’est data.london.gov.uk/apibeta). Londres mais également Vancouver, New-York ou encore San Francisco ; du coup Paris commence à se pencher sur la question.

Et puis un exemple pour montrer que l’imagination des développeurs n’a pas de limites – et tant mieux : la montre qui donne l’heure de passage des trains en temps réel ; c’est à San Francisco que ça se passe et là comme ailleurs, les contraintes à lever ont été les mêmes ; mais nulle doute que l’Histoire est en marche.