À chaque calculateur d'itinéraires sa stratégie d'intégration des données

À chaque calculateur d'itinéraires sa stratégie d'intégration des données

Il n’y a pas d’unique modèle de calculateur d’itinéraires ! Il est possible de les catégoriser selon la diversité des services proposés, le public ciblé, l’ergonomie de l’interface, etc. Et pourquoi pas les distinguer selon leur stratégie d’intégration des données ?

Les grandes catégories de calculateurs d’itinéraires…

Aujourd’hui, le marché de la recherche d’itinéraires peut être structuré autour de trois grandes catégories :

  • Les solutions propriétaires grand public (ex. Google Maps, Transit App, Citymapper…),
  • Les applications de recherche d’itinéraires en marque blanche fournies sous forme de solutions commerciales destinées aux Autorités Organisatrices des Mobilités (AOM), qu’elles soient basées ou non sur des moteurs de calcul open-source,
  • Les calculateurs d’itinéraires spécialisés sur un type de mobilité (vélos, piétons,..), qu’ils soient open-source ou non.

Il faut noter que, très souvent, les deux dernière catégories se reposent sur des moteurs de calcul d’itinéraires en open-source. Ces moteurs de calculs peuvent à la fois proposer des itinéraires de bout en bout ou une seule partie d’un itinéraire multimodal. Dans ce dernier cas, ils sont très souvent combinés pour proposer les résultats finaux à l’usager, selon des règles d’interfaçage et d’interopérabilité spécifique.

… ont des stratégies données complètement différentes

Chaque catégorie de calculateur d’itinéraires a des caractéristiques propres en matière d’intégration des données.

Les solutions grand public font de l’intégration de masse

Très souvent, les plateformes grand public se reposent sur les informations essentielles de l’offre de transport. Ces dernières sont intégrées en suivant principalement les formats GTFS Schedule et GTFS Realtime.

Dans ce cas, l’open data est utilisé comme :

  • Premier levier d’analyse de la complétude des données disponibles,
  • Outil d’évaluation de l’effort d’intégration vis-à-vis du volume de voyageurs couverts.

Dans la mesure où ces solutions ont pour vocation de couvrir le plus de territoires possibles, elles ne choississent que ponctuellement des intégration directes de jeux de données en provenance des AOM ou des opérateurs. Et, dans tous les cas, elles s’assurent d’un certain niveau de complétude des jeux de données avant leur passage en phase de préparation. Cette dernière comprend des corrections ou des compléments aux données collectées ou bien un travail de transcription dans un format interne qui leur permet d’optimiser la performance de l’algorithme. Les données ainsi retravaillées ou enrichies ne sont en général pas republiées. Elles constituent en effet un facteur différenciant majeur pour le calculateur d’itinéraires que les acteurs ne souhaitent pas partager à la concurrence.

Les solutions en marque blanche privilégient des collectes depuis les systèmes producteurs

Les applications en marque blanche ont plutôt tendance à collecter directement depuis les systèmes producteurs de données. Compte tenu de la relation commerciale entre le prestataire développeur de l’application et l’AOM donneuse d’ordre, l’accès aux outils de graphicage / habillage ou SAEIV est facilité.

On peut distinguer des approches différentes selon le degré de prise en charge par l’AOM ou le prestataire.

Certaines AOM internalisent largement la gestion des données, en prenant la responsabilité de leur préparation en amont du calculateur d’itinéraires. Cela correspond à la situation dans laquelle le prestataire développeur de l’application se désengage largement et n’accompagne pas l’AOM sur ce volet.

D’autres AOM préfèrent, au contraire, déléguer la préparation de la donnée au fournisseur qui a en charge le développement de l’application mobile. Le développeur de l’application se positionne alors sur la préparation / intégration de la donnée de manière plus affirmée. Il est amené à mettre en place des connecteurs spécifiques (par exemple, pour le transport à la demande ou les mobilités partagées) et à mettre en qualité la donnée collectée. Dès lors, il fait de ces services de gestion de la donnée un véritable argument commercial.

Du point de vue des formats de données, on constate des approches plus diversifiées : par exemple, s’appuyant en même temps sur le fichier GTFS Schedule produit par l’outil de graphicage et sur le flux SIRI en sortie du SAEIV.

Les fournisseurs d’application en marque blanche vont également avoir tendance à collecter des données plus spécifiques. Il s’agit souvent d’intégrer plus de modes de transport que les plateformes généralistes ou de créer des liens avec d’autres services, en particulier la billettique. Dès lors, les donnés sont disponibles selon le modèle interne utilisé par le calculteur d’itinéraire, rendant plus complexe son extraction dans des formats de données standardisés.

Les solutions spécialisées mettent en place des collectes directes

Les calculateurs d’itinéraires spécialisés s’appuient sur des données très riches et peu standardisées. Les processus de collecte, mise en qualité et intégration des données spécifiques font partie de leur stratégie de différenciation. Ces solutions deviennent alors expertes d’un mode particulier (ex. piéton, vélo), ce qui leur permet de s’interfacer plus facilement avec des solutions en marque blanche.

Lorsqu’elles le peuvent, ces solutions vont privilégier des formats de données standardisés pour pouvoir les mettre à disposition de l’AOM. On notera tout particulièrement l’usage de NeTEx pour les solutions de cacul d’itinéraire piéton accessible qui permet aux solutions de s’ouvrir davantages d’opportunités de marché tout en bénéficiant d’un interfaçage renforcé avec la topologie de l’offre de transport public.

Les moteurs open-source utilisent principalement l’open data

Quant aux moteurs de calcul open-source, ils ont tendance à privilégier l’usage des jeux de données en open data mis à disposition en GTFS Schedule et GTFS Realtime. Cela leur permet d’avoir de nombreux jeux de données formant une base commune pour affiner leur algorithme de calcul. C’est sur ce dernier point que leur proposition de valeur est la plus forte, et non pas sur la partie intégration / amélioration des données de mobilité multimodale.

Ils peuvent servir de briques à une solution en marque blanche afin de disposer d’un calcul d’itinéraire de bout en bout pour l’usager, mais également d’une interface utilisateur spécifique à l’AOM.

Des approches hybrides

Il est important de noter que les stratégies d’intégration des données mises en œuvre par les différents acteurs peuvent se combiner. Ainsi, une solution grand public pourra faire de l’intégration des données un argument commercial et négocier un partenariat avec l’autorité organisatrice lui garantissant l’accès à des données de qualité, voire à des données différenciantes.

Dans la mesure où AOM et opérateurs souhaitent être visibles de tous les calculateurs d’itinéraire, ils ont tout intérêt à définir leur propre stratégie de gestion de données.

Une gestion en propre permet de garantir :

  • L’accès complet aux données et en particulier aux données enrichies,
  • La cohérence des données exportées quel que soit le format standardisé attendu par le calculateur d’itinéraires,
  • Les exports différentiels de données selon le type de calculateur d’itinéraires alimenté (grand public, en marque blanche, etc.).

➡️ Comment Chouette et Ara vous permettent de gérer vos données en amont de la recherche d’itinéraires

Plus d'articles

Lettre dans une enveloppe

Incrivez-vous à notre newsletter

Recevez les derniers articles et actualités directement dans votre boîte mail.