Rapport Genie Logiciel

Mini-projet génie logiciel
présenté par :
Elyoussoufi Younesse
Mohamed el Mejdoub
Abderahmane Sabri
Oumaima Lahssiki
Achraf Ammari
Hammouche Mohamed Reda
« Étude et implémentation d’un système

marketplace »
Encadré par :
Abderrahmane Daif
Année universitaire : 2023/2024

Remerciements
Au nom de toute l'équipe, je tiens à vous exprimer notre profonde gratitude

pour votre encadrement et votre soutien tout au long de la réalisation du rapport du
mini-projet de génie logiciel.
Votre expertise et vos conseils avisés ont été d'une aide précieuse pour nous
orienter à chaque étape du processus. Votre disponibilité et votre volonté de
partager vos connaissances ont grandement contribué à notre apprentissage et à
notre succès dans ce projet.
Travailler en équipe a été une expérience enrichissante, et nous sommes

conscients que votre guidance a été déterminante pour notre collaboration
harmonieuse et notre accomplissement collectif. Votre capacité à nous motiver et à
nous inspirer a renforcé notre engagement envers le projet et notre désir d'atteindre
l'excellence.
2|Page
Résumé
Dans le cadre de notre projet de fin d'apprentissage, nous espérons construire une plateforme de
marché qui devra présenter nos produits dans une boutique virtuelle à la disposition de tout le
monde, de faire des transactions commerciales, de faciliter la tâche du paiement en ligne et de
suivre la livraison des produits.
Ce projet a suivi les étapes suivantes :
• Déterminer les exigences fonctionnelles et non fonctionnelles du projet.

• Recherche technique et conception détaillée de l'application.
• Réalisation.
3|Page
Abstract
In this project, we accomplished the marketplace web platform,
The goal of this platform is to facilitate the association with the use of users, the main sellers
and customers.
For this project, the following steps were taken as a project approach:
• Identify the functional and non-functional needs of the project.

• Technical study and detailed design of the application.
• Production.
4|Page
Liste des figures
Figure 1: représente le processus du marketplace .................................................................................. 16

Figure 2 : organisation de la Scrum Team autour de 3 rôles ................................................................... 19
Figure 3 : Image corresponde un processus Scrum ................................................................................. 22
Figure 5 : Image corresponds rest API pour multi-platform .................................................................... 33
Figure 6 : architecture technique de rest api avec n’ode js – express ..................................................... 34
Figure 7 : Image SSG vs SSR dans next j ................................................................................................... 35
Figure 8 : Les étape de déploiement d'une application React next js et express .................................... 36
Figure 9: Arborescence de projet front et back ....................................................................................... 40
Figure 10 : Diagramme d’acteur système marketplace ........................................................................... 43
Figure 11 : Diagramme de use case utilisateur ........................................................................................ 44
Figure 12 : Diagramme de séquence utilisateur de systèmes ................................................................. 45
Figure 13 : Diagramme de séquence utilisateur (messagerie)................................................................. 46
Figure 14 : Diagramme de use case (administrateur - modérateur)........................................................ 47
Figure 15 : Diagramme de séquence (administrateur - modérateur)...................................................... 48
Figure 16 : Diagramme de use case vendeur (gestion de boutique) ....................................................... 49
Figure 17 : Diagramme de use case vendeur (Gestion du produit et catégorie et annonce) .................. 51
Figure 18 : Diagramme de séquence création une boutique (Vendeur) ................................................. 52
Figure 19 : Diagramme de gestion de produit et catégorie – gestion des annonces (Vendeur) ............ 53
Figure 20 : image réalisation de plateforme boutique ............................................................................ 54
Figure 21 : Diagramme de gestion des commandes (Vendeur) ............................................................... 56
Figure 22 : Diagramme use case acheteur ............................................................................................... 58
Figure 23 : Diagramme de séquence acheteur ........................................................................................ 59
Figure 24 : Diagramme de classe système Marketplace .......................................................................... 61
Figure 25 : Schéma de base de donnés no SQL........................................................................................ 64
5|Page
Liste des tableaux
Table 1 : Livrables du projet ..................................................................................................................... 17

Table 2: Détermination des risques ......................................................................................................... 18
Table 3 : Phase de Conception générale .................................................................................................. 19
Table 4 : phase de conception détaillée .................................................................................................. 20
Table 5 : phase de phase de codage ....................................................................................................... 20
Table 6 : la Phase Recette ........................................................................................................................ 21
Table 8 : Tableau d'acteurs principaux acteurs et secondaires ............................................................... 28
Table 9 : Tableau Identification des rôles ................................................................................................ 29
Table 10 : les règles de gestion de projet ................................................................................................ 31
Table 11 : Fiche de sprint de l’utilisateur ................................................................................................. 42
Table 12 : Tableau de use case utilisateur ............................................................................................... 44
Table 13 : Tableau de séquence utilisateur ............................................................................................ 45
Table 14 : Tableau de séquence utilisateur (messagerie) ........................................................................ 46
Table 15 : Tableau use case (administrateur - modérateur).................................................................... 47
Table 16 : représente tableau de séquence (administrateur - modérateur) ........................................... 48
Table 17 : Tableau de phase module vendeur ......................................................................................... 49
Table 18 : Tableau use case vendeur ....................................................................................................... 50
Table 19 : Tableau use case Boutique ...................................................................................................... 50
Table 20 : Tableau descriptif des use case (Vendeur) .............................................................................. 51
Table 21 : Tableau de séquence (Vendeur)............................................................................................. 52
Table 22 : Tableau de séquence (Vendeur) ............................................................................................. 53
Table 23 : Tableau de phase module Commande .................................................................................... 56
Table 24 : Tableau de séquence (Vendeur) ............................................................................................. 57
Table 25 : La phase module acheteur ...................................................................................................... 57
Table 26 : Tableau de séquence vendeur ................................................................................................ 59
Table 27 : Dictionnaire de données ......................................................................................................... 66
6|Page
1 Table des matières
Remerciements................................................................................................................................................2
Résumé ............................................................................................................................................................3
Abstract ...........................................................................................................................................................4
Liste des figures ...............................................................................................................................................5
Liste des tableaux ............................................................................................................................................6
C HAPITRE 1 ..............................................................................................................................................12
Contexte générale du projet ........................................................................................................................12
I. Introduction du chapitre ...................................................................................................................... 13
1. Définition ...........................................................................................................................................13
2. Problématique générale ....................................................................................................................13
3. Périmètre du projet .......................................................................................................................... 14
4. Objectif du projet ...............................................................................................................................14
II. Contexte du projet ............................................................................................................................... 15
1. Processus de vente en ligne ...............................................................................................................15
a. Créer votre boutique en ligne ....................................................................................................... 15
b. Référencez votre boutique e-commerce pour être plus visible en ligne ...................................... 15
c. Faites évoluer votre boutique à l'instar de votre stratégie e-commerce ..................................... 16
2. Porté.................................................................................................................................................. 16
3. Mission du projet .............................................................................................................................. 16
4. Contraintes du projet .........................................................................................................................17
5. Livrables du projet ............................................................................................................................ 17
6. Détermination des risques ................................................................................................................ 18
7. Méthodologies de développement................................................................................................... 18
a. Définition de la méthode .............................................................................................................. 18
b. Pourquoi SCRUM ? .........................................................................................................................18
c. Les rôles dans une équipe Scrum .................................................................................................. 19
8. Description des phases ..................................................................................................................... 19
a. Phase de Conception générale ......................................................................................................19
b. Phase de Conception détaillée.......................................................................................................20
c. Phase de Codage ............................................................................................................................20
d. Phase de Test des modules ........................................................................................................... 21
e. phase recette ................................................................................................................................ 21
f. Schéma Scrum ............................................................................................................................... 22
g. Cycle de vie ....................................................................................................................................22
h. Exigences Qualité .......................................................................................................................... 23
9. Planning initial du projet ....................................................................................................................23
7|Page
a. Diagramme de Gantt sous ms-projet ............................................................................................ 23
10. Organisation d’équipe................................................................................................................... 24
b. Equipe core ................................................................................................................................... 24
c. Rôles des acteurs du projet............................................................................................................24
11. Conclusion ......................................................................................................................................25
CHAPITRE 2 ...............................................................................................................................................26
Etudes des besoins ...................................................................................................................................... 26
1. Rappel objectif .................................................................................................................................. 27
2. Les exigences fonctionnelles ............................................................................................................. 27
3. Expression des besoins fonctionnels ................................................................................................ 28
a. Identification des acteurs.............................................................................................................. 28
b. Identification des rôles...................................................................................................................28
c. Les besoins fonctionnels ............................................................................................................... 29
d. Les besoins non fonctionnels ........................................................................................................ 30
4. Les règles de gestion ......................................................................................................................... 31
5. Conclusion ......................................................................................................................................... 31
CHAPITRE 3 ...............................................................................................................................................32
Etude Technique.........................................................................................................................................32
1. Introduction ...................................................................................................................................... 33
2. Etude technique du projet .................................................................................................................33
3. Architecture technique ..................................................................................................................... 33
a. Le model REST API (RESTFUL API) ................................................................................................. 33
b. SSG vs. SSR in Next.js .....................................................................................................................35
c. Architecture déploiement ............................................................................................................. 36
4. Outil et Framework ........................................................................................................................... 37
5. Arborescence du projet .....................................................................................................................39
6. Conclusion ......................................................................................................................................... 40
CHAPITRE 4 .............................................................................................................................................. 41
Release 1........................................................................................................................................................41
I. Description du sprint : Gestion des propriétaires ............................................................................... 42
1. Présentation du module ................................................................................................................... 42
2. Fiche du sprint................................................................................................................................... 42
3. Diagramme d’acteur ..........................................................................................................................43
4. Diagramme use case utilisateur ........................................................................................................ 43
5. Tableau descriptif des use case......................................................................................................... 44
6. Diagramme de séquence utilisateur d’inscription .............................................................................44
7. Tableau de Séquence utilisateur ....................................................................................................... 45
8|Page
8. Diagramme de séquence utilisateur messagerie .............................................................................. 45
9. Tableau de Séquence utilisateur ....................................................................................................... 46
10. Diagramme use case (administrateur - modérateur) .................................................................. 47
11. Tableau descriptif des use case..................................................................................................... 47
12. Diagramme de séquence (administrateur - modérateur)............................................................. 48
13. Tableau de Séquence utilisateur ................................................................................................... 48
II. Description du sprint : Gestion des vendeurs ..................................................................................... 49
2. Fiche du sprint................................................................................................................................... 49
3. Le Diagramme use case vendeur ...................................................................................................... 49
III. Description du sprint : Gestion des Boutique ................................................................................. 50
2. Fiche du sprint................................................................................................................................... 50
3. Gestion du produit et catégorie et annonce ......................................................................................50
5. Diagramme de séquence Boutique ................................................................................................... 52
6. Tableau de Séquence Boutique .........................................................................................................52
7. Tableau de Séquence Boutique .........................................................................................................53
8. Réalisation......................................................................................................................................... 54
CHAPITRE 5 .............................................................................................................................................. 55
Release 2........................................................................................................................................................55
IV. Description du sprint : Gestion Commande .................................................................................... 56
2. Fiche du sprint................................................................................................................................... 56
3. Tableau de Séquence vendeur ...........................................................................................................57
V. Description du sprint : Gestion des Acheteur ......................................................................................57
2. Fiche du sprint................................................................................................................................... 57
3. Diagramme use case ..........................................................................................................................57
5. Diagramme de séquence Acheteur................................................................................................... 59
6. Tableau de Séquence vendeur ...........................................................................................................59
7. Diagramme de classe ........................................................................................................................ 60
8. Conclusion ......................................................................................................................................... 61
Conclusion générale ..................................................................................................................................... 62
Bibliographie et webographie ..................................................................................................................... 63
9|Page
Annexe .......................................................................................................................................................... 64
1. Schéma de base de données ............................................................................................................. 64
2. Dictionnaire de données ....................................................................................................................64
10 | P a g
e
Introduction générale
Marché, bazars, centres commerciaux... plusieurs termes le même objectif : développer une
Marketplace rentable. Comment gérer l'étendue des devis, la disponibilité des produits,
Compétitivité des prix sans stockage ni restrictions logistique et maintenir ses marges
bénéficiaires ? C'est le défi auquel les entreprises de commerce électronique sont confrontées
chaque jour. Parce qu'ils peuvent profiter de marques fortes, public qualifié ou expertise métier
à fournir conjointement vendeurs tiers sur une plateforme unique, le marché est
répondre aux enjeux du e-commerce d'aujourd'hui et de demain.
En connectant directement vendeurs et clients, Marketplace s'intègre parfaitement à l'ADN
internet : créer de la valeur raccourcir la chaîne.
En surmontant bon nombre des limites du commerce électronique d'aujourd'hui, le marché
garantit des revenus A toutes les parties prenantes (opérateurs, vendeurs, acheteur).
Amazon, RueduCommerce, Pixmania, Fnac.com…tous ces grands noms du e-commerce ont

