Dédicaces

je tiens à vous remercier du fond du cœur, chers parents et toutes les personnes qui
m’ont encouragé .

Hedy Fathallah

i
Dédicaces ii

À mes parents.

Mohamed Habib Frigui

Remerciements

En premier lieu, nous remercions Dieu, le tout-puissant pour ses faveurs et ses grâces,
de nous avoir donné le courage et la patience de mener ce travail.

Nous tenons également à exprimer notre sincère gratitude et nos remerciements à notre
encadrante académique, Madame Marwa Abdelhafidh pour sa disponibilité, sa pa-
tience et les conseils qu’elle nous a généreusement prodigués tout au long de la réalisation
de ce travail de fin d’études.

Nous remercions toute l’équipe Quetratech pour leur soutien contenu et leur encoura-
gement durant la réalisation de ce projet.

Enfin, nous tenons à exprimer notre profonde gratitude envers l’ensemble de nos ensei-
gnants et de tout le personnel de l’Institut Supérieur d’Informatique de Mahdia, ainsi
qu’envers les membres du jury Madame Raja Fdhila et Madame Imen Toumia qui
ont accepté d’évaluer notre humble projet.

iii
Table des matières

Dédicaces i

Remerciements iii

Table des matières iv

Table des figures vii

Liste des tableaux ix

Introduction générale 1

1 Contexte général 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . 4
1.2.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Etude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Langage de conception . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Architecture utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 12
1.7.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.7.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . 15

iv
Table des matières v

1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Sprint 0 : Analyse et spécification des besoins 18

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Pilotage de projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . 23
2.6 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Sprint 1 : Gestion des utilisateurs 27

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 Classification des cas d’utilisation par acteur . . . . . . . . . . . . . 29
3.2.3 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 29
3.2.4 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . 30
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.1 Diagramme de séquence «S’inscrire» . . . . . . . . . . . . . . . . . 34
3.3.2 Diagramme de séquence «S’authentifier» . . . . . . . . . . . . . . . 35
3.3.3 Diagramme de séquence «Réinitialiser mot de passe» . . . . . . . . 36
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table des matières vi

4 Sprint 2 : Gestion des produits 44

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2 Classification des cas d’utilisation par acteur . . . . . . . . . . . . . 45
4.2.3 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 46
4.2.4 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . 47
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.1 Diagramme de séquence «Ajouter un article» . . . . . . . . . . . . . 50
4.3.2 Diagramme de séquence «Modifier un article» . . . . . . . . . . . . 51
4.3.3 Diagramme de séquence «Supprimer un article» . . . . . . . . . . . 52
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Sprint 3 : Gestion des commandes et des livraisons 57

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.2 Classification des cas d’utilisation par acteur . . . . . . . . . . . . . 59
5.2.3 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 59
5.2.4 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . 60
5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.1 Diagramme de séquence «Passer une commande» . . . . . . . . . . 62
5.3.2 Diagramme de séquence «Affecter un livreur à une livraison» . . . . 63
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Conclusion et perspectives 69
Table des figures

1.1 Logo - QuetraTech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Capture d’écran du soie <Bringg> . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Capture d’écran du site <Route4me> . . . . . . . . . . . . . . . . . . . . . 6
1.4 Capture d’écran du site <Instacart> . . . . . . . . . . . . . . . . . . . . . 7
1.5 Le processus de la méthode Scrum . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Logo - Langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 Logo- PlantUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.9 Logo- LaTeX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.10 Logo- Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.11 Logo- Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.12 Logo- Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.13 Logo- GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.14 Logo- Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.15 Logo- Reactjs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.16 Logo- Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.17 Logo- Express.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.18 Logo- MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

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

2.2 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . . . . . . . . 30

3.2 Diagramme de séquence «S’inscrire» en cas du client . . . . . . . . . . . . 34
3.3 Diagramme de séquence «S’inscrire» en cas du gérant ou livreur . . . . . . 35
3.4 Diagramme de séquence «S’authentifier» . . . . . . . . . . . . . . . . . . . 36

vii
Table des figures viii

3.5 Diagramme de séquence «Réinitialiser mot de passe» . . . . . . . . . . . . 37

3.6 L’interface d’inscription en tant que client . . . . . . . . . . . . . . . . . . 38
3.7 L’interface d’inscription en tant que gérant / livreur . . . . . . . . . . . . . 38
3.8 L’interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9 L’interface «Mot de passe oublié» . . . . . . . . . . . . . . . . . . . . . . . 40
3.10 L’interface «Changer le mot de passe» . . . . . . . . . . . . . . . . . . . . 40
3.11 L’interface de la gestion des gérants . . . . . . . . . . . . . . . . . . . . . . 41
3.12 L’interface de la gestion des livreurs . . . . . . . . . . . . . . . . . . . . . . 42
3.13 L’interface de la gestion des clients» . . . . . . . . . . . . . . . . . . . . . . 42

4.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . 47

4.2 Diagramme de séquence «Ajouter un article» . . . . . . . . . . . . . . . . . 51
4.3 Diagramme de séquence «Modifier un article» . . . . . . . . . . . . . . . . 52
4.4 Diagramme de séquence «Supprimer un article» . . . . . . . . . . . . . . . 53
4.5 L’interface «Shop» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.6 L’interface «Détails d’un produit» . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 L’interface «Panier» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.8 L’interface «Ajouter un produit» . . . . . . . . . . . . . . . . . . . . . . . 55
4.9 L’interface «Modifier un produit» . . . . . . . . . . . . . . . . . . . . . . . 56

5.1 Diagramme de cas d’utilisation du sprint 3 . . . . . . . . . . . . . . . . . . 60

5.2 Diagramme de séquence «Passer une commande» . . . . . . . . . . . . . . 63
5.3 Diagramme de séquence «Affecter un livreur à une livraison» . . . . . . . . 64
5.4 L’interface «Mes commandes» . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5 L’interface «Livraisons en cours» . . . . . . . . . . . . . . . . . . . . . . . 65
5.6 L’interface «Historique des livraisons» . . . . . . . . . . . . . . . . . . . . 66
5.7 L’interface «Affecter un livreur» . . . . . . . . . . . . . . . . . . . . . . . . 66
5.8 L’interface «Dashboard de l’admin» . . . . . . . . . . . . . . . . . . . . . . 67
5.9 L’interface «Dashboard du gérant» . . . . . . . . . . . . . . . . . . . . . . 67
Liste des tableaux

1.1 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Caractéristiques des machines . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Backlog de notre projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Classification des cas d’utilisation par acteur sprint 1 . . . . . . . . . . . . 29
3.3 Description textuelle du cas d’utilisation «S’inscrire» . . . . . . . . . . . . 31
3.4 Description textuelle du cas d’utilisation «S’authentifier» . . . . . . . . . . 32
3.5 Description textuelle du cas d’utilisation «Réinitialiser mot de passe» . . . 33
3.6 Description textuelle du cas d’utilisation «Supprimer un utilisateur» . . . . 33

