SIRI et GTFS-RT : les deux standards de l'information voyageur temps réel
.webp)
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 est en pratique le format attendu par la réglementation française sur l'ouverture des données de transport. 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 devenue une exigence réglementaire
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 en fixant les formats attendus, et pour le temps réel, il demande la conformité au profil France de la norme SIRI ou SIRI Lite. GTFS-RT n'est que toléré, quand l'opérateur n'est pas encore en mesure de produire du SIRI ou en complément. Autrement dit, en France, SIRI n'est pas une option parmi d'autres, c'est le format que la réglementation place en tête.
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 reste en dessous de ce qu'attend le cadre réglementaire français. Un opérateur qui ne publie que du SIRI répond à l'obligation institutionnelle, 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.
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.
Nos derniers articles :
Retour au blog
Régulation temps réel dans le transport bus : rôle du régulateur, indicateurs clés (régularité, ponctualité, écart-tableau) et apport de l’algorithme à l’exploitation.
Transport public Maroc en 2025 : programme national de 11 MMDH, 3 700 bus, CasaBusway, tramway et digitalisation des gares. Ce qui manque encore, la régulation temps réel.
SAEIV cloud : pourquoi les opérateurs de transport public basculent vers des architectures cloud-native, entre conformité NeTEx et attentes voyageurs.







