Interopérabilité des données de demande et d’offre de covoiturage entre acteurs du covoiturage

De Communauté de la Fabrique des Mobilites

Description en une ligne:


Description: Il s’agit de travailler spécifiquement sur les formats de données, la nature des données fournies et les modalités d’interfaçage visuel, permettant à différents acteurs du covoiturage urbain de partager leurs offres et leurs demandes, pour offrir aux utilisateurs un service plus complet. La question de l’intégration de la diversité des business models devra être abordée.

Exemple : Wever et Instant System viennent de débuter une expérimentation pour initier un POC dans ce commun. Nous proposons aux autres acteurs de rejoindre l’initiative. Cela s’appuie sur Redex, mais va plus loin. Ceci répond notamment aux demandes des CCI, territoires qui souhaitent faciliter l'aggrégation des offres de covoiturage.

Sur l'interopérabilité, l'enjeu est d'abord d'avoir un référentiel commun et non pas des modalités d'interopérabilité locaux en fonction des différentes régions et des différents opérateurs qui collaborent ou s'interopérent.

Organisations intéressées pour contribuer ou qui contribuent déjà: Instant System, Wever, Roulez Malin, Scity.coop, OuiHop, Hupp, Covoiturage libre, Microstop

Organisations utilisatrice ou intéressée par utiliser la ressource

Contributeurs: HERVOUET Yann, JACQUOT Matthieu, DE LAVERGNE Nicolas, ROUGEAU Franck, ANAYAN Patricia, HERVOUET Yann

Référent: JACQUOT Matthieu, HERVOUET Yann

Défi auquel répond la ressource: Accélérer le déploiement du covoiturage quotidien

Type: Commun

Espace d'échange synchrone (de type chat): covoiturage_quotidien

Espace d'échange asynchrone (de type mail): https://framalistes.org/sympa/subscribe/covoituragequotidien

Lien vers l'outil de gestion des actions:

Lien vers l'outil de partage de fichiers:

Besoins:


Complément:


Prochaine Etape:

A court terme  :

Prochaines étapes à moyen terme :

  • Définir les limites de RDEX - Ce qu'il faut changer, ce qui fonctionne.
  • Mettre à jour RDEX pouu par exemple le covoiturage dynamique
  • Communiquer sur le travail de mise en lien
  • Légitimer le dispositif - Réunion avec le CEREMA, acteurs de la région Rhone Alpes Auvergne. Publication. Avoir des soutiens de la part d'acteurs publics
  • Quels opérateurs, sur un principe de réciprocité, peuvent ouvrir leurs APIs. Comment les acteurs qui n'ont pas d'API financent le développement de leurs APIs. Etre assez rapid sur e.
  • Avoir un retour d'expérience de collaboration : Entre wever et instant system, déjà des choses actives. Entre ecov et wever : Pas encore de solutions techniques pour l'interopérabilité.

Ensuite passer aux étapes suivantes

  • Identifier les covoiturage rééls
  • Métamoteur de recherche qui va chercher dans toutes les bases de données. Ce métamoteur serait entretenu en commun
  • Formaliser un matching une fois les données ouvertes ? Est ce trop ambitieux ?

Autres informations:

RDEX :

  • RDEX est un référentiel existant mais il est fragile:
    • Intérêt de lui donner plus de légitimité (ADEME / CEREMA ?) +
    • Intérêt que les "petits" (mais aussi les "gros") opérateurs puissent avoir rapidement une API documentée permettant la mise en oeuvre facile de l'interopérabilité

RDEX est un modèle d'annonce. A l'époque, ecolutis, roulez malin, covivo. covoiturage.com qui se mettent ensemble.

Derrière, compte tenu des coûts de mise en oeuvre, il doit y avoir un interet économique des acteurs qui s'engagent:

  • Chèque covoiturage
  • Echange de code qui donne une preuve de covoiturage

