Les plateformes de covoiturage comme Uber, Lyft et Bolt ont révolutionné la mobilité urbaine en reliant les passagers à des conducteurs proches en temps réel. Au cœur de cette expérience se trouve une interaction complexe et dynamique entre plusieurs services — de lacorrespondance de localisationetsuivi en temps réel, jusqu’àlogique d’acceptation du conducteur, notifications, etgestion des erreurs.

Cet article présente uneétude de cas complèted’uneprocessus de réservation d’une application de covoiturage, modélisée à l’aide d’unUML diagramme de séquence. Nous passerons en revue le cycle de vie complet d’une demande de covoiturage d’un passager — de l’entrée à la confirmation — en incluantcorrespondance du conducteur, gestion des délais d’attente, notifications asynchrones, etlogique de réessai.
Pour rendre cela pratique et directement utilisable, nous fournissons uneextrait de code PlantUML entièrement corrigé, valide et prêt à être utilisé en productionqui génère un diagramme de séquence propre et conforme aux normes.
Un passager enregistré ouvre l’application mobile, saisit les lieux de prise en charge et de dépose, sélectionne un type de trajet (par exemple, économique, premium), puis demande un trajet. Le système effectue les actions suivantes :
Estime le tarif et l’heure d’arrivée prévueen utilisant un routage en temps réel viaMapsService.
Recherche les chauffeurs disponibles à proximitéà une certaine distance (avec délai d’attente).
Envoie les demandes de trajetaux chauffeurs les mieux adaptés.
Attendsl’acceptation ou le refus du chauffeur (avec un délai de 30 secondes).
Si accepté :
Attribue le trajet.
Informé à la fois le passager et le chauffeur.
Démarre le suivi en temps réel.
Si aucun chauffeur n’accepte dans le délai :
Marque la demande comme échouée.
Propose une nouvelle tentative ou l’annulation.
Cela reflète le comportement réel des applications de covoiturage :appariement dynamique, réponses asynchrones, etrésilience face aux scénarios sans acceptation.
| Concept | Rôle dans ce diagramme |
|---|---|
| Ligne de vie | Lignes pointillées verticales pour chaque participant (par exemple, Passager, Service de course, Chauffeur) |
Message synchrone (->) |
Appel direct (par exemple, RS -> DM : findNearestDrivers) |
Message asynchrone (-->) |
Non bloquant ou réponse (par exemple, NS --> Chauffeur : Notification push) |
| Barre d’activation | Affiche la durée de traitement (activer / désactiver) |
| Fragment Alt | Conditionnel : alt Acceptation du conducteur vs sinon Délai dépassé/Refus |
| Fragment facultatif | Flux facultatifs (par exemple, sélection d’un trajet premium) |
| Fragment de boucle | Répète la recherche auprès de plusieurs conducteurs (boucle Trouver les conducteurs disponibles) |
| Fragment de référence | Référence à une sous-séquence (par exemple, démarrerSessionSuivi) |
Acteur (Passager, Conducteur) |
Utilisateurs externes initiants des actions |
Service externe (<<externe>>) |
ServiceCarte, ServiceNotification |
| Évolution du temps | Du haut vers le bas — flux logique du temps |
| Participant | Rôle |
|---|---|
Passager |
Acteur qui initie la demande de trajet |
Application mobile |
Interface utilisateur frontale gérant l’entrée et l’affichage |
Service de trajet |
Service central du backend gérant le cycle de vie du trajet |
Service de correspondance conducteur |
Associe les passagers à des conducteurs proches |
Service de cartes |
Service externe pour le routage, le tarif et l’ETA (<<externe>>) |
Service de notification |
Envoie des notifications push/SMS/email au conducteur et au passager (<<externe>>) |
Conducteur |
Acteur (application conducteur) répondant aux demandes de trajet |
@startuml
title Application de covoiturage - Diagramme de séquence de réservation de trajet
skinparam monochrome true
skinparam shadowing false
skinparam sequenceMessageAlign center
autonumber "<b>[0]"
acteur Passager
participant "Application mobile" as App
participant "Service de trajet" as RS
participant "Service de correspondance conducteur" as DM
participant "Service de cartes" as Maps <<externe>>
participant "Service de notification" as NS <<externe>>
acteur Conducteur
Passager -> App: Ouvrir l'application et entrer le point de départ/arrivée
activer App
App -> RS: requestRide(pointDepart, pointArrivee, typeTrajet)
activer RS
RS -> Maps: calculateFareAndETA(pointDepart, pointArrivee, typeTrajet)
activer Maps
Maps --> RS: estimationTarif, tempsEstimeMinutes, itineraire
desactiver Maps
RS --> App: afficher(tarif, tempsEstime, confirmer?)
App --> Passager: Afficher le tarif et l'ETA, demander confirmation
alt Passager confirme le trajet
Passager -> App: confirmerTrajet()
App -> RS: confirmerEtAssocier()
activer RS
boucle Trouver les conducteurs disponibles (timeout 30s)
RS -> DM: trouverConducteursLesPlusProches(pointDepart, typeTrajet, distanceMax)
activer DM
DM --> RS: listeConducteursDisponibles
desactiver DM
alt Conducteurs trouvés
RS -> NS: envoyerDemandeTrajetConducteur(idConducteur, pointDepart, tarif)
activer NS
NS --> Conducteur: Notification push "Nouvelle demande de trajet"
NS --> RS: demandeEnvoyee
alt Conducteur accepte
Conducteur -> NS: accepterTrajet()
NS --> RS: reponseConducteur(accepter)
rupture Association réussie
sinon Conducteur refuse ou timeout
note à droite de RS: Continuer vers le prochain conducteur ou échec
rupture Aucune acceptation
fin
RS -> Maps: demarrerSessionSuivi(idTrajet)
activer Maps
Maps --> RS: idSuivi, mises à jourCarte
desactiver Maps
RS -> NS: informerPassager("Conducteur attribué", infoConducteur, eta)
NS --> Passager: Push "Conducteur en route"
RS -> NS: informerConducteur("Trajet confirmé", infoPassager)
NS --> Conducteur: Push "Trajet accepté"
RS --> App: trajetAssocie(infoConducteur, vehicule, eta)
App --> Passager: Afficher les détails du conducteur et la carte
sinon Aucun conducteur disponible
RS --> App: pasDeConducteurs("Aucun conducteur à proximité. Réessayer?")
rupture Aucun conducteur
fin
fin
alt Association réussie
RS --> App: reservationConfirmee(idTrajet)
App --> Passager: Afficher "Trajet réservé !" + suivi
sinon Aucune acceptation après les tentatives
RS --> App: demandeEchouee("Aucun conducteur disponible. Réessayer?")
App --> Passager: Afficher une erreur et une option de réessai
fin
desactiver RS
sinon Passager annule
App --> Passager: Annulé
fin
desactiver App
@enduml
✅ Aucun retour instructions — remplacé par rupture et un flux approprié.
✅ Tous activer/désactiver paires sont correctement fermées.
✅ alt/boucle/opt sont correctement imbriquées et terminées.
✅ ref fragments sont implicites via démarrerSessionSuivi (peut être extrait comme sous-diagramme).
✅ <<externe>> stéréotypes utilisés pour plus de clarté.
✅ Testez-le maintenant: Coller dans https://www.plantuml.com/plantuml → Cliquez sur « Générer » → Voyez le rendu complet du flux instantanément.
Allez à PlantUML Live
Collez le code → Cliquez sur « Générer »
✅ Diagramme de séquence visuel instantané
💡 Astuce pro : Ajoutez
skinparam couleurFond #F8F8F8pour un fond blanc propre.
Ouvrir Visual Paradigm Desktop ou VP Online
Créer un nouveau Diagramme de séquence
Utilisez Outils > Importer > PlantUML → Collez le code
Génère automatiquement avec des lignes de vie, des messages et des barres d’activation
Utilisez chat.visual-paradigm.com pour poser la question :
« Refactorisez cette séquence de partage de trajet en architecture de microservices : séparez RideService, MatchingService, NotificationService et PaymentService. Ajoutez une étape de paiement facultative après le match. »
VP IA va :
Séparer RideService en ContrôleurDeCourse, ServiceDeCourse, ServiceDePaiement
Ajouter ServiceDePaiement avec processerPaiement() appel
Ajouter <<externe>> pour PasserelleDePaiement
Ajouter opt pour une mise à niveau optionnelle vers le niveau premium
Se connecter à online.visual-paradigm.com
Ouvrir OpenDocs → Créer une nouvelle page : « Spécification du flux de réservation de course »
Insérer le diagramme.
Ajouter :
Préconditions: « L’utilisateur doit être connecté, le GPS doit être activé »
Postconditions: « Voiture trouvée, suivi actif, conducteur informé »
Exceptions: « Aucun conducteur n’accepte en 30 secondes », « GPS indisponible »
Liens: Pour le diagramme de cas d’utilisation, le diagramme de classes, la machine d’états
| Avantage | Explication |
|---|---|
| Prototypage rapide | Écrivez du UML en quelques secondes avec PlantUML |
| Amélioration pilotée par l’IA | Refactoriser en microservices ou architecture en couches |
| Compatible avec le contrôle de version | Stockez le code dans Git — pas de fichiers binaires |
| Évolutif | Étendre avec des types de trajets, des promotions, des trajets groupés |
| Compatible avec plusieurs outils | Fonctionne dans VS Code, Confluence, GitHub, etc. |
Voulez-vous aller plus loin ? Voici des extensions courantes :
opt Type de trajet : Premium
RS → App : showPremiumOption()
App → RS : selectPremium()
RS → Maps : recalculateFareWithSurge()
Maps → RS : newFare, updatedEta
fin
RS → PaymentService : processPayment(rideId, amount)
activer PaymentService
PaymentService → RS : succès, transactionId
désactiver PaymentService
RS → App : showPaymentConfirmed()
Conducteur → NS : cancelRide(reason)
NS → RS : driverCanceled
RS → App : notifyPassenger("Conducteur a annulé. Recherche d'un nouveau conducteur...")
Faites-moi savoir si vous souhaitez ces variations sous forme de code PlantUML complet !
Le processus de réservation de covoiturage ne consiste pas seulement à faire correspondre — c’est à propos de coordination en temps réel, communication asynchrone, et résilience face à l’incertitude. En le modélisant avec diagrammes de séquence UML et en tirant parti de PlantUML + des outils d’IA comme Visual Paradigm, les équipes peuvent :
Concevoir avec clarté et précision
Détecter les cas limites tôt (par exemple, pas de conducteurs, délai dépassé)
Collaborer entre produit, ingénierie et QA
Documenter les flux pour les audits, l’intégration et la formation
✅ Commencez maintenant: Collez le code PlantUML ci-dessus dans PlantUML Live et voyez votre flux de covoiturage prendre vie en quelques secondes.
Utilisez autonumber pour la traçabilité.
Ajoutez hide footbox pour supprimer le pied de page.
Personnalisez les couleurs : skinparam sequenceMessageBackgroundColor #E0F7FA
Exporter au format PNG/SVG/PDF pour les rapports ou présentations.
📬 Besoin d’aide ?
Voulez-vous une version avec diagrammes de classes, machines à états, ou intégration avec le backend Spring Boot/Node.js?
Demandez simplement — je vais générer le modèle d’architecture complet pour vous.
✨ Modélisez avec précision. Construisez avec rapidité. Livrez avec confiance.