September 2, 2021 12:55 pm

GBFS et les données de mobilité partagée : des politiques publiques au service des villes européennes

Comment le GBFS soutient les villes dans leurs politiques en faveur d’une mobilité durable et fluide

(Ce guide est disponible en portugais, espagnol et anglais.)

Résumé

Une politique publique de mobilité partagée ne se conçoit qu’avec l’assurance d’avoir un accès aux données de mobilité. Cet accès doit être public pour deux raisons : s’assurer d’une confiance totale dans les offres de mobilité et développer l’usage de la mobilité partagée. Bien rédiger les règles encadrant les politiques publiques de mobilité est le meilleur moyen de s’assurer que les données de mobilité sont à la fois exactes et accessibles.

Ce document est à destination des personnes chargées de la gestion des offres de mobilité partagée au sein des villes et autorités locales, qu’elles rédigent les appels d’offres ou en régulent les opérations. Ce document permet, d’une part, de comprendre comment le GBFS soutient le développement de solutions de mobilité durables et fluides, et, d’autre part, comment bénéficier de l’effet de levier induit par les données ouvertes grâce à des réglementations publiques écrites de manière concise et en faveur d’une plus vaste adoption de la mobilité partagée. Ce document est avant tout destiné aux villes européennes. Une version adaptée aux villes nord-américaines a été publiée en juin 2021, elle est consultable ici (en anglais).

Comment le GBFS soutient les villes dans leurs efforts vers une mobilité plus durable

Le GBFS facilite la découvrabilité et l’usage de la mobilité partagée pour tous les voyageurs.

Depuis sa création en 2015, le GBFS est devenu le standard de facto de la mobilité partagée. Cette spécification est désormais utilisée dans plusieurs centaines de villes réparties dans plus de 45 pays dans le monde.

Les chargés de régulation devraient exiger des API GBFS publiques lorsque sont accordées des concessions de mobilité partagée. Le GBFS est un langage commun qui permet à tous les opérateurs de mobilité partagée de transmettre l’état de disponibilité de leur service à l’ensemble des voyageurs. Le GBFS contient des informations sur les véhicules (vélos, trottinettes, scooters et voitures), les stations et bien plus encore :

La disponibilité et l’emplacement des véhicules et des stations ;
Les caractéristiques des véhicules proposés à la location (type de motorisation, distance qu’il est possible de parcourir avec la charge restante) ;
Les zones géographiques dans lesquelles s’appliquent des règles données de vitesse, stationnement et d’interdiction d’usage.

Ces données sont utilisées à la fois dans les planificateurs de trajet et les applications de Mobilité en tant que Service (Mobility as a Service – MaaS) afin d’offrir aux utilisateurs toutes les informations dont ils ont besoin pour choisir leur solution de mobilité partagée. Des API GBFS publiques sont la clef de voûte d’une meilleure intégration de la mobilité partagée aux transports en commun. Elles assurent la couverture du premier et dernier mètre à parcourir, ou encore rendent possible le choix d’une expérience de mobilité multimodale complète qui permet d’éviter la conduite de véhicules motorisés privés.

En outre, le GBFS permet aux villes et autorités locales de bénéficier d’un standard pour recueillir, analyser et comparer les données générées par les systèmes de mobilité partagée. Leur développement récent s’est traduit par la production d’une très vaste quantité de données de mobilité. Ces dernières sont devenues essentielles pour contrôler et réguler les opérateurs de mobilité. En effet, elles permettent de comprendre les impacts de la mobilité partagée sur la sécurité routière mais également leur apport dans la construction d’une mobilité plus inclusive, plus responsable, plus durable et dans tout autre enjeu public. Un accès public aux données de mobilité partagée va également dans le sens d’une meilleure transparence et une responsabilisation des opérateurs alors qu’ils occupent l’espace public.

Le GBFS a été conçu spécialement pour permettre un usage public de la donnée. Pour que les API GBFS soient réellement publiques, elles doivent être mises à disposition en ligne sans restriction telle qu’une clef API, un jeton ou toute autre méthode d’authentification. Les flux de données contenant des informations sensibles et requérant une authentification ne peuvent pas se substituer aux API publiques.

Le GBFS permet à toutes les parties d’échanger des données avec l’assurance d’un accord sur ce qu’elles représentent. Tel un dictionnaire, chaque terme de la spécification comporte une définition et des règles d’usage. Le GBFS est une spécification pour des données en temps réel qui décrit l’état actuel d’un système de mobilité. Le GBFS ne permet pas et n’est pas conçu pour des données historiques telles que les déplacements des usagers ou encore les données de maintenance.

