REPUBLIQUE TUNISIENNE

Ministère de l’Enseignement
Supérieur et de la
Recherche Scientifique

ÉCOLE SUPERIEURE PRIVÉE DE TECHNOLOGIE

& INGENIERIE

Cycle de Formation des Ingénieurs en Informatique

Développement d’une application de

location de voitures pour une agence

Elaboré Par
Eya ourteni
Feriel Rabah
Hiba Chebbi

Superviseur
Mme. Yosra Kassis

Année universitaire : 2023/20214

Table de matière
Introduction générale .................................................................................................... 7
Chapitre 1 : Cadre du projet .......................................................................................... 9
1. Etude de l’existant .................................................................................................... 9
1.1 Description de l’existant ..................................................................................... 9
1.2 Critique de l’existant .........................................................................................10
1.3 Solution envisagée ............................................................................................10
2. Méthodologie de travail ...........................................................................................11
2.2 Présentation de SCRUM .....................................................................................11
2.2 Les rôles SCRUM ...............................................................................................11
Conclusion .....................................................................................................................12
Chapitre 2 : Analyse et spécifications des besoins .....................................................13
1. Spécification des besoins ..........................................................................................13
1.1 Besoins fonctionnels ..........................................................................................13
1.2 Besoins non fonctionnels ...................................................................................13
2. Backlog produit .......................................................................................................14
3. Diagramme de cas d’utilisation général.......................................................................16
3.1 Identification des acteurs ...................................................................................16
3.2 Diagramme de cas d’utilisation ...........................................................................16
4. Environnement et outils de développement ................................................................17
5. L’architecture du système .........................................................................................19
5.1 Architecture MVC..............................................................................................20
Conclusion .....................................................................................................................21
Chapitre 3 : Sprint 1 .......................................................................................................22
1. La spécification fonctionnelle ....................................................................................22
1.1 Backlog sprint ...................................................................................................22
1.2 Diagramme de cas d’utilisation ...........................................................................23
1.3 Les maquettes ..................................................................................................26
2. La conception ..........................................................................................................28
2.1 Diagramme de classes........................................................................................28
2.2 Diagrammes de séquences ......................................................................................29
3. La réalisation ...........................................................................................................32
3.1 Interfaces liées au client .....................................................................................32
3.2 Interfaces liées à l’administrateur .......................................................................35
3.3 Interfaces liées au gestionnaire ...........................................................................36

2
 Conclusion .....................................................................................................................37
Chapitre 4 : Sprint 2 .......................................................................................................38
1. Spécification fonctionnelle ........................................................................................38
1.1 Backlog sprint ...................................................................................................38
1.2 Diagramme de cas d’utilisation ...........................................................................40
2. La conception ..........................................................................................................45
2.1 Diagramme de classes........................................................................................45
2.2 Diagrammes de séquences .................................................................................45
3. La réalisation ...........................................................................................................49
3.1 Interfaces liées au client .....................................................................................49
3.2 Interfaces liées à l’administrateur .......................................................................50
3.3 Interfaces liées au gestionnaire ...........................................................................52
Conclusion .....................................................................................................................53
Chapitre 5 : Sprint 3 .......................................................................................................54
1. Spécification fonctionnelle ........................................................................................54
1.1 Backlog sprint ...................................................................................................54
1.2 Diagramme de cas d’utilisation ...........................................................................55
2. La conception ..........................................................................................................57
2.1 Diagramme de classes........................................................................................57
2.2 Diagrammes de séquences .................................................................................57
3. La réalisation ...........................................................................................................58
Conclusion .....................................................................................................................59
Conclusion et perspective ............................................................................................60
Nétographie ...................................................................................................................61

3
 Liste des tableaux

Tableau 1 : Applications similaires 9

Tableau 2 : Backlog produit 15
Tableau 3 : Sprint backlog (Sprint1) 23
Tableau 4 : Description de use case « authentifier » 25
Tableau 5 : Description de use case « consulter voiture » 25
Tableau 6 : Description de use case « ajouter voiture » 25
Tableau 7 : Sprint backlog du sprint 2 39
Tableau 8 : Description textuelle du cas d’utilisation « gestion des comptes utilisateurs » 40
Tableau 9 : Description textuelle du cas d’utilisation « Réserver voiture » 41
Tableau 10 : Description textuelle du cas d’utilisation « gestion voitures » 42
Tableau 11 : Sprint backlog du sprint 3 55
Tableau 12 : Description textuelle du cas d’utilisation supprimer une réservation et
générer PDF 56

4
 Liste des figures
Figure 1 : Cycle de vie de SCRUM 12
Figure 2 : Diagramme de cas d’utilisation général 16
Figure 3 : Architecture MVC 21
Figure 4 : Diagramme de cas d’utilisation de sprint 1 24
Figure 5 : Maquette d’inscription 26
Figure 6 : Maquette d’authentification 27
Figure 7 : Maquette d’ajout d’une voiture 28
Figure 8 : Diagramme de classe du sprint 1 29
Figure 9 : Diagramme de séquence « authentification admin » 29
Figure 10 : Diagramme de séquence « authentification manager » 30
Figure 11 : DIAGRAMME de séquence « authentification client » 30
Figure 12 : Diagramme de séquence « ajout voiture » 31
Figure 13 : Diagramme de séquence « consulter voitures » 31
Figure 14 : Interface d’inscription client 32
Figure 15 : Interface d'authentification client 33
Figure 16 : Page d'accueil 34
Figure 17 : Interface de test d'authentification 35
Figure 18 : Interface d'authentification de l'administrateur 35
Figure 19 : Test d'authentification administrateur 36
Figure 20 : Interface d'ajout voiture 36
Figure 21 : Diagramme de cas d'utilisation du sprint 2 40
Figure 22 : Maquette consulter administrateur ou gestionnaire 42
Figure 23 : Maquette de modification administrateur ou gestionnaire 43
Figure 24 : Maquette consulter voiture 43
Figure 25 : Maquette modifier voiture 44
Figure 26 : Maquette réservation voiture 44
Figure 27 : Diagramme de classes du sprint 2 45
Figure 28 : Diagramme de séquence de consulter la liste des administrateurs 45
Figure 29 : Diagramme de séquence de modification d’un administrateur 46
Figure 30 : Diagramme de séquence de suppression d’un administrateur 46
Figure 31 : Diagramme de séquence de consulter la liste des voitures 47
Figure 32 : Diagramme de séquence de modification d’une voiture 47
Figure 33 : Diagramme de séquence de suppression d’une voiture 48
Figure 34 : Diagramme de séquence de réserver voiture 48
Figure 35 : Interface de détails d'une voiture 49
Figure 36 : Formulaire de réservation 49
Figure 37 : Interface du contrat 50
Figure 38 : Message affiché en cas ou la voiture est déjà réserver 50
Figure 39 : Liste des administrateurs 51
Figure 40 : Listes des gestionnaires 51
Figure 41 : Interface de modification d'un administrateur 52

