rapport d’analyse pour la conception d’un

site de reservation de vehicule

R EALISÉ PAR :

SINGHE PENKA Hendrix Donavan

2025-03-01
 Contents

Contents
List of Figures I

1 INTRODUCTION II
1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
1.2 Problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

2 ANALYSE III
2.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
2.2 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
2.2.1 Diagramme des cas d’utilisation de l’utilisateur . . . . . . . . . . . . . . . . IV
2.2.2 Diagramme des cas d’utilisation de l’administrateur . . . . . . . . . . . . . . V
2.2.3 Description des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . V

3 CONCEPTION IX
3.1 Technologies Utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

4 DEVIS X

5 Coût Total du Projet X

i
 List of Figures

List of Figures
1 diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
2 Diagramme des cas d’utilisation utilisateur . . . . . . . . . . . . . . . . . . . . . . IV
3 Diagramme des cas d’utilisation de l’administrateur . . . . . . . . . . . . . . . . . . V

Page I of X
1 INTRODUCTION
Ce document présente l’analyse et la conception d’un système de réservation de voitures destiné
au Cameroun. Le système inclut des fonctionnalités telles que l’inscription, la recherche de véhicules
disponibles, la réservation avec paiement différé depuis le tableau de bord, la gestion des confirmations
par l’administrateur, ainsi qu’une gestion claire des rôles (Client et Admin).

1.1 Contexte
La demande en services de location de voitures connaît une croissance rapide au Cameroun,
portée par l’essor du tourisme, l’augmentation des déplacements professionnels et le besoin accru de
flexibilité en matière de transport. Cependant, les plateformes existantes souffrent de plusieurs lacunes
:

• Un manque de fluidité dans la réservation et le paiement en ligne.

• Une gestion manuelle des stocks, entraînant des erreurs de disponibilité.
• Une absence de transparence sur les véhicules disponibles, leurs caractéristiques et leurs vi-
suels.
• Une interaction limitée entre les clients et les administrateurs, ce qui ralentit les confirmations
et les modifications de réservation.

Face à ces défis, notre solution propose une plateforme où :

• Les clients peuvent rechercher un véhicule en fonction de leurs besoins et de leurs dates de
réservation.
• Un paiement différé est possible, permettant aux utilisateurs de réserver d’abord, puis de fi-
naliser leur paiement depuis un tableau de bord intuitif.
• Les administrateurs bénéficient d’un système de gestion complet, optimisant les confirma-
tions, la disponibilité et les stocks.
• Chaque véhicule est mis en valeur grâce à une présentation détaillée et des photos multiples.

1.2 Problème
Le système de location de voitures actuel présente plusieurs limitations majeures, tant pour les
clients que pour les administrateurs :

• Manque d’automatisation dans la gestion des disponibilités, entraînant des conflits et des er-
reurs.

Page II of X
 • Complexité du suivi des réservations et des paiements, rendant l’expérience utilisateur frus-
trante.
• Risque d’annulation mal géré, en cas de non-paiement dans un délai imparti.
• Surbooking possible, faute d’une gestion efficace du stock.
• Absence de rôles bien définis, ce qui peut générer des confusions entre administrateurs et
clients.
• Présentation limitée des véhicules, avec peu d’images et d’informations détaillées.
En réponse à ces enjeux, notre projet met en place une solution digitale moderne et ergonomique,
garantissant une gestion optimisée des réservations et une expérience utilisateur fluide et intuitive.

2 ANALYSE
2.1 Diagramme de classe
Afin d’assurer une modélisation claire et précise du système, nous avons conçu un diagramme
de classe permettant de structurer les différents acteurs et leurs interactions. Ce diagramme met en
évidence les principales entités du système ainsi que leurs relations :

Figure 1: diagramme de classe

Page III of X
 2.2 Diagramme des cas d’utilisation

2.2 Diagramme des cas d’utilisation

