Transport à la demande

Sur cette page:

Introduction pour le personnel des sociétés de transport
Éléments nécessaires pour l’intégration
- Un travail d’équipe
- Types de collaboration
Standards de données vs API propriétaires
Précautions supplémentaires
Exemples de demandes de propositions et de contrats

Introduction pour le personnel des sociétés de transport

Les services de transport en commun peuvent rapidement devenir complexes, particulièrement lorsqu’aucune ligne droite ne joint le point A au point B.

Transport à la demande, transport adapté, taxi collectif ou taxibus avec réservation téléphonique, retour garanti à domicile, programme de taxis sur le dernier kilomètre, partenariats avec services de voiturage... Qu’il s’agisse de services porte-à-porte, arrêt-à-arrêt, ou zone-à-zone, ces options peuvent représenter un défi pour les usager·ère·s, qui n’en connaissent peut-être même pas l’existence.

Il est essentiel de garantir l’accessibilité à ces services sur toutes les plateformes numériques des sociétés de transport en commun et des acteurs du transport. Bien sûr, ça inclut l’application Transit. 💅 Mais on parle aussi du planificateur de trajet de votre site web, de l’affichage numérique sur l’ensemble de votre réseau et des outils d’assistance aux utilisateur·rice·s.

Ces plateformes présentent déjà les informations des services à itinéraire fixe grâce aux standards de données comme les spécifications GTFS et GTFS-realtime. Mais les services à la demande semblent souvent être un cas à part.

Le taxi collectif (taxibus) et le transport adapté, par exemple, nécessitent souvent la réservation par appel téléphonique. Bien que certains fournisseurs de services à la demande décident d’aussi inclure dans leur propre application l’information des transports à itinéraire fixe offerts par d’autres sociétés de transport, cela n’aide en rien les usager·ère·s de ces sociétés de transport à accéder aux services à la demande depuis les applications, sites web et outils d’aide à la clientèle de ces sociétés.

Heureusement, il existe des standards de données ouvertes permettant d’obtenir l’information des services à demande, de planifier des trajets, et même de réserver une course depuis toutes les plateformes. De plus en plus, les fournisseurs choisissent d’utiliser ces standards de données, et l’appui des sociétés de transport en commun est important pour l’adoption de ces standards maintenant et dans le futur.

Ce guide est conçu pour aider le personnel des sociétés de transport à intégrer les services à la demande à toutes les plateformes auxquelles leurs usager·ère·s ont accès, incluant Transit, peu importe quels fournisseurs offrent ces services.

Éléments nécessaires pour l’intégration

Pour intégrer un service de transport à la demande aux plateformes utilisées par les usager·ère·s d’une société de transport, trois grandes composantes sont requises :

Informations du service : Dans sa version la plus simple, une intégration des transports à la demande partage l’information relative aux zones, aux heures d’opération et à la disponibilité du service dans un format compatible pour les systèmes devant l’utiliser. Ces données peuvent ensuite être utilisées par les applications et autres plateformes numériques pour informer les usager·ère·s des services.
Planification de trajet : L’intégration permet aussi aux usager·ère·s de planifier un trajet du point A au point B en combinant les correspondances entre plusieurs modes de transport, incluant le transport à la demande. Cette fonctionnalité peut inclure une prédiction du temps de départ en temps réel.
Commande, réservation et paiement : Les intégrations permettent aussi aux usager·ère·s de commander un trajet, le réserver ou payer pour celui-ci depuis la plateforme destinée aux usager·ère·s, à l’aide d’une des options suivantes. L’implémentation varie en complexité :
1. Option la plus simple : lien direct vers l’application, le site web ou le numéro de téléphone du fournisseur du service à la demande
2. App Clip (iOS) ou Instant App (Android), tel qu’offert par le fournisseur du service à la demande
3. Intégration web accessible depuis la plateforme destinée aux usager·ère·s
4. Option la plus complexe : intégration native sur mesure, à même la plateforme destinée aux usager·ère·s