5
Figure 42 : INTERFACE DE MODIFICATION D'UN gestionnaire 52
Figure 43 : Listes des voitures 53
Figure 44 : Interface de modification d'une voiture 53
Figure 45 : Diagramme de cas d'utilisation du sprint 3 55
Figure 46 : Maquette de gestion des réservations et contrats 56
Figure 47 : Diagramme de classe du sprint 3 57
Figure 48 : Diagramme de séquence de consulter liste des réservations et des contrats. 57
Figure 49 : Diagramme de séquence de suppression d’une réservation et son contrat 58
Figure 50 : Diagramme de séquence de générer PDF 58
Figure 51 : Interface de la liste des réservations et des contrats 59
Figure 52 : Rapport généré 59

6
 Introduction générale

Véritable catalyseur de la révolution numérique, le e-commerce redéfinit la

manière dont nous achetons et vendons dans un monde de plus en plus
connecté.
Le commerce électronique a connu une croissance fulgurante, tant en nombre
de sites Web ouverts qu’en nombre de visites sur ces sites. Les responsables de
ces emplacements doivent prendre des décisions architecturales importantes et
relever avec succès divers défis.
Le commerce électronique ne se limite pas aux transactions en ligne. Il s'agit d'un
mariage passionnant entre technologie et commerce qui simplifie nos vies et
élargit nos horizons commerciaux. Explorez les tenants et les aboutissants du
commerce électronique, des dernières tendances en matière de conception de
sites Web aux stratégies de marketing numérique qui captent l'attention des
consommateurs du monde entier.
Pour qu'un site Web de commerce électronique réussisse, il doit être sûr,
accueillant et accessible, tout en offrant de bons temps de réponse et en étant
capable de gérer les pics de trafic.
Dans le cadre de notre projet, nous nous intéressons au développement d'une
application web de location de voitures spécifique à une agence qui répondent
à des problématiques non-informatisées touchant les sociétés sans outils
informatiques.
Ce rapport se concentre sur les différents outils et concepts de développement
informatique mis en œuvre et décrit les étapes de recherche, d'analyse, de
conception et de développement de la solution d'informatisation proposée.
Pour atteindre cet objectif, nous abordons notre projet en utilisant la
méthodologie agile SCRUM et en adoptant UML comme langage de
modélisation.
Pour préparer ce rapport, nous l’avons divisé en cinq chapitres :
• Présentation du cadre du projet.
• Planification du projet
• Sprint 1

7
• Sprint 2
• Sprint 3
Pour mettre des mots sur notre projet, nous aimerions le présenter dans le
premier chapitre. Passez ensuite au chapitre 2, intitulé « Planification du projet
et spécification des besoins » dont nous allons discuter les exigences
fonctionnelles et non fonctionnelles du système, backlog produit, architecture
système et diagrammes de cas d’utilisation courants. Les 3 derniers chapitres de
ce travail sont « Sprint 1 », « Sprint 2 » et « Sprint 3 » qui contiennent leurs sprint
backlog, leurs maquettes, leurs conceptions, leurs interfaces réalisés.

8
 Chapitre 1 : Cadre du projet

Dans ce chapitre nous présenterons une étude préalable qui est une étape
essentielle afin d'analyser, d'évaluer et de critiquer des applications similaires
pour proposer une solution adaptée, ainsi que nous présenterons la
méthοdοlοgie adaptée pour effectuer cette application.
1. Etude de l’existant
L’étude de l’existant est une phase primordiale pour la réalisation d’un projet.
En effet elle consiste à observer et à analyser les solutions existantes puis à
déterminer leurs points faibles et leurs points forts afin de les prendre en
considération lors de la réalisation de l’application en question. Elle comporte
trois parties : description de l’existant, critique de l’existant et la solution
envisagée.
1.1 Description de l’existant
Il existe plusieurs solutions pour location de voitures en lignes. Nous citons
quelques applications parmi eux :

Nom Description
AVIS est une société internationale de location de voitures qui
opère dans de nombreuses régions du monde et propose des
services de location aux touristes et aux clients locaux.
Acteur majeur du secteur mondial de la location de voitures,
HERTZ se distingue par sa longue histoire d'innovation et son
service fiable. Connue pour sa présence mondiale, HERTZ propose
à ses clients une variété de choix de véhicules, allant des options
abordables aux véhicules de luxe, pour répondre à un large
éventail de besoins de voyage.
SIXT, société de location de voitures internationale renommée, se
caractérise par son engagement en faveur de l'innovation, de
l'élégance et de la flexibilité. Connu pour ses locations de véhicules
haut de gamme, SIXT offre à ses clients une expérience de
conduite supérieure dans une variété de véhicules allant des
berlines de luxe aux SUV élégants.
TABLEAU 1 : APPLICATIONS SIMILAIRES

9
 1.2 Critique de l’existant
Plusieurs applications fournissent des fonctionnalités et des solutions pour une
bonne gestion de location de voitures, mais malgré la présence évidente des
avantages pour ces différentes solutions, les inconvénients ne disparaissent pas.

