République Tunisienne Université de Sfax

Ministère de l’Enseignement Supérieur et École Supérieure de Commerce

De la Recherche Scientifique

Rapport De Stage

Présenté pour l’obtention du diplôme de

Licence Appliquée en Informatique de gestion

Parcours : Commerce électronique

Développement d’une application

mobile pour la gestion de petites
annonces de véhicules

Présenté et soutenu publiquement par : Dirigé par :

Rached CHERIF Wissem ABBES (ESCS)

Mohamed Hedi Khanfir (WIPOU)

.

Année universitaire 2020 – 2021

 DEDICACES

« … À mes parents, à tous

ceux que j’aime, à tous ceux
qui m’aiment, à tous ceux qui
m’ont toujours aidé ... »
- Rached CHERIF
 REMERCIEMENTS

Ce projet n’aurait pas vu le jour sans le soutien, l’encouragement et la

contribution de nombreuses personnes à qui nous exprimons notre gratitude et
notre profonde reconnaissance. Mes remerciements s’adressent
particulièrement à :

 Mon encadrante universitaire Monsieur Wissem Abbes pour la qualité de

son encadrement, son encouragement et ses conseils qui nous ont été très
bénéfiques, sans oublier sa participation dans la réalisation de ce rapport.

 À tous les enseignants qui ont participé à notre évolution scientifique durant
les années écoulées de la formation à l’ESCS.

 À toutes les personnes qui ont contribué à l’élaboration de ce travail. Il n’est

malheureusement pas possible de les citer toutes ici, mais elles se reconnaîtront
et nous leur adressons nos plus profonds remerciements.
 LISTE DE FIGURES
Figure 1 : page d’accueil du site web "[Link]" ................................................................. 4
Figure 2 : Page d'accueil de site web sayarti ........................................................................... 5
Figure 3 : page d’accueil du site web [Link] ........................................................................ 6
Figure 4 : Page d’accueil du site web [Link] ............................................................. 6
Figure 5 : Page d’accueil du site web [Link] ............................................................................. 7
Figure 6 : Diagramme de cas d'utilisation ................................................................................... 11
Figure 7 : Diagramme de séquences du scénario inscription ..................................................... 21
Figure 8 : Diagramme de séquences du scénario ajouter annonce ............................................ 21
Figure 9 : Diagramme de séquences du scénario « modifier annonce », ................................... 22
Figure 10 : Diagramme de séquences du scénario supprimer annonce .................................... 23
Figure 11: Diagramme de classes .................................................................................................. 26
Figure 12: Diagramme de classes du front office ........................................................................ 29
Figure 13: Interface d'accueil de l'application ............................................................................ 30
Figure 14 : interface de la liste des annonces ............................................................................... 31
Figure 15 : interface de la page détaille d’une annonce .............................................................. 32
Figure 16 : Modèle physique de données ..................................................................................... 37
Figure 17 : Schéma de navigation ................................................................................................. 38
Figure 18: interface mobile inscription ........................................................................................ 39
Figure 19: Interface de connexion ................................................................................................ 40
Figure 20: page d'accueil ............................................................................................................... 41
Figure 21: interface de la liste des annonces ................................................................................ 42
Figure 22 : interfaces de détail d'une annonce (1) ....................................................................... 43
Figure 23: interfaces de détail d'une annonce (2) ........................................................................ 43
Figure 24: interface « déposer une annonce (1) » ........................................................................ 44
Figure 25 : interface « déposer une annonce (2) » ....................................................................... 45
Figure 26: interface Dashboard admin ajout catégorie .............................................................. 46
Figure 27: interface Dashboard ajoute annonce ......................................................................... 46
Figure 28: interface ajoute modèle ............................................................................................... 47
 LISTE DE TABLEAUX
Tableau 1 : Identification des acteurs .......................................................................................... 10
Tableau 2: Contenu informationnel ............................................................................................. 24
Tableau 3 : Dictionnaire de données ............................................................................................ 28
Tableau 4: Matériel utilisé ............................................................................................................. 34
 INTRODUCTION GENERALE

ujourd’hui, le commerce en ligne comprend tous les processus qui permettent de

A lancer et traiter un achat. Une boutique en ligne qui fonctionne comme une plate-
forme centrale sur laquelle les acheteurs potentiels peuvent non seulement passer
une commande, mais également payer via un système numérique dédié, ce qui a
poussé les entreprises à penser à une commercialisation plus rapide et plus moderne. Pour
cela les chercheurs ont pensé à concevoir de nouvelles méthodologies de commercialisation.

Dans ce contexte, notre projet de fin d’études vise à concevoir et à développer une
application mobile d'annonce spécialisée dans les véhicules.

Le présent rapport composé de 4 chapitre.

Le première chapitre est consacré à la présentation de l’organisme d’accueil, le projet ainsi

que nos objectis à atteindre, ensuite nous allons analyser l’existant et proposer une solution

Le deuxième chapitre sera consacré à l’objectif de l’application, le public visé et les

différentes descriptions de diagramme de cas d’utilisation ainsi quelques diagrammes de
séquences.

Le troiséme chapitre sera consacré à l’architecture de notre application mobile à travers le

diagramme de classes, le dectionnaire de données ainsi que l’aspect visuel de l’application.

Le quatrieme chapitre sera consacré à la phase de la réalisation avec une présentation des
environnements matériel et logiciel du travail, ansi que le modèle logique de données et la
modélisation physique. Aussi, nous présentons le shéma de navigation et les interfaces de
l’application.