Cette intégration avec le ministère des Transports du Minnesota inclut les informations des zones et des heures d’opération, la planification des trajets et la réservation en ligne à même l’application Transit, le tout grâce aux standards de données ouvertes.

Un travail d’équipe

Dans la plupart des cas, trois partenaires sont nécessaires pour toute intégration de services à la demande :

🏢 Propriétaire du service	🚐 Fournisseur du transport à la demande	📲 Plateforme destinée aux usager·ère·s
Généralement, une société de transport en commun	Fournisseur avec technologie de transport adapté à la demande, ou avec capacité de production de données	Interface numérique regroupant tous les services d’une société de transport
Offre le service et négocie le contrat liant le fournisseur et la plateforme	Produit le flux de données ➔	➔ Récupère le flux de données

Types de collaboration

Le fournisseur de transport à la demande et la plateforme destinée aux usager·ère·s peuvent collaborer de deux façons différentes pour livrer l’intégration au propriétaire du service :

🤝 Coopérative	🏰 Jardin clos
Différents fournisseurs travaillent ensemble pour intégrer le service à la demande à une ou plusieurs des plateformes destinées aux usager·ère·s de la société de transport	Un fournisseur de transport à la demande intègre son propre service à sa propre plateforme destinée aux usager·ère·s, mais pas dans les autres applis, sites web et outils d’aide à la clientèle de la société de transport
Des frais d’installation et de maintien de l’intégration s’appliquent généralement pour le fournisseur et les plateformes	Inclus dans l’offre de service à la demande de certains fournisseurs

Standards de données vs API propriétaires

Les flux de données des fournisseurs de transport à la demande se conforment à l’un de ces deux grands types de formats :

🔄 Standards de données	🔒 API propriétaires
Formats standardisés acceptés et utilisés par un ensemble de fournisseurs de services à la demande et de plateformes destinées aux usager·ère·s, et encouragés par les sociétés de transport	Interfaces de programmation d’application (API, ou Application Programming Interface) utilisant format non standard, propres à un fournisseur de service à la demande en particulier
Lorsqu’un fournisseur ou une plateforme utilise un standard de données, il devient plus simple de collaborer avec tout autre partenaire utilisant ce même standard	Développement sur mesure nécessaire pour chaque plateforme destinée aux usager·ère·s afin de prendre en charge chaque API propriétaire. Lorsqu’une plateforme prend en charge l’API propriétaire d’un fournisseur, il devient alors plus simple d’y ajouter les services de ce fournisseur.
Permet aux sociétés de transport de plus facilement collaborer avec les différents fournisseurs	Complexifie la collaboration entre les sociétés de transport et les différents fournisseurs
Facilite la validation de la qualité et de la fiabilité du flux de données de chaque fournisseur de service à la demande, puisque les mêmes points de référence sont utilisés	La qualité peut varier grandement selon ce que chaque fournisseur de service à la demande choisit d’inclure dans son API, la structure de celle-ci, et ses performances de contrôle de qualité
Exemples : GTFS-flex, GOFS-lite	Exemples : RideCo API, Spare Labs API

Quel standard de données demander

La meilleure façon d’intégrer votre service à la demande à Transit (ou à vos autres plateformes, comme le site web de votre société de transport) est d’utiliser les standards de données ouvertes. Le choix d’un standard de données dépend du type de service à la demande offert :

	💪 GTFS-flex	🪶 GOFS-lite
