1. Combien de trains ont été touchés ?
Circulations perturbées
Le nombre de trajets (un train, un jour donné) ayant eu du retard à un moment
de leur trajet — même s'ils l'ont ensuite rattrapé avant l'arrivée.
Prenons une période avec 200 circulations sur l'axe Paris-Cherbourg.
40 d'entre elles ont eu du retard à un moment de leur trajet.
→ Affiché : « 40 circulations perturbées / 200 (20 %) »
Utile pour : avoir en un coup d'œil une idée de l'ampleur des perturbations du jour
ou de la semaine — une bonne ou une mauvaise période pour la ligne, « à quel point
la journée a été mauvaise ».
« Circulations perturbées » vs « ponctualité » ? La ponctualité officielle SNCF/ART
(Autorité de Régulation des Transports) mesure uniquement le retard à l'arrivée au
terminus. Un train retardé de 10 minutes entre Caen et Lison mais qui arrive à l'heure
à Cherbourg sera compté comme 100 % ponctuel dans les statistiques officielles,
ignorant la perturbation subie par les voyageurs descendant à Lison. Notre indicateur
compte tout train ayant subi un retard à un moment quelconque de son trajet, même s'il
a été rattrapé ensuite — mais seulement les circulations avec un retard réellement
connu et confirmées arrivées à leur terminus. La ponctualité officielle évalue la
performance au terminus ; le taux de « circulations perturbées » reflète l'impact réel
vécu tout au long de la ligne.
Le tooltip précise aussi « issues de X trains différents parmi les Y du référentiel » —
X peut dépasser Y sans que ce soit un problème actuel. Le référentiel est reconstruit à
partir d'un export SNCF limité à une fenêtre glissante d'environ 151 jours : une
variante d'horaire ancienne peut en sortir au fil des régénérations et disparaître du
référentiel, même si le train a bien circulé et reste compté dans X. Pour savoir si le
référentiel est à jour maintenant, voir « Vérification GTFS » plus bas.
Retard cumulé (reflète l'état final réel)
La somme des retards observés, en ne comptant chaque passage en gare qu'une seule fois
(le dernier retard connu à ce passage) — pas à chaque fois que le système a vérifié ce train.
Nos 40 circulations perturbées ont, ensemble, touché 90 passages en gare
(un même train peut être en retard à plusieurs gares).
Ces 90 passages cumulent 15 h de retard au total.
→ Affiché : « Retard cumulé : 15 h 00 min »
(le détail « 90 passages impactés » n'apparaît qu'au-dessus du graphique de
l'onglet Graphique, pas dans cette barre de stats du haut)
Utile pour : comparer deux journées ou deux semaines entre elles sur le volume réel
de perturbation, ou chiffrer le temps perdu cumulé sur l'axe Paris-Cherbourg (utile
pour un dossier ou un argumentaire auprès de la SNCF).
Cette stat ne garde que le dernier retard connu par gare — si pour ce train, le dernier
relevé montre 0 min partout, du départ à l'arrivée, donc aucun « passage impacté »
comptabilisé pour lui, même si des retards ont pu être observés plus tôt.
Retard moyen / relevé (reflète toute l'histoire des prédictions même corrigées)
La moyenne de tous les relevés individuels du système (chaque interrogation, gare
par gare) — pas une moyenne par train ni par passage.
Ce même jour, le système a fait 8 000 relevés au total (la plupart à 0 min ou
vite corrigés : un train à l'heure reste à l'heure à chaque relevé). La somme
de tous les retards fait 900 minutes.
→ Affiché : « Retard moyen / relevé : 900 ÷ 8 000 = 0.1 min »
Utile pour : avoir un ordre de grandeur pour interpréter l'échelle de la courbe
d'évolution du retard dans le temps (onglet Graphique) — un écart soudain entre
« moy. » et « Retard moyen / relevé », le premier qui grimpe bien plus vite que le
second, trahit souvent un incident ponctuel (coupure partielle de collecte/flux SNCF
figé) plutôt qu'un vrai pic de retard généralisé.
Ce chiffre paraît minuscule à côté d'un retard max de 45 min — c'est normal, il est
dilué par des milliers de relevés à 0. À ne pas confondre avec la courbe de l'onglet
Graphique : celle-ci calcule une moyenne différente (instant par instant, puis ces
points sont moyennés entre eux) — les deux donnent un ordre de grandeur similaire,
rarement le chiffre exact.
Accessoirement, elle capture le volume de signaux d'alerte temporaires vus par le
système en temps réel, même corrigés ensuite — une sorte de « volatilité » des
prédictions plutôt qu'un résultat final.
2. Où et sur quel train le retard a-t-il été le plus fort ?
Retard max
Le plus grand retard observé sur la période, avec le train concerné.
→ Affiché : « Retard max : train 1234 → 45 min »
Ce train a connu le pire retard de la période, 45 minutes, quelque part sur son trajet.
Utile pour : repérer tout de suite le pire incident de la période, celui qui a le
plus affecté un train en particulier.
Le flux temps réel SNCF ne confirme jamais explicitement l'arrivée d'un train : le
trajet disparaît simplement du flux une fois terminé, souvent juste après l'heure
d'arrivée prévue. Ce retard max (et plus généralement toute valeur affichée pour un
trajet, y compris dans l'onglet « Suivi d'un train ») correspond donc à la dernière
prédiction connue avant cette disparition, pas à une confirmation réelle d'arrivée —
dans l'immense majorité des cas les deux se rejoignent, mais rien ne le garantit formellement.
Retard moyen le + élevé
La gare avec le retard moyen le plus élevé, tous relevés confondus (y compris ceux à 0 min).
→ Affiché : « Retard moyen le + élevé : Bayeux → moy 3.6 min »
En moyenne sur tous les relevés de la période, Bayeux affiche 3.6 min de retard
— la valeur la plus haute des 11 gares de la ligne.
Utile pour : voir si les problèmes se concentrent sur un point précis de la ligne
(travaux, nœud engorgé) plutôt que d'être répartis partout.
Cette moyenne compte à plat chaque relevé individuel, pas chaque train — un seul train
très en retard, sondé à répétition tant qu'il reste dans le flux temps réel, peut donc
suffire à faire basculer ce classement. Rien dans ce chiffre ne permet de savoir si une
gare l'emporte à cause d'un vrai problème touchant plusieurs trains, ou simplement parce
qu'un train y est resté sondé plus longtemps — un signal à creuser (aller regarder
l'onglet Circulations pour cette gare), pas un verdict.
Les couleurs de l'onglet Circulations
Trois couleurs de texte dans l'onglet Circulations, selon le retard observé au dernier
relevé d'une ligne — pas de couleur (texte noir) si tout va bien.
Rouge : retard à l'arrivée ≥ 10 min dans cette gare.
Orange : retard à l'arrivée entre 5 et 10 min dans cette gare.
Doré/jaune : arrivée correcte (< 5 min), mais retard au départ ≥ 5 min
— le train reste immobilisé plus longtemps que prévu à cette gare.
Utile pour : repérer d'un coup d'œil non seulement l'ampleur d'un retard, mais aussi
son type : un retard déjà là à l'arrivée (rouge/orange) n'annonce pas la même chose
qu'un train à l'heure qui traîne au départ (doré).
Le doré existe pour un cas précis qui resterait sinon invisible : un train arrivé
pile à l'heure n'a aucune couleur d'alerte si on ne regarde que le retard à l'arrivée
— alors qu'il peut être en train d'accumuler un vrai retard de départ, pas encore
visible ailleurs. Sans cette couleur séparée, ce genre de ligne resterait noire, comme
si de rien n'était, jusqu'à ce que le retard finisse par apparaître à la gare suivante.
Ligne dorée : incident frais, ou connu ? (non distingué par l'appli)
Le doré signale qu'un train attend plus longtemps que prévu au départ d'une gare —
sans dire depuis quand cette attente est connue.
Cas 1 — nouveau : le train vient d'annoncer une attente imprévue (incident,
croisement non planifié) — un vrai signal à surveiller.
Cas 2 — déjà connu : l'attente est annoncée depuis longtemps (dès le départ du
trajet, ou depuis plusieurs relevés) — la SNCF le sait déjà, ce n'est pas une
surprise, juste un aléa stable.
Utile pour : éviter de s'alarmer pour une ligne dorée qui traîne en réalité depuis
des heures sans rien de nouveau — mais l'application ne permet actuellement aucun
moyen, ni automatique ni manuel, de le vérifier.
Distinguer les deux cas demanderait de comparer ce retard de départ à ce qu'il valait
aux relevés précédents de ce même train, pas juste au dernier — une fonctionnalité
jugée utile seulement en surveillance active de l'appli (voir si un problème vient
d'apparaître), sans intérêt pour les statistiques ou les rapports PDF (qui ne retiennent
de toute façon que la dernière valeur connue) — pas construite pour l'instant.
« Suivi d'un train » ne peut pas non plus aider : ses deux vues tracent le retard à
l'arrivée dès qu'il est connu et ignorent alors le retard au départ. Ce retard au
départ n'est visible nulle part ailleurs que dans la colonne « Dép. » du Tableau.
3. Autres points utiles — rapports PDF quotidien/hebdomadaire/mensuel
« Circulations sur l'axe Paris ↔ Cherbourg »
Le rapport ne suit pas seulement les trains Paris-Cherbourg de bout en bout : il suit
tout train empruntant un tronçon de cette ligne, même s'il continue ailleurs ensuite.
Un train Rennes → Caen, qui partage les gares de Lison, Bayeux et Caen avec la
ligne Paris-Cherbourg, est inclus dans les statistiques — même s'il ne va jamais
jusqu'à Paris ni jusqu'à Cherbourg.
Utile pour : comprendre pourquoi des trains qu'on ne prend pas forcément soi-même
(ex: Rennes → Caen) apparaissent dans les statistiques du rapport.
C'est volontaire : un retard survenu sur un tronçon partagé est un vrai signal utile
pour la ligne, qu'il vienne d'un train qui va jusqu'au bout ou non.
Période du rapport (2 h → 2 h)
Le rapport quotidien couvre une journée de 2 h du matin à 2 h le lendemain
(pas minuit à minuit, ni les 24 dernières heures).
Un rapport généré le 28/07 à 7 h couvre la période du 27/07 à 2 h au 28/07 à 2 h
— le dernier cycle complet déjà terminé.
Utile pour : comparer les rapports entre eux de façon cohérente d'un jour sur l'autre,
avec une même définition de « journée ».
2 h du matin est le creux du trafic nocturne (peu ou pas de trains) : ça limite le
risque qu'une circulation soit coupée en deux périodes différentes.
Météo et Perturbations
Moyennes météo (température, pluie, vent) et liste des perturbations SNCF en cours
sur l'axe Paris-Cherbourg pendant la période — sans traitement particulier, affichées
telles que publiées par les sources.
Rien à calculer ici — ces deux blocs sont les plus simples du rapport.
Utile pour : vérifier si un pic de retard coïncide avec une cause probable
(mauvais temps, travaux signalés).
Circulations annulées
Nombre de trains entièrement annulés sur la période, parmi ceux qui desservent au
moins une des 11 gares de la ligne — invisibles de toutes les autres statistiques
ci-dessus (un train annulé n'atteint jamais son terminus, donc jamais considéré
comme « arrivé »).
→ Affiché : « Circulations annulées sur la période (sur l'axe Paris-Cherbourg) : 2 (852610, 853430). »
Utile pour : voir d'un coup d'œil si des trains ont été purement et simplement
supprimés — une perturbation plus grave qu'un simple retard, mais invisible du
reste du rapport.
Rupture de collecte le 31/07/2026
Un bug de collecte, corrigé ce jour-là, faisait manquer jusqu'à ~1 train sur 4
certains jours (un identifiant technique mal reconnu, sans rien signaler). Les
statistiques globales augmentent donc mécaniquement à partir de cette date.
Avant le 31/07/2026 : jusqu'à ~27 % des trains manqués certains jours.
Après : quasi tous les trains sont captés.
Utile pour : ne pas confondre une hausse des chiffres autour de cette date avec une
vraie dégradation de la ponctualité.
L'identifiant technique d'un train intégrait une date qui ne correspondait plus
toujours à la date réelle — corrigé, mais sans effet rétroactif sur l'historique
déjà collecté.
4. L'onglet « Vérification GTFS » : les horaires suivis sont-ils toujours à jour ?
À quoi sert cet onglet
Compare chaque jour les horaires théoriques publiés en ligne par la SNCF à ceux
utilisés par l'application (un fichier de référence, mis à jour manuellement de
temps en temps) — pour repérer quand cette référence devient obsolète.
Une ligne du tableau : « 589 communs (546 identiques, 43 modifiés), 160 disparus,
4 nouveaux, 2 renommés » — comparé à la référence actuellement utilisée.
Utile pour : savoir si les trains suivis par l'application correspondent encore aux
horaires réels de la SNCF, sans avoir à comparer les fichiers à la main.
La référence n'est jamais mise à jour toute seule : la SNCF republie ses horaires en
continu, et un changement (nouvel horaire, nouvel arrêt, nouveau train) doit être
vérifié avant d'être appliqué, pas remplacé silencieusement.
La colonne « Nouveaux » (le chiffre le plus important)
Le nombre de trains présents dans les horaires SNCF en ligne, mais absents de la
référence utilisée par l'application — ces trains-là ne sont actuellement suivis par
aucun des relevés de l'application.
« Modifiés »/« Disparus » : un horaire théorique affiché peut être un peu faux,
mais le train reste suivi.
« Nouveaux » : le train n'est suivi du tout — aucun relevé, aucune statistique
ne le concerne.
Utile pour : décider quand une mise à jour de la référence (bouton dédié, ou
manuellement) est vraiment nécessaire, plutôt que de réagir à chaque petite variation.
Les horaires SNCF publiés en ligne ne couvrent jamais que les ~151 prochains jours,
une fenêtre qui avance d'un jour chaque jour. Un train déjà prévu par la SNCF mais
plus loin dans le temps devient visible d'un coup le jour où cette fenêtre l'atteint
— sans que la SNCF n'ait rien changé de son côté. Ça peut faire bouger légèrement les
chiffres d'un jour sur l'autre sans signification particulière (observé : 135 puis
160 trains « disparus », 5 puis 4 « nouveaux », entre deux vérifications à quelques
heures d'écart, sans aucun changement réel d'horaire entre-temps).
D'où la règle simple à suivre : ne pas s'inquiéter d'un chiffre isolé sur un seul
jour, mais surveiller si « Nouveaux » reste supérieur à zéro plusieurs jours de suite
dans le tableau — c'est ce qui distingue un vrai changement durable d'un simple effet
de la fenêtre glissante.
La colonne « Renommés »
Un service dont les arrêts et les horaires sont restés exactement identiques, mais
dont l'identifiant technique a changé — ni vraiment disparu, ni vraiment nouveau.
La SNCF réattribue parfois un service à une route légèrement différente (ex: un car
de substitution détaché de la ligne principale vers une route ad hoc) sans toucher ni
aux arrêts ni aux horaires. Sans traitement particulier, ce même service apparaîtrait
à la fois comme « disparu » et « nouveau ».
Utile pour : ne pas confondre un simple changement d'identifiant (sans conséquence
réelle) avec un vrai changement de desserte — « Renommés » reste un signal plus faible
que « Nouveaux »/« Disparus » distincts.
Détecté par rapprochement strict : seuls les services ayant exactement les mêmes
arrêts et les mêmes horaires des deux côtés sont comptés en « renommé » — un service
remplacé par un autre proche mais pas identique (quelques minutes d'écart) reste compté
en disparu + nouveau distinct, pas noyé ici.
« Régénérer » et « Déployer vers la VPS » (mettre à jour la référence — application desktop uniquement, absent de cette version web)
Deux boutons séparés, en deux étapes volontairement distinctes, disponibles
uniquement dans l'application desktop (Tkinter) — cette version web reste
volontairement en lecture seule tant qu'il n'y a pas d'authentification. « Régénérer »
télécharge l'horaire SNCF du jour et reconstruit la référence — sur ce PC uniquement,
sans rien changer côté VPS. « Déployer vers la VPS » envoie ensuite cette nouvelle
référence là où elle compte vraiment : la VPS, qui collecte les données en continu et
héberge cette même application web.
Avant l'envoi, une confirmation rappelle les deux versions en jeu :
« Référentiel actuellement sur la VPS : 2026-07-19
Référentiel local à déployer : 2026-08-04 »
Utile pour : mettre à jour la référence sans ligne de commande, tout en gardant la
main à chaque étape — rien ne part vers la VPS sans un clic de confirmation explicite.
Séparer « Régénérer » (local, sans conséquence) de « Déployer » (touche la collecte
et cette appli web, toutes deux en production sur la VPS) évite qu'une régénération
machinale ne modifie sans le vouloir ce qui tourne réellement. Une fois déployée, la
vérification GTFS est aussitôt relancée là-bas — sans ça, le seuil d'alerte resterait
basé sur l'ancienne référence jusqu'au prochain passage automatique (3h15) — et le
service web est redémarré automatiquement pour qu'il recharge la nouvelle référence
tout de suite : sans ce redémarrage, des champs comme « Sens »/« Heure théo. »
resteraient silencieusement basés sur l'ancienne version pour toute circulation ayant
changé.
Sources des données
Retards en temps réel : proxy.transport.data.gouv.fr (flux GTFS-RT SNCF, public, sans clé)
Météo actuelle : observations réelles Météo-France (réseau de stations au sol RADOME/ETENDU, nécessite une clé API personnelle gratuite) — repli automatique sur api.open-meteo.com (prévisions, sans clé) en cas d'indisponibilité
Horaires théoriques (référence des trajets/arrêts) : eu.ftp.opendatasoft.com/sncf/plandata (GTFS statique SNCF)
Jours fériés : calendrier.api.gouv.fr
Vacances scolaires (zone B) : data.education.gouv.fr
Cause d'une annulation (Perturbations) : api.sncf.com (API SNCF/Navitia, nécessite une clé API personnelle gratuite) — sans elle, l'annulation reste affichée mais sans cause précisée
Toutes ces sources sont publiques et gratuites ; Météo-France et l'API SNCF nécessitent chacune une clé API personnelle (gratuite).