1
CHAPITRE I : ÉTUDE
PREALABLE

2
Introduction
Dans ce premier chapitre, nous allons présenter l'organisme d'accueil, ensuite nous allons
présenter le contexte du sujet, et nous allons terminer par l’analyse de l’existant.

1 - Mission et Objectifs
1.1 - Mission
Le développement d’une application web/mobile (hybride) est désormais incontournable
dans la conquête de nouveaux marchés, la forte croissance de l’utilisation des nouvelles
générations de smartphones, nécessite des applications dédiées mobiles.

C’est la raison pour laquelle nous proposons de concevoir et de développer une application
hybride mobile.

1.2 - Objectifs
L’objectif général de notre application est de déposer les annonces de véhicules par des
annonceurs.

2 - Analyse de l’existant
L’étude de l’existant est une phase importante pour bien comprendre le système actuel et
définir ses objectifs en mettant en évidence les départements ou services impliqués dans la
présentation de projet.

2.1 - Présentation de l’entreprise

Fondée en 2014 à Sfax Tunisie, WIPOU est une agence digitale spécialisée dans le
développement des solutions Web et Mobile innovantes en se focalisant sur l'expérience
utilisateur (UX).

Elle est composée de développeurs et concepteurs web qui reposent sur une expérience
solide dans les nouvelles technologies et stratégies du domaine Web.

L’objectif principal de WIPOU est la satisfaction de ses clients en offrant des produits de
haute qualité qui répondent exactement aux exigences.

3
WIPOU offre les services suivants :

- Développement Web : le développement des sites web et des applications web.

- Développement Mobile : le développement des applications mobiles hybrides

(Android et Ios).

- Hébergement Cloud : permettant au client de déployer, de gérer et d’exécuter les

applications en ligne.

- Conseil en stratégie digitale et en web-marketing : Référencement et optimisation

SEO/SMO.

2.2 - Étude de sites web similaires

Il est important de faire une étude de marché de ce qu’il existe déjà pour englober le
fonctionnement des applications existant. Parmi les solutions disponibles sur le marché,
nous avons trouvé les sites web qui répondent aux besoins des consommateurs. Nous avons
pris ces exemples.

2.2.1 - Le site web Automobile ([Link]

Figure 1 : page d’accueil du site web "[Link]"

La figure 1 présente la page d’accueil de site web de automobile. Nous pouvons citer quelque
exemple de fonctionnalités qu’il existe dans ce site web : faire la création d’une annonce,

4
favoriser ces annonces , gérer les alertes en cas ou l’annonceur veut recevoir un email
d’alerte si une nouvelle annonce correspondant aux modèles qu’il recherche .

2.2.2 - Le site web Nayarit ([Link]

Figure 2: Page d'accueil de site web sayarti

La figure 2 présent la page d’accueil de site web sayarti. Nous pouvons citer quelque
exemple de fonctionnalité a savoir chercher les annonces, faire l’inscription a la newslettere,
espace d’actualité.

5
2.2.3 - Le site web Automoto ([Link]

Figure 3 : page d’accueil du site web [Link]

La figure 3 présente la page d’accueil de site web automoto. Les fonctionnalités de ce site
web sont : possibilité de déposer services ou annonces en tant que commerçant ou agence de
location auto, un espace de médias (actualité, divertissement, blog ).

2.2.4 - Le site web Argus automobile ([Link]

Figure 4 : Page d’accueil du site web [Link]

6
La figure 4 présent la page d’accueil de site web argusautmobile. Les fonctionnalités de ce
site web sont : un espace qu’il offre aux clients, l’évaluation et l’estimation des véhicules
d’occasion et encore la possibilité dépôt de vente des voitures d’occasion.

2.2.5 - Le site web Tayara ([Link]

Figure 5 : Page d’accueil du site web [Link]

La figure 5 présent la page d’accueil de site web tayara. Nous pouvons citer quelques
exemples de fonctionnalités : possibilité de client de déposer ces annonces et contacter
l’annonceur.

Conclusion
Dans ce premier chapitre, nous avons présenté le cadre général à travers la mission et
l’objectif. Ensuite, nous avons présenté l’analyse de l’existant à travers la présentation de
l’entreprise et l’étude des sites web similaires.

7
 CHAPITRE II :
MODELISATION DES
BESOINS

8
 Introduction
Dans ce chapitre nous détaillons en premier lieu, les différents diagrammes d’analyse tels
que le diagramme de cas d’utilisation et les diagrammes de séquences avec l’identification
et la représentation des scénarios. En deuxième lieu, nous présentons le diagramme de
classes de notre application.

1 - Objectif du l’application
Le travail que nous avons réalisé pendant notre période de stage se définit par développer
une application mobile qui a pour objectif de déposer les annonces de vente de véhicules et
des équipements de véhicules.

Notre solution proposée est de développer une application mobile qui consiste à :

- Améliorez l'ergonomie de l'application pour la rendre plus attractive.

- Permettre aux internautes, de :

 S’inscrire

 Contacter l’annonceur

 Rechercher une annonce

- Permettre aux annonceurs de :

 Gérer ces annonces

 Gérer son compte

- Permettre à L’administrateur de :

 Gérer les utilisateurs

 Gérer les catégories

 Gérer les marques

 Gérer les modèles

 Gérer Carburant

9
 2 - Public visé
Notre public visé est constitué de quatre types d’entreprises et des personnes qui veulent
acheter un véhicule.

Les entreprises visées sont les suivantes :

 Les constructeurs (Renault, Peugeot, Citroën, ...),

 Les équipementiers (fabricants des systèmes contrôle moteur, des tableaux de bord,
…)
 Les distributeurs (concessionnaires, …)
 Les réparateurs (mécaniciens, tôliers, …).

3- Services offerts
1) Diagramme de cas d’utilisation
1.1.1 Définition
Les diagrammes de cas d'utilisation décrivent les fonctions générales et la portée d'un
système. Ces diagrammes identifient également les interactions entre le système et ses
acteurs. [1]

1.1.2 Identification des acteurs

Acteur Rôle

C’est le web master de l’application qui gérer toutes les

L’administrateur
fonctionnalités.

L’internaute C’est un visiteur qui peut chercher une annonce ou s’inscrire

C’est un internaute qui déjà crée un compte, il peut donc ajouter ses
L’annonceur propres annonces de véhicules d’occasion ou des équipements de
véhicules.

C’est un internaute qui a déjà créé un compte professionnel, il peut

L’annonceur Pro
donc ajouter des nouvelles annonces de véhicules neuves ou des
(entreprise)
équipements de véhicules neufs.

Tableau 1 : Identification des acteurs

10
 1.1.3 Diagramme des cas d’utilisation
Nous allons utiliser les diagrammes de cas d’utilisation pour voir le comportement
fonctionnel de notre système. Ce diagramme aide à la compréhension du fonctionnement du
système afin de répondre aux différents besoins du client.

Figure 6 : Diagramme de cas d'utilisation

La figure 6 présente le diagramme de cas d’utilisation de notre application

11
 2) Identification et représentation des scénarios
 Description de cas d’utilisation « s’authentifier »

 Identification

Titre : S’authentifier
Acteurs : Annonceur, Annonceur Pro
Objectif : ce cas d’utilisation a pour objectif d’accéder à l’application.

 Description de scenario

- Précondition : le formulaire est affiché et l’internaute a un login et mot de passe

- Post condition : acteur authentifié,
- Scenario nominal :
1) L’acteur demande de s’authentifier
2) Formulaire de l’interface d’authentification est affiché
3) L’acteur saisit le login et le mot de passe
4) L’acteur cliquer sur « se connecter »
5) Le système vérifie les données et affiche l’interface personnel de celui-ci, si le login
et le mot de passe sont corrects sinon execption1 ou exception2 sont déclenchées.
6) L’acteur accède à la page d’accueil.

 Exceptions