Le GBFS réduit la charge administrative des villes, celle de conformité des opérateurs.

Au contraire de solutions ad-hoc créées par le passé pour le partage de données, la standardisation des données de mobilités est bénéfique à la fois aux villes et aux opérateurs. En effet, la standardisation permise par le GBFS favorise l’essor d’un marché de logiciels de gestion des données et des services y afférant, ce qui nourrit la création de nouvelles solutions et l’amélioration constante de celles qui existent. Ces produits et services sont autant d’outils d’aide à la gestion et à la décision que peuvent utiliser les pouvoirs publics en charge des solutions de mobilité, en s’appuyant sur le GBFS.

Des politiques publiques s’appuyant sur la standardisation des données ouvertes permettent d’éviter une situation de dépendance, dans laquelle les villes sont tributaires d’outils et de formats propriétaires développés par leurs fournisseurs. Des données ouvertes et standardisées renforcent le pouvoir de négociation des villes, leur permettant de changer d’opérateurs dès que leur niveau de service n’est plus satisfaisant.

Pour les opérateurs, la standardisation signifie la fin d’un patchwork de réglementations leur imposant de fournir des données différentes dans des formats divers et cela dans chaque ville dans laquelle ils opèrent. Dès lors, la standardisation assure à l’ensemble des opérateurs un alignement des contraintes auxquelles ils doivent se plier avec des demandes en données claires, précises et reproductibles. Le GBFS leur apporte aussi la possibilité d’étendre leur zone de chalandise avec une intégration facilitée dans des applications tierces. Développé sur la base d’un consensus, le format ouvert de données qu’est le GBFS tient compte des avis des opérateurs comme des villes dans ses évolutions. Sa documentation complète et les outils y afférant sont mis à disposition des villes comme des opérateurs pour en faciliter l’usage et l’adoption.

Recommandations

Que le GBFS figure dans les appels d’offres.

Votre appel d’offre devrait exiger une API GBFS publique et détailler les attentes que vous avez pour que la donnée fournie réponde aux objectifs de votre politique publique.

Éléments de langage suggérés

Exigences de partage des données

Une API publiquement accessible qui soit en conformité avec le General Bikeshare Feed Specification (GBFS) dont la version actuelle est disponible au https://github.com/NABSA/gbfs/.
L’API GBFS doit être mise à la disposition du public sur Internet et sans exigence d’authentification.

Déterminer les données à exiger pour une politique exhaustive.

À mesure que l’industrie de la mobilité partagée évolue, le GBFS en fait tout autant pour inclure de nouvelles fonctionnalités, capacités et services. C’est pourquoi vous pouvez lire ‘ou son équivalent’ dans les éléments de langage et descriptions du GBFS reprises ci-dessous. En effet, exiger d’un opérateur de mobilité partagée qu’il mette à disposition des données publiques en GBFS n’est pas suffisant pour s’assurer que ces données répondent à des exigences réglementaires ou autres.

Lorsque des politiques publiques de données sont développées, il est conseillé de demander leurs avis à des experts impliqués dans l’implantation des programmes. Ils peuvent faire partie de vos départements informatiques, de régulation et/ou de marchés publics ou encore se trouver au sein des équipes de développement de vos outils d’analyse de données.

Le GBFS a été conçu pour répondre aux besoins d’une grande variété de plateformes de mobilité et de cas d’usage, allant du vélo-partage historique sur la base de stations aux solutions de mobilité en libre-service que ce soit des vélos, des trottinettes ou tout autre véhicule. La spécification se compose de treize fichiers (ou terminaux) qui contiennent chacun des données de mobilité différentes. Certains de ces fichiers et leurs champs associés sont obligatoires pour être en conformité avec la spécification alors que d’autres sont optionnels. La liste des éléments requis dépend intrinsèquement de l’offre de mobilité retenue. Quant aux éléments optionnels, ils répondent à des besoins et cas d’usage spécifiques. Les villes ont toute liberté d’inclure ces derniers dans leurs réglementations afin de fournir des informations supplémentaires à leurs usagers et/ou en soutien à leurs politiques publiques et besoins.

Présentation des fichiers GBFS