lancé leur Marketplace au cours des dernières années. Pour certains, cette activité dépasse
déjà 40% des produits vendus et constitue près de 100% de leur rentabilité ! Pour d’autres,
Marketplace, verticales créées de toute pièce telles Etsy (artisanat), Farfetch (mode) ou Foodzie
(alimentaire), cette activité représente 100% de leurs ventes qui dépassent parfois le milliard
d’euros.
Tous ces exemples le confirment : la révolution est en marche et rapidement des centaines de
nouvelles Marketplace vont émerger partout dans le monde.
Le présent rapport a pour objectif de donner une idée claire sur le travail effectué pendant la
réalisation du projet marketplace. Il s’articule autour de quatre chapitres :
Chapitre 1 : présente le contexte général du projet.
Décris la problématique, les objectifs ainsi que les résultats attendus
Chapitre 2 : ce chapitre cible expliciter le besoin, au travers de fonctions de services et de
Fonctions de contraintes.
Chapitre 3 : Analyse et de conception du projet. Dans cette partie on décortique les cas
d’utilisation, on présente les processus et toutes les étapes détaillées pour finir avec la
conception logicielle.
Chapitre 4: traite tous les détails de la réalisation : les outils de travail, les différentes étapes de
la réalisation du système.
11 | P a g e
CHAPITRE 1 :
Ce chapitre a pour rôle de montrer les besoins du client, ainsi que les besoins fonctionnels de
la future application, de préciser les livrables et les risques les plus critiques du projet et la
méthodologie de développement et aussi équipe corps de projet.
12 | P a g e
I. Introduction du chapitre :
Dans cette l’introduction, nous allons mettre le sujet dans son cadre général. Par la suite, nous
aborderons l’étude de la manière de vente actuelle, suivie d’une critique pour pouvoir se
concentrer sur les problèmes à résoudre pendant la réalisation de notre projet. Ainsi, nous allons
présenter un ensemble des besoins fonctionnels et autres non fonctionnels et nous définirons les
règles de gestion de l’application et le rôle de chaque acteur.
1. Définition :
Une Marketplace (ou place de marché) électronique est un espace virtuel en ligne sur lequel se
rencontrent acheteurs et vendeurs pour effectuer des transactions de biens et/ou de services.
Les transactions entre acheteurs et vendeurs se déroulent sur la plateforme gérée par
l’opérateur de la Marketplace dont le rôle est de fournir un cadre de confiance, transparent et
sécurisé pour les différentes parties en mettant à disposition des outils et services qui fluidifient
les échanges : système de paiement en ligne, gestion du catalogue et des stocks, informations
authentifiées sur le vendeur et/ou l’acheteur, garanties diverses, etc.
2. Problématique générale :
Les innovations dans le domaine de développement informatique se multiplient et s’évaluent
sans cesse. Ce qui nous pousse toujours à trouver des moyens plus efficaces pour répondre à
plusieurs besoins afin de faciliter notre vie.
La technologie récente est plus en plus dans le domaine de commerce en ligne, de vente de main
à main vers des ventes virtuelles.
• Comment les offres de la marketplace sont- elles visibles et quelles sont les règles de
Fixation de prix de ces offres ?
• Comment faire venir les vendeurs sur votre plateforme en premier semble être le choix le
plus sûr ?
• Quels sont les problèmes que vous rencontrez lorsque vous êtes vendeur sur le marché ?
• Pourquoi vendre sur la marketplace ?
• Comment votre marché va-t-il évoluer ?
• Voulez-vous créer une boutique pour stocker votre produit ?
• Comment conserver les vendeurs et les acheteurs sur votre marketplace ?
• Comment amélioreriez-vous ce produit ?
13 | P a g e
3. Périmètre du projet :
Les marketplace (ou site e-commerce multi vendeurs) sont en passe de devenir les premières
plateformes d'achat pour les consommateurs. Et pour cause, elles proposent des offres
commerciales beaucoup plus vastes que les sites e-commerce traditionnel. Qui plus est, les
potentiels acheteurs peuvent y comparer les prix, les caractéristiques et les éventuels services
additionnels. Vous projetez vous-même de lancer une grosse plateforme de marketplace dans
votre secteur d'activité ? Découvrez d'abord les étapes à suivre pour réussir sa mise en place
d'un tel projet.
• Un modèle tripartite entre vendeur, acheteur et opérateur.

• La commande est passée par l’acheteur sur la marketplace.
• L’acheteur procède plusieurs méthodes de paiement par carte bancaire, virement ou
autres méthodes proposées sur la plateforme.
• Création d’un magasin par les vendeurs de plateformes.
• Stoker leur produit en utilise des services de plateforme.
• L'argent est stocké sur un compte de cantonnement le temps que la commande soit
traitée.
• Le vendeur est payé sur son compte bancaire.
• Optimisation des moteurs de recherche en utilisant SEO.
• N'importe qui peut écrire une annonce exprimant l’importance de ses produits.
• Les outils de communication de gestion du cycle de vente en utilisant des outils de
messagerie telle quelle la messagerie instantanée.
• Des statistiques sur le nombre des visiteurs du site.
4. Objectif du projet :
Nous allons décider de développer une stratégie sur les places de marché elle doit être
consciente que des enjeux organisationnels importants vont impacter tous les métiers de
marketplace.
▪ Le trafic : est le palier le plus important dans une marketplace, car cette dernière est en
relation directe avec le trafic, plus il y a des visiteurs plus les opportunités de transactions
seront nombreuses et la visibilité des annonces des vendeurs augmente.
▪ Le mix produit : pour un mix produit cohérent, l'opérateur doit définir quels sont les
Produits autorisés sur la marketplace.
▪ Le cadre légal : les marketplaces n’imposent pas le même niveau d’exigence au niveau
juridique. Pour certains marketplace les contrats sont bien contrôlés pour les échanges
des annonces sensibles. Et pour d’autres cette exigence est moindre, l’identification des
Intervenants n’est pas trop poussée.
▪ Les outils de communication et de la gestion de cycle de vente : Les outils de
communication entre les acheteurs et les vendeurs sont le facteur le plus important de la
réussite de concrétisation d’une vente et de l’après-vente, sa peut être des messageries,
Chat, Skype et beaucoup d’autres outils.
14 | P a g e
▪ Le paiement : cette partie est très sensible, elle doit être bien contrôlée. Pour avoir la
confiance du client, il faut leur assurer que les opérateurs enregistrent la transaction dans
un environnement sécurisé, et que leurs données sont bien protégées.
- Voici ce que vous allez trouver les éléments principaux :

