Construction d’un socle standard pour fournir un écosystème de services Mobilités aux territoires

Des besoins en services de mobilité différents pour chaque territoire

Tout dépend de sa géographie, de la topologie, des demandes de ses citoyens et visiteurs, de son équilibre économique et bien d’autres éléments qui lui sont propres. L’effet plateforme dans la mobilité n’est finalement jamais si global mais une répétition de solutions localement adaptées.

Sans compter que les besoins de mobilité par les personnes sont très différents. La plupart du temps obligatoires, pour se rendre au travail. Mais aussi plus agréables dans le cadre des loisirs, voire sociaux pour sortir de son isolement.

Ils sont de courte ou de longue distance, combinés ou uniques. Mais jusque-là, très rarement sans couture, alors que le voyageur ne souhaite bénéficier que de solutions pratiques, efficaces et économiquement pertinentes.

Réinventer  ?

Alors pour répondre de manière idéale à ces challenges variés et complexes, chaque solution de mobilités pour un territoire est construite ad hoc, sans réelle possibilité de la dupliquer aisément.

D’autant qu’aucun acteur privé n’est en mesure de couvrir tous les services. A contrario, on bénéficie même d’un vivier d’acteurs très compétents sur un panel plus ou moins large de solutions à disposition. Beaucoup d’énergie est déployée à agglomérer les solutions de ces acteurs projet par projet.

L’idée

Pour réussir à répondre aux besoins des territoires, il faudrait donc pouvoir bénéficier de toutes ces richesses de services disponibles, sans contraindre les fournisseurs, de les déployer rapidement et de les réutiliser facilement dans d’autres contextes.

Elargir le business des fournisseurs de service tout en répondant de manière adéquate aux voyageurs des territoires, le jeu en vaut la chandelle.

Pourquoi redévelopper un puzzle multi-services à chaque fois, au lieu d’utiliser un modèle standard d’invocation commun des services de mobilité pour faciliter un écosystème ouvert et dynamique, adaptable et scalable.

Tout en préservant un environnement compétitif et le développement commercial de chacun, l’idée est de mettre à disposition un langage d’échange commun, déjà disponible et open-source. Il permet les déploiements rapides de projets de mobilité. Ce langage commun doit aussi posséder le potentiel pour la découverte et la mise en relation directe entre les acteurs de la communauté business et les voyageurs, ces derniers souhaitant rester pleinement au contrôle de leurs données personnelles.

Ainsi, il répond au besoin spécifique d’une collectivité. Car il offre à ses usagers une solution adaptée pour planifier ses déplacements, les réserver et les payer simplement, tout en stockant les informations voyageur avec une protection forte de la donnée.

Et ça existe déjà !

Nous proposons de fournir ce langage d’échange commun open-source, déjà finalisé grâce à un financement européen Horizon 2020, il se nomme Masaï.

Cette approche est basée sur le modèle bien connu du concierge face à sa communauté. Le Concierge fait le lien entre le Voyageur et les Fournisseurs de Services. D’ailleurs, il est possible de recourir à autant de concierges que nécessaires.

Les Concierges accèdent aux Services de Mobilité disponibles à l’aide du Service de Découverte standardisé. La plateforme des concierges est donc centrée sur le Voyageur, doté d’un dossier de voyages sécurisé (préférences, itinéraires, etc.) et d’une application Concierge qui permet les interconnections entre les différents Fournisseurs de Services nécessaires pour le contexte du territoire.

Le framework décrit les modèles standards d’échange et d’accès aux différentes plateformes de services mobilité des acteurs qui adhèrent, au dossier sécurisé voyageur, à la brique paiement, aux mécaniques de rétribution à l’usage… Il permet même la découverte automatisée de services.

Une association européenne, Masaï Mobility Community, supporte et permet d’animer cette communauté ouverte de Fournisseurs de Services et de Concierges, en maintenant à jour les spécifications techniques du framework, en fournissant des outils, des composants technologiques, et des moyens de tests pour valider l’adhésion aux standards des solutions impliquées.

Plusieurs projets ont déjà déployé ce langage commun Masaï (Deutsche Bahn Reisebuddy, Agglomération de Nice, Transports Bus Rede Expressos…).

Et maintenant…

L’étape suivante serait ainsi de le décliner sur plusieurs territoires d’expérimentation, en France et en Europe. Selon la même démarche, et avec une pluralité de services de mobilités, la solution mise en place répondrait ainsi à l’expérience utilisateur et au respect des intérêts des parties prenantes, générerait des économies significatives grâce à une plus grande rapidité et souplesse de déploiement, tout en facilitant l’accès à de nouveaux marchés.

Pour réussir cela, nous proposons une démarche projet agile en plusieurs phases, et orienté résultat, succès après succès :

  1. Lancement du projet (groupe de travail)
    • Adhésion des 1ers fournisseurs services et concierges
    • Sélection des expérimentations
    • Élaboration du budget et obtention des financements
    • Organisation du  projet et du travailler ensemble
    • Description visuelle et écrite
  2. Implémentation & Développement
    • Mise en œuvre itérative
    • Déploiement du framework auprès des fournisseurs de services et concierges
    • Réduction du temps de mise en œuvre et des coûts de déploiement
  3. Validation à l’échelle
    • Expérimentations territoires
    • Evaluation en environnement réel pour estimer toute la complexité
    • Mise en application sur 1ère vague de territoires français sélectionné
    • Lancement et Généralisation
  4. Généralisation
    • Stratégie de montée en charge et go-to-market
    • Qualité attendue et les coûts souhaités
    • Objectifs de développement
    • Extension aux territoires européens

Vous êtes intéressés ?

Please follow and like us:
error0