4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Classification des cas d’utilisation par acteur sprint 2 . . . . . . . . . . . . 46
4.3 Description textuelle du cas d’utilisation «Ajouter un article» . . . . . . . 48
4.4 Description textuelle du cas d’utilisation «Modifier un article» . . . . . . . 49
4.5 Description textuelle du cas d’utilisation «Gérer le panier» . . . . . . . . . 50

5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2 Classification des cas d’utilisation par acteur sprint 3 . . . . . . . . . . . . 59
5.3 Description textuelle du cas d’utilisation «Passer une commande» . . . . . 61
5.4 Description textuelle du cas d’utilisation «Affecter une livraison à un livreur» 62

ix
Introduction générale

Dans les années 90, l’émergence des premiers sites Internet destinés au grand public
a permis aux entreprises de réaliser l’importance des connexions avec les clients pour
découvrir de nouveaux produits et de nouvelles façons de naviguer, comparer et acheter
des produits en quelques clics seulement. Cela a initié une évolution importante vers le
déplacement des transactions commerciales vers la voie virtuelle de l’internet.

De nos jours, il est devenu essentiel pour toutes les entreprises d’avoir une présence
en ligne afin de développer rapidement leur activité et d’atteindre un public plus large de
clients et de consommateurs actifs. Cette présence en ligne est indispensable pour aug-
menter leur base de communauté et favoriser leur croissance.

En Tunisie, les ventes en ligne ont connu une croissance significative ces dernières an-
nées. Les entreprises de livraison ont besoin d’une solution de gestion de livraisons pour
améliorer la visibilité de leurs services et la qualité de leur relation avec les clients.

Dans cette perspective, s’inscrit notre projet de fin d’études qui vise à la conception et
le développement une solution de gestion des livraisons pour les entreprises en ligne. Cette
solution vise à faciliter la gestion des flux de travail, à améliorer l’efficacité du processus
de livraison et à augmenter la satisfaction des clients.

Nous présenterons les différentes phases de ce projet en cinq chapitres :

— Chapitre 1 : intitulé "Contexte général" dans lequel nous présentons l’organisme
d’accueil et procédons à une étude de l’existant en proposant une solution qui
répond aux besoins des utilisateurs.
— Chapitre 2 : intitulé "Sprint 0 : Analyse et spécification des besoins" dans lequel

1
Introduction générale 2

on va spécifier les acteurs et leurs besoins ansi que le backlog du produit.

— Chapitre 3 : intitulé "Sprint 1 : Gestion des utilisateurs" est une description du
premier sprint à étudier.
— Chapitre 4 : intitulé "Sprint 2 : Gestion des produits" est une description du
deuxième sprint à étudier.
— Chapitre 5 : intitulé "Sprint 3 : Gestion des commandes et des livraisons" est une
description du troisième sprint à étudier.
 Chapitre 1

Contexte général
Contexte général 4

1.1 Introduction

Ce chapitre donne un aperçu général du projet en commençant par présenter l’orga-

nisation qui héberge le projet. Ensuite, il propose une analyse de la situation actuelle en
mettant en évidence les points forts et les points faibles identifiés. Enfin, il présente une
solution pour résoudre les problèmes existants, ainsi que la méthodologie de travail adop-
tée et le choix du langage de conception. Nous mettrons également notre environnement
matériel et logiciel utilisé, ainsi que nos choix techniques.

1.2 Présentation du projet

1.2.1 Cadre du projet

Dans le cadre de notre cursus en informatique, à ’Institut Supérieur d’informatique de

Mahdia (ISIMa), nous avons effectué un stage chez l’entreprise de développement Que-
traTech. Durant une période de quatre mois, du 6 février 2023 au 6 juin 2023, nous nous
sommes engagés dans le développement d’une application dédié à la gestion de livraisons.
Cette application vise à améliorer l’efficacité du processus de livraison de l’entreprise, à
réduire les coûts, à augmenter la satisfaction des clients et à simplifier les opérations.

1.2.2 Présentation de l’organisme d’accueil

QuetraTech (dont l’illustration de son logo est présentée dans la figure 1.1) est une
équipe complète de conception et de développement, possédant une expertise avérée dans
la création d’applications Web complexes, de sites e-commerce, d’applications mobiles,
de solutions IoT et d’image de marque. Depuis 2020, QuetraTech propose une gamme
complète de services de conception, développement, marketing et internet des objets pour
répondre aux besoins des marques émergentes.
Contexte général 5

Figure 1.1 – Logo - QuetraTech

1.2.3 Problématique

La croissance du commerce en ligne a engendré une augmentation significative des

besoins en matière de livraison, ce qui a contraint les entreprises à repenser leurs stratégies
de livraison afin de satisfaire les attentes de leurs clients. Aujourd’hui, la gestion de la
livraison joue un rôle clé dans la satisfaction des clients et la compétitivité des entreprises.
C’est pourquoi de nombreuses entreprises considèrent la mise en place d’un Marketplace
avec système de gestion de livraisons intégré performant comme une priorité essentielle.

1.3 Etude et critique de l’existant

Pour élaborer une solution compétitive, nous procéderons à une étude préliminaire
afin d’évaluer les solutions informatiques actuellement en place. Cette étape revêt une
importance cruciale pour comprendre les besoins des clients et définir les objectifs à at-
teindre. De plus, elle nous permettra d’évaluer les logiciels existants et de déterminer leurs
avantages et inconvénients respectifs.
— Bringg : (dont la page d’accueil apparait dans la figure 1.2) est une plateforme
de gestion de livraisons offrant des fonctionnalités telles que le suivi en temps réel,
l’optimisation des itinéraires, la communication avec les clients et la gestion des
tâches.
Contexte général 6

Figure 1.2 – Capture d’´ecran du site <Bringg>

— Route4me : (dont la page d’accueil est illustrée par la figure 1.3) est une solution
Web et mobile qui fournit une optimisation d’itinéraire en temps réel, un suivi GPS
et une planification de livraison à arrêts multiples.

Figure 1.3 – Capture d’écran du site <Route4me>

— Instacart : (dont la page d’accueil est visible dans la figure 1.4) est un service de
livraison d’épicerie à la demande.
Contexte général 7

Figure 1.4 – Capture d’écran du site <Instacart>

Dans le tableau suivant, nous avons fait une étude comparative de ces trois solutions
en mentionnant leurs points forts et leurs points faibles :

Points forts Points faibles

Bringg - Plate-forme de livraison per- - Interface utilisateur complexe

sonnalisable pour répondre aux et difficile à prendre en main.
besoins spécifiques des entre- - Coût élevé, en particulier pour
prises. les petites entreprises ou les uti-
- Possibilité de suivre en temps lisateurs individuels.
réel les livraisons et de fournir
des mises à jour en direct aux
clients.
Contexte général 8

