Table des matières

Liste des figuresviListe des tableauxvii

Introduction générale 1

1 Étude préliminaire et présentation du projet 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Structure générale de la société . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Les locaux de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Problématique du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.1 Présentation des solutions existantes . . . . . . . . . . . . . . . . . 5
1.6.1.1 Rentalcars.com . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.1.2 Europcar . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6.1.3 Sixt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9 Choix méthodologiques et conceptuels . . . . . . . . . . . . . . . . . . . . 9
1.9.1 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9.2 Méthodologie de développement : modèle en V . . . . . . . . . . . . 10
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

i
Dédicaces

2 Spécification des besoins 12

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Spécification des besoins : . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Besoins fonctionnels : . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Besoins non fonctionnels : . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Diagrammes généraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . 17
2.4 Raffinement et spécification des cas d’utilisation . . . . . . . . . . . . . . . 20
2.4.1 Spécification du cas d’utilisation « S’authentifier » . . . . . . . . . . 20
2.4.2 Raffinement du cas d’utilisation « Gérer l’inventaire des voitures » . 22
2.4.3 Spécification du cas d’utilisation « Gérer l’inventaire des voitures » 22
2.4.4 Raffinement du cas d’utilisation « Effectuer une réservation » . . . . 24
2.4.5 Spécification du cas d’utilisation « Effectuer une réservation » . . . 24
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Étude Conceptuelle 27
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1 Diagrammes de Séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 Séquence d’Authentification . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Opérations de l’Administrateur . . . . . . . . . . . . . . . . . . . . 28
3.1.3 Opérations de l’Agence . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.4 Processus de Réservation du Client . . . . . . . . . . . . . . . . . . 32
3.2 Diagramme des Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 Hiérarchie des Utilisateurs . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2 Entités Principales . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.3 Entités de Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.4 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Architecture Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

ii
Dédicaces

3.3.1 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.2 Stack Technologique . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3 Diagramme des Composants . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Schéma de Base de Données . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Réalisation 43
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1.1 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . 44
4.1.1.2 React.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.1.3 Express.js . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.1.4 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.1.5 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1.6 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1.7 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.1 Frontend (React.js) . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 Backend (Express.js/Node.js) . . . . . . . . . . . . . . . . . . . . . 47
4.2.3 Base de données (PostgreSQL) . . . . . . . . . . . . . . . . . . . . 47
4.2.4 Avantages de cette architecture . . . . . . . . . . . . . . . . . . . . 47
4.3 Organisation du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Structure du Backend . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.2 Structure du Frontend . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Présentation des interfaces de la solution . . . . . . . . . . . . . . . . . . . 50
4.4.1 Interface administrateur . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1.1 Interface de connexion . . . . . . . . . . . . . . . . . . . . 50
4.4.1.2 Tableau de bord administratif . . . . . . . . . . . . . . . . 51

iii
Dédicaces

4.4.1.3 Gestion des agences . . . . . . . . . . . . . . . . . . . . . 51

4.4.1.4 Gestion des plans d’abonnement . . . . . . . . . . . . . . 52
4.4.2 Interface agence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.2.1 Tableau de bord agence . . . . . . . . . . . . . . . . . . . 53
4.4.2.2 Gestion des voitures . . . . . . . . . . . . . . . . . . . . . 53
4.4.3 Interface client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.3.1 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.3.2 Recherche de voitures . . . . . . . . . . . . . . . . . . . . 55
4.4.3.3 Détails d’une voiture . . . . . . . . . . . . . . . . . . . . . 56
4.4.3.4 Création d’une réservation . . . . . . . . . . . . . . . . . . 56
4.4.3.5 Historique des réservations . . . . . . . . . . . . . . . . . . 57
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
CONCLUSION ET PERSPECTIVES . . . . . . . . . . . . . . . . . . . . . . . 60

iv
Table des figures

1.1 Logo de l’entreprise «Skillware» . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Exemples de plateformes de location de voitures . . . . . . . . . . . . . . . 5
1.3 Interface utilisateur de Rentalcars.com . . . . . . . . . . . . . . . . . . . . 6
1.4 Interface de réservation de Sixt . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Unified Modeling Language (UML) . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Modèle de développement en V . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . 18

2.2 Diagramme de cas d’utilisation - Vue Agence . . . . . . . . . . . . . . . . . 19
2.3 Diagramme de cas d’utilisation - Vue Client . . . . . . . . . . . . . . . . . 20
2.4 Raffinement du cas d’utilisation Gérer l’inventaire des voitures . . . . . . . 22
2.5 Raffinement du cas d’utilisation Effectuer une réservation . . . . . . . . . . 24

3.1 Diagramme de Séquence d’Authentification . . . . . . . . . . . . . . . . . . 28

3.2 Diagramme de Séquence de l’Administrateur . . . . . . . . . . . . . . . . . 29
3.3 Diagramme de Séquence de l’Agence . . . . . . . . . . . . . . . . . . . . . 31
3.4 Diagramme de Séquence de Réservation du Client . . . . . . . . . . . . . . 33
3.5 Diagramme des Classes de la Plateforme de Location de Voitures . . . . . 35
3.6 Diagramme des Composants de la Plateforme de Location de Voitures . . . 39

4.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

v
Dédicaces

4.3 Tableau de bord administratif . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.4 Interface de gestion des agences . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Interface de gestion des plans d’abonnement . . . . . . . . . . . . . . . . . 52
4.6 Tableau de bord agence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7 Interface de gestion des voitures . . . . . . . . . . . . . . . . . . . . . . . . 54
4.8 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9 Interface de recherche de voitures . . . . . . . . . . . . . . . . . . . . . . . 55
4.10 Interface de détails d’une voiture . . . . . . . . . . . . . . . . . . . . . . . 56
4.11 Interface de création d’une réservation . . . . . . . . . . . . . . . . . . . . 56
4.12 Interface d’historique des réservations . . . . . . . . . . . . . . . . . . . . . 57

vi
Liste des tableaux

2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Description du cas d’utilisation « S’authentifier » . . . . . . . . . . . . . . 21
2.3 Description du cas d’utilisation « Gérer l’inventaire des voitures » . . . . . 23
2.4 Description du cas d’utilisation « Effectuer une réservation » . . . . . . . . 26

vii
Introduction générale

