Politique en matière de données GBFS et de mobilité partagée

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

Ce guide est également disponible en portugais, en espagnol et en anglais.

Vue d'ensemble

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 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.

Photo prise par Martti Tulenheimo.

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

GBFS facilite la découvrabilité et l’usage de la mobilité partagée pour tous les voyageur·euses.

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

Les décideur·euses politiques devraient exiger des APIs GBFS publiques lorsqu'ils·elles autorisent ou délivrent des licences pour des opérations de mobilité partagée.

GBFS fournit un langage commun aux opérateurs de mobilité partagée pour partager des informations sur les options disponibles pour les voyageur·euses. GBFS comprend des informations sur les véhicules (vélos, trottinettes, scooters et voitures), les stations, etc :

• 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 utilisateur·rices toutes les informations dont ils·elles ont besoin pour choisir leur solution de mobilité partagée. Les APIs 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 kilomè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, 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.

GBFS a été conçu spécialement pour permettre un usage public de la donnée. Pour que les APIs GBFS soient réellement publiques, elles doivent être mises à disposition en ligne sans restriction (pas de clef API, de token 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 APIs publiques.

GBFS permet à toutes les parties prenantes 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. 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é. GBFS ne permet pas et n’est pas conçu pour des données historiques telles que les déplacements des utilisateur·rices ou encore les données de maintenance.

GBFS réduit les charges administratives des villes et 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 GBFS favorise l’essor d’un marché de logiciels de gestion des données et des services, 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 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. GBFS leur apporte aussi la possibilité d’étendre leur visibilité 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 GBFS tient compte des avis des opérateurs comme des villes dans ses évolutions. Sa documentation complète et les outils sont mis à disposition des villes comme des opérateurs pour en faciliter l’usage et l’adoption.

Photo prise par Jean-Louis Zimmermann.

Recommandations

GBFS devrait 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.

Exemple de formulation pour les appels d'offres

Exigences en matière de partage des données :

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

Déterminer les données à exiger dans le cadre d'une politique globale.

À mesure que l’industrie de la mobilité partagée évolue, 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 de GBFS repris 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 l'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.

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 en libre-service en station historique, 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 12 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 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 utilisateur·rices et/ou en soutien à leurs politiques publiques et besoins.

Photo prise par Spin.

Vue d'ensemble des fichiers GBFS

Nom du fichier	Requis ou non
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.
manifest.json	Requis sous condition - Ce fichier est un index des URLs gbfs.json pour chaque jeu de données GBFS produit par un éditeur.
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" et "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 "vehicle_status.json" 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 de geofencing.
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 donnée (virtuelle ou non), 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 rotation des véhicules composant l’offre. Le champ optionnel "num_vehicles_disabled" ou son équivalent est utile pour déterminer le pourcentage de véhicules disponibles à la location d’une flotte.
vehicle_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 uniquement 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 rotation dans une zone déterminée.
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 n'est peut être pas suffisant pour représenter toute la tarification existante de l’offre.
system_alerts.json	Optionnel - Ce fichier permet de prévenir les utilisateur·rices 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 utilisateur·rices tout type d’information hors service régulier.
geofencing_zones.json	Optionnel - Ce fichier permet de délimiter des zones géographiques 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 quantité 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éographique : 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 matière de politique des 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 du standard à respecter pour leur publication.

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

• S’assurer d’un accès aux données à la fois pour les autorités publiques et pour les utilisateur·rices 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 utilisateur·rices des plateformes de mobilité.

Éléments de langage suggérés

[L’ENTREPRISE] doit fournir une API accessible qui est en conformité avec le standard General Bikeshare Feed Specification (GBFS) dont la version actuelle est disponible à l'adresse https://github.com/MobilityData/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 de [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 de 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].

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, vehicle_status.json ou leur équivalent, etc.]

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

• fichier.json: nom du champ
• fichier.json: nom du champ

(1.) 90 jours recommandés

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).

Autres considérations

Il n’est possible de tirer pleinement parti des avantages des données ouvertes que si elles sont facilement accessibles par le public tout en protégeant la vie privée de tous : 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 de jeux de données en libre accès exprimés en GBFS.

Pour les pays européens

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 utilisateur·rices. 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. 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 de monopole ;
• 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 utilisateur·rices en s’assurant que les informations à destination des voyageur·euses sont publiées, en respect du Règlement Général de Protection des Données (RGPD) ;
• Il soutient une mobilité plus durable en offrant des solutions de mobilité aux utilisateur·rices 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.

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 utilisateur·rices. Les versions actuelles de 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 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ée 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 utilisateur·rices.

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.

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 correspondance canonique, en cours d’approbation par le CEN. Cette convertibilité réduit la charge de production et de consommation des données pour toutes les parties prenantes de l’industrie de la mobilité partagée.

Liens utiles

• Répertoire GitHub GBFS
• Canal Slack public GBFS
• NeTEx
• SIRI

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

Heidi Guenin, Mitch Vars, Josée Sabourin, Tu-Tho Thai et Newton Davis.

Relecteur·rices

Diego Canales - Responsable des partenariats mondiaux, Populus AI

Josh Johnson - Responsable des politiques publiques, Spin

Andrew Salzberg - Responsable des politiques, Transit

Michael Schwartz - Responsable des clients et de la politique, Ride Report

Oliver O'Brien - Associé de recherche principal, University College London

Scott Shepard - Vice-président du secteur public mondial, Iomob

Ce document a été conçu pour soutenir les villes dans leur adoption de 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.