• Hertz :
Interface complexe : certains utilisateurs signalent que l'interface du site Web
de Hertz peut parfois être complexe, rendant la navigation et les réservations
difficiles à utiliser.
Problèmes de réservation en ligne : des retours occasionnels font état de
difficultés à finaliser des réservations en ligne, avec des erreurs techniques ou
des interruptions.
• Sixt :
Manque de transparence des coûts : certains utilisateurs ont remarqué que les
informations sur le coût total, y compris les frais supplémentaires, ne sont pas
toujours clairement affichées lors de la réservation en ligne
• Avis :
Interface peu intuitive : certains clients ont exprimé des inquiétudes quant au
fait que l'interface du site Web d'Avis pourrait ne pas être intuitive et que la
navigation pourrait ne pas être fluide.
1.3 Solution envisagée
Face aux défis identifiés dans les solutions existantes de location de voitures en
ligne, la solution envisagée vise à introduire une plateforme novatrice avec une
interface utilisateur intuitive et transparente. Notre objectif est de simplifier le
processus de réservation en ligne en éliminant les interfaces complexes, de
garantir une transparence totale sur les coûts, et d'offrir une expérience
utilisateur fluide et agréable. En intégrant des fonctionnalités innovantes, telles
qu'une navigation simplifiée et des processus de réservation rationalisés, notre
solution ambitionne de répondre aux préoccupations des utilisateurs actuels
tout en offrant une alternative moderne et efficace dans le domaine de la
location de voitures en ligne.

10
 2. Méthodologie de travail
Au cours du développement des projets informatiques, il est indispensable de
respecter une démarche bien déterminée pour assurer un bon rendement de
développement en termes de qualité et de productivité. C’est pour cela que le
choix de la méthodologie en informatique est primordial. Les méthodologies de
développement suivent une séquence d’étapes ordonnées qui permet d’obtenir
un système informatique performant qui répond aux différents besoins des
utilisateurs dans des intervalles de temps.
2.2 Présentation de SCRUM
SCRUM est l’une des méthodes les plus utilisées pour la gestion des projets
informatiques. Son objectif est d’offrir plus de souplesse à l’équipe. Un projet
qui suit « SCRUM » comporte un « Product backlog » qui représente une liste
ordonnée des fonctionnalités à développer pour atteindre un objectif bien
déterminé. De son tour le « Product backlog » est divisé en un « sprint backlog »
qui est basé sur la division des flux de travail en « Sprint » qui est un intervalle
de temps généralement entre deux et quatre semaines. À la fin de chaque sprint
il y aura un livrable qui présente de son tour les fonctionnalités accomplies.
2.2 Les rôles SCRUM
Scrum à trois rôles :

• Scrum master : C’est le chef d’équipe qui assure la compréhension et

l’exécution de Scrum. Il contrôle l’équipe et organise le travail.
• Product Owner : C’est l’expert produit qui représente les parties
prenantes et peut être aussi le client, le propriétaire du projet, ou le chef
d’entreprise.
• Scrum Team : Est un groupe de membres qui travaille sur l’exécution du
produit (développeurs, programmeurs, designers...).

11
 FIGURE 1 : CYCLE DE VIE DE SCRUM

Conclusion
Dans ce premier chapitre, nous avons défini l’étude de l’existant afin de préciser
notre objectif à atteindre vers la fin accompagnée d’une solution proposée et le
choix de la méthodologie appliquée. Dans le chapitre qui suit, nous présenterons
l’analyse et la spécification des besoins.

12
 Chapitre 2 : Analyse et spécifications des besoins
Nous consacrons ce deuxième chapitre à la phase de spécification et d’analyse
des besoins.
1. Spécification des besoins
Dans cette partie, nous présentons l’ensemble des besoins auxquels doit
répondre notre système.
1.1 Besoins fonctionnels
Les besoins fonctionnels sont les fonctionnalités et les options que l’application
fournira à l’utilisateur.
Notre application fournira les fonctionnalités suivantes :

• Gestion des utilisateurs :

o Inscription du client
o Authentification
o Déconnexion
o Modification des données de administrateurs ou
gestionnaires
o Suppression d’un administrateur ou gestionnaires
• Gestion des voitures :
o Ajout voiture
o Modification d’une voiture
o Suppression d’une voiture
o Lister les voitures
• Gestion des réservations et des contrats :
o Passer une réservation
o Génération des contrats
o Lister les réservations et les contrats
o Suppression d’une réservation et d’un contrat
o Génération d’un fichier PDF pour un contrat
1.2 Besoins non fonctionnels
Les besoins non fonctionnels définissent les options internes essentielles pour
améliorer le fonctionnement du système. Pour cela notre application doit
répondre aux critères suivants :

13
 • Fiabilité : L’application doit toujours répondre à l’exigence afin de
fonctionner sans aucune erreur ou défaillance.
• La disponibilité : L’application doit être disponible à tout instant pour être
utilisée par n’importe quel utilisateur, elle doit être accessible facilement
via n’importe quel navigateur.
• Performance : Afin d’offrir un service de qualité, l’application doit être
performante au niveau de temps de réponse.
• Ergonomie : Les interfaces doivent être simple et conviviale.
• La sécurité : Les informations ne doivent pas être accessibles par tout le
monde.
2. Backlog produit
Avant de lancer le premier sprint, il est essentiel d’avoir un backlog du produit, c’est-à-
dire une liste hiérarchisée des fonctionnalités orientées vers les besoins du client. Le
backlog du produit est un élément permanent tout au long de la durée de vie du produit
et sert de feuille de route pour le développement du produit.
Pendant toute la durée du projet, le backlog du produit rassemble de manière
centralisée la liste de « tout ce qui peut être réalisé par l’équipe, classé par ordre de
priorité. » Il n’existe qu’un seul backlog du produit pour un produit donné.
Pour évaluer la complexité de nos histoires d’utilisateur, nous avons utilisé les échelles
suivantes :
• 2 : Facile
• 3 : Simple
• 5 et 8 : Modéré
• 13 : Difficile
• 21 : Très difficile
Le backlog du produit sert de référence pour la planification des sprints et la prise de
décisions concernant les fonctionnalités à développer en priorité. Il permet de garder
une vision d’ensemble du développement du produit tout au long de son cycle de vie.

Id Feature User story Priorité Complexité

1 En tant Moyenne 8
qu’utilisateur je
veux m’inscrire

