GTFS-RT en pratique : ce que les exploitants font mal avec les flux temps réel

GTFS-RT en pratique : ce que les exploitants font mal avec les flux temps réel

Le GTFS-RT est devenu le standard de facto pour la diffusion des données de transport en commun en temps réel. Applications voyageurs, points d’accès nationaux, calculateurs d’itinéraire, plateformes MaaS : tous consomment ce format. Pour les exploitants, publier un flux GTFS-RT est passé d’une option à une obligation contractuelle dans la grande majorité des nouveaux contrats DSP.

Mais adoption et qualité sont deux choses différentes. Dans les faits, un grand nombre d’exploitants publient des flux GTFS-RT techniquement valides mais opérationnellement peu fiables. Voici les erreurs les plus fréquentes et ce qu’elles coûtent.

Erreur 1 : confondre publication et conformité

Avoir un endpoint GTFS-RT ne signifie pas être conforme. La plupart des autorités organisatrices définissent des seuils de qualité : fréquence de rafraîchissement, précision de position, taux de couverture des mises à jour de courses. Un exploitant dont le SAEIV pousse des positions toutes les 90 secondes publie techniquement du GTFS-RT, mais peut être hors conformité contractuelle si la fréquence exigée est de 30 secondes. Cet écart est rarement audité en continu. Il remonte généralement lors des revues de pénalités ou quand une plateforme MaaS signale des anomalies de qualité.

Erreur 2 : désynchroniser les données théoriques et temps réel

Le GTFS-RT est une surcouche temps réel sur un GTFS statique. Si le GTFS statique n’est pas maintenu à jour (changements de lignes, modifications d’arrêts, mises à jour horaires), le flux temps réel devient incohérent. Les trip IDs du flux RT référencent des courses qui n’existent plus dans le statique, ou des arrêts renommés. C’est l’une des causes les plus fréquentes de bus fantômes dans les applications : le véhicule est en circulation et transmet sa position, mais le calculateur ne peut pas faire correspondre la mise à jour RT à une course planifiée.

Erreur 3 : traiter le GTFS-RT comme un output unidirectionnel

La plupart des exploitants configurent leur SAEIV pour pousser un flux GTFS-RT et considèrent le travail terminé. Peu utilisent ce flux comme un signal opérationnel interne. Les données GTFS-RT contiennent une image en temps réel du respect des horaires sur l’ensemble du réseau. Les exploitants qui le traitent exclusivement comme un output pour des consommateurs externes laissent de la valeur sur la table. La supervision du flux peut faire remonter des patterns invisibles dans les rapports de fin de journaux : départs prématurés systématiques sur une ligne, pics de latence à certaines heures, ou un sous-ensemble de véhicules qui produisent des données GPS dégradées en raison d’un problème matériel.

Erreur 4 : négliger la dépendance au GTFS statique

Les Vehicle Positions et Trip Updates du GTFS-RT référencent le flux GTFS statique par trip ID et stop sequence. Tout changement sur le statique (modification de service, restructuration de ligne, renommage d’arrêt) doit être répercuté simultanément dans le flux RT. Les exploitants qui gèrent ces deux flux via des processus ou des équipes séparés se retrouvent fréquemment avec des décalages de synchronisation difficiles à détecter. L’architecture la plus robuste est celle où les deux flux sont générés depuis la même source de vérité : les données de planification opérationnelle de votre SAEIV. Pysae génère GTFS statique et GTFS-RT depuis les mêmes données réseau, ce qui élimine les erreurs de synchronisation par construction.

Erreur 5 : absence de stratégie de repli en cas de perte GPS

Les environnements urbains denses, les tunnels et les zones souterraines génèrent des ruptures de couverture GPS. La plupart des exploitants n’ont pas de stratégie de repli définie : le véhicule disparaît du flux, et les consommateurs en aval affichent soit une position périmée, soit suppriment le véhicule de l’affichage. Un SAEIV bien configuré gère la dégradation GPS de manière gracieuse : calcul par estime, positions interpolées basées sur l’horaire et la dernière position connue, ou indicateurs explicites de données manquantes que les systèmes en aval peuvent traiter. Si votre système actuel cesse simplement de transmettre lors d’une perte GPS, c’est une lacune de fiabilité de flux qui affecte l’expérience voyageur.

Un flux GTFS-RT fiable se rafraîchit au rythme exigé par vos contrats, reste synchronisé en permanence avec votre GTFS statique, est supervisé pour la qualité et les anomalies, et gère les conditions dégradées sans disparaitre. Si votre configuration actuelle ne remplit pas ces quatre critères, une revue technique avant votre prochain renouvellement de contrat vaut la peine.