Les diagrammes des cas d’utilisation suivants illustrent les différentes interactions entre les util-
isateurs du système et le système lui-même, en fonction de leurs rôles. Ils permettent de clarifier
les fonctionnalités accessibles pour chaque type d’utilisateur, en l’occurrence, l’administrateur et
l’utilisateur standard.
Le premier diagramme représente les cas d’utilisation relatifs à l’administrateur, qui dispose de
privilèges étendus lui permettant de gérer l’ensemble du système, incluant la gestion des utilisateurs,
des données et des configurations.
Le deuxième diagramme présente les cas d’utilisation pour l’utilisateur standard, qui dispose
d’un accès limité, lui permettant d’interagir avec le système en fonction des fonctionnalités qui lui
sont attribuées.
Chaque diagramme est suivi d’une description détaillée des cas d’utilisation qui les composent,
précisant les actions et interactions possibles.

2.2.1 Diagramme des cas d’utilisation de l’utilisateur

Figure 2: Diagramme des cas d’utilisation utilisateur

Page IV of X
 2.2 Diagramme des cas d’utilisation

2.2.2 Diagramme des cas d’utilisation de l’administrateur

Figure 3: Diagramme des cas d’utilisation de l’administrateur

2.2.3 Description des cas d’utilisation

1. S’inscrire
• Acteurs : Client

• Précondition : Le client accède au site web.

• Postcondition : Le client est inscrit avec un rôle de "Client" et peut se connecter.

• Scénario Nominal :
– Le client remplit un formulaire avec ses informations personnelles (nom, email, télé-
phone, mot de passe).
– Le système valide les informations saisies.
– Un compte est créé dans la base de données avec le rôle "Client".

Page V of X
 2.2 Diagramme des cas d’utilisation

– Un message de confirmation est affiché.

• Scénarios Alternatifs
(a) Si l’email est déjà utilisé, un message d’erreur s’affiche.

2. Se connecter

• Acteurs : Client ou Administrateur

• Précondition : L’utilisateur a un compte existant.

• Postcondition : L’utilisateur est connecté et redirigé vers son tableau de bord (client ou
admin).

• Scénario Nominal :
– L’utilisateur entre son email et son mot de passe sur la page de connexion.
– Le système vérifie les identifiants dans la base de données.
– Si les identifiants sont corrects, l’utilisateur est redirigé vers son tableau de bord.
• Scénarios Alternatifs :
(a) Si les identifiants sont incorrects, un message d’erreur s’affiche.

3. Rechercher des véhicules disponibles

• Acteurs : Client

• Précondition : Le client doit être connecté au système.

• Postcondition : Le client voit une liste des véhicules disponibles pour les dates choisies
avec leurs photos associées.

• Scénario Nominal :
– Le client entre ses dates souhaitées dans le filtre/barre de recherche.
– Le système interroge la base de données pour récupérer les véhicules disponibles pen-
dant cette période.
– La liste des véhicules disponibles est affichée avec leurs photos, prix et caractéris-
tiques.
• Scénarios Alternatifs :

Page VI of X
 2.2 Diagramme des cas d’utilisation

(a) Si aucun véhicule n’est disponible pour les dates choisies, un message informatif
s’affiche.
4. Réserver une voiture

• Acteurs : Client

• Précondition : Le client doit être connecté et avoir recherché un véhicule disponible.

• Postcondition : La réservation est ajoutée au tableau de bord du client avec le statut "en
attente".

• Scénario Nominal :
– Le client sélectionne un véhicule disponible depuis la liste affichée.
– Il clique sur le bouton "Réserver".
– Le système enregistre la réservation dans la base de données avec le statut "en attente".
– La réservation apparaît dans le tableau de bord du client avec deux options : "Con-
firmer" ou "Annuler".
• Scénarios Alternatifs :
(a) Si le véhicule n’est plus disponible au moment où le client clique sur "Réserver", un
message d’erreur s’affiche.
(b) Si la réservation n’est pas confirmée dans les 24 heures, elle est automatiquement
annulée.
5. Confirmer une réservation

• Acteurs : Utilisateur
• Précondition : L’utilisateur a une réservation en attente.
• Postcondition : La réservation est confirmée.
• Scénario Nominal :
– L’utilisateur accède à son tableau de bord.
– Il sélectionne une réservation et clique sur "Confirmer".
6. Annuler une réservation

• Acteurs : Utilisateur
• Précondition : L’utilisateur a une réservation en attente.
• Postcondition : La réservation est annulée.

Page VII of X
 2.2 Diagramme des cas d’utilisation

