Book and Go
Le covoiturage qui met en relation conducteurs vérifiés et passagers : trajet publié, place réservée et payée, échanges et rappels dans l'application.
Book and Go est une plateforme de covoiturage qui met en relation conducteurs et passagers. Un conducteur publie un trajet avec ses places disponibles, un passager le trouve par recherche et carte interactive, réserve et règle sa place, puis échange avec le conducteur dans l'application. La confiance repose sur la vérification des conducteurs : permis, pièce d'identité, carte grise et assurance sont examinés par l'équipe avant qu'un compte puisse publier. Des notifications push prévenent des confirmations, des rappels de départ et des messages, avec des liens profonds vers le bon écran. J'ai contribué aux fonctionnalités de publication et de recherche de trajets, à la réservation, aux profils et aux notifications, au sein de l'équipe AD2S.
Le backend NestJS adopte l'Architecture Hexagonale et le Domain-Driven Design, avec un principe fort : aucun import direct entre modules fonctionnels (authentification, utilisateurs, trajets, réservations, paiements, documents, notifications, conversations). Tout passe par des événements, ce qui permet à chaque module d'évoluer, voire de se déployer, séparément. Le flux de réservation en est l'illustration : le montant est calculé et un identifiant de réservation généré, puis une demande de paiement est émise. La réservation n'est créée qu'une fois l'initiation réussie, et les places ne sont réservées qu'à la confirmation du paiement, pour qu'une disponibilité reste exacte. Une annulation ne les libère que si elles avaient été réservées. L'authentification associe JWT court, jeton de rafraîchissement révocable et OTP, et les notifications basculent de la push au SMS puis à l'email. Les tâches de fond passent par Bull et Redis, et le client mobile Expo / React Native vit dans un monorepo Nx avec l'espace d'administration.
Dans le covoiturage, une place affichée comme libre alors qu'elle ne l'est plus détruit la confiance plus vite qu'un bug visuel : toute la chaîne réservation, paiement, places est donc pilotée par des événements plutôt que par des appels directs.
Défis techniques
- Des places toujours exactes : réservées seulement à la confirmation du paiement, libérées à l'annulation uniquement si elles l'avaient été.
- Une réservation jamais créée si l'initiation du paiement échoue, via un identifiant généré en amont et une communication par événements.
- Des modules sans aucun import direct entre eux, pour pouvoir les faire évoluer et les déployer séparément.
- Une vérification des conducteurs par documents puis OTP, et des notifications qui basculent de la push au SMS puis à l'email avec liens profonds vers le bon écran.
Rôle
Développeur Logiciel — AD2S