Episode 3 : Services vélo et usages : pourquoi passe-t-on du GBFS au MDS ?

Episode 3/5 – Revenir sur les épisodes précédents ici 
Pas besoin de vous faire un dessin, le vélo (et ses cousines les trottinettes) fait un tabac dans l’hexagone ! Bénéficiant d’un soutien populaire et d’un regard de plus en plus intéressé des élus, il fait émerger de nombreux projets d’infrastructures et génère un foisonnement d’offres de services. Pourtant, malgré ce succès, son volet “numérique” reste, hormis quelques rares exceptions, plutôt à la traîne. Il y a une raison essentielle qui explique cela : la “donnée vélo” est un sujet encore très peu maîtrisé par les acteurs de la mobilité quels qu’ils soient. Pourquoi ? Quels sont les acteurs qui se penchent sur le dossier ? A quoi peut-on s’attendre demain ? Quels sont les défis à relever ? Notre investigation en une série de 5 épisodes…

Tous les spécialistes vous le diront : “pour répondre à toutes les nouvelles questions posées par l’évolution du secteur, il y a maintenant le MDS, qui signifie Mobility Data Specification. C’est une réflexion beaucoup plus jeune que le GBFS, car liée à l’arrivée des nouveaux opérateurs en free floating. L’idée est de permettre à la puissance publique d’accéder à des données qui peuvent éclairer la gestion de la circulation en temps réel et le pilotage des politiques publiques de mobilité.

Ce sont les nouvelles offres en free floating que vise le MDS avec des enjeux de régulation - Ici l'exemple de zones régulées à Bordeaux, 2019
Ce sont les nouvelles offres en free floating que vise le MDS avec des enjeux de régulation – Ici l’exemple de zones régulées à Bordeaux, 2019
C’est la municipalité de Los Angeles avec la collaboration de Santa Monica, San Jose et Austin, qui a produit le MDS. Mais désormais, il est utilisé par plus de 50 villes.

Et dans le détail ? Le MDS, c’est en quelque sorte une extension du GBFS, ou plutôt l’idée de le compléter pour faire face à de nouveaux défis. C’est donc un ensemble d’API, qui inclut notamment le GBFS. Le MDS permet aux municipalités et aux opérateurs de communiquer : il est bidirectionnel à l’inverse du GBFS. Les deux premières API sont basiques : l’une se nomme “provider”, et l’autre “agency”. D’un côté l’une sert au fournisseur de solution de mobilité à envoyer des données en temps réel sur ses véhicules aux autorités de transports (NB : on les appelle des “agences” aux Etats Unis). L’autre sert aux autorités de transports à demander des données historisées au fournisseur de solutions : état du véhicule, origine, destination… Une troisième API, baptisée “policy” regroupe les règles / la réglementation locale. Les fournisseurs de services l’interrogent pour savoir si ces dernières pourraient affecter le fonctionnement de leur service de mobilité ou pour en déterminer la conformité. 

Schéma fonctionnel du MDS
Schéma fonctionnel du MDS

Pour mieux comprendre la complémentarité entre les deux approches…

GBFS MDS
  • créée pour l’information en temps réel pour les utilisateurs de vélos partagés 
  • créée pour promouvoir la pratique du vélo partagé, 
  • en lecture seule, 
  • faite pour connaître la disponibilité et la localisation des vélos 
  • disponible en open data
  • spécifique aux micro mobilités 
  • ne donne pas accès aux informations sur les véhicules : maintenance, plus de batterie… 
  • ne donne pas accès à un historique d’usage, 
  • et uniquement bottom-up 
  • créée pour les autorités de transports, pour manager les services de free floating, 
  • propose des données en temps réel, et historisées en intégrant les trajets, ainsi que la disponibilité des véhicules, 
  • faite pour la régulation, la maintenance, le contrôle, la planification ou encore la sécurité, 
  • une extension du GBFS, 
  • open data uniquement pour la partie GBFS, 
  • données personnelles identifiables,
Pour “piloter” le MDS, les américains ont créé la Open Mobility Foundation (OMF), avec un “board” assez similaire à celui de la NABSA. L’objectif est, au delà du MDS, de créer des outils de dashboarding pour mieux piloter les offres partagées en tous genres, le tout en open source. 

Mais surtout, qu’en pensent les réutilisateurs ? Cela dépend quel est leur coeur de business, mais globalement, ils voient plutôt ce standard d’un bon oeil. En effet, la plupart des acteurs qui se positionnent sur le sujet veulent d’une part aider les autorités publiques à manager les nouveaux services “plus agiles” qui arrivent sur le marché. D’autre part, ils ont la volonté de pouvoir intégrer toutes les nouvelles formes de mobilité. Enfin, ils veulent être en mesure d’intégrer toutes les nouvelles fonctions offertes par ces nouvelles solutions. Le MDS répond donc d’autant plus à leur vision. 

Au final, que retenir ? D’abord que le MDS complète très bien le GBFS qui lui a été créé pour informer les utilisateurs. Il donne beaucoup plus de latitude quant aux données d’usage et permet un suivi et une régulation des offres, particulièrement en free floating. Néanmoins, malgré tous ses points positifs, il s’agit de le tester progressivement en France, pour savoir s’il s’adapte au contexte local. Il s’agit également, et c’est évidemment lié, de réfléchir aux meilleurs outils pour l’exploiter le plus finement possible. Enfin, ne nions pas le fait que pouvoir “identifier” facilement des données personnelles n’est pas sans poser de questions. C’est au coeur de notre épisode n°4 de demain. 

You May Also Like