Phase 2

De TIc-siT_wiki
Sauter à la navigation Sauter à la recherche

Note de synthèse sur la phase 2[modifier | modifier le wikicode]

La phase 2 a suivi une démarche guidée par le parcours client.

On imagine que le péage urbain a été mis en place dans une agglomération et l'on décrit les situations auxquelles va être confronté un automobiliste qui pénètre dans la zone sous péage.

Tout d'abord, on se focalise sur un péage de zone ou de cordon, considérant qu'un péage d'axe ressemble beaucoup à un système free flow tel que nous les avons déployés à Dublin ou à Vancouver et considérant également que la péage d'axe n'est pas celui qui aura la faveur des autorités car il nous semble le moins adapté aux objectifs liés à la pollution et la congestion ( report spatial).

Ensuite on définit les grandes étapes du cycle de vie du client dans l'agglomération vue comme un système.

Le client apparait dans le système, en ouvrant un compte auprès d'un opérateur pour déterminer ses droits à utiliser la zone à péage, les conditions tarifaires et les conditions de règlement. C'est la phase que nous appelons avant le voyage (sachant que nous n'incluons pas la phase la prospection qui précède et consiste à faire connaitre le service et inciter le client à souscrire)

Vient ensuite la phase "pendant le voyage", le client circule dans la zone à péage, s'acquitte ( ou pas ) du montant du péage, selon le type de compte prépayé ou postpayé il rechargera sa balance ou paie ses factures.

Dans cette phase nous devons introduire le client qui pénètre dans la zone à péage, mais n'a fait au préalable aucune démarche indiquant son intention. Nous appelons ces clients les occasionnels ou non-abonnés.

Cette phase comprend également les activités de contrôle, le contrôle est réalisé par des acteurs qui ne sont pas le client mais qui le concerne, surtout quand le contrôle est négatif et conduit à une sanction.

Dans la phase "Après le voyage" on classe généralement toutes les activités dites de SAV (badge perdu/volé/défectueux), les réclamations et la gestion des impayés.

On voit en décrivant ce parcours que les interactions entre le client et le système vont comporter un volet lié à la gestion de son ou ses comptes pour suivre son cycle de vie et un volet consommation du service. On peut dire en première approximation que les particularités du péage urbain ne sont pas d'abord dans la gestion du compte mais dans la processus de livraison/consommation du service.

La gestion du compte va comprendre la saisie d'une fiche client, de véhicules après éventuellement vérification des pièces justificatives, enregistrement des opérations sur ce compte comme dans une gestion clientèle assez classique.

La livraison/consommation du service, est elle par contre assez spécifique. Comment va-t-on mesurer la consommation du service, quels gestes, s'il y en a, devra faire le consommateur lorsqu'il entrera ou sortira de la zone à péage.

La description du parcours client est guidée par les questions suivantes :

Quels objets dans le véhicule servent à manifester la consommation de péage ?
Quels éléments de l'infrastructure servent à gérer les événements d'entrée et de sortie de la zone ?
Quels gestes le client doit-il faire dans tous les cas de couples OBU x RSE ?

Les objets dans le véhicule sont désignés sous le terme d'OBU (On Board Unit), à Singapour on utilise le terme de In vehicle Unit et dans d'autres sphères le terme plus général de PO (Portable Object) notamment lorsque l'objet est le téléphone mobile. Les éléments de l’infrastructure avec lesquels les OBUs interagissent sont désignés RSE (Road Side Equipements), ils comprennent des caméras, des antennes de lecture des OBUs dans une très large gamme de technologies ( RFID, DSRC, blue tooth, NFC, ...) et parfois des lasers pour la détection et la classification.

Cette description donne une grande combinatoire qui constitue la liste de tous les système possibles qu'une agglomération pourra mettre en place.

Ceci constitue le résultat de la phase 2 et le point d'entrée dans la phase 3 qui consistera à confronter cette liste de tous les systèmes possibles avec la liste de ceux que CS-ITS veut/peut proposer au marché

Principaux enseignements de la phase 2[modifier | modifier le wikicode]

Les résultats de la phase 2 ont été présentés à l'aide d'un PowerPoint lors d'une réunion de restitution dont les principales conclusions sont les suivantes :

L'éco système du Péage Urbain[modifier | modifier le wikicode]

Ce sont les Autorités Organisatrices de Transports qui auront la compétence pour déployer le PU.

Le PU sera envisagé par les décideurs comme une composante de l'offre de services de mobilités.

Nous pensons que si une agglomération décide de mettre en place le PU, lorsque viendra le temps de choisir l'organisation et le type de système qui répondra aux objectifs qui seront retenus, les autorités se tourneront vers leurs interlocuteurs habituels sur les sujets transports et déplacements.

Les sociétés d'exploitation d'autoroutes et leur fournisseurs historiques sont des acteurs ni très connus ni très reconnus dans l'éco système de la mobilité urbaine.

Du fait de cette attribution de compétence aux AOT, la mise en place du PU entre dans la démarche de réalisation du PDU, ce qui rend la perspective relativement lointaine et donne du temps pour se faire identifier auprès des acteurs clés de l'écosystème.

Le péage d'axe[modifier | modifier le wikicode]

Un péage dit d'axe, qui consiste à faire payer l'entrée dans l'agglomération peut répondre à un objectif financier.

CS-ITS a une offre et des références qui en font un (peut-être le seul si l'on exclue Ecomouv qui n'a pas encore déployé son système) acteur français de référence.

Mais ce type de solution, en première approche et sans pouvoir anticiper beaucoup sur les cas concrets qui nous serons soumis est plutôt adapté à l'objectif financier qu'aux objectifs liés à la pollution et la congestion. Il peut en effet provoquer une report spatial indésirable et poser des problèmes d'acceptabilité en ce qu'il peut apparaitre comme un service réservé aux plus aisés.

Cela dit, la solution type Dublin ou Vancouver peut servir de base pour la communication de CS-ITS sur sa connaissance du domaine,et peut servir d’accroche pour obtenir des rendez-vous auprès des maitres d'ouvrage.

Collecte versus contrôle[modifier | modifier le wikicode]

Le paragraphe suivant se rapporte au péage de zone et de cordon. Un système de collecte doit être exhaustif alors qu'un système de contrôle n'a pas à l'être ou du moins subit des contraintes moins fortes.

L'objectif d'exhaustivité se traduit par une exigence forte au niveau du RSE, donc un investissement lourd.

Dans le même temps on observe un développement de la dématérialisation des processus de contrôle ( CSA, EVR, Le procès verbal électronique, ...) et de la polyvalence des outils de contrôle.

Ces deux facteurs nous font penser qu'il est probable que les décideurs privilégieront des stratégies basées sur le contrôle plutôt que sur la collecte et qu'il faut imaginer un type de péage urbain où la zone à page ne sera pas ceinturée par des équipements type portique et où le contrôle sera fait par la police dans le cadre d'un général.

Ce contexte ne correspond pas aux bases de CS-ITS et nécessiterait un déplacement de positionnement pour rester un acteur du domaine.

Un système "client centric"[modifier | modifier le wikicode]

La description guidée par le parcours client que nous avons faite s'est focalisée sur les processus liés à la collecte et au contrôle-sanction. Malgré tout, parce que l’acceptabilité est un enjeu majeur de ce type de systèmes et parce que les nouvelles technologies permettent des approches très fines et de plus en plus proches de besoins le caractère "client centric" du système dans son ensemble reste un point clé d'une offre de péage urbain.

C'est pourquoi les aspects liés à la gestion de la relation client à travers les nouveaux canaux de communication seront un élément différencient de l'offre.

Et l'on pourrait conclure, que contrairement à l'intuition de départ le point fort de CS-ITS n'est dans le portique mais dans son back office qui intègre nativement les canaux de relation client tels que l'Internet, les applications sur mobiles, le SMS, ...


Retour