Étant étudiant à l’IUT2 de Grenoble et habitant la région voironnaise, je prends le train tous les matins et tous les soirs.

La gare de Grenoble servant de point de passage pour plus de 8 lignes différentes, les incidents entraînant des retards sont fréquents. Pour être tenu informé des retards, il faut consulter SNCF Connect et ceci est assez compliqué pendant les cours.

Pour répondre à ce problème et être informé en cas de retards des mes trains habituels, j’ai décidé de créer une automatisation qui me prévient automatiquement.

La SNCF possède une très grande quantité d’API utilisable par les développeurs et, parmi ces API, est disponible un API référençant tous les retards des trains sur une période de 60 minutes (appelée “API en temps réel”). Cette API est mise à jour toutes les 2 minutes. La SNCF possède aussi une “API théorique” référençant tous les trains théoriques avec leurs horaires, les gares desservies, …

L’automatisation est faite via un outil appelé n8n. Cet outil permet de créer des “Workflow” avec des déclencheurs (par exemple: tous les jours ouvrés à 5h00) et une suite d’actions qui sera réalisée. Présentation complète sur le site de n8n

Workflow 1 : horaires de cours et trains théoriques

Tous les matins, à 5h, un premier Workflow récupère mon emploi du temps et extrait l’heure de début et l’heure des fin de ma journée (ex: 8h & 17h30). A partir de ces heures, le Workflow récupère les trains qui me permettent d’arriver à l’heure en cours et les trains aux alentours de l’heure de fin de cours qui me permettent de rentrer chez moi.

Par exemple, via l’API théorique de la SNCF, le Workflow va récupérer le train de 7h16 à Voiron pour me permettre d’arriver à 7h39 à Grenoble et les trains partant à 17h21, 17h24, 17h51 et 17h54 de Grenoble pour aller à Voiron.

Workflow 2 : surveillance des changements

Une fois la liste de tous les trains à surveiller complète, un autre Workflow prend le relais. L’API en temps réel de la SNCF permet de récupérer les informations des trains circulant dans les 60 minutes après l’appel à l’API, il est donc inutile de surveiller ces trains à partir de 5h.

Le Workflow 2 va donc attendre jusqu’à ce qu’il ne reste plus que 50 minutes avant le départ théorique du train en gare (pour avoir une marge) (ex: attendre 17h04 pour le train de 17h54).
Une fois cette heure arrivée (ex: 17h04), le Workflow 2 appelle toutes les 5 minutes le Workflow 3, dédiée à vérifier les informations du train, jusqu’au départ réel du train (ex: pour le train qui part à 17h54 avec un retard de 5 minutes, le Workflow 2 va continuer jusqu’à 17h59).

Workflow 3 : vérifier les trains

Le Workflow 3 récupère le numéro du train (Ex: 885731) et la gare de départ pour récupérer les informations de ce train avec l’API en temps réel. 3 scénarios sont possibles :

• Le train est à l’heure : rien ne se passe, aucune notification
• Le train est en retard : une notification m’est envoyée via Discord pour me prévenir. Si le retard change (+ ou - de retard), une nouvelle notification m’est envoyée.
  -> Si le train ratrappe son retard, une notification m’est également envoyée.
• Le train est supprimé : une notification m’est envoyée et la surveillance s’arrête.

De cette manière, peu importe mes horaires de cours, ce système me prévient de tout éventuel retard.