CR Entretien Tu-Tho Thai (Benchmark MaaS)

Image :

Description en une ligne : Entretien avec Tu-Tho Thai, directrice des partenariats Europe chez MobilityData, mené par Marguerite Grandjean et Ghislain Delabie dans le cadre du Benchmark MaaS le 26 octobre 2021

Description : Entretien avec Tu-Tho Thai, directrice des partenariats chez MobilityData, mené par Marguerite Grandjean et Ghislain Delabie dans le cadre du Benchmark MaaS le 26 octobre 2021.

Intro

Quel est ton rôle à MobilityData?

Directrice des partenariats Europe & Événements

Mission : Agrandir et fédérer la communauté autour des standards & outils + financement de notre écosystème

Comment est née MobilityData?

Les grandes lignes : Initiative née en 2015, incubée par le Rocky Mountain Institute (RMI), pour l’élaboration et la diffusion des meilleures pratiques de production de jeux de données en GTFS. Le RMI est un institut à but non-lucratif de soutien à des initiatives de lutte contre le changement climatique

Enregistrement en tant qu’organisme à but non lucratif au Canada en 2019, DG Léo Frachet.

Enregistrement en tant qu’association en France début 2021.

En détails : Issu de la communauté open-source qui a bourgeonné autour du GTFS et qui n’avait pas d’endroit où échanger les bonnes pratiques, ni pour créer des outils open source pour améliorer l’information voyageur.

D’abord incubé par le RMI avec comme premier succès la publication des bonnes pratiques autour de la production / réutilisation des jeux de données en GTFS en 2018.

Ce momentum a poussé à la création d’un organisme à but non-lucratif en 2019, enregistré au Canada, avec un financement initial porté par la communauté.

À l’origine, le GTFS a été écrit par Google et TriMet (Portland, Oregon, USA) dans le but de proposer de l’information voyageur dans une application de cartographie. Succès immédiat car format simple et léger pour les opérateurs de transport public.

Inspiré par ce succès, a été conçu le GBFS pour proposer la même chose pour la mobilité partagée. Initiative à l’origine portée par la NABSA (association américaine de vélo-partage). Au vu de l’ampleur du succès et de la communauté, NABSA a choisi MobilityData pour développer le standard et le maintenir. Son auteur, Mitch, est employé de l’association, il voulait ce rapprochement.

Que ce soit le GTFS ou le GBFS ce sont des standards de facto de l’industrie.

La communauté grandit avec réutilisateurs + producteurs. Beaucoup d’applis / industriels + AOM.

Les PAN en Europe s’y sont intéressés.

Des instances publiques comme le département des transports de l’état de Victoria (Australie) ou DGITM en France, sont membres de MobilityData.

Le GTFS est né en 2006, a vécu dans une communauté informelle pendant plus de 10 ans, qui s’est en partie fédérée en 2019.

Une communauté sans modérateur ne peut vivre qu’un certain temps. Il y avait trop de versions GTFS sur le marché. Un petit AOM ne savait plus quelle version utiliser, risque sur la nature même des bénéfices apportés par la standardisation.

Comment avez-vous fait le tri ?

Premier travail : tout répertorier et consolider.

Beaucoup d’éléments étaient les mêmes sous des noms différents.

Gouvernance du standard par le consensus en demandant à la communauté ce qu’elle préfère entre les option A ou B, par exemple.

Pas eu de conflits, car format utilisé par des plateformes de poids comme Maps.me (Apple) ou Moovit ou Google Maps. Donc intérêt à la convergence pour les opérateurs.

Convaincre des moteurs de la communauté en priorité est essentiel.

Quelle était la vision de MobilityData pour fédérer les communautés ?

Vision = viser l’amélioration globale de l’info voyageur, pour éviter l’usage de la voiture individuelle. Il y a un manque.

Perspective commerciale : si les services sont représentés dans les applications généralistes d’info (Maps, Citymapper, Movit…), ils auront plus de clients.

Arrivé aussi au moment de l’explosion des smartphones et un intérêt pour la fiabilité de l’information.

Intérêt porté par la communauté technique, qui perdait du temps sur les différentes variantes des jeux de données.

Activités de MobilityData :

80% du travail, c’est améliorer les données.

