De la fiche horaire au calcul multimodal : comment l’information voyageurs a changé

Le Web sépare la ressource, la recherche et l’information courante

Avec les sites de transport, un même réseau peut publier une fiche de ligne, un moteur d’itinéraire, une page tarifaire, des conditions de vente et des perturbations. Ces ressources ont des rythmes différents. Une grille annuelle ne remplace pas une alerte du jour ; une alerte ne décrit pas toutes les heures planifiées.

Le voyageur passe d’une lecture de document à une suite de requêtes. Il saisit départ, arrivée et date, puis reçoit une ou plusieurs propositions. Cette commodité peut masquer la couverture : le moteur n’explique pas toujours quels opérateurs, modes ou dates sont absents.

Un guide fiable garde donc la provenance visible. Il distingue la donnée utilisée pour présélectionner, l’information courante du transporteur et le contrat de transport obtenu lors de l’achat.

• Horaire planifié : ce qui est publié pour une période.
• Information dynamique : ce qui change à court terme.
• Résultat calculé : combinaison produite par un moteur.
• Billet : droit de voyager selon ses conditions.
• Guide : aide à relier transport, lieu et décision.

GTFS rend l’horaire échangeable entre plusieurs outils

GTFS Schedule définit un ensemble de fichiers texte structurés pour agences, arrêts, lignes, trajets, heures et calendriers. Cette convention permet à un producteur de publier l’offre planifiée dans un format compris par différents logiciels. Les fichiers sont reliés par des identifiants et regroupés dans un jeu cohérent.

La référence distingue les éléments requis, conditionnels et facultatifs. Un jeu minimal peut calculer des trajets sans contenir tarifs, cheminements en gare ou accessibilité complète. La conformité syntaxique n’établit donc pas l’exhaustivité métier.

GTFS Realtime constitue une partie distincte destinée notamment aux mises à jour de trajet, alertes et positions. La présence d’un jeu statique n’implique pas un flux temps réel. CapVirée emploie une release planifiée et ne la présente pas comme dynamique.

Les identifiants remplacent les rapprochements par simple nom

Sur une fiche papier, le contexte aide à comprendre qu’un nom désigne une gare, un arrêt routier ou deux points proches. Dans un jeu structuré, chaque agence, arrêt, ligne et trajet reçoit un identifiant. Les relations se font avec ces clés, pas avec une ressemblance typographique. Deux arrêts appelés « Gare » peuvent appartenir à des communes différentes ; inversement, deux identifiants distincts peuvent représenter des quais ou zones d’une même station.

Le calculateur doit préserver l’identifiant du producteur et documenter toute table de correspondance locale. Fusionner automatiquement sur le nom expose à relier les mauvais points. Renommer pour l’affichage ne doit pas changer la clé technique. Lorsqu’un producteur renouvelle ses identifiants, l’import compare l’ancienne et la nouvelle release, signale les ruptures puis publie la nouvelle version de façon atomique.

Pour le voyageur, cette mécanique devient une question concrète : le point proposé correspond-il bien à l’entrée et au mode attendus ? L’écran doit afficher un libellé intelligible, la commune ou le contexte nécessaire et, lorsque disponible, une localisation utile. Il ne doit pas prétendre connaître le quai courant à partir du seul fichier planifié.

2017–2019 : l’information multimodale entre dans un cadre de mise à disposition

Le règlement délégué européen 2017/1926 traite la mise à disposition de services d’informations sur les déplacements multimodaux. Il distingue notamment données statiques et dynamiques et prévoit des points d’accès nationaux. Le droit français organise cette mise à disposition dans le code des transports, notamment à l’article L1115-1 dans sa version consultée.

Ce cadre explique pourquoi un service peut agréger des données provenant de plusieurs détenteurs tout en devant conserver leur provenance et leur actualité. Il ne garantit pas que toutes les données utiles à une excursion sont disponibles dans le même format ou à la même fréquence.

Le texte officiel doit être relu pour son périmètre exact ; ce guide ne fournit pas d’analyse juridique. Pour l’utilisateur, la conséquence pratique est plus simple : un jeu ouvert peut alimenter plusieurs calculateurs, mais chacun doit afficher ce qu’il couvre et ce qu’il ignore.

Le point d’accès national facilite la découverte, pas la qualité automatique

transport.data.gouv.fr référence des jeux de données de mobilité, dont les horaires et circuits Aléop utilisés par le pilote. SNCF Open Data publie aussi des ressources horaires. Un catalogue aide à trouver la source, son producteur et parfois sa licence ou sa couverture.

Le consommateur doit encore télécharger, valider, dater, dédupliquer et transformer. Deux jeux peuvent employer des identifiants différents pour une même gare, se chevaucher sur certaines lignes ou couvrir des périodes distinctes. Une absence de ligne peut signifier hors périmètre, expiration ou défaut de publication.

Le pipeline CapVirée produit un artefact compact versionné à partir des sources retenues. Il refuse les calendriers périmés ou incomplets et conserve les limites visibles. L’ajout futur d’un réseau exige un connecteur et des contrôles, pas une promesse nationale.

