GTFS Realtime : relier alertes, trajets et information voyageur

Séparer les trois informations reçues

La référence GTFS Realtime distingue notamment TripUpdate, VehiclePosition et Alert. Une mise à jour de trajet apporte des informations sur le service ; une position décrit un véhicule ; une alerte signale une perturbation avec son périmètre. Leur présence dans le même flux ne les rend pas interchangeables. La position d’un bus près d’un arrêt ne suffit pas à confirmer que ce bus dessert cet arrêt ou que le voyageur pourra monter.

Commencez par une matrice des usages de votre page : prévoir un départ, montrer un véhicule, expliquer une fermeture ou proposer une alternative. Pour chaque usage, choisissez le message qui l’étaye et le texte qui peut être publié. Dans un cas pédagogique, une carte reçoit une position mais aucune prévision d’arrivée. Le résultat attendu doit conserver la carte si elle reste utile, sans inventer un compte à rebours à partir de la seule distance.

Retrouver le trajet et le service concernés

Conservez le producteur, la version du jeu horaire utilisé, les références du trajet et celles des arrêts rapprochés. Examinez les champs du message selon le service concerné ; ne joignez pas deux flux uniquement parce qu’un libellé de ligne se ressemble. Un numéro de ligne peut être repris par plusieurs opérateurs et un service récurrent doit être compris avec sa journée de circulation.

Rejouez un trajet qui traverse minuit avec deux dates de service possibles. Le rapprochement doit retrouver le départ attendu et les arrêts concernés. Ajoutez ensuite une référence inconnue : la page doit la garder comme non rapprochée plutôt que l’affecter au premier trajet approchant. Faites conserver au registre la règle de jointure et son résultat sur ces deux cas. La personne qui reprend le test doit pouvoir expliquer pourquoi le message touche ce trajet et pas son voisin.

Mesurer l’âge de l’information affichée

L’horodatage d’un flux reçu récemment ne prouve pas que chacune de ses informations vient d’être produite. Les bonnes pratiques GTFS distinguent notamment l’âge du contenu et celui de l’en-tête. Conservez les horodatages disponibles, l’instant de réception et les critères de fraîcheur choisis pour votre usage. Un seuil utile à une position n’a pas nécessairement le même sens pour une alerte de fermeture valable toute une journée.

Dans le test, renvoyez un en-tête récent contenant une donnée devenue ancienne, puis interrompez complètement le flux. Vérifiez l’état que le voyageur voit dans les deux cas. Une dernière valeur peut rester consultable si son âge est clairement indiqué ; elle ne doit plus être annoncée comme une prévision actuelle. Documentez également ce qui manque lorsque le producteur ne fournit pas l’horodatage nécessaire. L’âge inconnu reste inconnu, même si la requête HTTP réussit.

Rendre l’effet d’une alerte compréhensible

Préparez une fermeture d’arrêt qui concerne une période limitée et un retard touchant une ligne entière. La page doit distinguer le périmètre, la durée annoncée et les personnes concernées. Conservez le texte source et la traduction réellement disponible ; une traduction éditoriale ne doit pas étendre l’alerte à une autre ligne ou transformer une information prudente en garantie de reprise.

Reliez l’alerte à la bonne étape du parcours : accéder à l’hôtel, rejoindre une excursion ou changer de gare. Une alternative doit préciser le trajet modifié et les contraintes à revérifier. Si votre système n’a pas de disponibilité ni de capacité sur le remplacement, présentez une piste d’itinéraire, pas une place réservée. Testez aussi la fin de période d’une alerte et sa disparition du flux, en gardant une trace de ce que votre règle de retrait permet de conclure.

Définir le repli et la responsabilité de suivi

Lorsque l’information temps réel devient inutilisable, choisissez une présentation de repli : horaire théorique identifié, lien vers l’opérateur ou message d’indisponibilité. Faites valider ce choix par les équipes qui assistent le voyageur. La présence d’un horaire théorique ne démontre pas que le service circule actuellement. Le repli doit permettre de comprendre l’origine de la donnée et la prochaine action utile.

Clôturez la recette avec un trajet normal, une perturbation, une donnée ancienne et une référence non rapprochée. Conservez le message anonymisé, la règle appliquée et une capture de l’état affiché. Mesurez séparément erreurs de récupération, erreurs de rattachement et manque de couverture. Un flux disponible toute la journée peut rester inutilisable pour le trajet vendu. La décision de mise en service doit nommer ce périmètre et l’interlocuteur chargé des anomalies.

Sources et périmètre des faits documentés

La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.

• GTFS : référence Realtime — Messages de mise à jour de trajet, position et alerte ; champs et relations du protocole. (consultée le 08/10/2026)
• GTFS : bonnes pratiques Realtime — Fraîcheur des messages et distinction entre horodatage du flux et des données. (consultée le 08/10/2026)
• GTFS : alertes de service — Périmètre des alertes et entités concernées. (consultée le 08/10/2026)