Introduction générale
Avec l’essor du numérique et la généralisation des usages en ligne, les entreprises sont de
plus en plus amenées à repenser leurs stratégies commerciales afin d’améliorer leur visibilité,
fidéliser leur clientèle et accroître leurs revenus. Le secteur du transport n’échappe pas à
cette transformation, en particulier le domaine de la location de voitures, qui connaît une
forte digitalisation.
Dans cette optique, les agences de location souhaitent désormais bénéficier d’outils
numériques performants qui leur permettent de gérer efficacement leur parc automobile,
suivre les réservations, interagir avec leurs clients et optimiser leur activité. De leur côté,
les utilisateurs recherchent des solutions simples, rapides et accessibles à distance pour
réserver un véhicule selon leurs besoins, tout en ayant accès à des informations claires sur
la disponibilité, les prix et les conditions.
C’est dans ce contexte que s’inscrit notre projet de fin d’année. Nous proposons la mise
en place d’une plateforme de location de voitures en ligne qui met en relation trois
types d’utilisateurs : les agences de location, les clients et l’administrateur de la plateforme.
Chaque acteur disposera d’un espace personnalisé répondant à ses besoins spécifiques. Les
agences pourront gérer leurs abonnements, voitures et réservations ; les clients auront la
possibilité de réserver un véhicule, de payer en ligne et d’évaluer les services reçus ; tandis
que l’administrateur assurera la supervision générale du système.
Afin de décrire la plateforme sur laquelle nous avons travaillé tout au long de ces mois
dans le cadre de notre projet de fin d’études, nous présentons le rapport actuel. Il est
constitué de quatre chapitres structurés comme suit :
• Le premier chapitre est dédié à la présentation de l’organisme d’accueil, suivi d’une
étude de l’existant. À la fin, nous définissons l’objectif de notre projet en précisant
notre apport.

• Le deuxième chapitre est consacré principalement à la spécification des besoins. Après

avoir identifié les différents acteurs et leurs besoins fonctionnels, un diagramme de
cas d’utilisation a été modélisé. Cette phase a donné lieu à la spécification et au

1
Introduction générale

raffinement des cas d’utilisation, sans oublier les besoins non fonctionnels de notre
application.

• Le troisième chapitre présente une conception détaillée à travers différents dia-

grammes UML, notamment les diagrammes de séquence, de classe et de déploiement.

• Le dernier chapitre est consacré à la présentation de l’environnement logiciel, ainsi

qu’aux résultats du projet à travers les interfaces graphiques de la plateforme déve-
loppée.

Enfin, nous clôturons ce rapport par une synthèse du projet ainsi que quelques pers-
pectives d’évolution envisagées pour cette solution.

2
Chapitre

1 Étude préliminaire et présentation du projet

Introduction
L’objectif principal de ce chapitre est de situer notre projet dans son contexte. Tout
d’abord, nous présentons l’entreprise d’accueil. Ensuite, nous décrivons l’étude de l’existant,
en analysant les solutions similaires. Nous exposons également les objectifs fixés pour ce
projet. Enfin, nous présentons la méthode de développement adoptée ainsi que le langage
de modélisation utilisé.

1.1 Présentation de l’entreprise

Skillware est une entreprise tunisienne fondée en 2020, spécialisée dans le développement
de solutions informatiques web, mobiles et desktop. Elle propose des services sur mesure
adaptés aux besoins de ses clients dans divers domaines tels que la gestion commerciale, la
comptabilité, les applications mobiles, les portails web et les solutions d’automatisation.

Figure 1.1 : Logo de l’entreprise «Skillware»

3
Chapter 1. Étude préliminaire et présentation du projet

1.2 Structure générale de la société

L’entreprise est composée de plusieurs départements assurant un fonctionnement opti-
mal : le département technique, le département développement, le service client, ainsi que
le service administratif. Skillware adopte une approche collaborative et agile, mettant en
avant l’innovation et la qualité.

1.3 Les locaux de la société

Skillware est basée à Sousse, Tunisie. Elle dispose de locaux modernes offrant un envi-
ronnement propice au travail collaboratif, favorisant la productivité et la créativité de ses
équipes.

1.4 Cadre général du projet

Dans le cadre de l’obtention du diplôme national d’ingénieur en informatique, spécialité
Génie Logiciel, ce projet de fin d’études a été réalisé au sein de la société Skillware, du 1er
février 2024 au 31 mai 2024. Le sujet du projet porte sur : « Conception et Réalisation
d’une application web de location de voitures ».

1.5 Problématique du projet

Le secteur de la location de voitures connaît une croissance importante, mais de nom-
breuses agences de location utilisent encore des méthodes traditionnelles, ce qui engendre
des inefficacités dans la gestion des réservations, des véhicules et de la clientèle. L’absence
de digitalisation peut entraîner des erreurs de gestion, des pertes de temps, et une mauvaise
expérience client. Le projet vise donc à fournir une solution numérique moderne et efficace.

4
Chapter 1. Étude préliminaire et présentation du projet

1.6 Étude de l’existant

Pour comprendre l’état actuel du marché des applications de location de voitures, nous
avons analysé plusieurs plateformes populaires, tant internationales que locales. Cette étude
nous a permis d’identifier leurs fonctionnalités clés, leurs points forts et leurs limitations.

1.6.1 Présentation des solutions existantes

Rentalcars
Sixt

Europcar

Figure 1.2 : Exemples de plateformes de location de voitures

1.6.1.1 Rentalcars.com

Rentalcars.com est une plateforme internationale de réservation de voitures opérant

dans plus de 160 pays. Elle sert d’intermédiaire entre les clients et diverses agences de
location.
Points forts :

• Interface multilingue facilitant l’accès à un public international

• Système avancé de filtrage par prix, type de véhicule, et équipements

• Système de notation des véhicules et des agences pour aider à la décision

• Options d’assurance intégrées directement dans le processus de réservation

• Support client 24/7 disponible en plusieurs langues

5
Chapter 1. Étude préliminaire et présentation du projet

Limitations :

• Interface surchargée d’informations pour les utilisateurs novices

• Frais additionnels parfois peu transparents jusqu’au paiement final

• Absence d’options pour la personnalisation des réservations spécifiques

• Expérience mobile moins optimisée que la version desktop

• Dépendance vis-à-vis des données fournies par les agences partenaires

Figure 1.3 : Interface utilisateur de Rentalcars.com

1.6.1.2 Europcar

Europcar est l’un des leaders mondiaux de la location de véhicules avec une présence
importante en Tunisie et en Afrique du Nord. L’entreprise propose une gamme complète
de services de mobilité.
Points forts :

• Réseau étendu d’agences physiques en Tunisie et à l’international

• Programme de fidélité "Privilege" avec avantages progressifs

• Flotte diversifiée et régulièrement renouvelée

6
Chapter 1. Étude préliminaire et présentation du projet

• Processus de réservation et de prise en charge standardisé

• Options de location flexibles (courte, moyenne et longue durée)

Limitations :

• Tarifs généralement plus élevés que les agences locales

• Interface web moins interactive que certains concurrents

• Rigidité dans les modifications et annulations de réservation

• Application mobile avec fonctionnalités limitées

• Peu d’adaptation aux spécificités du marché tunisien

1.6.1.3 Sixt

Sixt est une entreprise internationale de location de voitures présente en Tunisie, re-
connue pour sa flotte premium et son positionnement haut de gamme.
Points forts :

• Interface utilisateur moderne et épurée

• Qualité supérieure de la flotte avec véhicules premium

• Service client réactif avec assistance en plusieurs langues

• Système de réservation rapide avec confirmation instantanée

• Application mobile bien développée avec fonctionnalités complètes

Limitations :

• Tarification élevée comparée aux autres acteurs du marché

• Nombre limité d’agences en Tunisie, principalement dans les zones touristiques