Route4me - Interface facile à utiliser pour - En raison de la flexibilité of-

planifier des itinéraires avec des
étapes multiples.
- Possibilité d’ajouter des infor-
mations personnalisées sur les
clients et les destinations.
ferte par Route4Me, il peut être
complexe à configurer et à utili-
ser.
-Support client de Route4Me
peut être limité, surtout pour
les forfaits les moins chers.

Instacart - Les clients peuvent suivre leur
commande en temps réel.
-Possibilité de commander des
courses auprès d’une variété de
magasins différents.
- Instacart n’est disponible que
dans certaines zones géogra-
phiques, ce qui peut limiter sa
portée pour certains clients.
- Seuls les produits d’épicerie
sont disponibles.

Table 1.1 – Critique de l’existant

1.4 Solution proposée

Après avoir effectué une étude comparative des différentes solutions existantes et
compte tenu à leurs limites, il est apparu crucial de proposer une solution. En fait, les
clients auront la possibilité de commander plusieurs produits auprès de différents vendeurs
et de les recevoir en une seule livraison. Par la suite, notre solution permet essentiellement
de :
— La gestion des utilisateurs : permet d’ajouter, modifier et supprimer des utilisateurs
tout en gérant de manière optimale les droits d’accès qui leur sont accordés.
— La gestion des produits : permet à chaque gérant (vendeur) de créer, modifier,
Contexte général 9

supprimer et visualiser ses produits.

— La gestion des commandes et des livraisons : consiste à traiter et suivre les com-
mandes et les livraisons tout en assurant le lien entre le vendeur, le livreur et le
client.
— La visualisation du Dashboard : permet à l’administrateur de suivre les activités
du site web.

1.5 Choix de la méthodologie

Dans cette partie, nous allons présenter la méthodologie de travail choisie. Nous avons
décidé d’appliquer la méthode Agile (Scrum [1]) tout au long du projet. La méthode Agile
est une approche itérative et collaborative de gestion de projet qui permet d’adapter le
développement en fonction des besoins et des retours des utilisateurs. Elle se base sur des
principes de communication et de collaboration entre les différents membres de l’équipe du
projet. L’objectif est de livrer rapidement des produits fonctionnels tout en étant capable
de répondre rapidement aux changements et aux évolutions du projet. Scrum est l’une des
méthodes agiles les plus populaires qui s’appuie sur des cycles de développement itératifs
et incrémentaux appelés « sprints ». La figure 1.5 illustre bien le processus Scrum.
Contexte général 10

Figure 1.5 – Le processus de la méthode Scrum

1.5.1 Langage de conception

Nous allons travailler avec UML [2] (Unified Modeling Language). Ce langage de mo-
délisation graphique (dont le logo est illustré par la figure 1.6) est conçu comme une
méthode normalisée de visualisation dans les domaines du développement logiciel et de
la conception orientée objet, et utilise des pictogrammes pour représenter les différentes
composantes des systèmes.
Contexte général 11

Figure 1.6 – Logo - Langage UML

1.6 Architecture utilisée

Nous avons utilisé le modèle MVC [3] (Modèle-Vue-Contrôleur). En effet, il est un

patron de conception de logiciel qui divise une application en trois parties distinctes : le
modèle, la vue et le contrôleur.
— Modèle : représente les données et la logique métier de l’application. Il gère les
interactions avec la base de données ou les services web, les calculs et les opérations
sur les données.
— Vue : représente l’interface utilisateur de l’application. Elle affiche les données et
les résultats de traitement au format adapté à l’utilisateur et gère les interactions
de l’utilisateur avec l’application.
— Contrôleur : gère la logique de traitement et de coordination entre le modèle et
la vue. Il reçoit les entrées de l’utilisateur à travers la vue, effectue les opérations
nécessaires sur le modèle et met à jour la vue pour afficher les résultats.
L’utilisation de cette architecture permet de séparer les préoccupations de développe-
ment en couches distinctes, ce qui facilite la maintenance, la réutilisation et l’évolution
de l’application.
Contexte général 12

Figure 1.7 – Architecture MVC

1.7 Environnement de développement

Dans cette section, nous présentons l’environnement de développement mis en place

pour notre projet, y compris le matériel, les logiciels et les technologies choisies.

1.7.1 Environnement matériel

Le tableau suivant indique les caractéristiques des machines utilisées tout au long de
ce projet :
Contexte général 13

Num pc1 pc2

Ordinateur msi asus

Processeur Intel Core i7 11ème génération Intel Core i7 10ème génération

Mémoire vive 16 GB 8 GB

Disque dur 512 ssd 512 ssd

Système d’exploitation Windows 11 Windows 11

Table 1.2 – Caractéristiques des machines

1.7.2 Environnement logiciel

Dans cette partie, nous présentons la liste des environnements logiciels utilisés tout au
long du projet.
PlantUML [4] : PlantUML (dont le logo est illustré par la figure 1.8) est un langage
de description graphique utilisé pour créer des diagrammes UML. Il permet de générer
des diagrammes en utilisant une syntaxe textuelle simple et intuitive.

Figure 1.8 – Logo- PlantUML.

LaTeX [5] : LaTeX (dont le logo est illustré par la figure 1.9) est un système de
composition de documents destiné principalement à la création de documents techniques
et scientifiques, tels que des articles, des livres, des thèses et des présentations. Il utilise
des commandes de formatage pour structurer le texte.
Contexte général 14

Figure 1.9 – Logo- LaTeX.

Overleaf [6] : Overleaf (dont le logo est illustré par la figure 1.10) est un éditeur de
texte en ligne pour LaTeX qui permet aux utilisateurs de collaborer sur des projets de
documents en temps réel.

Figure 1.10 – Logo- Overleaf.

Visual Studio Code [7] : Visual Studio Code (dont le logo est illustré par la figure
1.11) est un éditeur de code source gratuit et open-source développé par Microsoft pour
Windows, Linux et macOS.

Figure 1.11 – Logo- Visual Studio Code.

Git [8] : Git (dont le logo est illustré par la figure 1.12) est un système de contrôle
de version distribué gratuit et open-source.
Contexte général 15

Figure 1.12 – Logo- Git.

GitHub [9] : GitHub (dont le logo est illustré par la figure 1.13) est une plateforme
en ligne de gestion de versions basée sur Git.

Figure 1.13 – Logo- GitHub.

Postman [10] : Postman (dont le logo est illustré par la figure 1.14) est un outil de
collaboration et de test d’API qui facilite l’envoi de requêtes HTTP et HTTPS et l’analyse
des réponses.

Figure 1.14 – Logo- Postman.

1.7.3 Technologies utilisées

