juliendelabacaInformation en temps réel, information prédictive, open data, open Innovation… Tout cela est bien séduisant sur le papier. Mais au quotidien, comment gérer l’information voyageurs pour offrir aux citoyens un service tout simplement fiable ? Laissez moi vous embarquer en gare d’Hendaye, dans le sud-ouest de la France, ou la réalité est beaucoup moins sexy que la théorie.
Proposer du multimodal
La gare d’Hendaye est une petite gare (classée C par Gare & Connexions !). Multimodale, elle l’est comme beaucoup d’autres, mais elle a aussi ceci de particulier qu’elle est transfrontalière. Elle est donc desservie par plusieurs offres de transports : des autobus, autocars… mais aussi par un train, qui a son propre opérateur, sa propre infrastructure et permet de traverser la frontière jusqu’à San Sebastian. Lorsque j’ai commencé à travailler sur le projet Transfermuga, j’ai identifié la gare d’Hendaye comme un lieu d’expérimentation idéal. Pourquoi ? parce que dans cette petite gare, il n’existait quasiment rien pour informer les usagers et que l’intermodalité était très mal organisée. Mon premier défi a donc été de faire installer par la SNCF (Gare & Connexions) un écran, qui permettrait d’afficher les horaires de l’ensemble des modes de transports desservant la gare, y compris le train reliant Hendaye à San Sebastian. En fait, il s’agissait tout simplement de fournir une information multimodale (théorique).
La complexité de la gouvernance
C’est là que les ennuis ont commencé. Bien avant la question de la donnée… oups, pardon, de l’existence de la donnée, de sa qualité, de son actualisation… s’est posée la question du support, de son intégration et de son modèle économique. Et là, je vais peut être vous surprendre, mais la SNCF m’a beaucoup aidé. Evidemment, quelques mois de négociation ont été nécessaires… Mais, j’ai pu obtenir que Gare & Connexions installe en gare un totem d’information voyageurs, sans rien débourser. Et j’ai eu la chance de bénéficier d’un dispositif d’un nouveau genre : un immense totem équipé d’un plan statique et de deux écrans pour y intégrer de l’info voyageurs. Génial, le plus dur était fait… enfin c’est ce que je croyais. Commençait alors la seconde étape : récupérer les données permettant d’afficher les horaires des autobus, autocars et train transfrontalier.
La difficulté d’accéder à la donnée transports
Entre le « GO » de la SNCF et l’installation réelle du totem, je me disais que je disposais de suffisamment de temps pour m’occuper de tout cela. Evidemment, c’était sans compter sur le fait que chaque donnée provenait d’une autorité de transports différente, et je ne vous parle pas des process différents de part et d’autre de la frontière. J’ai donc réfléchis à la meilleure méthode pour récupérer les données de manière centralisée, actualisée, et gratuite ! Bingo, l’Open Data. Cela sonnait comme une évidence. Le seul problème était qu’à part les données du train transfrontalier, aucun jeu de données n’était ouvert et donc disponible !!! J’allais donc mettre beaucoup de temps pour accéder aux jeux de données français. Mais par chance, j’ai en parallèle piloté un projet de calculateur d’itinéraires transfrontalier ainsi qu’une vaste dynamique d’open data en Pays Basque. Cela m’a permis dans un premier temps d’avoir accès aux données et de les envoyer manuellement à la SNCF, à chaque changement de service. Certes, cela n’était pas parfait, mais c’était un début. Quelques mois après avoir débuté ma lutte pour la donnée, je gagnais une première bataille et l’écran affichait les horaires des bus, des cars et des trains transfrontaliers (wahou !!!).
L’adaptation d’une donnée générique
Rapidement, j’ai compris qu’afficher les horaires n’était qu’une étape. Un premier problème s’est posé : il fallait adapter l’affichage des horaires au lieu. Afficher des horaires sur une application est une chose, mais dans une gare c’est un peu différent. Il s’agit de partir du postulat que cette dernière est le point de départ de tous les trajets. Il s’agit aussi d’adapter l’information à la spécificité du terrain, là est la plus value de ces écrans multimodaux. Dans notre cas il s’agissait par exemple pour le train transfrontalier d’afficher comme destination « San Sebastian » (beaucoup plus compréhensible par les touristes), et non pas « Lasarte » comme indiqué dans le fichier GTFS. C’est la que j’ai compris qu’il nous faudrait certes accéder aux données, mais aussi les adapter au contexte local, et ce à chaque mise à jour. Et à ce stade, il était trop compliqué de mettre en place des routines. Nous avons donc débuté manuellement.
Open Data et mutualisation ne suffisent pas
Une fois les précédents problèmes résolus, je n’en avais pas terminé avec les difficultés. La SNCF, pour améliorer son processus d’actualisation, m’a rapidement indiqué qu’il serait plus facile d’avoir un seul point d’accès pour les données. Une demande légitime. Comme la mutualisation faisait partie du coeur du projet Transfermuga, j’ai pu répondre facilement à cette requête. Je possédais les données des trois opérateurs et l’ouverture progressive de ces données m’a aussi permis de communiquer une seule URL à la SNCF pour accéder aux données. Encore un problème de réglé ! Désormais, j’avais accès aux données, je pouvais les proposer actualisées, avec un point d’accès unique. Néanmoins, c’était entre temps la donnée elle même, sa constitution et sa qualité qui avaient évolué… et pas vraiment dans le bon sens. D’un coté, l’opérateur du train transfrontalier avait décidé de modifier la nomenclature de ses fichiers. De l’autre, la gouvernance en France avait changé, le nom des réseaux aussi et la production des jeux de données était devenue plus compliquée. Pour couronner le tout, même du coté des données dont nous maitrisions la gouvernance, nous observions des doublons dans l’affichage de plusieurs destinations sur l’offre de cars, qui pouvaient induire en erreur les usagers (un problème de gestion des calendriers dans le GTFS)… bref rien n’était gagné dans l’exploitation de la donnée en elle même !
La nécessité d’un management global… mais personnalisé !
J’ai progressivement compris que le plus complexe serait non pas l’approche technique, mais le management de la donnée. Il me fallait donc réfléchir à un processus d’actualisation propre et adapté à cette situation bien particulière. Et avec le recul, un élément est essentiel pour assurer ce travail global : le facteur humain. Le transport est un métier spécifique. La gestion d’une gare tout autant. La gestion de la donnée encore plus. Pour pouvoir avancer, il est donc essentiel de composer entre un (ou plusieurs) spécialiste(s) de chacun de ces métiers. C’est LA solution, et elle peut s’appliquer dans d’autres cas. Cela coûte un peu d’argent, mais constitue une sécurité pour pérenniser un dispositif d’informations voyageurs. Parce que générer une belle API et compter dessus pour actualiser ses données est une chose. Gérer le quotidien d’un affichage multimodal (et donc multicanal) dans une gare est un tout autre job.
Ce qui se cache derrière ce beau totem (le bébé fait tout de même 800 kg) censé afficher des informations sur les prochains départs des bus, cars et trains est plus complexe qu’il n’y parait. Dans la réalité, ce morceau de tôle oblige à se confronter à de nombreuses problématiques, la plus importante était celle du management de la donnée et par conséquent de sa gouvernance ! J’ai dans ce projet assuré le lien entre le gestionnaire de gare (Gare & Connexions), le data manager (Okina), les opérateurs (Transdev et Euskotren), et les AOT. Ce rôle de pivot est essentiel, même si chronophage… et encore, j’ai eu la chance de travailler uniquement avec des personnes de bonne composition ! Je n’ai pas encore trouvé de solution miracle, mais une chose est sure, il faut des personnes capables de comprendre les métiers, le territoire et ses spécificités.
(…) Ce matin, je passais par la gare d’Hendaye. Le totem d’information voyageurs affichait deux écrans noirs. Echec ou dure réalité ? Je ne le sais pas (encore).
juliendelabaca
