API
Intégrateur API SNCF Open Data : afficher le bon départ, avec la bonne fraîcheur
Dawap transforme jeux SNCF, horaires théoriques, informations temps réel et réponses Navitia en un service exploitable par votre application, votre carte ou votre BI. Chaque valeur reste reliée à sa source, son horodatage, son identité transport, sa règle de cache et son mode dégradé.
APIs, données et infrastructures que nos projets savent connecter
Du besoin métier au run mesurable
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
actionnable
Réponse immédiate
Un intégrateur API SNCF Open Data transforme des données ferroviaires datées en décisions produit explicables.
Dawap construit la couche entre SNCF Open Data, Navitia et vos consommateurs. Le projet sélectionne les bons jeux, rapproche les identités transport, distingue horaire théorique, temps réel et perturbation, puis applique cache, seuil de fraîcheur et mode dégradé. Chaque écran ou indicateur conserve la preuve de la valeur servie.
- Choisir entre export open data, Explore API et API applicative selon la décision et la fréquence attendues.
- Conserver les identifiants et la portée de gare, arrêt, ligne, route et trajet sans fusion sur un libellé.
- Comparer base_schedule, realtime, perturbation, réception et âge du cache avant affichage.
- Servir une information datée ou un repli décidé lorsque la source ne permet plus une réponse certaine.
Tableau de départ contrôlé · scénario illustratif
Une heure affichée n’est fiable que si sa source, sa fraîcheur et son mode de repli restent lisibles.
Les gares, trains, horaires et identifiants de ce dossier sont fictifs. Le scénario montre la décision attendue quand l’horaire théorique reste valide mais qu’une information temps réel plus récente décale le départ.
Dossier voyageur fictif
LYS-PD · voie non publiée
Snapshot 18:05:12
18:31
Départ recalculé
Paris Gare de Lyon
base_schedule · source conservée
realtime reçu à 18:03
Décision produit
Afficher 18:31 · signaler le décalage
freshness: realtime · fallback: armed
- 01CatalogueJeu identifiéAccepté
- 02RéférentielArrêt rapprochéAccepté
- 03TempsDeux horlogesComparées
- 04DécisionRetard visibleDatée
- 05ProduitMessage serviTraçable
Le temps réel n’arrive plus
Afficher le dernier horaire théorique encore valide, daté et explicitement qualifié, plutôt qu’une précision inventée.
L’arrêt ne retrouve plus son identité
Isoler la ligne, conserver le payload et demander un rapprochement ; ne jamais fusionner sur le seul libellé de gare.
Le rafraîchissement expire après réponse
Comparer snapshot, horodatage et état servi avant de relancer. Le dernier écran sain reste disponible pendant le diagnostic.
Ce que les sources permettent d’affirmer
Prévu, temps réel et perturbation sont trois contrats à réconcilier.
SNCF Open Data publie notamment des horaires théoriques en GTFS et NeTEx, ainsi que des informations temps réel de type alertes en SIRI SX Lite et GTFS-RT. Navitia distingue base_schedule et realtime et documente des identifiants qui peuvent disparaître : l’intégration doit donc dater, rapprocher et tolérer l’évolution.
Horaires SNCF. Le jeu officiel décrit les formats GTFS et NeTEx et la profondeur publiée. Consulter le jeu de données.
Alertes temps réel. SNCF Open Data documente la diffusion SIRI SX Lite et GTFS-RT Service Alerts. Consulter le flux officiel.
API applicative. Navitia documente les horaires, départs, perturbations, fraîcheurs et règles de résilience des clients. Lire la documentation.
Premier lot recommandé
Une gare, un écran de départ et une règle de fraîcheur.
La recette prouve le nominal, le retard, la perturbation, l’identité disparue et l’absence de temps réel avant d’ouvrir une nouvelle zone ou un nouvel usage.
Quand un écran précis raconte une donnée incertaine
La panne SNCF Open Data commence quand personne ne sait quelle horloge fait foi.
Un import réussi, une réponse HTTP 200 ou un cache disponible ne prouvent pas que l’information affichée soit encore juste. Le connecteur doit relier source, objet, fraîcheur et décision avant de servir le produit.
01
Identité
Un libellé de gare ne suffit pas à rapprocher un arrêt
Gare, stop area, stop point, ligne, route et trajet gardent leurs identifiants et leur portée. Une disparition ou un renommage ouvre une quarantaine, jamais une fusion silencieuse.
02
Temps
Prévu et temps réel ne portent pas la même promesse
L’horaire de base reste la référence du service planifié ; la mise à jour temps réel modifie la décision servie. Les deux valeurs et leurs horodatages restent disponibles pour expliquer l’écart.
03
Continuité
Le mode dégradé doit être décidé avant l’incident
Source absente, quota, schéma rompu ou cache périmé conduisent à des réponses différentes : servir daté, masquer, geler ou alerter selon l’usage.
Contrats d’un service SNCF exploitable
Six contrats empêchent un horaire disponible de devenir une information trompeuse.
Les formats décrivent des données. La fiabilité vient des frontières qui relient chaque valeur à un objet, une période de validité, un owner et une décision de restitution.
Le jeu est choisi pour l’usage, pas pour son nom
Catalogue, export, Explore API ou Navitia répondent à des besoins différents. Le contrat note l’origine, le dataset, sa version, sa période utile et le consommateur visé.
Gare, arrêt, ligne et trajet ne sont pas interchangeables
Les identifiants source sont rapprochés à une identité interne avec niveau, couverture et provenance. Un code disparu déclenche une revue au lieu d’être remplacé par ressemblance.
Le service prévu reste conservé à côté de la mise à jour
Horaire de base, heure amendée, réception et valeur servie forment quatre faits distincts. L’écart devient explicable par le produit et le support.
Un message n’est appliqué qu’à son bon périmètre
Période, effet, objets impactés et lien avec le départ sont vérifiés avant de modifier un trajet, un écran ou une alerte.
La disponibilité ne masque jamais l’âge de la donnée
TTL technique, seuil métier et dernier snapshot sain restent séparés. Une réponse en cache peut être servie, datée ou refusée selon la décision concernée.
Chaque défaut mène à une prochaine action déterminée
Absence de flux, 429, rupture de schéma, identité inconnue et donnée périmée possèdent leurs alertes, replis, quarantaines et droits de reprise.
Méthode Dawap
Prouver un écran avant de couvrir tout le réseau.
Nous commençons par la décision qui perd aujourd’hui le plus de confiance. Les identités, horloges et seuils sont stabilisés, puis les absences et contradictions de source sont exercées avant d’ouvrir une nouvelle gare, ligne ou application.
Décision 1
Une gare témoin, pas tout le référentiel.
Décision 2
Un écran critique, pas tous les consommateurs.
Décision 3
Une règle de fraîcheur, pas un TTL implicite.
Décision 4
Un repli prouvé, jamais une valeur silencieusement périmée.
Premier lot SNCF
Fiabiliser une gare, un écran de départ et une règle de fraîcheur.
On choisit le parcours où un retard, une perturbation ou une donnée périmée crée déjà une décision ambiguë. Le lot est accepté quand produit, data et support peuvent expliquer la valeur affichée sans ouvrir les logs bruts.
1 gare témoin
1 écran
1 règle de fraîcheur
1 mode dégradé
5 contre-tests
Sorties attendues
Carte source–collecte–normalisation–cache–API interne–écran avec owner de chaque passage.
Contrats de gare, arrêt, ligne, trajet, horaire, perturbation et valeur servie avec identifiants stables localement.
Inventaire des jeux, formats, dates de validité, paramètres, quotas, fréquences et conditions d’usage réellement retenus.
Cinq contre-tests : temps réel absent, identité disparue, schéma rompu, quota atteint et cache hors seuil.
Snapshot expurgé reliant donnée prévue, mise à jour, réception, cache, décision et restitution utilisateur.
Recette produit–data–support, alertes, balance, stratégie de repli et runbook de reprise ciblée.
Trois scénarios de preuve
La recette porte sur les écarts qui modifient réellement l’information voyageur.
Les identifiants et horaires ci-dessous restent illustratifs. La recette finale utilise les jeux, objets et seuils validés pour votre produit.
Le retard remplace le prévu sans effacer sa preuve
Un scénario concret à cadrer et vérifier.
- Décision
- Afficher 18:31, signaler l’écart et conserver le repli théorique daté.
Un identifiant disparu ne fusionne pas deux gares
Un scénario concret à cadrer et vérifier.
- Décision
- Mettre la relation en quarantaine et conserver le dernier objet sain pour les usages autorisés.
Une source indisponible ne vide pas l’écran
Un scénario concret à cadrer et vérifier.
- Décision
- Servir la valeur datée avec mention de repli, puis retenter selon le runbook.
Frontières éditoriales
Choisir la page qui peut répondre précisément au besoin.
Service SNCF, guide technique, portefeuille d’API publiques et réseau RATP se renforcent sans se remplacer.
Avis & exigence projet
Une intégration SNCF Open Data jugée sur la valeur réellement servie.
5/5★★★★★Avis clients Dawap
“
Jeu, format, période, couverture, usage et owner sont explicitement choisis.
“
Identité, prévu, temps réel, perturbation, cache et seuil sont réconciliés.
“
Dernier état sain, repli, alerte, impact et prochaine action restent visibles.
Attractivité-locale.fr transforme un portail de collectivité en point d’entrée vers les entreprises, leurs offres d’emploi et leur carte OpenStreetMap. Dawap a relié le référentiel géographique de l’État, un back-office multi-rôles et treize routes API de lecture, sans confondre données territoriales et données d’entreprise.
API SNCF Open Data doit cadrer data.sncf.com, Explore API, API SNCF, Navitia, GTFS, NeTEx, GTFS-RT, SIRI SX Lite, gares, arrêts, lignes, horaires théoriques, temps réel, perturbations, clé développeur, 150 000 requêtes par mois, 5 000 par jour, cache, quotas, fraîcheur, retards source, journaux et mode dégradé.
API RATP Open Data doit cadrer data.ratp.fr, Explore API v2.1, jeux RATP, PRIM, SIRI Lite, prochains passages, messages écrans, LineRef, StopPointRef, GTFS IDFM, lignes, arrêts, stations, trafic entrant, qualité de l'air, commerces, sanitaires, quotas, cache, fraîcheur, statut onTime, delayed, cancelled et mode dégradé.
Un SLO d’intégration API doit mesurer fraîcheur, erreurs et conséquence métier plutôt qu’une disponibilité abstraite. La méthode propose de définir les seuils par flux, relier les alertes aux commandes ou dossiers concernés et prévoir la reprise, afin de prioriser la fiabilité là où une dégradation coûte réellement.
Une API rapide en test peut saturer quand les files grossissent, que les retries se croisent et que le cache propage un stock faux. Une stratégie de résilience relie budget de latence, priorité métier, dégradation contrôlée et seuil de reprise afin de préserver commandes, facturation et support lorsque la capacité devient rare.
Questions d’achat
Questions fréquentes sur l’intégration API SNCF Open Data
Les réponses à clarifier avant de relier des données SNCF à une application, une carte, une API interne ou une BI.
01Quand faire appel à un intégrateur API SNCF Open Data ?
Quand des jeux ou réponses SNCF doivent alimenter un produit métier avec des règles de mapping, fraîcheur, cache, repli, supervision et support que le simple téléchargement ne couvre pas.
02Quelle différence entre SNCF Open Data et Navitia ?
SNCF Open Data publie des jeux et formats ferroviaires ; Navitia fournit des services applicatifs de transport. Le bon contrat dépend de l’usage, de la couverture et de la fraîcheur attendue.
03Comment distinguer horaire théorique et temps réel ?
Nous conservons la valeur de base, la valeur mise à jour, leurs horodatages et la valeur servie. Le produit peut ainsi expliquer l’écart et appliquer un seuil de fraîcheur.
04Que se passe-t-il si le temps réel est indisponible ?
Le comportement est décidé par usage : dernier snapshot daté, horaire théorique qualifié, masquage ou blocage. Le connecteur n’invente jamais une précision qu’il ne peut plus prouver.
05Peut-on combiner SNCF, RATP et d’autres sources mobilité ?
Oui via un modèle canonique et une couche transverse, sans effacer la provenance, les couvertures, les identifiants ni les règles de fraîcheur propres à chaque réseau.
06Quel premier lot SNCF recommandez-vous ?
Une gare, un écran de départ, une règle de fraîcheur et un mode dégradé, avec cinq cas d’échec. L’extension attend une identité stable et une restitution expliquée par le métier.
SNCF Open Data · GTFS · NeTEx · temps réel
Votre prochain horaire SNCF restera-t-il explicable quand le temps réel manque ?
Dawap cadre les sources, identités, horloges, caches, perturbations et replis avant d’ouvrir le service à plus de gares ou de consommateurs.
Cadrer mon service SNCF