• Options d’assurance complexes avec suppléments nombreux

7
Chapter 1. Étude préliminaire et présentation du projet

• Manque d’intégration avec des services locaux

• Système de gestion pour agences partenaires peu développé

Figure 1.4 : Interface de réservation de Sixt

1.7 Solution proposée

Suite à cette analyse approfondie des solutions existantes, nous proposons une applica-
tion web innovante qui adresse les limitations identifiées :

• Architecture flexible : Une application web intuitive avec une architecture micro-
services permettant une évolutivité optimale.

• Gestion multi-agences avancée : Permettre à plusieurs agences d’administrer

leurs véhicules, tarifs et disponibilités via des tableaux de bord dédiés.

• Système de réservation intelligent : Gestion des réservations en temps réel avec

synchronisation automatique des disponibilités.

• Interface administrative complète : Tableau de bord analytique pour visuali-

ser les statistiques de performance, suivi des paiements, et gestion centralisée des
utilisateurs.

8
Chapter 1. Étude préliminaire et présentation du projet

• Expérience utilisateur optimisée : Interface moderne, responsive et intuitive avec

parcours de réservation simplifié.

• Sécurité et conformité : Respect des standards de sécurité et de protection des

données personnelles conformément aux réglementations en vigueur.

1.8 Présentation du projet

Le projet consiste à développer une application web de location de voitures, offrant
une gestion complète des agences, voitures, réservations et paiements. Il s’adresse à la
fois aux clients souhaitant louer un véhicule, et aux agences souhaitant gérer leur activité
efficacement.

1.9 Choix méthodologiques et conceptuels

Pour atteindre les objectifs du projet, une méthodologie adaptée est nécessaire pour
garantir un bon déroulement du développement et livrer une application fonctionnelle et
fiable.

1.9.1 Langage de modélisation

Figure 1.5 : Unified Modeling Language (UML)

9
Chapter 1. Étude préliminaire et présentation du projet

Le langage de modélisation utilisé est UML, pour représenter les différents cas d’utili-
sation, classes, et interactions de l’application.

1.9.2 Méthodologie de développement : modèle en V

Pour assurer un processus de développement rigoureux, nous avons opté pour la mé-
thode en V. Elle permet de structurer le cycle de vie du projet en deux grandes phases :
la conception descendante (de l’expression des besoins vers le code), puis la vérification
ascendante (des tests unitaires jusqu’à la validation finale).

Figure 1.6 : Modèle de développement en V

Les principales étapes du modèle en V sont :

– Spécification des besoins : identification des attentes fonctionnelles.

– Conception fonctionnelle : description des fonctionnalités majeures.

10
Chapter 1. Étude préliminaire et présentation du projet

– Conception technique : définition de l’architecture et des technologies.

– Implémentation : codage du front-end et back-end.

– Tests unitaires : vérification de chaque composant.

– Tests d’intégration : test de la communication entre les modules.

– Validation : livraison du produit final conforme aux exigences.

Conclusion
Dans ce chapitre, nous avons présenté l’entreprise d’accueil et le cadre du projet. Nous
avons effectué une analyse détaillée des solutions existantes sur le marché, identifiant leurs
forces et leurs limitations tant d’un point de vue fonctionnel que technique. Cette étude
critique nous a permis de définir une proposition de solution innovante et adaptée aux
besoins réels du marché. Le chapitre suivant sera consacré à l’analyse approfondie des
besoins et à la conception de l’application.

11
Chapitre

2 Spécification des besoins

Introduction
Dans le chapitre précédent, nous avons décidé de concevoir notre système en utilisant
le modèle de processus unifié. L’une des phases essentielles de ce processus est la phase
d’élaboration qui permet d’identifier les rôles des utilisateurs et de spécifier les principales
fonctionnalités. Au cours de ce chapitre, nous commençons par identifier les différents
acteurs qui interagissent directement avec le système. Nous représentons également la
spécification des besoins. Enfin, nous décrivons le diagramme de cas d’utilisation avec le
raffinement et la spécification de certains cas d’utilisation.

2.1 Acteurs
Un acteur est un composant du système qui interagit avec lui. Il s’agit d’une personne,
d’un ordinateur ou d’un logiciel. Dans notre plateforme de location de voitures, il y a trois
acteurs :

• Client : Un utilisateur authentifié qui peut rechercher des voitures, effectuer des
réservations et gérer ses réservations.

• Agence : Un utilisateur authentifié qui peut gérer l’inventaire des voitures, les
réservations et les tarifs.

12
Chapitre 2. Spécification des besoins

• Administrateur : Possède le plus haut niveau d’accès et de responsabilité, y

compris la gestion de la plateforme, les plans d’abonnement et les rapports.

2.2 Spécification des besoins :

L’application à créer doit répondre à des exigences fonctionnelles et non fonctionnelles
afin d’augmenter la qualité logicielle du système. Dans les paragraphes suivants, nous allons
passer en revue ces exigences.

2.2.1 Besoins fonctionnels :

Les besoins fonctionnels ou métiers permettent de mieux comprendre le rôle de l’ap-

plication, ses principales caractéristiques et les attentes de chaque acteur impliqué dans
le processus de développement. Il décrit les services que le logiciel doit offrir. De même,
il représente les principales fonctions que l’application fournira. Dans le tableau suivant,
nous allons définir ces exigences fonctionnelles :

13
Chapitre 2. Spécification des besoins

Acteurs Cas d’utilisation Description

Ce cas d’utilisation permet aux clients de re-

Rechercher des
chercher des voitures disponibles selon divers
voitures disponibles
critères.

Ce cas d’utilisation permet aux clients de voir

Consulter les détails
des informations détaillées sur des voitures spé-
Client d’une voiture
cifiques.

Effectuer une Ce cas d’utilisation permet aux clients de réser-

réservation ver une voiture pour une période spécifique.

Consulter l’historique Ce cas d’utilisation permet aux clients de voir

des réservations leurs réservations passées et à venir.

Ce cas d’utilisation permet aux clients de

Gérer le profil
mettre à jour leurs informations personnelles.

Annuler une Ce cas d’utilisation permet aux clients d’annuler

réservation leurs réservations existantes.

Ce cas d’utilisation permet aux clients de laisser

Créer un commentaire des commentaires pour les voitures qu’ils ont
louées.

Ce cas d’utilisation permet aux agences de

Gérer les réservations
consulter, approuver et rejeter les réservations.

Ce cas d’utilisation permet aux agences d’ajou-

Gérer l’inventaire des
ter, mettre à jour et supprimer des voitures de
voitures
leur inventaire.
Agence

14
Chapitre 2. Spécification des besoins

Ce cas d’utilisation permet aux agences de

Gérer la disponibilité
mettre à jour le statut de disponibilité de leurs
des voitures
voitures.

Consulter le
Ce cas d’utilisation permet aux agences de voir
calendrier des
une vue calendrier de toutes les réservations.
réservations

Ce cas d’utilisation permet aux agences de dé-

Gérer les tarifs
finir et mettre à jour les prix de location.