1. Identifier le producteur et l’URL stable.
2. Télécharger une version datée.
3. Valider structure, période et identifiants.
4. Mettre en quarantaine les lignes invalides.
5. Dédupliquer selon une règle documentée.
6. Construire un artefact atomique.
7. Conserver le précédent pour rollback.
8. Publier couverture et fraîcheur avec l’artefact.

Une release doit avoir une identité, une période et une preuve de contrôle

Le nom d’un fichier téléchargé ne suffit pas à prouver ce qui a été calculé. Une release exploitable conserve l’URL source, le producteur, l’instant de collecte, la période de service observée, l’empreinte du fichier et le résultat des validations. Cette identité permet de reproduire un résultat et de distinguer une donnée nouvelle d’un simple téléchargement du même contenu.

La période utile se lit dans les calendriers, leurs exceptions et, lorsqu’il existe, le fichier d’information du feed. Un jeu peut être techniquement lisible mais ne couvrir aucune circulation à la date demandée. L’import doit donc contrôler des dates de service réelles et non seulement la présence des fichiers requis. Les relations orphelines, heures invalides et références absentes restent en quarantaine plutôt que supprimées sans trace.

La publication atomique active ensemble index, données et métadonnées. Si la nouvelle release échoue, la dernière version verte peut servir de rollback seulement tant que sa période reste pertinente ; elle ne doit pas être prolongée silencieusement. L’utilisateur voit alors une indisponibilité ou une couverture limitée plutôt qu’un trajet fabriqué à partir d’un mélange de versions.

• URL et producteur conservés
• Collecte et période de service datées
• Empreinte du contenu
• Validations et quarantaine explicites
• Activation atomique
• Rollback borné par la fraîcheur

Du document au calcul : davantage d’automatisation, davantage de contrôles

Une personne lisant une fiche détecte parfois une note ou une incohérence grâce au contexte. Un import automatisé peut traiter des milliers de lignes et propager rapidement une erreur si le schéma, les dates ou les relations ne sont pas contrôlés.

Le calculateur doit interpréter calendrier, exceptions, ordre des arrêts et correspondances. À heure identique, CapVirée retient le trajet le plus court puis un horaire distinct. Cette règle est une décision produit explicable ; elle ne vient pas du format GTFS lui-même.

La publication atomique évite de servir un mélange de deux versions. Les checkpoints, tentatives avec backoff, limites de débit et métriques concernent l’ingestion ; l’utilisateur voit surtout la date, la couverture et l’indisponibilité lorsqu’un renouvellement échoue.

L’information en temps réel ne remplace pas le planifié

Le planifié répond à « que devrait-il circuler ? ». Le dynamique répond à « que sait-on maintenant ? ». Une alerte peut annuler ou modifier une circulation ; elle ne suffit pas à construire tout le calendrier d’une journée. Les deux doivent être reliés avec des identifiants et une fraîcheur connue.

Une position de véhicule ou un retard calculé peut devenir obsolète en quelques instants. Il serait trompeur de la mettre en cache comme une destination éditoriale. À l’inverse, une page guide stable peut être servie longtemps tant que ses horaires changeants restent des liens vers la source.

CapVirée ne consomme actuellement pas de temps réel qualifié dans la release publique. Le site utilise donc les termes horaire planifié et vérification transporteur, sans annoncer une alerte ou une garantie.

• Planifié et dynamique séparés
• Horodatage visible
• Source et identifiant conservés
• Donnée expirée refusée
• Cache court pour l’instable
• Guide stable sans recopier une circulation

Accessibilité et assistance ne se déduisent pas d’un horaire

Une donnée planifiée peut décrire certains attributs d’accessibilité d’un arrêt, d’un trajet ou d’un véhicule, selon ce que le producteur renseigne. Un champ absent ne signifie ni accessible ni inaccessible. Il indique seulement que le jeu consommé ne permet pas de conclure. L’état réel peut aussi dépendre d’un ascenseur, de travaux, d’une réservation d’assistance, du matériel en circulation ou du chemin entre deux modes.

Le service numérique doit présenter la valeur et sa provenance sans transformer « inconnu » en réponse rassurante. Avant un trajet nécessitant une assistance ou un équipement précis, le voyageur consulte le canal d’accessibilité du transporteur, vérifie les conditions et conserve une marge adaptée. Pour un lieu, l’accès depuis l’arrêt et l’accessibilité de l’établissement restent deux contrôles différents.

Cette séparation évite qu’un calcul multimodal apparemment complet masque un segment impraticable. CapVirée peut exposer ce que sa release qualifiée contient et renvoyer vers la source courante ; il ne réalise pas un diagnostic individuel et ne garantit pas une chaîne accessible de bout en bout.

Le dernier kilomètre reste hors de nombreux jeux régionaux

Un calcul peut arriver à la bonne gare tout en laissant le voyageur loin de son lieu. Les cheminements, sorties, réseaux urbains, navettes événementielles, accessibilité et horaires de fermeture proviennent souvent d’autres producteurs.