Exception1 : le système affiche : «login invalide »

Exception2 : le système affiche : « mot de passe invalide »

 Cas d’utilisation « Gérer annonce »

 Description de cas d’utilisation « Ajouter annonce »

 Identification

Titre : Ajouter annonce

Acteurs : annonceur, annonceur Pro
Objectif : ce cas d’utilisation a pour objectif ajouter des annonces des véhicules.

12
 Description des scenarios

- Pré condition : Acteur authentifié

- Post condition : annonce ajoutée avec succès.
- Scenario nominal :
1) L’acteur demande d’ajouter une annonce
2) Formulaire d’ajout d’une annonce est affiché
3) L’acteur remplit le formulaire et saisit les informations de l’annonce
4) L’acteur clique sur « se connecter »
5) Le système vérifie les données et les ajoute à la base de données puis il affiche un
message de réussite, sinon execption1 est déclenchée
- Les scenarios alternatifs :
 Modifier annonce :
Ce scénario débute lorsque l’acteur demande de modifier une annonce.
1) Le système affiche la page de liste des annonces
2) L’acteur peut modifier ou un plusieurs
3) Le système modifie le ou les annonces désirées
 Supprimer annonce :
Ce scénario débute lorsque l’acteur demande de supprimer une annonce.
1) Le système affiche la page de liste des annonces
2) L’acteur peut supprimer ou un plusieurs
3) Le système supprimer le ou les annonces désirées
 Recherche annonce :
Ce scénario débute lorsque l’acteur demande de rechercher une annonce
1) L’acteur clique sur la barre de recherche qui se trouve dans la page d’accueil
2) L’acteur tape son mot-clé
3) L’acteur lance la recherche
4) Le system vérifié l’existant de l’annonce
5) Le système affiche l’annonce

 Exception

Exception1 : le système affiche « invalidité de champ »

13
  Cas d’utilisation « Gérer compte » :

 Description de cas d’utilisation « Modifier compte »

 Identification

Titre : Modifier annonce

Acteurs : annonceur, annonceur Pro
Objectif : ce cas d’utilisation a pour objectif de modifie compte

 Description des scenarios

- Précondition : Les informations du compte ont été mises à jour.

- Post condition : mise à jour avec succès.
- Scenario nominal :
1) L’acteur choisi le compte à modifier
2) Le système affiche le formulaire de modification
3) L’annonceur modifie les informations et valide
4) Le système vérifie les données saisies
5) Le système enregistre les données.
 Scenario alternatif

1) L’acteur saisi des données manquantes ou invalides

2) Le système affiche un message d’erreur
3) Reprise de l’étape 3 du scénario nominal

 Cas d’utilisation « Gérer utilisateur » :

 Description de cas d’utilisation « ajouter utilisateur » :

 Identification

Titre : ajouté un utilisateur

Acteurs : administrateur
Objectif : ce cas d’utilisation a pour objectif d’ajouter un nouvel utilisateur

 Description des scenarios