Gérer le profil de Ce cas d’utilisation permet aux agences de

l’agence mettre à jour leurs informations commerciales.

Consulter les rapports Ce cas d’utilisation permet aux agences de gé-

de l’agence nérer et consulter des rapports commerciaux.

Ce cas d’utilisation permet aux agences de gérer

Gérer l’abonnement
leur abonnement à la plateforme.

Consulter les Ce cas d’utilisation permet aux administrateurs

statistiques de la de consulter les indicateurs de performance glo-
plateforme bale de la plateforme.
Administrateur
Ce cas d’utilisation permet aux administrateurs
Gérer les plans
de créer et mettre à jour les plans d’abonne-
d’abonnement
ment.

Ce cas d’utilisation permet aux administrateurs

Générer des rapports
de générer des rapports complets sur la plate-
de plateforme
forme.

15
Chapitre 2. Spécification des besoins

Ce cas d’utilisation permet aux administrateurs

Gérer les agences de superviser toutes les agences sur la plate-
forme.

Table 2.1 : Besoins fonctionnels

2.2.2 Besoins non fonctionnels :

Le système doit également répondre à des exigences non fonctionnelles, qui visent à
augmenter sa qualité.

• Disponibilité :
L’application doit être accessible aux utilisateurs de tous âges et de tous horizons.

• Ergonomie :
L’application possède une interface intuitive et facile à utiliser qui comprend toutes
les fonctionnalités accessibles. Les utilisateurs peuvent l’utiliser même sans expérience
informatique préalable.

• Maintenabilité :
Le code doit être compréhensible et bien organisé, afin de faciliter la maintenance
future.

• Performance :
L’application doit être interactive en minimisant le temps de réaction et de commu-
nication avec les serveurs, ainsi que le chargement de la plateforme, l’ouverture et la
mise à jour des affichages.

• Sécurité :
L’application doit protéger les données des utilisateurs et assurer un traitement sé-
curisé des paiements.

16
Chapitre 2. Spécification des besoins

2.3 Diagrammes généraux

2.3.1 Diagramme de cas d’utilisation global

Les diagrammes fournis représentent tous les cas d’utilisation de base pour la plate-
forme de location de voitures. Ces diagrammes sont génériques et ne spécifient pas chaque
exigence individuellement ; au contraire, ils combinent certaines caractéristiques dans un
seul exemple, qui peut être détaillé davantage pour mieux le comprendre.

17
Chapitre 2. Spécification des besoins

Figure 2.1 : Diagramme de cas d’utilisation global

18
Chapitre 2. Spécification des besoins

Figure 2.2 : Diagramme de cas d’utilisation - Vue Agence

19
Chapitre 2. Spécification des besoins

Figure 2.3 : Diagramme de cas d’utilisation - Vue Client

2.4 Raffinement et spécification des cas d’utilisation

2.4.1 Spécification du cas d’utilisation « S’authentifier »

Titre S’authentifier

Acteurs Client, Agence, Administrateur

20
Chapitre 2. Spécification des besoins

Ce cas d’utilisation permet à tous les acteurs de s’authentifier

Brève description
en fournissant leur nom d’utilisateur et leur mot de passe.

L’utilisateur dispose de l’application sur son ordinateur ou son smartphone.

Préconditions
L’utilisateur demande à se connecter au système.

Postconditions Utilisateur authentifié

1. L’utilisateur saisit son identifiant et son mot de passe.

2. L’utilisateur valide sa connexion.

Scénario de base 3. Le système vérifie la combinaison de l’identifiant et du mot de passe.

4. Le système affiche l’interface du menu principal appropriée

pour l’utilisateur.

3.a Si l’utilisateur ne remplit pas les deux champs :

1. Le système informe que les données sont vides.

2. Retour à l’étape 1 du scénario de base.

Scénarios d’exception
3.b Si la combinaison de l’identifiant et du mot de passe est incorrecte :

1. Le système informe l’utilisateur de cette erreur.

2. Retour à l’étape 1 du scénario de base.

Table 2.2 : Description du cas d’utilisation « S’authentifier »

21
Chapitre 2. Spécification des besoins

2.4.2 Raffinement du cas d’utilisation « Gérer l’inventaire des

voitures »

Figure 2.4 : Raffinement du cas d’utilisation Gérer l’inventaire des voitures

2.4.3 Spécification du cas d’utilisation « Gérer l’inventaire des

voitures »

Gérer l’inventaire des voitures

Titre Gérer l’inventaire des voitures

Acteurs Agence (authentifiée)

Ce cas d’utilisation permet

Brève description
aux agences de gérer leur inventaire de voitures.

Préconditions L’agence est authentifiée

Postconditions Voiture ajoutée, voiture mise à jour, ou voiture supprimée

22
Chapitre 2. Spécification des besoins

1. L’agence sélectionne l’option d’ajouter une nouvelle voiture.

2. Le système affiche le formulaire correspondant.

Scénario de base 3. L’agence remplit les champs de manière appropriée

(marque, modèle, année, caractéristiques, images, tarification).

4. Le système affiche un message de succès.

1. L’agence sélectionne une voiture à mettre à jour.

2. Le système affiche les informations de la voiture.

Scénario alternatif A.1
3. L’agence modifie les informations.

4. Le système affiche un message de succès.

1. L’agence sélectionne une voiture à supprimer.

2. Le système affiche un message

Scénario alternatif A.2 pour valider cette action ou l’annuler.

3. L’agence confirme la suppression.

4. Le système indique que la voiture a été supprimée.

3.a Si l’agence ne remplit pas tous les champs requis :

Scénarios d’exception 1. Le système affiche un message d’erreur.

2. Retour à l’étape 2 du scénario de base.

Table 2.3 : Description du cas d’utilisation « Gérer l’inventaire des voitures »

23
Chapitre 2. Spécification des besoins

2.4.4 Raffinement du cas d’utilisation « Effectuer une réserva-

tion »

Figure 2.5 : Raffinement du cas d’utilisation Effectuer une réservation

2.4.5 Spécification du cas d’utilisation « Effectuer une réserva-

tion »

Effectuer une réservation

Titre Effectuer une réservation

Acteur Client

Ce cas d’utilisation permet aux clients de réserver

Brève description
une voiture pour une période spécifique.

Le client est authentifié.

Préconditions
Le client a sélectionné une voiture.

Postconditions Réservation créée

24
Chapitre 2. Spécification des besoins

1. Le client sélectionne les dates pour la location.

2. Le système vérifie la disponibilité de la voiture

pour les dates sélectionnées.

3. Le client fournit les détails de location

(lieu de prise en charge, lieu de retour, options supplémentaires).

Scénario de base 4. Le système calcule et affiche le coût total.

5. Le client confirme la réservation.

6. Le système traite le paiement.

7. Le système génère un contrat.

8. Le système confirme la réservation et envoie

une confirmation au client.

25
Chapitre 2. Spécification des besoins

2.a Si la voiture n’est pas disponible pour les dates sélectionnées :

1. Le système informe le client de l’indisponibilité.

2. Le système suggère des dates alternatives ou des voitures similaires.

