Rezo Séniors : une SPA au service de la mobilité des personnes âgées

Cet article fait partie d’une série consacrée au site public rezopouce.fr. Après avoir présenté l’architecture de l’écosystème, le socle géographique et le système d’authentification, ce volet aborde le cœur fonctionnel du site : le service Rezo Séniors.

Le besoin

Rezo Séniors s’adresse à un public spécifique : des personnes âgées qui ont besoin d’aide pour se déplacer au quotidien — un rendez-vous médical, une course, une visite. En face, des conducteurs bénévoles acceptent de les accompagner sur leur territoire. Un référent Séniors, présent sur chaque territoire, joue le rôle de facilitateur entre les deux parties et surtout de s’assurer que le passager trouve une solution à sa demande.

La relation est asymétrique : un passager exprime un besoin, et le système se charge d’identifier les conducteurs compatibles et de les notifier. Les conducteurs reçoivent les demandes qui correspondent à leur profil — communes desservies, disponibilités — et sont libres de choisir celles auxquelles ils souhaitent répondre. Leur espace sur le site public leur permet de consulter les demandes en cours et d’accepter celles qui leur conviennent. Le référent Séniors du territoire peut intervenir à tout moment pour faciliter la mise en relation, notamment quand aucun conducteur ne s’est manifesté.

Ce fonctionnement impose une interface double : côté passager, un parcours simple et guidé pour formuler une demande, cette dernière peut également être exprimée via l’espace d’administration dédié par le référent Sénior ; côté conducteur, un espace de consultation des demandes, de gestion de ses disponibilités et de réponse aux sollicitations. Le tout intégré dans le site Symfony existant, sans rechargement de page.

Une SPA dans un site Symfony

Le choix technique a été d’intégrer une Single Page Application AngularJS directement dans le site Symfony. Les pages institutionnelles du site continuent d’être rendues par Symfony et Twig, mais dès que l’utilisateur entre dans l’espace Séniors, c’est l’application AngularJS qui prend la main — avec ses propres contrôleurs, services et directives.

Cette cohabitation impose une contrainte technique concrète : AngularJS et Twig utilisent tous les deux la syntaxe Mustache ({{ }}) pour l’interpolation. La solution retenue a été de modifier les délimiteurs AngularJS en {[{ }]}, ce qui évite les conflits de parsing tout en conservant la lisibilité des templates.

L’application AngularJS est structurée en modules fonctionnels : un contrôleur principal pour la page d’accueil, un contrôleur pour les détails de trajet, un pour les notifications, des services dédiés aux appels API (trajets, notifications, dates), et un ensemble de directives pour les composants réutilisables — la liste de trajets, la timeline, les indicateurs de statut.

Le parcours passager

Créer une demande de trajet

Un passager sénior — ou son aidant — accède à l’espace Rezo Séniors après connexion. La création d’une demande de trajet se fait en trois étapes.

La première étape concerne le trajet aller : l’adresse de départ est pré-remplie depuis le profil de l’utilisateur et géocodée via Google Maps, l’utilisateur saisit sa destination, choisit une catégorie de trajet (médical, administratif, courses…), sélectionne une date et un horaire, et peut ajouter un commentaire.

La deuxième étape, optionnelle, permet de renseigner un trajet retour. L’utilisateur indique la durée estimée de son rendez-vous, ce qui permet de calculer automatiquement l’heure de retour.

La troisième étape affiche un récapitulatif complet : les informations du trajet aller et retour, une carte avec l’itinéraire, et des estimations de distance, de durée et de coût indicatif. C’est à cette étape que l’utilisateur confirme sa demande.

Après confirmation, un email est envoyé au passager et le processus de recherche de conducteur démarre côté API.

Consulter ses trajets

Le passager retrouve l’ensemble de ses trajets dans une vue timeline, organisée par périodes : les 30 derniers jours, la semaine dernière, hier, aujourd’hui, demain, la semaine prochaine, les 30 prochains jours. Cette organisation temporelle a été pensée pour un public qui raisonne en termes de repères concrets plutôt que de dates abstraites. Le passager peut également valider qu’un trajet a bien été effectué — une information qui alimente les statistiques du service.

La parcours conducteur

Répondre aux demandes

Le conducteur solidaire ne crée pas de trajets — il répond aux sollicitations. Depuis son espace, il consulte la liste des demandes en cours qui correspondent à son profil. Cette liste se rafraîchit automatiquement toutes les cinq minutes. Il peut visualiser les détails d’une demande et choisir de l’accepter, ce qui déclenche une notification au passager.

Le conducteur dispose également de son propre récapitulatif de trajets, avec la même vue timeline que le passager.

Gérer ses préférences

C’est un aspect central du service. Le conducteur configure trois paramètres qui déterminent les demandes pour lesquelles il sera sollicité :

Les communes desservies définissent son périmètre géographique. Le conducteur ajoute ou retire des communes via un widget de recherche. Ce choix est déterminant : seules les demandes dont la destination correspond à l’une de ses communes lui seront proposées.

Les disponibilités hebdomadaires forment une grille par jour de la semaine, avec deux créneaux par jour — matin et après-midi. Le conducteur indique pour chaque demi-journée s’il est disponible ou non.