Relier ces sources exige une géographie cohérente, des identifiants ou des coordonnées et une politique de fraîcheur propre. Une distance à vol d’oiseau ne décrit pas un itinéraire piéton ; un arrêt portant le nom d’un lieu ne garantit pas qu’il soit accessible ou desservi au retour.

Les pages Nantes, Angers et V and B Fest’ restent donc bornées à des accès publiés par les lieux ou organisateurs. Cette prudence limite le volume mais améliore l’utilité réelle.

Lire un résultat comme une chaîne de preuves, pas comme une promesse

Avant de retenir une proposition, relevez le départ et l’arrivée exacts, la date, les correspondances, le temps sur place et la version des données. Vérifiez ensuite séparément le dernier kilomètre, l’ouverture du lieu, le titre de transport et l’information courante. La précision d’une heure à la minute ne prouve pas que le jeu est frais ou que le véhicule circulera.

Une proposition devient fragile lorsqu’elle dépend d’une correspondance très courte, d’un dernier retour sans repli, d’un arrêt ambigu ou d’un lieu qui ferme peu après l’arrivée. Elle peut rester utile comme piste, mais doit afficher la dépendance au lieu de recevoir la même présentation qu’un parcours avec marge. L’utilisateur peut alors comparer non seulement la durée, mais aussi le nombre de points à revérifier.

Conservez les références nécessaires à la décision — billet, réservation et pages officielles — sans copier des données personnelles dans le guide ou l’URL. Le jour du départ, une vérification courte auprès du transporteur remplace la relecture de tout le dossier. Si une information essentielle reste absente, choisissez un repli ou renoncez à présenter le trajet comme praticable.

1. Confirmer points, date et sens du trajet.
2. Lire version, période et source des horaires.
3. Évaluer correspondances et marges.
4. Qualifier gare, marche, réseau local ou navette.
5. Vérifier ouverture et accessibilité du lieu.
6. Choisir le titre sur le canal officiel.
7. Prévoir un retour antérieur ou une alternative.
8. Recontrôler l’information courante avant le départ.

Cas concret : la même sortie lue à trois époques

Avec une fiche papier, le voyageur repère manuellement un aller et un retour, téléphone ou consulte un document séparé pour le lieu, puis note les heures. Il comprend directement la grille mais doit résoudre seul les correspondances et mises à jour.

Avec un moteur Web, il saisit départ, arrivée et date. L’outil calcule une proposition, puis le voyageur consulte tarifs, perturbations et lieu dans d’autres pages. Le moteur accélère la lecture mais son périmètre peut rester invisible.

Avec une application d’inspiration comme CapVirée, le départ et la date peuvent précéder le choix de destination. L’outil explique temps sur place, correspondances et couverture, puis renvoie vers un guide pratique. La décision reste conditionnée au dernier kilomètre et à la vérification officielle.

Reconnaître les cinq erreurs de lecture les plus fréquentes

La première erreur consiste à chercher une heure sans appliquer le calendrier et ses exceptions. La deuxième confond le nom d’une ligne avec une circulation précise. La troisième traite une donnée planifiée comme une information en temps réel. La quatrième suppose que l’arrivée à une gare vaut arrivée au lieu. La cinquième déduit un tarif ou une validité de billet d’un horaire qui ne contient pas le contrat de vente.

Un outil peut prévenir ces erreurs en affichant date, sens, source, période, correspondances, couverture et limites près du résultat. Il doit aussi conserver l’état inconnu au lieu de compléter les champs absents. Une alerte générique placée au bas de la page ne compense pas une interface qui présente toutes les propositions comme certaines.

Pour auditer un service, rejouez un cas avec exception de calendrier, un arrêt homonyme, une correspondance courte, une destination sans dernier kilomètre documenté et une date hors couverture. Le comportement attendu n’est pas toujours un trajet : un refus explicite, une donnée inconnue ou une invitation à vérifier peuvent être les réponses les plus fiables.

Ce que cette histoire change dans la pratique

Le progrès utile n’est pas le nombre de résultats mais la capacité à expliquer d’où ils viennent et quand ils cessent d’être fiables. Une release doit avoir une identité, une période et un rollback. Une page événementielle doit porter une date d’expiration. Un tarif doit rester chez sa source officielle.

Le voyageur gagne à conserver une méthode stable malgré les outils : définir son besoin, vérifier la couverture, lire le résultat, ajouter le dernier kilomètre, contrôler l’information courante et prévoir un repli. Cette méthode fonctionne avec une fiche, un moteur ou CapVirée.

Dernière révision humaine : 9 septembre 2026. Le cadre juridique est présenté comme contexte général, sans avis individuel. Les capacités CapVirée sont limitées à la release publique qualifiée et ne sont pas déduites des possibilités générales de GTFS.

• Provenance avant volume
• Fraîcheur avant disponibilité apparente
• Planifié distinct du temps réel
• Couverture visible
• Dernier kilomètre qualifié
• Source officielle avant départ