3. Retour à l’étape 1 du scénario de base.

Scénarios d’exception 6.a Si le paiement échoue :

1. Le système informe le client de l’échec du paiement.

2. Le système permet au client de réessayer ou

d’utiliser un mode de paiement différent.

3. Retour à l’étape 5 du scénario de base.

Table 2.4 : Description du cas d’utilisation « Effectuer une réservation »

Conclusion
En conclusion, nous avons identifié les différents acteurs ainsi que les besoins fonction-
nels et non fonctionnels du système, ce qui constitue une étape essentielle dans la conception
de la solution applicative de plateforme de location de voitures. Dans le prochain chapitre,
nous présenterons la partie conceptuelle du projet et ses architectures logique et technique.

26
Chapitre

3 Étude Conceptuelle

Introduction
Dans le chapitre précédent, nous avons identifié les différents acteurs ainsi que les
besoins fonctionnels et non fonctionnels de notre plateforme de location de voitures. Cette
étape était cruciale pour comprendre ce que notre système doit accomplir.
Ce chapitre se concentre sur la conception conceptuelle du système, présentant l’archi-
tecture logique à travers divers diagrammes UML. Nous commençons par les diagrammes
de séquence qui illustrent les interactions entre les composants du système, suivis du
diagramme de classes qui définit la structure globale du système.

3.1 Diagrammes de Séquence

Les diagrammes de séquence illustrent l’interaction entre les objets dans une séquence
temporelle. Ils montrent comment les opérations sont effectuées — quels messages sont
envoyés et quand. Les diagrammes de séquence suivants représentent les principales inter-
actions dans notre plateforme de location de voitures.

3.1.1 Séquence d’Authentification

L’authentification est un processus fondamental requis par tous les acteurs avant qu’ils
puissent interagir avec le système. La figure 3.1 montre le diagramme de séquence pour le

27
Chapitre 3. Conception Conceptuelle

processus de connexion.

Figure 3.1 : Diagramme de Séquence d’Authentification

Ce diagramme illustre le processus de connexion avec les étapes suivantes :

• L’utilisateur soumet ses identifiants via l’interface utilisateur

• Le serveur envoie les identifiants à la base de données pour vérification

• Si valides, un jeton d’authentification est renvoyé à l’utilisateur

• Si invalides, un message d’erreur est affiché

3.1.2 Opérations de l’Administrateur

L’acteur administrateur a la responsabilité de gérer les agences et les plans d’abonne-

ment dans le système. La figure 3.2 illustre le diagramme de séquence pour les opérations
administratives.

28
Chapitre 3. Conception Conceptuelle

Figure 3.2 : Diagramme de Séquence de l’Administrateur

29
Chapitre 3. Conception Conceptuelle

Ce diagramme illustre trois opérations administratives principales :

• Consulter les agences : L’administrateur peut consulter la liste de toutes les agences
enregistrées dans le système.

• Approuver ou désactiver une agence : L’administrateur peut modifier le statut d’une

agence, déclenchant des notifications par e-mail à l’agence concernée.

• Gérer les plans d’abonnement : L’administrateur peut créer, mettre à jour ou sup-
primer les plans d’abonnement disponibles pour les agences.

Chaque opération suit un flux complet, de l’interaction utilisateur aux opérations de

base de données, y compris les scénarios de succès et de gestion des erreurs.

3.1.3 Opérations de l’Agence

Les agences doivent gérer leur inventaire de voitures en ajoutant, modifiant et suppri-
mant des voitures. La figure 3.3 montre le diagramme de séquence pour ces opérations.

30
Chapitre 3. Conception Conceptuelle

31de Séquence de l’Agence

Figure 3.3 : Diagramme
Chapitre 3. Conception Conceptuelle

Ce diagramme illustre les opérations suivantes de l’agence :

• Consulter les voitures : L’agence peut voir toutes les voitures dans son inventaire.

• Ajouter une nouvelle voiture : L’agence peut ajouter une nouvelle voiture avec tous
les détails nécessaires.

• Modifier une voiture : L’agence peut mettre à jour les informations d’une voiture
existante.

• Supprimer une voiture : L’agence peut retirer une voiture de son inventaire.

Le diagramme montre le flux complet pour chaque opération, y compris les interactions
entre l’interface utilisateur Frontend, le serveur Backend, la base de données et le service
de gestion des voitures.

3.1.4 Processus de Réservation du Client

L’interaction principale du client avec le système implique la recherche de voitures et

la réalisation de réservations. La figure 3.4 illustre ce processus.

32
Chapitre 3. Conception Conceptuelle

Figure 3.4 : Diagramme de Séquence de Réservation du Client

Ce diagramme montre le processus de réservation du client avec les étapes suivantes :

• Parcourir les voitures disponibles : Le client peut voir toutes les voitures disponibles.

33
Chapitre 3. Conception Conceptuelle

• Effectuer une réservation : Le client sélectionne une voiture et des dates pour créer
une réservation.

• Traiter le paiement : Après une réservation réussie, le paiement est traité.

• Confirmation par e-mail : Un e-mail de confirmation avec le contrat est envoyé au

client.

Le diagramme illustre également divers scénarios d’exception tels que les échecs de paie-
ment, les échecs de livraison d’e-mail ou les échecs de réservation, ainsi que leur traitement
approprié.

3.2 Diagramme des Classes

Le diagramme de classes représente la structure statique du système, montrant les
classes, leurs attributs, opérations, et les relations entre les objets. La figure 3.5 présente
le diagramme de classes complet pour notre plateforme de location de voitures.

34
Chapitre 3. Conception Conceptuelle

Figure 3.5 : Diagramme des Classes de la Plateforme de Location de Voitures

35
Chapitre 3. Conception Conceptuelle

Le diagramme de classes montre les composants clés suivants :

3.2.1 Hiérarchie des Utilisateurs

• User : Classe de base avec des attributs communs comme id, email et mot de passe.

• Admin : Spécialisation de User avec des opérations supplémentaires pour gérer les
agences et les abonnements.

• Customer : Spécialisation de User avec des opérations pour effectuer des réservations
et des paiements.

3.2.2 Entités Principales

• Agency : Représente une agence de location de voitures avec des attributs tels que
nom, adresse et statut de vérification. Elle gère les voitures et les abonnements.

• Car : Représente un véhicule dans le système avec des attributs comme modèle,
marque, année et prix.

• Reservation : Représente une réservation avec des attributs incluant date de début,
date de fin et statut.

• Payment : Représente une transaction financière associée à une réservation.

• Contract : Représente l’accord légal généré pour une réservation confirmée.

3.2.3 Entités de Support

• Subscription : Représente l’inscription d’une agence à un plan spécifique.

• SubscriptionPlan : Définit les options d’abonnement disponibles avec tarifs et fonc-

tionnalités.

36
Chapitre 3. Conception Conceptuelle

• Review : Représente les commentaires des clients pour une voiture ou une expérience
de location spécifique.

• AgencyStatistics et PlatformStatistics : Fournissent des données analytiques

pour les agences et les administrateurs.