▪ Au niveau des achats : Intégrer une marketplace amène l’opérateur à modifier sa
stratégie d’achat de produits. Grâce à une marketplace, un site propose plus de produits
et plus de prix.
▪ Au niveau de l’animation commerciale : La direction commerciale doit aussi s’adapter à
Ce changement avec la multiplication des produits il est nécessaire pour l’opérateur
defaire les bons arbitrages sur les produits qu’il va mettre en avant.
▪ Au niveau de la stratégie marketing : La mise en place d'une stratégie marketplace
Modifie aussi la stratégie marketing L’opérateur se retrouve par exemple à devoir gérer
ses campagnes de mots clefs.
▪ D’un point de vue administratif et financier : Une marketplace nécessite la mise en place
D’un système de comptabilité et de flux financiers qui intègrent les vendeurs tiers. Il faut
pouvoir synchroniser efficacement d’une part les indicateurs qui viennent de la
plateforme en termes de ventes et de facturation, et d’autre part, les virements à créditer
aux vendeurs qui ont souvent des enjeux de trésorerie et qui sont donc très regardants
sur la manière dont la marketplace gère les flux financiers.
▪ Au niveau du service client et du call center : Pour le service client, l’enjeu réside dans le
Fait qu’une partie des visiteurs qui vient sur la marketplace vient aussi pour sa
marque,pour ses valeurs et pour ce qu’elle véhicule.
II. Contexte du projet :

1. Processus de vente en ligne :
a. Créer votre boutique en ligne :

Créer un site e-commerce est la seule façon de créer une plateforme de vente en ligne qui
correspond à votre cible. Chaque marque a des clients qui lui sont propres. La création d’une
boutique en ligne où tu peux permet de développer son store.
b.Référencez votre boutique e-commerce pour être plus visible en ligne :

De plus en plus d’acteurs vendent sur internet. Vous êtes rarement seul sur votre marché
en ligne. Il est donc nécessaire de vous rendre plus visible que vos concurrents. Nous
ferons le saut pour le référencement e-commerce où sont devenues essentielles pour
développer vos ventes en ligne.
15 | P a g e
c. Faites évoluer votre boutique à l'instar de votre stratégie e-commerce :
Une stratégie e-commerce démarre par la création d’un site. Le référencement permet de
se rendre plus visible que les concurrents, mais faut-il encore se rendre plus intéressant et
plus compétitif… C’est l’innovation dans le domaine du e-commerce qui permet de se
démarquer.
Figure 1: Représente le processus du marketplace
2. Porté :
Intéressons-nous aux enjeux techniques liés à la création d'une marketplace. Tout d'abord,
il faut comprendre comment fonctionne une marketplace. Une marketplace est le résultat
des interactions entre trois couches principales :
o Un front office, pour que les acheteurs naviguent et achètent les produits disponibles.
o Un middle office pour que les vendeurs importent et mettent à jour leur catalogue de
produits. Le middle office contient également plusieurs fonctionnalités liées aux
transactions (édition de bons de commande, tableau de bord des ventes).
o Un back-office permettant à l'opérateur de monitor les activités transactionnelles ou non
de la marketplace, de la validation des inscriptions à l'envoi automatique de newsletters
aux membres.
3. Mission du projet :
Les étapes des missions couvrent toutes les types de prestations suivantes :
16 | P a g e
• Étude préalable
• Analyse fonctionnelle
• Conception générale
• Réalisation des modules
• Intégration
• Tests
• Déploiement
4. Contraintes du projet :
Les contraintes demandées par le client :
• Charte graphique
• Cahier des charges
• Dictionnaire de données
5. Livrables du projet :
Dans la plupart des projets, il existe de multiples livrables constituant le produit final donné
pour le client, mais aussi des livrables internes au projet à commencer par la Charte du
projet puis par le Cahier des Charges
Phase Livrable Date de livraison Date validation

Étude des besoins Cahier de charge & 28/04/2024 01/05/2024
PQP
Analyse et Dossier de spécification 01/05/2024 15/05/2024
conception fonctionnelle et technique
Sprint 1 Exécutable du module gestion de 16/05/2024 30/06/2024
propriétaire
Sprint 2 Exécutable du module gestion du 01/07/2024 15/07/2024
vendeur
Sprint 3 Exécutable du module gestion de 16/07/2024 30/07/2024
l’acheteur
Sprint 4 Exécutable de la gestion des 01/08/2024 15/08/2024
catégories
produits
Commandes
paiements
Documentation Rapport du projet 01/10/2024 15/10/2024
Table 1 : Livrables du projet

17 | P a g e
6. Détermination des risques :
Les risques principaux que vous avez identifiés dans le projet :
Risque Le type Impact Probabilité Action corrective

Cahier des Risque non Créer une Moyen Prévoir des réunions et des
charges bloquant ambigüité ce qui points de validation avec
incomplet pourrait l’encadrant au fur et à
générer un retard mesure de l’avancement du
qui influencera projet.
probablement la
date de livraison
Absence Risque Ralentissement Faible Doubler l’effort et travailler
ou maladie bloquant des travaux un temps extra.
gestion du Risque non Le projet ne sera Moyen Doubler l’effort et ajuster le

temps est bloquant pas achevé dans la planning pour respecter la
mal faite date prévue planification faite
au départ.
Table 2: Détermination des risques
7. Méthodologies de développement :
a. Définition de la méthode :
La méthode de gestion de projet appliquée pour le processus est la méthode agile Scrum.
Cette méthode privilégie les objectifs à court terme et donne lieu à des interactions
régulières avec les membres de l’équipe afin de discuter de l’avancement sur le projet.
Scrum est une méthodologie ou cadre de gestion de projet. Elle est construite autour d’une
équipe Scrum, d’artéfacts et de cérémonies. C’est un cadre méthodologie incrémentale,
organisée en sprint pendant lesquels l’équipe Scrum va produire un incrément
potentiellement livrable du produit. Le but est de livrer un incrément qui a une valeur
ajoutée pour le produit final.
Après une phase de formations aux différentes librairies, j’ai pu participer de manière active
au développement de la plateforme.
Mots-Clés : Agilité, scrum, pratiques agiles, gestion de projet
Un principe fort en SCRUM est la participation active du client pour définir les priorités dans les
fonctionnalités du produit, et pour choisir celles qui seront réalisées dans chaque sprint.
b. Pourquoi SCRUM ?
Nous avons opté pour cette méthode, car la mise en œuvre de notre projet nécessite une
vision globale de la solution à mettre en place, que ce soit au niveau technique, architectural
ou fonctionnel. L’aspect itératif et incrémental de notre projet constitue une autre raison qui
est aussi importante que la première sachant qu’il s’agit de prévoir des itérations dont le
18 | P a g e
Résultat serait validé. Ces itérations doivent être efficaces avec une durée minimisée et
unequalité maximum des livrables.
Le principe itératif de Scrum assure un contrôle constant du produit. Aussi bien les
corrections des erreurs que les améliorations sont intégrées au Backlog Produit. L’équipe de
développeurs présente d’autre part un incrément fini dans le cadre de la revue de Sprint. Le
Product Owner et les Stakeholders ont ainsi la possibilité de s’assurer de la qualité. En cas
d’erreur lors du développement, cela permet de réagir nettement plus rapidement par
rapport à une méthode où l’erreur serait uniquement constatée en fin de projet.
c. Les rôles dans une équipe Scrum :

• Le produit owner (PO) : c’est le garant du produit, il a la vision de ce qu’est le produit
et ce qui doit être fait en priorité pour maximiser la valeur.
• Le scrum master : il veille au respect de la méthodologie scrum et veille à ce que
rien n’entrave l’équipe pendant le sprint.
Figure 2 : organisation de la Scrum Team autour de 3 rôles
8. Description des phases :
a. Phase de Conception générale :

Phase de Conception générale
Objectifs - Une première étape dans le processus de conception d'un système, à
partir des spécifications des besoins, permet de se focaliser sur la
définition de l'architecture de la plateforme.
Contrainte - Respect de la charte graphique existante
- Prise en compte du rapport d’étude de l’existant et axes
d’amélioration
prérequis - Étude des besoins
- Étude d'existant
- Mise à disposition du rapport
Étape de la phase - Se référer au planning « Diagramme de Gantt »
Livrables en sortie - Cahier des charges
- Plan qualité projet
- Dossier de spécifications fonctionnelles
Dépendance - N/A
Critères de fin de phase :
• Compréhension fonctionnelle et technique de l’application par l’équipe de
développement
Table 3 : Phase de Conception générale
19 | P a g e
b. Phase de Conception détaillée
Phase de Conception détaillée
Objectifs - Une deuxième étape dans le processus de conception du logiciel
permet, à partir du résultat de la conception générale de poursuivre le
découpage du logiciel jusqu'à arriver à une description externe de
chacune des procédures et des structures de données.
Contrainte - Respect de la charte graphique existante
- Prise en compte du rapport d’étude de l’existant et axes d’amélioration
prérequis - Dossier de spécification fonctionnelle
Étape de la phase - Voir planning
Livrables en sortie - Spécification fonctionnelle
- Spécification technique
Dépendance - N/A
• Compréhension fonctionnelle et technique de l’application par l’équipe de
développement
Table 4 : phase de conception détaillée
c. Phase de Codage
Phase de Codage
Objectifs - Les procédures identifiées lors de cette phase sont codées les modules
de chaque entité.
Contrainte - Respect du référentiel d’exigence
- Respect les normes de chaque module
- Coder les modules en respectant leur interface.
prérequis - l'utilisation d'un langage modulaire avec un Framework
Étape de la phase - cf. planning
Livrables en sortie - Code Source
Dépendance - Appropriation fonctionnelle de l’équipe de développement