14
2 En tant Haute 21
qu’utilisateur je
veux m’authentifier
3 En tant que Haute 5
gestionnaire je
Sprint 1 veux ajouter des
nouvelles voitures
4 En tant que client Haute 3
je veux consulter
les voitures
disponibles
5 En tant Moyenne 8
qu’administrateur,
je veux gérer les
comptes
utilisateurs
6 Sprint 2 En tant que client Moyenne 21
je veux réserver
une voiture
7 En tant que Moyenne 8
gestionnaire je
veux
supprimer/modifier
des voitures
8 En tant Faible 3
qu’utilisateur, je
veux me
déconnecter
9 En tant que Haute 21
gestionnaire je
veux gérer les
Sprint 3 réservations/les
contrats.
10 En tant que Moyenne 13
gestionnaire, je
veux générer des
rapports pour les
contrats.
TABLEAU 2 : BACKLOG PRODUIT

15
 3. Diagramme de cas d’utilisation général
3.1 Identification des acteurs
Un acteur définit un role jouet par une personne externe qui interagit avec le
système. Il peut être parmi les utilisateurs du système et parmi les
responsables de sa configuration.
Cette application est composée de 3 acteurs :

• L’administrateur : une personne en charge la gestion globale des

utilisateurs.
• Le gestionnaire : une personne qui gérer les voitures ; les réservations et
les contrats.
• Le client : une personne qui peut également visualiser des voitures et
réserver.
3.2 Diagramme de cas d’utilisation

FIGURE 2 : DIAGRAMME DE CAS D’UTILISATION GENERAL

16
4. Environnement et outils de développement
• HTML [1]

L’HTML est un langage informatique utilisé sur l’internet. Ce langage est

utilisé pour créer des pages web. L’acronyme signifie HyperText Markup
Language, ce qui signifie en français « langage de balisage d’hypertexte ».
Cette signification porte bien son nom puisqu’effectivement ce langage
permet de réaliser de l’hypertexte à base d’une structure de balisage.
• CSS [2]

Le terme CSS est l’acronyme anglais de Cascading Style Sheets qui peut se
traduire par « feuilles de style en cascade ». Le CSS est un langage
informatique utilisé sur l’internet pour mettre en forme les
fichiers HTML ou XML. Ainsi, les feuilles de style, aussi appelé les fichiers
CSS, comprennent du code qui permet de gérer le design d’une page
en HTML.

• JavaScript [3]

JavaScript (« JS » en abrégé) est un langage de programmation dynamique

complet qui, appliqué à un document HTML, peut fournir une interactivité
dynamique sur les sites Web.

17
 • JAVA [4]

Java est un langage de programmation et une plate-forme informatique

lancé en 1995. Il s’agit d’un langage orienté objet, basé sur des classes,
conçu pour être portable, ce qui signifie que le code de Java peut
fonctionner sur une grande variété de matériel et de systèmes
d’exploitation.

• XAMPP [5]

XAMPP est une distribution Apache entièrement gratuite et facile à installer

contenant MySQL, PHP et Perl. Le paquetage open source XAMPP a été mis
au point pour être incroyablement facile à installer et à utiliser.

• Spring boot [6]

Open source, Spring Boot est un framework de développement Java. Il

permet ainsi la création et le développement d’API. Sa principale originalité
réside dans le fait qu’il facilite considérablement ces capacités de
développement grâce à une réduction importante de la complexité des
configurations.

18
 • Thymeleaf [7]

Thymeleaf est un template engine (moteur de rendu de document) écrit en

Java. Principalement conçu pour produire des vues Web, il fournit un
support pour la génération de documents HTML, XHTML, JavaScript et CSS
(voire de n’importe quel format texte).

• Trello [8]

Trello est une application de gestion de projet gratuite qui permet

d’organiser ses projets sous forme de tableaux, eux-mêmes composés de
listes en colonnes, qui répertorient des tâches sous formes de cartes.

• StarUML

C’est un logiciel de modélisation UML (Unified Modeling Language) open

source qui peut remplacer dans bien des situations des logiciels
commerciaux et coûteux. Il est simple à utiliser ainsi qu’il nécessite peu de
ressource système
5. L’architecture du système
Il est indéniable que la sélection du modèle architectural joue un rôle crucial
dans la conception de systèmes informatiques. Une architecture bien choisie est
essentielle pour garantir un fonctionnement optimal du système, en prenant en
compte des éléments tels que les performances, la réutilisation du code et la

19
mise en réseau fiable avec d’autres systèmes. Dans ce contexte, notre choix se
porte sur le modèle MVC (Modèle-Vue-Contrôleur).
5.1 Architecture MVC
Le modèle MVC est un modèle architectural couramment utilisé dans le
développement de logiciels pour concevoir et organiser des systèmes
informatiques. Cette approche divise l’application en trois composants
principaux, chacun avec des responsabilités différentes.

• Modèle
Le modèle représente les données de l’application ainsi que la logique métier
associée. Il gère l’accès aux données, effectue les opérations de manipulation
des données, et notifie la vue des changements éventuels. En d’autres termes,
le modèle est responsable de la gestion des données et de la logique métier de
l’application.
• Vue
La vue est chargée de l’interface utilisateur et de l’affichage des données au
travers du modèle. Elle n’effectue aucune logique métier, se contentant de
présenter les informations au format approprié pour les utilisateurs. Lorsque le
modèle est mis à jour, la vue est notifiée et se met à jour en conséquence.
• Contrôleur
Le contrôleur fait office d’intermédiaire entre la vue et le modèle. Il reçoit les
entrées de l’utilisateur de la vue, interprète ces entrées, puis effectue les
opérations nécessaires sur le modèle. En retour, il peut également recevoir des
notifications du modèle et mettre à jour la vue en conséquence. Le contrôleur
gère la logique de flux de l’application.

20
 FIGURE 3 : ARCHITECTURE MVC

Conclusion
Dans ce chapitre, nous avons détaillé les exigences fonctionnelles et non
fonctionnelles du produit à réaliser, ainsi que nous avons parlé des différents
outils et technologies utilisées tout au long du projet. Ensuite, nous avons
terminés présenter l’architecture.

21
 Chapitre 3 : Sprint 1

Dans ce chapitre, nous détaillerons le premier sprint en évoquant l’analyse, la