Dans cette partie, nous présentons les différentes technologies choisies pour réaliser ce
projet.
Reactjs [12] : ReactJS (dont le logo est illustré par la figure 1.15) est une bibliothèque
JavaScript open-source développée par Facebook depuis 2013, utilisée pour la construction
Contexte général 16

d’interfaces utilisateur.

Figure 1.15 – Logo- Reactjs.

Node.js [13] : Node.js (dont le logo est illustré par la figure 1.16) est un environ-
nement d’exécution permettant aux développeurs de créer des applications côté serveur
avec JavaScript.

Figure 1.16 – Logo- Node.js.

Express.js [14] : Express.js (dont le logo est illustré par la figure 1.17) est un fra-
mework de développement web Node.js minimaliste et flexible qui permet de créer des
applications web robustes et performantes.éer des applications côté serveur avec JavaS-
cript.

Figure 1.17 – Logo- Express.js.

MongoDB [15] : MongoDB (dont le logo est illustré par la figure 1.18) est une base
de données NoSQL de type document orientée objet qui stocke les données sous forme de
documents JSON.
Contexte général 17

Figure 1.18 – Logo- MongoDB.

1.8 Conclusion

Au cours de ce chapitre, nous avons introduit l’organisme d’accueil et décrit le travail

qui nous a été assigné. Nous avons également fourni un contexte général pour notre projet
et exposé la méthodologie de conception que nous allons utiliser dans les chapitres suivants
ainsi que l’environnement matériel et logiciel de développement.
 Chapitre 2

Sprint 0 : Analyse et spécification

des besoins
Sprint 0 : Analyse et spécification des besoins 19

2.1 Introduction

Ce chapitre représente la première étape de réalisation de ce projet. Nous commençons

par la détermination des acteurs ainsi que les besoins fonctionnels et non fonctionnels du
projet. Nous présentons par la suite le backlog du produit et les diagrammes de cas
d’utilisation et de classes globaux.

2.2 Identification des acteurs

Un acteur est une entité (personne, logiciel ou matériel) qui interagit avec le système.
Dans notre projet nous avons quatre acteurs :
— Administrateur : Il joue un rôle primordial pour assurer le bon fonctionnement
du système. Il prend en charge la gestion de tous ses aspects.
— Gérant : Il est responsable de la gestion des produits.
— Livreur : Il est responsable de la livraison des commandes.
— Client : Il est capable de passer des commandes et de les suivre.

2.3 Spécification des besoins

Les prochaines sous-sections définissent les différents besoins fonctionnels et non fonc-
tionnels que notre application suit.

2.3.1 Besoins fonctionnels

L’administrateur
— Se connecter en tant qu’administrateur
— Valider les comptes utilisateurs
— Gérer les listes des utilisateurs
— Gérer la liste de livraisons
— Afficher les statistiques
Sprint 0 : Analyse et spécification des besoins 20

Le gérant
— S’inscrire
— Se connecter en tant que gestionnaire
— Réinitialiser le mot de passe
— Recevoir des notifications de commandes
— Gérer les produits
Le livreur
— S’inscrire
— Se connecter en tant que livreur
— Réinitialiser le mot de passe
— Changer le statut de la livraison
— Voir l’historique des livraisons effectuées
Le client
— S’inscrire
— Se connecter en tant que client
— Réinitialiser le mot de passe
— Commander
— Gérer le panier
— Afficher les articles
— Suivre la commande
— Afficher l’historique des commandes

2.3.2 Besoins non fonctionnels

Ce sont les aspects et les comportements qui ne sont pas directement liés aux fonction-
nalités concrètes du produit. Ils sont des indicateurs de qualité de l’exécution des besoins
fonctionnels. Notre application garantit principalement :
— La convivialité : L’application doit être facile à utiliser. Elle doit fournir une
interface utilisateur simple et ergonomique.
Sprint 0 : Analyse et spécification des besoins 21

— L’extensibilité : L’application doit être flexible aux mises à jour et aux change-
ments de fonctionnalités.
— La performance : L’application doit être efficace avec un temps de réponse rapide.
— La sécurité : L’application doit être sécurisée. Elle doit assurer la confidentialité
et l’intégrité et contrôler l’accès aux données.
— La maintenance : Le code source doit être claire et compréhensible.
— La disponibilité : L’application doit être disponible en permanence et accessible
à tous les utilisateurs.

2.4 Pilotage de projet avec Scrum

La première étape de notre processus de projet consiste à établir le backlog du produit

et à planifier les sprints.

2.4.1 Backlog du produit

Le Backlog du produit est une liste des fonctionnalités requises dans le produit, ordon-
nées par ordre de priorité. Le tableau suivant représente le backlog du produit de notre
projet :

ID Fonctionnalité ID User Story Priorité

1 S’inscrire 1.1 - En tant que utilisateur (gérant, li- 1

vreur, client), je peux m’inscrire sur la
plate-forme.

2 S’authentifier 2.1 - En tant qu’utilisateur, je dois m’au- 1

thentifier en fournissant mon email et
mon mot de passe.
Sprint 0 : Analyse et spécification des besoins 22

3 Réinitialiser le mot 3.1 - En tant qu’utilisateur, je peux réini- 1

de passe tialiser mon mot de passe.

4 Gérer les utilisa- 4.1 - En tant qu’administrateur, je peux ac- 2

teurs tiver les comptes des gérants et des li-
vreurs.
4.2 - En tant qu’administrateur, je peux
supprimer les comptes des gérants, des
livreurs et des clients.

5 Visualiser les sta- 5.1 - En tant qu’utilisateur (administrateur 4

tistiques ou gérant), je peux visualiser les statis-
tiques à travers un dashboard.

6 Recevoir des noti- 6.1 - En tant que gérant, je peux recevoir 3

fiations des notifications par mail concernant les
commandes passées.

7 Passer une com- 7.1 - En tant que client, je peux passer une 3
mande commande.

8 Consulter la liste 8.1 - En tant qu’administrateur ou livreur, 3

des livraisons je peux accéder à la liste des livraisons.

9 Gérer une demande 9.1 - En tant qu’administrateur, je peux af- 3

de livraison fecter une livraison à un livreur.

10 Gérer les articles 10.1 - En tant que gérant, je peux ajouter, 2

supprimer et modifier un article.
Sprint 0 : Analyse et spécification des besoins 23

11 Consulter les ar- 11.1 - En tant que client, je peux consulter 2

ticles les articles.

12 Gérer le panier 12.1 - En tant que client, je peux gérer mon 2

panier.

13 Suivre la com- 13.1 - En tant que client, je peux suivre une 3

mande commande.

Table 2.1 – Backlog de notre projet

2.4.2 Planification des sprints

Après avoir déterminé le backlog du produit, nous avons découpé notre projet en 3
sprints :
— Sprint 1 : Gestion des utilisateurs
— Sprint 2 : Gestion des produits
— Sprint 3 : Gestion des commandes et des livraisons

