Sommaire

Le guide des solutions digitales pour le transport public

Véritable référence pour le secteur du transport de voyageurs, ce guide est l’allié de vos réunions stratégiques.

En savoir +

Comment interfacer un SAEIV avec des bornes d'information voyageurs existantes ?

publié le
November 20, 2025
Information voyageurs
Nicolas Jaulin, CEO
Nicolas Jaulin
CEO

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

Déployer un SAEIV en moins de 6 mois : retour d'expérience Transdev Cotentin

Comment un opérateur régional a migré vers un SAEIV SaaS en 6 mois sans interruption de service.

Comment améliorer la ponctualité des bus sur les réseaux interurbains ?

Retards chroniques, effets accordéon, reporting insuffisant : les clés pour reprendre la main sur la ponctualité.

Cybersécurité des SAEIV : Pourquoi la protection de vos données de transport est une priorité absolue

Ransomware, RGPD, DDoS : pourquoi le SAEIV est une cible critique et comment Pysae garantit la continuité de service.

Envie d'en voir davantage ?