conception et la réalisation pour aboutir à un incrément potentiellement
livrable.
1. La spécification fonctionnelle
Dans cette partie, nous élaborons le backlog du sprint, la conception dynamique,
les maquettes et les interfaces des sprints.
1.1 Backlog sprint

Tâches Sous-tâches Description Estimation

Backend Mettre en place le • Concevoir la 1 jours
modèle de structure de la base
données de données pour les
utilisateurs, les
voitures, etc.
• Créer les entités
Java
correspondantes.

Implémenter la • Créer des API 2 jours

gestion des pour l’ajout de
voitures nouvelles voitures.
• Mettre en place
la logique d’ajout de
voiture.

Configurer les • Créer des 3 jours

contrôleurs contrôleurs pour
gérer les pages web
(Thymeleaf).
Frontend Conception des • Créer les pages 4 jours
pages web pour
l’inscription et

22
 d’inscription et l’authentification des
d’authentification utilisateurs.
• Intégrer les
formulaires HTML.

Conception de la • Créer une page 2 jours

page de pour consulter les
consultation des voitures disponibles.
voitures • Afficher les
données
dynamiquement à
partir du backend.

Intégration des • Connecter les 2 jours

pages avec le pages web aux API
backend backend pour les
fonctionnalités
d’inscription,
d’authentification et
de consultation de
voitures.
Mise en forme et • Appliquer des 1 jour
stylisation styles CSS pour
améliorer l’aspect
visuel du site.

TABLEAU 3 : SPRINT BACKLOG (SPRINT1)

1.2 Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation du notre premier Sprint est présenté dans la
figure ci-dessous.

23
 FIGURE 4 : DIAGRAMME DE CAS D’UTILISATION DE SPRINT 1

Description de use case « authentifier » :

Cas d’utilisation S’authentifier

Acteurs Administrateur
Pré condition L’admin doit avoir un compte (login et
un mot de passe)
Post condition Quand la connexion est réussie,
l’admin est dirigé vers la page
d’accueil.
Scénario nominal : 1-l’utilisateur saisit ces données
2- système vérifie les coordonnées
saisies
3-l’utilisateur est redirigé vers la page
d’accueil.
Scénario alternatif : 4- Si les coordonnées saisies sont
incorrectes, un message d’erreur
s’affiche sur l’écran
L’enchainement démarre après 2 du
scénario normal

24
 5-le système va afficher en boucle la
page d’authentification et revient au
point 2 du scénario normal jusqu’à ce
que l’utilisateur réussisse
l’authentification.
TABLEAU 4 : DESCRIPTION DE USE CASE « AUTHENTIFIER »

Description de use case « consulter voiture » :

Cas d’utilisation Consulter les voitures

Acteurs Client
Pré condition Le client doit s’authentifier avant.
Post condition Le client visualise les voitures.
Scénario normal : 1-le système affiche l’interface d’accueil
où il y a une liste de voitures pour
locations.
TABLEAU 5 : DESCRIPTION DE USE CASE « CONSULTER VOITURE »

Description de use case « ajouter voiture » :

Cas d’utilisation Ajouter une annonce

Acteurs Gestionnaire
Pré condition Le gestionnaire s’authentifie.
Post condition L’annonce est enregistrée.
Scénario normal : 1-le système affiche le Dashboard de
manager
2-le gestionnaire accède au bouton
ajouter voiture
3-le système lui affiche le formulaire
d’ajout voiture
4-le mana gestionnaire remplie le
formulaire
5-le gestionnaire confirme l’ajout
6-afffichage de réussie ajout
TABLEAU 6 : DESCRIPTION DE USE CASE « AJOUTER VOITURE »

25
 1.3 Les maquettes

• Maquette d’inscription

FIGURE 5 : MAQUETTE D’INSCRIPTION

Cette maquette représente l’interface d’inscription. On a deux cas possibles :

- En cas de succès : l’utilisateur peut s’authentifier

- En cas d’échec :

Si le mot de passe n’est pas alphanumérique et ne contient pas au moins un

caractère spécial, un message d’erreur va être affiche
Si le username est déjà existant, un message d’erreur va être affiché.

26
 • Maquette d’authentification

FIGURE 6 : MAQUETTE D’AUTHENTIFICATION

Cette maquette représente l’interface d’authentification. On a deux cas

possibles :
- En cas de succès : l’utilisateur va être dirigé vers leur page dédié
- En cas d’échec :
Si le mot de passe ou le username ne sont pas correctes, un message d’erreur
va être affiché.

27
 • Maquette d’ajout d’une voiture

FIGURE 7 : MAQUETTE D’AJOUT D’UNE VOITURE

Cette maquette représente l’interface d’ajout de voiture. On a deux cas

possibles :
- En cas de succès : un message de succès va être affiché.
- En cas ou la matricule d’une voiture est déjà existante, un message
d’erreur va être affiché.
- En cas d’échec :
Données non enregistrées dans la base de données.
2. La conception
Nous allons présenter dans cette section le diagramme de classe du sprint 1 ,
ainsi que les diagrammes de séquences.
2.1 Diagramme de classes
La figure ci-dessous représente le diagramme de classe du sprint 1.

28
 FIGURE 8 : DIAGRAMME DE CLASSE DU SPRINT 1

2.2 Diagrammes de séquences

• Diagramme de séquence « authentification admin »

FIGURE 9 : DIAGRAMME DE SEQUENCE « AUTHENTIFICATION ADMIN »

29
• Diagramme de séquence « authentification manager »

FIGURE 10 : DIAGRAMME DE SEQUENCE « AUTHENTIFICATION MANAGER »

• Diagramme de séquence « authentification client »

FIGURE 11 : DIAGRAMME DE SEQUENCE « AUTHENTIFICATION CLIENT »

30
• Diagramme de séquence « ajout voiture »

FIGURE 12 : DIAGRAMME DE SEQUENCE « AJOUT VOITURE »

• Diagramme de séquence « consulter voitures »

FIGURE 13 : DIAGRAMME DE SEQUENCE « CONSULTER VOITURES »

31
 3. La réalisation
