CR Entretien Christian Senly (Benchmark MaaS)
Image :
Description en une ligne : Entretien avec Christophe Senly en tant qu'expert participant à MaaS Alliance, Calypso et Cubic mené par Marguerite Grandjean et Ghislain Delabie dans le cadre du Benchmark MaaS, le 29 novembre 2021
Description : Entretien avec Christophe Senly en tant qu'expert participant à MaaS Alliance, Calypso et Cubic mené par Marguerite Grandjean et Ghislain Delabie dans le cadre du Benchmark MaaS, le 29 novembre 2021.
Introduction
Quel est votre rôle chez MaaS Alliance ? Calypso ? Cubic ?
Expert Ticketing.
J'ai travaillé chez OSTP et d'autres avant d'être chez Cubic.
Calypso : Standardisation et sécurité des systèmes embarqués "secure core"
MaaS Alliance : Je suis dans le Ticketing Working Group qui réunit environ 100 membres / autorités organisatrices, opérateurs, techs, constructeurs automobiles... qui veulent comprendre leur place dans le MaaS.
L'enjeu du ticketing est intéressant car 80% du volume se fait dans le transport public.
Aujourd'hui, je suis employé 100% par Cubic (Environ 6000 salariés avec un QG aux USA). Historiquement, c'est une entreprise d'ingénierie (ascenceurs, etc.) puis elle a évolué en 2 filières : La defense et le transport public, principalement dans le pays anglophone. Aux USA (NYC, LA, SF... soit une disaine de grandes villes américaine), en Australie, au UK (Londres), en Irlande, mais mais aussi en Allemagne et à Singapour...
Le coeur Métier : des solutions techs mais aussi opérateurs "Merchant of record" quand il le faut. Par exemple, dans le transport public, Cubic collecte les paiements des passagers de bus. C'est un i.e. Cubie paie l'opérateur de bus même si le passager n'a pas eu les fonds pour payer. En d'autres, Cubic n'est jamais isolé sur une transaction, on agit sur l'ensemble des transactions, on est fait de la "revenue Collection" sur tous les passagers.
La valeur ajoutée est dans la vision plus opérationnelle, avec des responsabilités financières dans la durée, souvent un engagement de plus de 10 ans nécessitant des investissements lourds et des risques, voire des pertes.
Quelle est votre vision des standards ouverts ?
C'est un prérequis pour notre activités. Cubic ne peut pas faire sans, car les solutions propriétaires ne peuvent pas intégrer les réseaux qu'ils opèrent sans engagés des coûts supplémentaires. Avant, un contrat était structuré verticalement (carte, équipement, back-office, paiement...) pour tout adapter à la structure tarifaire de la région / AOM. On avait la maîtrise de tout. On allait jusqu'à négocier avec l'opérateur telecom, on se substituait à l'AOM qui était peu opérationnelle.
IDFM par exemple a une capacité opérationnelle et un mandant bien plus ancrés dans les opérations au quotidien. Il y a des grosses différences entre AOM entre les différents régions du monde. Cubic a des expériences très variées.
Est ce que c'est un avantage ?
Pas vraiment. Il n'y a pas de middleware, on tournait sur ANSI C et pas de C++ ou de C#. On n'avait pas le choix de faire du propriétaire.
On savait les standards dont on avait besoin. Mais c'était un marché de niche avec peu de volume d'affaires, donc peu de moyens pour capitaliser sur le produit = Métier difficile.
Beaucoup d'acteurs sont crispés sur les standards. C'est un petit guerre industrielle entre européens / japonais / US sur les standards du sans-contact. Sur Secure Card, avec STMicroelectronics, Infineon, NXP, SonyFelica etc cela reste de la petite niche.
En Asie, on voyait passer des notes techniques sur des standards type ISO/IEC 14443 alors que ce n'était pas ce qui arrivait sur le terrain. Chacun défendait ses intérêts. On a créé une industrie européen avec le Secure Card, c'est bien mais cela reste petit par rapport au sujet ( les standards ouverts)
Il y a un bénéfice à avoir ces standards spécifiques, non ?
Il faut un écosystème de développeurs qui contribuent. Le client = le développeur. Et personne d’autre… Ce ne sont pas les opérateurs ou les intégrateurs.
Le problème dans la sur-standardisation, c’est de vouloir résoudre en même temps tous les problèmes de l’avenir ET du passé, en étant compatible avec tout.
Cubic a un message marketing sur le “one account” : facilitateur d’une expérience de compte unique. On travaille avec des AOM pour gérer l’authentification des utilisateurs et la sécurité, de manière ad-hoc, sous leur responsabilité.
Enjeu = garantir l’interopérabilité sans avoir des standards techniques compliqués, avoir de la légèreté pour des applis mobiles, définir le strict minimum qui permet d’assurer l’interopérabilité:
- Portabilité minimale pour qu'un développeur puisse faire le passage des données d'usage d'une application à une autre
- Mobility service provisionning = délégation d'un service digital de bout en bout.
- Problème avec le compte mobilité comme commun : où est créée la valeur ? Une startup a besoin d'un Compte Mobilité, pour se valoriser. Un compte utilisateur est un atout pour une startup, elle montre l'adoption & la rétention.
On a creusé notre trou. La pensée simple sur les standards était : collecte des revenus billettiques mais il faut de l'interopérabilité. D'abord on entre sur le réseau, il y a le protocole de la carte ( Important !). Le MSP ou l'opérateur de services fait son business, il doit parler à une autre entité = MSP /MaaS / banque pour lier le compte du voyageur à compte de l'opérateur de transport. D'où le standard ISO 14443 OK pour l'échange avec les autorités de transport normalisé avec ISO 24014 ( Integrated Fare Management System)OK, avec des rôles abstraits pour l'interopérabilité.
Mais quand quelqu'un est venu avec un App, c'était bloquant ! Aucun APP ne s'est intéressé à l'ISO 24014. Donc le standard n'est pas adapté !
Techniquement c'était un bon standard, mais pas adapté au mode du téléphone mobile avec des entités supranationales et des serveurs partout.
Les Européens sont leaders dans la niche du Contactless, mais pas dans les processus, le cloud, l'internet ... On est capable de créer des standards très pertinents ( Ex RGPD), et de les imposer par l'interventionnisme, mais c'est difficile de le faire par la force des marchés
Comment la FabMob pourrait aider ?
Pour raisonner en écoystème de mobilité avec des acteurs "disruptifs", il faut des commun au milieu de tout cela.Des communs sur les données (certaines ouvertes, d’autres avec de la propriété intellectuelle, juste milieu à trouver) : données utilisateurs, données production, etc. Les méta-données peuvent avoir un intérêt au-delà des données brutes / naturelles - qui ont une valeur supérieure.
La donnée brute naturelle, c’est de l’or.
Les lois / réglementations créent des contraintes, les standards doivent aider les petites sociétés pour répondre aux contraintes.
–> C’est le régulateur qui devient le client.
Car on n’a pas confiance en Facebook pour nos données personnelles, mais pas confiance en l’Etat français non plus, car le standard ne sera pas orienté client… Donc besoin d’un intermédiaire.
Logique d’innovation ouverte, pas nécessairement de bien commun. Besoin de gérer les différents intérêts entre les acteurs, sinon ils vont batailler.
- Des acteurs de l'industrie très forts comme Apple ou Google
- 3 interfaces essentielles
- Portabilité des données du compte
- Roaming d'un réseau à l'autre (cf téléphonie mobile) sans que ce soit contraignant
- Niveau 3 ! Mobility Intiation Service Provisionning pour déléguer le rôle de réalisation du service mobilité digital de bout en bout. Parallèle avec le rôle PISP de PSD2
- Besoin d'interface simple pour qu'un utilisateur demande à une autre application de gérer un trajet de A à B. On délègue la confiance mais en restant centré sur les comptes mobilité du voyageur.
- Besoin de le définir c'est possible. A travailler avec des acteurs de la chaîne comme un standard (centrée sur le Compte Mobilité). Créer une approche d’innovation qui fonctionne, avec des développeurs. Transport partagé, un standard de facto pouvant être adopté.
Ex. Dans la location de voiture, ils ont déjà leurs manières de faire. On ne peut pas leurs demander de tous refaire. Il faut se poser la question du minimum viable pour permettre l’interopérabilité.
Comment et où faire ce travail ? Comment le rendre pérenne / systématique ? Où s'investir .
Favoriser la commission Européenne.Le règlement ITS peut être approché comme PSD2 (Payment Service Directive). Ils ont créé la norme IBAN. Ne descend pas au niveau des API, ils sont sur le grand schéma, les rôles, les interfaces, les responsabilités avec les conséquences. Ne pas descendre trop bas.
Et le ticketing ?
Quand ils regardent les appels d’offre dans le détail, les ingénieurs voient que l’ABT (Account Based Ticketing) tourne beaucoup autour des tickets, alors qu’il faut éviter une trop grande verticalité qui détruit l’écosystème. Il faut tronçonner l’ancrage qui n’a pas lieu d’être. Il faut protéger le compte mobilité en le rendant fluide, que les développeurs ajoutent des choses, que l’utilisateur choisisse, et le MSP aussi, sans créer des contraintes d’intégration ou impacts externes. C’est ce qui compte. Les fournisseurs de plateformes devront résoudre les frictions, et se battre là-dessus.
Historiquement, le transport en commun en Europe a une mentalité hybride.
Mandat publique mais opérations privatisés, en concurrence. Lorsque une technology account-based est utilisé, impossible de transférer le compte d’une compagnie à un autre acteur - données 100% propriétaires de facto. Si la donnée doit être ouverte, il y a des chances pour qu’une version de meilleur qualité existe ailleurs et soit elle propriétaire.
Standardisation de données = souvent une grosse erreur. Pas par les données que ça passe, pas par la revente de tickets, mais par le compte mobilité. Standardisation de l’interopérabilité du compte mobilité. Les communs doivent faciliter l’intégration des services digitaux de mobilité, qui est différente selon chaque territoire. Logique horizontale et non verticale.
Il y a des recherches sur ce thème, théorie des réseaux. Selon les industries, les réseaux deviennent des silos (avec moins d’interopérabilité), d’autres s’auto-régulent.
Recherche académique aérien vs. rail. ce qui marche, c’est la concertation entre acteurs industriels, pas l’intervention des pouvoirs publics. Via un nouveau standard ou une initiative de collaboration.
Ex. GSM avec Vodafone : P2P, un petit groupe de champion se met d’accord sur une collaboration en vue d’améliorer l’expérience utilisateur, interopérable entre Suède / Danemark / Angleterre, avec des comptes similaires et des coûts de roaming faibles. Point commun = brique très réduite (petit payload). Cela a attiré les autres opérateurs.
La même approche est possible pour les réseaux de mobilité.
Et si on avait un bien commun pour développeurs, en Europe sur le sujet de l'authentification partagée par exemple ?
Cela doit être consommable par des développeurs. “Le développeur a besoin de briller. Il commence par une petite implémentation, il le montre à ses collègues… Il faut lui donner des ‘trucs magiques’ pour qu’il aille vite sur des sujets clés.”
Partir de niches spécifiques pour démontrer l’effet sur l’écosystème. Sur autopartage / covoiturage ?
MaaS Alliance
Où en est MaaS Alliance aujourd'hui ?
Aujourd’hui la vision de MaaS Alliance est encore à définir. Ferdinand a une vision de MaaS 2.0.
MaaS Alliance reste souvent, naturellement, dans le MaaS 1.0: une vision où tous les MSPs/services seront éventuellement assez intégrés pour proposer des applis avec des souscriptions de mobilité, avec la promesse d’un nouveau business model disruptif.
Beaucoup de pilotes, mais sans succès commerciaux transformatifs. Il y a beaucoup d’Acteurs, liés à la voiture, aux transport publics, etc. Cela a donné lieu à des échanges sur ce qui fonctionne ou pas. Beaucoup d’entreprises ont fermé. Nous sommes sans doute à la 6éme année d’un cycle de 20 ans, profitabilité pas immédiate.
Transport = 2e poste budgétaire après le logement pour beaucoup. Les enjeux sont importants.
- MaaS Corporate : forfaits mobilité d'entreprise (ex. Mpact)
- Mobilité très subventionnée : Mobilité inclusive, MaaS Rural - Mieux que de déléguer aux gros opérateurs
Whim était la star du MaaS 1.0, prouvé leur modèle en Finlande mais sur de tout petits volumes (souvenir de 4% des volumes de transports) et pas réussi à essaimer.
Précurseurs, pas/peu changé le modèle, continuent d’insister. D’autres ont changé : ils vendent leurs produits comme un logiciel. Pas de vision MaaS avec service de mobilité, mais APIs et SDK, avec logiciel très intéressant. Ce sont des spécialistes. Vision du MaaS 2.0 comme une boîte à outils ? Ou encore des entreprises hybrides qui aident les villes a ‘hacker’ les systèmes existant pour faire de l’UX sympa. Mais efforts isolés, utile pour la transition mais pas pour la vision finale
Les villes se retrouvent face à David contre Goliath : soit des acteurs très agiles mais qui ne vont peut-être pas survivre, soit de très gros acteurs, mais souvent avec un conflit d’intérêt lié à leur business modèle existant.
Tout cela forme MaaS Alliance. Plus vraiment MaaS 1.0, pas encore MaaS 2.0
Quelle est votre vision sur le rôle de l'Alliance ?
Besoin d’une voix qui représente à la fois les utilisateurs, les acteurs techs, les opérateurs.
Bien fonctionné jusqu’ici. MaaS Alliance a fait une recommandation à la Commission sur la directive ITS avec un point de vue courageux, sur les données à inclure (dynamiques vs statiques), à rendre obligatoire, (rendre formats de données obligatoires, mais seules les très grosses entreprises peuvent s’y conformer et rester économiquement viables).
Besoin d’un forum industriel comme le GSM Alliance. Statuts clairs sur la représentativité, avec gouvernance.
–> Question de la représentativité des acteurs
–> Point de vue des développeurs - pas limités à un standard : pas vu ailleurs
Calypso aussi pourrait jouer ce rôle de forum industriel, mais point de départ = 100% utilisateurs (opérateurs et AOM). C’est une voix cohérente et représentative. Ils veulent plus (ex : ABT), mais pas encore au point de faciliter le GSM Alliance du MaaS ?
MaaS Alliance, Calypso Network Association, …, on aurait besoin d’une alliance qui se saisisse du sujet MaaS de la même façon que GSMA s’était saisie du sujet téléphonie mobile inter-réseaux.
Prise de note sur le PAD (cocher si Oui) ? Non
Document Central (CR) :
Evénement lié :
Organisations impliquées :
Contributeurs :
Tags : MaaS
Thème :
Animateur Atelier :
Défi lié à l'Atelier :
Commun(s) impliqué(s) :
Projet en cours à associer :
Communauté(s) d'intérêt impliquée(s) : Standards Ouverts pour des MaaS d'intérêt général
Personnes clés à solliciter :
Actions décidées par les participants :
Espace d'échange FORUM :
Espace d'échange CHAT :
Complément :
Prochaine Etape : == Texte du titre ==
Autres informations :
Français
English
Italiano