2.5 Diagramme de cas d’utilisation global

La figure 2.1 représente le diagramme de cas d’utilisation global de notre projet :

Sprint 0 : Analyse et spécification des besoins 24

Figure 2.1 – Diagramme de cas d’utilisation global

2.6 Diagramme de classes global

La figure 2.2 représente le diagramme de classes global de notre projet :

Sprint 0 : Analyse et spécification des besoins 25

Figure 2.2 – Diagramme de classes global

Sprint 0 : Analyse et spécification des besoins 26

2.7 Conclusion

Dans ce chapitre nous avons détaillé les acteurs ainsi que les exigences fonctionnelles
et non fonctionnelles de notre projet. Nous avons présenté aussi le backlog du produit
suivi des diagrammes de cas d’utilisation et de classes globaux.
 Chapitre 3

Sprint 1 : Gestion des utilisateurs

Sprint 1 : Gestion des utilisateurs 28

3.1 Introduction

Dans ce chapitre, nous allons aborder les fonctionnalités liées au premier sprint qui
se concentre sur la gestion des utilisateurs. Nous allons ainsi détailler la spécification
fonctionnelle, la conception et la réalisation.

3.2 Spécification fonctionnelle

3.2.1 Backlog du sprint

Le tableau ci dessous représente le backlog du premier sprint :

Tâche Priorité

- En tant que utilisateur (gérant, livreur, client), je peux m’ins- 1

crire sur la plate-forme.

- En tant qu’utilisateur (admin, gérant, livreur, client), je dois 1

m’authentifier.

- En tant qu’utilisateur (admin, gérant, livreur, client), je peux 2

réinitialiser mon mot de passe.

- En tant qu’administrateur, je peux activer les comptes des 1

gérants et des livreurs.

- En tant qu’administrateur, je peux supprimer les comptes des 2

gérants, des livreurs et des clients.

Table 3.1 – Backlog du sprint 1

Sprint 1 : Gestion des utilisateurs 29

3.2.2 Classification des cas d’utilisation par acteur

Le tableau ci-dessous présente la spécification de l’ensemble des fonctionnalités par

acteur :

Acteur Cas d’utilisation

Administrateur - S’authentifier
- Réinitialiser le mot de passe
- Activer les comptes des gérants
- Activer les comptes des livreurs
- Supprimer un compte d’un utilisateur

Gérant - S’inscrire
- S’authentifier
- Réinitialiser le mot de passe

Livreur - S’inscrire
- S’authentifier
- Réinitialiser le mot de passe

Client - S’inscrire
- S’authentifier
- Réinitialiser le mot de passe

Table 3.2 – Classification des cas d’utilisation par acteur sprint 1

3.2.3 Diagramme de cas d’utilisation

La figure 3.1 illustre le diagramme de cas d’utilisation du premier sprint :

Sprint 1 : Gestion des utilisateurs 30

Figure 3.1 – Diagramme de cas d’utilisation du sprint 1

3.2.4 Description textuelle des cas d’utilisation

Dans cette section, nous allons élaborer d’avantage sur les cas d’utilisation du sprint
1 pour fournir une description détaillée des divers scénarios possibles.
— Le cas d’utilisation «S’inscrire»
Le tableau ci-dessous détaille le cas d’utilisation

Cas d’utilisation S’inscrire

Acteurs Gérant, livreur et client

Pré-condition - L’utilisateur doit être non inscrit.

- L’utilisateur doit remplir le formulaire d’inscrip-
tion.

Post-condition - En cas du client : L’utilisateur est inscrit.

- En cas du gérant ou livreur : L’utilisateur est soit
inscrit soit éliminé.
Sprint 1 : Gestion des utilisateurs 31

Scénario principal 1- L’utilisateur demande l’interface d’inscription adé-

quate.
2- L’utilisateur remplit le formulaire d’inscription et
clique sur le bouton s’inscrire.
3.1- En cas du client, le système vérifie les données
et envoie un mot de passe par email au client.
3.2.1- En cas du gérant ou livreur, le système envoie
un email de confirmation en attendant l’approbation
ou le rejet de la demande par l’administrateur.
3.2.2- Le système envoie un email contenant la déci-
sion de l’administrateur.

Scénario alternatif - Les données saisies sont erronées alors Retour à

l’étape 2.
- L’utilisateur est déjà existant dans la base de don-
nées.

Table 3.3 – Description textuelle du cas d’utilisation «S’inscrire»

— Le cas d’utilisation «S’authentifier»

Le tableau ci-dessous détaille le cas d’utilisation

Cas d’utilisation S’authentifier

Acteurs Administrateur, gérant, livreur et client

Pré-condition - L’utilisateur doit être inscrit.

- L’utilisateur doit entrer ses identifiants.
Sprint 1 : Gestion des utilisateurs 32

Post-condition - L’utilisateur est connecté et dirigé vers l’interface

adéquate selon son rôle.

Scénario principal 1- L’utilisateur demande l’interface d’authentifica-

tion.
2- L’utilisateur remplit le formulaire et le valide.
3- Le système vérifie les données et donne à l’utilisa-
teur l’accès à l’interface adéquate.

Scénario alternatif - Les données saisies sont erronées et ce scénario va

retourner au point 2.

Table 3.4 – Description textuelle du cas d’utilisation «S’authentifier»

— Le cas d’utilisation «Réinitialiser mot de passe»

Le tableau ci-dessous détaille le cas d’utilisation

Cas d’utilisation Réinitialiser mot de passe

Acteurs Administrateur, gérant, livreur et client

Pré-condition - L’utilisateur doit être connecté.

- L’utilisateur doit remplir les champs du formulaire.

Post-condition - Le mot de passe est réinitialisé

Scénario principal 1- L’utilisateur demande l’interface.

2- L’utilisateur remplit le formulaire et le valide.
3- Le système vérifie les données et réinitialise le mot
de passe.
Sprint 1 : Gestion des utilisateurs 33

Scénario alternatif - Les données saisies sont erronées et retour au point

2.

Table 3.5 – Description textuelle du cas d’utilisation «Réinitialiser mot de

passe»

— Le cas d’utilisation «Supprimer un utilisateur» Le tableau ci-dessous détaille

le cas d’utilisation

Cas d’utilisation Supprimer un utilisateur

Acteurs Administrateur

Pré-condition - L’administrateur doit être connecté.

Post-condition - Le compte est supprimé.

Scénario principal 1- L’administrateur demande l’interface.

2- L’administrateur clique sur "Supprimer" et
confirme.

Scénario alternatif - L’administrateur annule la suppression.

Table 3.6 – Description textuelle du cas d’utilisation «Supprimer un utilisateur»

3.3 Conception