• AnalyticsReport : Représente les rapports formels générés à partir des statistiques.

• PaymentService : Service externe pour le traitement des paiements.

3.2.4 Relations

Le diagramme illustre plusieurs relations importantes entre les classes :

• Un Admin gère plusieurs Agencies

• Une Agency possède plusieurs Cars

• Une Agency a une Subscription actuelle

• Un Customer effectue plusieurs Reservations

• Une Reservation concerne une Car

• Une Reservation génère un Contract

• Une Reservation nécessite un Payment

• Un Customer peut créer plusieurs Reviews

Ce diagramme de classes complet fournit une base solide pour la phase d’implémenta-
tion, définissant clairement la structure et les relations des composants du système.

37
Chapitre 3. Conception Conceptuelle

3.3 Architecture Technique

Notre plateforme de location de voitures suit le modèle d’architecture Modèle-Vue-
Contrôleur (MVC), implémenté avec des technologies web modernes. Cette section détaille
les composants architecturaux et leur interaction.

3.3.1 Architecture MVC

Le modèle MVC sépare notre application en trois composants interconnectés :

• Modèle : Représente la structure de données et la logique métier

• Vue : Représente l’interface utilisateur et la couche de présentation

• Contrôleur : Agit comme intermédiaire entre le Modèle et la Vue, traitant les re-
quêtes et les réponses utilisateur

3.3.2 Stack Technologique

Notre plateforme de location de voitures utilise la stack technologique suivante :

• Frontend (Vue) : React.js

– React Router pour la navigation

– Redux pour la gestion d’état

– Axios pour la communication API

– Material UI pour le style des composants

• Backend (Contrôleur) : Express.js

– Points de terminaison API RESTful

– JWT pour l’authentification

– Middleware pour le traitement des requêtes

38
Chapitre 3. Conception Conceptuelle

• Base de données (Modèle) : PostgreSQL

– Sequelize ORM pour les opérations de base de données

– Modèles de données reflétant le diagramme de classes

3.3.3 Diagramme des Composants

La figure 3.7 illustre le diagramme des composants de notre plateforme de location de

voitures, montrant les relations entre les principaux composants du système basés sur notre
stack technologique.

Figure 3.6 : Diagramme des Composants de la Plateforme de Location de Voitures

Notre système se compose des principaux composants suivants :

• Frontend React :

– Tableau de Bord Admin : Interface pour les fonctions administratives

– Portail Agence : Interface pour les opérations d’agence

39
Chapitre 3. Conception Conceptuelle

– Interface Client : Interface pour parcourir les voitures et effectuer des réserva-
tions

– Composants Communs : Éléments d’interface utilisateur partagés comme les

formulaires d’authentification

• Backend Express :

– Routes API : Définissent les points de terminaison pour toutes les opérations

– Contrôleurs : Gèrent le traitement des requêtes et la logique métier

– Middleware : Gère les préoccupations transversales comme l’authentification

– Services : Encapsulent la logique métier complexe

• Base de Données PostgreSQL : Stocke toutes les données persistantes selon notre
modèle de données

• Services Externes :

– Passerelle de Paiement : Pour le traitement des paiements

– Service d’Email : Pour l’envoi des notifications

Ces composants interagissent entre eux via des interfaces bien définies, assurant la
modularité et la maintenabilité du système.

3.4 Schéma de Base de Données

Basé sur notre diagramme de classes, nous avons conçu un schéma de base de données
relationnelle pour PostgreSQL.
Le schéma comprend les tables principales suivantes :

• users : Stocke les informations utilisateur avec les rôles (admin, agence, client)

• agencies : Stocke les informations des agences

40
Chapitre 3. Conception Conceptuelle

• cars : Stocke les détails des voitures appartenant aux agences

• subscription_plans : Stocke les options d’abonnement disponibles

• subscriptions : Lie les agences à leurs plans d’abonnement

• reservations : Stocke les informations de réservation

• payments : Suit les transactions de paiement

• contracts : Stocke les documents légaux pour les réservations

• reviews : Stocke les commentaires des clients

• statistics : Stocke les données analytiques

Les clés primaires, les clés étrangères et les index appropriés sont définis pour assurer
l’intégrité des données et les performances des requêtes.

Conclusion
Dans ce chapitre, nous avons présenté la conception conceptuelle de notre plateforme
de location de voitures à travers divers diagrammes UML et descriptions architecturales.
Les diagrammes de séquence illustrent le comportement dynamique du système, montrant
comment les différents composants interagissent pour accomplir des tâches spécifiques. Le
diagramme de classes fournit une vision complète de la structure du système, définissant
les classes, leurs attributs, opérations et relations.
Nous avons également détaillé notre architecture technique, basée sur le modèle MVC et
implémentée avec React.js (Vue), Express.js (Contrôleur) et PostgreSQL (Modèle). Cette
stack technologique moderne fournit une base solide pour construire un système réactif,
évolutif et maintenable.
La stratégie de déploiement utilisant la conteneurisation assure la cohérence entre les
environnements de développement et de production, tandis que la solution d’hébergement
basée sur le cloud fournit l’infrastructure nécessaire pour la fiabilité et l’évolutivité.

41
Chapitre 3. Conception Conceptuelle

Cette conception conceptuelle sert de plan pour la phase d’implémentation, fournissant

des directives claires sur la façon de développer le système selon les exigences spécifiées au
chapitre 2.
Dans le prochain chapitre, nous approfondirons la conception détaillée du système, en
nous concentrant sur des aspects d’implémentation spécifiques tels que les spécifications
API, les mesures de sécurité et la conception de l’interface utilisateur.

42
Chapitre

4 Réalisation

Introduction
Dans le chapitre précédent, nous avons donné une représentation détaillée de la concep-
tion de notre plateforme de location de voitures mise en œuvre pendant la phase de concep-
tion.
Dans ce dernier chapitre, nous passons d’abord en revue l’environnement de développement,
qui comprend à la fois le matériel et le logiciel. Ensuite, nous présentons l’architecture de
l’application et son organisation technique. Pour finir, nous décrivons le travail effectué à
l’aide de captures d’écran des interfaces de notre application.

4.1 Environnement de développement

Le choix du logiciel est une étape essentielle dans le développement de tout projet. Il
dépend toujours de nos exigences en matière de temps et de performances.

4.1.1 Environnement logiciel

Pour développer notre plateforme de location de voitures, différents environnements de

développement logiciel ont été utilisés :

43
Chapitre 4. Réalisation

4.1.1.1 Visual Studio Code

Visual Studio Code est un éditeur de code source développé par Micro-
soft pour Windows, Linux et macOS. Il comprend la prise en charge du
débogage, la mise en évidence de la syntaxe, la complétion intelligente du
code, les snippets, la refactorisation du code et Git intégré. Il est haute-
ment personnalisable, permettant aux utilisateurs de modifier le thème,
les raccourcis clavier et les préférences. Il est gratuit, open-source et offre
de nombreuses extensions.

