OPEN DATA SNCF

Il y a quantité de choses, dont notamment l'API temps réel, mais aussi plusieurs centaines de jeux de données moins changeantes (notamment la moitié concernant SNCF Réseau1)
En voici une liste évidemment non exhaustive :

SNCF Mobilités

  • Le temps réel TGV, TER, INTERCITÉS, EUROSTAR, THALYS via l'API
  • Les horaires théoriques TGV, TER, INTERCITÉS, TRANSILIEN
    • Via l'API
    • Au format GTFS (sauf TGV)
  • Liste des gares et leur identification
  • Des données de régularités (non détaillées)
  • Des données RH

SNCF Réseau

  • Lignes (par déclivité, vitesse, type, etc.)
  • Courbes des voies
  • Positions, identification et types de signaux
  • Des données financières

Le temps réel Transilien n'est pas proposé par ce moyen, on en parle sur la page dédiée.

Tout dépend du besoin.
S'il s'agît du temps réel, alors il faut demander une clé d'API (150000 requêtes par mois gratuitement, largement suffisant pour tous les usages). Pour tout le reste, c'est disponible simplement via https://ressources.data.sncf.com/explore

Notes sur le format GTFS (horaires théoriques) : Attention, pour pouvoir téléchargement automatiquement la dernière version, il faut interroger l'API pour obtenir le lien vers le dernier fichier zip (le « latest.zip » n'est pas le dernier !).

Suivent quelques exemples qui ont vocation à s'étoffer au fil du temps, n'hésitez pas à proposer, compléter, ajouter du contenu.

Horaires au format GTFS

Le format GTFS est le format standard mondial de mise à disposition des données théoriques de transport. Il contient les horaires, les arrêts, les lignes, les dates, etc.
La documentation de Google est particulièrement explicite et bien construite : https://developers.google.com/transit/gtfs/reference/
L'avantage du format GTFS est son côté très normé (une instance personnelle de Navitia (open-source) par exemple, saura importer directement du GTFS pour reproposer les même services que ceux de l'API SNCF). Voir aussi la partie maîtrise du nombre de requêtes.

Récupérez une clé via https://data.sncf.com/api/fr/register et c'est tout bon ! Il s'agîra de votre « token » que vous pourrez notamment utiliser sur le playground de Navitia, formidable outil pour pouvoir se familiariser avec les concepts de l'API.

Le playground

Entrez l'url de l'API Navitia à utiliser, ici https://api.sncf.com/v1 ainsi que votre token. Il faudra ajouter également un premier élément (surlignage vert) nommé « coverage » et contenant « sncf », et c'est tout, l'API est prête à être interrogée !

Ensuite, il faut intégrer le « langage » de l'API, avec les exemples suivant nous allons essayer de couvrir les thèmes principaux.

Horaires théoriques

Pour récupérer les horaires TER par exemple, environ 27500 trains et variantes, vous devez régler :

  • un élément (en vert) nommé physical_modes contenant physical_mode LocalTrain
  • un élement (en vert) nommé vehicle_journeys contenant rien
Pensez à cliquer sur ADD sinon le paramètre/élement n'est pas pris en compte !

Vous demandez donc d'obtenir toutes les circulations (vehicle_journeys) du mode physique TER (LocalTrain). Vous obtiendrez 27500 réponses environ, que vous pourrez ensuite récupérer par paquet de 1000 maximum (donc 28 requêtes en tout). La requête obtenue sera la suivante : https://api.sncf.com/v1/coverage/sncf/physical_modes/physical_mode%3ALocalTrain/vehicle_journeys//?
C'est celle-ci que vous pourrez utiliser dans votre application.

Changez le physical_modes pour obtenir les horaires TGV, Intercités, Transilien (attention, cette requête ne propose pas encore le type de ligne Transilien (RER, L/H/R/etc.)).

Vous trouverez ici plus de détails sur la réponse obtenue (code json).

Horaires temps réel

Le temps réel s'appelle disruptions pour l'API et ce qui nous intéresse c'est ce qu'il se passe maintenant et après (pas avant), par conséquent le paramètre le plus important pour cette requête est since qui va permettre de requêter les disruptions à partir (since :) ) d'une date et heure voulues.

  • un élément (en vert) nommé disruptions contenant rien
  • un paramètre (en violet) nommé since contentant un datetime au format 20170725T103406 par exemple
  • à l'ajout du paramètre since un popup de choix de date apparaît, un raccourci « NOW » est disponible entre autres

La requête ressemble ensuite à https://api.sncf.com/v1/coverage/sncf/disruptions//?since=20170725T103406& et le résultat est détaillé sur la page dédiée.

Limites de l'API

Aujourd'hui, l'API temps réel est limitée à 150000 requêtes par mois, ce qui fait environ 3,5 requêtes par minute (à raison de 30 jours par mois).
Cela peut sembler peu, mais bien optimisé c'est en réalité très large.

Récupération horaires théoriques et stockage

Il faut tout d'abord récupérer les données théoriques d'horaires, ce qui correspond à une centaine de requêtes en tout (voir méthode plus haut), ou tout simplement avec le format GTFS, et en les stockant de son côté - celles-ci changent au maximum une fois par semaine (Transilien), voire seulement au mois (TER, TGV, InterCités).

Récupération temps réel, différentiel du théorique et stockage

Ensuite, toujours dans la même logique, plutôt que d'interroger l'API à chaque requête utilisateur, le temps-réel, qui n'est finalement qu'un différentiel du théorique, donc nettement moins lourd à récupérer, peut se récupérer d'une seule traite, avec une seul requête (voire deux en cas de grosse perturbations (chaleur, froid extrêmes). Dans ce cas, il faut à nouveau stocker l'ensemble de ce différentiel (retards, suppressions, causes, etc.), et en imaginant une mise à jour par minute, ce qui est déjà énorme (pas sûr que les données fournies soient rafraîchies autant !), cela correspond à 43200 requêtes par mois.

Conclusion

Avec cette méthode, plutôt simple, il nous reste chaque mois plus de 100000 requêtes disponibles ! Et comme l'interrogation des données de circulation, y compris temps-réel, se fait via une sorte de cache, le temps de réponse est totalement maîtrisé, sans que la qualité des données en pâtisse.

Vue la disponibilité des données continue et leur caractère non critique, le stockage sur une table type MEMORY est plutôt optimisé.

Une base de données lambda qui contient tous les horaires théoriques linéarisés à l'arrêt, avec autant de variantes que nécessaires, « pèse » environ 400Mo

Pas encore testé : pourquoi ne pas stocker et utiliser ce type de données dans des systèmes NoSQL (MongoDB, etc.) et/ou basés sur le temps (InfluxDB, ElasticSearch) ? Benchmark à faire !
  • GRAOU : Outil interne dédié à la gestion du planning des agents de conduite et commerciaux des trains.
1)
Le responsable de l'infrastructure ferroviaire française, en bref : les rails !