Peut-on mesurer les retards des bus STM directement avec cette source, ou faut-il d'abord construire un protocole d'archivage?
Pour travailler flux temps réel, métadonnées, unité statistique, variables dérivées à partir d’un contexte mobilité et performance de service lié à Réseau d'autobus de la STM.
Faire écrire explicitement ce qui est vérifié, ce qui ne l'est pas et ce qui devrait être collecté avant toute moyenne de retard.
Extrait public de la table préparée à partir de la source officielle, limité à 120 lignes pour une exploration rapide.
| TripUpdate | route_id | Identifiant de ligne ou parcours à utiliser pour les regroupements. | Champ attendu dans la spécification GTFS-realtime; non validé dans le flux ST… |
| TripUpdate | trip_id | Identifiant de trajet, utile pour relier le temps réel aux horaires planifiés. | Champ attendu dans la spécification GTFS-realtime; non validé dans le flux ST… |
| TripUpdate | stop_id | Arrêt auquel associer une mise à jour de temps de passage. | Champ attendu dans la spécification GTFS-realtime; non validé dans le flux ST… |
| TripUpdate | delay_seconds | Retard brut en secondes lorsque la mise à jour de passage contient un délai. | Champ possible dans StopTimeUpdate; à vérifier après extraction. |
| VehiclePosition | vehicle_id | Identifiant du véhicule observé dans un instantané. | Champ attendu dans la spécification GTFS-realtime; non validé dans le flux ST… |
| VehiclePosition | latitude | Coordonnée pour cartographier la position du véhicule. | Champ attendu dans la spécification GTFS-realtime; non validé dans le flux ST… |
| VehiclePosition | longitude | Coordonnée pour cartographier la position du véhicule. | Champ attendu dans la spécification GTFS-realtime; non validé dans le flux ST… |
| VehiclePosition | occupancy_status | Niveau d'occupation publié depuis la version 2 du flux, selon la documentatio… | Champ à vérifier après extraction du flux STM. |
| Archivage local | collection_time | Horodatage ajouté par le protocole d'archivage pour analyser les séries tempo… | Variable dérivée par l'équipe pédagogique. |
| Archivage local | retard_minutes | Conversion de delay_seconds en minutes pour les graphiques et les résumés. | Variable dérivée; ne pas présenter comme colonne brute garantie. |
Cette fiche ne décrit pas un CSV historique de retards déjà prêt. Elle décrit une source temps réel de la Société de transport de Montréal : le flux GTFS-realtime publié dans Données Québec pour les horaires et le positionnement des bus.
Elle est très utile pédagogiquement parce qu’elle force une distinction importante en science des données : une source opérationnelle temps réel n’est pas automatiquement un jeu de données statistique. Pour analyser la ponctualité, il faut d’abord archiver des instantanés, parser le flux, ajouter un horodatage de collecte, vérifier les champs disponibles, puis documenter les règles de calcul des retards.
Question d’analyse : comment construire un protocole reproductible pour mesurer la ponctualité à partir d’un flux temps réel, sans confondre données disponibles et conclusions sur la qualité du service?
| Élément | Résultat vérifié |
|---|---|
| Paquet CKAN | 1bcf0d8e-d67b-4291-8393-70621b0f5400 |
| Source officielle | Données Québec / Société de transport de Montréal |
| Titre CKAN | Horaires et positionnement des bus en temps réel (GTFS-realtime) |
| Ressources dans le paquet | 1 ressource |
| Ressource documentée | Horaires et positionnement des bus en temps réel |
| Format déclaré | GTFS |
| URL de ressource | Portail développeur STM |
| Licence | Attribution (CC-BY 4.0), selon les métadonnées CKAN consultées le 2026-06-21 |
| Dernière modification du paquet CKAN | 2026-06-21 |
| Table historique directement téléchargeable dans CKAN | Non vérifiée |
| Table préparée dans ce dépôt | Aucune table de retards; seulement des résumés de métadonnées et un protocole |
| Champ | Information |
|---|---|
| Page Données Québec | https://www.donneesquebec.ca/recherche/dataset/vmtl-stm-bus-temps-reel-gtfs-realtime |
| API CKAN | https://www.donneesquebec.ca/recherche/api/3/action/package_show?id=vmtl-stm-bus-temps-reel-gtfs-realtime |
| Portail développeur STM | https://www.stm.info/fr/a-propos/developpeurs |
| Organisme | Société de transport de Montréal |
| Territoire | Réseau d’autobus de la STM |
| Date d’accès | 2026-06-21 |
La description officielle indique que l’ensemble fournit les horaires, le positionnement des bus en temps réel et, depuis sa version 2, la donnée du taux d’occupation à bord des bus. Elle indique aussi que l’accès aux GTFS-realtime et à l’API i3 se fait par inscription au portail développeur STM.
Je ne sais pas. Le paquet CKAN vérifié ne publie pas une table historique dans laquelle une ligne aurait une unité statistique fixe.
Dans une table construite par l’équipe pédagogique, une ligne pourrait représenter :
Cette unité doit être choisie avant de calculer des moyennes, des proportions ou des graphiques par ligne.
| Variable pédagogique | Rôle | Statut |
|---|---|---|
collection_time |
Horodatage ajouté au moment de la collecte | Variable dérivée par le protocole |
message_type |
Type de message GTFS-realtime | À extraire du flux |
route_id |
Ligne ou parcours | À vérifier dans le flux ou par jointure GTFS |
trip_id |
Trajet | À vérifier dans le flux |
stop_id |
Arrêt | À vérifier dans les mises à jour de passage |
vehicle_id |
Véhicule | À vérifier dans les positions |
delay_seconds |
Délai brut en secondes | Champ possible, pas garanti sans inspection |
retard_minutes |
Retard en minutes | Variable dérivée de delay_seconds |
latitude, longitude |
Position du véhicule | À vérifier dans les positions |
occupancy_status |
Occupation à bord | Mentionnée par la documentation STM, à vérifier dans le flux |
La variable retard_minutes ne doit pas être présentée comme une colonne brute garantie. Elle doit être calculée seulement après avoir constaté qu’un champ de délai existe dans les messages collectés.
Les résultats ci-dessous proviennent de preparation.R, exécuté sur l’API CKAN officielle le 2026-06-21.
| Indicateur | Valeur |
|---|---|
| Ressources CKAN documentées | 1 |
| Ressources GTFS déclarées | 1 |
| Ressources pointant vers le portail développeur | 1 |
| Ressources de données directement téléchargeables | 0 |
| Compte développeur requis selon la ressource | Oui |
| Table historique disponible dans CKAN | Non |
| Lignes historiques vérifiées | Je ne sais pas. |
| Colonnes historiques vérifiées | Je ne sais pas. |
Ce résultat est une limite, pas un échec. Pour un cours de science des données, la source devient un bon cas d’étude sur la différence entre accès, collecte, données brutes et jeu analytique.
| Étape | Action | Point de contrôle |
|---|---|---|
| 1 | Créer un compte sur le portail développeur STM et obtenir une clé API. | Ne jamais publier la clé API. |
| 2 | Collecter des instantanés à intervalle fixe pendant une période définie. | Ajouter collection_time à chaque collecte. |
| 3 | Parser les messages Protocol Buffers du flux GTFS-realtime. | Conserver le type de message. |
| 4 | Joindre les identifiants au GTFS statique de la STM si nécessaire. | Vérifier que les périodes correspondent. |
| 5 | Calculer retard_minutes seulement si un délai est présent. |
Documenter la formule et les exclusions. |
| 6 | Résumer les retards par ligne, période et sens de déplacement. | Rapporter le nombre d’observations. |
| 7 | Présenter les limites avant toute conclusion. | Distinguer flux observé, fréquence de collecte et performance réelle. |
Une analyse solide doit commencer par la qualité du protocole de collecte. Par exemple, un intervalle de collecte aux 30 secondes et un intervalle aux 5 minutes ne produisent pas le même jeu de données. Les lignes très fréquentes peuvent produire davantage d’observations, et les pannes de collecte peuvent créer des trous temporels qui ressemblent à des changements de service.
Les comparaisons entre lignes doivent donc inclure un dénominateur clair : nombre d’observations, nombre de trajets, nombre d’arrêts, période de la journée ou distance parcourue. Sans cela, une moyenne de retard peut être difficile à interpréter.
| Dimension | Score | Justification |
|---|---|---|
| Contexte québécois | 3 | Source STM officielle |
| Accessibilité pédagogique | 1 | Accès développeur requis et absence de CSV historique |
| Qualité documentaire | 2 | Métadonnées CKAN claires, mais flux à inspecter séparément |
| Potentiel de nettoyage | 3 | Parsing, horodatage, jointures et validation |
| Potentiel de visualisation | 2 | Fort potentiel après archivage, mais pas immédiat |
| Potentiel de statistique descriptive | 2 | Résumés possibles après collecte |
| Potentiel d’inférence | 1 | Forte dépendance au protocole d’échantillonnage temporel |
| Potentiel de modélisation | 2 | Modélisation possible si historique stable |
| Potentiel éthique | 3 | Discussion sur service public, surveillance et interprétation |
| Réutilisabilité | 2 | Très utile en projet avancé, moins en introduction rapide |
Total : 21 sur 30.
En 45 à 60 minutes, demander aux étudiants et étudiantes de lire les métadonnées CKAN, d’identifier ce qui est vérifiable et ce qui ne l’est pas, puis de proposer l’unité statistique d’une future table de ponctualité.
En 2 à 3 heures, concevoir un protocole d’archivage reproductible : fréquence de collecte, durée, variables extraites, critères d’exclusion, dictionnaire de variables, limites et graphiques prévus.
À exécuter depuis la racine du projet.
# Load libraries
library(dplyr)
library(readr)
# Validate official CKAN metadata and write pedagogical summaries
source("datasets/retards-transport-collectif/preparation.R")
resume <- read_csv(
"data/processed/retards-transport-collectif/resume_retards_transport.csv",
show_col_types = FALSE
)
resume |>
select(
access_date,
n_resources_ckan,
n_gtfs_resources,
n_developer_portal_resources,
n_direct_download_resources,
source_requires_developer_account
)retard_minutes si la variable n’a pas été dérivée à partir d’un champ de délai vérifié.package_show pour le paquet STM GTFS-realtime. Consulté le 2026-06-21. https://www.donneesquebec.ca/recherche/api/3/action/package_show?id=vmtl-stm-bus-temps-reel-gtfs-realtimePeut-on mesurer les retards des bus STM directement avec cette source, ou faut-il d'abord construire un protocole d'archivage?
À produire : Un protocole ou une note d'audit qui distingue ce qui est vérifié, ce qui manque et ce qui ne peut pas encore être mesuré.
Comment archiver un flux GTFS-realtime pour produire une table de ponctualité utilisable en statistique descriptive?
À produire : Un protocole ou une note d'audit qui distingue ce qui est vérifié, ce qui manque et ce qui ne peut pas encore être mesuré.