Lire un résultat d’horaire régional sans lui faire dire plus qu’il ne sait

Horaire planifié, information courante et temps réel

GTFS Schedule décrit notamment les agences, arrêts, lignes, trajets, heures de passage et calendriers planifiés. GTFS Realtime peut compléter ce socle avec des mises à jour de trajet, des positions de véhicules et des alertes. Ces deux familles ne doivent pas être confondues.

Une heure issue d’un fichier planifié signifie que le service est annoncé dans la release pour la date calculée. Elle ne dit pas à elle seule si le véhicule est à l’heure aujourd’hui. Une mise à jour temps réel doit être attribuée, datée et reliée au trajet correspondant ; son absence ne signifie pas automatiquement que le véhicule circule à l’heure.

CapVirée présente aujourd’hui une faisabilité fondée sur une release officielle bornée. Le contrôle opérationnel avant départ reste le canal du transporteur. Le site n’ajoute pas la mention “temps réel” lorsqu’aucun flux public versionné ne la prouve.

Identifier la release avant de lire les heures

Une proposition fiable indique l’origine des jeux de données, la date de génération, la période couverte et l’identifiant ou l’empreinte de l’artefact calculé. Ces éléments permettent de reproduire le résultat et de savoir si la date demandée entre réellement dans le calendrier.

Une nouvelle release ne doit pas être mélangée silencieusement avec l’ancienne. Le manifeste courant pointe vers un artefact versionné ; une publication atomique évite de servir des arrêts d’une version avec les horaires d’une autre. En cas de défaut, le rollback revient à un ensemble cohérent.

Une date hors couverture produit une indisponibilité explicite. Le moteur ne prolonge pas un service hebdomadaire au-delà de la période pour laquelle l’opérateur l’a publié et n’invente pas les exceptions d’un jour férié.

• Producteur ou source officielle nommés.
• Date de génération visible.
• Début et fin de couverture connus.
• Artefact ou version identifiable.
• Date demandée incluse dans le calendrier.
• Limites de territoire et de modes affichées.

Lire le calendrier : service régulier et exceptions

Dans GTFS Schedule, le calendrier peut décrire des jours habituels sur une période et des exceptions ajoutées ou retirées à des dates précises. Un résultat ne doit donc pas être déduit du seul jour de la semaine. La date réelle doit activer le bon service après application des exceptions.

Cette distinction compte particulièrement pour les jours fériés, les vacances, les travaux planifiés ou une offre saisonnière. Le guide ne conclut pas qu’un trajet du lundi se répète tous les lundis de l’année. Il vérifie la période et l’exception disponible dans la release.

Le fuseau horaire de l’agence et les heures qui dépassent minuit demandent aussi une lecture cohérente du jour de service. L’interface doit présenter une date et une heure compréhensibles plutôt que d’exposer un détail technique ambigu.

Distinguer station, arrêt, quai et lieu final

Un fichier de transport manipule des points d’arrêt et parfois une hiérarchie de station. Le voyageur, lui, part d’une entrée réelle, rejoint un quai, descend à un autre point puis poursuit vers un lieu. Ces niveaux ne sont pas interchangeables.

Lisez le nom complet du départ et de l’arrivée, le mode, la direction et, lorsqu’elle est publiée, l’information de quai. Deux arrêts portant un nom proche peuvent se situer de part et d’autre d’un pôle. Une commune choisie ne prouve pas que le lieu culturel se trouve à proximité de l’arrêt calculé.

Ajoutez toujours le dernier kilomètre. La destination transport est le point où le moteur s’arrête ; la destination utilisateur est l’entrée du musée, du parc, de l’événement ou du rendez-vous.

Lire départ, arrivée, durée et nombre de correspondances

L’heure de départ est attachée au point de montée affiché ; l’heure d’arrivée est attachée au point de descente. La durée du trajet inclut normalement les segments et attentes calculés entre ces deux points, mais pas l’approche avant le départ ni le dernier kilomètre après l’arrivée.

Une correspondance ajoute un changement de véhicule ou de service. Sa durée théorique doit être lue avec le lieu de changement, les quais ou arrêts, la marche interne et les besoins du voyageur. Une correspondance présente dans les données n’est pas nécessairement garantie commercialement.