• Scénario Nominal :
– L’utilisateur accède à son tableau de bord.
– Il sélectionne une réservation et clique sur "Annuler".

7. Gérer les utilisateurs (Administrateur)

• Acteurs : Administrateur
• Précondition : L’administrateur doit être connecté.
• Postcondition : Les informations des utilisateurs sont mises à jour.

8. Gérer les utilisateurs

• Acteurs : Administrateur
• Précondition : L’administrateur doit être connecté au système.
• Postcondition : Les informations des utilisateurs sont mises à jour.
• Scénario Nominal :
– L’administrateur accède à la gestion des utilisateurs.
– Il consulte la liste des utilisateurs enregistrés.
– Il ajoute, modifie ou supprime des utilisateurs selon les besoins.
– Le système met à jour la base de données.
• Scénarios Alternatifs :
(a) Si un utilisateur à supprimer est un administrateur principal, une confirmation est
requise.

9. Gérer les véhicules et leur disponibilité

• Acteurs : Administrateur
• Précondition : L’administrateur doit être connecté.
• Postcondition : Les véhicules et leur disponibilité sont mis à jour.
• Scénario Nominal :
– L’administrateur accède à la gestion des véhicules.
– Il ajoute, modifie ou supprime des véhicules.
– Il met à jour leur statut de disponibilité.
– Le système enregistre les modifications.
• Scénarios Alternatifs :
(a) Si un véhicule est réservé, sa suppression est impossible.

Page VIII of X
 10. Consulter les statistiques de réservations
• Acteurs : Administrateur
• Précondition : L’administrateur doit être connecté.
• Postcondition : Les statistiques des réservations sont affichées.
• Scénario Nominal :
– L’administrateur accède au tableau de bord des statistiques.
– Il visualise les données sous forme de graphiques et de tableaux.
• Scénarios Alternatifs :
(a) Si aucune réservation n’est enregistrée, un message s’affiche.
11. Annulation automatique d’une réservation
• Acteurs : Système
• Précondition : Une réservation n’a pas été confirmée dans un délai imparti.
• Postcondition : La réservation est annulée automatiquement.
• Scénario Nominal :
– Le système vérifie régulièrement les réservations en attente.
– Si une réservation dépasse le délai imparti sans confirmation, elle est annulée automa-
tiquement.
– Un email de notification est envoyé au client concerné.
• Scénarios Alternatifs :
(a) Si un problème technique empêche l’annulation automatique, un administrateur est
averti.

3 CONCEPTION
3.1 Technologies Utilisées
Frontend : [Link] ou [Link]
- Ces technologies permettent une interface utilisateur fluide, réactive et performante.
- [Link] facilite le référencement (SEO) grâce au rendu côté serveur (SSR).

Backend : Spring Boot

- Framework robuste pour la gestion des API et des services backend.
- Sécurisé, performant et extensible pour des systèmes évolutifs.

Page IX of X
 Base de Données : MySQL
- Solution fiable et performante pour stocker les données des utilisateurs et des réservations.

Passerelle de Paiement : Orange Money ou Mobile Money

- Permet aux utilisateurs de payer facilement via des services de paiement mobile populaires au Camer-
oun.

Gestion des Rôles

- Le backend gère l’authentification et l’autorisation des utilisateurs en fonction de leur rôle (Client ou
Admin).
- L’interface utilisateur s’adapte dynamiquement aux autorisations définies.

4 DEVIS
Le projet comprend :

• Développement Frontend & Backend

• Configuration de la Base de Données

• Intégration du système de paiement (sans inclure l’achat des API de paiement)

• Hébergement du serveur : donc le paiement s’effectue annuellement auprès de la compagnie

d’hébergement

• Maintenance et Support

Remarque : Le client devra également acheter les API de paiement Orange Money ou Mobile
Money et prévoir des frais pour l’hébergement du serveur.

5 Coût Total du Projet

Au vu de l’ensemble des éléments mentionnés ci-dessus, le coût total estimé pour le développe-
ment du projet est de **100 000 FCFA**.
Remarque : Ce montant ne couvre pas l’achat des API de paiement ni les frais d’hébergement
du serveur, qui devront être pris en charge séparément par le client.

Page X of X