Nom des fichiers	Requis ou non – Description
gbfs.json	Requis – Ce fichier regroupe les liens (URL) des autres fichiers publiés formant l’API GBFS. Pour une publication publique, un lien vers ce fichier doit être publié sur le site de l’opérateur, celui de la ville et/ou sur un portail de données ouvertes.
gbfs_versions.json	Optionnel – Ce fichier énumère l’ensemble des fichiers publiés par l’opérateur par version. Le maintien de fichiers dans une version antérieure au GBFS actuel peut éviter des ruptures de service dans certaines applications.
system_information .json	Requis – Ce fichier contient les informations de base décrivant le système de mobilité partagée. Cependant, une majorité de ses champs sont optionnels. Une bonne pratique est d’inclure dans le fichier les champs optionnels “phone_number”, “email” et “feed_contact_email”. D’autres champs optionnels peuvent être utiles selon le cas d’usage.
vehicle_types.json	Requis sous condition – Ce fichier est requis lorsque le système comporte des informations sur le type de véhicules dans le fichier “free_bike_status” ou son équivalent. Ce fichier doit être publié lorsque le système permet la location de plusieurs types de véhicules, par exemple des vélos et des vélos électriques. Sans publication de ce fichier, il est admis que le système ne comporte que des véhicules non-motorisés.
station_information .json	Requis sous condition – Ce fichier est requis lorsque le système utilise des stations. Toute station définie dans le système doit avoir une entrée correspondante dans le fichier “station_status.json”. Il permet également de définir des stations virtuelles qui correspondent à des zones de stationnement autorisé telles que des cerceaux ou des emplacements dédiés pour les flottes en libre-service. Le stationnement de ces derniers est donc mieux contrôlé par la définition de zones géo-spatialement précises.
station_status.json	Requis sous condition – Ce fichier est requis lorsque le système utilise des stations et optionnel lorsqu’utilisé pour réguler les stations virtuelles. Toute station définie dans ce fichier doit avoir une entrée correspondante dans le fichier “station_information.json”. Il s’agit d’un fichier de données en temps réel qui exprime le statut d’une station (virtuelle) donnée, des véhicules et espaces de stationnement rattachés. Il inclut le total de véhicules et espaces de stationnement disponibles, avec en option une différenciation par type de véhicule. Cette donnée peut être utilisée pour s’assurer d’une bonne ventilation des véhicules composant l’offre. Le champ optionnel “num_bikes_disabled” ou son équivalent est utile pour déterminer le pourcentage de véhicules disponibles à la location d’une flotte.
free_bike_status.json	Requis sous condition – Ce fichier (ou son équivalent) est requis pour tout système en libre-service (sans station) ou hybride (avec et sans stations de dépôt). Il est optionnel pour tout système reposant sur des stations. Il s’agit d’un fichier de données en temps réel qui exprime la position, la disponibilité et tout autre attribut de chaque véhicule d’une flotte. Dans le cas d’un système avec des stations, il peut être utilisé pour représenter des informations spécifiques à chaque véhicule comme le type de carburant, le niveau de charge ou tout autre attribut. Cette donnée peut être utilisée pour déterminer le nombre de véhicules déployés, leur disponibilité à la location, et leur ventilation dans une zone déterminée.
system_hours.json	Optionnel – Ce fichier est utilisé pour indiquer les horaires et jours auxquels la location est possible. Ce fichier doit être exigé lorsque le système n’est pas opérationnel 24h/24 et 7j/7. Si ce fichier n’est pas publié, il est admis que les véhicules peuvent être loués sans interruption de service. (Ce fichier pourrait devenir obsolète, auquel cas les horaires d’opération seront à publier selon la méthode propre à chaque version.)
system_calendar.json	Optionnel – Ce fichier optionnel doit être exigé lorsque le système est saisonnier et/ou connaît des périodes d’interruption. (Ce fichier pourrait devenir obsolète, auquel cas les jours d’opération seront à publier selon la méthode propre à chaque version.)
system_regions.json	Optionnel – Ce fichier est utilisé pour définir des régions au sein d’un système. Il peut être utilisé pour générer des rapports de fonctionnement dans des zones soumises au contrôle de plusieurs administrations.
system_pricing_plans .json	Optionnel – Ce fichier décrit les tarifications d’un système. Il est utile dans le cas d’une application tierce de mobilité mais peut ne pas assez exhaustif pour représenter toute la tarification existante de l’offre.
system_alerts.json	Optionnel – Ce fichier permet de prévenir les usagers de changements anormaux affectant le système. Par exemple, la suspension du service pour cause d’intempéries. Les villes devraient exiger ce fichier afin de communiquer aux usagers tout type d’information hors service régulier.
geofencing_zones .json	Optionnel – Ce fichier permet de délimiter des zones géospatiales qui ont des règles et attributs propres. Ces zones peuvent contenir des informations sur le stationnement, les limites de vitesse, les interdictions de circulation ou tout autre règle en vigueur. Elles peuvent également être utilisées pour assurer des zones de service minimum, de ventilation maximale ou tout autre cas d’usage. Les villes devraient l’exiger si leur politique publique repose sur un zonage déterminé. Une grande attention doit être portée à toute réglementation publique se reposant sur une donnée géospatiale : qu’elle soit issue d’un GPS, des données mobiles ou du WiFi, elle diffère en précision et granularité. Il peut en résulter un écart de dix mètres ou plus.

