Le problème
Un service de taxi qui prend ses réservations via une application a besoin de bien plus qu’un formulaire de réservation. Il doit trouver un chauffeur libre à proximité, lui proposer la course, attendre sa réponse et passer au suivant si personne n’accepte, le tout en quelques secondes. Rome ajoute ses propres règles : des tarifs fixes approuvés par la ville pour les trajets vers et depuis les aéroports et le port. Le client avait besoin de toute la chaîne, du dispatch jusqu’au paiement.
Ce que j’ai construit
J’ai développé une plateforme de réservation et de dispatch en temps réel, avec un back end unique, trois applications mobiles et un tableau de bord web d’administration.
- Moteur de dispatch — il recherche les chauffeurs validés et disponibles qui ont envoyé leur position dans les 60 dernières secondes, dans un rayon de recherche (8 km par défaut). Il en classe jusqu’à 10 selon le temps de trajet réel dans le trafic du moment, calculé par Google, puis propose la course à un chauffeur à la fois, avec 20 secondes pour accepter.
- Tarifs de Rome — le service de tarification reconnaît 9 lieux clés, comme l’aéroport de Fiumicino et le centre historique. Il applique les 12 tarifs fixes établis par Roma Capitale (délibération 252/2024). Les autres trajets sont tarifés à partir de l’itinéraire Google, avec des suppléments pour les bagages et les passagers.
- Trois applications — une application passager, une application chauffeur et une application pour la tablette embarquée, qui affiche l’itinéraire et les bannières des partenaires. Toutes sont développées avec React Native et Expo, pour Android et le web.
- Suivi et appels en direct — Socket.IO transmet la position des chauffeurs et l’état de la course. Passager et chauffeur peuvent s’appeler dans l’application via WebRTC, sans voir le numéro de téléphone de l’autre.
- Paiements — Stripe avec des webhooks à signature vérifiée, et commandes PayPal. Les clés de paiement se configurent dans le panneau d’administration et sont stockées chiffrées.
- Intégration des chauffeurs — les chauffeurs téléversent leur permis, leurs documents et leur photo. Un administrateur les valide avant qu’ils puissent se mettre en service.
- Sponsors et coupons — un portail sponsors avec trois formules et des coupons avec suivi antifraude, ainsi que des courses programmées et des avis.
Comment c’est construit
Le back end tourne sur Node.js 22 avec TypeScript, Express et Socket.IO. Les données sont dans MariaDB/MySQL, et le schéma a évolué au fil de 24 migrations SQL versionnées. Zod valide les entrées ; la connexion utilise JWT et la connexion avec Google. Google Maps gère les itinéraires, les temps de trajet et le géocodage. Les applications utilisent Expo et React Native.
Pourquoi ce choix
Deux passagers ne doivent jamais se voir attribuer le même chauffeur. Quand un chauffeur accepte, le moteur le réserve avec une seule mise à jour conditionnelle : occupé, mais seulement s’il est encore disponible. Si aucune ligne ne change, c’est que le chauffeur vient d’être pris, et la course passe au candidat suivant. Les candidats sont classés selon le temps de trajet et non selon la distance à vol d’oiseau, car à Rome la voiture la plus proche n’est souvent pas la plus rapide. Si Google ne répond pas, le classement se rabat sur la distance.