Les périodes d’absence permettent de déclarer des vacances ou des indisponibilités ponctuelles. Pendant ces périodes, aucune sollicitation ne lui sera envoyée.

La mise en relation : l’algorithme côté API

C’est l’API qui orchestre la mise en relation entre passagers et conducteurs. Quand une demande de trajet arrive, l’algorithme recherche les conducteurs éligibles en croisant plusieurs critères : la commune de destination doit figurer dans les communes desservies par le conducteur, ses disponibilités doivent couvrir le jour et la demi-journée du trajet, il ne doit pas être en période d’absence, et il ne doit pas avoir été dissocié de ce trajet précédemment.

L’algorithme intègre une notion de délai qui influence la stratégie de notification. Si le trajet est prévu à plus de 48 heures, le système privilégie d’abord les conducteurs préférés du passager — des conducteurs avec lesquels une relation de confiance s’est établie au fil des trajets. Si aucun conducteur préféré n’est disponible, ou si le délai est plus court, les conducteurs solidaires éligibles sont sollicités directement.

Cette approche est volontairement simple. Pas de score de pertinence complexe, pas d’algorithme de recommandation. La correspondance sur la commune et la période suffit à couvrir les cas d’usage réels d’un réseau de bénévoles locaux. Cette simplicité est un choix assumé : elle rend le système prévisible pour les utilisateurs et maintenable pour le développeur.

Si aucun conducteur n’accepte la demande, une tâche planifiée réévalue périodiquement les trajets sans conducteur et relance les notifications à mesure que le délai évolue. Les gestionnaires de territoire peuvent également déclencher une relance manuelle depuis le back-office.

Les notifications

Le système de notifications est le liant entre les deux parcours. Chaque étape du processus — demande créée, conducteur trouvé, trajet accepté, trajet validé — génère des notifications par email et, quand le territoire l’a activé, par SMS.

L’utilisateur contrôle finement ses préférences de notification depuis une page dédiée : recevoir les notifications par email, par SMS, ou les deux. Accepter d’être contacté par Rezo Pouce ou par le référent territorial, par téléphone ou par courriel. Un avertissement s’affiche si aucun canal de notification n’est activé — sans notification, le service ne peut tout simplement pas fonctionner.

Le centre de notifications dans l’interface sépare les notifications par onglets — conducteur et passager — avec un historique de 30 jours et un badge de compteur sur chaque onglet.

Qui peut accéder au service

Rezo Séniors n’est pas un service ouvert à tous. Il est financé territoire par territoire, et il est logique que seuls les habitants des communes couvertes puissent en bénéficier. L’éligibilité repose sur plusieurs critères vérifiés dès l’inscription et à chaque connexion.

D’abord, le territoire de résidence de l’utilisateur doit avoir activé le service Séniors — tous les territoires Rezo Pouce ne le proposent pas. Ensuite, la commune de l’utilisateur doit elle-même être couverte par le dispositif, car toutes les communes d’un même territoire ne sont pas nécessairement incluses. Un seuil d’âge, configurable par territoire, détermine à partir de quel âge le service devient accessible en tant que passager. Enfin, l’utilisateur doit posséder un profil Séniors valide, et le système vérifie à chaque accès qu’il a le bon rôle — conducteur ou passager — selon la page consultée.

Ces vérifications en cascade reflètent la réalité du modèle économique et géographique du service : chaque territoire décide de ses propres paramètres, et le système s’y adapte.

Concevoir pour un public sénior

Développer pour un public sénior impose des contraintes qui vont au-delà de la technique. Les formulaires doivent être courts et guidés. Les messages d’erreur doivent être explicites. Les parcours doivent comporter des confirmations à chaque étape — pas de validation silencieuse. La typographie doit être lisible, la navigation simple, et les fonctionnalités secondaires ne doivent pas encombrer l’écran.

Ces contraintes ont influencé la conception de l’interface : moins de fonctionnalités visibles à l’écran, des parcours en étapes avec récapitulatif, des modales de confirmation explicites. Ce n’est pas de la simplification par appauvrissement — c’est une adaptation au public réel du service, dont une partie ne serait pas en mesure d’utiliser une interface pensée pour un utilisateur habitué au web.

Ce que ce projet illustre

L’intégration d’une SPA AngularJS dans un site Symfony est un cas de figure courant en contexte professionnel, notamment lors d’ajouts de fonctionnalités riches dans un site existant. Ce projet montre que cette cohabitation est possible et maintenable, à condition d’accepter quelques compromis techniques comme la modification des délimiteurs d’interpolation.

Au-delà de l’aspect technique, ce projet illustre ce qui se passe quand on construit un outil pour un public identifié et un besoin précis. L’algorithme de mise en relation est simple parce que le réseau de bénévoles est local. Les notifications sont omniprésentes parce que c’est le seul moyen de faire fonctionner un système asynchrone entre des personnes qui ne se connaissent pas. Les parcours sont guidés parce que les utilisateurs ne sont pas des développeurs. Chaque décision technique est la traduction d’une contrainte métier concrète.