• Validateur canonique pour valider la conformité des jeux de données
• Notation de la qualité des données (pourquoi ce n’est pas conforme, ou les irrégularités). Outils Open Source
• Mobility Database : base codée comme Wikipedia pour recenser tous les jeux de données connus, pour faciliter la vie des utilisateurs de GTFS / GBFS. Comme le PAN mais à l’échelle internationale.
• Amélioration des spécifications et des standards. Ex: ajouter autopartage dans GBFS, autres contraintes que trottinettes + vélos.
• Documentation précise pour tous.
• Formations, encore en développement. Ex : Animé le webinar du PAN français sur info TR pour expliquer possibilités du GTFS-RT. Présentations globales des standards aux techniciens ingénieurs. - Partenariat fin 2020 FabMob sur l’écosystème en Afrique, pour digitalisation. Ont répertorié les projets utilisateurs de GTFS, pour améliorer le standard pour le transport informel.

Y a-t-il d’autres fonctionnalités en développement ?

Tant que c’est pour l’info voyageur, oui.

On va étendre pour compléter les outils nécessaires à la production/représentation d’une information voyageur de qualité.

Adoption

Combien y a-t-il d’implémentations actuellement ?

Très difficile à tracer.

GTFS : 1300 opérateurs produisent, sur 2800 jeux de données.

GBFS : 650 jeux de données.

Aucune idée des modélisations académiques.

Écosystème

Qui sont les contributeurs ?

Très diversifié, de plus en plus avec l’ouverture européenne au-delà des US.

La question du RGPD les occupe beaucoup. Aux US la conception de vie privée est différente.

Est-ce qu’il y a des acteurs qui ne sont pas représentés, par exemple en mobilité inclusive ou solidaire ?

Oui, il en manque.

Mobilité inclusive : on ne connaît pas les acteurs, donc trop peu.

Manque de diversité géographique (Afrique, Amérique du Sud, Asie…)

Cas de l’Asie :

• Coréens sont dans ISO. Ils veulent un tampon.
• Japon a son propre profil GTFS.
• Singapour : l’État gère l’écosystème.
• Pays Asie du Sud-Est : plus ouverts à une communauté Open Source car ne pourraient pas payer un standard propriétaire au prix fort.

Quelles sont vos relations avec les autres organisations qui développent des standards MaaS?

On travaille avec Data4PT (groupement des auteurs de Netex, SIRI, Transmodel sous la bannière de l’UITP et ITxPT), mais pas directement avec le CEN.

Une réunion mensuelle avec eux pour rendre tout ça compatible, assurer que toutes les extensions réalisées sont compatibles.

Pour DG MOVE: pas d’accord de partenariat formalisé mais des rencontres ponctuelles.

Veille sur tous les programmes Horizon Europesur le développement de standards, à la fois pour la partie financière et pour la partie écosystème.

Équilibrer les forces entre l’UE et les US.

Visions très différentes : GTFS et GBFS sont très légers et non exhaustifs.

NeTEx/Transmodel a répondu à presque toutes les problématiques de modélisation, donc plus complexe.

On travaille sur la création d’un profil GTFS dans NeTEx ou d’un rapprochement avec le profil dédié à l’information voyageur.

ex. enRoute avec le convertisseur Chouette, convertit GTFS en NeTEx profil France.

TOMP-API : ils développent des choses qu’on n’aa pas la bande passante de faire. Donc on les aide pour accélérer un peu mais surtout s’entraider et s’aligner.

On ne travaille pas sur des aspects régulations, ni de contrôle des exploitations des concessions par les autorités publiques.

ex. MDS utilise le GBFS, mais pas dédié au service de l’amélioration de l’expérience usager. Ce n’est pas tout à fait la même communauté d’intérêt.

Gouvernance

Quel est le statut juridique de MobilityData?

Nonprofit au Canada (2019)

Association en France (2021)

Y a-t-il une équipe à plein temps ?

Oui, 22 salariés.

Grandi très vite : en sept 2019 on était 2 !

Croissance rapide, avec des financements d’institutions + adhésions de membres pour embaucher largement.

Quels sont leurs profils et leurs rôles ?