Recommandations en termes de politique de données

Les politiques de données doivent être claires et précises. Elles doivent identifier quelles sont les données requises et la version de la spécification à respecter pour leur publication.

A minima, une politique publique de données se mobilité partagée doit :

S’assurer d’un accès aux données à la fois pour les autorités publiques et pour les usagers sans restriction ;
Définir clairement le format et la version d’expression des données ;
S’assurer que les données nécessaires à la régulation, au contrôle et à la gestion des opérateurs de mobilité partagée soient accessibles ;
Protéger la confidentialité des données des usagers des plateformes de mobilité.

Éléments de langage suggérés

[L’ENTREPRISE] doit fournir une API accessible qui est en conformité avec le General Bikeshare Feed Specification (GBFS) dont la version actuelle est disponible au https://github.com/NABSA/gbfs/ . [L’ENTREPRISE] doit s’assurer que son API est mise à la disposition du public sur Internet et sans exigence d’authentification.

[L’ENTREPRISE] doit transmettre à [L’AUTORITÉ PUBLIQUE] le lien du fichier “gbfs.json” avant le déploiement de ses véhicules. En cas de changement de lien, une notification doit être transmise à [L’AUTORITÉ PUBLIQUE] par [L’ENTREPRISE] dans un délai minimal de 30 jours avant ledit changement.

Les données contenues dans l’API doivent être mises à la disposition du public et [L’AUTORITÉ PUBLIQUE] avec une licence non révocable qui permet aux données d’être utilisées, modifiées et partagées sans restriction autre que l’attribution.

Lors de la publication d’une nouvelle version du GBFS, [L’ENTREPRISE] se doit de mettre à niveau son API dans un délai de [XX¹] jours hormis dans le cadre d’un accord préalable avec [L’AUTORITÉ PUBLIQUE].

90 jours recommandés

L’API GBFS doit contenir au moins les fichiers et champs requis par la spécification GBFS, à savoir :

gbfs.json
system_information.json
[liste des fichiers optionnels tels que station_information.json, station_status.json, free_bike status.json ou leur équivalent, etc.]

En sus des champs requis par la spécification, les fichiers suivants doivent également comporter les champs optionnels suivants:

file_name.json: field_name, field name
file_name.json: field_name, field name

Pour un exemple d’élément de langage dans le cadre d’une autorisation spécifique, il est possible de se référer aux conditions d’autorisation de trottinettes émises par le SFMTA (à partir de la page 41).

Considérations supplémentaires

Il n’est possible de tirer pleinement parti des bénéfices inhérents aux données ouvertes que si elles sont facilement accessibles par le public tout en protégeant la vie privée de tous : le GBFS permet les deux. Les villes et autorités locales devraient publier les liens des fichiers “gbfs.json” sur leurs sites web ou sur des portails de données ouvertes et dans le catalogue mondial des jeux de données publics exprimées en GBFS.

Exiger des opérateurs de mobilité partagée l’ouverture de leurs données deviendra encore plus pressante alors que la Commission Européenne exigera de chaque État Membre la mise en place d’un Point d’Accès National (PANs) qui se veut être le portail de toutes les données ouvertes de mobilité en direction des usagers. Les PANs ont été conçus pour soutenir le développement d’un marché commun en Europe qui repose sur une interopérabilité complète entre les modes de mobilité et les régions, afin que chacun puisse voyager librement au sein de l’Union Européenne. Le GBFS est un format commun et reconnu qui permet à chacun des États Membres de se plier aux exigences européennes à plusieurs niveaux :