Principaux services pris en charge	Transport adapté, taxi collectif ou taxibus, service à itinéraire fixe avec détour	Transport à la demande, transport adapté, taxis, courses à la demande
Type de zone ou d’embarquement	Services allant d’une zone à une autre, d’un point d’embarquement à une zone, et autres services pouvant être réservés à l’avance ou hélés dans la rue	Services allant d’une zone à une autre ou se déplaçant à l’intérieur d’une même zone et pouvant être commandés en temps réel
Objectif principal du standard de données	Informations sur le service et planification des trajets	Informations sur le service et planification des trajets
Prédictions du temps d’arrivée en temps réel pour l’embarquement	Non disponibles. Informations statiques seulement.	Prises en charge
Informations tarifaires	Prise en charge partielle grâce aux fichiers GTFS utilisés pour les services à itinéraire fixe	Pris en charge directement dans le standard GOFS-lite
Gestion des réservations ou des demandes de transport	Lien direct vers l’application, le site web ou le numéro de téléphone du fournisseur du service à la demande	Lien direct vers l’application, le site web ou le numéro de téléphone du fournisseur du service à la demande
Exemple dans Transit	MnDOT (en anglais)	Pace On Demand (en anglais)
Les fournisseurs prenant en charge ce standard de données incluent :	Padam, Simpliciti, Trillium Transit (Optibus)	DemandTrans, Pantonium
Format du fichier	CSV	JSON
Documentation technique	GitHub (en anglais)	Informations supplémentaires et GitHub (en anglais)

Autres standards de données

Mobility Data Specification (MDS) : Il est important de garder en tête que le standard MDS n’est pas conçu pour les intégrations aux plateformes destinées aux usager·ère·s. MDS n’inclut pas les informations sur le service, ne permet pas la planification de trajets et ne prend pas en charge les demandes de réservations ou de collecte. MDS collecte plutôt les informations relatives aux trajets en cours ou passés afin d’aider les organismes de réglementation à mieux comprendre comment les opérateurs de services utilisent les voies du réseau public.
GTFS-OnDemand (GOFS) : Ce projet a rassemblé différents acteurs pour identifier les besoins de l’industrie et développer une spécification couvrant les informations du service et la planification des trajets des transports à la demande, mais ce format complexe n’est pas communément utilisé. À partir du projet GOFS, Transit a créé GOFS-lite. Ce standard de données ouvertes est disponible pour l’ensemble de l’industrie et comprend certaines des informations contenues dans GTFS-OnDemand, mais dans un format plus flexible et plus facile à utiliser.
Transport Operator Mobility-as-a-service Provider (TOMP) API : Développée par un groupe de travail hollandais, cette API permet la réservation de trajets et les transactions pour plusieurs modes de transport, incluant le vélopartage, les taxis, les scooters, le transport en commun à itinéraire fixe et le transport à la demande. L’API n’inclut pas les informations du service et la planification des trajets, mais redirige vers d’autres standards de données pouvant le faire. (Par exemple, GTFS-flex et GOFS-lite couvrent les informations des services et la planification des trajets expressément pour le transport à la demande.)
Transactional Data Specification (TDS) : Cette spécification de données permet aux usager·ère·s de réserver, commander et planifier des trajets adaptés à la demande depuis la plateforme déjà utilisée pour accéder aux informations du service et planifier des trajets. Les entreprises pouvant effectuer des intégrations avec TDS incluent IBI Group et Cambridge Systematics. En collaboration avec Cambridge Systematics et le ministère des Transports du Minnesota, un système de réservation utilisant TDS a été intégré à Transit pour permettre aux usager·ère·s de réserver et gérer leurs trajets à l’aide d’une interface web, directement dans l’application.

API propriétaires compatibles avec Transit

En plus des standards de données ouvertes GTFS-flex et GOFS-lite, Transit prend aussi en charge certaines API propriétaires ayant été développées indépendamment par différents fournisseurs de services à la demande.

Le fonctionnement de ces API propriétaires est similaire à GOFS-lite :

Toutes ces API comprennent les informations sur le service
La majorité prend en charge la planification de trajets et les prédictions de temps de départ en temps réel
Toutes ces API incluent un lien direct vers l’application du fournisseur du service à la demande pour effectuer les commandes, les réservations et les paiements

Les fournisseurs de services à la demande suivants ont développé leurs propres API propriétaires prises en charge par Transit : Curb, Lyft, Heetch, Ola, Padam, Revel, Riide, RideCo, Spare, Uber et Via.