Comparez les propositions sur plusieurs dimensions. Le trajet le plus court peut comporter davantage de changements ; un trajet un peu plus long peut être plus lisible. CapVirée expose les horaires et correspondances, mais ne choisit pas une capacité individuelle d’orientation ou de déplacement.

Évaluer une correspondance sans promesse implicite

Pour chaque changement, notez l’heure d’arrivée, l’heure de départ suivante, le point exact et la différence. Ajoutez les informations d’accessibilité et le chemin interne lorsqu’ils sont nécessaires. Une durée mathématiquement positive peut rester inadaptée au voyageur ou à la configuration du pôle.

Vérifiez auprès du transporteur si les segments appartiennent au même titre, si une réservation s’applique et quelles règles valent en cas de perturbation. Le moteur d’itinéraire ne doit pas inventer une garantie de correspondance à partir de la seule proximité des heures.

Préparez un repli : trajet direct, correspondance plus longue ou départ antérieur. Si aucune solution prudente n’existe, la proposition peut rester visible comme résultat planifié mais ne doit pas être présentée comme recommandation sûre.

1. Nommer le point de correspondance.
2. Calculer le temps entre arrivée et départ.
3. Vérifier le chemin et les équipements nécessaires.
4. Lire les conditions du transporteur.
5. Identifier une proposition moins fragile.
6. Recontrôler l’information le jour même.

Lire les deux sens avant de parler de sortie

Un aller disponible ne constitue pas une excursion à la journée. Cherchez le retour pour la même date de service, depuis le point cohérent avec le lieu final, puis vérifiez que le temps sur place permet réellement l’activité.

CapVirée borne l’affichage : les deux premiers allers et les deux derniers retours résument les possibilités sans prétendre remplacer la recherche exhaustive du transporteur. À heure identique, le trajet le plus court est conservé, puis une heure distincte complète la sélection. Cette règle limite les doublons et reste explicable.

Le dernier retour affiché n’est pas automatiquement le meilleur. Un retour antérieur peut offrir une marge, surtout après un événement, avec une correspondance ou lorsque l’information temps réel n’est pas disponible.

Calculer le temps réellement utilisable

Le temps brut entre l’arrivée et le retour n’est pas le temps de visite. Soustrayez la sortie de gare, le dernier kilomètre aller, l’entrée, les attentes, la pause nécessaire, le dernier kilomètre retour et la marge d’accès au quai.

Comparez le solde à l’objectif minimal de la sortie. Un aller-retour techniquement combinable peut rester peu pertinent si l’accès local consomme la majorité de la plage ou si la visite exige une réservation à heure fixe.

Utilisez des durées prudentes adaptées au groupe et laissez les estimations clairement séparées des horaires officiels. Si le solde devient négatif ou trop court, l’interface doit permettre de changer la date, le retour ou la destination plutôt que de masquer le problème.

1. Noter l’arrivée au point de transport.
2. Ajouter sortie, marche ou réseau local jusqu’au lieu.
3. Réserver la marge d’entrée et l’activité minimale.
4. Calculer l’heure limite de départ du lieu.
5. Ajouter le retour vers la gare et le quai.
6. Comparer avec un retour antérieur.

Ajouter le dernier kilomètre et l’ouverture du lieu

Le résultat horaire ne sait pas nécessairement quelle entrée du lieu est ouverte, quelle marche est adaptée, quel réseau urbain fonctionne ou quelle réservation est requise. Consultez les sources du lieu, de la gare et du réseau local.

Une distance cartographique ne qualifie pas l’accessibilité. Un lieu proche peut imposer un changement de niveau, un accès particulier ou une durée incompatible avec le groupe. À l’inverse, une correspondance locale bien documentée peut rendre un lieu plus accessible qu’une marche apparemment courte.

Les guides Nantes et Angers montrent comment attribuer chaque fait à son responsable. La page horaire reste générique et ne déduit aucune promesse locale d’un nom de gare.

Reconnaître les doublons et les alternatives réellement distinctes