3.1 Interfaces liées au client
La figure 14 représente l’interface d’inscription dans laquelle le client doit saisir
ses informations dans les champs correspondant pour créer son compte. Une
fois qu’il a cliqué sur le bouton « SIGN UP », le système vérifie les données
entrées. En cas d’échec, il affiche un message d’erreur si le username est déjà
existant ou si le mot de passe n’est pas alphanumérique contenant 6 caractères
au moins avec un caractère spécial. Après avoir saisi les coordonnées
correctement le client obtient la page d’authentification (figure 15).

FIGURE 14 : INTERFACE D’INSCRIPTION CLIENT

32
La figure 15 représente l’interface d’authentification dans laquelle le client doit
saisir son username et le mot de passe dans les champs correspondant pour
accéder à l’accueil. Une fois qu’il a cliqué sur le bouton « SIGN IN », le système
vérifie les données entrées. En cas d’échec, il affiche un message d’erreur. Si le
username et le mot de passe sont acceptables, le système passe à la page
d’accueil. Après avoir saisi les coordonnées correctement le client obtient la
page d’accueil ou il trouvera une section qui présente les voitures louer. (Figure
16)

FIGURE 15 : INTERFACE D'AUTHENTIFICATION CLIENT

33
FIGURE 16 : PAGE D'ACCUEIL

34
La figure ci-dessous montre le message d’erreur en cas ou les données sont
erronées.

FIGURE 17 : INTERFACE DE TEST D'AUTHENTIFICATION

3.2 Interfaces liées à l’administrateur

L’administrateur peut notamment s’authentifier via cette interface

FIGURE 18 : INTERFACE D'AUTHENTIFICATION DE L'ADMINISTRATEUR

35
En cas d’échec, un message d’erreur va être afficher.

FIGURE 19 : TEST D'AUTHENTIFICATION ADMINISTRATEUR

NB : Le même design graphique est appliqué pour l’interface d’authentification

du gestionnaire.
3.3 Interfaces liées au gestionnaire
Une fois authentifier, le gestionnaire va être rediriger vers son dashboard ou il
peut naviguer vers l’interface d’ajout d’une voiture.

FIGURE 20 : INTERFACE D'AJOUT VOITURE

36
Conclusion
Tοut au lοng de ce chapitre, nous avons présenté les différentes user stοries du
sprint 1, la cοnceptiοn, les maquettes et les interfaces. Dans le chapitre suivant,
nous présentons les mêmes étapes pour le sprint 2.

37
 Chapitre 4 : Sprint 2

Dans ce chapitre, nous détaillerons le deuxième sprint en évoquant l’analyse, la

conception et la réalisation pour aboutir à un incrément potentiellement
livrable.
1. Spécification fonctionnelle
Dans cette partie, nous élaborons le backlog du sprint, la conception dynamique,
les maquettes et les interfaces des sprints.
1.1 Backlog sprint
Tâches Sous-tâches Description Estimation
Backend Implémentation • Vérifier et ajuster 2 jours
de la gestion des la configuration
comptes existante.
utilisateurs • Mettre à jour les
services et les
repositories.
• Implémenter les
Endpoint pour lire,
mettre à jour et
supprimer des
utilisateurs.

Mise en place de • Implémenter les 5 jours

la réservation de Endpoint pour la
voiture réservation de
voiture.
• Assurer la gestion
des disponibilités
des voitures.

Mise à jour de la • Ajouter les 2 jours

gestion des fonctionnalités de
suppression et de

38
 voitures par le modification des
gestionnaire voitures dans le
backend.
Frontend Mise à jour de la • Vérifier et ajuster 3 jours
page la configuration
d'administration frontend existante.
des comptes • Mettre à jour les
utilisateurs pages Thymeleaf.
• Mettre en place
les contrôleurs
frontend pour
interagir avec les
services backend.
• Afficher la liste
des utilisateurs et
permettre la
modification et
suppression
d'utilisateurs.

Mise à jour de la • Mettre à jour les 2 jours

gestion des pages Thymeleaf
voitures par le pour permettre au
gestionnaire gestionnaire de
gérer les voitures.

Mise en forme et • Appliquer des 1 jour

stylisation styles CSS pour
améliorer l'aspect
visuel du site.

TABLEAU 7 : SPRINT BACKLOG DU SPRINT 2

39
 1.2 Diagramme de cas d’utilisation
La figure ci-dessous représente le diagramme de cas d’utilisation du sprint 2.

FIGURE 21 : DIAGRAMME DE CAS D'UTILISATION DU SPRINT 2

Description textuelle du cas d’utilisation « gestion des comptes utilisateurs » :

Cas d’utilisation Gestion des utilisateurs

Acteurs Administrateur
Pré condition L’administrateur s’authentifie.
Post condition L’admin gère les utilisateurs
Scénario nominal : 1-l'administrateur choisit
"administrateur", "gestionnaire".
2-le système affiche la page demandée.
3-l'administrateur choisit l’opération à
effectuer (modifier, supprimer)
4-l'administrateur saisit les nouvelles
informations nécessaires en cas de
modification.
5-le système enregistre les informations.

TABLEAU 8 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « GESTION DES COMPTES

UTILISATEURS »

40
Description textuelle du cas d’utilisation « Réserver voiture » :

Cas d’utilisation Réservation de voiture

Acteurs Client
Pré condition Le client doit s’authentifie.
Post condition Voiture réservée
Scénario nominal : 1-le système affiche l’interface d’accueil
ou il dispose toutes les voitures
disponibles.
2-le client clique sur voir détail.
3-s'il apprécie la voiture il va passer à
“book”
4-ce bouton va lui afficher un formulaire
de location ou il doit remplir les champs
selon ces besoins
5-le client confirme la réservation
6-affichage d’un contrat disposant de
détails de réservation
Scenario alternatif : 5.1 si la voiture choisit n’est pas disponible
pour la période demandée par le client
un message d’erreur affichée au client
TABLEAU 9 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « RESERVER VOITURE »

Description textuelle du cas d’utilisation « gestion voitures » :

Cas d’utilisation Gestion des voitures

Acteurs Gestionnaire
Pré condition Le gestionnaire doit s’authentifie.
Post condition Le gestionnaire gère les voitures
Scénario nominal : 1-le système affiche le Dashboard de
manager
2-le gestionnaire peut choisir entre listes
des voitures ou ajouter voiture