4.1.1.2 React.js
React.js est une bibliothèque JavaScript front-end open-source utilisée
pour construire des interfaces utilisateur ou des composants UI. Elle est
maintenue par Facebook et une communauté de développeurs individuels
et d’entreprises. React permet aux développeurs de créer de grandes
applications Web qui peuvent modifier les données sans avoir à recharger
la page. Son objectif principal est d’être rapide, évolutif et simple.

4.1.1.3 Express.js
Express.js est un framework d’application web pour Node.js, conçu pour
construire des applications web et des API. C’est de facto le framework
standard pour Node.js. Express est minimaliste, flexible et fournit un
ensemble robuste de fonctionnalités pour développer des applications web
et mobiles. Il facilite le développement rapide d’applications Node basées
sur le réseau.

4.1.1.4 PostgreSQL
PostgreSQL est un système de gestion de base de données relationnelle
objet (SGBDRO) puissant et open source. Il possède plus de 30 ans
de développement actif et une architecture éprouvée qui lui a valu une
solide réputation de fiabilité, de robustesse des fonctionnalités et de per-
formances. PostgreSQL est compatible avec tous les principaux systèmes
d’exploitation et est conforme à ACID depuis 2001.

44
Chapitre 4. Réalisation

4.1.1.5 GitHub
GitHub est une plateforme d’hébergement de code pour le contrôle de
version et la collaboration. Il permet à vous et à d’autres de travailler
ensemble sur des projets de n’importe où. GitHub utilise Git, un outil de
contrôle de version distribué qui suit les modifications de votre code au
fil du temps. GitHub facilite la collaboration et le partage du code avec
une équipe à travers le monde.

4.1.1.6 Node.js
Node.js est un environnement d’exécution JavaScript open-source et mul-
tiplateforme qui exécute du code JavaScript en dehors d’un navigateur
web. Node.js permet aux développeurs d’utiliser JavaScript pour écrire
des outils de ligne de commande et pour des scripts côté serveur - exécu-
ter des scripts côté serveur pour produire du contenu dynamique de page
web avant que la page ne soit envoyée au navigateur web de l’utilisateur.

4.1.1.7 Postman
Postman est une plateforme de collaboration pour le développement
d’API. Elle permet de construire, tester et documenter des API REST
et GraphQL via une interface graphique conviviale. Avec Postman, les
développeurs peuvent créer des collections de requêtes HTTP, automa-
tiser des tests, gérer des environnements variables et partager facilement
les scénarios de test et la documentation de leurs API avec leur équipe.

4.2 Architecture de l’application

Dans cette section, nous allons discuter de l’architecture de l’application. Nous expli-
querons la structure, le choix des technologies et leur fonctionnement.

45
Chapitre 4. Réalisation

Figure 4.1 : Architecture de l’application

Notre application de location de voitures est basée sur une architecture moderne à trois
niveaux, séparant clairement le frontend du backend et de la base de données :

4.2.1 Frontend (React.js)

Le frontend de notre application est développé avec React.js, une bibliothèque JavaS-
cript populaire pour la construction d’interfaces utilisateur. Nous utilisons également Re-
dux pour la gestion de l’état global de l’application, ce qui facilite la communication entre
les différents composants. L’interface utilisateur est conçue pour être intuitive, responsive
et agréable à utiliser sur différents appareils.

46
Chapitre 4. Réalisation

4.2.2 Backend (Express.js/Node.js)

Le backend est construit avec Express.js, un framework web minimaliste pour Node.js.
Il est responsable du traitement des requêtes, de l’authentification des utilisateurs, de la
gestion des données et de la communication avec la base de données. Nous avons organisé
notre backend selon le modèle MVC (Modèle-Vue-Contrôleur) pour une meilleure sépara-
tion des préoccupations et une maintenance plus facile.

4.2.3 Base de données (PostgreSQL)

Pour le stockage des données, nous avons choisi PostgreSQL, un système de gestion de
base de données relationnelle robuste et fiable. Notre schéma de base de données est conçu
pour gérer efficacement les informations sur les utilisateurs, les agences, les voitures, les
réservations, les paiements et autres entités importantes pour notre application.

4.2.4 Avantages de cette architecture

Cette architecture présente plusieurs avantages :

• Séparation des préoccupations : Chaque couche a une responsabilité distincte,

ce qui facilite la maintenance et l’évolution de l’application.

• Évolutivité : Les différentes couches peuvent être mises à l’échelle indépendamment

en fonction des besoins.

• Flexibilité technologique : Cette architecture nous permet d’adopter de nouvelles

technologies ou de remplacer des composants existants sans affecter l’ensemble du
système.

• Développement parallèle : Les équipes peuvent travailler simultanément sur dif-

férentes parties de l’application.

47
Chapitre 4. Réalisation

4.3 Organisation du code

Notre code est organisé selon une architecture moderne séparant clairement le frontend
du backend. Voici la structure exacte de notre projet :

4.3.1 Structure du Backend

backend/
config/ # Configuration de l’application
migrations/ # Migrations de base de données
models/ # Modèles de données PostgreSQL
node_modules/ # Dépendances Node.js
seeders/ # Scripts pour peupler la base de données
src/ # Code source principal
uploads/ # Fichiers téléchargés par les utilisateurs
.env # Variables d’environnement
package-lock.json # Verrouillage des versions des dépendances
package.json # Configuration du projet Node.js
README.md # Documentation du backend

Le backend est construit avec Express.js et suit une architecture modulaire. Les prin-
cipaux dossiers sont :

• config/ : Contient les fichiers de configuration pour la base de données, l’authenti-

fication, etc.

• models/ : Définit les modèles de données et leur structure dans PostgreSQL

• src/ : Contient les contrôleurs, routes et services de l’application

• migrations/ : Scripts pour gérer l’évolution de la structure de la base de données

• seeders/ : Scripts pour initialiser la base de données avec des données de test

48
Chapitre 4. Réalisation

4.3.2 Structure du Frontend

frontend/
node_modules/ # Dépendances Node.js
src/ # Code source principal de l’application React
.eslintrc.js # Configuration ESLint
.gitignore # Configuration Git
index.html # Point d’entrée HTML
package-lock.json # Verrouillage des versions des dépendances
package.json # Configuration du projet
postcss.config.js # Configuration PostCSS
README.md # Documentation du frontend
tailwind.config.js # Configuration Tailwind CSS
tsconfig.json # Configuration TypeScript
tsconfig.node.json # Configuration TypeScript pour Node
vite.config.ts # Configuration Vite

Le frontend est développé avec React.js et utilise plusieurs technologies modernes :

• Vite : Comme outil de build rapide et moderne

• TypeScript : Pour un typage statique et une meilleure robustesse du code

• Tailwind CSS : Pour le styling et une interface responsive

• ESLint : Pour maintenir une qualité de code consistante

Dans le dossier src/, nous avons organisé le code selon une architecture orientée com-
posants, avec des dossiers dédiés pour les pages, les composants réutilisables, les hooks
personnalisés, les services d’API, et la gestion d’état avec Redux.

49
Chapitre 4. Réalisation

4.4 Présentation des interfaces de la solution

