Rapport de PFE - Safa BENABDESSADOK

République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université Constantine 2 - Abdelhamid Mehri -
Faculté des Nouvelles Technologies de l’Informatique et de la Communication

Département des Technologies des Logiciels et Systèmes d’Information
Projet de fin d’études pour l’obtention du diplôme de Licence en Informatique
Option : Génie Logiciel
Thème
Conception et réalisation d’un système intelligent pour la
gestion d’une agence de location des véhicules

GoRent
Réalisé par : Dirigé par :

• BENABDESSADOK Safa - Dr LACHEHEUB Mohammed Nassim
• DAOUDI Souheib
• MANSOURI Kaouther Soundous
- Session Juin 2022 -

- Remerciements -
La présentation de ce modeste travail nous offre l’occasion d’exprimer notre profonde grati-
tude à Monsieur le professeur Lacheheub Mohammed Nassim d’avoir bien voulu diriger ce travail,
pour le temps qu’il a consacré pour nous orienter.Ses nombreux conseils ne nous ont jamais fait
défaut.
Nous remercions également :

Les membres du jury d’avoir accepté de juger ce travail, et pour les critiques instructives
qu’ils apporteront qui nous permettrons d’évoluer et ainsi de proposer à l’avenir des projet plus
sophistiquées .
- Dédicaces -
A tous les enseignants qui ont contribué à notre formation, pour toutes les connaissances
qu’ils nous ont prodiguées
Nous sommes également redevables à nos parents, frères, sœurs et amis, dont le soutien,
l’optimisme et la confiance qu’ils témoignent nous ont portée tout au long de nos études
A tous ceux qui nous ont soutenus durant tout notre cursus universitaire, et nous sou-
tiennent encore
Table des matières
Introduction Générale 1
I Inception et Elaboration 2
1 Analyse des besoins 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Le processus Unifié (UP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Cahier de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Cahier de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.3 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.2 Les Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.3 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Maquettes IHM, fiches descriptives et diagramme de séquence système . . . . . . . 16
1.6.1 Maquettes IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6.2 Les fiches descriptives et les diagrammes de séquence système . . . . . . . . 21
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2 Conception 47
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2 Modèle de domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2.1 Identification des entités du système et les relations entre elles . . . . . . . 47
2.2.2 Description des éléments de diagramme de classe . . . . . . . . . . . . . . . 48
2.2.3 Diagramme de classe domaine . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3 Diagramme de classe conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.3.1 Identification des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.3.2 Diagramme de classe conception . . . . . . . . . . . . . . . . . . . . . . . . 50
2.4 Schéma de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.4.1 Passage du modèle du domaine au modèle relationnel . . . . . . . . . . . . 53
2.4.2 La normalisation de la base de données . . . . . . . . . . . . . . . . . . . . 54
2.4.3 Schéma de la base de données sous forme diagramme . . . . . . . . . . . . . 54
2.5 Daigramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
II Construction et Transition 58
3 Implimentation 59
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2 Patrons de conception (Design Pattern) . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3 Présentation de l’environnement de travail . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.1 Langages Utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
i
3.3.2 Plateformes Logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.3 Plateformes Matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.3.4 Services Web utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4 Développement d’application sécurisée . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.2 Two Factors authentification . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4.3 permission classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4.4 Cryptage base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5 Développement de l’intelligence artificielle . . . . . . . . . . . . . . . . . . . . . . . 65
3.5.1 Pourquoi utiliser l’intelligence Artificielle : . . . . . . . . . . . . . . . . . . . 65
3.5.2 Fonctionnalités développée . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5.3 Domaines de développementt . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5.4 Bibliothèques utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6 Présentation des interfaces graphique . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6.2 Interface d’accueil - Home Page - . . . . . . . . . . . . . . . . . . . . . . . . 68
3.6.3 Interface de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.6.4 Interface fiche technique du véhicule . . . . . . . . . . . . . . . . . . . . . . 70
3.6.5 Interface payement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6.6 Interface de signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.6.7 Interface de validation de la réservation . . . . . . . . . . . . . . . . . . . . 73
3.6.8 Interface d’affichage du Contrat et Facture de la location . . . . . . . . . . 74
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Conclusion Générale 75
III Annexe 77
Annexe 78
ii
Table des figures
1.1 Les Phases et les intérations d’UP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Daigramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Diagramme de contexte statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Daigramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Daigramme de cas d’utilisation en paquet . . . . . . . . . . . . . . . . . . . . . . . 13
1.6 Diagramme de cas d’utilisation en paquet ≪ paquet Garagiste ≫ . . . . . . . . . . 13
1.7 Diagramme de cas d’utilisation en paquet ≪ paquet Admin ≫ . . . . . . . . . . . . 14
1.8 Diagramme de cas d’utilisation en paquet ≪ paquet Locataire ≫ . . . . . . . . . . . 14
1.9 Diagramme de cas d’utilisation en paquet ≪ paquet Profil ≫ . . . . . . . . . . . . . 15
1.10 Diagramme de cas d’utilisation en paquet ≪ paquet Propriétaire ≫ . . . . . . . . . 15
1.11 Diagramme de cas d’utilisation en paquet ≪ paquet Secritaire ≫ . . . . . . . . . . . 16
1.12 La maquette de la page d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.13 La maquette de la page d’accueil de site . . . . . . . . . . . . . . . . . . . . . . . . 17
1.14 Les maquettes des pages de processus de loaction d’un vehicule . . . . . . . . . . . 18
1.15 La maquette de gestion des vehicules . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.16 La maquette gestion des utilisateurs de système . . . . . . . . . . . . . . . . . . . . 19
1.17 La maquette d’affichage de contrat . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.18 La maquette de la page de consultation des statistiques . . . . . . . . . . . . . . . 20
1.19 La maquette de la page d’etablir état de véhicules . . . . . . . . . . . . . . . . . . 21
1.20 Diagramme de séquence système de cas d’utilisation ≪Gérer les utilisateurs≫ . . . 24
1.21 Diagramme de séquence système de cas d’utilisation ≪Modifier l’état de réservation≫ 26
1.22 Diagramme de séquence système de cas d’utilisation ≪Etablire liste des exclus≫ . . 28
1.23 Diagramme de séquence système de cas d’utilisation ≪Conduire le véhicule≫ . . . . 30
1.24 Diagramme de séquence système de cas d’utilisation ≪Louer véhicule≫ . . . . . . . 32
1.25 Diagramme de séquence système de cas d’utilisation ≪Signaler les problèmes avec
le véhicule≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.26 Diagramme de séquence système de cas d’utilisation ≪Signature de contrat≫ . . . . 36
1.27 Diagramme de séquence système de cas d’utilisation ≪Consulter liste véhicules dis-
ponible≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.28 Diagramme de séquence système de cas d’utilisation ≪Gérer les reclamations≫ . . . 40
1.29 Diagramme de séquence système de cas d’utilisation ≪Payer≫ . . . . . . . . . . . . 43
1.30 Diagramme de séquence système de cas d’utilisation ≪Renouveler contrat≫ . . . . 45
2.1 Le modele de domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.2 Diagramme de class de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3 Diagramme de class de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4 Diagramme de schéma de base de données . . . . . . . . . . . . . . . . . . . . . . . 55
2.5 Daigramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.1 Architechtre du MVT () . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2 différence ML et DL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.3 interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.4 interface de la page d’accueil de site . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5 interface de la page de recher d’un véhicule selon les critères d’entrée . . . . . . . 69
3.6 Interface de fiches technique d’un véhicule . . . . . . . . . . . . . . . . . . . . . . . 70
3.7 interface de payement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.8 interface e-signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
iii
3.9 interface de validation de la location . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.10 Interface de Contrat et facture relatif à la location . . . . . . . . . . . . . . . . . . 74
3.11 fractions de l’implémentation de la reconnaissance faciale . . . . . . . . . . . . . . 78
3.14 implémentation du modèle de DL de reconnaissance des signaux routiers . . . . . 81
3.15 fractions de l’implémentation de la prédiction des signaux routiers . . . . . . . . . 82
3.16 fractions de l’implémentation des fonctions tiers de la reconnaissance des signaux
routiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.17 fractions de l’implémentation reconnaissance de textes . . . . . . . . . . . . . . . . 84
iv
Liste des tableaux
1.1 La table des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Les acteurs de système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Fiche descriptive de cas d’utilisation ≪Gérer les utilisateurs≫ . . . . . . . . . . . . 21
1.4 Fiche descriptive de cas d’utilisation ≪Valider réservation≫ . . . . . . . . . . . . . 25
1.5 Fiche descriptive de cas d’utilisation ≪Etablire liste des exclus≫ . . . . . . . . . . . 27
1.6 Fiche descriptive de cas d’utilisation ≪Conduire le véhicule≫ . . . . . . . . . . . . 29
1.7 Fiche descriptive de cas d’utilisation ≪Louer un véhicule≫ . . . . . . . . . . . . . . 31
1.8 Fiche descriptive de cas d’utilisation ≪Signaler un problème avec véhicule≫ . . . . 33
1.9 Fiche descriptive de cas d’utilisation ≪Signature de contrat≫ . . . . . . . . . . . . 35
1.10 Fiche descriptive de cas d’utilisation ≪Consulter liste véhicules≫ . . . . . . . . . . 37
1.11 Fiche descriptive de cas d’utilisation ≪Gérer réclamations≫ . . . . . . . . . . . . . 39
1.12 Fiche descriptive de cas d’utilisation ≪Payer≫ . . . . . . . . . . . . . . . . . . . . . 41
1.13 Fiche descriptive de cas d’utilisation ≪Renouveler le contrat≫ . . . . . . . . . . . . 44
v
Introduction Générale
La location de voitures est un commerce en pleine croissance, car elle permet au locataire de
vivre l’expérience de la conduite du véhicule sans pour autant s’engager à long terme, mais aussi elle
permet de répondre à des situations exceptionnelle ou le déplacement est crucial. Certains sondages
indiquent même le décroı̂t du marché de l’achat avec au contraire une augmentation exponentielle
de celui de la locations, ce qui nous indique l’existence d’un réel intérêt et une demande réel pour
ce secteur.
Cependant ce modèle économique prometteur est victime de son propre succès, la compétitivité
des différentes agences augmente jour après jour ; mais la gestion traditionnelle de ce secteur l’affecte
énormément et parfois l’emmène jusqu’à un point de stagnation ou il est impossible de continuer
à développer l’activité tout en conservant les critères de qualité existant.
En effet, en suivant le schéma de gestion traditionnelle il faut utiliser des formulaires en
papier pour les clients, les contrats, les archives et pour le stockage de tout anciennes opérations
ou transactions, ce qui rend le travail désagréable et très lent.
Pour pouvoir se développer une agence de location doit répondre à des critères de qualité.
En effet elle doit être à la fois sur, accueillante et disponible, mais également offrir un temps de
réponse excellent tout en conservant l’exactitude des traitements.
Malheureusement L’humain ayant ses limites et ne pouvant être parfait surtout dans des
condition ou la charge est importante ces critères sont parfois surréaliste et impossible à réaliser, il
est nécessaire donc d’informatiser cette gestion, en utilisant les concepts moderne de l’informatique.
Toute réflexion logique nous mènera tout naturellement à nous poser la question suivante :
comment peut-on informatiser le système existant de gestion des agences de location pour faciliter
ce processus ?
Entrant dans l’ère de l’intelligence artificielle, cette dernière peut s’avérer très utile dans
la gestion de ce marché et son développement. En effet l’automatisation des différentes tâches
secondaires, le traitement et la gestion des données récupérée, l’utilisation des différent techniques
de reconnaissances...etc nous permettra d’attendre plus facilement les critères de qualité et les
objectifs de développement de l’agence, sans pour autant augmenter la charge de travail sur l’effectif
humaine existante.
Notre projet consiste à concevoir une application intelligente de location de véhicules. Nous
souhaitons proposer une solution de gestion des clients, des véhicules et des contrats d’une agence
de location. Cette application offre les fonctions standards de fonctionnement d’une agence de
location, tout en intégrant quelques principes de l’intelligence artificielle.
Chapitre 01 : Analyse des besoins
L’objet de ce chapitre est d’identifier les exigences du projet et faire le point sur les éléments
attendus à partir des besoins exprimé par le client.
Chapitre 02 : Conception
Ce chapitre vise à représenter l’ensemble d’activités qui permettent de comprendre le problème
posée théoriquement et envisager toutes les choix possibles afin d’appliquer la solution la plus
optimale qui répondra a tous les besoins identifié.
Chapitre 03 : implémentation
Dans ce chapitre on s’intéressera au déroulement des actions logiques qui suivent la réflexion
menée durant les premières de développement et qui permettent la réalisation et exécution du
projet. Au bout de ce dernier nous obtiendrons le produit souhaité
1
Première partie
Inception et Elaboration
CHAPITRE 1. ANALYSE DES BESOINS
Chapitre 1
Analyse des besoins
1.1 Introduction
Dans ce chapitre, nous allons fair un analyse de domaine d’application de notre système, puis
nous définissons la problématique et le cadre de projet. En suite, nous commancons la spécification
des besoins puis la description textuelles et graphiques des cas d’utilisation.
1.2 Le processus Unifié (UP)

Le processus Unifié (UP, en englais Unified Process) est un processus de développement logiciel,
ce processus englobe plusieurs caractéristiques (Itératif, Centré sur une architecture, Piloté par les
cas d’utilisation, et piloté par les risques). cette processus gérer le cycle de développement de
logiciel comme un projet ayant quatre phase(Inception, Élaboration, Construction, Transition) et
dans chaque phase en applique les cinq activité d’UP (Recueil des besoins, Analyse, Conception,
Implémentation, et Tests)
Figure 1.1 – Les Phases et les intérations d’UP

[?]
Selon UP, Nous faisons une planification de cycle de développement de notre projet comme
montre la table et le diagramme de GANTT qui suive :
3
Num tâche Tâche Durée Prédécesseurs

1 Établissement cahier de charge 3 jours
2 Inception (Lancement) 6 jours 1
3 Analyse le domaine 2 jours
4 Définition de la problématique et de l’objectif 1 jour 3
5 Définition du besoins fonctionnels et non fonctionnels 3 jours 4
6 Élaboration 11 jours 2
7 Établissement de modèle de domaine 6 jours
8 Établissement diagrammes de classes conception 5 jours 7
9 Établissement diagramme d’activité 5 jours 7
10 Construction 55 jours 6
11 Élaboration de la base de données 6 jours
12 Front end 21 jours
13 Back end 42 jours 11
14 Modèle 35 jours 13
15 View 35 jours 14
16 API 8 jours
17 IA 9 jours 15
18 Test 7 jours 17
19 Transition 7 jours 10
Table 1.1 – La table des tâches
4
Figure 1.2 – Daigramme de GANTT
5
1.3 Expression des besoins

1.3.1 Cahier de charge
1.4 Expression des besoins

1.4.1 Cahier de charge
1. Contexte et définition du projet
A. Activités
L’entreprise GoRent crée le 13/02/2022, qui a pour activité principale la location de
différents catégories de véhicules Voitures, Motos, Utilitaire , Bus avec un large choix
de type dans chaque catégorie ( par exemple la catégorie voiture se divise en plusieurs
types SUV (Sport Utility Vehicules), monospaces, coupés, cabriolet, sport... la catégorie
utilitaire se divise aussi en plusieurs types légers, camionnette.. )
L’entreprise GoRent propose aussi de nombreux services tel que des services de locations
de véhicules, service d’aide a la conduite, service de reconnaissance faciale...
L’entreprise GoRent base son développement en premier lieu sur un plan national
(Algérie) et dans ce domaine aucune concurrence réel de ce type n’existe encore. Donc
l’entreprise se considère comme novatrice dans la façon d’agir dans ce domaine.
B. Projet
L’entreprise actuellement demande le développement de sa première application web, le
trafic attendue est a peu prés de 5%. Cette application Web a été créé le 27/02/2022,
sa mise a jour se fera sous forme de mise a jour et maintenance.
L’objectif cette application web est majoritairement de augmenter le trafic de l’entre-
prise, générer des ventes, devenir plate-forme compatible...
La cible ce l’entreprise sont toute personne ayant un permis de conduire de plus de 2ans
et ayant plus de 23ans, et aussi les entreprises ayant de besoins de véhicules pour une
période déterminée
2. Périmètre du projet
L’entreprise propose un large catalogue de produit et de services( environ 500 véhicules
proposée). qui seront disposée sur un ensemble de 20 pages et/ou chapitres
La concurrence au niveau nationale se base sur un mode de traitement traditionnelle et non
informatisé des requêtes des clients
Cependant des système similaire opèrent sur le niveau international les leader de ce marché
sont notaient Booking, RentCar, Sixth, Hertz
3. Enveloppe budgétaire
L’estimation budgétaire totale donnée par l’entreprise est de 200 000.00 DA pour les en-
semble fonctions attendue de l’application.
4. Engagement et délais
La date de réception du projet est définie sur le 12 juin 2022. les étapes de développement
qui permettrons le suivi et la bonne compréhension du projet serons discutée ultérieurement.
Les livrables demandée sont :
• Un calendrier prévisionnel avec les étapes
• Les fiches de programmation et les fichier exécutable
• Les fichier de graphisme
• Les base de données associée
• Documents technique qui regroupe l’ensemble des informations du site( hébergement,
fonctionnement, identifiants d’accès ...)
5. Description fonctionnelle
Les caractéristiques techniques et les fonctionnalités particulières de l’application qui de-
vront être inclus sont :
• Des espaces membres
• Un moteur de recherche interne
• Une gestion automatique des mises à jour
• Une interface de mise à jour du site
6
La gestion quotidienne de l’application web est une des responsabilité de l’administrateur .

Concernant la mise a jour et maintenance une équipe sera assignée pour garantir le suivi et
le développement.
1.4.2 Identification des acteurs

Problématiques :
- Comment faciliter et automatiser la gestion de location des véhicules d’une agence de loca-
tion des véhicules ?
- Comment rendre le système intelligent ?
Objectif :
- Satisfaire les locataire
- Augmenter le nombre de locataire
- Faciliter le travail de l’agence
- Garantir une bonne utilisation des véhicules
Les acteurs :
Les acteurs modélisent les rôles du les entités externes au systéme qu’ils interagent avec le
système. Notre application contient neuf (9) acteurs, sont :
acteur Type Rôle

Internaute Principal Représente le visiteur de l’application (site)
Utilisateur Principal Représente tout les personnes inscrite dans le système
Secrétaire Principal Représente le responsable de la gestion des locations
Chauffeur Principal Représente le personne qu’il conduit le véhicule
Locataire Principal Représente le client qui besion de louer un véhicule, il peut entre
un personne ou une entreprise
Garagiste Principal Représente le responsable de la gestion de dépôt
Propriétaire Secondaire Représente le propriétaire de l’agence (propriétaire de
l’application)
Admin Secondaire Représente l’administrateur de l’application
Véhicule Principal Représente le système responsable de déclencher la reconnaissance
facial et de pannaux
La modélisation de la communication de le systeme avec les acteures externe de système avec

un diagramme de contexte statique :
1.4.3 Identification des besoins

Domaine : location , transport
Concept :
- Les informations de marché de location de véhicule
- Les informations des utilisateurs du système (locataire, chauffeur, administrateur, pro-
priétaire, secrétaire, garagiste, ...)
- Les informations des véhicules
- La facturation et les modalités de paiement
- Les informatios sur les routes, code de routes, reconnaissance des panneaux de signalisation
- Localisation
- Electricité et mécanique des véhicules
7
Figure 1.3 – Diagramme de contexte statique
Système existants :
- GPS : (Global Positioning System) est un système utilisé pour la position géographique
- Google Maps : est un service gratuit de carte géographique et de plan en ligne. Le service
a été créé par Google.[?]
- Rentcars : Outil de comparaison des différentes offres de location de véhicules, disponible
pour 160 pays
- Bookingcar :
Booking : Entreprise néerlandaise qui propose des hébergements dans différents types
de propriétés (Leader Mondiale)
Booking Car : (comparateur de prix) service additionnelle a l’outil Booking, propose
différente offres de location de véhicules ( par différentes agence Sixth, Hertz ...)
- Sixth : entreprise allemande de location de voitures, fondée en 1912 opère sur plus de 110
pays majoritairement en Amérique et Europe
- Hertz : société Américaine de location de voitures, exploite prés de 12000 succursales et
franchises au niveau national et international ( Amériques, Europe , Asie)
Point négatifs de ces systèmes existants :
• Entreprises focalisé sur la location de voitures majoritairement avec des catalogues réduit
pour les autres types et catégories de véhicules, et options facultatifs
• Activité inexistante sur le plan nationale (Algérie)
• Application développée pour faciliter le processus de location pour l’utilisateur seulement,
et ne s’intéressent pas sur la gestion administrative des agences/ franchises
• Application ne traitant pas le coté suivi après location ( une fois la location réservée, l’agence
s’occupe du reste/ méthode de travail traditionnelle)
• Suivi durant période de location inexistant ( une fois le locataire a pris possession du
véhicule, il n’y a aucun moyen de suive l’état de ce dernier et on doit se fier au propos
du locataire après restitution )
• Utilisation des système de gestion intelligent inexistante ( certain outils utilisent quelques
principes de intelligence artificielle que pour la recommandation )
1.5 Spécification des besoins

Les besoins d’un système sont les propriètés que le système doit respecter. On a deux type de
besoins :
1.5.1 Les besoins fonctionnels

Les besoins fonctionnels sont les fonctionnalité de système. Notre système a les besions fonc-
tionnels suivent :
- Chaque utilisateur gérer son profil
- Le propriétaire gérer les réclamation des locataires
- Le propriétaire peut consulter les statistiques et modifier les prix de location et les salaire
des employés.
8
- L’administration et la secrétaire peuvent ajouter et supprimer des véhicules dans les par-
kings.
- Le propriétaire établissent la liste des chauffeur bloqués.
- La secrétaire peut valider réservations.
- Le système établit les factures.
- L’administrateur peut gérer les utilisateurs du système.
- Locataire loue un véhicule et identifier le chauffeur.
- Locataire renouvele contrat de location.
- Locataire et le chauffeur signé des contrats de location.
- La secrétaire peut ajouter et supprimer les locataires.
- Locataire paye une location.
- Locataire consulter facture.
- Les utilisateurs faire une réclamation au propriétaire.
- Le chauffeur peut signaler les problèmes avec le véhicule.
- Le garagiste établit l’état des véhicules.
- Le garagiste gère le parking.
- L’administrateur gère les utilisateurs du système.
- L’administrateur gère les états de système.
- Tous les internautes peuvent consulter la liste de véhicules disponible.
- Les internautes peuvent s’inscrire dans le système comme des locataires ou chauffeurs.
1.5.2 Les Besoins non fonctionnels

Les besoins non fonctionnels sont des contraintes sur le système comme des besoins de perfor-
mance, sécurité, matériels... . Les besions non fonctionnels de notre système sont :
- Fiabilité et l’utilisabilité.
- La disponibilité (24/2 et 7/7).
Ö
- PLH 24 > PLJ
- Système sécurisé
- La prolongation de contrat de location à condition de ne pas dépasser le délai définie pour
la prolongation (1 jour).
- Tous les véhicules sont identifiés avec un code QR.
- Tous les contrats et les factures sont identifiés avec un code QR.
- Reconnaissance faciale et reconnaissance des panneaux de signalisation sur la route.
- Confirmer les informations de chauffeur depuis la photo de son permis.
- Compatible avec tous les écrans (Responsive).
- Les promotions
- Locataire peut retourner le véhicule à un parking différent de celui ou il a été prise.
1.5.3 Diagramme de cas d’utilisation

Les cas d’utilisation représentent les fonctionnalité de systéme. Alors, chaque cas d’utlisation
est une suite d’actions réalisé par le systeme en enteraction avec les acteurs de systeme.
Diagramme de cas d’utilisation Global :
9
Figure 1.4 – Daigramme de cas d’utilisation
10
Description des Cas d’utilisation identifiée :

Consulter les Contrats : permet au locataire de consulter son historique de location, en af-
fichant ses contrat.
Consulter Facture : permet au locataire de consulter les détails de facturation associée à

chaque location.
Authentification : permet a un internaute de d’accéder à son compte et ainsi bénéficier des

action permise relatif à son type de compte.
S’inscrire : permet à un internaute anonyme de s’identifier .
Consulter Liste Véhicule disponible : action permise pour tous les utilisateurs du système
sans distinction , permet de consulter le catalogue de véhicule qu’offre l’agence.
Gérer son Profil : permet à un locataire authentifié de gérer les information associé a son
compte.
Poser Question : permet à l’utilisateur du système de poser un questionnement concernant

le fonctionnement de l’application web.
Signaler les problèmes du véhicule : permet au chauffeur de signaler des potentiel défaillances
dans le véhicules louée, ces dernières seront ensuite vérifiée par le garagiste.
Faire Réclamation : permet au locataire d’exprimer un mécontentement, qui sera pris en

charge par le propriétaire .
Louer Véhicule : permet à un locataire de louer un véhicule disponible dans le catalogue de

l’agence.
Payer : action de payement du montant de la facture, peut se faire par différente méthodes
(carte, chèque, liquide) .
Renouveler le contrat : Permet à un locataire de renouveler une location en cours, doit se

faire avant un certain délais imposée.
Consulter les réservations : Permet au locataire de consulter les location à venir qu’il a fait.
Gérer parking : action de gestion des véhicules dans une location définie, exercée par le ga-
ragiste.
Valider réservation : permet à la secrétairerie après réception de la demande de location

d’accepter cette dernière.
Gérer les locataire et les chauffeurs : Gestion des locataires dans le système effectuée par
la secrétaire.
Établir liste des exclus : permet de bloquer des comptes de locataires bannis du site , suite
à des comportement inadmissible.
Gérer les véhicules : action partagé entre le propriétaire et la secrétaire, permet la gestion
des différent véhicules dont l’agence dispose.
Consulter les statistiques : Le propriétaire peut consulter les différents statistiques relatif
à l’activité de son agence.
Modifier prix : permet au propriétaire de modifier le prix d’un véhicule , ce prix sera appli-
cable qu’après la fin de la location en cours.
11
Gérer réclamations : La gestion par le propriétaire des réclamations faites par les locataires.
Gérer Q & A : permet à l’administrateur la gestion des questions posée par les internautes.
Gérer les utilisateurs : permet a l’administrateur de gérer les différents utilisateurs du système
(Propriétaire, Secrétaire, Garagiste ...etc)
Gérer état du système : gestion globale du système.
Conduire le véhicule : L’action de conduite du véhicule louée.
Identifier Chauffeur : Permet au locataire de type entreprise, d’identifier la personne qui se

chargera de conduire le véhicule durant la location.
12
Diagramme de cas d’utilisation en paquet

Les paquetes dans UML permet de grouper les éléments de modélisation. Donc,pour organiser
les cas d’utilisation on les regrouper par acteur et obtient le daigramme suivent :
Figure 1.5 – Daigramme de cas d’utilisation en paquet
Le contenu de chauque paquet :
Figure 1.6 – Diagramme de cas d’utilisation en paquet ≪ paquet Garagiste ≫
13
Figure 1.7 – Diagramme de cas d’utilisation en paquet ≪ paquet Admin ≫
Figure 1.8 – Diagramme de cas d’utilisation en paquet ≪ paquet Locataire ≫
14
Figure 1.9 – Diagramme de cas d’utilisation en paquet ≪ paquet Profil ≫
Figure 1.10 – Diagramme de cas d’utilisation en paquet ≪ paquet Propriétaire ≫
15
Figure 1.11 – Diagramme de cas d’utilisation en paquet ≪ paquet Secritaire ≫
1.6 Maquettes IHM, fiches descriptives et diagramme de

séquence système
1.6.1 Maquettes IHM
Ces maquettes répresente la page d’accueil de site et la page d’inscription pour les internautes
Figure 1.12 – La maquette de la page d’inscription
16
Figure 1.13 – La maquette de la page d’accueil de site
17
Les maquettes suivante présentent le processus de loaction d’une vehicule le cas de l’exemple
est une voiture
(b) La maquette de la page d’affichage des

(a) La maquette de la page d’affichage des information de le vehicule, le prix et la lo-
catigories un type de vehicules calisation de garage
(c) La maquette de les formulaires pour les

information de chauffeur et de paiement
Figure 1.14 – Les maquettes des pages de processus de loaction d’un vehicule
18
La maquette suivante répresente la page de gestion des vehicules pour l’administrateur et

secrétaire
Figure 1.15 – La maquette de gestion des vehicules
La maquette suivante répresente les pages de gestion des utilisateurs de système pour l’admi-
nistrateur
(a) La maquette de consulter liste d’utilisateurs
(b) La maquette d’ajouter un utilisateur
Figure 1.16 – La maquette gestion des utilisateurs de système
19
Cette maquette présente la page d’affichage de contrat pour la secrétaire
Figure 1.17 – La maquette d’affichage de contrat
Cette maquette présente la page de consultation des statistiques pour le proprietaire
Figure 1.18 – La maquette de la page de consultation des statistiques
20
La maquette suivante represente la page d’etablir état de véhicules pour le garagiste
Figure 1.19 – La maquette de la page d’etablir état de véhicules
1.6.2 Les fiches descriptives et les diagrammes de séquence système

Les fiches descriptives est représentation textuelle de l’interactions entre les acteurs et le
système et le diagramme de séquence système est son modélisation avec UML
Cas d’utilisation ≪ Gérer les utilisateurs ≫
Nom du cas Gérer les utilisateurs

Type Principal
Acteurs Admin
Acteur Se- /
condaire
Objectif Permet l’ajout, la suppression, la modification, et l’affichage des compte des uti-
lisateur de système (Propriétaire, locataire, chauffeur, Garagiste, et Secrétaire)
Précondition la liste des compte d’utilisateur de système est affichée ou un compte d’utili-
sateur est ajouté ou est supprimé ou est modifié.
Postcondition la liste des compte d’utilisateur de système est affichée ou un compte d’utili-
sateur est ajouté ou est supprimé ou est modifié.
Scénario no-
minal 1. L’administrateur de système cliquez sur gérer les comptes d’utilisateur
2. Le système demande de choisir une fonctionnalité (ajouter, supprimer,
modifier, afficher)
3. L’administrateur choisit une fonctionnalité (A1) (A2) (A3) (A4)
21
Scénarios A1 : L’administrateur choisit d’ajouter un compte d’utilisateur. L’en-

alternatifs chaı̂nement démarre après le point 3 de la séquence nominale.
3.1. Le système demande de remplir le formulaire pour ajouter un
utilisateur.
3.2. L’administrateur remplit le formulaire.
3.3. Le système valide les entrées (A1.1) (E1)
3.4. Le système ajoute le compte de l’utilisateur aux comptes d’utili-
sateurs.
3.5. Le système affiche que le compte de l’utilisateur est ajouté avec
succès.
A1.1 : Le système ne valide pas les entrées. L’enchaı̂nement démarre
après le point 3.3 du scénario alternatif (A1). Si le nombre de foix d’essai de
valider les entrées < 3.
3.3.1. Le système affiche que les entrées ne sont pas valides.
3.3.2. Le séquence alternatif (A1) reprend au point 3.
A2 : L’administrateur choisit de supprimer un compte d’utilisateur.
L’enchaı̂nement démarre après le point 3 de la séquence nominale.
3.1. Le système affiche la liste des comptes d’utilisateur.
3.2. Le système demande de choisir un compte.
3.3. L’administrateur choisit un compte.
3.4. Le système demande la confirmation de la suppression de ce
compte.
3.5. L’administrateur confirme l’opération. (E2)
3.6. Le système supprime le compte d’utilisateur.
3.7. Le système affiche que le compte d’utilisateur est supprimé.
A3 : L’administrateur choisit de modifier un compte d’utilisateur.
3.2. Le système demande de choisir un compte.
3.3. L’administrateur choisit un compte.
3.4. Le système affiche toutes les informations du compte choisi.
3.5. L’administrateur modifie les informations modifiables.
3.6. Le système valide la modification. (A3.1) (E3)
3.7. Le système enregistre les informations modifiées.
3.8. Le système affiche que la modification de compte d’utilisateur est
fait avec succès.
A3.1 : Le système ne valide pas la modification. L’enchaı̂nement démarre
après le point 3.6 de la scénario alternatif (A3). Si le nombre de foix d’essai de
valider la modification < 3.
3.6.1. Le système affiche que les entrées pour la modification ne sont
pas valides.
3.6.2. Le séquence alternatif (A3) reprend au point 3.4.
A4 : L’administrateur choisit d’afficher les comptes d’utilisateurs.
3.2. Le système demande de choisir un filter
3.3. L’administrateur choisit un filtre.
3.4. Le système affiche la liste des comptes d’utilisateurs selon le filtre
choisi par l’administrateur.
22
Scénarios E1 : La 3éme fois le système ne valide pas les entrées. L’enchaı̂nement

d’excep- démarre après le point 3.3 de la scénario alternatif (A1).
tions 3.3.1. Le système affiche que l’opération est annulée.
3.3.2. Le système annule l’opération.
E2 : L’administrateur ne confirme pas l’opération. L’enchaı̂nement
démarre après le point 3.5 de scénario alternatif (A2)
3.5.1. Le système affiche un message disant que l’opération est annulée.
E3 : La 3éme fois le système ne valide pas la modification. L’en-
chaı̂nement démarre après le point 3.6 de la scénario alternatif (A3).
3.6.1. Le système affiche que l’opération est annulée.
23
Figure 1.20 – Diagramme de séquence système de cas d’utilisation Gérer les utilisateurs≫
≪
24
Cas d’utilisation ≪ Modifier l’état de réservation ≫ :
Nom du cas Valider réservation

Type Principal
Acteurs Secrétaire
Acteur Se- Locataire
condaire
Objectif Permet de valider que le locataire payé le montant du loyer sur place .
Précondition - Authentification
- Locataire selectionne la methode de paiment sur place
Postcondition L’état de réservation du locataire et les information de paiement sont modifiés.
Scénario no-
minal 1. Le secrétaire demande de valider réservation.
2. Le système affiche la liste des réservations qu’elles ne sont pas encore
son montant est paid et demande de choisir une.
3. Le secrétaire choisit une réservation.
4. Le système affiche les informations de la réservation.
5. Secrétaire vérifier les informations de la réservation.
6. Secrétaire valide la reservation. (E1)
7. Le système enregistre les modifications.
8. Le système affiche que les modification sont enregistre.
9. Le système notifie le locataire.
Scénarios /
alternatifs
Scénarios E1 : Secrétaire ne valide pas. L’enchaı̂nement démarre après le point 6 de
d’excep- la séquence nominal.
tions 6.3.1. Le système affiche que l’opération est annulée.
25
Figure 1.21 – Diagramme de séquence système de cas d’utilisation Modifier l’état de

≪
réservation≫
26
Cas d’utilisation ≪ Etablire liste des exclus ≫ :
Nom du cas Etablire liste des exclus

Type Principal
Acteurs Propriétaire
Acteur Se- /
condaire
Objectif supprimer des chauffeurs et locataires de la liste d’exclus.
Précondition Authentification
Postcondition la liste des exclus est mise a jour
Scénario no-
minal 1. Propriétaire demande d’établir la liste des exclus
2. Le système affiche la liste des exclus
3. Propriétaire décide de supprimer de la liste d’exclus.
4. Le système demande de sélectionner les chauffeurs ou locataires qu’il
veut supprimer de la liste d’exclus. (E2)
5. Propriétaire sélectionne les chauffeurs et locataires qu’il veut débloquer.
6. Le système demande confirmation.
7. Propriétaire confirme. (E1)
8. Le système enregistre la liste d’exclus.
9. Le système affiche le message dit que l’établissement est fait avec succès.
Scénarios /
alternatifs
Scénarios E1 :Propriétaire ne confirme pas. L’enchaı̂nement démarre après le point
d’excep- 7 de la séquence nominale.
tions 7.1. Le système affiche que l’opération est annulée.
7.2. Le système annule l’opération.
E2 : Le Propriétaire décide de supprimer de la liste d’exclus et la liste
est vide L’enchaı̂nement démarre après le point 4 de la séquence nominale.
4.1. Le système affiche que l’opération est annulée.
27
Figure 1.22 – Diagramme de séquence système de cas d’utilisation Etablire liste des exclus≫
≪
28
Cas d’utilisation ≪ Conduire le véhicule ≫ :
Nom du cas Conduire le véhicule

Type Principal
Acteurs système de le véhicule
Acteur Se- Chauffeur
condaire
Objectif Permet de reconnaı̂tre le chauffeur pour démarrer le véhicule, et reconnaı̂tre
les panneaux de signalisation sur la route pour limiter la vitesse.
Précondition Locataire fait une location et identifie ce chauffeur
Postcondition le chauffer peut conduire la véhicule et le système enregistre les infractions de
chauffeur.
Scénario no-
minal 1. Le chauffeur demande de démarrer le véhicule.
2. Le système reconnaı̂t le chauffeur. (E1)
3. Le système permet au chauffeur de démarrer le véhicule
4. Le chauffeur démarre le véhicule.
5. Le système reconnaı̂t les panneaux. (A1)
6. Le chauffeur décide d’arrêter.
7. Le système arrête le véhicule.
Scénarios A1 : Le système détecte que la vitesse est supérieure à celle limitée.

alternatifs L’enchaı̂nement démarre après le point 5 de la séquence nominale.
5.1. Le système limite la vitesse.
5.2. Le système enregistre infraction.
5.3. Le séquence nominale reprend au point 4.
Scénarios E1 : Le système ne reconnaı̂t pas le chauffeur. L’enchaı̂nement démarre

d’excep- après le point 2 de la séquence nominale.
tions 6.1. Le système affiche que l’opération est annulée.
29
Figure 1.23 – Diagramme de séquence système de cas d’utilisation Conduire le véhicule≫

≪
30
Cas d’utilisation ≪ Louer véhicule ≫ :
Nom du cas Louer un véhicule

Type Principal
Acteurs Locataire
Acteur Se- Sécretaire
condaire
Objectif Faire une location d’un ou plusieurs véhicule
- Consulter la liste des véhicules
Postcondition Demande de location doit être enregistré
Scénario no-
minal 1. Locataire demande de louer un véhicule.
2. Le système faire appel au cas ≪consulter liste des véhicules≫
3. locataire choix un véhicule.
4. Le système afficher la localisation du garage correspondant
5. Le système demande de choisir les accesoires supplémentaires
6. locataire choisi les utiles supplémentaires (A1)
7. Le système calculer et afficher le prix total
8. Le système demande de remplir les informations du chauffeur
9. Le système vérifie et valide les informations du chauffeur (A2)
10. Le système appel au cas ≪ payer≫
11. Le système demande de confirmer la location
12. locataire confirmer son location (E1)
13. Le système enregistre la réservation.
14. Le système affiche les informations de réservation
Scénarios A1 : locataire choix aucun utiles supplémentaires. Ce scénario débute

alternatifs à partir du point 6 du scénario nominale
6.1. Le système enregistre que locataire choisi aucune utile.
A2 : système ne valide pas les informations du chauffeur. Ce scénario
débute à partir du point 11 du scénario nominale
11.1. Le système demande au locataire de remplir un autre fois les
informations du chauffe
Scénarios E1 : locataire ne confirme pas la réservation du véhicule. Ce scénario

d’excep- débute à partir du point 14 du scénario nominale
tions 14.1. le système annule l’opération
31
Figure 1.24 – Diagramme de séquence système de cas d’utilisation Louer véhicule≫

≪
32
Cas d’utilisation ≪ Signaler les problèmes avec le véhicule ≫ :
Nom du cas Signaler un problème avec véhicule

Type Principal
Acteurs Chauffeur
Acteur Se- /
condaire
Objectif Faire un déclaration d’un problème avec le véhicule en temps de la réservation
- Location d’un véhicule
Postcondition Le problème doit être enregistré
Scénario no-
minal 1. chauffeur cliquer sur signaler un problème
2. système demande de remplir les informations du problème
3. chauffeur remplir les informations
4. système demande de confirmation les informations
5. chauffeur confirme les informations de problème (E1)
6. système valide et enregistre le problème (A1)
7. système affiche un message d’enregistrement.
Scénarios A1 : le système ne valide pas les informations du problème. Ce scénario

alternatifs débute à partir du point 6 du scénario nominale
6.1. le système affiche que les informations du problème ne sont pas
valide.
A2 : système ne valide pas les informations du chauffeur. Ce scénario
débute à partir du point 12 du scénario nominale
12.1. Le système demande au locataire de remplir un autre fois les
informations du chauffe
Scénarios E1 : le chauffeur ne confirme pas la déclaration du problème. Ce

d’excep- scénario débute à partir du point 5 du scénario nominale.
tions 5.1. système affiche message d’annulation
5.2. le système annuler l’opération
33
Figure 1.25 – Diagramme de séquence système de cas d’utilisation Signaler les problèmes avec
≪
le véhicule≫
34
Cas d’utilisation ≪ Signature du contrat ≫ :
Nom du cas Signature de contrat

Type Principal
Acteurs - Chauffeur
- Locataire
Acteur Se- Secrétaire
condaire
Objectif Permet d’attester la validité du contrat et concrétise l’accord des parties sur
les termes et condition d’utilisation de l’agence
- Réservation d’un véhicule
- Paiement du la réservation
- Les termes et condition d’utilisation de l’agence doit être prédéfinie
- L’identification du chauffeur
Postcondition - La signature sera enregistrée

- Secrétaire est notifiée que cette chauffeur va signer le contrat sur place
Scénario no-
minal 1. Locataire (Chauffeur) cliquer sur signer un contrat
2. Système affiche contrat
3. Système demande du signer le contrat
4. Locataire (Chauffeur) signer contrat
5. Le système vérifie la signature (A1)
6. Le système demande de confirmer la signature
7. Locataire (Chauffeur) confirmer la signature du contrat (E1)
8. Système affiche message de confirmation
9. Le système enregistre contrat
10. Le système envoyé au locataire (Chauffeur) une version signée du
contrat
Scénarios A1 : La signature n’est pas valide. déclenche après point 4 de la séquence

alternatifs nominale
5.1. Le système affiche un message d’invalidation
5.2. La séquence nominale reprend au point 3
Scénarios E1 : Locataire (Chauffeur) ne confirme pas la signature du contrat.

d’excep- déclenche après point 7 de la séquence nominale
tions 7.1. Notifie la secrétaire que le contrat n’est pas signé
7.2. Le système annuler l’opération
35
Figure 1.26 – Diagramme de séquence système de cas d’utilisation Signature de contrat≫

≪
36
Cas d’utilisation ≪ Consulter liste véhicules disponible ≫ :
Nom du cas Consulter liste véhicules

Type Principal
Acteurs Internaute
Acteur Se- /
condaire
Objectif Permet à l’internaute du site de parcourir les différentes options de location
que propose l’agence
Précondition /
Postcondition La liste des véhicules est consultée
Scénario no-
minal 1. L’internaute demande de voir la liste de véhicule
2. Le système demande de période de réservation
3. l’internaute entre période
4. Le système affiche les types disponibles
5. L’internaute clique sur le type de véhicule qu’il souhaite
6. Le système affiche la liste des catégories de ce type de véhicule et de-
mande de choisit une catégorie
7. L’internaute choisit une catégorie parmi celle affichée
8. Le système affiche une liste de véhicules de la catégorie choisie (A1)
(A2)
9. L’internaute sélectionne un des véhicules figurant sur la liste
10. Le système affiche la fiche descriptive complète du véhicule choisie
Scénarios A1 : Internaute souhaite faire une recherche plus spécifique (filtrée).

alternatifs Démarre après le point 8 du scénario nominale.
8.1. L’internaute entre une multitude de filtres concernant le véhicule
voulue
8.2. Le système retourne une liste filtrée des véhicules correspondant
aux filtres entrée (A1.1)
8.3. le scénario nominale reprends au point 9
A1.1 : le système ne possède pas de véhicules répondants à la de-
mande spécifique de l’internaute. Ce scénario débute à partir du point 8.2
du scénario alternatif 1
8.2.1. le système affiche message ≪ aucun véhicule correspond à votre
requête≫
8.2.3. le scénario alternatif 1 reprend au point 8.1
A2 : Le système affiche une liste vide. Démarre après le point 8 du
scénario nominale.
8.1. Le système affiche qu’il n’y a pas des véhicule disponible de cette
catégorie dans cette période.
8.3. le scénario nominale reprends au point 4
Scénarios /
d’excep-
tions
37
Figure 1.27 – Diagramme de séquence système de cas d’utilisation Consulter liste véhicules
≪
disponible≫
38
Cas d’utilisation ≪ Gérer les reclamations ≫ :
Nom du cas Gérer réclamations

Type Principal
Acteurs Propriétaire
Acteur Se- Locataire
condaire
Objectif Permet de consulter, répondre et de supprimer aux différentes réclamations
des locataires
Précondition S’authentifier
Postcondition la réclamation est
- consulté
- répondue
- supprimée
Scénario no-
minal 1. Le propriétaire sélectionne réclamation≫
≪
2. Le système affiche liste de réclamations (A3)

3. Le propriétaire sélectionne une réclamation de la liste et la vérifie (A1)
(A2)
Scénarios A1 : propriétaire veut répondre à une réclamation, début au point 3

alternatifs de la séquence nominale
3.1. Le propriétaire clique sur ≪répondre≫
3.2. Le système affiche un espace de réponse
3.3. Le propriétaire renvoie cette réponse
3.4. Le système enregistre puis notifie le locataire de l’ajout d’une
réponse
A2 : Le propriétaire désire supprimer la réclamation, débute au point
3 de la séquence nominale
3.1. Le propriétaire clique sur ≪supprimer≫
3.2. Le système demande une confirmation de la suppression
3.3. Le propriétaire confirme la suppression de cette réclamation (E1)
3.2. Le système supprime cette réclamation
A3 : Liste de réclamations vide, débute au point 2 de la séquence nominale
2.1. Le système affiche message ≪aucune réclamation pour l’instant≫
Scénarios E1 : Le propriétaire ne confirme pas la suppression de la réclamation,

d’excep- débute au point 3.3 de la séquence alternatif 2
tions 3.3.1. le système affiche que l’opération est annulée
3.3.2. le système annule le processus de suppression
39
Figure 1.28 – Diagramme de séquence système de cas d’utilisation ≪ Gérer les reclamations≫
40
Cas d’utilisation ≪ Payer ≫ :
Nom du cas Payer

Type Secondaire
Acteurs Locataire
Acteur Se- /
condaire
Objectif Permet au locataire de payer le montant de sa location
Précondition Le locataire doit avoir commencée le processus de location
Postcondition - Les informations de paiement sont enregistrées
- Une notification vers la secrétaire est envoyée
Scénario no-
minal 1. Locataire clique sur payer≫
≪
2. Système affiche la facture de la location

3. Système affiche les types de paiement possible et demande de sélectionne
type de paiement (A1)
4. Locataire sélectionne type de paiement (par carte) (A2)
5. Le système affiche formulaire bancaire
6. Locataire renvoie le formulaire replie
7. Le système vérifie la véracité des informations bancaires entrée (A3)
(E1)
8. Le système enregistre les informations de paiement.
9. Le système affiche une fiche récapitulative de la location + paiement
Scénarios A1 : Locataire dispose d’un code promotionnel, débute au point 3 de

alternatifs la séquence nominale
3.1. Locataire clique sur ≪entrer un code promo≫
3.2. Le système demande d’entrer le code promo
3.3. Locataire entre ce code de promotion
3.4. Le système vérifie la validité du code (A1.1)
3.6. Système affiche la facture de la location après la promotion
A1.1 : Le système ne valide pas le code promo insérer, débute au point
3.4 du scénario alternatif 1
3.5.1. Le système affiche message ≪ code promotionnelle invalide≫
3.5.2. Le scénario alternatif 1 reprend au point 3.2
A2 : Début au point 4 de la séquence nominale,le client choisit l’option de
payer sur place.
4.1. Locataire clique sur ≪paiement à l’agence≫
4.2. Le système notifier secrétaire
A3 : Le système ne valide pas les informations bancaires fournies et
le nombre de tentatives est inférieur à 4, début au point 7 de la séquence
nominale
7.1. Le système affiche un message d’erreur
7.2. Le séquence nominale reprend à partir du point 5
41
Scénarios E1 : Les informations bancaires incorrecte et le nombre de tentatives

d’excep- est égal à 4, début au point 7 de la séquence nominale
tions 7.1. Le système affiche message ≪nombre tentatives écoulée≫
7.2. le système bloque le processus de paiement et le client est redirigé
vers la page d’accueil (annule l’opération)
42
Figure 1.29 – Diagramme de séquence système de cas d’utilisation Payer≫

≪
43
Cas d’utilisation ≪ Renouveler contrat ≫ :
Nom du cas Renouveler le contrat

Type Secondaire
Acteurs Locataire
Acteur Se- /
condaire
Objectif Permet au locataire de prolonger la durée de la location du véhicule
Précondition Le délai avant fin contrat de location n’est pas écoulé
Postcondition - La secrétaire est notifiée
- La demande de renouvellement est enregistrée
Scénario no-
minal 1. Locataire clique sur ≪ renouveler contrat≫
2. Système affiche les contrats en cours et son délai de renouvellement n’est
pas écoulé (E1)
3. Locataire sélectionne un contrat en cours
4. le système affiche les informations relatives au contrat sélectionné
5. Locataire valide les informations du contrat
6. Le système demande la durée et les informations relatives au renouvel-
lement
7. Locataire envoie les informations et la durée souhaitée
8. Le système affiche les données du contrat de renouvellement
9. Locataire valide le renouvellement (E2)
10. Le système enregistre la demande de renouvellement
11. Le système affiche que la demande de renouvellement est enregistrée
Scénarios /
alternatifs
Scénarios E1 : Système ne trouve pas des contrats en cours et son délai de
d’excep- renouvellement n’est pas écoulé, débute au point 2 de la séquence nominale
tions 2.1. Le système affiche que il n’y a pas des contrats en cours et son
délai de renouvellement n’est pas écoulé
2.2. Le système annule l’opération
E2 : Locataire ne valide pas le renouvellement. débute au point 9 de la
séquence nominale
9.1. Le système affiche que l’opération est annulée
9.2. L système annule l’opération
44
Figure 1.30 – Diagramme de séquence système de cas d’utilisation Renouveler contrat≫

≪
45
1.7 Conclusion
Durant ce chapitre, nous ayons fait un etude préliminaire et une spécification des besoins
d’utilisateurs et nous obtenous un modèle de cas d’utilisation qu’il nous aide à faire une déscription
détaillée des besoins d’utilisateurs dans le chapitre suivant.
46
CHAPITRE 2. CONCEPTION
Chapitre 2
Conception
2.1 Introduction
Dans ce chapitre nous suivons avec l’étape de la conception qui constitue une étape fonda-
mentale dans la processus de développement puisqu’elle fait correspondre la vision applicative (le
modèle d’analyse) à la vision technique (l’environnement de développement et d’exécution) nous
commençons avec le modéle de domaine qui contient les identifications des entités du système et
les relations entre ces entiés ,modélisé par diagramme de classe ,ensuite nous identifions les classes
du systéme et diagramme de classe ,ainsi nous montrons le passage de ce dernier en modéle logique
données et la normalisations et le soutenir avec une schéma de la base de donneés.
2.2 Modèle de domaine

2.2.1 Identification des entités du système et les relations entre elles
Identification Une entité est la représentation d’un élément matériel ou immatériel ayant un
rôle dans le système que l’on désire décrire. On appelle classe d’entité un ensemble composé d’entités
de même type.
User : contient les données sur les utilisateurs du notre système.
Infraction : représente les informations des infraction qui fait par le chauffeur.
Entreprise : contient les informations sur les entreprises qui fait les réservations.
blacklist : les informations des chauffeurs exclus de notre système.
Reclamation : les informations sur les réclamations de locataire .
Question : les informations sur les questions posé par les utilisateurs.
Driver : les données des chauffeurs qui conduit les véhicules louées.
Problem : les informations sur les problèmes déclaré depuis les chauffeurs sur les véhicules.
Vehicle : les informations sur les véhicules a louée sur notre système.
Tool : les informations sur les accessoires supplémentaire qui peut ajouter sur les véhicules
durant la location.
Contract : représente les contrats avec les locataire et l’entreprise qui louée les véhicules.
Bill : représente la facture a payé de la location.
Parking : les informations sur les parking de notre système.
Employee : les informations sur les employé de notre système.
Renter : les informations sur les locataire de notre systéme.
Renting : les données de l’opération de location des véhicules.
Notifications : les données qui informent les utilisateurs d’un changement d’état dans notre
système.
Owner : les informations sur le propriétaire de notre système.
Admin : les informations sur les administrateurs de notre systéme.
47
Agency : les informations sur les agences géré par notre systéme.
Payement : les informations sur le payement des locations
Secretary : les informations sur les secrétaires de notre système.
Salaries : les informations sur les salaires des employée de notre système
Garage Manager : les informations sur les garagistes de notre système.
Les relation entre les différentes entités sont démontrées dans la figure de modele de domaine
Figure 2.1.
2.2.2 Description des éléments de diagramme de classe

Classes : Dans le langage UML, une classe représente un objet ou un ensemble d’objets qui
partagent une structure et un comportement communs.
Objets : Dans les modèles UML, les objets sont des éléments de modèle représentant les
instances d’une ou plusieurs classes.
Type de données : Dans les diagrammes UML, les types de données sont des éléments de
modèle qui définissent des valeurs de données. Vous utilisez généralement les types de
données pour représenter des types primitifs, tels que les types integer (entier) ou string
(chaı̂ne), et des énumérations, telles que des types de données définis par l’utilisateur.
Relations dans les diagrammes de classes : En langage UML, une relation est une connexion
entre des éléments de modèle. Une relation UML est un type d’élément de modèle qui ajoute
une sémantique à un modèle en définissant la structure et le comportement entre les éléments
de modèle.
Qualificateurs sur les extrémités d’association : Dans UML, les qualificateurs sont des
propriétés applicables aux associations binaires et des composants facultatifs des extrémités
d’association. Un qualificateur contient une liste d’attributs d’association, doté chacun d’un
nom et d’un type. Les attributs d’association modélisent les clés utilisées pour indexer un
sous-ensemble d’instances de relation.
[?]
2.2.3 Diagramme de classe domaine

Cet diagramme repéresent le plan de le systéme ,nous utilisons des diagrammes de classes pour
modéliser les objets qui constituent le système, pour afficher les relations entre les objets et pour
décrire ce que ces objets font et les services qu’ils fournissent.
48
Figure 2.1 – Le modele de domaine
2.3 Diagramme de classe conception

2.3.1 Identification des classes
Dans la partie suivante nous montrons les différentes classe de notre système et attributs et
méthodes principales de ces classes.
Attributs :
int entreprise name : le nom de l’entreprise
int commercial register num : le numéro de registre commerce de l’entreprise
status : état de la notification (lu, non lu ...etc)
type :
boolean is deleted : montrer que l’utilisateur supprime son compte ou non
char UserType : distingue les types de locataires (compte entreprise E, comptes person-
nelles P)
String justification : description de la réclamation, ou le probléme de véhicule, ou bien le
raison d’ajout d’un locataire au liste de locataires exclus
String answer : le contenu de la réponse sur une réclamation ou une question
promotion : montant diminuée du total de la facture aprés insertion d’un code promotion-
nelle
PDFBill : fichier PDF de la facture générée
String img id : photo d’identité pour identifier le chauffeur
RenterType : definit les différents type de locataire possible (entreprise, employee, propriai-
raire...)
49
boolean is active : Indique si l’utilisateur travaille toujours en tant qu’un employé dans
tells poste
Time start of working timel : définir l’heure de début temps travail l’employé
Time end of work time : définir l’heure de fin temps travail l’employé
EmployeeTypes : définit quelle position peut occuper l’employée ( administrateur, secrétaire,
garagiste )
method paiment : définit la méthode de payement que le locataire a selectionée ( par carte,
ou sur place)
Recipt : reçu du payement sur place
cardNum : numéro de carte bancaire avec laquelle le locataire a efectué le payement
nbHour : nombre d’heures de location facturée
nbDay : nombre de jours de location facturée
PDFFile : définit le fichier pdf qui représente le contrat de location
type : définit quelle type de contrat ( nouveaux contrat ou renouvellement )
RentingState : définit si le véhicul est disponible pour la location ou non
String state in accessoire : pour dire que l’accessoire est disponible ou non
String name : le nom du véhicule (marque)
String model : le modèle du véhicule
String type : dans quelle catégorie se trouve le véhicule (Sport , familial, ... )
String gearbox type : définit le type de boite vitesse (Manuelle , automatique)
int number Seat : le nombre de place
String state : pour dire que le véhicule est loué ou disponible ou réparer
boolean reduced mobility : définit si le véhicules réponds aux critères d’accommodations
pour les personnes à mobilité réduite
String type of engine : définir les caractéristique de moteur
int spot number : représente le numéro de la place de paking attribuée a ce véhicule
int spot Letter : représente la lettre de la zone d’emplacement de ce véhicules dans le
parking
int qr code : représente le code qr unique associé a ce vehicule
Méthodes :
QRgenerator () : méthode permettant de générer des codes QR uniques et spécifique à
chaque véhicule .
Billgenerator() : méthode permettant de générer les factures de chaque réservation sous
format PDF.
ContartGenerator () : méthode permettant de générer les contrat relatif à chaque réservation
sous format PDF.
Pay() : méthode permettant le payement en ligne.
2.3.2 Diagramme de classe conception
50
Figure 2.2 – Diagramme de class de conception
51
Figure 2.3 – Diagramme de class de conception
52
2.4 Schéma de la base de données

2.4.1 Passage du modèle du domaine au modèle relationnel
Le modèle relationnel est le modèle logique de donnée qui correspond à l’organisation des
données dans les bases de données relationnelles. Un modèle relationnel est composé de relations,
encore appelée table. Ces tables sont décrites par des attributs aux champs. Pour décrire une
relation, on indique tout simplement son nom, suivi du nom de ses attributs entre parenthèses.
L’identifiant d’une relation est composé d’un ou plusieurs attributs qui forment la clé primaire.
Une relation peut faire référence à une autre en utilisant une clé étrangère, qui correspond à la clé
primaire de la relation référencée. [?]
Règles de passage au modèle relationnel

Il est possible de traduire un diagramme de classe en modèle relationnel en suivant les règles
de passages suivantes :
- Chaque table dans UML devient une table (relation), son identifiant devient la clé primaire
tandis que les autres propriétés deviennent les attributs de la table
- la représentation des association :
- Association 1 vers 1 : les clé primaire d’une table deviennent des clé étrangères dans
la tables associé
- Association 1 vers plusieurs : la relation est similaire aux association 1 à1 excepté
que ici le coté plusieurs est celui qui reçoit forcément les clé étrangère
- Association plusieurs vers plusieurs : une table intermédiaire est nécessaire ici ou
figurent les clés primaires des 2 tables en et dont la clé primaire est une concaténation
de ces 2 attributs
- Transformation de l’héritage : les clés primaires de la table de generalisation deviennent
des clés primaires et étrangères dans la table de spécialisation.
Schéma logique des données

Le modèle logique des données consiste à décrire la structure de données utilisée. Il s’agit donc
de préciser le type de données utilisées lors des traitements.
User (user id, password, first name, last name, user name, phone num, email, date of birth,
registration date, gender, address, is deleted, type user)
Admin (#admin id)
Driver (#driver id, permit number, permit category, issued, photo permit, img id, available,
#entreprise id)
Renter (#renter id, type)
Reclamation (reclamation id, post date, response date, motif, response, #renter id, #ow-
ner id)
Infraction (ifraction id, type, date, #driver id)
Question (question id, question, response, post date, response date, user id, #admin id)
Bill (bill id, date of establishment, promotion, PDFBill, #Contrat id, #payment id)
Renting (renting id, departure location, return location, date of departure, date of return, state,
#renter id, #diver id, #vehicle id , #exit checker, #entry checker)
Problem (id, post date, probelem, type, response, response date, #garage manager id, #dri-
ver id, #vehicle id)
Contract (contract id, date of establishment, signatureDriver, signatureRente ,PDFFile, type,
#secretary id, #reservation id)
Vehicle (id, registration num, name, model, type, year of purchase, gearbox type, number seat,
color, state, reduced mobility, type of engine, priceH, priceD, spotLetter, spotNumber, photo,
qr code, #parking id)
Tool (id, name, price, state, #parking id)
53
Parking (parking id, address, capacity, name , location)

Employee (#employee id, type, grade, start of working time, end of work time, work time,
agency location , is active)
Entreprise (#entreprise id, entreprise name, commercial register num)
Garage manager (#garage manager id, #parking id)
blacklist (#driver id, date, motif)
Owner (#owner id, is active)
Secretary (#secretary id, is active)
Agency (id, address, phone, email, name, location, #admin id)
Salaries (id, type, grade, Salary)
payment (id, method paiment, Receipt, date, cardNum , exDate, cardName, Amount, nb-
Hour, nbDay)
Renting tool (id, #renting id, #tool id)
2.4.2 La normalisation de la base de données

La normalisation d’une relation consiste à la décomposer en un ensemble de relations telles
qu’aucune des relations obtenues ne possède les anomalies de redondance, de mise à jour et de
suppression. Relativement aux dépendances fonctionnelles, on distingue quatre formes normales :
[?]
la 1re forme normale : Une relation est en 1re forme normale si tous ses attributs ont une
valeur atomique.
la 2éme forme normale : Une relation est en 2éme forme normale si elle est en 1re forme
normale et si chaque attribut non-clé dépend totalement et non partiellement de la clé
primaire..
la 3éme forme normale : Une relation est en 3éme forme normale si pour chaque dépendance
fonctionnelle non triviale X Y, on a : soit, X est une super-clé de R ; soit, Y appartient
à une clé candidate de R. La 2éme partie de la règle est importante, car elle dit qu’un
constituant d’une clé candidate peut dépendre.
En suivant les règles de normalisation prédéfinit, on remarque que notre base de données
réponds a tous les critères de la 3FN. Donc elle est normalisée.
2.4.3 Schéma de la base de données sous forme diagramme
54
55
Figure 2.4 – Diagramme de schéma de base de données
2.5 Daigramme d’activité

Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont donc
particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de flots de
données. Ils permettent ainsi de représenter graphiquement le comportement d’une méthode ou le
déroulement d’un cas d’utilisation.
La modalisation d’un scénario d’utilisation de notre système avec un diagramme d’activité.
Le scénario début par l’inscription dans le système et faire une opération de location jusqu’à la fin
de location.
Figure 2.5 – Daigramme d’activité
56
2.6 Conclusion
Dans cet chapitre nous montrassions le modéle de domaine avec identification des entités du
systéme et le diagramme de classe, aprés nous avons le transformé au modèle relationnel avec
l’applications les régles de passage ,ce dernier on applique la normalisation pour obtenir une base
de données moins redondante. suivis par le patrons de conception pour faire un lien avec le chapitre
suivant.
57
Deuxième partie
Construction et Transition
CHAPITRE 3. IMPLIMENTATION
Chapitre 3
Implimentation
3.1 Introduction
Étant arrivé à une des dernières étapes du processus de développement on discutera des
choix techniques relatifs à la mise en œuvre de notre projet. Nous aborderons l’environnement
de développement, les outils et langages de programmation utilisée ainsi que le développement de
nouvelles technologies (intelligence artificielle) et on conclura avec la présentation des réalisations
effectuée.
3.2 Patrons de conception (Design Pattern)

En informatique et plus particulièrement en développement logiciel, un patron de conception
(design pattern) est un arrangement caractéristique de modules, reconnu comme bonne pratique
en réponse à un problème de conception d’un logiciel. Il décrit une solution standard, utilisable
dans la conception de différents logiciels.
MVT : signifie Modèle-Vue-Template. Parfois, il est également appelé MTV (Model-Template-
View). MVT est un modèle de conception ou une architecture de conception que Django suit
pour développer des applications Web. Il est légèrement différent du modèle de conception
MVC (Model-View-Controller) communément connu. MVT détermine la structure totale et
le flux de travail d’une application Django. Dans une architecture MVT
La vue reçoit des requêtes HTTP et envoie des réponses HTTP. Une vue interagit avec un
modèle et un modèle pour compléter une réponse.
Le modèle gère les données et est représenté par une base de données. Un modèle est essen-
tiellement une table de base de données
Template est le composant qui rend MVT différent de MVC. Les modèles agissent comme la
couche de présentation et sont essentiellement le code HTML qui restitue les données. Le
contenu de ces fichiers peut être statique ou dynamique
Figure 3.1 – Architechtre du MVT ()
59
3.3 Présentation de l’environnement de travail

3.3.1 Langages Utilisée
Python
Python est un langage de programmation interprété, multi-paradigme et multiplateformes.
Utile durant le développement d’un large éventail de projets, allant de simples applications web à
des systèmes d’exploitation complets.[?]
Pourquoi utiliser Python ?[?] - langage conçu pour optimiser la productivité avec des outils de
haut niveau. - l’un des langages de programmation les plus accessibles grâce à sa syntaxe simplifiée.
- Polyvalence, efficacité, fiabilité et rapidité. - Langage flexible.
Django [?] framework Web Python de haut niveau, encourage un développement rapide et
une conception propre et pragmatique.Le projet a pour slogan ≪ Le framework pour les
perfectionnistes avec des deadlines ≫. Cette framework prend en charge une grande partie
des tracas du développement Web, on peut donc se concentrer sur l’écriture de l’application
seulement .
Pourquoi utiliser Django : [?]
- Django possède une sécurité rassurante, il gère automatiquement les fonctionnalités de
sécurité standard (gestion des comptes d’utilisateurs, la gestion des transactions, détournement
de clics, etc.)
- Excessivement évolutif et maintenable.
- Django suit des modèles et des principes de conception pour réutiliser et maintenir le
code.
Rest Framework [?] Le framework Django REST (DRF) est une boı̂te à outils puissante et
flexible pour la création d’API Web.Elle prend les concepts de REST et les lie aux modèles
et aux vues dans Django. DRF prend en charge une variété d’interfaces de rendu de données,
d’autres mécanismes sont également pris en charge, ainsi que des bibliothèques tierces. Tout
d’abord, les modèles Django sont associés à des sérialiseurs DRF (Les sérialiseurs spécifient
comment transformer le contenu en JSON ).Comme les URL Django, les routeurs DRF
mappent les vues aux URL réelles exposées.
Quelques raisons qui justifient l’utilisation du framework REST :
- L’API navigable sur le Web est un énorme avantage en termes de convivialité pour les
développeurs.
- Politiques d’authentification, y compris les pacages pour OAuth1a et OAuth2.
- Sérialisation prenant en charge les sources de données ORM et non ORM.
- Personnalisable jusqu’au bout
SQL
Structured Query Language est un langage informatique normalisé utilisé pour exploiter des
bases de données relationnelles.. Il permet de façon générale la définition, la manipulation et le
contrôle de sécurité de données. [?]
Pourquoi utiliser SQL :
- Évolutivité
- Structure, Les bases de données SQL sont mieux adaptées aux transactions multilingues.
- Documentation et Grande Communauté
HTML
≪ HyperText Markup Language ≫ qu’on peut traduire par ≪ langage de balises pour l’hyper-
texte . Il est utilisé afin de créer et de représenter le contenu d’une page web et sa structure.
≫
[?]
CSS
Cascading Style Sheets en anglais, ou ≪ feuilles de style en cascade ≫ sont le code utilisé pour
mettre en forme une page web. [?]
60
Bootstrap
Collection d’outils utiles à la création du design (graphisme, animation et interactions avec la
page dans le navigateur, etc.) de sites et d’applications web. C’est un ensemble qui contient des
codes HTML et CSS et JS [?]
Pourquoi utiliser bootstrap ?
- Fonctionnalités prédéfinies
- Personnalisation facile, il propose des propriétés par défaut facilement personnalisables selon
les besoins.
- Open-source, il y a une immense communauté pour continuer à améliorer ses fonctionnalités.
- Idéal pour la conception réactive
JavaScript
Langage de script léger, orienté objet, principalement connu comme le langage de script des
pages web. C’est un langage à objets utilisant le concept de prototype, disposant d’un typage
faible et dynamique qui permet de programmer suivant plusieurs paradigmes de programmation
(fonctionnelle, impérative et orientée objet. . .)[?]
React js une bibliothèque JavaScript libre, son but principal est de faciliter la création d’ap-
plication web monopage, via la création de composants dépendant d’un état et générant
une page (ou portion) HTML à chaque changement d’état.[?]
Pourquoi utiliser ReactJs ?
- Les composants de ReactJS sont des morceaux de code indépendants et réutilisables.

- Virtual Document Object Model (DOMS)
- Aucune architecture imposée.
- React JS offre une flexibilité totale au développeur.
JSON JavaScript Object Notation est un format d’échange de données en texte lisible. Il est
utilisé pour représenter des structures de données et des objets simples dans un code qui
repose sur un navigateur Web [?]
Pourquoi utiliser JSON ?
— JSON est léger par rapport à XML.

— La structure de données JSON aide à créer des API RESTful fournissant des méthodes
d’échange de données plus simples.
— Etant donné que le format JSON n’est que du texte, il peut facilement être envoyé vers
et depuis un serveur et utilisé comme format de données par n’importe quel langage de
programmation.
— JSON analyse les données plus rapidement que XML en utilisant la fonction JavaScript
standard. JSON est analysé dans un objet JavaScript prêt à l’emploi.
D3.JS Data-Driven Documents est une bibliothèque JavaScript et un framework permettant
de produire des visualisations de données dynamiques et interactives dans les navigateurs
Web. D3 associe les données au DOM, cela permet à l’utilisateur de manipuler, modifier ou
ajouter au DOM. [?]
Signature pad une bibliothèque JavaScript pour dessiner des signatures fluides, basée sur un
canvas HTML5 et utilise une interpolation de courbe de Bézier à largeur variable basée sur
la publication de Smoother Signatures par Square, ne dépend d’aucune bibliothèque externe.
React QR reader application de code QR de haute qualité. Le lecteur de QR code est conçu
pour décoder (scanner le code) et permet donc à l’utilisateur d’avoir accès aux informations
stockées.
61
LaTex
LaTeX est un système de composition de haute qualité ; il comprend des fonctionnalités conçues
pour la production de documentation technique et scientifique. LaTeX est le standard de facto pour
la communication et la publication de documents scientifiques. LaTeX est disponible en tant que
logiciel libre. [?]
Tensorflow
TensorFlow est un framework open source développé par des chercheurs de Google pour
exécuter l’apprentissage automatique, l’apprentissage en profondeur et d’autres charges de travail
d’analyse statistique et prédictive. Comme des plates-formes similaires, il est conçu pour ratio-
naliser le processus de développement et d’exécution d’applications d’analyse avancées pour les
utilisateurs tels que les scientifiques des données, les statisticiens et les modélisateurs prédictifs. [?]
Keras une API basé sur Tensorflow2 conçue pour les humains, non pas pour les machines.
Keras suit les meilleures pratiques pour réduire la charge cognitive : il propose des API
cohérentes et simples, il minimise le nombre d’actions de l’utilisateur requises pour les cas
d’utilisation courants et il fournit des messages d’erreur clairs et exploitables. [?]
3.3.2 Plateformes Logicielle

Pour le développement de ce projet nous avons eu recours a différent logiciels et environne-
ments,listé ci-dessus
MySQL Workbench :
système de gestion de bases de données relationnelles SQL open source développé et supporté
par Oracle.Il fait partie des logiciels de gestion de base de données les plus utilisés au monde (ap-
plications web principalement).[?]
Pourquoi choisir MySQL ?
- MySQL est mondialement reconnu pour être le SGBD le plus sécurisé et le plus fiable utilisé
dans les applications Web populaires.
- Haut niveau de performances.
- Facilité d’adaptation et Évolutivité à la demande.
VSCode
Visual Studio Code est un éditeur de code source léger mais puissant. Il est livré avec un sup-
port intégré pour JavaScript, TypeScript et Node.js et dispose d’un riche écosystème d’extensions
pour d’autres langages (tels que C++, Java, Python, PHP, Go) et des runtimes (tels que .NET et
Unity) .[?]
Pycharm
un environnement de développement intégré utilisé pour programmer en Python. Il permet
l’analyse de code et contient un débogueur graphique. Il permet également la gestion des tests
unitaires, l’intégration de logiciel de gestion de versions, et supporte le développement web avec
Django. [?]
Postman :
Postman est une plate-forme API pour créer et utiliser des API. Elle simplifie chaque étape du
cycle de vie des API et rationalise la collaboration pour créer de meilleures API plus rapidement.[?]
62
Google chrome :
Chrome est un navigateur web propriétaire développé par la société Google depuis 2008, basé
sur Chromium fonctionnant sous Windows, Mac, Linux, Android et iOS. [?]
Microsoft Edge :
Microsoft Edge est un navigateur web propriétaire développé par la société Microsoft depuis
2015, et basé sur Chromium depuis 2020. Il est conçu pour remplacer Internet Explorer. installé
par défaut avec Windows 10 et 11, et il est disponible également sur d’autre plateformes [?]
Github :
Github est un service web d’hébergement et de gestion de développement de logiciels, utilisant
le logiciel de gestion de versions Git. Le site assure également un contrôle d’accès et des fonction-
nalités destinées à la collaboration comme le suivi des bugs, les demandes de fonctionnalités et la
gestion de tâches. [?]
Google drive :
Service de stockage et de partage de fichiers dans le cloud lancé par la société Google. C’est
une suite bureautique permettant de modifier des documents, feuilles de calcul, présentations,des
formulaires ... etc [?]
Google Keep :
Google Keep est une application de prise de notes développée par Google ; disponible à la fois
sur le Google Play , l’App Store et en tant qu’application web liée à Google Drive. Elle offre une
variété d’outils pour optimiser la prise de notes en équipe [?]
TexStudio
TeXstudio est un éditeur LaTeX open source multiplateforme. Ses fonctionnalités incluent un
vérificateur d’orthographe interactif, le pliage de code et la coloration syntaxique. Il ne fournit
pas LaTeX lui-même - l’utilisateur doit choisir une distribution TeX et l’installer en premier.(dans
notre cas on a choisi MikTex) [?]
PlantUML
PlantUML est un outil open source permettant aux utilisateurs de créer des diagrammes à
partir d’un langage de texte brut. Outre divers diagrammes UML, PlantUML prend en charge di-
vers autres formats liés au développement de logiciels, ainsi que la visualisation des fichiers JSON.
[?]
Figma
Figma est une application Web d’édition graphique et de conception d’interface utilisateur.
Peut être utilisée pour effectuer toutes sortes de travaux de conception graphique à partir de sites
Web filaires, concevoir des interfaces d’applications mobiles, concevoir des prototypes, créer des
publications sur les réseaux sociaux et tout le reste. [?]
63
3.3.3 Plateformes Matérielle

Ordinateurs Portables
- DELL Latitude E7450 i7 5éme génération Intel (R) HD Graphics 5500 - NVIDIA GeForce
840M
- HP NoteBook i5 7éme génération ( 8GB RAM - 256GB SSD ) Carte graphique Radeon AMD
R5M330B 2GB
- HP EliteBook i5 6éme génération ( 8GB RAM - 256GB SSD)
Appareils Mobiles
- Redmi 9
- Samsung A7
- Samsung S8+
3.3.4 Services Web utilisée

Google Maps service mondial de cartographie en ligne. Google Maps propose une vue en plan
cartographique classique et une vue en images satellites ou photographies aériennes. Les ha-
bitations et reliefs sont également visibles en 3D, Disponible sur plusieurs plateformes.[?]
3.4 Développement d’application sécurisée

L a sécurité est un facteur important à prendre en compte durant le développement des logiciels.
En effet il faut protéger les données qui transitent entre notre site et le visiteur, un défaut de
sécurité peut amener de lourdes conséquences.
N otre développement d’une application plus sécurisé se fait ressentir notamment lors de la
conception des fonctionnalités suivantes :
3.4.1 Authentification
L’authentification est le mécanisme d’association d’une demande entrante à un ensemble d’in-
formations d’identification. Les politiques d’autorisation et de limitation peuvent ensuite utiliser
ces informations d’identification pour déterminer si la demande doit être autorisée. [?]
token authentification (authentification par jeton) Les mots de passe nécessitent également
une authentification du serveur. Chaque fois que la personne se connecte, l’ordinateur crée
un enregistrement de la transaction. La charge mémoire augmente en conséquence.
Avec l’authentification par jeton, un service secondaire vérifie une requête du serveur.
Lorsque la vérification est terminée, le serveur émet un jeton et répond à la demande.
L’utilisateur peut toujours avoir un mot de passe à retenir, mais le jeton offre une autre
forme d’accès qui est beaucoup plus difficile à voler ou à surmonter.[?]
session authentification Une session est un petit fichier (souvent sous format JSON), qui
stocke des informations sur l’utilisateur (ID, heure de connexion. . .). Il est généré et stocké
sur le serveur afin que le serveur puisse suivre les demandes des utilisateurs.
L’utilisateur reçoit certaines de ces informations, en particulier l’identifiant, sous forme de
cookies qui seront envoyés à chaque nouvelle demande, afin que le serveur puisse reconnaı̂tre
l’identifiant et autoriser les demandes de l’utilisateur.[?]
basic authentification Ce schéma d’authentification utilise l’authentification de base HTTP,

signée avec le nom d’utilisateur et son mot de passe. Elle n’est généralement appropriée que
pour les tests.[?]
64
3.4.2 Two Factors authentification

vérification en deux étapes, consiste à renforcer la protection de votre compte en ajoutant
un second moyen d’identification. Cela peut se traduire de diverses manières (envoi d’un code
unique par SMS, envoi d’un code utilisable pendant une période limitée, utilisation d’une applica-
tion d’authentification ,recours à la reconnaissance faciale, vocale ou par empreinte digitale ..etc)[?]
3.4.3 permission classes

Les contrôles d’autorisation s’exécutent toujours au début de chaque vue. Il utilise les infor-
mations d’authentification dans les propriétés ≪ request.user ≫ et ≪ request.auth ≫ pour chaque
demande entrante. Si la vérification des autorisations échoue, le code d’affichage ne sera pas exécuté
[?]
3.4.4 Cryptage base de données

Le chiffrement désigne la conversion des données depuis un format lisible dans un format codé.
Les données chiffrées ne peuvent être lues ou traitées qu’après leur déchiffrement.
C’est le moyen le plus simple et le plus efficace de s’assurer que les informations du système
informatique ne peuvent être ni volées ni lues par autrui
Mais aussi la sécurité de notre application s’est faite par la prise de décisions stratégiques, en
ce qui concerne les différents langages et frameworks utilisés. Nous avons veillé à prendre les choix
les plus fiables parmi ceux disponibles ( utilisation de framework Django , MySQL Workbench . . .
etc ) [?]
3.5 Développement de l’intelligence artificielle

l’intelligence artificielle (IA) fait référence à des systèmes qui imitent l’intelligence humaine
pour effectuer des tâches et qui peuvent s’améliorer en fonction des informations collectées.
3.5.1 Pourquoi utiliser l’intelligence Artificielle :

- L’intelligence artificielle apporte un avantage concurrentiel dans les objectifs des entre-
prises (eg : les recommandations ciblées du système d’IA aident les entreprises à prendre de
meilleures décisions)
- Les prévisions générées facilitent l’automatisation des tâches excessivement complexes ou
répétitives
- permet de mieux appréhender l’abondance des données disponibles.
3.5.2 Fonctionnalités développée

Réconnaissance faciale une méthode d’identification biométrique qui consiste à identifier
une personne grâce à son visage d’une manière automatique. La technologie recueille un
ensemble de données biométriques uniques auprès de chaque personne, associées à son visage
et expression faciale afin d’identifier, vérifier et/ou authentifier une personne.
Réconnaissance de signaux routier Le système de reconnaissance des panneaux de si-
gnalisation fonctionne grâce à une caméra multifonctions positionnée contre le pare-brise
du véhicule. Ce sont les images captées par cette caméra qui seront ensuite visualisées par un
logiciel spécialisé, qui fera alors une comparaison entre le panneau capturé et ceux stockés
dans la base de données. Il ne restera alors plus qu’à afficher le panneau.
Réconnaissance de textes La Reconnaissance Optique de Caractères (OCR) est un procédé
qui consiste à convertir les images de texte imprimé ou manuscrit en données modifiables.
L’OCR est une fonction essentielle d’un logiciel qui effectue une analyse d’un fichier image et
65
qui convertit les caractères dans un fichier texte (word, pdf ...) afin de pouvoir travailler sur
ce texte. C’est un outil simple à manipuler, et permet une conversion rapide des documents.
3.5.3 Domaines de développementt

Dans cette section on va aborder une brève définition des domaines de l’IA utilisée pour
développer les fonctionnalité souhaitée :
Machine learning (ML) est axé sur la création de systèmes qui apprennent ou améliorent
leurs performances en fonction des données qu’ils traitent. [?]
Computer vision (CV) un sous-ensemble de ML qui consiste à faire en sorte que les ma-
chines comprennent les actions,comportements et les langages humains de la même manière
que les humains. L’idée est d’amener les machines à comprendre et à interpréter le monde
visuel afin qu’elles en tirent des idées significatives. [?]
Deep Learning (DL) forme dérivée du ML, Il a été créé en s’inspirant des réseaux neuronaux
du cerveau humain. L’apprentissage profond est constitué d’un grand nombre de couches
de neurones artificiels interconnectés. [?]
Différence entre Machine Learning et Deep Learning :

La différence entre ML et DL réside dans le fait que les algorithmes de ML vont traiter des
données quantitatives et structurées (des valeurs numériques), lorsque ceux de DL traiteront des
données non structurées (le texte, l’image...)
Figure 3.2 – différence ML et DL

[?]
66
Modèles de développement
Le développement de logiciel selon le DL, se fait suivant des modèles pré-définis en fonction
du résultat attendu et de la fonctionnalités voulue. Ici on va discuter de certain de ces modèle
Dans le développement de logiciel intelligent nous avons notamment fait recours au modèles
du DL , les 2 principaux types d’algorithmes sont les suivant :
réseaux de neurones conventionnels (CNN) constitués d’une multitude de couches chargées
de traiter et d’extraire les caractéristiques des données. De manière spécifique, les réseaux
neuronaux convolutifs sont utilisés pour l’analyse et la détection d’objets.(images ...).on a
notamment utilisée cet algorithme durant le développement de logiciel de reconnaissance de
signaux routier [?]
réseaux de neurones récursifs(RNN) possèdent des connexions qui constituent des cycles
dirigés.Elle peut mémoriser les entrées précédentes à l’aide de sa mémoire interne et les
exploiter comme entrées au niveau de la phase actuelle [?]
3.5.4 Bibliothèques utilisée

Durant cette partie nous allons citer les bibliothèque principales utilisée durant le développement
de l’IA
OpenCV Open Computer Vision est une bibliothèque graphique libre, spécialisée dans le
traitement d’images en temps réel. [?]
Tesseract JS moteur de reconnaissance optique de texte (OCR) open source. Il peut être uti-
lisé directement ou à l’aide d’une API pour extraire le texte imprimé des images. Il prend
en charge une grande variété de langues. [?]
NumPy est le package fondamental pour le calcul scientifique en Python. Il s’agit d’une bi-
bliothèque Python qui fournit un objet tableau multidimensionnel, divers objets dérivés (tels
que des tableaux masqués et des matrices) et un assortiment de routines pour des opérations
rapides sur des tableaux, y compris mathématiques, logiques, manipulation de forme, tri,
sélection, E/S , transformées de Fourier discrètes, algèbre linéaire de base, opérations sta-
tistiques de base, simulation aléatoire et bien plus encore.[?]
Pandas est un package Python open source qui est le plus largement utilisé pour la science
des données/l’analyse des données et les tâches d’apprentissage automatique. Il est construit
au-dessus d’un autre package ”Numpy 3.5.4”. En tant que l’un des packages de gestion de
données les plus populaires, Pandas fonctionne bien avec de nombreux autres modules de
science des données au sein de l’écosystème Python. [?]
Scikit-learn (Sklearn) la bibliothèque la plus utile et la plus robuste pour l’apprentissage

automatique en Python. Il fournit une sélection d’outils efficaces pour l’apprentissage au-
tomatique et la modélisation statistique, notamment la classification, la régression, le re-
groupement et la réduction de la dimensionnalité via une interface de cohérence en Python.
Cette bibliothèque, qui est en grande partie écrite en Python, est construite sur NumPy,
SciPy et Matplotlib. [?]
3.6 Présentation des interfaces graphique

3.6.1 Interface d’authentification
Cette interface représente la page d’authentification pour les internautes
Figure 3.3 – interface d’authentification
67
3.6.2 Interface d’accueil - Home Page -

Cette interface représente la page d’accueil du site, elle permet aux internautes de chercher un
véhicule pour la location, mais aussi une explication du processus de location ainsi qu’une Q/A
Figure 3.4 – interface de la page d’accueil de site
68
3.6.3 Interface de recherche

Cette interface représente le résultat d’une recherche d’un internaute, et affiche tous les
véhicules correspondant aux filtres de recherche.Ici notamment l’internaute recherche un véhicule
de type voiture ...
Figure 3.5 – interface de la page de recher d’un véhicule selon les critères d’entrée
69
3.6.4 Interface fiche technique du véhicule

Les interfaces suivantes présentent le processus d’affichage d’un véhicule sélectionnée
(a) inteface affichage caractéristiques rela- (b) interface caractériqtiques relatif a la lo-
tif au véhicule selectionée cation du véhicule selectionée
Figure 3.6 – Interface de fiches technique d’un véhicule
70
3.6.5 Interface payement

afin de continuer la location de ce véhicule, le locataire à la possibilité de payement en ligne.
cette possibilté est représente par l’interface suivante
Figure 3.7 – interface de payement
71
3.6.6 Interface de signature

pour simplifier le processus de location, et faire en sorte que la majorité de cette transaction
se fasse en ligne. le locataire est invité a signer le contrat en ligne travers cette interface :
Figure 3.8 – interface e-signature
72
3.6.7 Interface de validation de la réservation

l’utilisateur au cours de sa réservation devra attendre un accord de réservation par la secrétaire
de l’agence avant de pouvoir poursuivre le processus de réservation. Cette validation de la demande
s’affiche pour le locataire comme ceci :
Figure 3.9 – interface de validation de la location
73
(a) inteface affichage contrat de location (b) interface affichage facture
Figure 3.10 – Interface de Contrat et facture relatif à la location
3.6.8 Interface d’affichage du Contrat et Facture de la location

l’interface suivante représente la dernière interface concernant le processus de location , a la
fin de ce dernier le contrat et la facture de la location concernée seront affichée comme suit
3.7 Conclusion
Dans ce chapitre, nous avons présenté la structure du site, des rappels sur l’architecture MVT
suivie , les langages que nous avons utilisés, ainsi que les autres outils techniques et matériels. Nous
avons aussi mentionné le processus du développement de l’intelligence artificielle, en terminant par
quelques aperçus qui montrent les différentes parties de ce travail.
74
Conclusion Générale
L’objectif de notre projet était de créer une application web pour une agence de location de
véhicules, cette application offre un ensemble de services de gestion de base ainsi que des nouvelles
fonctionnalités que nous avons juger nécessaire (gestion des comptes, modification d’état de la
réservation, établissement de liste d’exclus, signalement d’anomalies dans le véhicule, reconnais-
sance faciale, reconnaissance de signaux routier ..... )
Plusieurs technologies ont été utilisée pour la réalisation de ce projet, parmi lesquels on cite
le langages Python qui été l’outil le plus important durant le développement du Back-end de
l’application Web et notamment l’utilisation de ses framework ( Django, Rest API ...).Durant le
développement du Front-End on a notamment utilisée les technologies populaires (HTML, CSS,
JavaScript, React JS),Finalement pour l’élaboration de la base de données nous avons opté pour
l’utilisation du langage SQL.
A la fin du processus de développement, nous avons créer un produit fonctionnel répondant

aux normes de ce domaine et critères spécifiée dans le cahier de charges. Le présent travail nous
a permis d’acquérir des connaissances dans le domaine de la programmation web, et de renforcer
nos connaissances en conception logicielle.
Durant ce travail, nous avons essayé d’étudier et de comprendre le fonctionnement des agences
de location sur le plan national mais aussi les systèmes de location de véhicules existant à l’in-
ternational (Booking, Sixth ...).Après avoir synthétise les résultat de nos recherches, nous avons
tenter d’apporter les améliorations que nous trouvions nécessaire notamment celle suivantes :
— Facilité et simplicité d’utilisation de l’interface de l’application, que ce soit pour le client ou

pour le personnelle de l’agence.
— le client a la possibilité de louer un véhicule sans pour autant être le chauffeur de ce véhicule
— augmentation de la sécurité de la location en ajoutant un système de reconnaissance faciale

qui permettra d’activer le véhicule qu’en cas de reconnaissance du chauffeur prédéfinit
— la location poura se faire entièrement en ligne sans besoins de se déplacer à l’agence ce qui
permettra un gain de temps considérable pour les clients
— la secrétaire pourra vérifier la demande de location et donc accepter ou refuser la demande

à différente étapes
— le client a la possibilité de signaler un probléme avec le véhicule, qui sera pris en charge par
le garagiste une fois la location terminée
— le client a la possibilité de définir un lieu de départ et de retour différent
— la possibilité de récupérer l’historique d’un client (locations, extras, infractions ...)

Enfin, ce projet fut une expérience très intuitive, il nous a été très bénéfique nous avons pu
mettre en pratique nos connaissances théoriques acquises durant notre cursus, nous avons aussi pu
grâce à cette expérience développer des nouvelles compétence en programmation ( apprentissage
de nouveaux langages, développement de connaissance antérieur ... ). nous avons aussi pu nous
75
rendre compte de la complexité de développement d’un projet réel, ainsi que l’importance du
travail d’équipe.
Travaux Futur et Perspectives

— Développement d’une version mobile de l’application web
— Le propriétaire peut suivre la localisation des véhicules.
— Développement d’un algorithme de prédiction et suggestion des véhicules personnalisée se-

lon les profils des clients
— Établissement d’un système de messagerie entre les locataires et les chauffeurs
— Développement d’un système de livraison de véhicules jusqu’à l’adresse demandé par le client
— Ajout de fonctionnalités supplémentaires permettant la collocation de véhicules entre plu-

sieurs client
— Développement d’un système de suggestion de chauffeurs pour les locataires particulières
76
Troisième partie
Annexe
Annexe
Reconnaissance faciale
Ces capteurs représnte l’implémentation de fonctionnalité de réconnaissance faciale.
Figure 3.11 – fractions de l’implémentation de la reconnaissance faciale
78
79
80
Réconnaissance de signaux routier
Ces capteurs représnte l’implémentation de fonctionnalité de réconnaissance de signaux rou-
tier.
Figure 3.14 – implémentation du modèle de DL de reconnaissance des signaux routiers
81
Figure 3.15 – fractions de l’implémentation de la prédiction des signaux routiers
82
Figure 3.16 – fractions de l’implémentation des fonctions tiers de la reconnaissance des signaux
routiers
83
Réconnaissance de textes
Ces capteurs représnte l’implémentation de fonctionnalité de réconnaissance de textes.
Figure 3.17 – fractions de l’implémentation reconnaissance de textes
84

Rapport de PFE - Safa BENABDESSADOK

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de PFE - Safa BENABDESSADOK

Transféré par

Droits d'auteur :

Formats disponibles

République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Faculté des Nouvelles Technologies de l’Informatique et de la Communication

Projet de fin d’études pour l’obtention du diplôme de Licence en Informatique

Option : Génie Logiciel

Conception et réalisation d’un système intelligent pour la

gestion d’une agence de location des véhicules

Réalisé par : Dirigé par :

- Session Juin 2022 -

Nous remercions également :

1.1 Les Phases et les intérations d’UP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Le modele de domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1 Architechtre du MVT () . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

1.1 La table des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Analyse des besoins

1.2 Le processus Unifié (UP)

Figure 1.1 – Les Phases et les intérations d’UP

Num tâche Tâche Durée Prédécesseurs

Table 1.1 – La table des tâches

Figure 1.2 – Daigramme de GANTT

1.3 Expression des besoins

1.4 Expression des besoins

La gestion quotidienne de l’application web est une des responsabilité de l’administrateur .

1.4.2 Identification des acteurs

acteur Type Rôle

La modélisation de la communication de le systeme avec les acteures externe de système avec

1.4.3 Identification des besoins

Figure 1.3 – Diagramme de contexte statique

1.5 Spécification des besoins

1.5.1 Les besoins fonctionnels

1.5.2 Les Besoins non fonctionnels

1.5.3 Diagramme de cas d’utilisation

Diagramme de cas d’utilisation Global :

Figure 1.4 – Daigramme de cas d’utilisation

Description des Cas d’utilisation identifiée :

Consulter Facture : permet au locataire de consulter les détails de facturation associée à

Authentification : permet a un internaute de d’accéder à son compte et ainsi bénéficier des

S’inscrire : permet à un internaute anonyme de s’identifier .

Poser Question : permet à l’utilisateur du système de poser un questionnement concernant

Faire Réclamation : permet au locataire d’exprimer un mécontentement, qui sera pris en

Louer Véhicule : permet à un locataire de louer un véhicule disponible dans le catalogue de

Renouveler le contrat : Permet à un locataire de renouveler une location en cours, doit se

Valider réservation : permet à la secrétairerie après réception de la demande de location

Gérer état du système : gestion globale du système.

Conduire le véhicule : L’action de conduite du véhicule louée.

Identifier Chauffeur : Permet au locataire de type entreprise, d’identifier la personne qui se

Diagramme de cas d’utilisation en paquet

Figure 1.5 – Daigramme de cas d’utilisation en paquet

Le contenu de chauque paquet :

Figure 1.6 – Diagramme de cas d’utilisation en paquet ≪ paquet Garagiste ≫

Figure 1.7 – Diagramme de cas d’utilisation en paquet ≪ paquet Admin ≫

Figure 1.8 – Diagramme de cas d’utilisation en paquet ≪ paquet Locataire ≫

Figure 1.9 – Diagramme de cas d’utilisation en paquet ≪ paquet Profil ≫

Figure 1.10 – Diagramme de cas d’utilisation en paquet ≪ paquet Propriétaire ≫

Figure 1.11 – Diagramme de cas d’utilisation en paquet ≪ paquet Secritaire ≫

1.6 Maquettes IHM, fiches descriptives et diagramme de

Figure 1.12 – La maquette de la page d’inscription

Figure 1.13 – La maquette de la page d’accueil de site

(b) La maquette de la page d’affichage des

(c) La maquette de les formulaires pour les

La maquette suivante répresente la page de gestion des vehicules pour l’administrateur et

Figure 1.15 – La maquette de gestion des vehicules

(a) La maquette de consulter liste d’utilisateurs

(b) La maquette d’ajouter un utilisateur