- Précondition : Une authentification préalable de l’administrateur

14
 - Post condition : Un nouvel utilisateur est ajouté
- Scenario nominal :
1) L’administrateur faire la connexion au système
2) Le système valide
3) L’administrateur demande d'enregistrer un nouvel utilisateur
4) Le système retourne un formulaire d'enregistrement
5) L’administrateur rempli les champs nécessaires et valide
6) Le système vérifie les données saisies et l’ajoute à la base de données puis il affiche
l’utilisateur qui été ajouté sinon exception1 est déclenchée
- Les scenarios alternatifs :
 Modifier utilisateur :
Ce scénario débute lorsque l’administrateur demande de modifier un utilisateur.
1) L’administrateur choisi le compte à modifier
2) Le système affiche le formulaire de modification
3) L’administrateur modifie les informations et valide
4) Le système vérifie les données saisies
5) Le système enregistre les données

 Supprimer utilisateur :
Ce scénario débute lorsque l’administrateur demande de supprimer un utilisateur.
1) L’administrateur choisi le compte à supprimer
2) Le système affiche un message de confirmation
3) L’administrateur valide son choix
4) Le système supprime le compte

 Exception

Exception1 : le system affiche : « utilisateur est déjà existé »

 Cas d’utilisation « Gérer catégories » :

 Description de cas d’utilisation « Ajouter catégorie »

 Identification

Titre : Ajouter catégorie

Acteurs : l’administrateur

15
Objectif : ce cas d’utilisation a pour objectif d’ajouter une catégorie

 Description des scenarios

- Pré condition : l’administrateur s’authentifier

- Post condition : catégorie ajoutée avec succès.
- Scenario nominal :
1) L’administrateur demande d’ajouter une catégorie
2) Formulaire d’Interface ajouter une catégorie s’affiche
3) L’administrateur remplir le formulaire et saisir les informations
4) L’administrateur cliquer sur « ajouter »
5) Le système vérifie les données et les ajoute à la base de données puis il affiche
message de réussie, sinon exception1 est déclenchée
- Les scenarios alternatifs :
 Modifier catégorie :
Ce scénario débute lorsque l’administrateur demande de modifier une catégorie.
1) L’administrateur sélectionne une catégorie qui sera modifié
2) L’administrateur demande de modifier la catégorie
3) Formulaire d’Interface de modifier une catégorie s’affiche
4) L’administrateur modifier les champs de catégorie
5) L’acteur cliquer sur « modifier »
6) Le système vérifie la validité des champs modifiés.
7) Le système afficher message modification réussi si les champs est correct
Le système enregistre la modification.
 Supprimer catégorie :
Ce scénario débute lorsque l’administrateur demande de supprimer une catégorie.
1) L’administrateur choisir d’afficher la liste des catégories
2) Le system affiche la liste des catégories
3) L’acteur sélectionne l’annonce à supprimer
4) L’acteur click sur le bouton « supprimer »
5) Le système demande la validation de la suppression.
6) L’acteur valide ou annule la suppression
7) Le système effectue l’opération et affiche « catégorie est supprimé »

16
 Exception

Exception1 : le system affiche « invalidité du champs »

 Cas d’utilisation « Gérer marque » :

 Description de cas d’utilisation « Ajouter marque »

 Identification

Titre : Ajouter une marque

Acteur : Administrateur
Objectif : ce cas d’utilisation a pour objectif d’ajouter une marque

 Description des scenarios

- Précondition : administrateur est déjà identifié

- Post condition : marque ajoutée avec sucées
- Scenario nominal :
1) L’administrateur choisit d’ajouter d’une nouvelle marque
2) Le système affiche le formulaire à remplir.
3) L’administrateur saisit les informations à remplir d’une nouvelle marque
4) Le système vérifie les données si la marque existe déjà le système déclenche
l’exception1 sinon l’écran système actualise la liste des marques et l’affiche de
nouveau.
- Les scenarios alternatifs :
 Modifier marque :
Ce scénario débute lorsque l’administrateur demande de modifier une marque.
1) L’administrateur choisit de modifier une marque.
2) L’acteur choisit la marque à modifier.
3) Le système affiche le formulaire de modification.
4) L’acteur modifie les informations de marque choisie.
5) Le système demande la validation des modifications.
6) L’acteur valide ou annule la modification.

17
  Supprimer marque :
Ce scénario débute lorsque l’administrateur demande de supprimer une marque.
1) L’administrateur choisit d’afficher la liste des marques
2) Le système affiche la liste.
3) L’administrateur choisit le modèle à supprimer et clique sur le bouton supprimer
4) Le système demande la validation de la suppression.
5) L’administrateur valide ou annule la suppression.
6) Le système effectue l’opération et affiche à nouveau la liste des marques.

 Exception

Exception1 : si la marque existe déjà le système affiche « marque existant ».

 Cas d’utilisation « Gérer modèle » :

 Description de cas d’utilisation « Ajouter modèle »

 Identification

Titre : Ajouter un modèle

Acteur : Administrateur
Objectif : ce cas d’utilisation a pour objectif d’ajouter un modèle

 Description des scenarios

- Précondition : administrateur est déjà identifié

- Post condition : modèle ajoutée avec sucées
- Scenario nominal :
1) L’administrateur choisit d’ajouter d’un nouveau modèle.
2) Le système affiche le formulaire à remplir.
3) L’acteur saisit les informations à remplir d’un nouveau modèle.
4) Le système vérifie les données si la marque existe déjà le système déclenche.
L’exception1 sinon l’écran système actualise la liste des marques et l’affiche de
nouveau.
- Les scenarios alternatifs :
 Modifier modèle :