• Les critères de sortie sont les suivantes :
▪ Aucune anomalie bloquante
Table 5 : phase de phase de codage
20 | P a g e
d. Phase de Test des modules
Phase test des modules
Objectifs - Chaque module est testé individuellement. On vérifie que les services
spécifiés par l'interface d'un module sont effectivement rendus par le
module.
Contrainte - -----------------
prérequis - Installé un package de tests
Étape de la phase - cf. planning
Livrables en sortie - Résultats des tests de modules
Dépendance - Appropriation fonctionnelle de l’équipe de développement
• Les critères de sortie sont les suivantes :
▪ Aucune anomalie bloquante
Tableau 1 : Représente phase test des modules
e. phase recette
Phase Recette
Objectifs - Le logiciel lui-même est intégré dans l'environnement extérieur (autres
logiciels, utilisateurs). On vérifie que le logiciel développé répond aux
besoins exprimés dans la phase de spécifications des besoins.
Contrainte - Respect des procédures de livraison du client si définies
Prérequis - Procédure d’installation et de configuration de l’application validée
- Package d’installation de l’application validée
Livrables en sortie - Résultats de la recette
- Déploiement de l’application
Étape de la phase - Assistance à l’installation de l’application
- Installer un environnement de déploiement
- Bilan de projet
Dépendance - Dépendance avec la phase Intégration & recette, cette phase ne peut
débuter seulement si les critères de sortie de la phase de recette sont
validés.
• Fin de la période de garantie de l’application (1 Mois)
Table 6 : la Phase Recette
21 | P a g e
f. Schéma Scrum:
Figure 3 : Image corresponde un processus Scrum
Le Backlog du produit définit les modules du projet tout entier qui est ensuite divisé en
plusieurs sous-modules constituant le Backlog du sprint. Les principales caractéristiques de
cette méthodologie sont :
✓ Les projets SCRUM progressent par une série de sprints.

✓ La durée d’un sprint est de 2 à 4 semaines.
✓ Une durée constante apporte un meilleur rythme.
✓ Le produit (partiel) est conçu, codé et testé pendant le sprint
g. Cycle de vie :
Le développement d'une plateforme se fait suivant un cycle appeler le cycle de vie du logiciel
plateforme. Le cycle de vie est décomposé en phases de développement :
- Spécifications des besoins

- Conception générale,
- Conception détaillée,
- Codage,
- Tests des modules,
- Intégration du logiciel,
- Recette.
Ces phases sont échelonnées dans le temps. Une phase se termine par la remise d'un (ou
plusieurs) document(s) validé conjointement par l'utilisateur et le développeur. Une phase
de développement se termine lorsque la revue de cette phase est faite. Une phase ne peut
commencer que lorsque la précédente est terminée. À la fin de chaque phase, l'utilisateur et
22 | P a g e
le développeur sont d'accord. La décomposition en phase de développement permet donc le
suivi du projet par l'utilisateur.
h. Exigences Qualité :
➢ Les exigences qualité pour le présent projet

➢ Aptitude de performance de l'application se précise dans la rapidité, la fiabilité et
la sécurité ainsi que la maintenabilité
➢ Aptitude de l'application a respecté le délai de chaque sprint
23 | P a g e
9. Organisation d’équipe :
a. Rôles des acteurs du projet
❖ Développeur :
▪ Réalisation de la spécification détaillée.
▪ Codage de l’application.
▪ Effectuation des tests unitaires.
❖ Scrum Master :
▪ Élaboration du dossier de gestion de projet.
▪ Valide le dossier des spécifications fonctionnelles.
▪ Valide le codage.
▪ Présentation des Backlog du sprint du projet.
▪ Valide les livrables.
▪ Contrôle le respect des demandes.
❖ Product Owner
▪ Encadrer la progression d’un projet (mise à jour, planification, supervision)
▪ Superviser les étapes de développement
▪ Adopter une démarche d’amélioration continue du produit
▪ Gérer le Backlog produit
24 | P a g e
10.Conclusion :
Dans ce chapitre, nous avons présenté le cadre général du projet et le processus de
développement du projet. Nous n'avons pas spécifié les méthodes et les exigences. Dans ce
chapitre, nous nous concentrerons sur les besoins du projet.
25 | P a g e
CHAPITRE 2 :
On va entamer dans ce chapitre la partie réalisation et implémentation dans laquelle on

s’assure que le système est prêt pour être exploité par les utilisateurs finaux
26 | P a g e
1. Rappel objectif :
Aujourd’hui, le marché du marketplace est en plein développement grâce aux différentes
plateformes qui permettent de créer facilement et rapidement sa propre boutique en ligne.
L’objectif principal des créateurs de sites marketplace est de parvenir à se démarquer et d’attirer
toujours plus de clients.
Les étapes sont nombreuses depuis l’élaboration du projet jusqu’à la réalisation, il y a tout un
processus à mettre en place
▪ chaque étape de ce processus devra être réalisée avec finesse et précision pour créer
une plateforme qui permet aux clients d'installer leur boutique performante et
professionnelle et de placer leurs produits …
▪ Cela permettra aux créateurs du marketplace de débuter leur activité dans les
meilleures conditions.
2. Les exigences fonctionnelles :

Dans cette section du chapitre, nous nous intéressons aux besoins des utilisateurs traités dans
notre projet de fin d’études.
Gestion du vendeur : Une fois un vendeur inscrit, il est nécessaire de l’accompagner dans la
création de sa boutique. Vous aurez certainement choisi un design particulier pour les produits,
et vous souhaiterez sans doute que le vendeur respecte certains paramètres pour la diffusion de
ses produits.
Gestion de l’acheteur : Le processus d'inscription va donc être différent pour les vendeurs et les
acheteurs. L’acheteur n’aura qu’à entrer ses informations personnelles, puis il aura accès à votre
catalogue et vous avez obtenu votre produit que vous voulez.
Gestion de propriétaire : Les propriétaires de site se sont des gestionnaires de plateforme et les
rôles de régulateur qui permet de sécuriser le cadre dans lequel s’effectuent les transactions, il
met à disposition un système de paiement sécurisé, gère le catalogue de produits, la sécurité et
l’authentification des informations sur les vendeurs/acheteurs.
Gestion catégorie : Si les catégories de vendeurs sont activées de site, les vendeurs pourront
gérer leur propre structure de catégories en accédant à la page de gestion des catégories via le
sélecteur de produits. Les vendeurs peuvent créer de nouvelles catégories et gérer
l'arborescence des catégories existante, une fois la structure de catégories créée, les vendeurs
pourront répertorier les produits dans les nouvelles catégories.
Gestion des commandes : lors qu’un acheteur valide une commande sur la Marketplace, celle-ci
vérifie les informations de paiement, et que ce dernier soit notifié ainsi que les vendeurs (en cas
de multi panier), qu’une commande est en attente d’acceptation.
Gestion produite : le produit proposer à un descriptif mettant en avant les qualités et les
spécificités de biens commercialisés sur une marketplace.
27 | P a g e
Gestion paiement : Dans le cas d’une marketplace, la solution de paiement est spécifique au
modèle et constitue l’intermédiaire entre la place de marché et ses utilisateurs (vendeurs et
acheteurs). S’appuyant sur le principe d’encaissement pour le compte de tiers, Stripe gère les
transactions et l’encaissement des fonds pour le marchand Il assure à la fois la protection des
vendeurs et des acheteurs. En effet, les fonds sont séquestrés, dans un premier temps, jusqu’à
ce que la prestation ait été réalisée. Ils sont ensuite redistribués aux marchands.
3. Expression des besoins fonctionnels
a. Identification des acteurs :

Dans un marketplace on distingue trois acteurs principaux acteurs et d’autres secondaires,
qui ont des rôles spécifiques et complémentaires afin de concrétiser une vente.
ACTEUR DESCRIPTION
Propriétaires Sont des acteurs qui gèrent la plateforme et garantissent une confiance aux
utilisateurs. Ils mettent les vendeurs et les acheteurs en relation, et garantissent
la fluidité des échanges afin d’offrir une meilleure transaction.
Vendeur Sont des personnes présentent dans Marketplace pour vendre leurs produits et
leurs services, ils peuvent être des vendeurs professionnels ou non
professionnels.
Leurs intérêts sont d’accueillir de nouveaux clients en présentant leurs produits
en meilleurs prix avec le bon service.
Peuvent être des particuliers ou des entreprises qui prennent en charge
Acheteur la politique d’achat en consultant une vaste sélection de produits proposés par
une diversité de vendeurs.
Sont des acteurs qui construisent Marketplace et proposent des solutions
Éditeurs de techniques. Pour ajouter des fonctionnalités techniques, il existe
solution des plug-ins.
Leurs solutions assurent d’exporter les catalogues des marchands sur des
Différends marketplace. Ils se chargent aussi d’adapter les informations.
Intégrateurs de De chaque produit (annonces, prix, quantité, disponibilité...) sur chaque
flux Support e-commerce.
Logisticiens Sont responsables d’un bon acheminement des commandes afin de satisfaire le
client.
Table 8 : Tableau d'acteurs principaux acteurs et secondaires
b. Identification des rôles :

Les rôles de marché et de partenaire ont accès à différentes ressources. En règle générale,
un vendeur utilise des rôles de partenaire tandis qu'un acheteur utilise des rôles de marché.
Parfois, les comptes contiennent à la fois des rôles de marché et de partenaire.
28 | P a g e
Rôles Module
Acheteur Consultation des catégories

Consultation des produits
Chercher annonces.
Acheter produit.
Administrateur Gérer les comptes des utilisateurs.
Gérer la fonctionnalité de système.
Gérer des produits et catégories.
Consultation des membres de plateforme.
Refuser annonces.
Analyser donnée.
Vendeur Gérer le stock de produit.
Consultation les membres de plateforme.
Affecter les catégories.
Ajouter annonces.
Supprimer annonces
Modifier les informations.
Suivre contrat (renouveler contrat).
Table 9 : Tableau Identification des rôles
c. Les besoins fonctionnels :

