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

Développer la pratique du covoiturage en améliorer l'interopérabilité des différentes offres

https://rdex.fabmob.io

💼 porté par Covoiturage libre, Hupp, Instant System, Mobicoop, OuiHop, Roulez Malin, Scity.coop, Microstop

Discuter sur le chat Poser des questions

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.

Le dépôt github : https://github.com/fabmob/rdexplus

L'adresse : https://rdex.fabmob.io

Google doc : https://docs.google.com/spreadsheets/d/1IgJz8d_VAEHbzfSup0XjR2xDARm9gczHd_0BJmPyKhE/edit#gid=1142712071

Organisations utilisatrices ou intéressées pour utiliser la ressource : Conseil régional de l'environnement, Conseil régional de l’environnement de l’Estrie (CREE), Nextérité, Regroupement national des conseils régionaux de l’environnement du Québec (RNCREQ)

Contributeur(s) : HERVOUET Yann, JACQUOT Matthieu, DE LAVERGNE Nicolas, ROUGEAU Franck, ANAYAN Patricia, HERVOUET Yann, SARRAT Olivier

Tags : Covoiturage, RDEX

Catégories : Données

Thème : Données ouvertes, Covoiturage quotidien

Référent : JACQUOT Matthieu, HERVOUET Yann

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

Personnes clés à solliciter :

Autre commun proche : API covoiturage Vianavigo, Preuve de covoiturage, Embarque Estrie

Richesse recherchée :

Compétences recherchées :

Communauté d'intérêt : Communauté autour des données ouvertes, Communauté autour du Covoiturage quotidien, Covoiturage au Québec

Type de licence :

Conditions Générales d’Utilisation (CGU) :

Niveau de développement :

Lien vers l’outil de gestion des actions :

Lien vers l’outil de partage de fichiers :

Besoins :

Prochaines étapes : Atelier final de bonification du standard RDEX+

Documentation des expérimentations :

Autres informations

Liste des acteurs qui utilisent ou souhaitent utiliser ce commun :

• Mobicoop

Liste des CR d’atelier en lien avec ce commun :

• CR Atelier Communs du covoit (bdd des aires et interopérabilité des données)
• CR Atelier final bonification RDEX+

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

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.

Point d'avancement en février 2018

Rappel de l'historique des travaux sur l'interopérabilité:

• initiative en 2011 de 4 opérateurs de l'époque (Ecolutis, covoiturage.com, RoulezMalin, Covivo) qui lancent RDEX, un standard d'échange des annonces en covoiturage téléchargeable sur rdex.org
• en 2013 la FEDUCO accepte de reprendre les travaux sur RDEX notamment pour lui donner plus de légitimité auprès des autres opérateurs et des pouvoirs publics (http://www.feduco.org/articles/actus/rdex/)
• RDEX est mis en oeuvre concrètement entre Ecolutis et Covivo sur 2 territoires (Bourgogne et Isère/Drôme-Ardèche) et entre Taxistop et Covivo pour la Région Wallonne (le service ne sera jamais ouvert au public)
• le Cerema a réalisé une évaluation du dispositif entre Ecolutis et Covivo
• Ecolutis racheté par SNCF et fusionné avec Greencove prend des positions depuis lors contre le standard RDEX afin sans doute de proposer une solution plus proche de ses intérêts
• RDEX est utilisé aussi pour un métamoteur franco-suisse en 2015: www.covoiturage-leman.org mais certains opérateurs n'ayant pas d'API, RDEX n'est donc pas mis en oeuvre par tous
• RDEX est utilisé en 2016 pour rendre interopérable les bases des services Covoit'oùra devenu Mov'ici avec covoiturage-grandlyon et auvergne-covoiturage (service opérés par LRVerte)
• IDFMobilité lance fin 2017 un metamoteur de recherche mais ne s'appuie pas sur RDEX pour le faire évoluer quand bien même IDFMobilité soutient les travaux de la FabMo

--> c'est donc naturellement que les différents acteurs concernés cherchent à faire converger les différents protocoles d'interopérabilité en un seul

Retour d'expérience sur l'interopérabilité des services entre Drôme-Ardeche et Isère opérés respectivement par Ecolutis et Covivo:

• peu de transformation en prise de contact: 6 sur 8000 requêtes en 3 mois (mais les requêtes étaient systématiques, qu'il y ait des résultats issus de l'interopérabilité ou pas)
• algorithmes différents entre les partenaires/services donc les annonces remontées en résultats peuvent être de qualité différente
• différences de politique de gestion entre les deux services/partenaires (nom, prénom ou autres données pas forcément connues, paiement pas disponible...)
• gestion des temps de réponse différents à prendre en compte pour que cela n'impacte pas la qualité globale du service (cela n'avait pas été pris en compte à l'époque)
• surcharge potentielle des serveurs de chacun des services est un élément qui avait été soulevé mais qui n'avait pas trouvé de réponse immédiate: chacun des opérateurs assumant cette surcharge dans le cadre de son marché public avec les Départements respectifs

Retour d'expérience sur l'utilisation du métamoteur d'IDFMobilité:

• à la question posée de savoir pourquoi RDEX n'a pas été retenu par IDFMobilité comme base de leur métamoteur, la réponse technique est que les données des opérateurs présents autour de la table étaient plus riches que celles présentes sur RDEX (cela n'empêchait pas en soi d'enrichir RDEX plutôt que d'utiliser d'autres variables mais la raison n'est peut être pas que technique)
• 200 à 300 000 requetes par jour sur vianavigo cela pose la question des coûts générés chez les opérateurs pour traiter ces requêtes avec un temps de réponse très court: ainsi d'autres méthodes sont envisagées que la seule méthode d'interrogation des opérateurs en temps réel - qualité du matching et tri des résultats sont aléatoires: actuellement le critère retenu pour afficher et trier les résultats et le temps de parcours mais on ne sait pas comment c'est calculé par chacun des opérateurs
• qualité (deeplink) du transfert vers l'opérateur demeure un souci d'autant que certains opérateurs ne proposent leurs services que sur application mobile (si 8 opérateurs, nécessite idéalement d'avoir 8 inscriptions et éventuellement 8 applis téléchargées)
• pas de différence entre trajet planifié et trajet temps réel voire trajet habituel (qui est considéré comme trajet temps réel ce qui n'est pas la même chose) et pas de différence faite entre une annonce qui est récurrente et annonce qui ne l'est pas - est ce qu'il faut une notion de pertinence qui ne serait pas basée uniquement sur le temps de parcours?
• API/métamoteur est opensource même si la publication sur GitHub ou équivalent n'est pas encore faite et même si la question de la gouvernance de ce dépôt n'est pas traitée (possibilité que la FabMob s'empare de cette gouvernance avec IDFMobilité ou IDFMobilité en assure la gouvernance seule?)
• prise en compte du rayon au point de départ ou d'arrivée (800m ou plus?)

--> problématique différente en milieu rural

--> différenciation entre zones denses et peu denses possibles dans le rayon de recherche

--> le rayon au départ et à l'arrivée ne traite pas le sujet du parcours central non inclus dans les rayons mais cette approche est suffisante en milieu dense

• réunion avec retour d'expérience prévue par IDFMobilité le 12 mars matin

Echange sur d'autres projets en cours:

- system X travaille sur calculateur multimodal avec covoiturage à Lyon

- Lanes (bornes covoiturage sur Lyon entre Bourgoin et Lyon avec intégration entre bornes Ecov et application/base de données Instant System)

- NETEX Transmodel (normes sur les transports en commun)

--> intérêt pour interopérabilité avec les SIM mais pas utile pour interop entre 2 services de covoiturage

Conclusions et suites à donner:

- Périmètre de travail de ce commun: Noms des variables, Description des variables, Espace de travail commun

- Espace de travail commun = espace qui ne nécessite pas à ce stade d'être "technicien/développeur": https://docs.google.com/spreadsheets/d/1IgJz8d_VAEHbzfSup0XjR2xDARm9gczHd_0BJmPyKhE/edit?usp=sharing

--> l'accès en modification/édition est réservé aux gestionnaires du commun qui ont pour but à court terme de faire converger RDEX

--> proposition de faire une réunion "technique" de discussion en reprenant chacune des variables, l'ensemble ensuite étant soumis aux collectivités pour avis le cas échéant (08 mars 15h30 au STIF ou en ligne)

--> si évolution standard, implémentation sera à faire par les territoires et donc les opérateurs qui utilisent RDEX ou le service IDFMobilité

--> le standard pourrait être diffusé par le CEREMA (à confirmer) outre la FabMob et la FEDUCO

- Objet technique: API opensource --> quelle gouvernance ? FabMob?

--> l'important c'est plus les données et l'évolution de ces dernières que le code source lui même

- évolution aussi prévue d'une connexion commune covoiturage (un peu comme France Connect mais pour le covoiturage par exemple - sujet à repréciser avec EtatLab qui n'a pas participé à la réunion)

Point d'avancement le 8 mars 2018

Présentation :

• de l'intérêt de faire converger RDEX et la documentation IDFMob
• des nouvelles notions à intégrer (Rex) en perspective (exemple de la "réservation")
• du nouvel atelier de travail à prévoir
• de la gouvernance à redéfinir autour de la FabMMob

Décisions/évolutions sur la documentation:

• proposition de faire évoluer le nom RDEX pour se projeter sur l'avenir: "RDEX+" a fait consensus parmi les présents
• choix de retenir par défaut les noms de variables IDFM quand les variables existent aussi en RDEX pour impacter moins fortement le plus grand nombre d'opérateurs

--> l'essentiel a déjà pu être validé ainsi, quelques interrogations subsistent et méritent validation plus large (en rouge dans le document partagé)

• quelques points présents dans RDEX demandent une réflexion plus longue sur la manière dont cela doit être traité: la distinction passager/conducteur, la fréquence (régulier/occasionnel), la concatenation des adresses, la notion de points de passage, les plages horaires
• quelques points présents dans IDFM non présents dans RDEX ont été validés sans difficulté (les liens vers les applis/deeplinks, les préférences...)
• la notion de prise de contact avec le covoitureur affiché "POST Connections" n'existe pas dans IDFM mais peut rester pour RDEX+: elle pourrait servir de base à la réflexion de l'ajout de la notion de réservation/booking
• proposition du prochain atelier sur ce commun le mardi 10/04

Point d'avancement en avril 2018

A cette adresse vous trouverez les conclusions de la réunion de travail dans les colonnes RDEX+, nouveau standard proposé suite à la fusion et au retour d'expérience du standard RDEX et Vianavigo: https://docs.google.com/spreadsheets/d/1IgJz8d_VAEHbzfSup0XjR2xDARm9gczHd_0BJmPyKhE/edit?usp=sharing

Cette réunion "technique" avait pour objet essentiellement de définir le nom des variables et de vérifier si le nouveau standard pourrait être compatible avec les besoins des différents "clients" l'utilisant jusque là. Ce qui est bleu a été validé en réunion directement. Certaines lignes (orange/jaune) n'avaient pas fait l'objet d'une proposition en réunion et doivent faire l'objet d'une validation collective puisqu'à ce stade il ne s'agit que d'une proposition de Covivo-RoulezMalin (Olivier Sarrat en copie qui reprend le dossier). Les éléments sont présentés ci-dessous.

- les attributs sont parfois à la racine (utilisation plus simple pour les développeurs ) ou parfois dans des sous-objets (meilleure lecture pour une vue d'ensemble notamment pour les non développeurs): il ne nous a pas semblé possible de ne privilégier qu'une seule manière d'écrire

- certaines variables ont été homogénéisée (pas de _ et Majuscule pour faire la séparation visuelle, utlisation du "lower camel case" déjà utilisé sur Vianavigo)

- passage de la distance en "optionnel" comme dans vianavigo alors qu'elle était obligatoire dans RDEX

- sur le prix, conservation de toutes les variables, soit 3 variables qui puissent permettre soit à l'opérateur de renvoyer ou non un prix avec une distinction payant/gratuit, soit de renvoyer un prix constitué d'un fixe et d'un prix au km (dans le cas où l'opérateur ne calcule pas le prix pour permettre à l'utilisateur de l'information de le faire: utile dans l'hypothèse d'un trajet conducteur utilisé partiellement par rapport à la demande passager)

--> discussion à avoir sur la notion de "gratuit" et "sans commission" car le type, n'est pas clair là-dessus.

- sur les itinéraires, les deux approches ont été conservées (Polyline standard Google de Vianavigo ou les points de passages de RDEX)

- sur le nom des variables pour les points de prise et de dépose passager, les attributs sont dans des sous-objets, qui peut être "passenger" ou "driver" c'est donc le nom de variable RDEX qui a été conservé ce qui constitue une rare exception puisque chaque fois que possible, les variables Vianavigo ont été privilégiées

- avait été ajouté la possibilité de nommer un point en "poiName" optionnel lors de la discussion pour faire référence au commun "lieux de covoiturage"

- possibilité de rechercher avec certains paramètres pas gérés par tous les algos (comme radius ou des trajets réguliers) : l'erreur "NOT_IMPLEMENTED" pourra alors être retournée

--> discussion de fond à avoir car la qualité du résultat renvoyé et son appréciation dépendent de la qualité de la requête initiale

- sur les durées d'attente ou flexibilité, pour prendre en compte la possibilité de gérer dans le standard des trajets réguliers et des trajets passager, le type reste celui de Vianavigo en secondes mais la durée se calcule par la différence entre deux dates/moments

- sur "Post connections" (mise en relation) qui n'existait pas dans Vianavigo, mise en conformité avec les règles de nommage décidées

Pour mémoire les fonctionnalités principales nouvelles par rapport à Vianavigo:

- la possibilité de rechercher des passagers et non plus uniquement des conducteurs

- la possibilité de proposer une mise en relation en 2e étape après le renvoi des résultats

- la distinction "realTime" ou pas

Quelques questions soulevées à traiter lors de notre prochaine rencontre le 4/10 pm à Paris chez blablacar:

- validation par les opérateurs, les administrations et les collectivités engagées dans le commun

- mise à jour du document de description fonctionnel de RDEX+

- retour d'expérience d'IDFMobilité sur les paramètres departureRadius / arrivalRadius et sur l'approche à retenir pour maîtriser la qualité par les informations disponibles sur les résultats renvoyés

- publication de la description fonctionnel et de la description technique et mise à disposition en ligne

- calendrier réaliste de mise en oeuvre de RDEX+ sur les nouveaux projets à venir (évolution des projets existants ou nouveaux terrains d'interopérabilité)

- respect des RGPD et protection des données: faut il une charte liée à l'utilisation du standard?

Atelier 4 Octobre 2018

Voir le CR de l'Atelier.

Atelier du 15 Janvier 2019

Compte-rendu complet de l'atelier disponible ici.

Prochaines étapes convenues au terme de cet atelier :

• IDFM va vérifier ce qu'il peut partager techniquement sur leur compte mobilité "ViaNavigo connect"
• La FabMob est invitée à faire une proposition d'ici 6 mois de convergence des protocoles d'interopérabilité qui intègre la mise en relation sans ré-authentification et la preuve de covoiturage
• beta.gouv est invité à intégrer la question de la preuve de covoiturage en contexte d'interopérabilité dans ses travaux sur le registre de preuve

Exemple d'intégration de RDEX à l'appel d'offres d'une collectivité (Alpes Maritimes) : https://www.cerema.fr/system/files/documents/2019/06/6_developpement_covoiturage_cd06.pdf

Atelier final de bonification de RDEX+ (18 mars 2021)

Compte-rendu de l'atelier disponible ici.

Principales conclusions :

• Une version initiale v2.0.0 du standard RDEX+ est validée.
• Un groupe est initié pour gérer la gouvernance du standard.

Action suivante : Fabmob: créer une liste de discussion publique pour initier ce groupe de gouvernance avec opérateurs qui veulent déjà initier (Ridygo, Mobicoop, Ouestgo, Rezopouce), un représentant du RPC, un représentant de la FabMob.

Réunions du Groupe RDEX+

Le fil des comptes-rendus des réunions du Groupe RDEX+ depuis juin 2021 est disponible sur ce lien : Comptes-rendus du Groupe RDEX+.