• 2.5 ETP sur l’admin
• 3 ETP partenariats
• 2 ETP sur la DG
• Tout le reste : équipes techniques (modélisateurs de données, interfaces users, bdd…)
• 1 ETP externalisé sur des compétences absentes de l’équipe (ex. temps réel).

Profils internationaux : Paris, Berlin, Canada, NYC, Minnesota, Portland.

Facteur pour recruter vite. On se retrouve une semaine par an pour répondre aux problématiques du travail à distance.

Plein de gens motivés, plutôt jeunes. Mais une asso a du mal à recruter des profils techniques, car plafond de ressources. On joue sur les conditions de travail (flexibilité), l’ambiance, les activités, etc.

Comment sont structurés les rôles et les statuts des membres ?

cf. document de gouvernance.

Working Group :

Si on nous le demande, quelqu’un de MobilityData fait le rapporteur.

Ce n’est pas forcément le cas : ex. Japon, question spécifique. On est dans leur Slack, mais tout est en japonais.

Ils nous envoient des jeux de données informatiques qu’on peut étudier.

Quels sont les processus de décision, formels et informels ? Qui prend les décisions ?

Chacun est toujours libre de verser des contributions.

Chacun peut formuler des propositions de manière ouverte sur GitHub. Chacun est libre de voter sur les propositions ouvertes.

Chez TOMP-API c’est le GT qui formule des propositions, soumise à la communauté ouverte qui en discute.

Cela permet de récupérer des réutilisateurs qui étaient loin et avaient leur propre implémentation, qui ont un retour intéressant.

Ensuite, vote par consensus à l’unanimité des votants (pas de veto) avec minimum 1 producteur et 1 producteur de données. La partie qui propose l’extension n’a pas droit de vote.

Tout vote contre doit être documenté, même très légèrement.

Qui possède le standard ?

Concrètement, la propriété intellectuelle est encore GTFS à Google et GBFS à la NABSA.

Mais en cours de transfert vers MobilityData.

Comment définirais-tu la communauté autour du standard ?

Certaines communautés sont assez indépendantes, comme le Japon, avec ses extensions propres. Des petites communautés indépendantes nous demandent régulièrement d’animer des extensions.

Conditions pour accepter : il faut un peu de financement (une personne ou du temps à consacrer) + Demandes aux membres de l’association s’ils y voient un besoin immédiat (3-6 mois) ou si c’est du long terme (1, 2 ou 3 ans).

Ex : été 2020, levée restrictions post-pandémie, services à la demande type VTC ont décollé. Des opérateurs / AOM ont voulu un standard en urgence pour “transport à la demande”. Les membres étaient tous OK, ils ont fait un GT avec le.taxi (France) et Uber (US) parmi d’autres. Travaillent depuis décembre, et auront une description du transport à la demande (hormis cas particuliers type paratransit) à la fin de l’année.

Quel est le rôle de MobilityData dans la gouvernance ?

MobilityData a le rôle d’animateur de communauté, on ne prend aucune décision sur l’évolution des standards.

Notre roadmap est ouverte sur l’évolution de GTFS et GBFS, tout le monde peut commenter et proposer une modification.

On a notre équipe de développeurs pour réaliser certaines extensions, mais toujours en coopération avec les membres.

ex. Début pandémie en Europe, extension du “taux d’occupation” est remontée dans l’ordre des priorités. Nos équipes ont fait le travail préliminaire de modélisation et cadrer les compétences, et beaucoup de développeurs et techniciens sont venus aider. Le développement s’est fait en 6 semaines, très rapide.

Y a-t-il des sujets clivants ?

Du moment qu’il y a une preuve, on étudie.

Il y a des extensions qui ont provoqué des remous, ex. inclusion des données opérationnelles dans GTFS. Ça n’est pas passé car les données doivent pouvoir être publiques sans problèmes de protection des données, etc.

Donc cela a créé une sous-communauté, avec des outils gérés que par eux.

Une convergence paraît difficile, mais pas d’opposition de principe. Si demain 80% de la communauté nous dit qu’elle le voudrait, ce sera validé.

Globalement, il y a toujours des discussions entre ces 2 profils : les producteurs de données qui veulent limiter le nombre de champs nouveaux et/ou complexes, et les consommateurs de données qui veulent un maximum de détails.