Les besoins fonctionnels se présentent en partie :
Gestion de propriétaire :
▪ Gestion du compte utilisateur.
▪ Gérer des propriétaires.
▪ Ajouter les informations des propriétaires
▪ Modifier les informations des propriétaires
▪ Supprimer les informations des propriétaires
▪ Recherche une propriétaire
▪ Authentification / inscription par email ou sur les réseaux sociaux
▪ Autorisation pour chaque rôle.
Gestion du vendeur :
▪ L’inscription
▪ Création des boutiques avec le potentiel des sites de marketplace
▪ consulté le client et l’administration par un chat.
▪ Gérer des annonces
▪ Consultation de la liste des commandes
▪ Gérer des produits
Gestion de l’acheteur :
▪ Choisir le produit.
▪ Rechercher le produit
▪ Ajouter le produit au panier
▪ Supprimer le produit au panier
▪ Payer le produit en utilisant le choix (carte de crédit et PayPal).
▪ Consulter le vendeur de produit
29 | P a g e
Gestion Boutique :
▪ Gérer la catégorie.
▪ Catégorie page.
▪ Chercher une catégorie.
▪ Gérer le produit
▪ Ajouter les informations sur les produits
▪ Mettre à jour les informations sur les produits
▪ Supprimer les informations sur les produits
▪ Pages produits
▪ Filtrage des produits par catégorie, prix
▪ Chercher un produit.
▪ Créer annonces
▪ Supprimer annonces
Gestion des commandes :
▪ Confirmation de la commande.
▪ Consultation de la liste des commandes
▪ Ajouter la commande.
▪ Supprimer la commande
▪ Recherche une commande.
▪ Confirmation de l’opération d’achat et la réception de la facture.
Gestion des paiements:
▪ Passerelle de paiement
▪ Panier d'achats en ligne
▪ Choix du mode de livraison
d. Les besoins non fonctionnels :

Les besoins non fonctionnels sont importants, car ils agissent de façon indirecte sur le résultat et
sur le rendement de l’utilisateur, ce qui fait qu’ils ne doivent pas être négligés, pour cela il faut
répondre aux exigences suivantes :
Fiabilité: L’application doit fonctionner de façon cohérente sans erreurs et doit être satisfaisante.
Les erreurs : Les ambigüités doivent être signalées par des messages d'erreurs bien organisés
pour bien guider l’utilisateur et le familiariser avec notre site web.
Ergonomie et bonne Interface : L’application doit être adaptée à l’utilisateur sans qu’il ne
fournisse aucun effort (utilisation claire et facile) de point de vue navigation entre les différentes
pages, couleurs et mises en textes utilisés.
Sécurité : Notre solution doit respecter surtout la confidentialité des données personnelles des
acheteurs ou des vendeurs qui reste l’une des contraintes les plus importantes dans les sites web
marketplace.
30 | P a g e
Aptitude à la maintenance et la réutilisation : Le système doit être conforme à une architecture
standard et claire permettant sa maintenance et sa réutilisation.
Compatibilité et portabilité : Un site web quel que soit son domaine, son éditeur et son langage
de programmation ne peut être fiable qu’avec une compatibilité avec tous les navigateurs web et
tous les moyens que ce soit PC ou Mobiles, et optimisation du moteur de recherche seo en
utilisant Framework de Reactjs qui s'appelle Next js
4. Les règles de gestion :

Le tableau qui suit présente la liste globale des règles de gestion des différents modules :
Règle Description
RG1 L’administrateur qui a le droit de supprimer des vendeurs et gérer tout ce qui
concerne le site marketplace
RG2 Chaque utilisateur doit posséder un rôle.
RG3 Le visiteur peut visualiser les produits sans avoir être authentifié.
RG4 Acheteur doit être authentifié pour diriger la facture des produits
RG5 Acheteur doit être authentifié pour diriger la facture des produits
RG6 Le vendeur doit créer un compte pour remplir les informations de profile
RG7 Les acheteurs ayant les droits d’ajout au panier et de suivi des commandes déjà réalisées.
RG8 Seuls les administrateurs peuvent désactiver un compte vendeur
Table 10 : les règles de gestion de projet
5. Conclusion
Dans ce chapitre nous avons étudié les besoins fonctionnels du projet, à travers cette étude,
nous avons soulevé la problématique détectée ainsi que les objectifs définis. Le chapitre
sera dédié pour la présentation de l’étude technique du projet.
31 | P a g e
CHAPITRE 3 :
Étude technique
Après avoir fixé les besoins et les objectifs dans le chapitre précédent, nous nous focalisons
Sur l’aspect architectural de l’application. Cette phase a pour but de concevoir les schémas
Généraux qui permettent la modélisation et la description d’une manière non ambiguë du
fonctionnement désiré de l’application. Dans ce chapitre deux vues conceptuelles seront
décrites.
32 | P a g e
1. Introduction :
Les spécifications techniques détaillées présentent tous les aspects techniques utiles au projet,
comme les contraintes matérielles, logicielles et humaines.
Elles ont pour but de décrire précisément :
• Les environnements matériel et logiciel.

• La mise en œuvre de l’application
• Les exigences de programmation
• Le déploiement de l’application
• Les éléments de sécurité mis en place
• Les jeux de tests effectués
2. Étude technique du projet :

Concernant la recherche technique du projet, selon le cahier des charges, notre plateforme de
marché sera développée par Framework Express basé sur n’ode js, et nous l'utiliserons en
parallèle Système de gestion de base de données Mongodb, la partie front sera développée par
Framework Next js basée sur React js.
3. Architecture technique
a. Le modèle REST API (RESTFUL API) :

L'API RESTful est un style architectural d'interface de programmation d'application (API) qui
utilise des requêtes HTTP pour accéder aux données et les utiliser. Ces données peuvent être
utilisées pour les types de données GET, PUT, POST et DELETE. Ces types de données font
référence aux opérations de lecture, de mise à jour, de création et de suppression liées aux
ressources.
Un système reposant se compose d'un :
 Le client qui a demandé la ressource.
 Serveur qui a les ressources.
Figure 5 : Image corresponds rest API pour multi-platform
33 | P a g e
Figure 6 : architecture technique de reste api avec node js – express
Couches ou composants de l'API REST Node.js :

En règle générale, le service RESTful accomplira la tâche de servir la demande dans
l'approche en couches. Dans le monde Node.js, différents composants sont disponibles pour
implémenter la fonctionnalité API. Il s'agit de la route, du middleware, du service et du
modèle.
1. Controller :
Habituellement, un contrôleur traitera la demande, invoquera les services pour effectuer
cette action et traitera la réponse pour renvoyer au demandeur.
2. Middleware :
Le middleware dans un monde NodeJS est une fonction qui a accès à l'objet de demande, à
l'objet de réponse et à la fonction suivante. Ici, la fonction next () est utilisée pour invoquer
le middleware suivant dans la pile.
3. Service
Un service est une fonction qui peut effectuer n'importe quelle tâche, comme calculer une
formule, accéder à la base de données pour lire ou écrire. Ici, nous utiliserons une fonction
de service pour accéder à la base de données afin de récupérer et de stocker les
informations client.
4. Model
Ce composant est la couche d'accès aux données pour récupérer et enregistrer les
documents. La couche de service invoquera les modèles pour effectuer des actions sur le
document dans la base de données via le modèle.
Un modèle représente le document qui peut être créé, mis à jour, supprimé et extrait de la
base de données.
34 | P a g e
b. SSG vs. SSR in Next.js:
Next.js est un Frameworks React les plus importants et les plus utilisés. Aujourd'hui, il est
devenu un cadre consolidé pour la création d'applications Web étonnantes.
Figure 7 : Image SSG vs SSR dans next j
▪ SSR (server-side rendering) :

Les frameworks JavaScript modernes ont rendu notre vie de développeurs beaucoup plus facile.
Nous pouvons créer des applications Web puissantes et riches en utilisant de nombreuses
techniques de rendu différentes
Le rendu côté serveur (SSR) est l'exact opposé de cela. SSR décrit le processus de pré rendu de la
page sur le serveur, qui est ensuite généré à chaque demande de l'utilisateur.
Lorsque la page prétendue atteint le navigateur, le code JavaScript est exécuté pour rendre la
page interactive. L'ensemble de ce processus accélère la vitesse de chargement. Cela rend
également plus facile et préférable l'utilisation du rendu côté serveur pour les applications qui
dépendent du référencement (seo).
Next.js fait ce travail hors de la boîte. Par défaut, il essaiera de détecter la technique de pré-
rendu utilisée par votre application et récupérera vos données
▪ SSG (static site generation) :

Les sites Web générés de manière statique ne sont pas nouveaux pour les développeurs. Nous
les construisons depuis le début du web. Construire des expériences Web riches peut être
difficile, mais avec Next.js, nous pouvons le faire facilement.
35 | P a g e
SSG décrit le processus de création de sites Web qui s'affichent au moment de la création. La
sortie est un fichier HTML, des actifs tels que JavaScript et CSS, et quelques autres fichiers
statiques.
Lorsque vous utilisez SSG avec Next.js, la page est prérendue au moment de la compilation. Cela
signifie que l'utilisateur n'aura pas à attendre que la page se charge dans le navigateur, la page
sera simplement rendue
c. architecture déploiement:
Nous devons déployer un monorepo dans Vercel qui contient une application frontend (React)
et une API backend (Express). Nous voulons également les avantages suivants :
• Cela doit être fait en utilisant le plan gratuit.
• Nous voulons servir l'API lorsque l'URL correspond à /API ; sinon, servez l'application
React et ses actifs statiques
• Les deux projets doivent être déployés sur git push
Figure 8 : Les étapes de déploiement d'une application React next js et express
36 | P a g e
4. Outil et Framework :
Visual Studio
Visual Studio Code est éditeur de texte open source, gratuit et multiplateforme (Windows,
Mac et Linux), développé par Microsoft. Principalement conçu pour le développement d'application
avec JavaScript, Type script et Node.js, l'éditeur peut s'adapter à d'autres types de langages grâce à
un Système d'extension bien fourni.
Microsoft Project
Microsoft Project est un logiciel de gestion de projet développe et vendu par Microsoft. Il
est conçu pour aider un chef de projet à élaborer un calendrier, à affecter des ressources aux
taches, à suivre les progrès, à gérer le budget et à analyser les charges de travail.
Enterprise Architect
Enterprise Architect est un outil de modélisation et de conception visuelle basée sur UML.
La plateforme prend en charge: la conception et la construction de systèmes logiciels processus
d’affaires de modélisation; et de l’industrie de la modélisation des domaines en fonction. Il est
utilisé pour traiter la mise en œuvre de ces modèles sur toute la vie du cycle de développement
d’applications.
Mongodb
MongoDB est un programme de base de données multiplateforme orienté

