Comment interfacer un SAEIV avec des bornes d'information voyageurs existantes ?
.webp)
C'est l'une des premières questions posées par les collectivités et les opérateurs qui envisagent de déployer un SAEIV : faut-il remplacer les bornes d'information voyageurs existantes ? La réponse est généralement non. La grande majorité des bornes installées depuis 2015 sont compatibles avec les standards ouverts du marché. L'enjeu est de comprendre comment fonctionne l'interface entre le SAEIV et les bornes, et quelles sont les conditions techniques à vérifier avant tout projet.
Comment une borne d'information voyageurs fonctionne-t-elle ?
Une borne d'information voyageurs (BIV) ou afficheur de quai a besoin de deux types de données pour fonctionner :
- Les données théoriques : les horaires programmés (généralement au format GTFS)
- Les données temps réel : les positions actuelles des véhicules et les écarts par rapport à l'horaire théorique (généralement au format GTFS-RT ou SIRI)
Les données théoriques sont en général mises à jour périodiquement (lors des changements de service). Les données temps réel sont rafraîchies en continu, toutes les 30 secondes à 2 minutes selon le système.
La borne reçoit ces données depuis un serveur central qui les agrège et les distribue. Le SAEIV est l'outil qui produit et alimente ce serveur.
Les protocoles standards : GTFS-RT et SIRI
L'interface entre un SAEIV et des bornes repose sur des standards ouverts qui sont aujourd'hui largement adoptés par les fabricants de bornes français et européens.
GTFS-RT
Le format GTFS-RT (General Transit Feed Specification Real-Time) est le standard mondial pour la diffusion de données transport en temps réel. Il comprend trois flux :
- Trip Updates : retards et avancements prévus pour chaque course
- Vehicle Positions : position GPS de chaque véhicule
- Service Alerts : perturbations et messages d'information
La grande majorité des bornes modernes (Lumiplan, Hanover, Televic, Horus) consomment nativement les flux GTFS-RT. Pysae génère ces flux en continu pour chaque réseau déployé.
SIRI
Le standard SIRI (Service Interface for Real-Time Information) est le protocole de référence en France pour les échanges entre systèmes de gestion du transport. Il est plus complet que le GTFS-RT et intègre des fonctionnalités avancées (gestion des perturbations, correspondances, messages complexes). Pysae produit également des flux SIRI, notamment le profil SIRI Lite utilisé par Île-de-France Mobilités.
Les étapes d'un projet d'interface SAEIV-bornes
1. Audit des bornes existantes
La première étape est d'inventorier précisément les bornes en place : fabricant, année d'installation, firmware actuel, protocoles supportés. La plupart des fabricants indiquent dans leur documentation les versions de GTFS-RT et SIRI supportées. Si les bornes ont plus de 10 ans et fonctionnent avec des protocoles propriétaires anciens, une mise à jour du firmware ou un remplacement partiel peut s'avérer nécessaire.
2. Définition du schéma de données
Les bornes ont besoin d'un référentiel d'arrêts cohérent avec celui du SAEIV. Les identifiants d'arrêts dans le GTFS du SAEIV doivent correspondre aux identifiants utilisés par les bornes pour savoir quelles données afficher. Cette alignement des référentiels est souvent le travail le plus délicat d'un projet d'interface.
3. Paramétrage et tests
Une fois le protocole défini, le SAEIV est configuré pour exporter les flux vers l'adresse du serveur des bornes. Une période de test de 2 à 4 semaines permet de valider la qualité de l'affichage, les délais de rafraîchissement et le comportement en cas de données manquantes (panne de connexion d'un bus, par exemple).
Les cas particuliers
Bornes avec protocole propriétaire
Certaines bornes plus anciennes fonctionnent avec des protocoles propriétaires développés par leur fabricant. Dans ce cas, l'interface nécessite soit un adaptateur (middleware) qui traduit les flux GTFS-RT en protocole propriétaire, soit un accord avec le fabricant pour une mise à jour du firmware vers les standards ouverts.
Bornes multimodales
Dans les pôles d'échanges où cohabitent bus, tram et train, les bornes affichent des données provenant de plusieurs SAEIV différents. Le serveur central agrège ces flux et les distribue à toutes les bornes. Pysae s'intègre nativement dans ces architectures multi-sources.
Ce qu'il faut retenir
Interfacer un SAEIV avec des bornes existantes est un projet technique structuré, mais rarement un obstacle rédhibitoire. Les standards GTFS-RT et SIRI couvrent la grande majorité des installations récentes. Le point clé est d'auditer l'écosystème existant avant de choisir un SAEIV, et de vérifier que la solution retenue génère nativement les protocoles attendus par les bornes en place.
Un SAEIV comme Pysae, conçu nativement pour l'interopérabilité, produit l'ensemble des flux standards nécessaires sans développement spécifique. L'interface avec les bornes existantes fait partie du périmètre standard du projet de déploiement.
Nos derniers articles :
Retour au blog
Comment piloter 530 véhicules sur des lignes à forte saisonnalité ? Le défi opérationnel de la Régie des Transports de l'Ain avec Pysae.
Réseau gratuit sans billettique : comment garantir une information voyageurs fiable et en temps réel sans données de validation ?
La COOP30 fédère 21 PME de transport qui mutualisent un SAEIV commun. Un modèle coopératif unique qui change la donne pour les petits opérateurs.







