Une voiture avec chauffeur à la demande pour éviter d’en posséder une lorsque notre usage ne le justifie pas. Un moyen supplémentaire de faire le pont entre deux moyens de transport lorsque la distance, les heures de services disponibles ou d’autres raisons empêche de le faire à pied ou à vélo. Autant de raisons de justifier la présence du taxi parmi les modes de transport indispensables pour une mobilité durable dans le Grand Montréal.
Comment l’expérimentation a-t-elle permis d’intégrer cette industrie, si complexe et diverse aux dynamiques d’innovation tout en restant au plus près des préoccupations de ses usagers et de l’industrie ? Comment la question de la valorisation des données du taxi a progressivement repoussé les travaux et réflexions vers une meilleure connexion avec le terrain ?
Cet article retrace la trajectoire du projet d’intégration du Registre des taxis à un planificateur de trajet et les expérimentations ayant permis d’en dérisquer les éléments clés car la Fabrique des Mobilités Québec contribue au déblocage des enjeux soulevés par les parties prenantes. Nous avions publié un premier article cet hiver à propos de l’état actuel de l’industrie du taxi et son évolution afin de commencer à diffuser les apprentissages.
Comment intégrer le taxi à la mobilité intégrée ?
Depuis plusieurs années, le Bureau du taxi de Montréal (BTM) et les professionnels du Service des Technologies de l’information de la Ville de Montréal entretiennent et développent le “Registre des taxis”. Celui-ci est une cartographie permettant de visualiser la position géolocalisée de chaque taxi en temps réel et les informations de disponibilités à propos de celui-ci.
Le Registre ayant rapidement été vu comme une opportunité de partage des données du taxi qui seraient utiles à l’écosystème en mobilité, les équipes concernées ont ensuite travaillé sur des standards de données ouvertes (“GOFS” renommé depuis “GTFS-on Demand”), faisant émerger par la suite l’idée d’intégrer ce Registre à un planificateur. Au début de Montréal en commun, l’objectif était de valider cette intégration comme “preuve de concept”.1
La Fabrique des Mobilités est principalement intervenue sur deux volets d’expérimentation : technique (test du fonctionnement de l’API, test d’expérience utilisateur) et mobilisation des parties prenantes (sondage des opérateurs, recueil des besoins usagers et comparaison des solutions de planification existantes sur le marché).
Dérisquer grâce à l’expérimentation, maximiser ses chances de succès sur le marché
En premier lieu, la Fabrique des Mobilités avait été sollicitée pour travailler des cas d’usage des données du taxi d’un côté, et une comparaison des solutions de planification sur le marché de l’autre, axée autour des modèles d’affaires des divers fournisseurs possibles, avec leurs avantages et inconvénients. Cela a mis en évidence le planificateur le plus adapté aux besoins du BTM.
Cependant, ce résultat impliquant un travail postérieur de négociation, la Fabrique des Mobilités Québec a pu proposer l’opportunité de dérisquer en amont le fonctionnement de la clé API du Registre afin de faciliter son intégration (ou celle du format le mieux adapté à l’application choisie). Cette proposition offrait un double avantage : enrichir l’outil de planification de trajet (basé sur Open Trip Planner) et vérifier le bon fonctionnement du Registre de l’autre (notamment sur répartition équitable entre les opérateurs de taxi). Cette expérimentation, réalisée avec le service des TI de la Ville et le BTM, fit suite à l’intégration du Registre et permit de concrétiser et valoriser des années de travail de ces équipes car l’intégration est un succès.
Les réflexions successives autour de ces tests permirent également de déceler et lever certaines réticences de la part des opérateurs de taxi, parties prenantes essentielles au bon fonctionnement de l’ajout de ce mode de transport au futur projet de “mobilité intégrée”. Certains affichaient des doutes quant au caractère équitable d’une telle technologie quant à la sollicitation d’un taxi via le Registre et la répartition des clients entre les opérateurs.
Ces questionnements débouchèrent sur le second axe de travail expérimental : la compréhension des besoins et enjeux des opérateurs et des usagers. Pour cela, nous avons réalisé deux sondages : le premier, destiné aux opérateurs pour comprendre leur degré de familiarité avec les parcours utilisateurs de leurs usagers, et le second, pour sonder les attentes des usagers eux-mêmes. Ces deux enquêtes, en “miroir”, devaient nous permettre d’identifier des désalignements éventuels ou des angles morts dans le développement des solutions comme l’intégration du Registre à un planificateur.
Le climat de confiance bien établi permettra de réaliser un test en direct avec le BTM pour valider le bon fonctionnement de l’API2, terminant de lever les doutes présents au départ dans les prochains mois.
Aujourd’hui, nous travaillons à mieux cartographier nos connaissances des parcours utilisateurs autour du Registre afin de repérer les risques prioritaires pour les prochaines expérimentations. Par exemple, la problématique du passage d’une interface (planificateur) à une autre (opérateur) et les éventuels problèmes d’expérience utilisateur associés semblent émerger comme éléments à dérisquer prochainement. Cette compréhension des besoins permet aussi de travailler le positionnement du taxi au sein des options de mobilité intégrée, notamment comment le différencier d’Uber et mettre en évidence sa valeur propre.
- “Une preuve de concept (que nous appellerons POC pour Proof of Concept) est une démonstration de faisabilité, c’est à dire une réalisation expérimentale concrète et préliminaire, courte ou incomplète, illustrant une certaine méthode ou idée afin d’en démontrer ou pas la faisabilité”. (Source)
↩︎ - Application Programming Interface : une API est une “interface logicielle qui permet de « connecter » un logiciel ou un service à un autre logiciel ou service afin d’échanger des données et des fonctionnalités.” (Source)
↩︎