Normes importantes de la Mobilité Publique

L’interopérabilité n’apparaît pas d’elle-même. Elle résulte d’un accord, établi publiquement, sur la manière dont les systèmes se décrivent mutuellement horaires, véhicules, disponibilités, réservations et paiements. Trois familles de normes assurent aujourd’hui l’essentiel de ce travail dans la Mobilité Publique.

GTFS, OSDM, MDS, CDS/M, OTP, OJP.

GTFS (General Transit Feed Specification) décrit les transports publics planifiés — lignes, arrêts et horaires — sous une forme lisible par toute application. C’est la raison pour laquelle un calculateur d’itinéraires peut couvrir le réseau d’un pays entier sans négocier avec chaque opérateur séparément.

L’OSDM (Open Sales and Distribution Model) ne remplace pas directement les autres normes de mobilité, mais les complète en gérant spécifiquement les ventes, la tarification et la billetterie. Dans le paysage européen des transports, l’OSDM comble les lacunes des autres normes. Alors que les protocoles existants se concentrent principalement sur les horaires, la topologie du réseau ou l’infrastructure des véhicules, l’OSDM gère la transaction financière proprement dite. Ce modèle est officiellement normalisé par l’Union internationale des chemins de fer (UIC) sous la référence IRS 90918-10. Son utilisation n’est cependant pas limitée aux opérateurs ferroviaires.

La norme MDS (Mobility Data Specification) est spécifiquement conçue pour la gestion de l’espace public. Alors que des normes comme OSDM se concentrent sur la billetterie et la vente, MDS est entièrement dédiée à la régulation des véhicules en circulation. Elle est gérée par l’Open Mobility Foundation (OMF). La norme fonctionne principalement via trois composants API principaux :

Fournisseur : Les opérateurs de mobilité partagée (comme Lime, Bird ou Tier) envoient des données historiques et en temps réel à la ville (par exemple, la localisation des véhicules, les trajets effectués).

Agence : La ville demande des données en temps réel ou des données télémétriques spécifiques aux opérateurs.

Réglementation : La ville transmet aux opérateurs la réglementation numérique dans un format lisible par machine (par exemple, les limitations de vitesse, les zones d’interdiction de stationnement géolocalisées).

CDS-M signifie City Data Standard - Mobility (également appelée City Data Specification for Mobility). Il ne s’agit pas d’un format de données autonome, mais d’un cadre normalisé et d’un manuel de procédures conçus pour aider les municipalités et les opérateurs de transport à échanger des données de mobilité partagée de manière sécurisée, légale et éthique. Alors que les API techniques telles que MDS (Mobility Data Specification) ou GBFS définissent le format des données, CDS-M définit la manière dont ces données doivent être gouvernées, traitées et faire l’objet d’un accord entre les entreprises et les pouvoirs publics (B2G). Initialement développée aux Pays-Bas par le ministère des Infrastructures et de la Gestion de l’eau, en collaboration avec les principales villes néerlandaises (dont Amsterdam, Rotterdam et Utrecht), CDS-M visait à résoudre les problèmes de partage de données.

OTP (OpenTripPlanner) est une plateforme logicielle open source de référence pour la création d’applications de planification d’itinéraires. Elle traite les données brutes de transport (horaires et cartes) afin de trouver les meilleurs itinéraires pour les utilisateurs. OTP agit comme le « cerveau » du système de routage. Si un utilisateur souhaite se rendre du point A au point B, OTP calcule la combinaison la plus rapide de marche, de vélo, de voiture et de transports en commun. Elle utilise des formats de données ouverts et standardisés tels que GTFS (pour les horaires de transport) et OpenStreetMap (OSM) (pour la géométrie des routes et des trottoirs). Les principales autorités et entreprises de transport du monde entier (telles qu’Entur en Norvège, TriMet à Portland et diverses applications régionales en Europe) utilisent OJP comme moteur backend pour leurs applications grand public.

OJP signifie Open Journey Planner. Il s’agit d’une norme API européenne officielle (formalisée par la norme CEN/TS 17118) développée pour permettre à différents systèmes de planification de trajets indépendants de communiquer entre eux. OJP est un protocole d’interconnexion ouvert basé sur une structure de requête/réponse XML. Au lieu d’obliger chaque région à centraliser toutes ses données dans une base de données unique et massive, OJP permet à une application de demander simultanément des calculs d’itinéraires en temps réel à plusieurs systèmes régionaux et de les assembler en un seul itinéraire transfrontalier continu.

OJP fait partie du cadre de référence européen Transmodel. Il fonctionne avec des normes apparentées telles que NeTEx (pour les horaires) et SIRI (pour la géolocalisation des véhicules en temps réel). Le règlement MMTIS de la directive STI de la Commission européenne impose l’utilisation d’OJP afin de faciliter la planification de déplacements multimodaux transfrontaliers et fluides à travers l’Europe.

TOMP-API, élaborée par le groupe de travail Transport Operator / Mobility Provider, normalise la transaction entre un opérateur de mobilité et le service qui revend ses trajets : ce qui est disponible, comment la réservation s’effectue, comment le trajet est déclaré et réglé.

Le protocole Beckn va plus loin. Plutôt que de normaliser une interface, il décrit comment un réseau décentralisé de prestataires et d’applications destinées aux usagers peut se découvrir et transiger directement, sans plateforme intermédiaire. FINOMAD en promeut l’application, l’usage, la formation et le développement à des fins de mobilité.

Chacune répond à une question différente. Lues ensemble, elles décrivent les normes dont un système de mobilité ouvert a besoin.