41
 2.1- dans le cas où il choisit la liste des
voitures il peut modifier ou supprimer une
voiture.
2.2-s’il choisit d’ajouter une voiture il va
remplir le formulaire d’une voiture.
3-chaque changement au niveau des
annonces va être enregistrer dans la base.

TABLEAU 10 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION « GESTION VOITURES »

1.3 Les maquettes

• Les maquettes de gestion des utilisateurs
L’administrateur peut également lister les administrateurs. (La même chose
pour les gestionnaires).

FIGURE 22 : MAQUETTE CONSULTER ADMINISTRATEUR OU GESTIONNAIRE

En cliquant sur l’icône “PEN”, l’administrateur va être dirigé vers un formulaire

pour l’édition d’un admin en récupérant les anciennes données. (La même
chose pour les gestionnaires).
En cliquant sur l’icône “trash”, l’utilisateur va être supprimé.

42
 FIGURE 23 : MAQUETTE DE MODIFICATION ADMINISTRATEUR OU GESTIONNAIRE

• Les maquettes de gestion des voitures

Le gestionnaire peut également lister les voitures. En cliquant sur l’icône “PEN”,
le gestionnaire va être dirigé à un formulaire pour l’édition d’une voiture en
récupérant les anciennes données.
En cliquant sur l’icône “trash”, la voiture va être supprimé.

FIGURE 24 : MAQUETTE CONSULTER VOITURE

43
 FIGURE 25 : MAQUETTE MODIFIER VOITURE

• Les maquettes de réservation de voiture

FIGURE 26 : MAQUETTE RESERVATION VOITURE

44
 2. La conception
Nous allons présenter dans cette section le diagramme de classe du sprint 2, ainsi
que les diagrammes de séquences.
2.1 Diagramme de classes
La figure ci-dessous représente le diagramme de classes du sprint 2.

FIGURE 27 : DIAGRAMME DE CLASSES DU SPRINT 2

2.2Diagrammes de séquences
• Diagramme de séquence de consulter la liste des administrateurs

FIGURE 28 : DIAGRAMME DE SEQUENCE DE CONSULTER LA LISTE DES ADMINISTRATEURS

45
 • Diagramme de séquence de modification d’un administrateur

FIGURE 29 : DIAGRAMME DE SEQUENCE DE MODIFICATION D’UN ADMINISTRATEUR

• Diagramme de séquence de suppression d’un administrateur

FIGURE 30 : DIAGRAMME DE SEQUENCE DE SUPPRESSION D’UN ADMINISTRATEUR

NB : La même logique est appliquée pour la gestion des gestionnaires.

46
• Diagramme de séquence de consulter la liste des voitures

FIGURE 31 : DIAGRAMME DE SEQUENCE DE CONSULTER LA LISTE DES VOITURES

• Diagramme de séquence de modification d’une voiture

FIGURE 32 : DIAGRAMME DE SEQUENCE DE MODIFICATION D’UNE VOITURE

47
• Diagramme de séquence de suppression d’une voiture

FIGURE 33 : DIAGRAMME DE SEQUENCE DE SUPPRESSION D’UNE VOITURE

• Diagramme de séquence de réserver voiture

FIGURE 34 : DIAGRAMME DE SEQUENCE DE RESERVER VOITURE

48
 3. La réalisation
3.1 Interfaces liées au client
Lorsque le client clique sur le bouton "VIEW DETAILS" qui se trouve dans la carte
de présentation d’une voiture dans la page d’accueil (Figure 16), il va être diriger
vers cette interface qui affiche les détails de la voiture sélectionnées.

FIGURE 35 : INTERFACE DE DETAILS D'UNE VOITURE

En cas ou le client veut réserver cette voiture, il clique sur le bouton "Book" pour
qu’il soit dirigé vers un formulaire de réservation en précisant la date de début
de réservation et la date de fin comme le montre la figure ci-dessous.

FIGURE 36 : FORMULAIRE DE RESERVATION

49
Une fois le client a confirmé sa réservation en cliquant sur le bouton "Add
rental", le système génèrera un contrat et affichera ces détails. (Figure 36)

FIGURE 37 : INTERFACE DU CONTRAT

En cas ou la voiture est déjà réserver dans les dates sélectionnées par le client,
le système affichera une page contenant ce message. (Figure 37)

FIGURE 38 : MESSAGE AFFICHE EN CAS OU LA VOITURE EST DEJA RESERVER

3.2Interfaces liées à l’administrateur

Une fois connecté, l’administrateur va être rediriger vers son dashboard. En
cliquant sur "Admins", le système affichera la liste des administrateurs
enregistrés dans la base de données.

50
 FIGURE 39 : LISTE DES ADMINISTRATEURS

En cliquant sur "Managers", le système affichera la liste des gestionnaires

enregistrés dans la base de données.

FIGURE 40 : LISTES DES GESTIONNAIRES

En cliquant sur l’icône "PEN" qui se trouve dans la colonne "actions" du tableau,
l’administrateur va être dirigé vers la page de modification des données d’un
administrateur sélectionné ou d’un gestionnaire. (Les anciennes données vont
être récupérées)

51
 FIGURE 41 : INTERFACE DE MODIFICATION D'UN ADMINISTRATEUR

FIGURE 42 : INTERFACE DE MODIFICATION D'UN GESTIONNAIRE

3.3 Interfaces liées au gestionnaire

Une fois connecté, le gestionnaire va être rediriger vers son dashboard. En
cliquant sur "List cars", le système affichera la liste des voitures enregistrés
dans la base de données.

52
 FIGURE 43 : LISTES DES VOITURES

En cliquant sur l’icône "PEN" qui se trouve dans la colonne "actions" du tableau,
le gestionnaire va être dirigé vers la page de modification des données d’une
voiture sélectionné. (Les anciennes données vont être récupérées)

FIGURE 44 : INTERFACE DE MODIFICATION D'UNE VOITURE

Conclusion
Tοut au long de ce chapitre, nous avons présenté les différentes user stοries du
sprint 2, la conception, les maquettes et les interfaces. Dans le chapitre suivant,
nous présentons les mêmes étapes pour le sprint 3.