Ce scénario débute lorsque l’administrateur demande de modifier un modèle.
1) L’administrateur choisit de modifier un modèle

18
 2) L’administrateur choisit le modèle à modifier.
3) Le système affiche le formulaire de modification
4) L’administrateur modifie les informations de modèle choisi
5) Le système demande la validation des modifications.
6) L’administrateur valide ou annule la modification
 Supprimer modèle :
Ce scénario débute lorsque l’administrateur demande de supprimer un modèle.
1) L’administrateur choisit d’afficher la liste des modèles
2) Le système affiche la liste.
3) L’acteur choisit le modèle à supprimer et clique sur le bouton supprimer
4) Le système demande la validation de la suppression.
5) L’acteur valide ou annule la suppression.
6) Le système effectue l’opération et affiche à nouveau la liste des modèles.
 Exception

Exception1 : si la marque existe déjà le système affiche « modèle existant ».

 Cas d’utilisation « Gérer carburant » :

 Description de cas d’utilisation « Ajouter carburant »

 Identification

Titre : Ajouter un carburant

Acteur : Administrateur
Objectif : ce cas d’utilisation a pour objectif d’ajouter un carburant

 Description des scenarios

- Précondition : administrateur est déjà identifié

- Post condition : carburant ajoutée avec sucées
- Scenario nominal :
1) L’administrateur choisit d’ajouter d’un nouveau carburant
2) Le système affiche le formulaire à remplir.
3) L’acteur saisit les informations à remplir d’un nouveau carburant

19
 4) Le système vérifie les données si la carburant existe déjà le système déclenche
l’exception1 sinon l’écran système actualise la liste des carburants et l’affiche de
nouveau.
- Les scenarios alternatifs :
 Modifier carburant :
Ce scénario débute lorsque l’administrateur demande de modifier un carburant.
1) L’administrateur choisit de modifier un carburant
2) L’acteur choisit le carburant à modifier.
3) Le système affiche le formulaire de modification
4) L’acteur modifie les informations de carburant choisi
5) Le système demande la validation des modifications.
6) L’acteur valide ou annule la modification
 Supprimer modèle :
Ce scénario débute lorsque l’administrateur demande de supprimer un carburant.
1) L’administrateur choisit d’afficher la liste des carburants
2) Le système affiche la liste.
3) L’acteur choisit le carburant à supprimer et clique sur le bouton supprimer
4) Le système demande la validation de la suppression.
5) L’acteur valide ou annule la suppression.
6) Le système effectue l’opération et affiche à nouveau la liste des carburants.
 Exception

Exception1 : si la marque existe déjà le système affiche « carburant existant ».

2.1 Diagrammes de séquences

Pour schématiser la vue dynamique de notre système informatique, nous faisons recours au
diagramme de séquence d’UML. Ce schéma permet de présenter l'interaction entre l'acteur
système avec des messages présentés dans l'ordre. En nous référant à la description textuelle
de la section précédente, nous présentons les diagrammes de séquence adéquats à notre
système. En effet, nous avons sélectionné quelques exemples pour les traiter.

20
2.1.1 Diagramme de séquences du scénario « Inscription »

Figure 7 : Diagramme de séquences du scénario inscription

La figure 7 représente le diagramme de séquences du scénario « inscription », qui est

composé par les objets annonceur, Écran d’inscription, et contrôleur d’inscription.

2.1.2 Diagramme de séquences du scénario « ajouter annonce »

Figure 8 : Diagramme de séquences du scénario ajouter annonce

21
La figure 8 représente le diagramme du scénario « ajouter annonce », qui est composé par
les objets annonceur, Écran d’ajout d’une annone, contrôleur d’ajout d’une annonce et
annonce.

2.1.3 Diagramme de séquences du scénario « modifier annonce »

Figure 9 : Diagramme de séquences du scénario « modifier annonce »,

La figure 9 représente le diagramme de séquences du scénario « modifier annonce », qui est

composé par les objets annonceur, Écran de modification, contrôleur de modification et
annonce.

22
2.1.4 Diagramme de séquences du scénario « supprimer annonce »

Figure 10 : Diagramme de séquences du scénario supprimer annonce

La figure 10 représente le diagramme de séquences du scénario « supprimer annonce », qui

est composé par les objets annonceur, Écran de suppression, contrôleur de suppression et
annonce.

2.2 Contenu informationnel

Contenu rédactionnel Objectifs

Limiter l’accès à travers un nom d’utilisateur et un mot

Accès autorisé
de passe.

Recherche annonce qui peut

être par :
Avoir les caractéristiques d’une annonce
 Catégorie
 Prix

23
 Offre aux entreprises et aux clients la possibilité
Ajouter annonce
d’ajouter ses annonces.

Offre la possibilité aux internautes de contacter les

Contacter annonceur
annonceurs
Tableau 2: Contenu informationnel

Conclusion
Dans ce chapitre nous avons présenté la modélisation des besoins. Ensuite, nous avons
présenté l’application à réaliser de façon détaillée, commençant par décrire l’objectif de
l’application, le public visé en passant au diagramme de cas d’utilisation ensuite
l’identification et représentation des scénarios et enfin le diagramme de classes.

24
 CHAPITRE III :
MODELISATION
CONCEPTUELLE

25
 Introduction
