Après Tisséo pour Toulouse, plusieurs personnes ont des réseaux qui n’ont pas leur intégration dédiée. Plutôt que d’en faire une par ville, voici Transports en commun (GTFS) : les prochains passages à vos arrêts et les perturbations pour n’importe quel réseau publié sur transport.data.gouv.fr. TER et TGV SNCF, Naolib, STAR, TaM, M, Ilévia, Stan… environ 490 réseaux, dont 220 avec du temps réel. Tout vient de l’open data : sans compte et sans clé.
Ce que ça fait
Le réseau se choisit depuis Gladys : recherche dans le catalogue national, ou adresse d’un fichier GTFS pour un réseau qui n’y serait pas. Jusqu’à 3 réseaux.
Un appareil par arrêt (20 au plus) : pour chaque ligne et direction, les minutes avant le prochain passage et le suivant, les trois prochains passages en texte, et l’info trafic. Le temps réel est utilisé quand le réseau le publie ; un horaire théorique est marqué « ≈ ».
Un widget « Prochains passages », un déclencheur « Perturbation sur une ligne suivie » et une action qui prépare une phrase prête à envoyer.
Le truc sympa
À 7 h 45 en semaine → la phrase des prochains passages à mon arrêt sur Telegram
Perturbation sur ma ligne TER → message sur le téléphone avant de partir
Bus à moins de 4 minutes → la lampe de l’entrée clignote
Dans Configuration : cherchez votre réseau, ajoutez-le, puis cherchez et ajoutez vos arrêts (par nom ou autour de la maison).
Créez les appareils depuis l’onglet Découverte, puis ajoutez le widget.
Pour Toulouse, Lyon, l’Île-de-France et Bordeaux, les intégrations dédiées (Tisséo, TCL, IDFM, TBM) restent plus complètes : la doc les cite. L’Île-de-France est d’ailleurs trop grosse pour celle-ci.
Petites réserves honnêtes : le temps réel dépend de ce que publie chaque réseau, et il peut peser lourd (jusqu’à environ 100 Mo par heure et par réseau avec un rafraîchissement par minute ; la nuit, une lecture toutes les 15 minutes). Elle a été testée sur les vraies données (SNCF en gare de Nantes, Naolib, Aix-Marseille) dans les conditions du bac à sable de Gladys, avec un pic à 138 Mo de mémoire, mais pas encore dans une vraie instance.
Codée avec l’aide de Claude Code, à partir du code de mon intégration Tisséo. Projet indépendant, non affilié à transport.data.gouv.fr ni aux réseaux.
Mon test de charge d’aujourd’hui… et comme j’ai pris Toulouse à cœur ces derniers jours, je suis allé tester à : 64 Boulevard Pierre Semard Toulouse, mieux connu sous le nom de Matabiau.
Et voici le même résultat pour la gare centrale de Heidelberg:
Tout y est, les bus urbains (BUS), les lignes de bus interrégionales (COACH), les tramways urbains (TRAM), les trains interrégionaux (FERN), les trains de banlieue (S-BAHN).
Les ferries (FÄHRE) sont également affichés, voici l’exemple de l’Elbphilharmonie à Hambourg:
5.) Lieu déterminé par géolocalisation, prévu : indication de la ville
Si tout se passe bien, alors j’aurai terminé les tests aujourd’hui et ensuite, en tant que débutant absolu sur GitHub, je vais me plonger brièvement dans la création d’une intégration externe ou je confierai simplement le projet à quelqu’un qui maîtrise le sujet…
Je découvre que les données temps réelles du réseau Ginko de Besançon sont sur cette plate-forme opendata. Je vais tester ton intégration, et si ça marche ça va le faire encore un bricolage node-red que je pourrai supprimer !
Alors en fait l’intégration trouve bien le.reseau Ginko bisontin, mais ce sont uniquement les horaires théoriques, au format GTFS.
Les horaires temps réel sont mentionnés sur le site transport.data.gouv.fr, mais dans un format SIRI. Le détail explique que ça passe par une API nécessitant une clé.
Je dispose d’une telle clé, c’est comme ça que je fait fonctionner mon bricolage node-red.
Tu crois, @guim31, que tu pourrais compléter ton intégration avec ce format ?
@StephaneB bien vu, et oui c’est faisable. J’ai regardé : Ginko n’est pas seul dans ce cas, une petite vingtaine de réseaux publient leur temps réel uniquement en SIRI sur transport.data.gouv.fr (Strasbourg, les Pays de la Loire, Idelis, TUB…). Je m’y mets : un champ facultatif pour la clé du réseau, et l’intégration ira chercher les passages en SIRI quand il n’y a pas de GTFS-RT. Tes arrêts restent les mêmes, rien à recréer. Je te fais signe dès que c’est prêt, et ton bricolage Node-RED sera le test parfait ^^
@ruegerth joli test de charge Tu passes par quelle source pour avoir l’Allemagne, Hambourg et Québec sans rien télécharger ? Si c’est une API mondiale ouverte, ça m’intéresse, que ce soit pour compléter celle-ci ou pour ton intégration à toi.
@StephaneB c’est en ligne : la 1.1.0 lit le temps réel SIRI et SIRI Lite des réseaux qui n’ont pas de GTFS-RT, dont Ginko.
Pour l’activer : dans la configuration de l’intégration, champ « Clés d’API SIRI », ajoute une ligne Ginko = ta-clé. La clé ne sort jamais dans les journaux. Tes arrêts restent les mêmes : les passages suivis s’affichent sans le « ≈ » quand ils sont en temps réel, et les perturbations Ginko alimentent l’info trafic et le déclencheur.
J’ai pu tester depuis chez moi contre les vrais serveurs : celui de Ginko répond bien, mais sans aucun arrêt quand on n’a pas de clé, donc c’est toi qui vas faire le premier vrai essai ^^ Si l’intégration te signale un arrêt inconnu ou une clé refusée, dis-le-moi.
Au passage, ça marche aussi pour une quinzaine d’autres réseaux dans le même cas : les Pays de la Loire (Aléop et les réseaux urbains de l’agrégat), Saint-Brieuc (TUB), plusieurs réseaux de Nouvelle-Aquitaine (Tanlib, Calibus, R’Bus, TuT…), Strasbourg avec une clé CTS… Petite réserve : la plateforme Okina, derrière beaucoup de ces réseaux, n’accepte qu’une requête toutes les 30 secondes environ. Mieux vaut donc y suivre un ou deux arrêts, pas dix.
J’ai testé. Ça progresse bien, mai voilà mes retours:
J’ai voulu modifier le réseau que j’avais déjà configuré, mais on ne peut pas. On ne peut que ajouter et supprimer, et il n’y a d’ailleurs pas de liste des réseaux déjà configurés pour savoir où on en est.
C’est bizarre d’ajouter la clé d’API SIRI dans la section Configuration, alors qu’elle est propre au réseau.
Le champ clé API est donc prévu pour pouvoir écrire « Réseau1 = API 1 ; Réseau 2 = API 2 ». Sauf que c’est un champ qui masque ce qu’on saisit, donc c’est compliqué… Raison de plus peut-être pour définir la clé API dans l’action « Ajouter un réseau »
Dans l’action « Chercher un arrêt », si on ne renseigne rien pour faire la recherche « proche de moi », il manque la sélection de la maison quand on en a plusieurs
A l’arrêt de bus près de chez moi, il y a 2 lignes x 2 directions x (le prochain bus + le suivant). Je n’avais rien saisi dans le champ ‹ Ligne ›, donc ça a découvert l’arrêt avec 8 fonctionnalités. J’aurais dû renseigner uniquement les lignes qui m’intéressaient, mais à ce stade je ne les connaissaient pas. Ce serait bien que leurs noms soient affichés quand on a fait l’action « ajouter un arrêt ».
Et idéalement il faudrait pouvoir n’ajouter que un couple ‹ ligne+direction ›. Devant chez moi. Je ne prends jamais la ligne qui part vers l’ouest…
Ensuite quand j’ajoute le widget sur le dashboard, je n’ai que les horaires théoriques. Par exemple :
[2026-10-16T18:01:43.871Z] [INFO] [gtfs] Stop added: 4 Vents (Ginko)
[2026-10-16T18:01:53.074Z] [WARN] [gtfs-feed] Ginko: realtime (SIRI) unavailable: api.ginko.voyage: answers without any stop nor departure
Et je pense aussi que le widget pourrait être mieux affiché, pour que le nom de ligne soit sur deux lignes afin d’éviter le troncage des temps de passage
La 1.2.0 est en ligne, avec presque tout ce que tu demandais :
Clé SIRI par réseau : « Ajouter un réseau » a maintenant un champ Clé d’API SIRI. Plus besoin du format « Réseau = clé » dans la configuration (il marche toujours).
Modifier un réseau : ajoute-le à nouveau en ne remplissant que ce qui change (nom, flux, clé) : il est mis à jour et ses arrêts restent. La liste des réseaux et arrêts déjà ajoutés est dans Afficher la surveillance, la dernière action de la page.
Plusieurs maisons : « Chercher un arrêt » a un champ Maison, et la réponse cite les autres maisons.
Lignes et directions : « Ajouter un arrêt » liste maintenant les lignes et directions de l’arrêt. Tu peux n’en garder qu’une avec 3 > Chazal dans « Lignes » (la ligne 3, direction Hauts du Chazal). Ajoute à nouveau l’arrêt pour réduire ton appareil, puis « Mettre à jour » dans l’onglet Découverte.
Pour le temps réel de Ginko, le message du journal veut dire que le serveur répond, mais vide : c’est ce qu’il fait sans clé, ou avec une clé qu’il ne reconnaît pas. Tu en as demandé une au support de Ginko ? Si oui, remets-la dans le nouveau champ et dis-moi ce que donne « Afficher la surveillance »
Pour le widget, la mise en page des lignes vient de Gladys, pas de l’intégration : je ne peux pas faire passer le nom sur deux lignes de mon côté. Garder seulement tes directions devrait déjà laisser plus de place.
le champ ‹ clé api siri › dans l’ajout du réseau, c’est mieux. Mais je ne vois pas l’intérêt de le garder dans la section configuration. Je trouve que ça prête à confusion.
Pour le champ ‹ maison › pour chercher les arrêts proches, ça fonctionne bien. Mais ce serait mieux de pouvoir choisir la maison dans un sélecteur que de devoir saisir son nom
Pour l’ajout d’un arrêt en configurant la ligne et la direction, ça fonctionne. Mais il faut ‹ deviner › comment la direction est nommée. Ce serait pratique que l’action ‹ chercher un arrêt › liste les lignes et les directions, et avec le format ‹ ligne > direction › puisque c’est le format attendu quand on ajoute un arrêt, plutôt que ‹ ligne → direction ›
Et surtout, c’est bizarre pour le fonctionnement du temps réel. Je suis certain de ma clé API, elle fonctionne quand je construis ma requête http dans node-red. Est-ce que ça t’aiderait si je te confiais ma clé en MP pour faire tes tests ?
Clé SIRI : elle n’est plus que dans « Ajouter un réseau ». Le champ de la configuration a disparu, et une clé saisie là-bas passe toute seule sur son réseau.
Maison : c’est maintenant une liste de tes maisons (il faut Gladys 5.2.0).
Directions : « Ajouter un arrêt » les écrit au format de « Lignes » (3 > Hauts du Chazal), prêtes à copier. Je ne peux pas les lister dès « Chercher un arrêt » : pour rester léger, l’intégration ne lit les horaires détaillés que des arrêts suivis. Le plus simple est d’ajouter l’arrêt une fois avec toutes ses lignes, de copier les directions voulues, puis de l’ajouter à nouveau avec elles.
Pour le temps réel, pas besoin de m’envoyer ta clé Dis-moi plutôt comment est faite ta requête dans node-red, en masquant la clé : l’adresse appelée, et où va la clé (paramètre de l’URL, en-tête, ou RequestorRef dans le XML). Aujourd’hui, l’intégration la met dans le RequestorRef de la requête SOAP. Si Ginko l’attend dans l’URL, tu peux déjà essayer de saisir apiKey=ta-clé (avec le nom du paramètre de ta requête) dans le champ « Clé d’API SIRI » : l’intégration la mettra alors à cet endroit.
Merci @StephaneB, c’était exactement l’info qu’il fallait !
J’ai interrogé le serveur SIRI de Ginko : comme pour la requête que tu utilises dans node-red, il attend la clé dans le paramètre apiKey de l’adresse. L’intégration la mettait dans le XML de la requête, où Ginko ne la voit pas. Et quand la clé manque, il répond par un petit message d’erreur que l’intégration prenait pour une réponse vide.
C’est corrigé dans la 1.3.1 : la clé part maintenant dans apiKey, et une clé refusée s’affiche comme telle dans « Afficher la surveillance ». Rien à changer de ton côté : mets à jour depuis Gladys, et le temps réel devrait arriver au rafraîchissement suivant. Dis-moi si c’est bon
J’ai une erreur « » dans le journal. Mais je suis sûr de ma clé API qui fonctionne dans mes requetes HTTP, et j’ai modifié la clé API par « BIDON » pour remettre ensuite la bonne clé, sans que ça change les choses. Ceci dit, point bizarre: mes logs complets (dans l’onglet journal) sont:
[2026-10-17T12:05:13.878Z] [INFO] Starting the GTFS public transport integration...
[2026-10-17T12:05:15.644Z] [INFO] [gladys-sdk] connected to Gladys (http://172.30.0.1:80)
[2026-10-17T12:05:26.652Z] [WARN] [gtfs-feed] Ginko: realtime (SIRI) unavailable: api.ginko.voyage: Error: Vous n'avez pas les droits nécessaires pour ce service.
[2026-10-17T12:10:54.285Z] [INFO] [gtfs] Stop added: 4 Vents (Ginko)
[2026-10-17T12:12:04.483Z] [INFO] [gtfs] Stop updated: 4 Vents (Ginko)
[2026-10-17T12:16:39.495Z] [INFO] [gtfs] Network updated: Ginko (tdg80590)
[2026-10-17T12:18:02.567Z] [INFO] [gtfs] Network updated: Ginko (tdg80590)
On y voit le ‹ starting › juste après la mise à jour en 1.3.1, puis un échec de temps réel, et plus bas les deux ‹ network updated › correspondent aux changements de clé API (d’abord « BIDON » puis la vraie clé), mais on n’y voit pas de nouvelles tentative de connection à l’API temps réel (je m’attendais au moins à une nouvelle ligne « unavailable » avec la clé « BIDON ».
Faut-il que supprime complètement le réseau pour le reconfigurer ?
Autre truc : dans l’onglet appareil, quand j’ouvre la section ‹ technique ›, il n’y a rien dans la ligne realtime_urls, je ne sais pas si c’est normal:
Le widget actuellement ne permet de ne choisir qu’un seul arrêt et l’affiche tel quel, avec l’inconvénient déjà cité d’un nom long qui provoque le troncage des temps d’attente.
Je suggère que ce widget fonctionne comme le widget appareil : pouvoir ajouter plusieurs arrêt, pouvoir renommer le libellé d’affichage de l’arrêt, et pouvoir ordonner les arrêts
renommer l’extension
C’est un détail, mais est-ce que l’extension ne devrait pas d’appeler « Transports en commun (GTFS et SIRI) » ?
La ligne « Vous n’avez pas les droits nécessaires pour ce service » vient du serveur de Ginko lui-même. Avant la 1.3.1, il disait qu’il ne voyait pas de clé. Maintenant, il la reconnaît, mais elle n’ouvre pas le service SIRI. Ta clé marche avec getTempsLieu (leur API maison), mais le temps réel SIRI semble être un service à part chez Ginko. Le plus simple : demande à leur support d’activer SIRI sur ta clé. Rien à reconfigurer de ton côté, tu peux garder le réseau tel quel.
Pour tes deux autres questions :
Pas de nouvelle ligne après le changement de clé : c’est voulu. Pour ne pas remplir le journal, une même panne n’est écrite qu’une fois, puis une seule ligne quand ça revient. La dernière erreur reste visible dans « Afficher la surveillance ».
realtime_urls vide : c’est normal. Ce champ sert aux flux GTFS-RT, et Ginko n’en a pas, seulement du SIRI.
Le widget à plusieurs arrêts et le nom « GTFS et SIRI », je note, je regarde ça
@guim31 En parcourant la page Open data du réseau Ginko, je comprends que Ginko ne fournit qu’une seule clé API pour GTFS et pour SIRI. Donc celle que j’ai devrais marcher
Et je découvre aussi qu’il y a en fait une api GTFS-RT, décrite sur Open data du réseau Ginko (même si elle n’est pas référencée sur le site transport.data.gouv.fr). Comme les requêtes commencent par https://api.ginko.voyage/GTFSRT/tripUpdates.do?apiKey=XXX, j’ai ajouté https://api.ginko.voyage/GTFSRT/tripUpdates.do dans le champ « URL GTFS-RT » dans la page config.
Mais les infos qui s’affichent dans le widget restent théoriques, pas de temps réel…
Je suppose que ça vient du fait que cette API GTFS-RT de Ginko nécessite une clé API, alors que tu n’as prévu la notion de clé API que sur l’interface SIRI ?
L’intégration ne mettait la clé que sur le SIRI. Avec la 1.3.2, la clé du réseau part aussi vers les flux GTFS-RT des plateformes qui en demandent une, dont Ginko (dans le paramètre apiKey). Le champ s’appelle maintenant Clé d’API du réseau.
Comme tu as déjà ajouté https://api.ginko.voyage/GTFSRT/tripUpdates.do dans « URL GTFS-RT » et ta clé dans le réseau, il te suffit de mettre à jour depuis Gladys. Le temps réel devrait arriver au rafraîchissement suivant, et « Afficher la surveillance » doit indiquer « Temps réel : mis à jour il y a … ». Dis-moi si c’est bon
Tu passes par quelle source pour avoir l’Allemagne, Hambourg et Québec sans rien télécharger ? Si c’est une API mondiale ouverte, ça m’intéresse, que ce soit pour compléter celle-ci ou pour ton intégration à toi.
