SIRI et GTFS-RT : les deux standards de l'information voyageur temps réel

En bref : le GTFS-RT et le SIRI sont les deux normes qui rendent un réseau visible en temps réel. Le GTFS-RT alimente Google Maps, Citymapper, Moovit et les écrans d'information ; le SIRI, norme européenne du CEN, est le protocole d'échange entre systèmes et avec les plateformes institutionnelles. Sur le Point d'Accès National, le temps réel peut être publié en GTFS-RT, SIRI Lite ou SIRI complet. La bonne pratique : produire les deux à partir de la même donnée d'exploitation.

Rendre son réseau visible en temps réel dans les outils que les voyageurs utilisent réellement ne dépend pas d'un seul flux. Deux normes coexistent et répondent à deux besoins différents : le GTFS-RT, devenu le standard de fait pour les applications grand public, et le SIRI (Service Interface for Realtime Information), la norme européenne élaborée par le CEN, qui sert de base aux échanges entre systèmes et avec les plateformes institutionnelles. Confondre les deux, ou ne miser que sur l'un, laisse un réseau à moitié visible.

GTFS-RT, le standard de fait des applications grand public

Google Maps, Citymapper, Moovit et la plupart des applications de mobilité grand public ne devinent pas les horaires réels d'un bus, elles lisent un flux GTFS-RT publié par l'exploitant ou l'AOM. Sans ce flux, ces applications retombent sur l'horaire théorique du GTFS statique, ce qui veut dire qu'elles annoncent un passage à l'heure alors que le bus a dix minutes de retard. Le voyageur ne blâme pas l'application, il blâme le réseau.

Le même flux alimente les écrans d'information en station, les bornes d'arrêt et les widgets embarqués sur les sites web des AOM. C'est ce qui en fait un investissement à fort effet de levier, mais GTFS-RT reste un format né hors d'Europe, pensé pour les besoins d'un calculateur d'itinéraires, pas pour un cadre réglementaire.

SIRI, la norme européenne des échanges entre systèmes

Le SIRI est une spécification technique du CEN (NF EN 15531), élaborée avec la participation initiale de la France, l'Allemagne, la Norvège et le Royaume-Uni, et adossée au modèle de référence européen du transport public, Transmodel. Contrairement à GTFS-RT, qui décrit un flux, SIRI décrit un protocole d'échange complet entre systèmes, avec un profil France normalisé pour les échanges institutionnels.

Ce n'est pas qu'une question de préférence technique. Le règlement délégué (UE) 2017/1926 encadre l'ouverture des données de transport, et en France, le Point d'Accès National accepte plusieurs voies pour le temps réel : GTFS-RT, SIRI Lite conforme au profil français, ou SIRI complet, sans obligation légale de privilégier l'un plutôt que l'autre. Le SIRI reste en pratique le format demandé quand l'autorité organisatrice impose une spécification technique propre. Notre article sur ce que le Point d'Accès National exige vraiment des opérateurs français détaille ces exigences.

Pourquoi un seul format ne suffit jamais

Un opérateur qui ne publie que du GTFS-RT gagne en visibilité dans les applications grand public, mais peut ne pas répondre à la spécification technique d'une autorité organisatrice qui exige du SIRI. Un opérateur qui ne publie que du SIRI répond aux échanges institutionnels, mais risque de rester invisible dans les outils que les voyageurs utilisent au quotidien. La bonne pratique, confirmée par la doctrine du Point d'Accès National, est de faire correspondre le théorique et le temps réel : GTFS théorique avec GTFS-RT, NeTEx théorique avec SIRI.

Ce qu'il faut avoir en place pour publier des flux fiables, quel que soit le format

Produire GTFS-RT ou SIRI ne se limite pas à formater un fichier dans le bon schéma. Il faut :

• Une source de position véhicule fiable, généralement un boîtier AVM embarqué qui remonte la géolocalisation en continu.
• Un calcul d'écart horaire en temps réel, comparant la position réelle à l'horaire théorique pour générer les prédictions d'arrivée.
• Une republication continue et multi-format, capable de servir à la fois GTFS-RT pour les applications grand public et SIRI ou SIRI Lite pour les plateformes institutionnelles, à partir de la même donnée d'exploitation.

Sans ces trois briques, un flux publié "pour la forme", quel que soit son format, affiche des prédictions peu fiables, ce qui abîme la confiance des voyageurs plus sûrement que l'absence de flux.

Questions fréquentes

Quelle différence entre SIRI et GTFS-RT ?

Le GTFS-RT décrit un flux, devenu le standard de fait des applications grand public comme Google Maps, Citymapper et Moovit. Le SIRI décrit un protocole d'échange complet entre systèmes, élaboré par le CEN et adossé au modèle Transmodel, avec un profil France normalisé pour les échanges institutionnels.

Faut-il publier du SIRI et du GTFS-RT ?

Un seul format laisse un réseau à moitié visible : le GTFS-RT seul gagne en visibilité dans les applications mais peut ne pas répondre à une spécification SIRI, et le SIRI seul peut rester invisible dans les outils du quotidien. La bonne pratique est de produire les deux à partir de la même donnée d'exploitation.

Quel format publier sur le Point d'Accès National ?

Le Point d'Accès National accepte le GTFS-RT, le SIRI Lite conforme au profil français et le SIRI complet. Les horaires théoriques doivent être disponibles en complément : GTFS théorique avec GTFS-RT, NeTEx théorique avec SIRI. Voir notre article GTFS-RT, SIRI, NeTEx : ce que le Point d'Accès National exige vraiment des opérateurs français.

Comment afficher les horaires en temps réel aux arrêts de bus ?

Les écrans d'information en station, les bornes d'arrêt et les widgets des sites d'AOM lisent le même flux GTFS-RT que les applications grand public. Il faut donc produire ce flux à partir de la position réelle des véhicules et d'un calcul d'écart horaire en temps réel.

Que faut-il pour publier des flux temps réel fiables ?

Trois briques : une source de position véhicule fiable, un calcul d'écart horaire en temps réel qui génère les prédictions d'arrivée, et une republication continue et multi-format à partir de la même donnée d'exploitation.

Vous voulez être visible dans Google Maps et Citymapper tout en restant conforme au cadre réglementaire français ? L'équipe Pysae peut vous montrer comment notre SAEIV génère nativement vos flux GTFS-RT et SIRI/SIRI Lite depuis la même donnée d'exploitation.