Youmoov Flex
Cinq rôles, plusieurs entreprises cloisonnées sur une même base, un tarif encadré par arrêté préfectoral, et de l'argent qui circule entre elles.
Mon rôle
Plateforme écrite seul de bout en bout : schéma de base, authentification, cinq espaces applicatifs, cloisonnement multi-tenant, moteur tarifaire réglementaire, planification des aller-retour, dispatch, portefeuille et retraits, cartographie temps réel, audit de sécurité et déploiement. Aucune ligne ne vient de quelqu'un d'autre.
La demande
Le client voulait un SaaS pour gérer la réservation des courses de ses bénéficiaires. Pas un outil interne : une plateforme où plusieurs entreprises coexistent sans jamais se voir, chacune avec ses bénéficiaires, ses chauffeurs et son budget. Trois exigences en découlaient dès le départ — un cloisonnement strict entre entreprises, un tarif conforme à l'arrêté préfectoral plutôt que fixé librement, et un circuit financier interne pour reverser aux chauffeurs ce qui leur revient.
Ce que j'ai livré
- Cinq espaces distincts — bénéficiaire, chauffeur, entreprise, sous-responsable, administrateur — avec leurs permissions propres.
- Isolation multi-tenant par identifiant de société porté sur l'utilisateur, appliquée sans exception à toute requête non-administrateur.
- Grille tarifaire réglementaire paramétrable : prise en charge, course minimum et quatre tarifs kilométriques selon jour ou nuit et retour en charge ou à vide, avec calcul des jours fériés — Pâques comprise — et marge de service ajustable par l'administrateur.
- Réservation en aller-retour ou en aller simple, le retour créé automatiquement deux heures après l'aller, chaque trajet portant son propre tarif si le second bascule en horaire majoré.
- Planning des chauffeurs par fenêtre d'immobilisation, avec limite quotidienne d'aller-retour et garde-fou unique partagé par l'acceptation volontaire et l'assignation imposée.
- Préavis de réservation de deux jours ouvrés, week-ends et jours fériés fermés, contrôlés côté serveur et pas seulement dans le sélecteur de dates.
- Dispatch automatique : à la validation d'une demande, tous les chauffeurs éligibles sont notifiés ; le premier qui accepte remporte la course.
- Demande d'inscription séparée du compte : tant que l'entreprise n'a pas validé, aucun utilisateur n'existe en base et rien ne peut se connecter.
- Portefeuille interne par utilisateur et registre de retraits séparé pour la traçabilité des versements aux chauffeurs.
- Suivi cartographique du trajet en cours et position du chauffeur remontée en continu.
- Alerte au-delà de vingt-quatre heures sans chauffeur, déclenchée par une tâche planifiée, avec assignation manuelle de secours.
Les points durs
Deux chauffeurs, une seule course
Le dispatch au premier arrivé est une course critique classique. Je l'ai résolue par une mise à jour conditionnelle atomique : je ne modifie la course que si elle est encore en attente et sans chauffeur. Si le nombre de lignes affectées est nul, c'est qu'un autre a gagné. Pas de verrou applicatif, pas de double attribution.
Un tarif qu'on ne choisit pas
Le prix n'est pas une décision commerciale, c'est un arrêté : prise en charge, course minimum, et quatre tarifs kilométriques selon l'heure, le jour et la nature du retour. J'ai sorti la grille du code pour la rendre modifiable quand l'arrêté change, gardé des valeurs de repli, et calculé les jours fériés mobiles plutôt que de les tenir dans une liste qui se périme chaque année. La marge de la plateforme s'ajoute par-dessus, séparée du tarif réglementaire jusque dans le schéma de base.
Une course qui immobilise une journée
Un aller-retour n'occupe pas le chauffeur deux fois vingt minutes : il le bloque de l'heure qui précède l'aller aux trois heures qui suivent le retour, parce qu'un rendez-vous déborde. J'ai persisté cette fenêtre sur la course et indexé la table dessus, ce qui ramène la détection de conflit à une seule requête — la même pour le chauffeur qui accepte et pour l'entreprise qui impose, afin qu'aucun des deux chemins ne contourne la règle.
Durcissement de mes propres mutations serveur
En auditant mon code, j'ai trouvé trois failles critiques que j'avais laissées passer : un prix transmis par le navigateur et accepté tel quel, un changement de statut sans vérifier que la course appartenait bien à l'appelant, et une création de rôle sans liste blanche. Je les ai corrigées, puis converties en cinq règles que j'applique désormais par défaut à toute mutation sensible plutôt que de les redécouvrir projet après projet.
Aperçus