Dans ce chapitre nous détaillons en premier lieu, les différentes architectures statiques de
notre application et en deuxième lieu l’aspect visuel.

1 - Architecture statique
1.1 - Architecture du Back Office
1.1.1 Diagramme de classes

Figure 11: Diagramme de classes

La figure 11 représente le diagramme de back office de notre application.

1.1.2 Dictionnaire des données

Le tableau suivant représente le dictionnaire de données de notre diagramme de classes.

26
 Class Attribut Libellé
Id Id d’un annonceur

name Nom d’un annonceur

User email Email d’un annonceur

password Mot de passe de l’annonceur

tel Téléphone d’un annonceur

Système d'identification du répertoire des

siret
entreprises
Catégorie qui associé à l’activité d’un
cat_activite
annonceur pro
User pro
adresse Adresse d’un annonceur pro

codePostal Code postal de l’annonceur pro

Id Id d’un annonce

title Titre d’un annonce

Annonce
description Description de l’annonce

Price Prix de l’annonce

Id Id d’un véhicule

boite_de_vitesse Boite de vitesse d’un véhicule

AnneeModele Année de modèle d’un véhicule

Véhicule type_annonce Type d’annonce d’un véhicule

puissance_fiscale Puissance fiscale d’un véhicule

nombreDePorte Nombre de porte d’un véhicule

nombreDeplace Nombre de place d’un véhicule

27
 cylindre Cylindre d’un véhicule

kilometrage Kilométrage d’un véhicule

Id Id d’une catégorie

name Nom d’une catégorie

Catégorie
picture Photo d’une catégorie

description Description d’une catégorie

Poids total autorisé en charge d’un

Camion ptac_camion
camion

Moto frein_moto Frein d’une moto

Utilitaire longueur_utile_utilitaire Longueur d’un véhicule utilitaire

Voiture voies_voiture La voies d’une voiture

id_marque Id d’une marque

marque_vehicule
nom_marque Nom d’une marque

id_modele Id d’un modèle

Modèle
nom_modele Nom d’un modèle

id_carburant Id d’un carburant

Carburant
nom_carburant Nom d’un carburant
Tableau 3 : Dictionnaire de données

28
1.2 - Architecture du Front Office

Figure 12: Diagramme de classes du front office

29
2 - Aspect visuel
2.1 Maquette de la page d’accueil

Figure 13: Interface d'accueil de l'application

La figure 12 représente l’interface de la page d’accueil de notre application

30
 2.2 Maquette de la page des annonces

Figure 14 : interface de la liste des annonces

La figure 13 représente l’interface de la liste des annonces de notre application

31
 2.3 Maquette de la page du détaille d’annonce

Figure 15 : interface de la page détaille d’une annonce

La figure 14 représente le détaille d’une annonce de notre application

Conclusion
Dans ce chapitre nous avons présenté la modélisation conceptuelle de notre projet. Nous
avons commencé par le back office et le front office. Ensuite, nous avons présenté l’aspect
visuel à travers les maquettes de notre application.

32
 CHAPITRE IV :
REALISATION DE
L’APPLICATION
MOBILE

33
 Introduction
Ce chapitre se divise en trois parties. La première partie concerne l’Environnement matériel
et logiciel et la deuxième partie concerne le modèle logique et la modélisation physique de
donnée de notre application et la dernière contient quelque interface de l’application.

1 - Environnements de réalisation
1.1 - Environnement matériel
Pour la réalisation et la conception de cette application, nous avons utilisé un ordinateur
portable dont la configuration est présentée par le tableau suivant.

Caractéristique Type
Marque HP

Processus Intel(R) Core i3-5005U [email protected] 2.00GHz

Mémoire vive 4GO

Système d’exploitation Windows 10

Tableau 4: Matériel utilisé

1.2 - Environnement logiciel

Dans cette partie, nous présentons les outils, les langages de programmation et les
Framework utilisés tout au long de développement de notre application.

1.2.1 Les Framework utilisés

Les langages de programmation utilisés pour le développement de notre système sont
présentés dans le tableau 3 ci-dessous :

 Ionic Framework est une boîte à outils d'interface utilisateur open source permettant
de créer des applications natives et de bureau performant et de haute qualité à l'aide
de technologies Web HTML, CSS et JavaScript avec des intégrations pour des
Framework populaires comme Angular, React et Vue. [2]

34
  Angular est une plateforme de développement qui permet de créer des applications
web dynamiques et immersives. [3]-

 Laravel est un Framework d'application Web avec une syntaxe expressive et

élégante. Un Framework Web fournit une structure et un point de départ pour la
création de votre application. [4]

1.2.2 Outils de développement et modélisation :

Nous présentons les outils utilisés pendant le développement de notre application :

 MySQL Database Service est un service de base de données entièrement géré pour
déployer des applications natives du Cloud en utilisant la base de données open
source la plus populaire au monde [5]

 XAMPP est l'environnement de développement PHP le plus populaire. XAMPP

est une distribution Apache entièrement gratuite et facile à installer contenant
MySQL, PHP et Perl. Le paquetage open source XAMPP a été mis au point pour
être incroyablement facile à installer et à utiliser. [6]

 Postman est une plate-forme de collaboration pour le développement d'API. Les

fonctionnalités de Postman simplifient chaque étape de la création d'une API et
rationalisent la collaboration afin que vous puissiez créer de meilleures API, plus
rapidement. [7]
 Visual Studio Code est un éditeur de code extensible développé par Microsoft