document et disponible en source. Classé comme un programme de base de données NoSQL,
Mongodb utilise des documents de type JSON avec des schémas facultatifs. MongoDB est
développé par Mongodb inc. et sous licence Server Side Public License (SSPL).
37 | P a g e
Mongodb Atlas
MongoDB Atlas est une base de données cloud entièrement gérée développée par les
mêmes personnes qui construisent Mongodb. Atlas gère toute la complexité du déploiement, de la
gestion et de la réparation de vos déploiements sur le fournisseur de services cloud de votre choix
(AWS, Azure et GCP).
Node js
Node.js est un environnement d'exécution JavaScript back-end open source,

multiplateforme qui s'exécute sur le moteur V8 et exécute le code JavaScript en dehors d'un
navigateur Web.
Express.js, ou simplement Express, est un framework d'application Web back-end pour

Node.js, publié en tant que logiciel gratuit et open source sous la licence MIT. Il est conçu pour créer
des applications Web et des API. Il a été appelé le framework de serveur standard de facto pour
Node.js.
React est une bibliothèque JavaScript frontale open source permettant de créer des
interfaces utilisateur ou des composants d’interface utilisateur. Il est maintenu par Facebook et une
communauté de développeurs individuels et d’entreprises. React peut être utilisé comme base dans
le développement d’applications monopages ou mobiles.
Next.js is an open-source Reacts front-end development web framework created by

Vercel that enables functionality such as server-side rendering and generating static websites for
React based web application
Tailwind est un framework CSS "utile d'abord" qui fournit un catalogue complet de
classes et d'outils CSS qui vous permet de commencer facilement à styliser votre site Web ou votre
application.
38 | P a g e
Stripe Payments est une plateforme de traitement des paiements. Il vous permet de
transférer de l’argent du compte bancaire d’un client vers le compte de votre entreprise au moyen
d’une transaction par carte de crédit ou de débit. Continuez votre lecture pour un aperçu complet
du fonctionnement de Stripe dans un environnement de vente au détail en ligne.
Socket.IO est une bibliothèque JavaScript pour les applications Web en temps réel. Il
permet une communication bidirectionnelle en temps réel entre les clients Web et les serveurs. Il se
comporte en deux parties : une bibliothèque cotée client qui s’exécute dans le navigateur et une
bibliothèque côté serveur pour node.js. Les deux composants ont une API presque identique.
Redux est une bibliothèque JavaScript open source pour la gestion de l'état de
l'application. Il est le plus souvent utilisé avec des bibliothèques telles que React ou Angular pour
créer des interfaces utilisateur. Semblable à l'architecture Flux de Facebook, il a été créé par Dan
Abramov et Andrew Clark.
JSON Web Token est une norme Internet proposée pour la création de données
avec une signature facultative et/ou un cryptage facultatif dont la charge utile contient JSON qui
revendique un certain nombre de revendications. Les jetons sont signés à l'aide d'un secret privé ou
d'une clé publique/privée.
5. Arborescence du projet :
La figure ci-dessous illustre l’arborescence de notre projet au niveau de l’outil de
développement Spring Tool Suite :
39 | P a g e
Figure 9: Arborescence de projet front et bacs
6. Conclusion :
À travers ce chapitre, nous avons présenté quelques outils de programmation, l'architecture
technique et déploiement du projet qui permet d'implémenter notre solution
40 | P a g e
CHAPITRE 4
Release 1
Dans cette partie, on va analyser et modéliser les besoins du client avec le langage UML.
L’activité d’analyse et de conception permet de traduire les besoins fonctionnels et les

contraintes issues du cahier des charges et de la spécification des exigences dans un langage
plus professionnel et compréhensible par tous les individus intervenants dans la réalisation et
l’utilisation de l’application.
41 | P a g e
I. Description du sprint : Gestion des propriétaires
1. Présentation du module :
Sur ce module, nous reverrons un ensemble d’information liée aux propriétaires de ce
système, et chaque acteur à des lois et comment utilisé ce système.
2. Fiche du sprint
Ce tableau ci-dessous est une fiche de sprint des propriétaires.
Phase module propriétaire
Objectifs - Diagramme d’acteur de l’utilisateur de plateforme

- Construire un diagramme use case utilisateur
- Construire un diagramme de séquence utilisateur de systèmes
- Construire un diagramme de séquence utilisateur de systèmes
messagerie
- Construire un diagramme de use case (administrateur - modérateur)
Contrainte - Respecte le délai.
Prérequis - l’installation et configuration d’un outille de diagramme
Livrables en sortie - Code source et l’exécutable de la gestion des propriétaires.

Dépendance - Afin d’affecter une tache à une ressource, il faut d’abord avoir le
module de gestion des utilisateurs
Table 11 : Fiche de sprint de l’utilisateur
42 | P a g e
3. Diagramme d’acteur :
Figure 10 : Diagramme d’acteur système marketplace
Vendeur : utilisateur disposant du droit de créer de nouveaux produits pour les vendre.
Acheteur : utilisateur ayant les droits d’ajout au panier et de suivi des commandes déjà
réalisées.
Administrateur : gestionnaire de la plateforme disposant d'accès avancés au système.
Modérateur : gestionnaire de la plateforme disposant d’accès restreints à son

administration.
4. Diagramme use case utilisateur :

La figure suivante présente le cas d’utilisation du sprint de la gestion utilisateur , qui
permet d'identifier les possibilités d'interaction entre le système.
43 | P a g e
Figure 11 : Diagramme de use case utilisateur
5. Tableau descriptif des use case :

Le tableau qui suit présente les caractéristiques d’utilisateur par module utilisateur :
Code Libellé Acteur Description
User 01 Parcourir le marché Utilisateur utilisateur peut parcourir le site sans être
authentifié
User 02 Créer un compte Utilisateur Chaque utilisateur doit inscrire pour faire une
opération au notre système.
User 03 Créer une boutique Utilisateur Tout utilisateur peut créer une boutique sur
notre système et doit conclure un contrat avec
une période puis payer sa facture pour la
rencontre pour accéder à votre profil.
User 04 Ajouter un produit au Utilisateur Tout utilisateur peut rechercher le produit qu'il
panier souhaite et l'ajouter au panier
User 05 Chercher une annonce Utilisateur Tout utilisateur peut rechercher et lire toute
l’annonce publiée
Table 12 : Tableau de use case utilisateur
6. Diagramme de séquence utilisateur d’inscription :

Dans ce diagramme de séquence, nous verrons que l'utilisateur peut effectuer certaines
actions sans authentification, et nous verrons également qu'il suivra un scénario suivant :
44 | P a g e
Figure 12 : Diagramme de séquence utilisateur de systèmes
7. Tableau de Séquence utilisateur:

Le tableau qui suit présente les scénarios de diagramme de séquence par module
utilisateur :
Description Connexion au front office
Acteur Utilisateur
Précondition Authentification
Scenario - utilisateur doit remplir les informations et
valider pour générer un token son propre.
- si utilisateur saisir un login et mot de passe
correcte vous avez entrerez dans la plateforme
pour faire une opération, sinon on affiche un
message d'erreur
- chaque utilisateur peut parcourir le site sans
être authentifié et doit inscrire pour faire une
opération
Table 13 : Tableau de séquence utilisateur
8. Diagramme de séquence utilisateur messagerie :

Dans ce diagramme de séquence, nous verrons qu'un utilisateur peut envoyer un
message à un autre utilisateur via le chat. C'est ce que nous verrons ce dessous :
45 | P a g e
Figure 13 : Diagramme de séquence utilisateur (messagerie)
9. Tableau de Séquence utilisateur:

Le tableau qui suit présente le scénario de diagramme de séquence par module
messagerie :
Description Envoyer un message à l'utilisateur
Acteur Utilisateur
Précondition Messagerie
Scénario - Si un utilisateur envoie un message à une autre

personne, le message sera Realtime
- Login obligatoire pour discuter avec les
utilisateurs
- L’utilisateur demande au système d’afficher la
page du message, puis le rôle de l’utilisateur est
vérifié avant d’envoyer le message
Table 14 : Tableau de séquence utilisateur (messagerie)
46 | P a g e
10. Diagramme use case (administrateur - modérateur) :
Figure 14 : Diagramme de use case (administrateur - modérateur)

Le tableau qui suit présente la caractéristique administrateur et modérateur par module
utilisateur :
User Parcourir le marché Utilisateur Chaque utilisateur peut parcourir le site