Au sein de cette section, nous allons exposer les diagrammes de séquences et le dia-
gramme de classes des fonctionnalités de ce sprint.
Sprint 1 : Gestion des utilisateurs 34

3.3.1 Diagramme de séquence «S’inscrire»

Le processus d’inscription du client n’est pas le même que celui du gérant ou livreur.
Nous allons représenter le diagramme de séquence de chacun d’eux. La figure 3.2 représente
le diagramme de séquence de l’inscription du client.

Figure 3.2 – Diagramme de séquence «S’inscrire» en cas du client.

La figure 3.3 représente le diagramme de séquence de l’inscription du gérant ou du

livreur.
Sprint 1 : Gestion des utilisateurs 35

Figure 3.3 – Diagramme de séquence «S’inscrire» en cas du gérant ou livreur.

3.3.2 Diagramme de séquence «S’authentifier»

La figure 3.4 représente le diagramme de séquence de l’authentification.

Sprint 1 : Gestion des utilisateurs 36

Figure 3.4 – Diagramme de séquence «S’authentifier».

3.3.3 Diagramme de séquence «Réinitialiser mot de passe»

La figure 3.5 représente le diagramme de séquence de la réinitialisation de mot de

passe.
Sprint 1 : Gestion des utilisateurs 37

Figure 3.5 – Diagramme de séquence «Réinitialiser mot de passe».

3.4 Réalisation

Dans cette partie, nous présentons une visualisation du travail accompli dans ce sprint.

Interface «Inscription au tant que client»

Un client accède à cette interface pour s’inscrire où il saisit son email.
Sprint 1 : Gestion des utilisateurs 38

Figure 3.6 – L’interface d’inscription en tant que client.

Interface «Inscription au tant que gérant / livreur»

Un utilisateur peut s’inscrit en tant que gérant ou livreur à travers cette interface où il
doit saisir tous ses informations.

Figure 3.7 – L’interface d’inscription en tant que gérant / livreur.

Sprint 1 : Gestion des utilisateurs 39

Interface «Authentification»
L’utilisateur se connecte sur l’application à travers cette interface tout en introduisant
son email et son mot de passe.

Figure 3.8 – L’interface d’authentification.

Interface «Mot de passe oublié»

Si un utilisateur oublie son mot de passe, il peut demander un autre mot de passe à travers
cette interface.
Sprint 1 : Gestion des utilisateurs 40

Figure 3.9 – L’interface «Mot de passe oublié».

Interface «Changer le mot de passe»

Chaque utilisateur a la possibilité de changer son mot de passe à travers cette interface.
Il doit respecter les conditions de création de mot de passe.

Figure 3.10 – L’interface «Changer le mot de passe».

Sprint 1 : Gestion des utilisateurs 41

Interface «Gestion des gérants»

Cette interface, comme illustré dans la figure3.11, permet à l’administrateur du site de
visualiser la liste des gérants, de supprimer un gérant existant et de gérer les demandes
d’inscription en tant que gérant en les acceptant ou en les rejetant.

Figure 3.11 – L’interface de la gestion des gérants.

Interface «Gestion des livreurs»

Cette interface offre à l’administrateur du site la possibilité de consulter la liste des li-
vreurs, de supprimer des livreurs existants, ainsi qu’accepter ou rejeter les demandes
d’inscription en tant que livreur comme le montre la figure 3.12.
Sprint 1 : Gestion des utilisateurs 42

Figure 3.12 – L’interface de la gestion des livreurs.

Interface «Gestion des clients»

A travers cette interface, l’administrateur du site peut consulter la liste des clients. Il peut
également supprimer un client.

Figure 3.13 – L’interface de la gestion des clients.

Sprint 1 : Gestion des utilisateurs 43

3.5 Conclusion

Durant ce chapitre nous avons présenté l’analyse, la conception et la réalisation du

premier sprint. Le chapitre suivant sera consacré pour le deuxième sprint : Gestion des
produits.
 Chapitre 4

Sprint 2 : Gestion des produits

Sprint 2 : Gestion des produits 45

4.1 Introduction

Dans ce chapitre, nous allons aborder les fonctionnalités liées au deuxième sprint qui
porte sur la gestion des produits. Nous allons ainsi détailler la spécification fonctionnelle,
la conception et la réalisation.

4.2 Spécification fonctionnelle

4.2.1 Backlog du sprint

Le tableau ci dessous représente le backlog du deuxième sprint :

Tâche Priorité

- En tant que gérant, je peux ajouter un article. 1

- En tant que gérant, je peux modifier un article. 1

- En tant que gérant, je peux supprimer un article. 1

- En tant que client, je peux consulter les articles. 1

- En tant que client, je peux gérer mon panier. 1

Table 4.1 – Backlog du sprint 2

4.2.2 Classification des cas d’utilisation par acteur

Le tableau ci-dessous présente la spécification de l’ensemble des fonctionnalités par

acteur :
Sprint 2 : Gestion des produits 46

Acteur Cas d’utilisation

Gérant - Ajouter un article

- Modifier un article
- Supprimer un article

Client - Consulter les articles

- Gérer le panier

Table 4.2 – Classification des cas d’utilisation par acteur sprint 2

4.2.3 Diagramme de cas d’utilisation

La figure 4.1 illustre le diagramme de cas d’utilisation du deuxième sprint :

Sprint 2 : Gestion des produits 47

Figure 4.1 – Diagramme de cas d’utilisation du sprint 2

4.2.4 Description textuelle des cas d’utilisation

Cette section est dédiée à une exploration plus approfondie des cas d’utilisation du
sprint 2, dans le but de fournir une description détaillée des différents scénarios envisa-
geables.
— Le cas d’utilisation «Ajouter un article»
Le tableau ci-dessous détaille le cas d’utilisation

Cas d’utilisation Ajouter un article

Acteurs Gérant

Pré-condition - Le gérant doit être authentifié.

Sprint 2 : Gestion des produits 48

Post-condition - Le nouveau article est ajouté avec succès.

Scénario principal 1- Le gérant demande l’interface d’ajout d’un pro-

duit en cliquant sur "Ajouter un produit".
2- Le gérant remplit le formulaire avec les informa-
tions du nouveau produit et clique sur "Ajouter".
3- Le système vérifie les données et ajoute un nou-
veau produit à la base de données.

Scénario alternatif - Les données saisies sont erronées, et ce scénario va

retourner au point 2.

Table 4.3 – Description textuelle du cas d’utilisation «Ajouter un article»

— Le cas d’utilisation «Modifier un article»

Le tableau ci-dessous détaille le cas d’utilisation

Cas d’utilisation Modifier un article

Acteurs Gérant

Pré-condition - Le gérant doit être authentifié.

- L’article à modifier correspond à ce gérant.

Post-condition - L’article est modifié avec succès.

Sprint 2 : Gestion des produits 49

Scénario principal 1- Le gérant demande l’interface pour modifier un

