Le lab : le conseil « les mains dans la donnée »
Pour moi, le conseil repose sur une conviction : on comprend mieux un écosystème quand on a soi-même construit quelque chose avec. « Wait a minute » est né de cette envie – un petit assistant de trajets qui découvre et affiche les prochains passages de bus et de métro aux arrêts que j’emprunte, branché sur les API publiques d’Île-de-France Mobilités (la plateforme PRIM) et sur les jeux de données ouverts franciliens.
C’est un objet modeste mais qui m’a permis de me plonger au coeur de la donnée, d’en comprendre la structure, la complexité,, les qualités et défauts. Après avoir piloté à Île-de-France Mobilités la stratégie d’investissement dans les systèmes d’information voyageurs et l’ouverture des données, et confronté désormais à des besoins équivalents pour d’autres territoires, j’ai voulu reprendre la matière première brute – du point de vue de celui qui la consomme. Voici quelques apprentissages.
Une seule vérité, plusieurs identifiants
Le premier obstacle n’est pas la donnée elle-même : c’est sa mise en cohérence. Un même arrêt existe sous plusieurs identifiants selon la source – identifiant de zone dans l’open data, identifiant dans le référentiel de calcul d’itinéraire, identifiant dans le flux temps réel, identifiants de quai. Aucun n’est directement l’autre. Les libellés varient également d’une source à l’autre pour un même point d’arrêt. Construire un service impose donc de bâtir et d’entretenir sa propre table de correspondance – un travail invisible, jamais valorisé, et pourtant déterminant pour la fiabilité perçue.
Une fois mis en qualité, les référentiels ouverts – liste des arrêts, dessertes, couleurs officielles des lignes, position géographique et leur déclinaison en données topologiques et en plans de transport – sont une ressource précieuse : ils permettent d’implémenter des fonctionnalités comme l’autocomplétion, la géolocalisation, l’affichage aux bonnes couleurs. Les mobiliser, c’est concevoir un service riche, avec néanmoins la préoccupation permanente de la frugalité des appels aux API, particulièrement sensible pour une Région qui fait face à de très gros consommateurs (Google, Apple, Citymapper…).
Au delà de la qualité, la documentation. Un détail, vécu : une fonction de recherche censée filtrer sur un préfixe s’est révélée sensible à la casse – une saisie en minuscules ne renvoyait rien. La qualité perçue d’un référentiel ne dépend pas que de la donnée : elle dépend aussi de l’outil d’accès, de sa documentation et de ses pièges.
Interpréter le temps réel demande du métier
C’est le cœur de l’exercice. La donnée « temps réel » francilienne est hétérogène – en couverture, en fraîcheur, en fiabilité – et il faut le savoir pour concevoir un service honnête. Quelques situations rencontrées :
- Couverture inégale. Tous les réseaux ne diffusent pas de temps réel, et ceux qui le font ne le font pas partout ni sur toutes les lignes. Encore faut-il distinguer une ligne sans flux d’une ligne… qui ne circule pas ce jour-là (travaux programmés) : une donnée absente n’a pas la même signification selon le contexte.
- Du théorique déguisé en temps réel. Sur certains réseaux, seul le véhicule en approche est réellement suivi ; les passages suivants sont « complétés » à l’horaire théorique et réémis dans le flux comme s’ils étaient observés. Le seul indice fiable est alors la fraîcheur de l’horodatage d’enregistrement – pas les secondes affichées, qui peuvent être figées.
- Doublons. Une même course peut être publiée sous deux identifiants – un classique, un synthétique horodaté. L’usager voit alors « deux bus » à la même minute. Il faut les fusionner.
- Incohérences non résolues. Un départ annoncé supprimé à son terminus mais « à l’heure » quelques arrêts plus loin : la donnée se contredit, et le service doit arbitrer plutôt qu’afficher les deux.
La conséquence produit est simple : ne jamais présenter une estimation incertaine comme une certitude. J’ai introduit des statuts nuancés – « théorique », « information à confirmer », « vient de passer » -, réservé le clignotement d’un passage imminent aux seules données confirmées, et tenu une note interne recensant les défauts observés, source par source, pour les opérateurs des réseaux que j’ai étudiés.
En réalité, plonger dans ces données, c’est photographier un écosystème où les systèmes d’aide à l’exploitation, l’agrégation et la normalisation des flux sont d’une maturité inégale d’un opérateur à l’autre. Ce constat n’a rien d’anecdotique : c’est précisément ce qui se pilote par les spécifications, les contrats d’exploitation et les appels d’offres, mais aussi par un travail constant d’examen et d’exploitation de la donnée, qui, pour un gros réseau urbain ou un réseau régional, peut nécessiter des ressources spécialisées qui interviennent quotidiennement en lien avec les fournisseurs, dont les opérateurs, les réutilisateurs, les usagers et les territoires.
Penser en usager, pas en réseau
Le prototype a été l’occasion de dérouler quelques partis pris qui se déclinent dans la conception d’un service digital pensé pour l’usager du réseau :
- afficher par arrêt, puis par ligne, puis par sens – l’inverse de la logique d’exploitant ;
- bannir le vocabulaire interne (« aller », « retour ») au profit de la destination réelle, seule information qui parle à l’usager ;
- assumer deux régimes distincts : « je pars maintenant » (temps réel) et « je planifie » (horaires théoriques à x jours), qui ne répondent pas au même besoin.
Enfin, la frugalité : une API, même ouverte, a un coût – pour celui qui l’expose comme pour celui qui l’appelle. Le prototype adopte une approche économe (cache partagé entre visiteurs, interrogation du seul écran regardé, arrêt du rafraîchissement quand la page n’est plus au premier plan). Un bon réflexe de réutilisateur : la sobriété d’accès fait partie du cahier des charges.