Deux résultats peuvent partager la même heure de départ tout en suivant des itinéraires différents. Pour une liste courte, conserver les deux sans explication peut donner une impression artificielle de choix. La règle CapVirée retient à heure identique le trajet le plus court, puis cherche une autre heure.

À l’inverse, deux horaires différents sont utiles même si la durée est proche : ils offrent une vraie décision sur l’heure de départ. Une proposition avec un autre mode ou une autre correspondance peut également être pertinente si sa différence est visible.

L’interface doit expliquer son tri et ne pas affirmer avoir exploré tout le marché des transports. Elle travaille dans les sources et la période indiquées. Une option absente peut être hors catalogue plutôt qu’inexistante.

Accessibilité : lire les champs sans conclure pour une personne

Des données de transport peuvent indiquer certaines caractéristiques d’arrêt, de station ou de véhicule. Leur présence dépend de la source et leur absence signifie souvent “non renseigné”, pas “inaccessible”. Un pictogramme ne décrit pas la chaîne complète.

Vérifiez l’assistance, l’état des équipements, les cheminements, la montée, la correspondance, la descente et l’accès au lieu auprès des acteurs responsables. Les délais de réservation ou conditions d’un service viennent de leurs pages courantes.

CapVirée ne transforme pas un champ technique en conseil individuel. Le résultat peut signaler une information disponible ou manquante, puis renvoyer vers l’autorité. Le besoin personnel ne doit pas être placé dans l’URL ou indexé.

Que faire lorsque l’information courante contredit le planifié

L’information opérationnelle plus récente du transporteur prime pour le départ réel. Une alerte peut annoncer une suppression, un arrêt non desservi, un changement de quai ou une perturbation qui rend le résultat planifié inutilisable.

Ne corrigez pas silencieusement la release éditoriale avec une observation isolée. Pour le voyage, appliquez l’instruction courante. Pour les données, signalez la divergence avec sa source afin qu’elle soit examinée, versionnée et publiée atomiquement si une correction durable est nécessaire.

En l’absence d’information temps réel, ne présumez ni retard ni ponctualité. Affichez que le résultat est planifié et invitez à vérifier le canal officiel.

Trois exemples de lecture

Erreurs fréquentes

Ce que CapVirée calcule aujourd’hui

CapVirée utilise une release officielle datée et bornée pour construire des combinaisons aller-retour, exposer horaires, durée et correspondances et calculer un temps minimal sur place. Les parcours direct et inspiration s’appuient sur le même moteur et les mêmes limites.

L’application ne vend pas de billet, ne réserve pas de place, ne promet pas le temps réel et ne qualifie pas automatiquement le dernier kilomètre ou l’accessibilité individuelle. En l’absence d’un adaptateur public versionné pour une capacité supplémentaire, le site reste fail-closed et ne simule pas le moteur.

Le bénéfice potentiel est une lecture plus rapide des deux sens et des dates couvertes. Il ne constitue pas une garantie de transport ni une supériorité universelle sur le calculateur du transporteur, qui reste le contrôle opérationnel.

Checklist avant de retenir une proposition

• Source, release et horizon identifiés.
• Date réelle activée dans le calendrier.
• Départ, arrivée, sens et modes compris.
• Correspondances et marges qualifiées.
• Aller et retour compatibles.
• Temps utile calculé après dernier kilomètre.
• Ouverture et accessibilité du lieu vérifiées.
• Titre contrôlé séparément.
• Information courante relue avant départ.
• Repli ou retour antérieur connu.

Sources, date de révision et correction

Les définitions de données planifiées et temps réel s’appuient sur les références GTFS Schedule et GTFS Realtime. Les jeux SNCF et Aléop identifient les sources du pilote. Le transporteur reste responsable de l’information courante et des conditions commerciales.

Dernière révision humaine : 25 août 2026. Les horaires, quais, alertes, équipements et conditions de vente doivent être vérifiés pour le trajet réel. Le guide décrit une méthode stable et n’archive pas une observation opérationnelle comme vérité permanente.

Une divergence peut être signalée avec l’URL publique, la date et la source concernées, sans billet, identité, position personnelle ou besoin de santé.