Aujourd'hui, les acteurs ont besoin de se mettre en mouvement sur cela. Cela fonctionne avec 3 acteurs qui ont des API ouvertes avec RDEX. Covivo-RoulezMalin et LRVerte + Taxistop et Ecolutis dans le passé

Enjeu:

L’interopérabilité, c’est une première étape qui va permettre ensuite de matérialiser une preuve de covoiturage qui elle même va pouvoir être utilisée pour des incitations ou paiements de type chèque covoiturage

  • Pour faire la preuve, l'opérateur qui voit l'échange entre les deux annonces pourrait en garder trace mais cela nécessite que juridiquement la tracabilité soit assumée et assumable
  • Une solution serait d'utiliser la blockchain pour que la tracabilité soit "répartie" (RidyGo travaille déjà sur la blockchain)

Interopérabilité avec les transports en commun: comment par exemple navitia pourrait utiliser les annonces de covoiturage au format RDEX ?

Il existe des agrégateurs "payants" comme kelbillet ou optitrip mais l'idée serait de construire un commun qui rend le même service mais avec une plateforme centrale (voir techniquement décentralisée) collectant les annonces de différents opérateurs (métamoteur de recherche), puis redirection - avec blockchain (rdex) - vers les différents opérateurs en fonction des résultats de recherche est possible à faible Un agrégateur avec compensation entre plateformes.

Tous les acteurs n'ont pas les mêmes modèles. Chaque plateforme va ensuite réinterpréter les choses.

Sujet lié à la question des chèques covoiturage qui peuvent permettre de monétiser les échanges en interopérabilité

L'intéropérabilité avancera vite quand des acteurs auront un intérêt à le faire

Point d'avancement en janvier 2017[modifier | modifier le wikicode]

Suite au premier atelier et à des discussions avec Ouihop, RidyGo et Covoiturage-libre.

Le CEREMA a confirmé son intérêt pour contribuer à sa mesure sur l'interopérabilité entre base de données covoiturage  (angle base de données d'offre de mobilité et formats associés) et a de toutes façons une personne en théorie qui suit le sujet "covoiturage". Malheureusement le poste est vacant jusque septembre 2017 et LCHEVEREAU assure une mission de direction par interim qui ne lui permet pas de s'investir beaucoup.

Néanmoins une réunion peut être proposée avec le CEREMA et la Région Auvergne Rhône Alpes pour avoir un retour d'expérience et préparer une publication du standard RDEX amélioré.

Pour éviter la réunion sans suite, la mise en forme et la réécriture des documents RDEX disponibles sur le site de la FEDUCO est nécessaire avant la tenue de la réunion. La réunion permettrait donc d'ajouter un chapitre sur le retour d'expérience et de valider les modifications éventuelles en partant d'un nouveau document.