sans être authentifié
User 01 Gestion des données Administrateur celui qui peut être l'administrateur des
bases de données des utilisateurs et peut
ajouter un autre administrateur
User 02 Gérer les comptes Administrateur C'est lui qui peut accepter la commande
des utilisateurs que ça soit la création
d’un contrat ou bien un service et autre
sort ...
User 03 Gestion de plateforme Administrateur Il peut faire n'importe opération que ça
soit ajouter un produit et catégorie et
chercher un produit ...
User 05 Consulter l’utilisateur Administrateur L’administrateur consulté un modérateur
ou bien vendeur pour gérer un problème.
User 06 Report un utilisateur Modérateur modérateur report au l'administrateur un
utilisateur qui enfreint les lois de
plateforme
Table 15 : Tableau use case (administrateur - modérateur)
47 | P a g e
12. Diagramme de séquence (administrateur - modérateur) :
Dans ce diagramme de séquence, nous verrons qu'un administrateur peut communique
avec un modérateur de site pour consulter les règles de plateforme est ce que nous
verrons ce dessous :
Figure 15 : Diagramme de séquence (administrateur - modérateur)
13. Tableau de Séquence utilisateur :

Description Les propriétaires de plateforme
Acteur Administrateur - Modérateur
Précondition Gérer une plateforme
scénario - Administrateur demande au système d'afficher
l'interface pour gérer les données utilisateur
pour ajouter un nouveau produit en liste des
produits.
- Administrateur doit remplir les informations de
produit que ça soit la quantité et la taille et
colore ...
- Administrateur Consulté modérateur pour gérer
une situation ou bien un problème au système à
travers un chat ou email
- Modérateur consulté administrateur est aussi.
- login obligatoire pour faire une opération
- Le modérateur vérifier le contenu d'une
annonce est peut accepter ou refusé si
l'annonce que vous avez écrite n'est pas
adaptée au contenu de notre système
Le modérateur report un utilisateur qui enfreint
les règles du système pour son chemin est
rapporté à l’administrateur
Table 16 : représente tableau de séquence (administrateur - modérateur)
48 | P a g e
II. Description du sprint : Gestion des vendeurs
Dans ce module, nous abordons un certain nombre de caractéristiques liées aux
fournisseurs de plates-formes pour ce système. Chaque fournisseur a des lois qui doivent
être suivies et comment cette plateforme est utilisée par les propriétaires du système.
2. Fiche du sprint
Ce tableau ci-dessous est une fiche de sprint de l’utilisateur.
Phase module Vendeur
Objectifs - Définir les tâches de sprint
Livrables en sortie - Exécutable un module de gestion vendeur.
Dépendance - Afin d’affecter une tache à une ressource, il faut d’abord avoir le module de
gestion des acheteurs
Table 17 : Tableau de phase module vendeur
3. Le Diagramme use case vendeur :

Dans cette figure nous avons voire les use case des vendeurs de notre ce pendant créer
un accourt dans la plateforme :
Figure 16 : Diagramme de use case vendeur (gestion de boutique)
49 | P a g e
4. Tableau descriptif des use case:
Le tableau qui suit présente les caractéristiques par module vendeur :
User 02 Login vendeur Chaque vendeur doit inscrire pour faire

une opération au notre système.
User 03 Créer une boutique vendeur vendeur créer une boutique sur notre
système et doit créer un contrat avec une
période ensuit paie sa facture pour
rencontre d'accédée au votre profile.
User 06 Consulté utilisateur vendeur Vendeur il peut consulter un utilisateur à
travers un chat ou bien u email
User 04 Gestion profile boutique vendeur Le vendeur peut modifier ses informations
personnelles et organiser ses produits et
annonces au profile pour choisis un design
particulier
Table 18 : Tableau use case vendeur
III. Description du sprint : Gestion des Boutiques

Dans ce module, nous abordons un certain nombre de caractéristiques liées aux fournisseurs
de plateformes pour ce système. Chaque fournisseur a des lois qui doivent être suivies et
comment cette plateforme est utilisée par les propriétaires du système.
2. Fiche du sprint
Phase module Boutique
- Construire un diagramme cas d’utilisation
- Construire un diagramme de séquence création une boutique
- Construire un diagramme de séquence gestion de produit et catégorie
et gestion des annonces
module de gestion des acheteurs
Table 19 : Tableau use case Boutique
3. Gestion du produit et catégorie et annonce :

Dans cette figure nous avons voire les use case des vendeurs pour consulter ou bien
gérer leur produit.
50 | P a g e
Figure 17 : Diagramme de use case vendeur (Gestion du produit et catégorie et annonce)

User 05 Acter un produit vendeur vendeur il peut également acheter le produit

dans notre système
User 07 Gérer les annonces vendeurs Vendeur il peut également mettre une annonce
sur la plateforme et parler de l'importance de
tout nouveau produit...
User 08 Consulté liste des vendeur Il peut consulter les commandes pour valider et
commandes voir la liste des commandes effectuées par les
clients et également consulter les donnes des
acheteurs
User 09 Gérer les produits Vendeur permet de gérer les produits dans le stock peut
ajouter et modifier et supprimer sur la
plateforme.
User 10 Gérer les catégories Vendeur permet de gérer (Ajouter/modifier/supprimer,
activer/désactiver) les contenus de la boutique
en ligne (les produits, les commandes, les
catégories).
Table 20 : Tableau descriptif des use case (Vendeur)
51 | P a g e
5. Diagramme de séquence Boutique :
❖ Diagramme de séquence « création une boutique »
Figure 18 : Diagramme de séquence création une boutique (Vendeur)
6. Tableau de Séquence Boutique:

Description Créer une boutique sure marketplace
Acteur Vendeur - Administrateur
Précondition Demande d’un contrat
Post Condition - login obligatoire pour faire une opération
- Le vendeur demande l'interface d'ajouter un
produit le système afficher un formulaire pour
remplir les informations de ce produit.
- Accéder à votre profil vous pouvez également
modifier vos informations personnelles avec la
publication de vos meilleurs produits et
annonces...
- Il faudra s'engager à créer un contrat selon les
conditions qui sont présentées à l'interface de
marché avec paiement, puis le système envoie
les données au fonctionnaire pour accepter la
demande après cela, le système vous donnera
votre profile pour gérer les produits ....
Table 21 : Tableau de séquence (Vendeur)
52 | P a g e
❖ Diagramme de séquence « gestion de produit et catégorie – gestion des annonces »
Figure 19 : Diagramme de gestion de produit et catégorie – gestion des annonces (Vendeur)
7. Tableau de Séquence Boutique:

Description Construire un diagramme de séquence gestion
de produit et catégorie et gestion des
annonces.
Acteur Vendeur - Modérateur
Précondition Consultation avec système marketplace
Post Condition -Login obligatoire pour faire une opération
-Le vendeur demande l'interface d'ajouter un
produit le système afficher un formulaire pour
remplir les informations de ce produit.
-Un vendeur peut ajouter une catégorie pour
chaque produit dont il dispose.
- Le vendeur remplira les informations sur le
produit et systèmes envoyer une requête au
serveur pour vérifiera son authenticité avant
qu'elle soit stockée dans la base de données
après cela le système affichera à l'écran des
produits qui tu as ajouté.
- Le vendeur peut ajouter des annonces à ses
produits, mais d'un autre côté, le système
envoie le contenu à l'intermédiaire pour
s'assurer de son exactitude, puis il sera accepté
ou rejeté
53 | P a g e
8. Réalisation
L’interface ci-dessous c’est une page d’ensemble du produit marketplace.
Figure 20 : image réalisation de plateforme boutique
54 | P a g e
CHAPITRE 5
Release 2
On va présenter le release 2 qui concerne la commande de produit par un client et la gestion
des acheteurs.
55 | P a g e
IV. Description du sprint : Gestion Commande
Dans ce module, nous abordons un diagramme de séquence pour supprimer une commande
déjà effectuée par un acheteur.
2. Fiche du sprint
Phase module Vendeur
- Construire un diagramme de séquence supprimer un produit
module de gestion des acheteurs
Table 23 : Tableau de phase module Commande
❖ Diagramme de séquence « supprimer des commandes »
Figure 21 : Diagramme de gestion des commandes (Vendeur)
56 | P a g e
3. Tableau de Séquence vendeur:
Description Construire un diagramme de séquence de la
commande.
Acteur Vendeur
Précondition Relation entre la commande et vendeur
Post Condition - le vendeur peut supprimer la commande de
client à travers la liste des commandes
- vendeur peut voir total paiement de toutes les
commandes effectuées à travers son profile.
- Une fois la commande confirmée par le client, le
système l'enverra au vendeur et vous montrera
la période dans laquelle le produit sera livré.
V. Description du sprint : Gestion des Acheteurs :

Dans cette unité, nous discutons d'un ensemble de caractéristiques liées aux acheteurs
pour ce système, et chaque acheteur a des étapes à suivre pour acheter un produit.
2. Fiche du sprint
Phase module Acheteur
- Construire un diagramme cas d’utilisation
- Construire les diagrammes de séquence
- Tableau de séquence
Livrables en sortie - Exécutable un module de gestion acheteur.

Dépendance Afin d’affecter une tache à une ressource, il faut d’abord avoir les
spécifications techniques de projet
Table 25 : La phase module acheteur
3. Diagramme use case :

La figure suivante, présente le cas d’utilisation du sprint de la gestion acheteur , qui
permet d'identifier les possibilités d'interaction entre le système
57 | P a g e
Figure 22 : Diagramme use case acheteur

User 01 Login system Acheteur Chaque Acheteur doit inscrire pour faire une
commande au notre système.
User 02 Chercher un produit Acheteur L'acheteur peut rechercher et lire n'importe quel
produit qu'il souhaite sans inscrire
User 03 Chercher une annonce Acheteur L'acheteur peut rechercher et lire n'importe quelles
annonces qu'il souhaite sans inscrire
User 04 Acter un produit Acheteur L'acheteur peut acheter le produit fourni par le
système via une commande.
User 05 Créer un compte Acheteur L’acheteur peut également créer un compte.
User 06 Gérer le panier Acheteur Cela signifie que vous pouvez supprimer et augmenter
le produit que vous souhaitez dans la gestion du
panier et choisit la quantité comme vous voulez.
User 07 Passer une commande Acheteur Il est nécessaire que cela passe une commande pour
obtenir un produit
User 08 Consulté vendeur Acheteur L'acheteur peut parler au propriétaire du produit via
un chat ou bien un email.
User 09 Choisis mode livraison Acheteur L'acheteur peut choisir le mode de livraison du produit
via les options du système.
Table 26 : Diagramme de use case acheteur
58 | P a g e
5. Diagramme de séquence Acheteur :
Figure 23 : Diagramme de séquence acheteur
6. Tableau de Séquence vendeur:

Description Construire les diagrammes de séquence acheteur
Acteur Acheteur
Précondition Acheter un produit
Post Condition - L'acheteur demande au système de montrer tous les
produits dans lesquels chercher ou bien taper à
l'input et le système affichera List des produits.
- L'acheteur peut rechercher et lire n'importe quelle
annonce qu'il souhaite sans inscrire.
- L'acheteur peut choisir le mode de livraison du
produit via les options du système.
- L'acheteur peut parler au propriétaire du produit via
un chat ou bien un email pour confirmer et vérifier la
disponibilité de produits après ça le système va
affichera un message de succès
- Pour qu'un acheteur puisse acheter un produit, il doit
d'abord être affiché dans un panier
- Une fois que vous avez ajouté un produit à votre
panier, vous pourrez passer une commande pour
payer votre produit.
- le système va vérifier si déjà tu as inscrit
- S'il est déjà faire inscription, il va l'offre l'interface de
paiement seront confirmées
- sinon va diriger pour faire l'inscription
Table 27 : Tableau de séquence vendeur
59 | P a g e
7. Réalisation
L’interface ci-dessous c’est une page d’ensemble du produit marketplace.
8. Diagramme de classe :
Le modèle physique de données représente les classes intervenant dans le système avec ces
attributs et les relations entres eux, la figure 11 représente un modèle de données de notre
plateforme :
60 | P a g e
Figure 24 : Diagramme de classe système Marketplace
9. Conclusion
Dans ce chapitre, nous avons décrit la conception globale de notre application, à travers les
différents diagrammes d’UML ainsi que le Business Process Model and Notation. Dans le
chapitre suivant, nous abordons la mise en place de la solution.
61 | P a g e
Conclusion générale :
Ce rapport décrit les différentes étapes de notre mise en œuvre du projet. Plateformes Web et
mobiles pour le marché du commerce électronique. Inégal le contexte général du projet, la
recherche fonctionnelle et technique, puis la conception les détails du projet pour terminer la
réalisation et la mise en œuvre du projet. Afin de mettre en œuvre ce projet, nous avons choisi
une méthode de gestion de projet. Nous avons d'abord défini le contexte général du projet en
clarifiant les enjeux et les exigences du projet, et passé présenter les enjeux que notre projet
doit traiter afin de finaliser son utilisez les méthodes de gestion Scrum pour la planification. Par
la suite, dans le cadre de l'étude fonctionnelle, nous identifier les acteurs impliqués dans le
système et spécifier les exigences fonctionnelles et la non-fonctionnalité attendue de
l'application.
L’étape suivante était de concevoir et de modéliser les différents cas d’utilisation, scénarios et
modules de l’application à travers le standard UML, pour qu’ensuite réaliser et mettre en
œuvre l’application. Ensuite, nous avons mené une étude et l'architecture technique qui sera
utilisée pour construire l'application.
Le projet de fin d’études nous a permis de développer nos compétences techniques,

D’approfondir nos connaissances théoriques et pratiques et de stimuler notre créativité.
D’autre part, l’environnement de travail nous a permis d’améliorer notre savoir-faire et
savoir-être, notre capacité d’analyse et de synthèse et surtout, il nous a aidés à fortifier notre
motivation.
Enfin, notre travail ne s'arrête pas à ce niveau, mais sur de nombreuses fonctions. Il peut être
spécialement ajouté à notre application, et le projet sera développé pour concurrencer les
grandes plateformes du marché...
62 | P a g e
Bibliographie et webographie :
Express Reference documentation

Construire une API REST avec Node, Express et Mongodb
Node.js Security best practices
Passeport d'authentification middleware pour Node.js.
Le package Redux Toolkit est destiné à être le moyen standard d'écrire la logique Redux.
https://github.com/goldbergyoni/nodebestpractices
https://github.com/john-smilga/node-express-course
https://daisyui.com/
https://www.youtube.com/watch?v=SBvmnHTQIPY&ab_channel=TraversyMedia
https://www.youtube.com/watch?v=bxmDnn7lrnk &ab_channel=TheNetNinja
https://www.youtube.com/watch?v=mTz0GXj8NN0&t=2548s&ab_channel=WebProbProEducation
63 | P a g e
Annexe :
1. Schéma de base de données :
Un schéma permet de décrire la structure d’une collection de données stockées dans des
fichiers accessibles à la demande pour de nombreux utilisateurs et pour divers besoins. Ces
données représentent un ensemble de données et la relation entre les tables.
Figure 25 : Schéma de base de donnés no SQL
2. Dictionnaire de données
Pendant la phase de conception, les données recueillies et spécifiées sont inscrites dans un
dictionnaire. Ce dictionnaire est un outil important, car il constitue la référence de toutes les
études effectuées ensuite. Les données sont présentées dans un tableau.
64 | P a g e
Champ Type Obligation Entité
Id Int Oui
Nom Char Non
Email Char Oui
Hash password Char Oui
Salt
Utilisateur
Date Non
Rôle Date Non
Histoire Int Non
Id Int Oui
Nom Char Oui
Admin
Prénom Date Oui
Téléphone Time Oui
Avatar profile Char Non
Id Int Oui Acheteur
Prénom Char Oui
Nom Char Oui
Téléphone Int Oui
Id Int Oui
Nom Char Non Vendeur
Prénom Char Non
description Int Non
Logo Buffer Nom
Email Char Nom
Téléphone Int Nom
Adresse Char Nom
Social Char Nom
Id Int Oui
Nom Char Oui Produit
Référence Char Oui
Quantité Char Nom
Prix public Décimal Nom
Prix d’achat Décimal Nom
Image Buffer Oui
Titre Char Oui
Description Char Nom
Statuts Char Nom
Id Int Oui
Date Commande Date Non Commande
65 | P a g e
Montant Décimal Non
Date Livraison Date Nom
Paiement mode Char Nom
Paiement date Char Nom
Prix total Décimal Nom
Lieu Char Non
Id Int Oui Catégorie
Libelle catégorie Char Non
Id Int Oui Panier
Quantité In Oui
Id Int Oui
Titre Char Non Annonce
Contenu Char Non
Image Buffer Non
Commentaire Char No
Id Int Oui
Body Char Nom Messagerie
Table 28 : Dictionnaire de données
66 | P a g e

Rapport Genie Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Rapport Genie Logiciel

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Genie Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Mini-projet génie logiciel

« Étude et implémentation d’un système

Année universitaire : 2023/2024

Au nom de toute l'équipe, je tiens à vous exprimer notre profonde gratitude

Travailler en équipe a été une expérience enrichissante, et nous sommes

• Déterminer les exigences fonctionnelles et non fonctionnelles du projet.

In this project, we accomplished the marketplace web platform,

• Identify the functional and non-functional needs of the project.

Figure 1: représente le processus du marketplace .................................................................................. 16

Table 1 : Livrables du projet ..................................................................................................................... 17

Amazon, RueduCommerce, Pixmania, Fnac.com…tous ces grands noms du e-commerce ont

• Un modèle tripartite entre vendeur, acheteur et opérateur.

- Voici ce que vous allez trouver les éléments principaux :

II. Contexte du projet :

a. Créer votre boutique en ligne :

b.Référencez votre boutique e-commerce pour être plus visible en ligne :

Figure 1: Représente le processus du marketplace

Phase Livrable Date de livraison Date validation

Table 1 : Livrables du projet

Risque Le type Impact Probabilité Action corrective

gestion du Risque non Le projet ne sera Moyen Doubler l’effort et ajuster le

Mots-Clés : Agilité, scrum, pratiques agiles, gestion de projet

c. Les rôles dans une équipe Scrum :

rien n’entrave l’équipe pendant le sprint.

Figure 2 : organisation de la Scrum Team autour de 3 rôles

8. Description des phases :

a. Phase de Conception générale :

Table 4 : phase de conception détaillée

Critères de fin de phase :

Table 5 : phase de phase de codage

Tableau 1 : Représente phase test des modules

Critères de fin de phase :

• Fin de la période de garantie de l’application (1 Mois)

Table 6 : la Phase Recette

Figure 3 : Image corresponde un processus Scrum

✓ Les projets SCRUM progressent par une série de sprints.

- Spécifications des besoins

➢ Les exigences qualité pour le présent projet

a. Rôles des acteurs du projet

On va entamer dans ce chapitre la partie réalisation et implémentation dans laquelle on

2. Les exigences fonctionnelles :

3. Expression des besoins fonctionnels

a. Identification des acteurs :

b. Identification des rôles :

Acheteur Consultation des catégories

c. Les besoins fonctionnels :

d. Les besoins non fonctionnels :

4. Les règles de gestion :

RG2 Chaque utilisateur doit posséder un rôle.

RG8 Seuls les administrateurs peuvent désactiver un compte vendeur

Table 10 : les règles de gestion de projet

Elles ont pour but de décrire précisément :

• Les environnements matériel et logiciel.

2. Étude technique du projet :

a. Le modèle REST API (RESTFUL API) :

Figure 5 : Image corresponds rest API pour multi-platform

Couches ou composants de l'API REST Node.js :

Figure 7 : Image SSG vs SSR dans next j

▪ SSR (server-side rendering) :

▪ SSG (static site generation) :