Y a-t-il des règles pour assurer la bonne foi ? des méthodes d’exclusion ?

Un acte de mauvaise foi ne s’est pas encore produit.

Arrivé qu’avec une personne qui bloquait, provoqué un rdv et demandé ce qui n’allait pas. Il trouvait qu’on poussait l’agenda de Google. Démontré que la voix de Google et Apple n’avait pas plus de poids.

Règles d’accès

Quelle licence utilisez-vous ?

GTFS & GBFS : Apache 2.0

Tous les autres docs sont en CC-BY 4.0

-> Pas d’obligation de reverser les modifs ou utilisations (licence full open source).

Mais souvent en pratique les gens le font.

Le PAN utilise ODBL et c’est obligatoire, tandis que MobilityData préfère le partage spontané / volontaire. Les enjeux sont différents pour ce choix.

Vous avez opté pour l’open source dès le début ?

C’est venu progressivement, pour répondre aux besoins des acteurs de l’écosystème.

Au départ le format a été écrit par TriMet (Portland, Oregon, USA). Google a demandé à l’utiliser, cela a été décidé dans la foulée d’en faire une coopération. C’était en 2006. Donc, plus de 10 ans de vie informelle avant de voir émerger le besoin et l’intérêt de créer MobilityData.

Business Model

Quel est le budget de MobilityData ?

Fonctionnement sur année scolaire 2020-2021 : 1.3 million d’euros

Dons défiscalisés, présence asso 1901 en France permet de couvrir toute l’Europe.

Quels sont les coûts ?

85% RH

15% provisionné en matelas de sécurité.

D’où viennent les revenus ?

3 sponsors principaux représentent 70% du budget.

Le reste est du membership. Conditions : tout le monde peut adhérer si c’est une organisation. Pas d’adhésion à titre individuel.

5 niveaux d’adhésion, selon le degré d’implication désiré :

- Bronze : faire partie sans moyens financiers / humains à mettre dansle développement standard. Gratuit (ex : FabMob)

- Argent : regarder ce qui se passe, sans développer (relecture, droits de vote au CA + feuille de route)

3 niveaux de OR à DIAMANT selon volonté d’implication / contribution. Diamant pour grosse entreprise : 30 700€ pour une entreprise de +1.6m CA.

La plupart des membres sont en Bronze et Argent.

- Diamant : 2 membres.

- Platine : 2.

- Gold : 0.

Globalement les entreprises manquent de temps / ressources humaines sur développement des standards / outils. Ne peuvent pas toujours contribuer au code. Le plus souvent, veulent bien être relecteurs, mais pas contributeurs.

Est-ce que ça peut poser un problème que les choix soient faits par les contributeurs et pas par les autres membres ? Sont-ils prêts à accepter les résultats ?

On a fait un choix : différencier la gouvernance des standards de celle de l’organisation. Pour être sûr que les 2 standards continuent d’appartenir à la communauté et non à l’organisation qui la gère.

À l’opposé de TOMP-API, qui a choisi de laisser la décision finale au sein du GT de comment le format évolue.

Éviter d’être uniquement dédié à des acteurs privés, tout en ayant un CA compétent.

-> Si le membre n’a pas le temps de s’impliquer, dans le standard ou dans les outils autour, il ne peut pas venir le reprocher !

Comment penses-tu que MobilityData va évoluer à l’avenir ?

À court terme, avoir la propriété intellectuelle de GBFS et GTFS.

Dans 2 ans, doubler l’équipe pour aller plus vite.

D’ici 5 ans, on aura réfléchi à “jusqu’où va l’information voyageurs”

Cycle de 5 ans car pas évident de trouver des gens prêts à animer une communauté open source. Ça peut être ingrat, car pris à partie sur des conflits.

Lancé notre événement sur les enjeux de la donnée dans la mobilité, car manque crucial. Modèle OSM, avec des événements régionaux et nationaux.

Prise de note sur le PAD (cocher si Oui) ? Non

Commun(s) impliqué(s) : GTFS, GBFS

Communauté(s) d'intérêt impliquée(s) : Standards Ouverts pour des MaaS d'intérêt général

Prochaine Etape : n/A

Autres informations :