pour Windows, Linux et macOS. Les fonctionnalités incluent la prise en charge du
débogage, la mise en évidence de la syntaxe, la complétion intelligente du code, les
snippets, la refactorisation du code et Git intégré. [8]

 Visual Paradigm est un logiciel de création de diagrammes dans le cadre d'une

programmation. Tout en un, il possède plusieurs options permettant une large possibilité
de modélisation en ULM. [9]

35
2 - Vers la réalisation du l’application
2.1 - Passage du diagramme de classes au modèle logique de
données
La modélisation logique des données permet de modéliser la structure selon laquelle les
données seront stockées dans la future base de données, est adapté à une famille de SGBD
et ainsi de mieux comprendre les relations entre les différentes tables.

user (id, name, email, password,#id_vehicule)

user_pro (siret, catActivity, adresse, codePostal, # id_user)
post (id, title, description, price)

vehicule(id, boite_de_vitesse, AnneeModele, type_annonce, puissance_fiscale,

nombreDePorte, nombreDeplace, cylindre, kilometrage, # id_modele, #id_marque,
id_carburant, # id_photo)

categorie (id, name, picture, description)

camion (ptac_camion, # id_vehicule)

moto ( frein_moto, # id_vehicule )
utilitiare (longueur_utile_utilitaire, # id_vehicule )
voiture ( voies_voiture, # id_vehicule )
photo(id_photo)
marque_vehicule (id_marque,nom_marque )

modele (id_modele,nom_modele, #id_marque)

carburant (id_carburant, nom_carburant )

36
2.2 - Modélisation physique de données

Figure 16 : Modèle physique de données

La figure 15 représente le modèle physique de données de notre application.

3- Schéma de navigation de l’application

37
 Figure 17 : Schéma de navigation

La figure 16 représente le schéma de navigation de notre application

38
4 - Réalisation de l’aspect visuel du notre
application
4.1 Partie Client
4.1.1 Interface mobile « inscription »

Figure 18: interface mobile inscription

La figure 18 représente l’interface mobile d’inscription.

39
4.1.2 Interface mobile « login »

Figure 19: Interface de connexion

La figure 19 représente l’interface mobile de connexion

40
4.1.3 Interface mobile « page d’accueil »

Figure 20: page d'accueil

La figure 20 représente l’interface de page d’accueil.

41
4.1.4 Interface mobile « interface liste des annonces »

Figure 21: interface de la liste des annonces

La figure 21 représente l’interface de la liste des annonces.

42
4.1.5 Interface mobile « détaille annonce »

Figure 22 : interfaces de détail d'une annonce (1)

La figure 22 représente la première interface de détail d’une annonce

4.1.6 Interface mobile « détaille annonce »

Figure 23: interfaces de détail d'une annonce (2)

43
La figure 23 représente la deuxième interface de détaille annonce

4.1.7 Interface mobile « déposer annonce »

Figure 24: interface « déposer une annonce (1) »

La figure 24 représente la première interface de déposer une annonce

44
4.1.8 Interface mobile « déposer annonce »

Figure 25 : interface « déposer une annonce (2) »

La figure 25 représente la deuxième interface de déposer une annonce

45
4.2 Partie Administrateur
4.2.1 Interface «ajout catégorie »

Figure 26: interface Dashboard admin ajout catégorie

La figure 26 représente l’interface Dashboard de l’admin d’ajouter catégorie

4.2.2 Interface « ajoute annonce »

Figure 27: interface Dashboard ajoute annonce

46
La figure 27 représente l’interface Dashboard de l’admin d’ajouter catégorie

4.2.3 Interface « ajoute modèle »

Figure 28: interface ajoute modèle

La figure 28 représente l’interface Dashboard de l’admin d’ajouter modèle

Conclusion
Au cours de ce dernier chapitre, nous avons détaillé l’implémentation de notre projet. Tout
d’abord nous avons commencé par présenter les environnements matériels et logiciels sur
lesquels nous avons travaillé durant notre projet. Ensuite, nous avons détaillé notre modèle
logique de données ainsi notre modèle physique de données. Ensuite nous avons présenté le
schéma de navigation de notre application

Et finalement, nous avons exposé le résultat de développement en présentant les interfaces

des différents modules de notre projet.

47
 CONCLUSION GENERALE

Notre stage a été une expérience enrichissante qui nous a permis d’une part d’appliquer et
d’approfondir nos connaissances acquises tout au long de notre formation à l’ESCS et
d’autre part, de nous familiariser avec la conduite des projets informatiques et d’explorer le
milieu professionnel.

Dans ce stage, nous étions chargés de développer une application mobile pour la gestion de
petite annonce de véhicule qui permet aux internautes de publier les différents types des
véhicules ainsi leurs équipements.

Le point de départ de la réalisation de ce projet était une récolte des informations nécessaires
pour dresser un état de l’existant, présenter un aperçu sur l’objectif du projet ainsi que la
solution. Par la suite, nous nous sommes intéressés à la modélisation des besoins qui nous
a permis de définir les fonctionnalités qui devraient être présentes dans le projet, ainsi que
la conception, dans laquelle nous avons fixé la structure globale de notre application. Le
dernier volet de notre projet était la partie réalisation qui a été consacrée par la présentation
des outils du travail et les interfaces les plus significatifs de notre application.

Finalement, au terme de ce stage, nous avons eu la satisfaction d’avoir réalisé ce projet

suivant un plan bien organisé. Mais plus que cette satisfaction, nous avons eu le plaisir de
travailler dans un domaine qui nous passionne.

48
 WEBLIOGRAPHIE
[1] : [Link]
[2] : [Link]
[3] : [Link]
[4] : [Link]
[5] : [Link]
[6] : [Link]
[7] : [Link]
[8] : [Link]
[9] : [Link]
 TABLE DE MATIERES
DEDICACES........................................................................................................................ 3
REMERCIEMENTS ........................................................................................................... 4
LISTE DE FIGURES .......................................................................................................... 5
LISTE DE TABLEAUX...................................................................................................... 6
INTRODUCTION GENERALE ........................................................................................ 1
CHAPITRE I : ÉTUDE PREALABLE ............................................................................. 2
INTRODUCTION ................................................................................................................... 3
1 - MISSION ET OBJECTIFS ................................................................................................ 3
1.1 - Mission ................................................................................................................... 3
1.2 - Objectifs ................................................................................................................. 3
2 - ANALYSE DE L’EXISTANT ............................................................................................ 3
2.1 - Présentation de l’entreprise ................................................................................... 3
2.2 - Étude de sites web similaires ................................................................................. 4
2.2.1 - Le site web Automobile ([Link] .................................... 4
2.2.2 - Le site web Nayarit ([Link] .................................................. 5
2.2.3 - Le site web Automoto ([Link] ................................................... 6
2.2.4 - Le site web Argus automobile ([Link] ................. 6
.................................................................................................................................... 6
2.2.5 - Le site web Tayara ([Link] .................................................... 7
CONCLUSION....................................................................................................................... 7
CHAPITRE II : MODELISATION DES BESOINS ....................................................... 8
INTRODUCTION ................................................................................................................... 9
1 - OBJECTIF DU L’APPLICATION ....................................................................................... 9
2 - PUBLIC VISE ............................................................................................................... 10
3 - SERVICES OFFERTS .................................................................................................... 10
1) Diagramme de cas d’utilisation ............................................................................ 10
1.1.1 Définition ....................................................................................................... 10
1.1.2 Identification des acteurs ............................................................................... 10
1.1.3 Diagramme des cas d’utilisation.................................................................... 11
2) Identification et représentation des scénarios ...................................................... 12
2.1 Diagrammes de séquences ..................................................................................... 20
2.1.1 Diagramme de séquences du scénario « Inscription »................................... 21
2.1.2 Diagramme de séquences du scénario « ajouter annonce »........................... 21
2.1.3 Diagramme de séquences du scénario « modifier annonce » ........................ 22
2.1.4 Diagramme de séquences du scénario « supprimer annonce » ..................... 23
2.2 Contenu informationnel..................................................................................... 23
CONCLUSION..................................................................................................................... 24
CHAPITRE III : MODELISATION CONCEPTUELLE ............................................. 25
 INTRODUCTION ................................................................................................................. 26
1 - ARCHITECTURE STATIQUE ......................................................................................... 26
1.1 - Architecture du Back Office ................................................................................. 26
1.1.1 Diagramme de classes ................................................................................... 26
1.1.2 Dictionnaire des données ............................................................................... 26
1.2 - Architecture du Front Office................................................................................ 29
2 - ASPECT VISUEL .......................................................................................................... 30
2.1 Maquette de la page d’accueil .......................................................................... 30
2.2 Maquette de la page des annonces .................................................................... 31
2.3 Maquette de la page du détaille d’annonce ...................................................... 32
CONCLUSION..................................................................................................................... 32
CHAPITRE IV : REALISATION DE L’APPLICATION MOBILE .......................... 33
INTRODUCTION ................................................................................................................. 34
1 - ENVIRONNEMENTS DE REALISATION .......................................................................... 34
1.1 - Environnement matériel ....................................................................................... 34
1.2 - Environnement logiciel ........................................................................................ 34
1.2.1 Les Framework utilisés .................................................................................. 34
1.2.2 Outils de développement et modélisation : ................................................... 35
2 - VERS LA REALISATION DU L’APPLICATION................................................................. 36
2.1 - Passage du diagramme de classes au modèle logique de données ..................... 36
2.2 - Modélisation physique de données ...................................................................... 37
3 - SCHEMA DE NAVIGATION DE L’APPLICATION ............................................................. 37
4 - REALISATION DE L’ASPECT VISUEL DU NOTRE APPLICATION...................................... 39
4.1 Partie Client ...................................................................................................... 39
4.1.1 Interface mobile « inscription » ........................................................................ 39
4.1.2 Interface mobile « login » ................................................................................. 40
4.1.3 Interface mobile « page d’accueil » .................................................................... 41
4.1.4 Interface mobile « interface liste des annonces » ............................................... 42
4.1.5 Interface mobile « détaille annonce » ................................................................. 43
4.1.6 Interface mobile « détaille annonce » ................................................................. 43
4.1.7 Interface mobile « déposer annonce » ................................................................ 44
4.1.8 Interface mobile « déposer annonce » ................................................................ 45
4.2 Partie Administrateur........................................................................................ 46
4.2.1 Interface «ajout catégorie » ................................................................................ 46
4.2.2 Interface « ajoute annonce » ............................................................................... 46
4.2.3 Interface « ajoute modèle » ................................................................................. 47
CONCLUSION..................................................................................................................... 47
CONCLUSION GENERALE........................................................................................... 48
WEBLIOGRAPHIE ............................................................................................................ 1
TABLE DE MATIERES ..................................................................................................... 2