53
 Chapitre 5 : Sprint 3

Dans ce chapitre, nous détaillerons le premier sprint en évoquant l’analyse, la

conception et la réalisation pour aboutir à un incrément potentiellement
livrable.
1. Spécification fonctionnelle
1.1 Backlog sprint
Dans cette partie, nous élaborons le backlog du sprint, la conception dynamique,
les maquettes et les interfaces des sprints.

Tâches Sous-tâches Description Estimation

Backend Développement de • Créer une API de 1 jours
l'API de déconnexion déconnexion pour
gérer la déconnexion
de l'utilisateur.
Gestion des • Mettre en place les 4 jours
réservations/contrats Endpoint API
nécessaires pour
gérer les
réservations/contrats.
• Implémenter la
logique backend pour
la création, la
modification et la
suppression des
réservations/contrats.

Génération de • Développer les 2 jours

rapports fonctionnalités
backend pour générer
des rapports basés
sur les contrats.
• Intégrer la logique
nécessaire pour
extraire les données

54
 pertinentes des
contrats.

Frontend Interface de gestion • Développer des pages 6 jours

des d'interface utilisateur
réservations/contrats pour permettre au
gestionnaire de gérer
les
réservations/contrats.
• Intégrer les appels
API appropriés pour
récupérer, afficher,
modifier et supprimer
les
réservations/contrats.
Page de génération • Intégrer les appels 1 jours
de rapports API nécessaires pour
récupérer les
données et générer
les rapports à
afficher.
TABLEAU 11 : SPRINT BACKLOG DU SPRINT 3

1.2 Diagramme de cas d’utilisation

FIGURE 45 : DIAGRAMME DE CAS D'UTILISATION DU SPRINT 3

55
 • Description textuelle du cas d’utilisation supprimer une réservation et
générer PDF
Cas d’utilisation Gestion des réservations et des contrats
Acteurs Gestionnaire
Pré condition Le gestionnaire doit s’authentifier
Post condition Réservation/contrat modifiés ou
supprimés
Scénario nominal : 1-le système affiche le Dashboard de
manager.
2-le gestionnaire choisit la section
"rentals".
3-Le système affichera la liste des
réservations.
3.1- dans le cas où il clique sur l’icône
"TRASH", une réservation est supprimée
ainsi que son contrat.
3.2-dans le cas où il veut générer un
fichier PDF du contrat, il clique sur l’icône
"PDF".
4-chaque changement au niveau des
annonces va être enregistrer dans la base.
TABLEAU 12 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION SUPPRIMER UNE RESERVATION
ET GENERER PDF

1.3 Les maquettes

• Maquette de gestion des réservations et contrats

FIGURE 46 : MAQUETTE DE GESTION DES RESERVATIONS ET CONTRATS

56
2. La conception
Nous allons présenter dans cette section le diagramme de classe du sprint 3, ainsi
que les diagrammes de séquences.
2.1 Diagramme de classes

FIGURE 47 : DIAGRAMME DE CLASSE DU SPRINT 3

2.2Diagrammes de séquences
• Diagramme de séquence de consulter liste des réservations et des
contrats

FIGURE 48 : DIAGRAMME DE SEQUENCE DE CONSULTER LISTE DES RESERVATIONS ET DES

CONTRATS.

57
 • Diagramme de séquence de suppression d’une réservation et son contrat

FIGURE 49 : DIAGRAMME DE SEQUENCE DE SUPPRESSION D’UNE RESERVATION ET SON

CONTRAT

• Diagramme de séquence de générer PDF

FIGURE 50 : DIAGRAMME DE SEQUENCE DE GENERER PDF

3. La réalisation
Le gestionnaire peut notamment consulter la liste des réservations. Cette liste
contiendra aussi le numéro de contrat.
En cas de suppression d’une réservation, son contrat associé va être supprimer
automatiquement.

58
 FIGURE 51 : INTERFACE DE LA LISTE DES RESERVATIONS ET DES CONTRATS

Pour générer un fichier PDF contenant toutes les informations nécessaires d’une
réservation, le gestionnaire doit juste cliquer sur l’icône "PDF " . Le navigateur va
lui ouvrir le fichier directement.

FIGURE 52 : RAPPORT GENERE

Conclusion
Tοut au long de ce chapitre, nous avons présenté les différentes user stοries du
sprint 4, la conception, les maquettes et les interfaces de ces user stοries.

59
 Conclusion et perspective
Au cours de ce projet, nous avons étudier un secteur d’activité très intéressant,
c’est celui du service de location des voitures en ligne. L’objectif escompté par
ce présent travail est de concevoir, de développer un site web pour une agence
de location des voitures en ligne.
En achevant ce rapport, il est indispensable de signaler les aspects bénéfiques
de ce projet :

• Sur le plan méthodologique, il a permis de mieux maitriser le langage de

modélisation UML.
• Sur le plan pratique, nous avons été confrontés à la gestion d’un projet
depuis la phase d’analyse jusqu’à I ’implémentation en passant par la
conception et la réalisation.
• Sur le plan personnel, l'apport de ce travail a été d'une importance
considérable, puisque nous avons acquis un ensemble de compétences
précieuses, tant sur le plan théorique que pratique, en nous familiarisant
avec le développement web, en découvrant de nouveaux outils et en
appliquant la méthοdοlοgie agile Scrum.
Dans le cadre de perspective, nous envisageons à améliorer notre application
en donnant au client la possibilité d’annuler ses réservations en lignes.

60
 Nétographie
[1] http://glossaire.infowebmaster.fr/html/
[2] http://glossaire.infowebmaster.fr/css/
[3]https://developer.mozilla.org/fr/docs/Learn/Getting_started_with_the_
web/JavaScript_basics
[4] https://appmaster.io/fr/blog/quest-ce-que-java-definition-signification-
caracteristiques
[5] https://www.apachefriends.org/fr/index.html
[6] https://easypartner.fr/blog/quest-ce-que-java-spring-boot/
[7] https://gayerie.dev/docs/spring/spring/thymeleaf.html
[8] https://www.blogdumoderateur.com/tools/trello/

61