Alertes SMS, appli, écrans : prévenir vos voyageurs en cas de retard ou déviation sans y passer la journée

Un incident survient sur une ligne. Il faut prévenir les voyageurs qui attendent à l'arrêt, ceux qui suivent l'application, et mettre à jour les écrans en gare. Dans beaucoup de réseaux, cela veut dire rédiger le même message trois fois, dans trois interfaces différentes, avec le risque qu'une version diffère d'une autre ou qu'un canal soit tout simplement oublié pendant que le régulateur gère l'incident lui-même. Cet article s'adresse aux responsables information voyageurs qui veulent sortir de cette ressaisie multiple, pas à ceux qui découvrent le sujet de la perturbation pour la première fois.

Nous avons déjà traité l'importance de l'information voyageur dans la gestion des perturbations d'un point de vue général, et la manière dont le GTFS-RT permet de détecter et gérer les déviations de bus d'un point de vue technique. Ici, l'angle est strictement opérationnel : comment faire en sorte qu'une seule saisie suffise à informer tous les canaux, simultanément, sans y passer la journée.

Le vrai coût n'est pas la perturbation, c'est sa diffusion

Une déviation ou un retard n'est pas en soi un problème de communication complexe. Ce qui consomme du temps, c'est la répétition : composer un SMS, reformuler le même message pour l'application, le ressaisir une troisième fois pour les écrans d'affichage, parfois une quatrième pour le site web. Chaque ressaisie est une occasion d'erreur, de délai, et d'incohérence entre canaux, ce qui finit par coûter plus cher en confiance voyageur que la perturbation elle-même.

Le symptôme le plus fréquent sur le terrain n'est pas l'absence d'outils, la plupart des réseaux disposent déjà d'un système de SMS, d'une application et d'écrans. Le symptôme, c'est que ces outils ne communiquent pas entre eux, et que chacun exige sa propre saisie.

Un seul point de saisie, trois canaux diffusés en simultané

Le principe qui change la donne est simple à énoncer et exigeant à mettre en œuvre : le régulateur saisit un incident une seule fois, sur une seule interface, et la diffusion vers SMS, application et écrans se fait automatiquement et simultanément.

Concrètement, cela suppose que la création d'une déviation ou d'une alerte retard sur la carte d'exploitation déclenche, sans ressaisie, la mise à jour des horaires recalculés dans l'application voyageurs, l'envoi des notifications push et SMS aux abonnés concernés, et l'actualisation des écrans en arrêt et en gare. Sur le module Déviations avancées de Pysae, cette diffusion complète s'effectue en moins de 30 secondes, avec une visibilité GPS maintenue à 100% pendant toute la durée de l'incident et les trois acteurs, régulateur, conducteur et voyageur, synchronisés au même instant.

Ce n'est pas une automatisation aveugle. L'opérateur garde le contrôle total sur la publication : l'alerte est d'abord remontée en interne avant d'être diffusée aux voyageurs, ce qui laisse la main au régulateur pour valider, corriger ou retarder une communication si la situation évolue vite.

Ce que chaque canal doit recevoir, et pourquoi ils ne se valent pas

Les trois canaux ne servent pas le même usage, et les traiter de façon strictement identique produit une information mal calibrée.

SMS

C'est le canal du push pur, sans action requise du voyageur. Il doit rester court et actionnable : nature de la perturbation, ligne concernée, alternative si elle existe. C'est aussi le canal le plus sensible à la latence : un SMS reçu après le passage du bus n'a plus aucune valeur, ce qui impose que la diffusion soit quasi instantanée dès la validation du régulateur.

Application voyageurs

C'est le canal le plus riche : horaires recalculés, tracé dévié visible sur la carte, notification push reçue même application fermée. C'est aussi celui qui permet le suivi dans la durée d'une perturbation, avec une mise à jour continue tant que l'incident n'est pas clos, ce qui en fait le canal de référence pour un voyageur qui suit activement son trajet.

Écrans d'affichage

En arrêt ou en gare, l'écran touche un public qui n'a pas forcément l'application ni activé les notifications, ce qui en fait un filet de sécurité pour l'information de dernière minute. Il doit rester lisible en quelques secondes : prochain départ, direction, alerte trafic, sans surcharge de texte.

Le référentiel unique, condition silencieuse de la simultanéité

Rien de tout cela ne fonctionne sans un point commun : les trois canaux doivent puiser dans la même base d'arrêts, de lignes et d'horaires. Si l'application utilise un référentiel et les écrans un autre, la diffusion simultanée produit des informations différentes selon le canal, ce qui est pire pour la confiance voyageur qu'une absence de diffusion sur l'un des trois.

C'est un chantier de fond plus qu'un réglage technique, et c'est généralement lui qui détermine si un projet multicanal tient ses promesses ou retombe, au bout de quelques mois, dans la ressaisie manuelle sur au moins un des canaux.

Ce que cela change pour l'équipe information voyageurs

Le bénéfice ne se mesure pas seulement en minutes gagnées par incident, même si c'est la première chose qui se voit. Il se mesure surtout dans la capacité à traiter plusieurs incidents simultanés sans que l'équipe se retrouve à choisir quel canal sacrifier faute de temps, ce qui est la situation la plus fréquente lors d'un épisode de perturbations multiples, intempéries, grève partielle, incident de voirie.

Une équipe qui ne ressaisit plus la même information trois fois peut consacrer ce temps à autre chose : vérifier la cohérence du message, anticiper la perturbation suivante, ou simplement s'assurer que l'alerte a bien été reçue plutôt que de la rédiger une troisième fois.

Ce qu'il faut vérifier avant de généraliser

Avant d'étendre la diffusion automatique multicanal à l'ensemble du réseau, trois points méritent d'être vérifiés sur un périmètre pilote. La cohérence du référentiel entre les canaux, déjà évoquée, doit être validée en conditions réelles et pas seulement en recette. Le circuit de validation interne doit être clair, qui a la main pour publier, qui peut corriger un message déjà diffusé, et dans quel délai. Enfin, la mesure du délai réel entre la détection d'un incident et sa diffusion sur les trois canaux doit être suivie dans la durée, c'est l'indicateur le plus parlant pour démontrer, en interne, que la diffusion simultanée tient sa promesse.

Une fois ces trois points stabilisés, la généralisation à l'ensemble du réseau ne consiste plus qu'à étendre un fonctionnement déjà éprouvé, plutôt qu'à réinventer un processus canal par canal.