Pfe Islem Ryhem

DEDICACES
Dédicaces Du profond de mon cœur

Je dédie ce travail à tous ceux qui me sont chers,
À Mes Très Chers Parents
Que ce travail soit l’expression de ma reconnaissance pour vos sacrifices consentis,

votre soutien moral et matériel que vous n’avez cesse de prodiguer. Vous avez
tout fait pour mon bonheur et ma réussite.
Que Dieu vous préserve en bonne santé et vous accorde une longue vie.
À ma sœur
Nourhene Rezgui
Vous étiez toujours présents pour m’aider et m’encourager. Je vous souhaite une
vie pleine de bonheur et de succès et que Dieu vous protège et vous garde.
À Tous mes amis. . . .
Rezgui Islem
J’aimerai dédier ce rapport,
À mes Parents,
Qui m’ont comblé de leur soutien et m’ont voué un amour inconditionnel. Vous
êtes pour moi un exemple de courage et de sacrifice continu. Que cet humble
travail témoigne mon affection, mon éternel attachement et qu’il appelle sur moi
vos continuelles bénédictions.
À mes frères et ma sœur,
Pour leurs compréhensions, leurs soutiens, leurs tendresses... Qu’ils trouvent ici
l’expression de ma reconnaissance et le témoignage de ma gratitude ressentie. À
ceux qui m’aiment, Que ce modeste travail vous honore et vous témoigne mes
reconnaissances.
À mes amis et à toute la promo à l’ISSATM,
Arjouni Ryhem
REMERCIEMENTS
A u terme de ce travail, nous tenons à exprimer mes remerciements envers toutes

les personnes qui ont contribué au bon déroulement de ce Projet de Fin d’Étude.
Tout d’abord, nous adressons nos sincères remerciements et notre profonde gra-
titude à notre encadrant M.JAMEL SLIMI pour son encadrement de qualité , sa
disponibilités et pour tous ses conseils judicieux tout au long de ce projet.
Nous tenons aussi à exprimer nos vifs sentiments de gratitude à M.ACHREF SE-
LEOUI pour sa disponibilité, sa générosité, ses directives et ses conseils.
Nous tenons aussi à exprimer notre profond respect à toute l’équipe de travail qui
nous ont fourni le cadre nécessaire pour la réalisation de notre projet. Nous avons
eu l’honneur et le plaisir de travailler au sein d’une aussi dynamique équipe.
Par ailleurs, nous adressons nos sincères remerciements aux membres du jury pour
avoir bien voulu examiner et juger ce travail.
Nous remercions enfin tous les enseignants de l’Institut Supérieur des Sciences
Appliquées et de Technologie de Mateur.
TABLE DES MATIÈRES
1 CADRE GENERAL DU PROJET 2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Preséntation de l’organisme d’Acceuil . . . . . . . . . . . . . . . . . . 3
1.3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . 4
1.7 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7.1 Méthode agile SCRUM . . . . . . . . . . . . . . . . . . . . . . . 5
1.7.2 Pourquoi SCRUM ? . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.7.3 Les acteurs SCRUM : . . . . . . . . . . . . . . . . . . . . . . . . 5
1.7.4 Les évenements SCRUM : . . . . . . . . . . . . . . . . . . . . . 6
1.8 La modélisation objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.8.1 Définition de UML . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.8.2 Processus de modélisation . . . . . . . . . . . . . . . . . . . . 7
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 ANALYSE ET SPECIFICATION DES BESOINS 9

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 11
2.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Raffinement des cas d’utilisations . . . . . . . . . . . . . . . . . . . . 13
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 CONCEPTION 23
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 L’architecture 2-tiers . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.3 Description d’un service web . . . . . . . . . . . . . . . . . . . 26
3.1.4 Choix de l’architecture . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 RÉALISATION DE L’APPLICATION 35
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1 Envirennement du travail . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.3 Langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.4 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Interface Homme-Machine . . . . . . . . . . . . . . . . . . . . . 44
4.2.2 Espace d’administrateur . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2.1 Gestion des annonce . . . . . . . . . . . . . . . . . . 47
4.2.2.2 Gestion des Catégories . . . . . . . . . . . . . . . . . 48
4.2.2.3 Gestion Utilisateur . . . . . . . . . . . . . . . . . . . . 49
4.2.3 Espace Utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 50
TABLE DES FIGURES
1.1 Méthodologie SCRUM [1] . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Diagramme général de cas d’utilisation . . . . . . . . . . . . . . . . . 12

2.2 Cas d’utilisation " Gérer les catégories" . . . . . . . . . . . . . . . . . 13
2.3 Cas d’utilisation " Supprimer annonce" . . . . . . . . . . . . . . . . . 15
2.4 Cas d’utilisation " Gérer les réclamations" . . . . . . . . . . . . . . . 17
2.5 Cas d’utilisation " Gérer les utilisateurs" . . . . . . . . . . . . . . . . 18
2.6 Cas d’utilisation " Gérer les annonces" . . . . . . . . . . . . . . . . . 20
3.1 Représentation d’une architecture 2-tiers . . . . . . . . . . . . . . . . 25

3.2 Représentation d’une architecture MVC . . . . . . . . . . . . . . . . . 25
3.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 : Diagramme de séquence du cas d’utilisation " S’authentifier . . . 29
3.5 : Diagramme de séquence du cas d’utilisation "Supprimer les récla-
mations" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 : Diagramme de séquence du cas d’utilisation "Supprimer un utili-
sateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7 : Diagramme de séquence du cas d’utilisation "Ajouter catégories" 31
3.8 : Diagramme de séquence du cas d’utilisation "Supprimer catégorie" 31
3.9 : Diagramme de séquence du cas d’utilisation "Supprimer annonce" 32
3.10 : Diagramme de séquence du cas d’utilisation "Ajouter annonce" . 32
TABLE DES FIGURES
3.11 : Diagramme de séquence du cas d’utilisation "Créer réclamation" 33