produit.
2- Le système affiche un formulaire avec les informa-
tions actuelles de produit.
3- Le gérant modifie les informations nécessaires et
valide en cliquant sur "Enregistrer".
4- Le système enregistre les modifications dans la
base de données.

Scénario alternatif - Les données saisies sont erronées. Ce scénario va

retourner au point 3.

Table 4.4 – Description textuelle du cas d’utilisation «Modifier un article»

— Le cas d’utilisation «Gérer le panier»

Le tableau ci-dessous détaille le cas d’utilisation

Cas d’utilisation Gérer le panier

Acteurs Client

Pré-condition - Le client doit être authentifié.

Post-condition - Le panier est mis à jour.

Sprint 2 : Gestion des produits 50

Scénario principal 1- Pour ajouter un produit :

1.1- Le client choisit le produit à ajouter au panier
et clique sur "Ajouter au panier".
2- Pour modifier la quantité d’un produit :
2.1- Le client choisit le produit à modifier et clique
sur "+" pour incrémenter ou sur "-" pour décrémen-
ter ou saisit la quantité directement .
3- Pour supprimer un produit :
3.1 Le client choisit le produit à retirer du panier et
clique sur "Supprimer".

Scénario alternatif - Le client ajoute un produit déjà existant dans le

panier, donc incrémentation de la quantité dans le
panier.
- Le client essaie de mettre une quantité non valide.
Un message d’erreur est affiché.

Table 4.5 – Description textuelle du cas d’utilisation «Gérer le panier»

4.3 Conception

Au sein de cette section, nous allons exposer les diagrammes de séquences et le dia-
gramme de classes des fonctionnalités de ce sprint.

4.3.1 Diagramme de séquence «Ajouter un article»

La figure 4.2 représente le diagramme de séquence d’ajouter un article.

Sprint 2 : Gestion des produits 51

Figure 4.2 – Diagramme de séquence «Ajouter un article».

4.3.2 Diagramme de séquence «Modifier un article»

La figure 4.3 représente le diagramme de séquence de modifier un article.

Sprint 2 : Gestion des produits 52

Figure 4.3 – Diagramme de séquence «Modifier un article».

4.3.3 Diagramme de séquence «Supprimer un article»

La figure 4.4 représente le diagramme de séquence de supprimer un article.

Sprint 2 : Gestion des produits 53

Figure 4.4 – Diagramme de séquence «Supprimer un article».

4.4 Réalisation

Dans cette section, nous présentons le travail effectué dans ce sprint à travers des
captures d’écran.

Interface «Shop»
Cette interface est partagée entre le client et le gérant avec quelques différences. Le client
peut consulter tous les produits disponibles, ainsi que le gérant peut consulter et gérer
ses propres produits.
Sprint 2 : Gestion des produits 54

Figure 4.5 – L’interface «Shop».

Interface «Détails d’un produit»

En cliquant sur un produit, le client est dirigé vers cette interface pour obtenir une des-
cription de ce produit.

Figure 4.6 – L’interface «Détails d’un produit».

Interface «Panier»
Le client peu consulter et gérer son panier à travers cette interface. Il est aussi invité à
remplir un petit formulaire avant de passer sa commande.
Sprint 2 : Gestion des produits 55

Figure 4.7 – L’interface «Panier».

Interface «Ajouter un produit»

Le gérant peut ajouter des produits en remplissant ce formulaire.

Figure 4.8 – L’interface «Ajouter un produit».

Sprint 2 : Gestion des produits 56

Interface «Modifier un produit»

Le gérant peut mette à jour un produit ou le supprimer à travers cette interface.

Figure 4.9 – L’interface «Modifier un produit».

4.5 Conclusion

Dans ce chapitre, nous avons exposé l’analyse, la conception et la réalisation du

deuxième sprint. Le prochain chapitre sera consacré au troisième sprint : Gestion des
commandes et des livraisons.
 Chapitre 5

Sprint 3 : Gestion des commandes

et des livraisons
Sprint 3 : Gestion des commandes et des livraisons 58

5.1 Introduction

Au sein de ce chapitre, nous explorerons les fonctionnalités relatives au troisième et

dernier sprint, qui se concentre sur la gestion des commandes et des livraisons. Nous dé-
taillerons la spécification fonctionnelle, ainsi que les phases de conception et de réalisation
de ces fonctionnalités.

5.2 Spécification fonctionnelle

5.2.1 Backlog du sprint

Le tableau ci dessous représente le backlog du troisième sprint :

Tâche Priorité

- En tant que client, je peux passer une commande. 1

- En tant que gérant, je peux recevoir des notifications par mail 1

concernant les commandes passées.

- En tant qu’administrateur ou livreur, je peux consulter la liste 1

des livraisons.

- En tant qu’administrateur, je peux affecter une livraison à un 1

livreur.

- En tant que client, je peux suivre une commande. 1

- En tant qu’administrateur ou grérant, je peux visualiser les 2

statistiques à travers un dashboard.

Table 5.1 – Backlog du sprint 3

Sprint 3 : Gestion des commandes et des livraisons 59

5.2.2 Classification des cas d’utilisation par acteur

Le tableau ci-dessous présente la spécification de l’ensemble des fonctionnalités par

acteur :

Acteur Cas d’utilisation

Administrateur - Vérifier la liste des livraisons

- Affecter une livraison à un livreur
- Visualiser les statistiques à travers un dash-
board

Gérant - Recevoir des notifications par mail concernant

les commandes passées
- Visualiser les statistiques à travers un dash-
board

Livreur - Vérifier la liste des livraisons

Client - Passer une commande

- Suivre une commande

Table 5.2 – Classification des cas d’utilisation par acteur sprint 3

5.2.3 Diagramme de cas d’utilisation

La figure 5.1 illustre le diagramme de cas d’utilisation du troisième sprint :

Sprint 3 : Gestion des commandes et des livraisons 60

Figure 5.1 – Diagramme de cas d’utilisation du sprint 3

5.2.4 Description textuelle des cas d’utilisation

Dans cette section, nous allons élaborer davantage sur les cas d’utilisation du sprint 3
pour fournir une description détaillée des divers scénarios possibles.
— Le cas d’utilisation «Passer une commande»
Le tableau ci-dessous détaille le cas d’utilisation

Cas d’utilisation Passer une commande

Acteurs Client

Pré-condition - Le client doit être authentifié.

- Le panier contient au moins un article.
Sprint 3 : Gestion des commandes et des livraisons 61

Post-condition - La commande est enregistrée avec succès.

- Le panier est vidé.

Scénario principal 1- Le client accède à l’interface de passage de com-

mande.
2- L’utilisateur remplit un formulaire et clique sur
"Confirmer".
3- Le système crée la nouvelle commande et une nou-
velle livraison en attente.

Scénario alternatif - Le client essaie de passer une commande sans avoir