Dans la section suivante, nous exposons des captures d’écran de la réalisation et quelques
interfaces de notre plateforme de location de voitures :

• Interface administrateur

• Interface agence

• Interface client

4.4.1 Interface administrateur

Nous allons maintenant montrer les interfaces principales de l’application pour les ad-
ministrateurs.

4.4.1.1 Interface de connexion

Cette interface permet de se connecter au platforme.

Figure 4.2 : Interface de connexion

50
Chapitre 4. Réalisation

4.4.1.2 Tableau de bord administratif

À partir de cette interface, l’administrateur peut voir les statistiques globales de la

plateforme.

Figure 4.3 : Tableau de bord administratif

4.4.1.3 Gestion des agences

À partir de cette interface, l’administrateur peut gérer toutes les agences enregistrées
sur la plateforme.

51
Chapitre 4. Réalisation

Figure 4.4 : Interface de gestion des agences

4.4.1.4 Gestion des plans d’abonnement

À l’aide de cette interface, l’administrateur peut créer et gérer les plans d’abonnement
disponibles pour les agences.

Figure 4.5 : Interface de gestion des plans d’abonnement

52
Chapitre 4. Réalisation

4.4.2 Interface agence

Nous présentons maintenant les interfaces principales pour les agences de location.

4.4.2.1 Tableau de bord agence

Cette interface permet à l’agence de voir les statistiques de son activité.

Figure 4.6 : Tableau de bord agence

4.4.2.2 Gestion des voitures

Cette interface permet à l’agence de gérer son inventaire de voitures.

53
Chapitre 4. Réalisation

Figure 4.7 : Interface de gestion des voitures

4.4.3 Interface client

Enfin, nous mettrons en évidence les interfaces principales pour les clients.

4.4.3.1 Page d’accueil

Cette interface est la page d’accueil de notre application où les clients peuvent recher-
cher des voitures disponibles.

54
Chapitre 4. Réalisation

Figure 4.8 : Page d’accueil

4.4.3.2 Recherche de voitures

Cette interface permet aux clients de rechercher des voitures disponibles selon différents
critères.

Figure 4.9 : Interface de recherche de voitures

55
Chapitre 4. Réalisation

4.4.3.3 Détails d’une voiture

Cette interface affiche les détails d’une voiture sélectionnée.

Figure 4.10 : Interface de détails d’une voiture

4.4.3.4 Création d’une réservation

Cette interface permet au client de réserver une voiture pour une période spécifique.

Figure 4.11 : Interface de création d’une réservation

56
Chapitre 4. Réalisation

4.4.3.5 Historique des réservations

Cette interface permet au client de consulter ses réservations passées et à venir.

Figure 4.12 : Interface d’historique des réservations

Conclusion
Au cours de ce chapitre, nous nous sommes particulièrement intéressés à la mise en
œuvre de notre plateforme de location de voitures. Nous avons d’abord présenté l’en-
vironnement de développement utilisé, incluant le matériel et les technologies logicielles
(React.js, Express.js, Node.js, PostgreSQL, etc.). Ensuite, nous avons détaillé l’architec-
ture de l’application, son organisation technique et son processus de développement. Enfin,
nous avons présenté les principales interfaces de notre plateforme pour les trois types d’uti-
lisateurs : administrateurs, agences et clients.
Cette plateforme de location de voitures offre une solution complète et intuitive pour
tous les acteurs impliqués dans le processus de location. Les administrateurs peuvent gérer
efficacement la plateforme, les agences peuvent gérer leur inventaire de voitures et leurs
réservations, tandis que les clients peuvent facilement rechercher, réserver et gérer leurs
locations de voitures.

57
Chapitre 4. Réalisation

Les technologies modernes que nous avons choisies nous permettent d’offrir une ex-
périence utilisateur fluide et réactive, tout en garantissant la robustesse et la sécurité de
l’application. L’architecture modulaire facilite la maintenance et l’évolution future de la
plateforme pour répondre aux besoins changeants du marché de la location de voitures.

58
CONCLUSION ET PERSPECTIVES

Conclusion générale
Ce projet de fin d’Année a conduit à la réalisation d’une plateforme de location de
voitures innovante permettant à trois types d’acteurs d’interagir efficacement : les clients,
les agences de location et les administrateurs. La plateforme offre aux clients une expérience
intuitive pour rechercher, comparer et réserver des véhicules selon leurs besoins spécifiques.
Les agences de location peuvent gérer leur inventaire de voitures, suivre les réservations
et optimiser leur activité grâce à des outils analytiques performants. Les administrateurs
disposent d’une vision globale de la plateforme et peuvent superviser les agences, gérer les
plans d’abonnement et assurer le bon fonctionnement du système.
L’utilisation de technologies modernes comme React.js, Express.js et PostgreSQL nous
a permis de développer une solution robuste, évolutive et offrant une expérience utilisateur
de qualité. L’architecture modulaire adoptée garantit la maintenabilité du code et facilitera
les évolutions futures de la plateforme.

Accomplissements personnels
Concernant l’aspect humain, ce projet nous a permis de mener un travail de déve-
loppement complet sur plusieurs mois en toute autonomie. Comme tout projet de cette
envergure, nous avons fait face à des difficultés variées qu’il fallait surmonter au fur et
à mesure. C’est un travail sculpteur de la personnalité et de la capacité à gérer les défis
professionnels.
Nous avons approfondi nos compétences techniques en apprenant à maîtriser des tech-
nologies que nous n’avions pas utilisées auparavant, notamment React.js avec TypeScript,
Tailwind CSS, Express.js, et PostgreSQL. Cette expérience nous a également permis de
comprendre l’importance d’une bonne architecture logicielle et d’une méthodologie de
développement structurée pour mener à bien un projet complexe.

59
CONCLUSION ET PERSPECTIVES

Perspectives
Nous avons réussi à réaliser une plateforme de location de voitures opérationnelle certes,
mais nous comptons l’améliorer encore plus. Les idées pour faire cela ne manquent pas,
comme :

• Implémenter un système de géolocalisation pour permettre aux clients de trouver des

voitures disponibles à proximité.

• Développer une application mobile native pour améliorer l’expérience sur les appareils
mobiles.

• Intégrer un système de recommandation intelligent pour suggérer des voitures adap-

tées aux préférences des clients.

• Ajouter des méthodes de paiement alternatives, y compris les cryptomonnaies.

• Mettre en place un système de notation et d’avis plus élaboré pour les voitures et les
agences.

• Utiliser des outils d’analyse big data pour explorer les comportements des utilisateurs
et optimiser l’expérience.

RÉFÉRENCES
[1]https ://www.uml.org [2]https ://www.sciencedirect.com/topics/computer-science/unified-
process [3]https ://developer.mozilla.org/fr/docs/Glossary/SPA [4]https ://reactjs.org/
[5]https ://redux.js.org/ [6]https ://expressjs.com/ [7]https ://www.postgresql.org/
[8]https ://www.typescriptlang.org/ [9]https ://tailwindcss.com/ [10]https ://vitejs.dev/

60