Transit préfère l’utilisation des standards de données. Mais puisque ces API propriétaires ont déjà été intégrées à l’application, il est relativement simple pour les sociétés de transport de travailler avec Transit pour ajouter ces services adaptés à la demande à leurs réseaux. À l’avenir, nous encourageons tous les fournisseurs de services à la demande à effectuer leurs intégrations avec les standards de données GTFS-flex ou GOFS-lite, selon le type de service offert.

Intégration des réservations et des commandes dans Transit

Certaines API propriétaires, similaires aux systèmes de réservation utilisant TDS, incluent une option permettant aux usager·ère·s de réserver des trajets adaptés à la demande et de payer pour ceux-ci à l’aide d’une intégration web à même l’application Transit.

Transit lancera bientôt cette fonctionnalité en collaboration avec les fournisseurs suivants :

Padam
RideCo
Spare Labs

Cette fonctionnalité permettra aux usager·ère·s de se connecter à leur compte de transport à la demande, de réserver un trajet, de demander un transport et d’effectuer leur trajet, le tout depuis l’application Transit.

Précautions supplémentaires

Deux difficultés potentielles sont à garder à l’esprit avant l’intégration d’un service à la demande :

⚠️ Disponibilité, formatage et qualité des données. Les informations offertes par différents fournisseurs ne sont pas toutes du même type ou de la même qualité, particulièrement si une API propriétaire est utilisée :

Informations sur le service : Certains fournisseurs n’incluent pas les informations sur le service, comme la division du territoire en zones et les heures d’opérations, dans leur API. Un travail supplémentaire doit être fait par chaque plateforme destinée aux usager·ère·s pour coder manuellement ces informations dans un format compatible avec les systèmes devant y accéder, et ce chaque fois que ces informations changent, plutôt que de recevoir des mises à jour automatiques de l’API.
Prédiction des temps de départ en temps réel : Certains fournisseurs ne sont pas en mesure de prédire le temps d’arrivée des véhicules pour l’embarquement des passager·ère·s avant la réservation du trajet. Cela signifie que les prédictions des temps de départ en temps réel seront soit erronées, soit non disponibles sur les plateformes destinées aux usager·ère·s.
Planification des trajets : Certains fournisseurs n’incluent pas les informations nécessaires dans leurs API pour permettre aux plateformes destinées aux usager·ère·s d’inclure les services à la demande parmi les options de trajet entre un point A et un point B lors de l’utilisation du planificateur de trajet. Dans ces cas, seules les informations de service, comme la division du territoire en zones et les heures d’opération, sont fournies.

Les sociétés de transport peuvent éviter ces problèmes communs en exigeant, par contrat, que les fournisseurs et les plateformes destinées aux usager·ère·s démontrent soit :

La prise en charge des flux de données GTFS-flex ou GOFS, ou
L’offre et la capacité à intégrer une API propriétaire fournissant les informations équivalentes à celles requises pour un flux GTFS-flex ou GOFS-lite

Ce qui nous mène au deuxième point sensible :

⚠️ Communication des frais et des échéanciers avec le fournisseur et la plateforme destinée aux usager·ère·s . L’installation et le maintien de tout type d’intégrations coopératives, qu’elles utilisent des standards de données ou des API propriétaires, requièrent des ressources de la part du fournisseur du service à la demande et de la plateforme destinée aux usager·ère·s. Assurez-vous de communiquer clairement avec ces deux partenaires à propos des échéanciers et des coûts relatifs à l’intégration avant d’entreprendre celle-ci. En particulier, déterminez à l’avance si les coûts de l’intégration seront assumés par la société de transport ou par le fournisseur du service à la demande.

Exemples de demandes de propositions et de contrats

Les demandes de propositions et les contrats sont la meilleure façon pour les sociétés de transport de contrôler les termes d’une intégration et de récompenser les fournisseurs potentiels pour leur utilisation des standards de données ouvertes.

Certains des exemples de contrats ci-dessous précisent l’intégration dans l’application Transit explicitement. Bien sûr, les sociétés de transport sont libres de demander une intégration en particulier avec l’accord de leurs partenaires avec plateformes destinées aux usager·ère·s, qu’il s’agisse de Transit ou non. De plus en plus de demandes de propositions de la part des sociétés de transport précisent aussi si l’intégration doit respecter les standards GTFS-flex ou GOFS-lite.

