< retour à la page précédente

2.Algorithme

Interopérabilité des systèmes d'informations 2

Cet article est la suite de http://labs.canaltp.fr/2013/10/interoperabilite-des-systemes-dinformations:

Itinéraire porte à porte: pourquoi choisir un système réparti ?

Nous avons précédemment présenté le principe d'interopérabilité des systèmes de calcul d'itinéraire. Nous avons également abordé la raison pour laquelle les systèmes répartis ne peuvent en théorie pas trouver la meilleure solution à une recherche d'itinéraire. Du coup, voici un petit comparatif des 2 méthodes : agrégation de données dans un service central consolidé ou agrégation de service dans un système réparti. Celui-ci va nous aider à comprendre la raison qui pousse Canal TP et Cityway à engager de la R&D sur un nouveau protocole, dans le cadre d'un projet de recherche commun subventionné par l'AFIMB. Tout d'abord, il faut rappeler que les systèmes d'information voyageurs, les calculateurs d'itinéraires multimodaux, sont mis en place:

  • soit par des transporteurs (par exemple www.tcl.fr à Lyon)

  • soit par les collectivités locales : régions, département, commune, etc. (par exemple www.destineo.fr ou www.vianavigo.com)

On appellera ces calculateurs des SIM (Système d'Information Multimodal). Je passe volontairement sous silence les entités autonomes "non concernées par l'article" (http://www.mappy.com, http://www.multicity.citroen.fr, http://maps.google.com, etc.)

Quelques points de comparaison

Protocole d'échange

Ce point est le plus simple à identifier : afin de présenter des itinéraires de porte à porte entre 2 adresses situées dans des régions distinctes, 2 SIM doivent soit s'échanger mutuellement leurs données, soit offrir une interface compatible. L'échange de données parait de prime abord plus contraignant que l'échange de service. En réalité le travail d'intégration des données d'une région dans une autre est simplifié par le fait que les données fournies sont globalement "propres" puisque déjà utilisées dans le SIM d'origine. Par ailleurs les limitations des algorithmes de systèmes répartis nécessitent une administration fine des métadonnées. Ce qui induit des échanges fastidieux entre les acteurs : répartitions/fusion des lignes présentes en double (ou coupées comme le RER A) dans chacun des calculateurs régionaux, activation de points de correspondance manuels, le tout en faisant intervenir plusieurs acteurs et donc avec des lourdeurs de gestion de projet... Ce tweet d'Herr Doktor Tristram en réponses aux annonces de Frédéric Cuvillier résume parfaitement la vision "hacker" de la chose: https://twitter.com/tristramg/status/433264080477233152 Bref, jusque là pour avoir essayer les 2, c'est plutôt kif-kif...

Qualité des réponses et performances

Je ne vais pas m'étendre sur le fait qu'intrinsèquement, seule la méthode par système consolidé permet d'obtenir l'ensemble des solutions optimales. Quant aux performances de calcul, les calculateurs consolidés sont forcément plus performants, n'étant pas contraints algorithmiquement, et n'ayant pas de latences réseaux. Pour ces points, malheureusement, il n'y aura pas de miracle : le système réparti que nous étudions, comme les existants, va rester un peu lent comparé à un service "all inclusive" comme vianavigo.

Souplesse des services à disposition

Les systèmes répartis existants ne proposent que le service de calcul d'itinéraires. A contrario, sur les systèmes d'information standards, reposant sur une base de données horaire complète, une multitude d'autres services peuvent être imaginés : fiche horaire de ligne, prochains passages, navigation dans le référentiel, mais aussi et surtout analyse de l'offre inter-transporteur. Ce dernier point est identifié comme un axe d'aide à l'amélioration de l'offre de transport, en particulier autour des points de correspondances. Il est temps en effet de révéler les "trous d'offre" qui se produisent régulièrement les dimanches ou en soirée ! Et pourtant ce service est difficilement implémentable sans base consolidée.

Maîtrise des itinéraires présentés

J'ai abordé ce point dans ce billet. Ce qui intéresse les collectivités locales, c'est la possibilité de contrôler les itinéraires sur leur territoire. Ainsi, les nouveaux calculateurs d'itinéraires s'orientent vers des solutions plus naturelles qu'auparavant : itinéraire confortable, itinéraire sportif, touristique, etc. Et les régions, qui organisent les transports, souhaitent chacune mettre leurs spécificités en avant, comme une marque de fabrique. Cependant, ces nouveaux types d'itinéraires reposant sur des algorithmes personnalisés, ne suivent aucune norme. Ils ne suivent pas de cohérence entre deux régions, même très proches. Ainsi les régions Bretagne et Pays de la Loire, frontalières, présentent leur offre sous des formats très différents. Le site Destineo, des Pays de la Loire, propose un minimum de paramètre à l'internaute, et présente plusieurs types d'itinéraire différents. L'internaute fait son choix a posteriori. A contrario, le site BreizhGo propose plus de paramètres, mais les réponses ne s'écartent pas de la demande. Comment un système réparti pourrait-il réconcilier ces deux méthodes de présentation de l'offre de transport ? Forcément les itinéraires présentés entre les SIM locaux et ceux du meta-système seront différents.

Mais alors... pourquoi est-ce intéressant ?

Tout simplement pour répondre au problème récurrent de maîtrise des données. Si l'échange et l'intégration d'un jeu de données tiers dans un système n'est pas complexe techniquement, les acteurs rechignent toujours à fournir l'intégralité de leurs horaires. Le système réparti permet donc de simplifier les accords de réciprocité entre les collectivités locale ou nationale (grandes lignes, région, département, communes, etc.) puisque l'on maîtrise le périmètre d'utilisation des données. Personnellement, j'y vois un autre intérêt : une concurrence plus forte et plus saine entre les différents calculateurs d'itinéraires. En effet, le maillage des SIM référencés par un système réparti est constitué de plusieurs types de calculateurs hétérogènes. Par conséquent, statistiquement, plus d'acteurs peuvent pénétrer les marchés de calculateur sous-jacent. On peut donc mettre en concurrence des calculateurs qui couvrent la même zone géographique. On permet également aux collectivités locales de travailler en collaboration avec leur propres universités ou PME dans le cadre de projets qui peuvent s'inscrire directement dans un système réparti.

Conclusion

Parallèlement, l'ouverture des données permet de déclencher des initiatives alternatives comme www.navitia.io, qui sont moins contraintes, puisque reposant sur la maîtrise de l'ensemble des données manipulées. Les services proposés seront forcément plus nombreux, plus créatifs, mais ne pourront pas combler le besoin d'interconnexion entre les systèmes si l'on souhaite adresser les itinéraires internationaux ou les acteurs qui conservent l'exclusivité de leur données.  

Par Stephan Simart, le 21 February 2014