de produits dans son panier. Un message d’erreur est
affiché.

Table 5.3 – Description textuelle du cas d’utilisation «Passer une commande»

— Le cas d’utilisation «Affecter une livraison à un livreur»

Le tableau ci-dessous détaille le cas d’utilisation

Cas d’utilisation Affecter une livraison à un livreur

Acteurs Administrateur

Pré-condition - L’administrateur doit être authentifié.

- Il existe au moins une livraison en attente et un
livreur disponible.

Post-condition - La livraison est affectée à un livreur avec succès.

Sprint 3 : Gestion des commandes et des livraisons 62

Scénario principal 1- L’administrateur accède à l’interface de livraisons

en attente.
2- L’administrateur choisit une livraison, puis il
clique sur un livreur de la liste des livreurs.
3- L’administrateur clique sur "Confirmer".
4- Le système met à jour la livraison en lui affectant
le livreur choisi.

Scénario alternatif - Échec de l’opération. Un message d’erreur est affi-

ché.

Table 5.4 – Description textuelle du cas d’utilisation «Affecter une livraison à

un livreur»

5.3 Conception

Au sein de cette section, nous allons exposer les diagrammes de séquences et le dia-
gramme de classe des fonctionnalités de ce sprint.

5.3.1 Diagramme de séquence «Passer une commande»

La figure 5.2 représente le diagramme de séquence du passage d’une commande.

Sprint 3 : Gestion des commandes et des livraisons 63

Figure 5.2 – Diagramme de séquence «Passer une commande».

5.3.2 Diagramme de séquence «Affecter un livreur à une livrai-

son»

La figure 5.3 représente le diagramme de séquence de l’affectation d’un livreur à une

livraisons.
Sprint 3 : Gestion des commandes et des livraisons 64

Figure 5.3 – Diagramme de séquence «Affecter un livreur à une livraison».

5.4 Réalisation

Cette section est consacrée à la visualisation du travail réalisé dans ce sprint, présenté
sous forme de captures d’écran.

Interface «Mes commandes»

À travers cette interface, chaque client peut accéder à l’historique de ces commandes et
suivre leurs statuts (pending, processing, delivered). Il peut également consulter les dates
des livraisons ainsi que leurs total.
Sprint 3 : Gestion des commandes et des livraisons 65

Figure 5.4 – L’interface «Mes commandes».

Interface «Livraisons en cours»

Cette interface permet à chaque livreur de visualiser la liste des livraisons qui lui sont
assignées. De plus, il a la possibilité de modifier leurs statuts.

Figure 5.5 – L’interface «Livraisons en cours».

Interface «Historique des livraisons»

Cette interface permet à chaque livreur de visualiser l’historique des livraison qu’il a
effectuées. Il peut consulter la date de livraison, le nom du client, ainsi que ses coordonnées
Sprint 3 : Gestion des commandes et des livraisons 66

pour faciliter le processus de livraison.

Figure 5.6 – L’interface «Historique des livraisons».

Interface «Affecter un livreur»

Cette interface permet à l’administrateur d’accéder à la liste des nouvelles livraisons à
effectuer. Il a la possibilité de sélectionner un livreur et de lui attribuer une livraison
spécifique.

Figure 5.7 – L’interface «Affecter un livreur».

Sprint 3 : Gestion des commandes et des livraisons 67

Interface «Dashboard de l’admin»

Cette interface représente un dashboard où l’administrateur du site peut visualiser quelques
statistiques.

Figure 5.8 – L’interface «Dashboard de l’admin».

Interface «Dashboard du gérant»

Cette interface représente un dashboard où chaque gérant peut visualiser quelques statis-
tiques concernant ses produits et ses ventes.

Figure 5.9 – L’interface «Dashboard du gérant».

Sprint 3 : Gestion des commandes et des livraisons 68

5.5 Conclusion

Dans ce chapitre, nous avons abordé l’analyse, la conception et la réalisation du troi-

sième sprint. À ce stade, toutes les fonctionnalités du projet mentionnées précédemment
ont été approuvées. Par conséquent, nous parvenons à la dernière étape de notre applica-
tion, marquant ainsi la finalisation de notre travail.
Conclusion et perspectives

À la fin de ce rapport, nous pouvons conclure que la réalisation de notre projet Mar-
ketplace avec système de gestion de livraisons intégré a été une expérience enrichissante
et formatrice. Grâce à notre stage et à l’application des connaissances théoriques acquises
tout au long de notre parcours d’études en informatique, nous avons pu concevoir et
développer une solution complète.
Ce projet nous a permis de mettre en pratique nos compétences en développement
web, en utilisant des technologies modernes et en adoptant une approche agile de gestion
de projet, notamment en suivant la méthodologie SCRUM.
Cependant, malgré les fonctionnalités déjà implémentées, notre projet reste évolutif
et offre de nombreuses perspectives d’amélioration. Nous envisageons d’intégrer des fonc-
tionnalités supplémentaires, telles qu’un système de suivi en temps réel des livraisons, des
notifications personnalisées pour les utilisateurs, ainsi que des fonctionnalités d’analyse et
de génération de rapports pour l’administrateur.
En conclusion, ce projet nous a permis de consolider nos compétences techniques, de
mettre en pratique nos connaissances et de nous familiariser avec les enjeux du dévelop-
pement d’une application web complète. Nous sommes fiers du résultat obtenu et nous
sommes convaincus que notre Marketplace avec système de gestion de livraisons intégré
sera une solution utile et efficace pour les entreprises cherchant à optimiser leur processus
de livraison.

69
References

[1] Scrum, https://www.scrum.org/ (Visité le 28-02-2023).

[2] uml, https://www.uml.org/ (Visité le 28-02-2023).

[3] MVC, https://developer.mozilla.org/fr/docs/Glossary/MVC (Visité le 28-02-

2023).

[4] PlantUML, https://plantuml.com/fr/ (Visité le 28-02-2023).

[5] LaTeX, https://www.latex-project.org/ (Visité le 28-02-2023).

[6] Overleaf, https://www.overleaf.com/ (Visité le 28-02-2023).

[7] vscode, https://code.visualstudio.com/ (Visité le 28-02-2023).

[8] Git, https://git-scm.com/ (Visité le 28-02-2023).

[9] GitHub, https://github.com/ (Visité le 28-02-2023).

[10] Postman, https://www.postman.com/ (Visité le 28-02-2023).

[11] Trello, https://trello.com/ (Visité le 28-02-2023).

[12] Reactjs, https://reactjs.org/ (Visité le 28-02-2023).

[13] Node.js, https://nodejs.org/en/ (Visité le 28-02-2023).

[14] Express.js, https://expressjs.com/ (Visité le 28-02-2023).

[15] mongoDB, https://www.mongodb.com/ (Visité le 28-02-2023).

70