Société de Transport de Sherbrooke (Sherbrooke, Québec), janvier 2024 : « Afin de permettre l'intégration de nouvelles technologies, la feuille de route souhaitée par le DONNEUR D’ORDRE pour les prochaines étapes, suivant la mise en place de la Solution, comprend entre autres : L’intégration du GTFS-Flex ou du GOFS-lite pour le TAD. » (Appel d’offres STS-23-09)

Pace Suburban Bus (banlieues de Chicago, Illinois), janvier 2024 : « Interoperability – Contractor shall make the application compatible with other Application Programming Interface (API) or general feed specifications (i.e, GOFS). General feed specifications should comply with MobilityData standards and use the latest revisions (including non‐finalized specifications, if necessary). At a minimum, deep linking will be required with Pace’s MaaS pilot. » (voir page 7 de 15, Exhibit C, en anglais seulement)

KCATA (Kansas City, Missouri), septembre 2022 : « The service must provide users with an estimated pickup time, time of arrival, and fare prior to confirmation of the ride. These service features must be available across all access methods. Services will ideally allow an interface with RideKC Apps to all full trip planning and connections from the flex to fixed routes. »

RGRTA (Rochester, New York), janvier 2022 : « To streamline the customer experience, RGRTA would like to offer a singular platform of payment for the customer to execute all rides across its network. The Masabi Just Ride platform offers an SDK (Software Development Kit) which will enable the functionality of payment integration... delivery of this information to the customer is via Transit app... The proposing vendor shall integrate and provide fare payment through this interface. RGRTA has the understanding that several firms that could respond to this RFP have integrated with parties on other projects and this requirement will not reduce competition. Vendors who meet this requirement will be scored more favorably than those that do not in the evaluation process. If any software development is necessary for the interface, Vendor shall provide in pricing sheet. If any additional hardware is necessary for interface Vendor shall provide in pricing sheet. Timeline to integrate with Masabi JustRide Platform and Transit app shall be incorporated into the overall project plan. »

Saskatoon Transit (Saskatchewan), octobre 2021 :« Move Saskatoon Transit closer toward a Mobility-as-a-Service (MaaS), integrating On Demand trip planning with existing trip planning tools for fixed routes (I.e: Transit app; Google Transit, other) so the customer experience is as seamless as possible. This solution will provide the customer with the available transportation choices based on their preferences and will suggest fixed route options in addition to On Demand. »

St. Albert Transit (Alberta), mai 2021 : inclusion de la formulation « Proven and demonstrable compatibility with the TransitApp through API or General On-Demand Feed Specification (GOFS) » en tant que préférence pour les fournisseurs de transport à la demande. (voir en bas de page 21 de la demande de propositions, en anglais seulement)

VIA Metropolitan Transit (San Antonio, TX), février 2021 : « VIA is also rolling out a new mobility payment platform in 2021 with Masabi and Transit app and is seeking a tightly integrated payment experience in selected partner’s Mobility on Demand app, utilizing the Masabi fare payment engine. Additionally, since Transit app will be utilizing the same Masabi fare payment engine, the Contractor shall work with Transit app to allow trip planning across fixed and Mobility on Demand routes right within Transit app. The whole trip could be planned, booked, and paid right within Transit app.” (voir page 19 de la demande de propositions, en anglais seulement) et « VIA seeks to have provider directly integrate MOD trip planning within Transit app, where VIA customers can trip plan MOD journeys, bus travel, or combined bus and MOD journeys. Ideally, provider would allow full booking of the trip on the Transit app platform as well, but if not, the provider shall work with Transit app to link to the provider’s MOD app for booking. » (voir page 25 de la demande de propositions, en anglais seulement)

Durham Region Transit (Ontario), juin 2020 : demande d’une « Seamless integration with Transit app. » (voir page 1 de l’énoncé de travail, en anglais seulement)