Le transporteur, l'élu... et le hacker !

Voici une petite fable. Elle se joue, aujourd'hui, aux antipodes... mais il est possible qu'elle s'exporte rapidement !

Nick Maher, c'est le Hacker, a réalisé deux applications sur iPhone : TrainView et TripView. Elles permettent, notamment, d'accéder, via son iPhone au tableau "départ arrivée" des trains de RailCorp. Pour se faire, il capture l'information sur le site de RailCorp sans accord.

RailCorp, c'est l'exploitant, a aussitôt porté plainte arguant que les informations lui appartiennent... que le système d'un amateur n'est pas fiable et qu'il est susceptible de donner des informations erronées... Bref, cette application ne correspond pas la "baseline" de RailCorp qui est : sûr, propre et fiable !

Jusqu'ici la fable est classique, elle s'est déjà jouée à Berlin par exemple... 

Nathan Rees, c'est l'homme politique, utilise des moyens de communications modernes, c'est même un utilisateur de twitter. Il a justement "twitté" un avis sur la dispute entre RailCorp et Nick Maher. Cet avis, venant du premier ministre de l'état, et relayé par le ministre des transports a valeur d'injonction...

RailCorp "négocie" un contrat de licence avec le développeur en faisant face à une pression politique et médiatique importante. Il est probable que cette licence ne sera pas limitée à Mick Maher et qu'elle devra être ouverte à d'autres. 
Il est probable que cette licence engage RailCorp sur un niveau minimal de fiabilité du service et sans doute aussi sur la pérennité de l'interface... Bref, cela va présenter un coût pour l'exploitant et une responsabilité.

Moralité pour les exploitants de transports publics ou les services techniques : prenez les devant et accueillez les développeurs avec des API ouvertes et un contrat de licence adapté ! 

From Bern with Wifi
Originally uploaded by Gary Winterboer

La pratique de la mise en place d'API permettant à des développeurs d'utiliser les informations produites par votre entreprise est un grand classique pour les entreprises technologiques comme Google, Yahoo ou Amazon

BART l'a déjà fait dans le domaine du transport public. Plus récemment le New York Time et le Guardian, l'ont fait dans le domaine de la presse. 
Ces trois initiatives ont été saluées par les observateurs et ont vocation à être rentables pour leurs entreprises. 

Moralité pour les Hackers : essayez d'avoir quelques "amis" sur FaceBook ou "suiveur" sur Twitter qui soient des élus locaux ou régionaux...

10 commentaires:

Colibri a dit…

C'est (agréablement) étonnant que ce soit vous qui relayez cet appel pour des "API ouvertes". Quand l'on sait que Navitia a décroché le marché de nombre de calculateurs multimodaux des régions. Et que Navitia ne propose aucune API non plus..
Mais tout ceci a déjà été évoqué dans les commentaires de ce fil notamment.

Vous devez pensez que vous n'avez pas assez de concurrence alors :-)

Yann a dit…

Cela n'étonne que ceux qui ne me connaissent mal !

NAViTiA offre bien des api ouvertes, la décision de permettre à des tiers de les utiliser appartient à nos clients : Conseil Régionaux, Généraux ou exploitants de transport public.

Ce sont eux qui disposent des droits sur les données et le services que nous produisons pour eux.

Il est vrai qu'en général, ils ne souhaitent pas mettre cette facilité à disposition des projets tiers... Ma conviction est que cela viendra !

Pour ce qui est de la concurrence elle est vive dans ces intentions au moins.

En saluant un lecteur et un contributeur fidèle !

Anonyme a dit…

Belle histoire en tout cas,
espérons qu'il y aura des initiatives similaires chez nous, il y a des élus français aussi ouverts (au sens web2 ;-) que leurs homologues australiens.
Je pense à Michel Briand à Brest parce que j'ai lu récemment un article à son sujet, mais il y en a sûrement beaucoup d'autres.
Il faudrait leur parler de opentransitdata et ce genre de choses ;
Le mot hacker est parfois confondu avec celui de pirate / déliquant informatique, mais évidemment rien à voir, attention au vocabulaire qui fait peur!
cordialement
pat gendre, cete med

Anonyme a dit…

D'où vient l'idée que les données théoriques appartiennent à un industriel ou à une collectivité. La PREDIM l'a d'ailleurs démontré dans une étude, l'accès aux données (payé par le contribuable) correspond "au mode d'emploi du service".
Alors pourquoi attendre ? mettez-vous en conformité avec les lois européennes et donnez accès aux données !

Yann a dit…

La question de la propriété des données est effectivement tranchée. Mais cela n'a pas permis de faire évoluer la situation. Cette approche juridique de la propriété des données est très théorique et elle élude la question des modalités pratiques de mise à disposition. D'où la proposition faite dans mon article : ouvrez les API !

Colibri a dit…

"ouvrez les API !"

J'ai bien peur que (certains) "hackers" soient plus gourmands et demandent bel et bien l'accès aux données brutes.
Car pour calculer un itinéraire et/ou faire des combinaisons par exemple, travailler sur le "graphe entier" offre bien plus de possibilités.
Ah ces informaticiens, jamais satisfaits :-)

Anonyme a dit…

Ouvrir un API ne constitue que la moitiée du travail, l'autre moitiée consiste à créer un écosystème de développeurs qui seront s'approprier l'API et construire des applications autour.
Programmableweb.com (la "bible" sur le sujet) recense 1200 API et la très grosse majorité reste orpheline de mashups.

Sur le sujet particulier du transport public, il est clair qu'à un jour les données théoriques seront disponibles par contre j'attends vraiment de voir pour les données temps-réel car les exploitants les considèrent encore fortement comme des données privées d'exploitation.

Dernier point, NAViTiA est fortement marquée par la vision "exploitation" ce qui nuit à l'accessibilité de l'API et de ces données sous-jacentes. En imaginant que CanalTP obtienne les droits de diffusion des données, je souhaite bon courage aux futures développeurs pour comprendre les subtilités du RER C issues des données du STIF (par exemple).

Yann a dit…

Les deux derniers points de Colibri et Olivier font progresser le débat vers la question du design des API. Des API peuvent permettre un accès "détaillé" à des données brutes.

Elles peuvent aussi rester très globales et masquer la complexité sous jacente des données, de leur date de validité, de leurs liens, souvent obscurs avec les processus de production...

Les API NAViTiA sont effectivement plutôt dans la première catégorie. Il s'avère, comme le dit Olivier, que leur intégration nécessite un certain investissement.

Du coup nous élaborons aussi des API plus "synthétiques" et plus faciles à utiliser.

Anonyme a dit…

"Plus facile à utiliser" cela signifie masquer de la complexité et mettre de l'intelligence dans la réponse renvoyée !

Canal TP ou autre est sans doute en mesure d'avoir une vision avertie et légitimé de l'IV mais laissons donc les hackers s'approprier les données brutes, faire des erreurs, les corriger... Bref apprendre le "métier" et proposer, à leur tour des solutions innovantes.
L'innovation est entre toutes les mains !

Julien

Anonyme a dit…

"Plus facile à utiliser" cela signifie masquer de la complexité et mettre de l'intelligence dans la réponse renvoyée !

Canal TP ou autre est sans doute en mesure d'avoir une vision avertie et légitimé de l'IV mais laissons donc les hackers s'approprier les données brutes, faire des erreurs, les corriger... Bref apprendre le "métier" et proposer, à leur tour des solutions innovantes.
L'innovation est entre toutes les mains !

Julien