Il est en adéquation avec la volonté de mise en place d’un marché commun ouvert, qui permet d’éviter des positions monopolistiques ;
Il permet une meilleure transparence des données et soutient les efforts européens en faveur de l’ouverture des données pour une société civile plus active dans la vie des institutions ;
Il protège les données personnelles des usagers en s’assurant que celles les informations à destination des voyageurs sont publiées, en respect du Règlement Général de Protection des Données (RGPD) ;
Il soutient une mobilité plus verte, plus durable en offrant des solutions de mobilité aux usagers autres que de conduire leur propre voiture ;
Il est intégralement compatible avec les normes et standards européens.

Dans un effort constant d’ouverture des données, certains PANs, tels que celui géré par Entur en Norvège ou transport.data.gouv.fr en France, ont mis en place une équipe pour accompagner les opérateurs de mobilité. Leurs conseils sur la façon de tirer parti de GBFS peuvent être sollicités, si nécessaire.

Le GBFS a été développé et testé sur la base d’un consensus pour s’assurer que les données contenues dans la spécification n’aient pas d’impact négatif sur la confidentialité des données des usagers. Les versions actuelles du GBFS sont toutes conformes au RGPD, notamment parce qu’elles ne contiennent aucune donnée personnelle et/ou d’identification. Le point essentiel à retenir est qu’il n’y pas de moyen trivial de reconstruire le trajet d’une personne données et/ou ses habitudes grâce à la rotation obligatoire des identifiants des véhicules.

Une attention toute particulière doit être portée aux demandes formulées auprès des opérateurs de fournir des données en dehors du cadre de la spécification. Les données sur des véhicules en location active ne doivent jamais apparaître dans un flux de données GBFS. La sur-collecte des données (i.e. toute collecte qui ne répond pas à un but déterminé) est fortement déconseillée. Le croisement des données de mobilité partagé avec d’autres données disponibles pourrait mettre à mal la protection des données personnelles. Il nous semble important de rappeler que l’état d’esprit du RGPD est de s’assurer que toute collecte de données doit être suffisante et proportionnée aux besoins opérationnels et ne peut en aucun cas contenir des informations d’identification sans le consentement explicite des usagers.

Pour favoriser une meilleure interopérabilité au sein du marché commun européen, le comité européen de normalisation (CEN) a développé Transmodel (la norme européenne « Modèle de données de référence pour les transports publics » (EN 12896)) – une norme de données qui facilite l’interopérabilité entre les systèmes de traitement de l’information des opérateurs de mobilité et agences en se reposant sur des définitions, des structures et une sémantique communes à l’ensemble des systèmes. En s’appuyant sur Transmodel, d’autres normes ont été définies : NeTEx (CEN/TS 16614-1/2/3/5) pour l’échange d’informations sur les transports publics, et SIRI (EN 15531-1/2/3/4/5) pour les informations en temps réel. Tous deux sont en cours d’adaptation aux « nouveaux modes », dont les solutions de mobilité partagée.

Le GBFS est le seul standard ouvert de données, utilisé au niveau international, à être reconnu par le CEN comme compatible et convertible en NeTEx/SIRI sur la base d’une cartographie canonique, en cours d’approbation par le CEN. Cette convertibilité réduit la charge de production et de consommation des données pour tous les acteurs de l’industrie de la mobilité partagée.

Liens utiles

* principalement en anglais avec quelques ressources en français

E-mail de l’équipe de mobilité partagée de MobilityData : sharedmobility@mobilitydata.org
Notre équipe parle français, alors n’hésitez pas à nous faire part de vos questions ou demandes.

Remerciements

L’équipe de Mobilité partagée – MobilityData

Heidi Guenin, Directrice, Produit, Mobilité partagée

Mitch Vars, Spécialiste senior en mobilité partagée

Josée Sabourin, Spécialiste en mobilité partagée

L’équipe de Partenariats pour l’Europe – MobilityData

Tu-Tho Thai, Directrice, Partenariats Europe

Newton Davis, Partenariats Europe

Relecteurs

Josh Johnson, Public Policy Manager, Spin

Oliver O’Brien, Senior Research Associate, University College London

Scott Shepard, VP Global Public Sector, Iomob

Ce document a été conçu pour soutenir les villes dans leur adoption du GBFS. Il ne peut en aucun cas être considéré comme conseil juridique. Il est recommandé aux acteurs publiques de s’assurer de la conformité des éléments de langage suggérés aux lois et réglementations locales en vigueur.