3.12 : Diagramme de séquence du cas d’utilisation "Créer un compte" . 33
4.1 Logo de Visual Studio Code[3] . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Logo de XAMPP[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Logo du Postman[5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4 Logo du npm[6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Logo de Node.js[7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Logo de Html5[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7 Logo de TypeScript[9] . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8 Logo de CSS3[10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.9 Logo de JSON[11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.10 Logo de PHP[12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.11 Logo de Bootstrap[13] . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.12 Logo de Angular[14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.13 Logo de Capacitor[15] . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.14 Logo de draw.io[15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.15 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.16 Interface d’accuei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.17 Interface de se connecter . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.18 Interface de registre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.19 Interface de contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.20 Interface d’accueil d’ une annonce . . . . . . . . . . . . . . . . . . . . 47
4.21 Suppression d’une annonce . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.22 Interface des listes des catégories . . . . . . . . . . . . . . . . . . . . . 48
4.23 Interfaces des listes des utilisateur . . . . . . . . . . . . . . . . . . . . 49
4.24 Interfaces Suppression des utilisateurs . . . . . . . . . . . . . . . . . . 50
4.25 Interface de déposer une annonce [1] . . . . . . . . . . . . . . . . . . . 50
4.28 Interface de Mes annonces . . . . . . . . . . . . . . . . . . . . . . . . . 52
LISTE DES TABLEAUX
2.1 Description du cas d’utilisation «s’authentifier» . . . . . . . . . . . . 13

2.2 Description du cas d’utilisation "Gérer les catégories " . . . . . . . . 14
2.3 Description du cas d’utilisation " Ajouter une catégorie " . . . . . . . 14
2.4 Description du cas d’utilisation " Supprimer une catégorie " . . . . . 15
2.5 Description du cas d’utilisation "Supprimer une annonce" . . . . . . 16
2.6 Description du cas d’utilisation "Chercher l’annonce par son titre" . 16
2.7 Description du cas d’utilisation "Consulter les réclamations" . . . . . 17
2.8 Description du cas d’utilisation "Supprimer la réclamation" . . . . . 18
2.9 Description du cas d’utilisation "Gérer les utilisateurs " . . . . . . . . 19
2.10 Description du cas d’utilisation "Chercher l’utilisateur par son nom" 19
2.11 Description du cas d’utilisation "Supprimer un utilisateur" . . . . . . 20
2.12 Description du cas d’utilisation "Ajouter une annonce" . . . . . . . . 21
2.13 Description du cas d’utilisation "Supprimer une annonce" . . . . . . 21
4.1 Description des machines de développement . . . . . . . . . . . . . . . 36

Nous sommes aujourd’hui dans une époque où la vente entre personnes privées
est une chose fréquente. Divers moyens permettent en effet d’acheter ou vendre
divers objets en effectuant moins de dépenses. Il n’y aurait même aucune dépense
si l’intéressé a choisi de passer par un site de petite annonce gratuite en ligne.
L’augmentation incessante du nombre des transactions en ligne est due en grande
partie à un tel site. Plusieurs milliers de personnes, entreprises et particuliers, s’y
échangent tous les jours, de biens. La plupart ont déclaré être satisfaits d’avoir
passé par un site d’annonce gratuite en ligne.
Les sites de petites annonces facilitent l’achat. En outre, ils permettent d’avoir
une large proposition de produits et de prix différents. L’utilisateur choisit l’offre
qui la convient au mieux puis contacte l’annonceur. En général, ce service est
entièrement libre, sans frais ni de commissions.
C’est dans ce cadre que s’inscrit notre projet de fin d’études intitulé « Création
d’un site web et application mobile des annoces gratuit sur tout le Niger ». C’est
un projet qui s’intéresse à la création d’un site d’annonce pour vendre ou acheter
des services et des produits provenant de divers domaines d’activités.
Dans ce rapport, nous commençons dans un premier chapitre par présenter le

cadre général du projet, l’étude de l’existant et la méthodologie de développement
adoptée. Le deuxième chapitre est consacré à l’analyse et la spécification des be-
soins. Dans le troisième chapitre, nous travaillrons sur la conception . Pour la qua-
triéme chapitre ,nous présenterons l’environnement de travail, puis pour chauque
cas d’utilisation on a le test et la validation et nous décrirons le résultat de notre
projet.
Ce travail sera clôturé par une conclusion générale et des perspectives.
1
CHAPITRE
CADRE GENERAL DU PROJET
2
CHAPITRE 1. CADRE GENERAL DU PROJET
Introduction
L ’objectif de ce chapitre est de mettre notre travail dans son contexte général.
Pour cela, nous présenterons le cadre du projet, par la suite nous présenterons
l’organisme d’accueil. Nous passerons ensuite à l’étude de l’existant puis nous pré-
senterons la nouvelle solution. Enfin, nous allons mettre l’accent sur la méthodo-
logie qui a été suivie pour réaliser le travail demandé.
1.1 Cadre du projet

Notre stage s’inscrit dans le cadre de la validation de notre projet de fin d’études
en vue de l’obtention de la licence appliquée en informatique spécialité systèmes
informatique et logiciels. Nous avons mis en pratique les connaissances que nous
avons acquises pendant notre formation académique. Pour mener à bon terme ce
travail, et pendant une durée de quatre mois, nous avons été accueillis au sein de
l’entreprise 24IT .
1.2 Preséntation de l’organisme d’Acceuil
1.3 Étude de l’existant

Dans nos jours les sites d’annonces sont les premiers endroits à regarder chaque
matin pour trouver de bonnes affaires en ligne. Ils jouent le rôle d’un canal d’inter-
médiaire entre ceux qui offrent et ceux qui demandent.Certains sont généralistes,
d’autres sont spécifiques à un seul secteur.
1.4 Critique de l’existant

Certes, cette stratégie des réseaux sociaux propose des avantages et permet
de simplifier les choses.Il y a la facilité d’utilisation et la démarche simple pour
l’inscription. Pour le vendeur, il lui faut seulement quelques secondes et quelques
clics pour saisir et valider son annonce. Après une relecture par l’équipe du site,
cette dernière sera mise en ligne. L’acheteur, de son côté, peut trouver facilement
3
tous les objets dont il en a besoin. En effet, chaque annonce est classée dans une
catégorie, sous-catégorie et rubrique qui lui est attachée. Il faut donc seulement
accéder seulement à la catégorie immobilière pour trouver des annonces sur la
vente d’une maison. Il en est de même pour une recherche d’annonces d’autres
secteurs.
1.5 Objectifs du projet

Le travail consiste donc à traiter les différentes défaillances présentées dans la
section précédente. Notre objectif donc, consiste à développer nos propres solutions
répondant aux exigences suivantes :
• Rapide : Les utilisateurs de nos jours désirent naviguer sur un site qui se charge
rapidement et qui délivre les contenus demandés en quelques secondes.
• Ergonomique : L’application web doit être capable de répondre efficacement

aux attentes des utilisateurs et à leur fournir un confort de navigation.
• Responsive : L’application web devra s’adapter à tous types de navigateurs et

tous types de résolutions d’écrans, offrant ainsi plus de liberté au client dans
sa navigation.
1.6 Méthodologie de développement

La finalisation du projet dans les délais de livraison est le souci majeur de chaque
équipe de développement d’un logiciel. Un des problèmes les plus fréquemment af-
frontés lors de la construction du logiciel est la mauvaise spécification des besoins
et leur changement continu. Afin d’éviter de se retrouver dans ces situations cri-
tiques, nous adoptons une méthodologie itérative ou agile pour la gestion de notre
projet.
1.7 Choix de la méthodologie

Nous avons recours aux méthodes agiles qui programment une édition minimale
et qui incorporent les spécificités par un processus itératif établi sur une écoute
client et des tests pendant la durée du développement. L’origine de ces méthodes
est rattachée à l’instabilité de l’envireonnement technologique au fait que le client
4
est toujours dans l’impossibilité de déterminer ses exigences au tout premier ins-
tant. Une fois que nous décidons d’adopter une gestion de développement agile, il
nous reste encore à comparer les nombreuses méthodes disponibles et à choisir la
méthodologie la plus adaptée à notre projet.
1.7.1 Méthode agile SCRUM
Il existe une multitude de méthodes agiles. Il ne s’agit pas de choisir la meilleure

méthode parmi celles existantes mais plutôt de sélectionner la méthode la plus
adaptée à notre projet. Le choix entre une méthode et une autre, dépend de la
nature du projet et de sa taille. Pour les projets de petite taille, un cycle de vie
en cascade par exemple s’avère largement suffisant. Lorsqu’il s’agit d’un projet où
les données ne sont pas réunies dès le départ ou les besoins sont incomplets ou
floues, il faut s’orienter vers une méthode itérative ou orientée prototype. Pour la
nature de notre projet qui doit être évolutif, on va s’orienter vers la méthodologie
SCRUM.
1.7.2 Pourquoi SCRUM ?
La méthodologie SCRUM est une approche de gestion des projets. L’objectif

de cette méthode est de développer uniquement les fonctionnalités qui apportent
une valeur ajoutée au produit, tout en respectant les délais et en garantissant sa
qualité, avec un retour rapide de la part du client. Le choix de SCRUM comme la
méthodologie de pilotage de notre projet est basé sur les atouts de ce dernier. Il
se résume comme suit :
Plus de souplesse et de réactivité.
La grande capacité d’adaptation au changement grâce à des itérations courtes.
SCRUM rassemble les deux côtés, théorique et pratique, et se rapproche beaucoup

de la réalité.
1.7.3 Les acteurs SCRUM :
Citons les trois rôles principaux dans SCRUM :
Le responsable produit : le représentant des clients et des utilisateurs. Il détermine

ce que doit être réalisé.
5
L’équipe projet : les développeurs sont chargés de construire ce que le responsable

produit a demandé et d’en faire une démonstration.
SCRUM Master : le responsable au bon déroulement des différentes étapes du

processus. Il garantit que la collaboration demeure efficace et bien organisée.
1.7.4 Les évenements SCRUM :
La vie d’un projet Scrum est rythmée par un ensemble de réunions définies avec
précision et limitées dans le temps.
- Le sprint : est une période de 2 à 4 semaines maximum pendant laquelle une

version terminée et utilisable du produit est réalisée .
- Planification d’un sprint : est une réuinion durant laquelle l’équipe SCRUM
déterminet les tâches à accomplir pendant le Sprint.
- Revue de Sprint : une fois le Sprint terminé, l’équipe Scrum et les parties pre-
nantes se réunissent pour valider ce qui a été accompli pendant le Sprint.
- Rétrospective : une réunion interne à l’équipe Scrum qui a pour rôle de s’adapter
aux changements qui peuvent survenir et d’améliorer le processus de réalisation.
- Mêlée quotidienne : un « stand-up meeting » quotidien qui permet à l’équipe de

synchroniser ses activités et de faire un plan pour les prochaines 24 heures.
Figure 1.1 – Méthodologie SCRUM [1]
6
1.8 La modélisation objet

Depuis quelques années, la modélisation objet avec le langage UML est devenue
une pratique courante sur de nombreux projets informatiques. En effet, Le recours
à la modélisation est une pratique indispensable au développement logiciel, car un
modèle est prévu pour arriver à anticiper les résultats du codage.
1.8.1 Définition de UML
UML se définit comme un langage de modélisation graphique et textuel destiné à

comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser
des architectures logicielles, concevoir des solutions et communiquer des points de
vue. UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit pas
d’une simple notation graphique, car les concepts transmis par un diagramme ont
une sémantique précise. L s’articule autour de treize types de diagrammes, chacun
d’eux étant dédié à la représentation des concepts particuliers d’un système logiciel
.
1.8.2 Processus de modélisation
Le processus que nous allons présenter et appliquer tout au long de ce rapport :
• Conduit par les cas d’utilisation.
• Relativement léger et restreint, comme les méthodes agiles, mais sans négliger
les activités de modélisation en analyse et conception.
• Fondé sur l’utilisation d’un sous-ensemble nécessaire et suffisant du langage

UML, conformément à méthodes agiles.
Conclusion
Dans ce chapitre, nous avons présenté l’organisme d’accueil. Nous avons aussi
fait une étude de l’existant pour pouvoir dégager les problématiques et les dé-
faillances. Nous avons ensuite évoqué la solution qui permet d’écarter les difficultés
dégagées précédemment. Nous avons aussi étudié la méthodologie de travail que
nous avons adopté pour réaliser notre projet. Le prochain chapitre sera consacré à
7
l’analyse et la spécification des besoins en décrivant l’ensemble des caractéristiques

fonctionnelles.
8
CHAPITRE
ANALYSE ET SPECIFICATION DES

BESOINS
9
CHAPITRE 2. ANALYSE ET SPECIFICATION DES BESOINS
Introduction
Dans le chapitre précédent, nous nous sommes focalisés sur l’étude approfondie
de la problématique afin de la mettre dans son cadre théorique. Dans ce chapitre,
nous nous intéresserons de L’étape d’analyse et spécification des besoins consiste
à définir l’ensemble des fonctionnalités que l’application doit fournir.Ces besoins
seront répartis en deux groupes fonctionnels et non fonctionnels de notre projet.
2.1 Capture des besoins
2.1.1 Identification des acteurs
• un administrateurs : sont chargés de la gestion du site, que ce soit la mainte-

nance, ou la modération des annonces. L’interaction avec le système consiste
en une interaction avec les composants de contrôle du site grâce à un compte
administrateur, qui comporte des privilèges supplémentaires comme, la sup-
pression d’annonces.
• Un Utilisateur : est un utilisateur du site qui a déposé une ou plusieurs an-

nonces. Son interaction avec le site consiste en une création d’un profil avec
ses coordonnées, et de la gestion de ses annonces (dépôt, suppression). Il peut
aussi éditer son profil. Un utilisateur peut aussi être un client.
• Un visiteur : est un utilisateur du site qui vient pour chercher des annonces.
Son interaction avec le site consiste en une consultation des annonces du site.
Il peut aussi éditer son profil. Un visiteur peut aussi être un utilisateur .
2.1.2 Besoins fonctionnels
Les besoins fonctionnels, ils s’agissent des besoins spécifiant un comportement

d’entrée / sortie du Système.
Notre produit doit répondre aux besoins suivants :
• Gestion des annonces : Elle permet à l’administrateur de supprimer une annonce

.
10
• Gestion des catégories : Elle permet à l’administrateur de créer , modifier ou

supprimer une catégorie .
• Gestion des utilisaturs : Elle permet de supprimer un utilisateur.
•Ajouter des annonces : Elle permet à l’utilisateur de déposer une annonce .
• Consultation des annonces : Elle permet au visiteur de consulter et rechercher

les annonces .
• Contacter un administrateur : Elle permet au visiteur d’envoyer des réclamations

à un administrateur.
2.1.3 Besoins non fonctionnels
Tous les systèmes d’information à un certain point dans leur cycle de vie doivent
considérer des besoins non-fonctionnels et leurs tests. Pour certains projets ces
besoins demanderont un travail très important et pour d’autres un contrôle rapide
sera suffisant. Au minimum, la liste suivante peut être un rappel utile pour s’assurer
que vous avez couvert l’essentiel .
Les besoins non fonctionnels de notre projet :
XErgonomie : L’application doit offrir une interface conviviale et ergonomique

exploitable par l’utilisateur en envisageant toutes les interactions possibles à l’écran
du support tenu, tout en assurant le confort visuel.
XRapidité du service : Les applications doivent optimiser les traitements pour avoir
un temps de consultation raisonnable.
XMaintenabilité : Les codes des applications doivent être lisibles et compréhen-

sibles afin d’assurer leur évolutivité et extensibilité par rapport aux besoins de
l’entreprise.
XLa Sécurité : une authentification est exigée vu que cette application contient
des données confidentielles. Tous les accès aux différents espaces (Administrateur,
Utilisateur) doivent être protégés par un mot de passe .
2.2 Diagramme de cas d’utilisation

Une étude détaillée permet de dégager les besoins qui définissent ces fonction-
nalités principales. Ces besoins sont modélisés sous forme de cas d’utilisation avec
11
le diagramme suivant :
Figure 2.1 – Diagramme général de cas d’utilisation
Selon ce diagramme, le visiteur peut consulter les annonces, contacter l’adminis-

trateur par d’envoyer des réclamations, ou créer un compte pour étre un utilisateur
. Après qu’il s’authentifie,
l’utilisateur peut ajouter une annonce , modifier ou supprimer .
l’administrateur peut supprimer les annonces , les catégories(ajouter ou supprimer

ou ),et peut supprimer un utilisateur .
12
2.3 Raffinement des cas d’utilisations

Pour mieux comprendre ce que fait l’application, nous avons recours aux ta-
bleaux de raffinement qui permettent de décrire chaque cas d’utilisation de point
de vue acteurs, objectif, pré conditions, post conditions et scénarios .
Raffinement du cas d’utilisation «S’authentifier »
Cas d’utilisation : S’authentifier

Objectif : Permettre à tout acteur d’accéder à son propre espace
Acteur : Administrateur, Utilisateur
Précondition : L’acteur possède un compte
Post-condition : L’acteur accède au système
Description de scénario de base :
1- L’utilisateur saisit son email et son mot de passe.
2- Le système vérifie la combinaison saisie
3- Le système autorise l’accès pour l’utilisateur à son espace.
Exception :
Si l’email ou le mot de passe sont erronés :
- Le système affiche un message d’erreur
Tableau 2.1 – Description du cas d’utilisation «s’authentifier»
Raffinement du cas d’utilisation «Gérer les catégories »
Figure 2.2 – Cas d’utilisation " Gérer les catégories"
13
Dans ce cas, l’administrateur peut gérer les catégories. Soit il ajoute d’autres,
soit il les supprimes.
Cas d’utilisation 2 : Gérer les catégories

Objectif : Permettre à l’administrateur d’ajouter ou supprimer une catégorie
Acteur : Administrateur
Précondition :• Administrateur authentifié avec succès.
La vue de gestion de catégorie doit être ouverte.
Post-condition : Catégories gérées
1- L’administrateur peut ajouter une catégorie.
2- L’administrateur peut supprimer une catégorie.
Exception :
Echec de lancement de l’application.
Tableau 2.2 – Description du cas d’utilisation "Gérer les catégories "
Cas d’utilisation : Ajouter une catégorie

Objectif : Permettre à l’administrateur d’ajouter une catégorie
Précondition : L’administrateur doit remplir tous les champs de données de la catégorie
.
Post-condition : Catégorie ajoutée
1- L’administrateur peut ajouter une catégorie.
2- L’administrateur peut supprimer une catégorie.
Exception :
• Echec de l’ajout de la catégorie.

• L’un des champs est vide.
Tableau 2.3 – Description du cas d’utilisation " Ajouter une catégorie "
14
Cas d’utilisation : Supprimer une catégorie

Objectif : Permettre à l’administrateur de supprimer une catégorie
Précondition :La vue de suppression des catégories doit être ouvert .
Post-condition : Catégories supprimée.
Description de scénario de base : L’administrateur sélectionne la marque à suppri-
mer.
Exception :
• Echec de la suppression de la catégorie.

• Echec de lancement de la vue.
Tableau 2.4 – Description du cas d’utilisation " Supprimer une catégorie "
Raffinement du cas d’utilisation «Supprimer les annonces »
Figure 2.3 – Cas d’utilisation " Supprimer annonce"
Dans ce cas, l’administrateur peut supprime ses annonces.
15
Cas d’utilisation : Supprimer une annonce

Objectif : Permettre à l’administrateur de supprimer une annonce
Précondition La vue de suppression des annonces doit être ouverte.
Post-condition : Annonce supprimée.
L’administrateur supprime une annonce.

Exception :
• Echec de suppression de l’annonce..

Tableau 2.5 – Description du cas d’utilisation "Supprimer une annonce"
Cas d’utilisation : Chercher l’annonce par son titre

Objectif : Permettre à l’administrateur de rechercher une annonce
PréconditionLa vue de suppression des annonces doit être ouverte.
Post-condition : Résultat de la recherche est affiché.
L’administrateur entre l’identifiant de l’annonce.

Exception :
• Echec de la recherche de l’annonce..

Tableau 2.6 – Description du cas d’utilisation "Chercher l’annonce par son titre"
16
Raffinement du cas d’utilisation «Gérer les réclamations»
Figure 2.4 – Cas d’utilisation " Gérer les réclamations"
Selon ce diagramme, l’administrateur peut consulter les réclamations, avec la

possibilité de les supprimer.
Cas d’utilisation : Consulter les réclamations

Objectif : Permettre à l’administrateur de consulter les réclamations
Précondition :
• Administrateur authentifié avec succès.
• La vue de gestion de messages doit être ouverte.
Post-condition : Réclamations gérées.
L’administrateur peut supprimer la réclamations.
Exception :
• Echec de lancement de l’application. .
Tableau 2.7 – Description du cas d’utilisation "Consulter les réclamations"
17
Cas d’utilisation : Supprimer les réclamations

Objectif : Permettre à l’administrateur de supprimer les réclamations
Précondition :
• La vue de gestion de messages doit être ouverte.
Post-condition : Réclamation supprimé
L’administrateur supprime la réclamation .
Exception :
•Echec de la suppression du réclamation . .
Tableau 2.8 – Description du cas d’utilisation "Supprimer la réclamation"
Raffinement du cas d’utilisation «Gérer les utilisateurs»
Figure 2.5 – Cas d’utilisation " Gérer les utilisateurs"
Selon ce raffinement, l’administrateur peut consulter ou supprimer les utilisa-

teurs .
18
Cas d’utilisation : Gérer les utilisateurs

Objectif : Permettre à l’administrateur de gérer les utilisateurs .
Précondition :
• La vue de gestion des utilisateurs doit être ouverte.
Post-condition : Utilisateurs gérées.
• L’administrateur peut supprimer un utlisateur.
Exception :
• Echec de lancement de l’application. .
Tableau 2.9 – Description du cas d’utilisation "Gérer les utilisateurs "
Cas d’utilisation : Chercher l’utilisateur par son nom

Objectif : Permettre à l’administrateur de rechercher un utilisateur .
Précondition La vue de suppression des utilisateurs doit être ouverte.
Post-condition : Résultat de la recherche est affiché.
L’administrateur entre le nom de l’utilisateur.
Exception :
• Echec de la recherche de l’utilisateur.

Tableau 2.10 – Description du cas d’utilisation "Chercher l’utilisateur par son nom"
19
Cas d’utilisation : Supprimer un Utilisateur

Objectif : Permettre à l’administrateur de supprimer un utilisateur
Précondition :
• La vue de gestion des utilisateurs doit être ouverte.
Post-condition : Utilisateur Supprimé
L’administrateur supprime l’utilisateur .
Exception :
• Echec de suppression de l’utilisateur.
• Echec de lancement de l’application.
Tableau 2.11 – Description du cas d’utilisation "Supprimer un utilisateur"
Raffinement du cas d’utilisation «Gérer les annonces »
Figure 2.6 – Cas d’utilisation " Gérer les annonces"
20
Cas d’utilisation : Ajouter une annonce

Objectif : Permettre à l’utilisateur de ajouter une annonce
Acteur : utilisateur
Précondition :
• Utilisateur authentifié avec succès.
• L’utilisateur doit remplir tous les champs de données de l’annonce..
Post-condition : Annonce ajoutée.
L’utilisateur ajoute une annonce. .
Exception :
• Echec de l’ajout de l’annonce.
• • L’un des champs est erroné ou vide .
Tableau 2.12 – Description du cas d’utilisation "Ajouter une annonce"
Cas d’utilisation : Supprimer une annonce

Objectif : Permettre à l’utilisateur de supprimer une annonce
Acteur : utilisateur
Précondition :
• Utilisateur authentifié avec succès.
• L’utilisateur doit remplir tous les champs de données de l’annonce..
Post-condition : Annonce supprimée .
L’utilisateur supprime une annonce. .
Exception :
• Echec de suppression de l’annonce.
• L’un des champs est erroné ou vide .
Tableau 2.13 – Description du cas d’utilisation "Supprimer une annonce"
21
2.4 Conclusion
Tout au long de ce chapitre, nous avons présenté notre sujet afin de mieux cerner
son champ d’actions. Ainsi, nous avons pu dégager les différentes fonctionnalités
auxquelles le système doit répondre
22
CHAPITRE
CONCEPTION
23
CHAPITRE 3. CONCEPTION
Introduction
La conception constitue une phase très importante dans la réalisation de notre
application, elle permet de concevoir la base de données de notre futur système
d’information, de réduire la complexité et d’enlever l’ambiguïté. En outre elle per-
met une meilleure compréhension du système ce qui engendre un gain du temps.
Dans ce chapitre, nous allons aborder la tâche la plus importante dans l’élaboration
de ce travail, à savoir la tâche de conception. En effet, nous présentons, en premier
lieu, l’architecture générale de notre application afin d’en extraire les différents
modules qui la composent .
3.1 Architecture
Nous allons présenter les différents types d’architectures au début de cette partie
puis nous préciserons l’architecture choisie pour notre application.
3.1.1 L’architecture 2-tiers
Dans une architecture 2-tier, appelée aussi architecture client/serveur de pre-

mière génération (de données), le client s’occupe de la présentation et la logique
applicative et le serveur s’occupe de la gestion des données. La gestion des données
est prise en charge par un SGBD centralisé, s’exécutant le plus souvent sur un
serveur dédié (serveur de données). Il y a échange de messages à travers le réseau
reliant les deux machines. L’architecture 2-tiers présente plusieurs limites : • Une
charge importante du poste client qui réalise l’ensemble des traitements applicatifs.
• La maintenance et les mises à jour sont difficiles à gérer. • La conversation entre
client et serveur est assez bruyante. Ces limites proviennent de la nature du client
qui est un client lourd (comprends la gestion des traitements).
24
Figure 3.1 – Représentation d’une architecture 2-tiers
3.1.2 Architecture MVC
L’architecture MVC est un patron de conception très répandu pour réaliser des
applications web. Ce patron de conception est une solution éprouvée et reconnue
permettant de séparer l’affichage des informations (vue), les actions de l’utilisateur
(contrôleur) et l’accès aux données (modèle). Durant le développement de notre
application, nous utilisons l’architecture MVC illustrée dans la figure suivante :
Figure 3.2 – Représentation d’une architecture MVC
• Le modèle définit les données utilisées par l’application. En effet, c’est ici que le
lien se fera entre notre application et la base de données .
• La vue définit la façon dont les informations seront affichées à l’écran (via des
composants par exemple). Il s’agit de l’interface utilisateur. C’est ici qu’on utilisera
les données récupérées par le modèle afin de les présenter à l’utilisateur
• Dans le contrôleur, nous retrouvons toute la logique métier. En effet, lorsque

l’utilisateur interagit avec la vue, la requête est traitée par le contrôleur.
25
3.1.3 Description d’un service web
Par définition, un Web service (ou service Web) est une application appelable
via Internet par une autre application d’un autre site Internet permettant l’échange
de données (de manière textuelle) afin que l’application appelante puisse intégrer
le résultat de l’échange à ses propres analyses. Les requêtes et les réponses sont
soumises à des standards et normalisées à chacun de leurs échanges. Les services
web sont caractérisés par :
• Modularité : La réutilisation et la composition des services
• Interopérabilité : C’est la capacité de dialogue entre des environnements et des

plates-formes hétérogènes.
• Intégration : Le masquage de complexité en intégrant le système d’information

au sein et en dehors de l’entreprise.
• Indépendance : Indépendance de la plate-forme (UNIX, Windows. . . ), des lan-

gages et des implémentations (Java, C++, Visual Basic...) et de l’architecture
(.NET, J2EE, ...). [5] Il existe deux types de services web :
• Les services web de type REpresentational State Transfer (REST) qui exposent
entièrement ces fonctionnalités comme un ensemble de ressources identifiables et
accessibles via le protocole HTTP. Les Services Web de type REST sont donc basés
sur l’architecture du web et ses standards de base : HTTP et URI.
• Les Services Web SOAP exposent des fonctionnalités via d’autres protocoles du
web sous la forme de services exécutables à distance. Leurs spécifications reposent
sur le standard WSDL pour transformer les problématiques d’intégration héritées
du monde Middleware en objectif d’interopérabilité.
3.1.4 Choix de l’architecture
Nous avons choisi le modèle MVC parce qu’il apporte de nombreux avantages.
• Conception claire et efficace.
• Responsabilité unique.
• Couplage faible.
• Cohésion forte.
• Gain de temps.
26
• Facilité d’avoir plusieurs développeurs travaillant sur le même projet.
3.2 Conception détaillée

La conception est la phase la plus importante dans le cycle du développement
d’une application. C’est un procédé qui a pour objectif de permettre de formaliser
les étapes préliminaires du développement d’un système afin de rendre ce déve-
loppement plus fidèle aux besoins de l’utilisateur. La phase de conception permet
de décrire de manière non ambiguë, le plus souvent en utilisant un langage de
modélisation, le fonctionnement futur du système afin d’en faciliter la réalisation.
3.2.1 Diagramme de classes
Le diagramme de classes est une représentation statique des éléments qui com-
posent le système et des relations qui s’établissent entre eux.Les ensembles des
classes vont permettre la réalisation des cas d’utilisation.
27
Figure 3.3 – Diagramme de classes
3.2.2 Diagramme de séquence
La conception consiste à façonner le système et lui accorder une forme et une

architecture. Elle accomplit le travail déjà commencé au niveau de l’analyse et
constitue une entrée majeure pour les activités d’implémentation et de test. Elle
se traduit par le diagramme de séquence système d’UML.
• Diagramme de séquence du cas d’utilisation «S’authentifier »
28
Figure 3.4 – : Diagramme de séquence du cas d’utilisation " S’authentifier
Pour accéder à l’espace de ( l’administrateur ou l’utilisateur) , celui-ci doit

passer par le contrôleur de la partie front pour valider l’email et le mot de passe
qui seront transmis à la partie( back-office ou espace utilisateur) où nous allons
vérifier si l’utilisateur est enregistré ou non. Dans le cas du succès, nous allons
comparer le mot de passe entré avec celui de ( l’administrateur ou l’utilisateur ).
Si les deux mots de passe sont identiques, nous allons afficher l’espace .
33,97,140 • Diagramme de séquence du cas d’utilisation «Supprimer les réclama-
29
tions »
Figure 3.5 – : Diagramme de séquence du cas d’utilisation "Supprimer les réclamations"
Comme l’indique ce diagramme, le système envoie une requête au serveur avec

l’identifiant du réclamation à supprimer.
• Diagramme de séquence du cas d’utilisation «Supprimer les utilisateurs »
Figure 3.6 – : Diagramme de séquence du cas d’utilisation "Supprimer un utilisateur"
Ce diagramme nous illustre la suppression d’un utilisateur du système
• Diagramme de séquence du cas d’utilisation «Ajouter catégorie »
30
Figure 3.7 – : Diagramme de séquence du cas d’utilisation "Ajouter catégories"
Comme l’indique ce diagramme de séquence, le système ajoute la catégorie saisie

par l’administrateur si elle n’existe pas.
• Diagramme de séquence du cas d’utilisation «Supprimer catégorie »
Figure 3.8 – : Diagramme de séquence du cas d’utilisation "Supprimer catégorie"
Ce diagramme nous indique les étapes établies par le system pour la suppression
de toute une catégorie.
• Diagramme de séquence du cas d’utilisation «Supprimer annonce »
31
Figure 3.9 – : Diagramme de séquence du cas d’utilisation "Supprimer annonce"
Ce diagramme nous présente les étapes établies pour supprimer une annonce
du systeme .
• Diagramme de séquence du cas d’utilisation «Ajouter annonce »
Figure 3.10 – : Diagramme de séquence du cas d’utilisation "Ajouter annonce"
Comme l’indique ce diagramme de séquence, l’utilisateur ajoute une annonce

après avoir saisi des données valides.
32
Figure 3.11 – : Diagramme de séquence du cas d’utilisation "Créer réclamation"
Ce diagramme nous explique les étapes d’envoi de réclamations. Le visiteur

remplit le formulaire d’abord, et si les données saisies sont valides, le système
envoie la réclamation à l’administrateur.
• Diagramme de séquence du cas d’utilisation «Créer un compte utilisateur »
Figure 3.12 – : Diagramme de séquence du cas d’utilisation "Créer un compte"
*********
33
3.3 Conclusion
Au cours de ce chapitre nous avons pu dégager une vue conceptuelle qui englobe
toutes les fonctionnalités majeures à réaliser. La nécessité d’une telle étude se révèle
très utiles lors de la phase d’implémentation.
34
CHAPITRE
RÉALISATION DE L’APPLICATION
35
CHAPITRE 4. RÉALISATION DE L’APPLICATION
Introduction
L a réalisation est une étape très importante dans le cycle de vie de toute appli-
cation informatique. Nous commençons ce chapitre par présenter l’environnement
matériel et logiciel. Nous entamerons ensuite la présentation et la réalisation de
l’application.
4.1 Envirennement du travail
4.1.1 Environnement matériel
Cette partie est consacrée pour la description de l’ensemble des composants

matériels supportant l’application.
Dans la réalisation de notre système nous avons utilisé nos ordinateurs portables.
Dans le tableau qui suit nous trouvons les caractéristiques de ces ordinateurs.
Caractéristique PC1 PC2

Modéle ASUS ASUS
Processeur Core i5-7200U Core i7-7200U
Fréquence de processeur 2.7GHz 2.7GHz
RAM 8GB 8GB
Stockage 1To 1To
Système d’exploitation ubuntu 20.4 ubuntu 20.4
Tableau 4.1 – Description des machines de développement
4.1.2 Environnement logiciel
Cette partie est réservée pour la présentation des logiciels utilisés dans la réa-
lisation de l’application, des langages, des Frameworks, des technologies et des
architectures.
36
• Visual Studio Code :

Visual Studio Code (VSC par la suite) est un éditeur de code open-source,
gratuit et multi-plateforme (Windows, Mac et Linux), développé par Micro-
soft. VSC est principalement conçu pour le développement d’application avec
JavaScript, TypeScript et Node.js, l’éditeur peut s’adapter à d’autres types
de langages grâce à un système d’extension bien fourni.
Figure 4.1 – Logo de Visual Studio Code[3]
• XAMPP :
XAMPP est un ensemble de logiciels servant à mettre en place aisément un
serveur Web, un serveur FTP et un serveur de messagerie électronique. C’est
une distribution de logiciels libres (X Apache MySQL Perl PHP) offrant une
bonne souplesse d’utilisation, reconnue pour son installation simple et rapide.
Figure 4.2 – Logo de XAMPP[4]
37
• Postman :
Postman est une solution pour interroger ou tester les services Web. Il propose
de nombreuses fonctionnalités.
Figure 4.3 – Logo du Postman[5]
• NPM :
« Node Package Manager » est les gestionnaire de paquets officiel de Node.js.
Il fonctionne avec un terminal et gère les dépendances pour une application. Il
permet également d’installer des applications Node.js disponible sur le dépôt
npm.
Figure 4.4 – Logo du npm[6]
38
• Node.js :
Node.js est un environnement d’exécution JavaScript construit sur le moteur
JavaScript V8 de chrome. C’est une plateforme logicielle libre et évènemen-
tielle en JavaScript orientée vers les applications réseau qui doivent pouvoir
monter en charge.
Figure 4.5 – Logo de Node.js[7]
4.1.3 Langages
• HTML 5 :
L’HyperText Markup Language, généralement abrégé HTML est le langage
de balisage conçu pour représenter les pages web. Il permet également de
structurer sémantiquement et logiquement et de mettre en forme le contenu
des pages.
Figure 4.6 – Logo de Html5[8]
39
• TypeScript :
TypeScript est un langage de programmation qui a pour but d’améliorer et de
sécuriser la production de code JavaScript. Le code TypeScript est transcom-
pilé en JavaScript, pouvant ainsi être interprété par n’importe quel navigateur
web ou moteur JavaScript.
Figure 4.7 – Logo de TypeScript[9]
• CSS 3 :
Cascading Style Sheets (feuilles de styles en cascade), servent à mettre en
forme des documents web, type page HTML ou XML.
Par l’intermédiaire de propriétés d’apparence (couleurs , bordures , polices ,
etc ..) et de placement (largeur , hauteur, côte à côte, etc ..).
Figure 4.8 – Logo de CSS3[10]
40
• JSON :
JavaScript Object Notation est un format de données textuelles indépendant

de tout langage, dérivé de la notation des objets du langage JavaScript. Il
permet de représenter de l’information structurée.
Figure 4.9 – Logo de JSON[11]
• PHP :
PHP est un langage informatique utilisé sur l’internet. Le terme PHP est
un acronyme récursif de "PHP : Hypertext Preprocessor". Ce langage est
principalement utilisé pour produire un site web dynamique. Il est courant
que ce langage soit associé à une base de données, tel que MySQL.
Figure 4.10 – Logo de PHP[12]
41
• Bootstrap :
Bootstrap est une infrastructure de développement frontale, gratuite et open
source pour la création de sites et d’applications Web. L’infrastructure Boots-
trap repose sur HTML, CSS et JavaScript (JS) pour faciliter le développement
de sites et d’applications réactives et tout-mobile.
Figure 4.11 – Logo de Bootstrap[13]
4.1.4 Frameworks
• Angular :
Angular est un framework javascript côté client qui permet de réaliser des
applications de type « Single Page Application ». Il est basé sur le concept de
l’architecture MVC (Model View Controller) qui permet de séparer les don-
nées, les vues et les différentes actions que l’on peut effectuer. Ses composants,
indépendants les uns des autres, facilitent le développement d’applications à
grande échelle tout en conservant la maintenabilité. Angular est un outil très
performant pour la création d’applications web.
42
Figure 4.12 – Logo de Angular[14]
• Capacitor :
Capacitor transforme n’importe quelle application Web en application native
afin que vous puissiez exécuter une application sur iOS, Android et le Web
avec le même code.
capacitor.png
Figure 4.13 – Logo de Capacitor[15]
draw.io :
Draw.io est un logiciel qui est utilisé pour modéliser, représenter et visualiser les
informations. Entre autres utilisations, ces schémas sont souvent utilisés dans les
logiciels et le développement technique et commercial pour représenter les flux de
données, les flux de travail, l’architecture logicielle et les organigrammes.
43
Figure 4.14 – Logo de draw.io[15]
4.2 Réalisation
4.2.1 Interface Homme-Machine
Tout visiteur de notre plateforme aura accès à la page d’accueil , la barre de

recherche disponible . L’accueil représente tous les annonces que les utlisateurs
déposer .
Figure 4.15 – Interface d’accueil
44
Figure 4.16 – Interface d’accuei
les services qu’elle offert. La figure ci-dessous représente la page d’accueil de notre
application : Le click sur la button se connecter présente une interface de login :
Figure 4.17 – Interface de se connecter
Lorsque on click sur la button créer un compte présente la page registre pour
le visiteur peuvent de créer des comptes utilisateurs ... il faut de remplir tous les
champs .le système vérifie ces données et ajoute un utilisateur s’ils sont valides.
45
Figure 4.18 – Interface de registre
Cette capture d’écran nous montre l’interface de contact. Le visiteur peut rempli
le formulaire et l’envoyer à l’administrateur. Ce message va apparaitre à la page
de gestion des réclamation .
Figure 4.19 – Interface de contact
46
4.2.2 Espace d’administrateur
4.2.2.1 Gestion des annonce
• Liste des annonce

La liste des annonce s’affiche . Cette interface permet au administrateur de gérer
les annonces . A droite, le boutton "Rechercher "qui permet de faire la recherche
des annonces a partir d’un titre , region ou bien prix . et le boutton "Supprimer" qui
supprime les annonces . le boutton "Réinitialiser" qui remet les zones de recherche
dans leurs états initials.
Figure 4.20 – Interface d’accueil d’ une annonce
• Suppression d’une annonce

Cette interface permet d’supprimer une annonce Lorsque l’administrateur clique
sur "Supprimer", un message de confirmation s’affiche. S’il confirme la suppression,
l’annonce sera supprimée.
47
Figure 4.21 – Suppression d’une annonce
4.2.2.2 Gestion des Catégories
• Liste des catégories

La liste des catégories s’affiche . Cette interface permet au administrateur de gérer
les catégories . A gauche , le boutton "Rechercher "qui permet de faire la recherche
des catégories par nom et le boutton "Ajoute" qui permet de créer une nouvelle
catégorie . le boutton "Réinitialiser" qui pemet les zones de recherche dans leurs
états initials.
Figure 4.22 – Interface des listes des catégories
48
4.2.2.3 Gestion Utilisateur
• Liste des utlilisateurs

La listes des utilisateurs s’affiche. Cette interface permet au administrateur de
gérer les utilisateurs. Le boutton "Rechercher" permet de recherche l’utilisateur
par (Nom , prénom , téléphone , Adresse) et le button "Rénitialiser" qui permet
les zones de recherche dans leurs états initials.
Figure 4.23 – Interfaces des listes des utilisateur
• Suppression des utlisateurs

Cette interface permet d’supprimer un utilisateur Lorsque l’administrateur clique
sur "Supprimer", un message de confirmation s’affiche. S’il confirme la suppression,
l’utilisateur sera supprimée.
49
Figure 4.24 – Interfaces Suppression des utilisateurs
4.2.3 Espace Utilisateurs
Cette capture d’écran nous présente l’interface d’ajout des annonces. Après le
remplissage des informations nécessaires (Titre, Prix,Ctégorie , Description ,nu-
méro de télephone , Images , localisation ...) par l’utilisateur, le système vérifie ces
données et ajoute l’annonce s’ils sont valides.
Figure 4.25 – Interface de déposer une annonce [1]
50
La figure ci-dessous représente la page de favoris via laquelle les utilisateurs de

la plateforme peuvent choisir les annonces qui les aimes pour enregistrer et les
afficher dans cette page .
51
Figure 4.28 – Interface de Mes annonces
52
CONCLUSION GÉNÉRALE
1
Ce stage m’a permis de mettre en pratique mes connaissances acquises en

conception et en programmation, les ancrer et les améliorer pour intégrer la vie
professionnelle. En plus de l’esprit critique, j’ai acquis un esprit de recherche et
d’analyse visant à identifier la source de problème, trouver la solution adéquate,
et prendre l’initiative afin de l’améliorer et cerner le problème réel. Il s’agit, en
effet, d’une phase de mise en situation et d’apprentissage à laquelle nous avons été
préparés pendant notre formation à l’Institut Supérieur de Sciences Appliquées et
de Technologie de Mateur .
L’objectif de ce projet de fin d’études était de créer une application web d’an-
nonce pour proposer un milieu quelque soit d’acheter ou bien de vendre.
Pour atteindre nos objectifs, nous avons procédé par l’analyse et la conception
de l’application en faisant recours au modèle incrémental comme méthodologie
de développement logiciel basée sur le langage unifié de modélisation UML et
Visual Paradigm comme environnement de développement intégrant une vue de
modélisation UML.
De plus, étant donné que nous avons deux processus à concevoir, nous avons
essayé d’étudier chacun d’eux à part en appliquant la méthodologie déjà choisie,
puis faire une synthèse de leur analyse. Cette dernière a abouti à choisir ANGULAR
9 comme langage de programmation WEB FULL STACK et à la création de la base
de données Mysql . Ensuite, nous avons passé à la phase de réalisation et nous avons
choisi comme outil Visual Studio Code.
En effet tout application web peut être améliorée d’une façon continue et itéra-
tive et cela en se basant sur le principe de la méthodologie SCRUM. La méthodo-
logie SCRUM affirme de manière intrinsèque qu’un produit n’est jamais achevé ;
après sa construction initiale, il demeure en développement permanent (mainte-
nance ou améliorations). La consolidation permet de préparer le prochain cycle de
développement. Elle a pour fonction de nettoyer les produits et artéfacts du cycle
de développement qui s’achève pour permettre un démarrage propre du cycle sui-
vant.
L’ambiance stressante qui régnait aprés la propagation de la COVID-19 a com-
pliqué notre travail. Nous nous sommes trouvés dans l’obligation de travailler tous
seuls et à distance. Ces conditions pénibles nous ont appris qu’il faut s’adapter aux
situations difficiles.
Enfin, nous gardons de ce stage encourageant un excellent souvenir et nous
2
tenons à exprimer notre satisfaction d’avoir pu travaillé dans des bonnes conditions
matérielles et environnement agréable.
3

Pfe Islem Ryhem

Transféré par

Informations du document

Titre original

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

Pfe Islem Ryhem

Transféré par

Droits d'auteur :

Formats disponibles

DEDICACES

Dédicaces Du profond de mon cœur

À Mes Très Chers Parents

Que ce travail soit l’expression de ma reconnaissance pour vos sacrifices consentis,

À Tous mes amis. . . .

À mes frères et ma sœur,

À mes amis et à toute la promo à l’ISSATM,

A u terme de ce travail, nous tenons à exprimer mes remerciements envers toutes

1 CADRE GENERAL DU PROJET 2

2 ANALYSE ET SPECIFICATION DES BESOINS 9

1.1 Méthodologie SCRUM [1] . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Diagramme général de cas d’utilisation . . . . . . . . . . . . . . . . . 12

3.1 Représentation d’une architecture 2-tiers . . . . . . . . . . . . . . . . 25

3.11 : Diagramme de séquence du cas d’utilisation "Créer réclamation" 33

4.1 Logo de Visual Studio Code[3] . . . . . . . . . . . . . . . . . . . . . . 37

2.1 Description du cas d’utilisation «s’authentifier» . . . . . . . . . . . . 13

4.1 Description des machines de développement . . . . . . . . . . . . . . . 36

Dans ce rapport, nous commençons dans un premier chapitre par présenter le

CADRE GENERAL DU PROJET

1.1 Cadre du projet

1.2 Preséntation de l’organisme d’Acceuil

1.3 Étude de l’existant

1.4 Critique de l’existant

1.5 Objectifs du projet

• Ergonomique : L’application web doit être capable de répondre efficacement

• Responsive : L’application web devra s’adapter à tous types de navigateurs et

1.6 Méthodologie de développement

1.7 Choix de la méthodologie

1.7.1 Méthode agile SCRUM

Il existe une multitude de méthodes agiles. Il ne s’agit pas de choisir la meilleure

1.7.2 Pourquoi SCRUM ?

La méthodologie SCRUM est une approche de gestion des projets. L’objectif

Plus de souplesse et de réactivité.

La grande capacité d’adaptation au changement grâce à des itérations courtes.

SCRUM rassemble les deux côtés, théorique et pratique, et se rapproche beaucoup

1.7.3 Les acteurs SCRUM :

Citons les trois rôles principaux dans SCRUM :

Le responsable produit : le représentant des clients et des utilisateurs. Il détermine

L’équipe projet : les développeurs sont chargés de construire ce que le responsable

SCRUM Master : le responsable au bon déroulement des différentes étapes du

1.7.4 Les évenements SCRUM :

- Le sprint : est une période de 2 à 4 semaines maximum pendant laquelle une

- Mêlée quotidienne : un « stand-up meeting » quotidien qui permet à l’équipe de

Figure 1.1 – Méthodologie SCRUM [1]

1.8 La modélisation objet

1.8.1 Définition de UML

UML se définit comme un langage de modélisation graphique et textuel destiné à

1.8.2 Processus de modélisation

Le processus que nous allons présenter et appliquer tout au long de ce rapport :

• Conduit par les cas d’utilisation.

• Fondé sur l’utilisation d’un sous-ensemble nécessaire et suffisant du langage

l’analyse et la spécification des besoins en décrivant l’ensemble des caractéristiques

ANALYSE ET SPECIFICATION DES

2.1 Capture des besoins

2.1.1 Identification des acteurs

• un administrateurs : sont chargés de la gestion du site, que ce soit la mainte-

• Un Utilisateur : est un utilisateur du site qui a déposé une ou plusieurs an-

2.1.2 Besoins fonctionnels

Les besoins fonctionnels, ils s’agissent des besoins spécifiant un comportement

Notre produit doit répondre aux besoins suivants :

• Gestion des annonces : Elle permet à l’administrateur de supprimer une annonce

• Gestion des catégories : Elle permet à l’administrateur de créer , modifier ou

• Gestion des utilisaturs : Elle permet de supprimer un utilisateur.