A ce stade, c'est surtout du temps qui est nécessaire: voir si un financement modeste des contributeurs potentiels permet d'accélérer la construction et quels sont les contributeurs (vu que c'est essentiellement Covivo-RoulezMalin qui a écrit les supports jusque là, ce serait bien que la relecture et la mise en forme par un nouveau soit l'occasion pour lui de mieux comprendre RDEX de l'intérieur).


Ensuite se pose  la question de la mise en oeuvre concrète car pour l'instant elle reste limitée à quelques acteurs et quelques territoires. La mise en oeuvre suppose des prérequis:

  • une vraie volonté de partager les données ce qui signifie que le modèle économique ne repose pas sur la donnée ou que la donnée est considérée comme enrichie par l'interopérabilité
  • une API pour chaque opérateur qui accepte de rendre sa base interopérable pour recevoir et communiquer les données selon le standard RDEX

Sur l'API, les avancements des opérateurs sont différents:

  • Certains opérateurs ont une API non ouverte et à compléter pour RDEX
  • Certains n'ont pas d'API (fonctionnement client-serveur interne)
  • Certains ont une API déjà compatible avec RDEX

Pour que l'interopérabilité puisse être mise en oeuvre rapidement et le plus largement possible, une proposition est d'aider au financement du développement ou de la mise à jour du développement.

RidyGo estime qu'un opérateur de covoiturage sans API peut en mettre une en oeuvre en 1mois.homme (20jours). Covivo-RoulezMalin confirme ce point. Nous convenons aussi que de nombreuses questions connexes peuvent être chronophages : sécurité, maintenance... Ainsi en doublant ce temps, il y a une certitude que l'opérateur peut s'y retrouver mais dans tous les cas l'idée serait de cofinancer l'implantation d'API au format RDEX avec une obligation d'ouverture des données (API) en conséquence sans limite territoriale ou quantitative et pour un minimum de temps (3 ans, 5 ans?). Il ne s'agirait pas de financer en totalité. Le co-financement est aussi une manière de s'assurer que la démarche est une conviction et non pas une opportunité.

Ouihop rappelle que cette interopérabilité ne fonctionne pas pour les données temps réel (covoiturage dynamique) et que donc c'est problématique pour les opérateurs concernés.

Ouihop et RidyGo sont également d'accord pour dire que co-financer x API pour x opérateurs représente un coût en doublon par rapport à l'utilisation de la blockchain et d'une API commune telle que prévue sur le commun "chèque de covoiturage". En effet à partir du moment où le service existe en blockchain pour le chèque de covoiturage, les informations pour les trajets/annonces peuvent aussi être traitées de la même manière. Reste alors à déterminer quelle est la gouvernance de cette API sur une base de données en blockchain.

Covivo-RoulezMalin ne connaît pas cette techno mais craint que le temps de mise en oeuvre puisse être long et que donc au final les temps de développement (API globale contre plusieurs petites API distribuées pour chaque opérateur) soient similaires.

L'avis de tous les contributeurs et les personnes intéressées par le commun "interopérabilité" est sans doute nécessaire pour trancher.

Covoiturage-libre est OK sur l'interopérabilité afoin que les trajets du quotidien de son site soit accessibles à tous et vice versa sur les longues distances. Sous réserve, de relecture de ce compte rendu, l'idée d'avoir une API pour permettre cette interopérabilité les intéresse puisqu'aujourd'hui cette API n'existe pas pour eux.

Instant System est identifié aussi comme contributeur et Covio-RoulezMalin verra avec eux leur positionnement avant la fin de l'année.


Instant System sent qu'il existe une demande des territoires (par exemple le STIF) pour un métamoteur (par exemple covoiturage-leman.org). Mais il pourrait être développé un métamoteur en opensource qui serait exploitable par les opérateurs partie prenantes qui développeraient les interfaces pour leurs clients. Le métamoteur géré en commun n'aurait pas en soi d'interface cela éviterait de se poser trop de questions sur comment doivent être affichées et triées les annonces. La gouvernance se limiterait à savoir qui développe et maintien le métamoteur et avec quel budget. Ce métamoteur accessible sous forme d'API n'est pas contradictoire avec un usage de la blockchain.

L'inconvénient du metamoteur par rapport à RDEX, c'est que l'expérience utilisateur est limitée puisque le covoiturage nécessite un échange de coordonnées qui oblige à être redirigé sur la plateforme "propriétaire" de l'annonce et de s'y inscrire si l'internaute ne l'est pas. L'avantage c'est que le coût global ne dépend pas du nombre d'opérateurs alors que dans le cas de RDEX l'échange des coordonnées nécessite que chaque opérateur adapte a minima son API pour traiter cet échange, échange qui n'existe pas dans le cas du métamoteur puisque c'est l'internaute qui doit s'inscrire et s'adapter à la plateforme dans laquelle il est redirigé.

A ce stade il y a deux approches qui ne sont pas forcément exclusives l'une de l'autre: métamoteur ou interopérabilité RDEX. Faut il choisir ou faire les deux ? Si les deux sont faits Covivo-RoulezMalin pense que les opérateurs ne peuvent pas s'engager dans l'un sans s'engager dans l'autre car dans les deux cas l'intérêt est qu'il y ait un maximum d'opérateurs ou plutôt d'annonces concernées.