Conception et développement d'une marketplace basée sur l'architecture microservices

M. Fakher Ben Ftima
Mme. Sana Hamdi
M. Ramzi Mahmoudi
M. Ayoub Maatallaoui

Remerciement
Nous aimerions commencer par remercier l'ensemble de l'équipe
pédagogique de l’ISIMM et les intervenants professionnels
responsables de la formation sciences de l’informatique, pour avoir
assuré la partie théorique de celle-ci.
Nous tenons à exprimer également notre profonde gratitude et nos
remerciements les plus sincères à :
Dr. Ramzi Mahmoudi
Vous avez été bien plus qu'un simple encadrant pédagogique. Vous
avez été un mentor attentionné, toujours prêt à écouter nos idées, à
nous encourager et à nous pousser à donner le meilleur de nous-
même. Vos retours constructifs et vos suggestions pertinentes ont
contribué à affiner nos réflexions et à améliorer la qualité de notre
travail.
Mr. Ayoub Maatallaoui
Pour votre encadrement et votre mentorat pendant cette période
de stage. Votre expérience et vos conseils nous ont aidés à grandir
professionnellement et à acquérir une compréhension approfondie
du monde du travail. Les compétences que nous avons développées
grâce à votre encadrement seront un atout précieux tout au long de
nos carrière.
Les membres du jury
Qui ont accepté d’évaluer ce projet de fin d’études en espérant
qu’ils trouvent dans ce rapport les qualités de clarté et de
motivations qu’ils attendent.

Dédicace
Au moment où s'achève ce travail, il me tient à cœur d'exprimer ma
gratitude envers :
Mes Très chères Parents
Que ce travail soit l'expression profonde de ma reconnaissance envers
vous pour les sacrifices que vous avez consentis et le soutien moral et
matériel que vous n'avez cessé de prodiguer. Que Dieu vous préserve
en bonne santé et vous accorde une longue vie.
Mes chères sœurs.
Pour votre soutien tout au long de mes études, je tiens à exprimer ma
reconnaissance infinie. Vous avez été présentes à chaque étape de ma
vie académique, et grâce à vous, je suis devenu la personne que je suis
aujourd'hui.
Adem Amen Allah Thabti

Dédicace
Je dédie ce travail :
À mes parents, pour tous les sacrifices qu’ils ont fait et pour
tout le soutien qu’ils ont divulgué tout au long de mes études.
J’espère qu’ils puissent trouver dans ce modeste
travail un témoignage d’amour et d’affection envers eux.
À chaque membre de ma famille pour leurs encouragements et
leur continuel soutien...
Pour n’en oublier aucun, à tous mes amis, qui ont été toujours
présents...
À tous ceux qui m’ont aidé afin de réaliser ce travail.
À tous ceux que j’aime et qui m’aiment.
Merci !
Mohamed Yassine Essid

Table des matières
Introduction générale 1
1 Contexte et Objectifs 2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Contexte générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Présentation de l’entreprise d’accueil . . . . . . . . . . . . . . . . 3
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Méthodologie de développement et modélisation . . . . . . . . . . . . . . 9
1.5.1 Étude de Méthodologie de développement . . . . . . . . . . . . . 10
1.5.2 Choix de la méthodologie de travail . . . . . . . . . . . . . . . . 12
1.6 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Capture des besoins 15
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
i

2.4 Besoins techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Etude technologique . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2 Etude architecturale . . . . . . . . . . . . . . . . . . . . . . . . . 25
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Conception 32
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Conception générique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Urbanisation fonctionnelle en microservices . . . . . . . . . . . . . . . . 36
3.3 Microservice de « Gestion des utilisateurs » . . . . . . . . . . . . . . . . . 37
3.3.1 Diagramme de Cas d’utilisation associé au microservice « Gestion
des utilisateurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Description détaillée des cas d’utilisation associés au microservice
« Gestion des utilisateurs » . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3 Diagramme de séquence « S’authentifier » . . . . . . . . . . . . . 39
3.3.4 Description textuelle du cas d’utilisation « S’authentifier » . . . . 40
3.3.5 Diagramme de séquence « Modifier coordonnées » . . . . . . . . . 41
3.3.6 Description textuelle de cas d’utilisation « Modifier coordonnées » 42
3.3.7 Diagramme de séquence « Consulter les réclamations » . . . . . . 42
3.3.8 Description textuelle de cas d’utilisation « Consulter les réclama-
tions » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.9 Diagramme de composant « Gestion des utilisateurs » . . . . . . 44
3.3.10 L’architecture logicielle de Microservice « Gestion des utilisateurs » 45
3.4 Microservice de « Gestion des produits » . . . . . . . . . . . . . . . . . . 45
3.4.1 Diagramme de Cas d’utilisation associés au microservice « Gestion
des Produits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.2 Description détaillée des cas d’utilisations associé au microservices
« Gestion des Produits » . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.3 Diagramme de séquence « Ajouter produit » . . . . . . . . . . . . 48
3.4.4 Description textuelle du cas d’utilisation « Ajouter un produit » . 48
ii

3.4.5 Diagramme de séquence « Evaluer produit » . . . . . . . . . . . . 49
3.4.6 Description textuelle du cas d’utilisation « Evaluer produit » . . . 50
3.4.7 Diagramme de composant associé au microservice « Gestion des
produits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.8 L’architecture logicielle de microservice « Gestion des produits » 52
3.5 Microservice de « Gestion des commandes » . . . . . . . . . . . . . . . . 53
3.5.1 Diagramme de cas d’utilisation associé au microservice « Gestion
des commandes » . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5.2 Description détaillée des cas d’utilisation associé au microservice
« Gestion des commandes » . . . . . . . . . . . . . . . . . . . . . 54
3.5.3 Diagramme de séquence « Passer une commande » . . . . . . . . . 54
3.5.4 Description textuelle du cas d’utilisation « Passer une commande » 56
3.5.5 Diagramme de composant associé au microservice « Gestion des
produits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.6 L’architecture logicielle de microservice « Gestion des commandes » 58
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4 Réalisation 59
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 59
4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Présentation de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.1 Présentation de la solution web . . . . . . . . . . . . . . . . . . . 62
4.2.2 Présentation de la solution Mobile . . . . . . . . . . . . . . . . . . 66
4.2.3 Realisation des microservices . . . . . . . . . . . . . . . . . . . . . 71
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
iii

Table des figures
1.1 Veredent Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 DentalPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Jumia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 eBay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Pictogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Diagramme de gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Les bases de données relationnelles les plus populaires . . . . . . . . . . . 24
2.2 Les bases de données non relationnelles les plus populaires . . . . . . . . 25
2.3 Architecture Monolithique . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5 Architecture Microservice . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Architecture API Gateway Pattern . . . . . . . . . . . . . . . . . . . . . 30
2.7 Choix technologique de notre application . . . . . . . . . . . . . . . . . 31
3.1 Maquette préliminaire de l’interface login . . . . . . . . . . . . . . . . . . 33
3.2 Maquette préliminaire de l’interface d’accueil . . . . . . . . . . . . . . . . 34
3.3 Maquette préliminaire de l’interface dashboard de l’admin . . . . . . . . 34
3.4 Diagramme de classe globale . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Diagramme de classe orienté microservices . . . . . . . . . . . . . . . . . 37
3.6 Diagramme de cas d’utilisation associé au microservice « Gestion des uti-
lisateurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
iv

3.7 Les cas d’utilisation associés au microservice « Gestion des utilisateurs » 39
3.8 Diagramme de séquence« S’authentifier » . . . . . . . . . . . . . . . . . . 40
3.9 Diagramme de séquence « Modifier coordonnées » . . . . . . . . . . . . . 41
3.10 Diagramme de séquence« Consulter les réclamations » . . . . . . . . . . . 43
3.11 Diagramme de composant « Gestion des utilisateurs » . . . . . . . . . . 44
3.12 Architecture logicielle de microservice « Gestion des utilisateurs » . . . . 45
3.13 Diagramme de cas d’utilisation associés au microservice « Gestion des pro-
duits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.14 Diagramme de séquence « Ajouter un produit » . . . . . . . . . . . . . . 48
3.15 Diagramme de séquence « Evaluer produit » . . . . . . . . . . . . . . . . 50
3.16 Diagramme de composant associé au microservice « Gestion des produits » 52
3.17 Architecture logicielle de microservice « Gestion des produits » . . . . . 53
3.18 Diagramme de cas d’utilisation associé au Microservice « Gestion des com-
mendes » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.19 Diagramme de sequence « Passer une commande » . . . . . . . . . . . . . 55
3.20 Diagramme de composant associé au microservice « Gestion des commandes » 57
3.21 Architecture logicielle de microservice « Gestion des produits » . . . . . 58
4.1 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5 Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6 Nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7 LYX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.8 LucidChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.9 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.10 Interface d’acceuil Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.11 Interface d’acceuil Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.12 Interface SignIn Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
v

4.13 Interface Login Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.14 Interface vendeur-dashboard . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.15 Interface authentification application mobile. . . . . . . . . . . . . . . . . 67
4.16 Authentification cas d’erreur . . . . . . . . . . . . . . . . . . . . . . . . 68
4.17 Interface d’accueil application mobile . . . . . . . . . . . . . . . . . . . . 68
4.18 Interface catégorie application mobile . . . . . . . . . . . . . . . . . . . . 69
4.19 Interface produit application mobile . . . . . . . . . . . . . . . . . . . . . 70
4.20 Interface evaluer produit application mobile . . . . . . . . . . . . . . . . 71
4.21 Les images docker des microservices . . . . . . . . . . . . . . . . . . . . 71
4.22 Swagger Figure 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.23 Swagger Figure2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.24 Communication synchrone avec RabbitMq . . . . . . . . . . . . . . . . . 75
4.25 Liste des queues RabbitMq . . . . . . . . . . . . . . . . . . . . . . . . . . 75
vi

Liste des tableaux
1.1 Points forts et points faibles de DentalPlanet . . . . . . . . . . . . . . . 5
1.2 Point fort et point faible de Jumia . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Points forts et points faibles de eBay . . . . . . . . . . . . . . . . . . . . 7
1.4 Tableau compartif des solutions existantes . . . . . . . . . . . . . . . . . 8
1.5 Tableau comparatif des méthodologies de développement . . . . . . . . . 12
2.1 Besoins non fonctionelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Point forts et points faibles de React js . . . . . . . . . . . . . . . . . . . 19
2.3 Points forts et points faibles de Angular . . . . . . . . . . . . . . . . . . 20
2.4 Tableau comparatif entre les différents technologies Front-End Web . . . 20
2.5 Points forts et points faibles de React native . . . . . . . . . . . . . . . . 21
2.6 Points forts et points faibles de Flutter . . . . . . . . . . . . . . . . . . . 21
2.7 Tableau comparatif entre les différents technologies Front-End Mobile . . 21
2.8 Points forts et points faibles Spring Boot . . . . . . . . . . . . . . . . . . 22
2.9 Points forts et points faibles de NestJs . . . . . . . . . . . . . . . . . . . 23
2.10 Avantages et inconvénients des bases de données relationnels . . . . . . . 23
2.11 Avantages et inconvénients des bases de données non relationnels . . . . . 24
3.1 Description textuelle du cas d’utilisation « S’authentifier » . . . . . . . . 41
3.2 Description textuelle du cas d’utilisation « Modifier cordonnées » . . . . . 42
3.3 Description textuelle du cas d’utilisation« Consulter les réclamations » . 43
3.4 Les cas d’utilisation associés au microservice « Gestion des produits » . . 47
3.5 Description textuelle du cas d’utilisation « Ajouter Produit » . . . . . . . 49
vii

3.6 Description textuelle du cas d’utilisation « Evaluer produit » . . . . . . . 51
3.7 Tablau des cas d’utilisation associés au microservice « Gestion des com-
mendes » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.8 Description scénariste du cas d’utilisation « Passer une commande » . . . 56
viii

Liste des symboles
2TUP Two tracks unified process
ACID Atomicity Consistency Isolation Durability
AMQP Advanced Message Queuing Protocol
API Application programming interface
DDD Domain-Driven Design
JSON JavaScript Object Notation
REST REpresentational State Transfer
1

LISTE DES SYMBOLES
Introduction générale
L’informatique joue un rôle de plus en plus important dans l’évolution de notre
marché au cours des dernières décennies. Les technologies informatiques ont permis de
nombreuses innovations, notamment dans le domaine de la communication, de l’automa-
tisation des processus, de la gestion des données et de la connectivité entre les personnes
et les organisations.
Au vu de ce constat et de cette croissance, on ne peut pas négliger le passage des
priorités des opérations de vente de main en main vers des ventes virtuelles ce qui nous
oblige à donner plus d’importance à la vente électronique. Ce sont les boutiques élec-
troniques qui accélèrent et facilitent les traitements traditionnels tels que les processus
de commande et de facturation en offrant un accès facile et rapide aux produits. Le défi
est alors de faire des internautes d’aujourd’hui nos futurs clients à travers une inter-
face agréable et une plate-forme performante qui répondent aux besoins du client et lui
facilitent la procédure d’achat des biens et des services.
Les marketplaces jouent un rôle de plus en plus important dans le marché actuel en
permettant aux entreprises de vendre leurs produits et services en ligne via une plate-
forme unique. Elles ont créé un nouvel écosystème commercial, qui offre aux vendeurs
une audience plus large et aux acheteurs une expérience d’achat plus pratique et plus
complète. Les marketplaces offrent une variété de fonctionnalités telles que la gestion de
stocks, la gestion des commandes et des paiements, ainsi que des outils de marketing, de
communication et de service client. Elles permettent aux petites et moyennes entreprises
de concurrencer les grands acteurs du marché en proposant leurs produits à un public
plus large, sans avoir à investir dans des infrastructures coûteuses
1

Chapitre 1
Contexte et Objectifs
Introduction :
Dans ce chapitre, nous présentons le contexte général de notre projet. Nous commen-
çons par une introduction de l’organisation d’accueil. La deuxième partie sera consacrée à
notre contexte global du projet, dans lequel nous présenterons la problématique et l’étude
de ce qui existe, suivie de la solution proposée. Enfin, la dernière partie sera consacrée à
la méthodologie de travail adoptée.
1.1 Contexte générale
1.1.1 Cadre du projet
Le présent travail s’inscrit dans le cadre du projet de fin d’études en vue de l’obtention
du diplôme National de Licence en Sciences Informatique de l’Institut Supérieur d’Infor-
matique et Mathématiques de Monastir (ISIMM) pour l’année universitaire 2022/2023,
dans lequel nous allons concevoir et implémenter une solution web et mobile d’une mar-
ketplace basée sur l’architecture microservice de la société Veredent spécialisée dans le
domaine dentaire.
2

CHAPITRE 1. CONTEXTE ET OBJECTIFS
1.1.2 Présentation de l’entreprise d’accueil
Veredent est une startup dédiée à faciliter la connexion des praticiens dentaires avec
leur communauté et à les aider à rester à jour avec les dernières avancées de leur domaine.
Grâce à une application mobile, Dentallx, et d’autres outils innovants, Dentallx permet
aux dentistes de se connecter et d’échanger avec d’autres professionnels de la santé bucco-
dentaire, de partager leurs connaissances et d’accéder à des ressources précieuses. De
plus, Dentallx facilite la relation entre les praticiens et leurs fournisseurs de produits en
offrant un accès simplifié à un large éventail de fournisseurs, de promotions exclusives
et d’informations sur les produits. Cette plateforme interactive permet aux dentistes de
rester à l’avant-garde de leur profession, en améliorant leur pratique quotidienne et en
renforçant leur réseau professionnel. Avec Dentallx, les praticiens dentaires sont connectés,
informés et prêts à offrir des soins de qualité supérieure à leurs patients.
Figure 1.1 – Veredent Logo
1.2 Problématique
Malgré l’avènement de la technologie et d’Internet, l’achat et la vente de produits
et de services en ligne sont confrontés à des problèmes de fiabilité et de sécurité. Les
systèmes complexes peuvent rendre les transactions en ligne difficiles et peu fiables pour
3

les utilisateurs. Mais Il est important de souligner que pour s’aligner davantage sur les
besoins du client, les développeurs peuvent opter pour des solutions sur mesure, qui
répondent à des exigences spécifiques. Cela permet aux clients de bénéficier d’un système
personnalisé qui répond à leurs besoins spécifiques, tout en offrant des avantages tels que
des fonctionnalités uniques et une expérience utilisateur améliorée. Cela peut sembler
pratique au début, mais à mesure que le système grandit, il devient de plus en plus
difficile de le gérer et de le maintenir. Les développeurs peuvent avoir du mal à comprendre
comment le code est structuré, ce qui peut rendre la détection et la correction des erreurs
plus difficiles.
En 2018, Amazon a connu une panne technique majeure lors de son événement annuel
Prime Day. Le site Web et l’application ont été indisponibles pendant plusieurs heures,
empêchant les utilisateurs d’accéder au site Web, d’effectuer des achats et de profiter
d’offres exclusives. Certains ont émis l’hypothèse que le trafic important sur le site Web
pendant l’événement aurait pu surcharger les serveurs de l’entreprise et provoquer la
panne. La panne a provoqué l’insatisfaction des clients et la perte de ventes sur Amazon.
Amazon s’est par la suite excusé et s’est engagé à travailler pour éviter de tels problèmes
à l’avenir.
1.3 Etude de l’existant
La réalisation de tout projet doit être précédée par une étude de l’existant qui dé-
termine les points faibles et les points forts des systèmes actuels et les besoins du client
en vue de les prendre en considération lors de la conception et de la réalisation. Cette
étude nous permet de dégager et donner leurs atouts et leurs faiblesses an de déterminer
les besoins et les traiter.
1.3.1 Solutions existantes
• DentalPlanet
Dental Planet, Figure1.2, est une plateforme en ligne complète dédiée à l’industrie den-
taire. Elle est conçue comme une destination unique pour les professionnels dentaires et
les patients, offrant une large gamme de ressources et de services[1].
4

Figure 1.2 – DentalPlanet
Points forts Points faibles
-Vaste sélection de produits : Dental
Planet propose un catalogue étendu de
matériel dentaire, de fournitures et
d’instruments, offrant aux
professionnels dentaires un large choix
pour répondre à leurs besoins
spécifiques.
- Limitations géographiques : Dental
Planet peut avoir des limitations
géographiques en termes de livraison et
de disponibilité de services. Certains
utilisateurs peuvent être exclus de
certains avantages ou options offerts
par la plateforme en raison de leur
emplacement géographique.
- Support client limité : Il peut arriver
que le support client de Dental Planet
ne soit pas aussi réactif ou disponible
que souhaité. Cela peut entraîner des
retards dans le traitement des
questions ou des problèmes rencontrés
par les utilisateurs.
Table 1.1 – Points forts et points faibles de DentalPlanet
• Jumia
Jumia, illustrée par la figure 1.3, est une marketplace en ligne, présent dans 14 pays afri-
cains. Il met en relation des vendeurs et des acheteurs en mettant à leur disposition des
fonctionnalités basiques tel que Gestion de commande, de profil la consultation de l’his-
torique d’achats, la recherche filtrée, le retours et remboursements et les notifications[2].
5

Figure 1.3 – Jumia
Le tableau ci-dessous représente quelques points forts et points faibles de Jumia.
Points Forts Points Faibles
-Accessibilité facile et disponible sur
Web,Android et IOS
- interface chargé de publicité.
Table 1.2 – Point fort et point faible de Jumia
• eBay
eBay ,voir figure1.4 , est une plateforme de commerce électronique qui permet aux utilisa-
teurs d’acheter et de vendre une grande variété de produits, allant des produits neufs aux
articles d’occasion. Fondée en 1995, eBay est devenue l’une des plus grandes entreprises
de vente en ligne dans le monde, avec des millions d’utilisateurs actifs chaque jour. Les
utilisateurs peuvent acheter des produits dans une grande variété de catégories, y compris
l’électronique, la mode, la maison et le jardin, les bijoux, les jouets et les jeux, et bien
plus encore. Les vendeurs peuvent créer des annonces pour leurs produits, ajouter des
images et des descriptions détaillées, et fixer des prix de vente aux enchères ou des prix
d’achat immédiat. eBay propose également une large gamme d’options de paiement et de
livraison pour les acheteurs et les vendeurs [3] .
6

Figure 1.4 – eBay
Le tableau 1.3 représente quelque point forts et faible de eBay.
- Grande Audience
- Un système de protection de
l’acheteur : eBay dispose d’un système
de protection de l’acheteur qui peut
aider à protéger les acheteurs contre les
vendeurs malhonnêtes ou les produits
défectueux.
- Risque de fraudes : Comme eBay est
une plateforme de commerce
électronique ouverte, il peut y avoir un
risque de fraudes ou d’arnaques de la
part de certains vendeurs malhonnêtes.
- Enchères compétitives : Alors que les
enchères peuvent être une bonne façon
de trouver des produits rares ou
difficiles à trouver, cela peut également
conduire à des enchères compétitives et
à des prix élevés.
Table 1.3 – Points forts et points faibles de eBay
1.3.2 Critique de l’existant
Nous pouvons classer le résultat de l’analyse des applications web existantes mention-
nées précédemment selon cinq critères pris en considération dans le processus d’évaluation
de ses applications :
• Interface utilisateur et Attirance :
Le visiteur doit se sentir ciblé, il faut qu’il soit attiré par le site et que sa navigation soit
orientée et balisée. C’est ici que l’apparence du site sera évaluée.
7

• Application Mobile associé :
Avoir un site n’est pas de tout repos, avec une société et des internautes toujours plus
exigeants. Il faut être en mesure de leur fournir une meilleure expérience et améliore
la disponibilité du contenu, pour cela on a pris en considération dans l’évaluation si
l’application admet-elle une version mobile ou non ?
• Espace client :
Un espace client permet de faciliter les actions des utilisateurs tel que gérer ses coordon-
nées, ses préférences, son adresse, etc.
• Existance d’un Tableau de Bord :
Un tableau de bord qui permet d’analyser et gérer les produits et les ventes dans chaque
market .
• Paiement en ligne sécurisé :
Le paiement en ligne est aujourd’hui la méthode la plus simple et le plus rapide, en plus
il est plus sécurisé que les méthodes classiques, donc pour cela on a choisi le paiement en
ligne comme un critère dans l’évaluation des sites.
Le tableau ci-dessous présente une comparaison entre les solution existantes.
DentalPlanet Jumia eBay
Interface utilisateur et attirance Passable Passable Passable
Application Mobile associé Non Oui Oui
Espace client Oui Oui Oui
Gestion des Produits Non Oui Oui
Paiement en ligne sécurisé Non Oui Oui
Table 1.4 – Tableau compartif des solutions existantes
1.4 Solution proposée
La solution proposée est l’utilisation d’une architecture de microservices pour construire
une place de marché efficace et fiable. Cette approche permet de maintenir une sépara-
tion claire entre les différentes fonctions de la plateforme, ce qui facilite la maintenance et
l’extension de la plateforme tout en améliorant la fiabilité et la sécurité des transactions
en ligne. En plus de cette architecture de microservices, il est également possible de déve-
lopper une application web et mobile pour la plateforme. Cette application permettrait
aux vendeurs de créer leur propre marché personnalisé avec leur liste de produits, des
8

catégories et des descriptions détaillées. Les acheteurs pourraient facilement naviguer et
acheter des produits en utilisant cette application. Cette solution permettrait d’offrir une
expérience de transaction en ligne simple et pratique pour tous les utilisateurs de la place
de marché.
Pictogramme
Un pictogramme est une représentation visuelle simplifiée qui utilise des symboles
ou des icônes pour transmettre rapidement et efficacement des informations.
La figure ci-dessous présente notre solution sous forme d’un pictogramme illustrant
graphiquement ses caractéristiques.
Figure 1.5 – Pictogramme
1.5 Méthodologie de développement et modélisation
Une méthodologie de travail est un ensemble de techniques et de procédures permet-
tant d’organiser et de structurer efficacement le travail. Elle vise à améliorer la qualité
du travail accompli et à optimiser le temps et les ressources utilisés pour atteindre des
9

objectifs spécifiques. Cette méthodologie comprend la planification, l’organisation, la prio-
risation, l’exécution, le suivi et l’évaluation des phases, ainsi que l’utilisation d’outils et
de techniques de gestion du temps.
1.5.1 Étude de Méthodologie de développement
Devant le nombre de méthodes disponibles, le choix parmi elles devient difficile,
beaucoup de questions peuvent se poser à un chef de projet lors d’un démarrage de
projet. À cet égard, nous envisagerons plusieurs méthodes de développement, et selon
cette recherche, nous choisissons au mieux la méthodologie qui correspend à notre projet.
Méthodologie Two Tracked Unified Process
La méthodologie 2TUP (Two Tracks Unified Process) est une méthode de dévelop-
pement de logiciels qui combine deux approches de développement : l’approche dirigée
par les cas d’utilisation (Use Case-Driven) et l’approche dirigée par les fonctionnalités
(Feature-Driven). Cette méthode est basée sur le processus unifié (Unified Process) qui
est un cadre de développement logiciel itératif et incrémental. L’approche dirigée par
les cas d’utilisation (Use Case-Driven) se concentre sur la définition des exigences du
système à partir des cas d’utilisation et sur la modélisation de ces exigences pour créer
une représentation graphique du système. Cette approche est particulièrement utile pour
comprendre les besoins des utilisateurs et les fonctionnalités du système.
La figure ci-dessous présente un schéma de la La méthodologie 2TUP.
Méthode Scrum
Il s’agit d’une méthodologie de développement itérative et incrémentale qui met l’ac-
cent sur la collaboration entre les membres de l’équipe et la fourniture de fonctionnalités
utilisables aussi rapidement que possible. Elle est hautement adaptable et peut être uti-
lisé dans des projets dont les exigences évoluent rapidement. Il s’agit d’une méthode agile
axée sur la livraison de petits produits viables dans un court laps de temps. Les sprints
(phases de travail intensives) sont utilisés pour atteindre les objectifs, et les membres de
l’équipe se voient attribuer des rôles spécifiques[8].
La figure 1.7 illustre la méthodologie Scrum .
10

Figure 1.6 – 2TUP
Figure 1.7 – Scrum
Comparaison des méthodologies de développement
Le tableau 1.5 représente une comparaison des méthodologies de développement :
11

Méthodologies Avantages Inconvénients
2 Track Unified
Process (2TUP)
- Documentation rigoureuse
- Structuration claire
- Facilité de validation
-Économie d’espace
-Fiabilité et tolérance aux pannes
- Longue durée de développement
- Inflexibilité
Scrum - Livraison rapide de
fonctionnalités
- Collaboration : Scrum favorise la
collaboration entre les membres de
l’équipe, besoins de
développement, les parties
prenantes et le client, ce qui
permet d’identifier rapidement les
problèmes et de les résoudre de
manière proactive.
- Nécessité d’une implication
continue des parties prenantes
- Dépendance à l’égard de l’équipe
auto-organisée
- Difficulté de planification précise
Table 1.5 – Tableau comparatif des méthodologies de développement
1.5.2 Choix de la méthodologie de travail
Notre projet est basé sur un processus de développement bien défini qui va de la
détermination des besoins fonctionnels attendus du système jusqu’à la conception et le
codage final. Étant donné que nous avons une équipe de taille réduite, il est essentiel
d’adopter une approche de développement qui dissocie les aspects techniques des aspects
fonctionnels, tout en commençant par une étude préliminaire approfondie.
Après une analyse comparative approfondie des différentes méthodes de développement[24],
nous avons opté pour la méthode 2TUP. Cette méthode s’est avérée être une option adap-
tée à notre projet, car elle offre une approche nouvelle et originale tout en respectant le
cadre et les contraintes spécifiques de notre équipe et de notre projet.
Mise en pratique du processus 2TUP
2TUP est un processus de développement logiciel qui implémente le processus unifié
(c.à.d. itératif, incrémental, basé sur UML). Il propose un cycle de développement qui
sépare les aspects techniques des aspects fonctionnels en partant du constat que toute
évolution peut se traiter parallèlement, suivant un axe fonctionnel et un axe technique.
Ensuite, et en fusionnant les résultats de ces deux axes (branches), on arrive à réaliser le
système désiré.
12

1. L’étude préliminaire : Elle a pour objectif de définir les grandes lignes du projet
et d’évaluer sa faisabilité.
2. la capture des besoins fonctionnnels : Cette étape consiste à identifier et
à documenter les fonctions et les caractéristiques du logiciel qui sont nécessaires
pour satisfaire les besoins et les attentes des parties prenantes.
3. l’analyse : Elle consiste à examiner en détail les besoins des parties prenantes,
à comprendre leurs problèmes et leurs attentes, à identifier les processus et les
flux de travail impliqués dans le projet et à déterminer les contraintes techniques,
financières et temporell es qui s’appliquent au projet.
4. la capture des besoins techniques : Elle consiste à identifier et à documenter
les exigences techniques du logiciel, y compris les normes, les plateformes, les
outils et les technologies nécessaires à la conception, au développement et à la
maintenance du logiciel.
5. la conception générique : La conception générique consiste à élaborer la solu-
tion qui répond aux exigences techniques qu’on à spécifié dans la partie « capture
des besoins techniques »
6. la conception détaillée : Elle consiste à concevoir en détail chaque composant
logiciel identifié lors de l’analyse et à décrire comment ces composants seront im-
plémentés.La conception détaillée inclut des éléments tels que la modélisation des
données, l’architecture logicielle, la conception de l’interface utilisateur, la concep-
tion des algorithmes et des fonctions, ainsi que la définition de la structure et de
la hiérarchie du code.
7. le codage et les tests : Le codage consiste à écrire le code source du logiciel en
utilisant un langage de programmation approprié.Le but des tests est de s’assurer
que le logiciel fonctionne correctement et répond aux spécifications de conception.
1.6 Diagramme de Gantt
Un diagramme de Gantt est un outil de gestion de projet qui permet de visualiser
les différentes tâches de votre projet et leur avancement dans le temps. Nommé d’après
son inventeur Henry Gantt.
13

Figure 1.8 – Diagramme de gantt
Conclusion
Dans ce premier chapitre, nous avons réalisé une étude approfondie existante, ce
qui nous a permis d’obtenir une base solide pour notre projet en mettant en évidence la
solution souhaitable. Nous avons comparé plusieurs méthodes et conclu ce chapitre en
présentant la méthodologie 2TUP que nous adopterons pour le développement de notre
projet. Le chapitre suivant sera consacré à l’identification des besoins.
14

Chapitre 2
Capture des besoins
Introduction
L’étape d’analyse et de spécification des besoins vise à déterminer les diverses fonc-
tionnalités attendues du système. Dans ce chapitre, nous allons explorer comment les
besoins fonctionnels, non fonctionnels et techniques peuvent être capturés en utilisant la
méthode 2TUP.
2.1 Identification des acteurs
Pour notre système nous avons identifié les acteurs suivants :
• Internaute : c’est un visiteur de site , il peut consulter les Produits sur la page
d’acceuil, comme il peut les rechercher. Il peut aussi créer un profil et devenir un
client de la plateforme.
• Client : c’est un internaute qui est inscrit, possède un compte, dans la plateforme.
Il peut commander, consulter l’état de sa commande et évaluer des produits.
• Vendeur : Est un fournisseur de produits qui utilise notre système pour vendre
leurs produits à un large public.
• Administrateur : L’administrateur est responsable de la maintenance et de la
surveillance de la marketplace. Ses tâches incluent la gestion des utilisateurs, la
15

CHAPITRE 2. CAPTURE DES BESOINS
résolution des problèmes techniques et la conformité aux réglementations.
2.2 Besoins fonctionnels
Les besoins fonctionnels sont les exigences qui décrivent ce que le système doit faire
ou comment il doit fonctionner. Ils décrivent les fonctionnalités ou les services que le
système doit fournir pour répondre aux besoins de l’utilisateur final.
Dans la suite, nous allons exposer les besoins fonctionnels de notre application en
étroite relation avec les acteurs précédemment mentionnés.
L’internaute (Visiteur) détient le droit de :
• Consulter le site : consiste à accéder à la plateforme via un navigateur web ou
l’application mobile et à consulter les produits et les markets proposés.
• Créer compte : consiste à s’inscrire dans la platefrome en fournissant des infor-
mations personnelles.
• Rechercher un produit : consiste à effectuer une recherche pour trouver un
produit ou une boutique (fournisseur de produits).
le client (acheteur) détient le droit de :
• Gérer Panier : permet aux utilisateurs d’ajouter, modifier et supprimer des
produits de leur panier sur notre marketplace, avant de passer à la commande.
• Passer commande : consiste à passer la commande en ligne en validant les
produits selectionnées, en saisissant les informations nécessaire pour valider la
commande.
• Evaluer un produit : consiste à attribuer une note et à laisser un commentaire
sur un produit acheté ou utilisé précédemment sur la plateforme.
• Passer une réclamation : consiste à signaler un problème ou une insatisfaction
concernant un produit ou un service acheté auprès d’un vendeur ou d’un service
client sur la plateforme.
• Modifier Coordonnées : permet aux utilisateurs de mettre à jour leurs infor-
mations personnelles telles que leur adresse, leur numéro
16

le vendeur détient le droit de :
• Ajouter un nouveau produit : consiste à créer une nouvelle fiche produit en y
ajoutant les informations du produit, telles que la description, les images, le prix,
etc.
• Modifier un produit : consiste à mettre à jour les propriété d’un produit déja
ajouter dans la plateforme.
• Gérer ses commandes : consiste à suivre et à traiter les commandes passées par
les clients, en expédiant les produits et en mettant à jour les statuts de commande.
• Supprimer un produit : consiste à retirer une fiche produit existante, généra-
lement en raison de la fin de la disponibilité ou de la décision de ne plus proposer
le produit.
• Modifier infromations personnelle et boutique : permet aux vendeur de
mettre à jour leurs informations personnelles telles que leur adresse, leur numéro
L’administrateur détient le droit de :
• Gérer les comptes des clients : consiste à surveiller et à gérer les informations
des utilisateurs, en traitant les demandes de suppression de compte, en vérifiant
les informations d’identification et en gérant les problèmes de sécurité.
• Gérer les Produits : consiste à superviser et contrôler les différentes fonction-
nalités liées aux produits sur la plateforme
• Consulter les réclamations : recevoir, traiter et résoudre les réclamations des
clients, telles que les retours, les remboursements, les plaintes et les litiges, en
veillant à ce que les politiques et procédures de l’entreprise soient suivies et que
les clients soient satisfaits.
2.3 Besoins non fonctionnels
Les besoins non fonctionnels décrivent toutes les conditions requises permettant d’as-
surer le bon fonctionnement du système et d’améliorer la qualité des services pour l’uti-
lisateur. Pour notre platform ces exigences fonctionnelles doivent être décomposées en
17

microservices pour une architecture flexible, évolutive et maintenable. On a défini les
besoins non fonctionnels suivants :
Ergonomie : Tous les standards d’ergonomie doivent être res-
pectés dont la convivialité et la compréhensibilité des interfaces
graphiques. De plus, le choix des couleurs, la densité et l’or-
ganisation des éléments sur l’écran et aussi l’utilisation des
messages informatifs et des messages d’erreurs bien formées et
bien lisibles.
Disponibilité : Le système doit être hautement disponible,
avec une faible tolérance aux pannes, pour garantir une expé-
rience utilisateur fluide et ininterrompue.
Évolutivité : L’architecture microservices doit permettre
l’évolutivité facile des différents services, en fonction des be-
soins du système, sans affecter les autres services.
Intégration : Les différents services doivent être facilement
intégrables et compatibles avec d’autres applications tierces,
afin de permettre une intégration facile avec des systèmes exis-
tants.
Cohérence : L’ensemble du système doit être cohérent et fonc-
tionner de manière homogène, afin de garantir une expérience
utilisateur transparente et cohérente.
Performance : Le système doit être rapide et répondre rapi-
dement aux demandes des utilisateurs, en minimisant les temps
de latence et les temps d’arrêt.
Sécurité : Le système doit être sécurisé et protéger les don-
nées sensibles des utilisateurs, telles que les informations de
paiement et les données personnelles.
Table 2.1 – Besoins non fonctionelles
2.4 Besoins techniques
Nous nous intéressons ici à la branche droite du cycle en Y « Capture des besoins
techniques » qui capitalise le savoir-faire technique. Afin de bien expliquer nos choix
technologiques, nous avons fait recours à une étude comparative entre les différentes
technologies qui peuvent être utilisés durant notre projet.
18

2.4.1 Etude technologique
Dans la partie suivante nous présentons les Framework Front-End et Back-End que
nous allons utiliser pour le développement de notre application Web et Mobile.
Front-End Web
Le nombre des technologies de développement des applications web (coté client) est
en croissance continue. Parmi les langages les plus populaires nous citons :
React.js est une bibliothèque JavaScript open-source qui est
utilisée pour construire des interfaces utilisateur spécifique-
ment pour des applications d’une seule page. Elle est utilisée
pour gérer la couche d’affichage des applications web.React
permet aux développeurs de créer de grandes applications web
qui peuvent modifier les données, sans avoir à recharger la
page.
Points forts Points faibles
-Virtual DOM efficace
-Composants réutilisables
-Flux de données unidirectionnel
-Grande communauté de développeurs
-Courbe d’apprentissage initiale
-Complexité croissante avec des
applications complexes
-Taille de la bibliothèque et temps de
chargement potentiellement plus longs.
Table 2.2 – Point forts et points faibles de React js
AngularJS est un framework JavaScript open-source déve-
loppé par Google en 2010. Il est conçu pour simplifier la créa-
tion d’applications web complexes en offrant une approche
structurée pour organiser le code.
19

- Angular est basé sur une architecture
MVC qui facilite la structuration et la
maintenance du code.
- Il dispose d’une vaste gamme de
fonctionnalités et de modules prêts à
l’emploi pour faciliter le
développement.
- Angular est compatible avec de
nombreux autres outils et technologies,
tels que TypeScript, RxJS, Ionic, etc.,
ce qui permet de créer des applications
multiplateformes.
- Les directives personnalisées
d’Angular peuvent nécessiter une
configuration et un développement
supplémentaires, ce qui peut prendre
du temps et ajouter de la complexité
au projet.
- Les mises à jour fréquentes d’Angular
peuvent également poser des problèmes
de compatibilité avec les anciennes
versions, ce qui peut nécessiter des
efforts supplémentaires pour la
maintenance et la mise à jour des
applications existantes.
Table 2.3 – Points forts et points faibles de Angular
Vue Js React Js Angular Js
Performance Moyen Haute Haute
Scalabilité Faible Haute Haute
Apprentissage Facile Facile Moyen
Communité des développeurs Petite Très grande Grande
Acceptation et confiance Faible Haute Haute
Table 2.4 – Tableau comparatif entre les différents technologies Front-End Web
Front-End Mobile
Le développement mobile peut être divisé en deux catégories principales : le déve-
loppement natif et le développement multiplateforme.
• Le développement natif : implique la création d’applications spécifiques à une
plateforme particulière .
• Le développement multiplateforme : permet de créer une application unique
qui peut être déployée sur plusieurs plateformes différentes.
Le développement multiplateforme est une option intéressante lorsque vous souhaitez
réduire les coûts et les efforts de développement en créant des applications qui doivent
fonctionner sur plusieurs plateformes différentes. Cependant, cela peut entraîner une ex-
périence utilisateur sous-optimale et des performances plus lentes que le développement
natif.
Il existe plusieurs technologies multiplateformes populaires qui vous permettent de
développer des applications mobiles pour plusieurs plates-formes différentes à l’aide d’un
20

seul ensemble de code source. Les trois technologies multiplateformes les plus couramment
utilisées sont React Native, Xamarin et Flutter.
React Native est une plateforme de développement multipla-
teforme open source développée par Facebook qui vous aide à
développer des applications mobiles pour iOS et Android à
l’aide de JavaScript et React.
- Grande communauté de soutien
- Développement rapide et facile grâce
à l’utilisation de JavaScript
- Performances moins rapides que le
développement natif
- Peut nécessiter des configurations
spécifiques pour les différentes
plateformes
Table 2.5 – Points forts et points faibles de React native
Flutter est une plate-forme de développement multiplate-
forme open source développée par Google pour développer des
applications mobiles pour iOS, Android et le Web à l’aide du
langage de programmation Dart.
- Offre une qualité d’interface
utilisateur élevée grâce à son
architecture moderne
- Développement rapide et facile grâce
à l’utilisation de Dart et du hot
reloading
- Moins de support et de
documentation par rapport à React
Native ou Xamarin.
- Peut nécessiter des connaissances en
Dart
Table 2.6 – Points forts et points faibles de Flutter
React Native flutter
Performance Moyen Haute
Scalabilité Moyen Haute
Apprentissage Moyen Moyen
Communité des développeurs Très grande Tres grande
Acceptation et confiance Moyen Haute
Table 2.7 – Tableau comparatif entre les différents technologies Front-End Mobile
Back-End
Le Back-End, qui est invisible pour le client, représente une grande partie du déve-
loppement de notre projet. On peut décomposer le Back-End en deux parties essentielles :
21

Services métier les services métier occupent une place centrale en tant que respon-
sables de la logique applicative qui gère les fonctionnalités clés de la plateforme. Ils sont
chargés de mettre en œuvre les règles métier spécifiques à la marketplace .
Les services métier peuvent être développés en utilisant différents frameworks adap-
tés, tels que Spring Boot et NestJS, qui offrent des fonctionnalités de développement
robustes et une structure modulaire.
Examinons de plus près les caractéristiques de chacun de ces frameworks
Spring Boot est l’un des frameworks les plus utilisés pour le
développement d’applications backend, y compris les Services
Métier. Basé sur Java, un langage de programmation largement
adopté dans l’industrie, Spring Boot offre un écosystème riche
et mature. Il dispose d’une vaste gamme de bibliothèques et
de modules pour gérer des fonctionnalités telles que l’injection
de dépendances, la persistance des données et la sécurité.
- Spring Boot bénéficie d’un
écosystème Java mature et étendu,
offrant une multitude de bibliothèques,
de modules et d’outils pour le
développement d’applications backend.
- Spring Boot dispose d’une
communauté très active et d’une
documentation complète.
- il peut y avoir une courbe
d’apprentissage initiale plus longue
pour les développeurs moins familiers
avec le framework ou le paradigme de
programmation Spring.
- Configuration parfois complexe
Table 2.8 – Points forts et points faibles Spring Boot
NestJs NestJS est un framework basé sur JavaS-
cript/TypeScript qui gagne en popularité pour le déve-
loppement d’applications backend, y compris les Services
Métier. Il offre une architecture basée sur les modules, ce qui
facilite l’organisation du code en composants réutilisables.
22

- Fortement basé sur TypeScript,
offrant une expérience de
développement plus solide grâce à la
typage statique, à l’autocomplétion et
à la détection précoce des erreurs.
- Adopte une architecture modulaire
qui facilite la structuration du code en
composants réutilisables. Cela permet
de développer des applications bien
organisées et faciles à maintenir.
- Communauté relativement plus petite
Table 2.9 – Points forts et points faibles de NestJs
Base de Données
Les bases de données sont essentielles pour gérer des informations de manière orga-
nisée et cohérente, offrant ainsi un support précieux pour la prise de décision et l’analyse
des données, on peut citer deux types de base de données (relationnels et non relation-
nels). Dans le cas de notre application nous allons utiliser les deux types de bases de
données selon les besoins de chaques services.
• Base de données relationnels[5] : Une base de données relationnelle est un
type de base de données où les données sont liées à d’autres informations au
sein des bases de données. Les bases de données relationnelles sont composées
d’un ensemble de tables qui peuvent être accessibles et reconstruites de différentes
manières, sans qu’il soit nécessaire de réarranger ces tables de quelque façon que
ce soit. Le langage de requête structuré (SQL) est l’interface standard pour une
base de données relationnelle.
Avatages Inconvénients
- Capacité de gérer des relations complexes
- Puissance des requêtes complexes
- Structure et intégrité des données
- Normalisation des données
- Difficulté avec les données
semi-structurées ou non structurées
- Complexité des requêtes et de la
modélisation
- Rigidité du schéma
Table 2.10 – Avantages et inconvénients des bases de données relationnels
23

Figure 2.1 – Les bases de données relationnelles les plus populaires
• Base de données non relationnels (NOSQL)[5] : Les bases de données non rela-
tionnelles sont conçues pour gérer de grandes quantités de données non structurées
ou semi-structurées, telles que des documents, des graphes, des paires clé-valeur
ou des données en colonnes. Elles offrent une flexibilité accrue pour évoluer hori-
zontalement et supporter des charges de travail distribuées à grande échelle.
Avatages Inconvénients
- Gestion de données non structurées
- Évolutivité horizontale
- Flexibilité de schéma
- Haute performance
- Moins adaptées aux requêtes complexes
- Moins de support et de documentation
- Manque de normalisation
Table 2.11 – Avantages et inconvénients des bases de données non relationnels
24

Figure 2.2 – Les bases de données non relationnelles les plus populaires
2.4.2 Etude architecturale
Dans cette partie , nous explorerons les principes fondamentaux des différentes ar-
chitecture, en mettant l’accent sur les avantages et les considérations clés de chacune.
Nous examinerons également les principes de conception sous-jacents qui guident la mise
en œuvre de chaque architecture.
Architecture Monolithique
Une architecture monolithique est un style de développement logiciel dans lequel
toutes les fonctionnalités d’une application sont regroupées dans un seul bloc de code.
Cela signifie que l’application est construite, testée et déployée comme une seule unité.
Les architectures monolithiques sont généralement utilisées pour des applications simples
et peu complexes, mais peuvent devenir difficiles à gérer à mesure que les applications
deviennent plus grandes et plus complexes. Les mises à jour et les modifications peuvent
également être plus difficiles à mettre en œuvre dans une architecture monolithique[4].
25

Figure 2.3 – Architecture Monolithique
Inconvénients de l’architecture monolithique Les principaux inconvénients de
l’approche monolithique sont les suivants :
• Risque accru de défaillance : si une partie de l’application échoue, cela peut
entraîner l’arrêt de l’ensemble du système.
• Difficulté de mise à l’échelle : Lorsque le trafic augmente et que l’application
doit être mise à l’échelle pour gérer la charge, l’architecture monolithique peut
poser des défis.
• Inconvénients Extensibilité limitée : L’architecture monolithique peut devenir
difficile à étendre lorsque de nouvelles fonctionnalités doivent être ajoutées.
• Déploiement complexe : Les applications monolithiques nécessitent souvent un
déploiement complet pour apporter des modifications, ce qui peut entraîner des
temps d’arrêt plus longs.
Architectures microservices
Ce partie se focalise sur les concepts fondamentaux en lien avec notre travail. Tout
d’abord, nous abordons les concepts liés à l’architecture Microservices
Les concepts liés à l’architecture microservices
• Le Domain Driven Design
Le DDD pour « Domain-Driven Design » [9]est appelé en français «Conception pilotée
par le domaine» est une approche de conception logicielle qui se concentre sur la com-
préhension approfondie du domaine métier d’une application. Cette approche permet de
26

développer des logiciels plus proches des besoins réels des utilisateurs, en utilisant un
vocabulaire et des concepts communs à tous les acteurs du projet. Le Domain Driven
Design (DDD) utilise le principe de Bounded Context pour découper le domaine métier
d’une application en plusieurs parties cohérentes et autonomes. Chaque Bounded Context
possède son propre vocabulaire, modèles et règles métier, et est délimité par des interfaces
claires et précises qui définissent les interactions avec les autres contextes. Cette approche
permet de mieux gérer la complexité des applications en permettant à chaque contexte
de gérer sa propre logique métier de manière indépendante.
La mise en œuvre de Bounded Context peut aider à résoudre des problèmes tels que
la coordination des équipes de développement et la mise à l’échelle de l’application.
Figure 2.4 – Domain-Driven Design
• Le développement à base de composants
Le développement à base de composant est une branche de l’ingénierie logicielle consiste à
découper une application en plusieurs composants autonomes, chacun étant responsable
d’une fonctionnalité spécifique. Les composants sont conçus pour être réutilisables, ce qui
permet de les assembler de manière flexible pour créer des applications plus grandes et
plus complexes.
• Programmation polyglotte
En 2000, Scott Leberknight [6] a introduit le terme "programmation polyglotte" (Polyglot
Programming), qui consiste à utiliser plusieurs langages de programmation pour résoudre
différents types de problèmes dans une application. Les applications complexes peuvent
bénéficier de cette approche en choisissant le langage le mieux adapté à chaque tâche. Ce
concept peut également s’appliquer aux bases de données .
27

• Iolation des microservices dans des conteneurs (conteneurisation) :
L’isolation des microservices dans des conteneurs est une pratique clé de l’architecture
microservice. Chaque microservice est encapsulé dans un conteneur léger et autonome
qui contient tous les éléments nécessaires à son fonctionnement. Cette isolation assure
une meilleure stabilité et résilience de l’architecture, tout en permettant une gestion
plus flexible des ressources informatiques. En résumé, l’isolation des microservices dans
des conteneurs est un élément essentiel pour une architecture microservice efficace et
évolutive[10].
Définition de l’architecture Microservice
L’architecture microservices[4] est une approche de développement logiciel qui consiste
à construire une application en la décomposant en un ensemble de services indépendants,
autonomes et spécialisés, chacun exécutant une tâche spécifique. Chaque service est conçu
pour fonctionner de manière autonome, en communiquant avec les autres services via
une interface bien définie. Cette architecture est basée sur le principe de la séparation
des préoccupations et de la modularité, ce qui permet une plus grande flexibilité et une
évolutivité accrue.
Figure 2.5 – Architecture Microservice
Les avantages de l’architecture microservice Les avantages de l’architecture de
microservices incluent :
• Évolutivité : Les services peuvent être développés, déployés et évalués indépen-
damment les uns des autres, permettant une évolutivité horizontale et une utili-
28

sation plus efficace des ressources.
• Agilité : Les petites équipes peuvent travailler sur des services individuels, ce qui
permet une plus grande flexibilité et une itération plus rapide.
• Résilience : Si un service tombe en panne, les autres services continuent de
fonctionner, réduisant l’impact des pannes.
• Réutilisation : Les services peuvent être réutilisés dans différentes applications
et les nouvelles fonctionnalités peuvent être développées sans perturber les services
existants.
• Technologie adaptée : Les services peuvent être développés dans différents lan-
gages de programmation et utiliser différentes technologies de stockage de données
en fonction de leurs besoins spécifiques.
• Mise à l’échelle : Les services peuvent être mis à l’échelle individuellement en
fonction des besoins de l’application.
Choix architectural et technologique
Choix architectural
Pour la mise en œuvre de notre application, nous avons choisi une architecture basée
sur les microservices. Cette approche architecturale divise notre système en plusieurs
services indépendants et spécialisés, appelés microservices, qui interagissent entre eux
pour offrir les fonctionnalités de l’application. Chaque microservice est responsable d’une
partie spécifique du système, ce qui permet une séparation claire des préoccupations et
une évolutivité horizontale.
Nous adoptons le patron de passerelle API, qui permet de centraliser la ges-
tion des requêtes provenant des clients en fournissant une interface unique. Il offre des
fonctionnalités telles que la mise en cache, la limitation du débit, la transformation des
données et la sécurité. Au lieu de devoir contacter chaque service individuellement, les
clients envoient leurs requêtes à l’API Gateway, qui se charge de les router vers les services
appropriés. [7].
29

Figure 2.6 – Architecture API Gateway Pattern
Choix technologique
Nous avons sélectionné un ensemble de technologies robustes et performantes pour
la mise en œuvre de notre solution :
• Angular pour le frontend web
• Flutter pour l’application mobile
• Nginx en tant que passerelle API « Api Gateway »
— Pour gérer et sécuriser la communication entre nos microservices et les clients,
nous utiliserons Nginx en tant que passerelle API. Nginx agit comme un proxy
inverse, gérant les requêtes des clients et les redirigeant vers les microservices
appropriés.
• Nous avons décidé d’adopter une approche hybride en utilisant à la fois
PostgreSQL et MongoDB.
— Nous avons opté pour MongoDB pour les services qui nécessitent une grande
flexibilité de schéma et une évolutivité horizontale.
— D’autre part, pour les services qui exigent un modèle de données relationnel
plus strict et des transactions ACID nous avons choisi PostgreSQL.
• RabbitMQ comme courtier de messages « Message Broker »
— Pour faciliter la communication asynchrone et découpler les services, nous avons
intégré RabbitMQ en tant que courtier de messages. RabbitMQ prend en charge
le modèle d’édition-souscription, permettant aux microservices d’échanger des
30

messages de manière efficace. Cela permet une communication évolutive et
résiliente entre les différentes composantes de notre système.
La figure ci-dessous illustre l’architecture technologique choisie pour notre solution .
Figure 2.7 – Choix technologique de notre application
Conclusion
Dans ce chapitre, nous avons également documenté diverses exigences du projet.
Nous classons ces besoins en besoins fonctionnels, besoins non fonctionnels et besoins
techniques.
31

Chapitre 3
Conception
Introduction
Cette partie traite des aspects conceptuels de la conception orientée microservices de
l’application. Contrairement aux approches traditionnelles, cette conception se base sur
la création de services indépendants et autonomes, chacun ayant une fonctionnalité spéci-
fique. La mise en œuvre de cette architecture repose sur une méthodologie de conception
par service, où chaque service est conçu de manière autonome, indépendante des autres
services. Cette approche offre une flexibilité marquante, permettant une évolutivité facile
et une meilleure gestion de la complexité de l’application. Nous utiliserons pour cela le
format UML, en créant des diagrammes spécifiques pour chaque service.
3.1 Conception générique
La phase de conception permet de décrire de manière ambigüe, le plus souvent en uti-
lisant un langage de modélisation, le fonctionnement futur du système, afin d’en faciliter
la réalisation.
32

CHAPITRE 3. CONCEPTION
Le language UML
Pour faciliter notre tâche nous avons fait recours au langage de modélisation unifié
« UML » (Unified Modeling Language) qui permet de modéliser un problème de façon
standard. Ce langage qui est né de la fusion de plusieurs méthodes existantes auparavant
est devenu une référence en termes de modélisation objet[23] :
• Il permet le gain, encourage l’utilisation d’outils et constitue à cet effet un gage
de stabilité.
• Il cadre l’analyse et facilite la compréhension de représentations abstraites com-
plexes.
• Il est formel et normalisé : son caractère polyvalent et sa souplesse en font un
langage universel.
Conception préliminaire des interfaces-Prototypes
Une maquette est un produit jetable donnant aux utilisateurs une vue concrète mais
non définitive de la future interface de l’application. Elle est développée rapidement afin
d’améliorer la relation développeur-client. Les maquettes de notre application sont les
suivantes :
Figure 3.1 – Maquette préliminaire de l’interface login
33

Figure 3.2 – Maquette préliminaire de l’interface d’accueil
Figure 3.3 – Maquette préliminaire de l’interface dashboard de l’admin
34

Diagramme de classe globale
Un diagramme de classe dans le langage UML est un type de diagramme de structure
statique qui décrit la structure d’un système en montrant le système de classes, leurs
attributs, les opérations (ou) les méthodes et les relations entre les classes.
La figure ci-dessous illustre bien le diagramme de classe globale de notre système.
Figure 3.4 – Diagramme de classe globale
35

3.2 Urbanisation fonctionnelle en microservices
Dans le cadre de notre application, nous avons adopté une architecture basée sur
les microservices en nous appuyant sur les principes de la conception orientée domaine
(DDD). Cette approche nous permet de diviser notre système en services indépendants
et orientés, alignés sur les concepts clés de notre domaine métier.
Nous avons défini précédemment le DDD comme étant la « Conception pilotée par
le domaine », une approche de conception logicielle qui se concentre sur la compréhension
approfondie du domaine métier de notre application (voir page 27 pour plus de détails).
nous avons identifié plusieurs services, dont User Management, Product Management,
Command Management, et Payment.
• Le micro-service Gestion des utilisateurs est responsable de la gestion de tous
les utilisateurs liés, y compris les clients et les vendeurs.
• Le micro-service Gestion des produits est chargé de la gestion des produits
proposés par les vendeurs.
• Le micro-service Gestion des commandes se concentre sur la gestion des com-
mandes passées par les clients et recus aux vendeurs.
• Enfin, le micro-service Paiement est spécifiquement dédié à la gestion des paie-
ments.
Pour mieux illustrer l’implémentation pratique de notre architecture, nous avons créé un
deuxième diagramme de classe, dans la figure ci-dessous, qui regroupe chaque classe avec
le service auquel elle appartient. Nous utilisons des cercles pour représenter ces regrou-
pements, ce qui permet de visualiser clairement l’organisation des classes en fonction des
services.
36

Figure 3.5 – Diagramme de classe orienté microservices
3.3 Microservice de « Gestion des utilisateurs »
Dans le contexte des microservices, la gestion d’utilisateurs peut être traitée comme
un service autonome, responsable de toutes les opérations liées aux comptes utilisateurs.
Cela permet de simplifier la maintenance et l’évolution de ces fonctionnalités, tout en
offrant des interfaces claires pour les autres services qui ont besoin d’interagir avec les
utilisateurs.
37

3.3.1 Diagramme de Cas d’utilisation associé au microservice
« Gestion des utilisateurs »
La figure ci-dessous illustre le diagramme de cas d’utilisation « Gestion des utilisa-
teurs » qui détermine le role (les fonctionnalités) de ce microservice.
Figure 3.6 – Diagramme de cas d’utilisation associé au microservice « Gestion des
utilisateurs »
3.3.2 Description détaillée des cas d’utilisation associés au mi-
croservice « Gestion des utilisateurs »
Dans cette section nous allons présenter une description détaillée de quelques cas
d’utilisation
38

Cas
d’utilisation
Acteur Description
S’authentifier Client,
Vendeur,
Admin
Permet aux utilisateurs de s’authentifier au système .
Créer
Compte
Internaute Le visiteur de site peut faire une inscription pour qu’il
soit un Client ou bien un vendeur.
Modifier
coordonnées
Client Permet au client de mettre à jour ses informations
personnelles dans son compte sur la marketplace. Cela
peut inclure le nom, l’adresse, les coordonnées, les
préférences de communication, etc.
Passer une
réclamation
Client Consiste a signaler un problème ou une insatisfaction
concernant un produit acheté auprès d’un vendeur ou
d’un service client sur le site ou l’application.
Modifier les
informations
personnelles
et boutique
Vendeur Permet au vendeur de mettre à jour ses informations
personnelles dans son compte et son boutique. Cela
peut inclure le nom, l’adresse, les coordonnées, les
informations de paiement, etc.
Gérer les
comptes des
clients
Admin Cela consiste à surveiller et gérer les informations des
utilisateurs enregistrés sur un site ou une application
de commerce électronique, en vérifiant les informations
d’identification et en gérant les problèmes de sécurité.
Gérer les
comptes des
vendeur
Admin Cela consiste à surveiller et gérer les informations des
vendeur,en traitant les demandes de modification,
implique également la gestion des contrats conclus avec
les vendeurs sur la marketplace.
Consulter les
reclamation
Admin Cela consiste a examine les réclamations soumises par
les utilisateurs (clients/vendeur) .
Figure 3.7 – Les cas d’utilisation associés au microservice « Gestion des utilisateurs »
3.3.3 Diagramme de séquence « S’authentifier »
La Figure 3.8 décrit les différentes interactions entre l’utilisateur et les différents
objets du sytème pour le traitement du cas d’utilisation « S’authentifier »
39

Figure 3.8 – Diagramme de séquence« S’authentifier »
3.3.4 Description textuelle du cas d’utilisation « S’authentifier »
La description textuelle suivante présente en détail les différentes étapes et interac-
tions impliquées dans le cas d’utilisation « S’authentifier ». Ce cas d’utilisation permet
aux utilisateurs de s’authentifier(se connecter/créer un compte) à la plateforme. Le ta-
bleau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des
post-conditions, des scénarios principaux et alternatifs de ce cas d’utilisation.
40

Cas d’utilisation S’authentifier
Acteur principal Internaute
Pré-conditions L’internaute n’est pas connecté à l’application
Scénario nominal 1.L’internaute accède à la page d’authentification
2.l’internaute saisie son email et son password pour se
connecter
3.L’internaute envoie la demande de connexion
Scénario alternatif 2a.l’internaute accède à la page de création de compte
2b.l’internaute saisie les données de son nouveau
compte
2c.l’internaute envoie la demande de création de
compte
Post-conditions l’internaute sera redirigé vers la page correspondonte
selon le type de son compte
Table 3.1 – Description textuelle du cas d’utilisation « S’authentifier »
3.3.5 Diagramme de séquence « Modifier coordonnées »
La Figure 3.9 décrit le diagramme de séquence de cas d’utilisation « Modifier coordon-
nées » qui nous explique comment la modification des cordonnées sera traité intérigissant
avec les différents objets système.
Figure 3.9 – Diagramme de séquence « Modifier coordonnées »
41

3.3.6 Description textuelle de cas d’utilisation « Modifier coor-
données »
tions impliquées dans le cas d’utilisation « Modifier cordonnées ». Ce cas d’utilisation vise
à permettre aux utilisateurs de modifier les cordonnées personnelles de leurs profils. Le
tableau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des
post-conditions, des scénarios principaux et alternatifs de ce cas d’utilisation.
Cas d’utilisation Modifier coordonnées
Acteur principal Client
Pré-conditions Le client est connecté à l’application ou site web à
travers un compte actif
Scénario nominal 1.Le client accède à la page de modification de profil.
2.Le client modifie les informations de profil qu’il
souhaite mettre à jour.
3.Le client sauvegarde les modifications effectuées.
4.Le service de gestion de clients met à jour les
informations de profil du client dans la base de
données.
Scénario alternatif 2a.Le client ne souhaite pas modifier toutes les
informations de profil et laisse des champs vides.
2b.Le client rencontre une erreur lors de la modification
des informations de profil et reçoit un message d’erreur.
Post-conditions Les informations de profil du client sont mises à jour
dans la plateforme.
Table 3.2 – Description textuelle du cas d’utilisation « Modifier cordonnées »
3.3.7 Diagramme de séquence « Consulter les réclamations »
La Figure 3.10 décrit le diagramme de séquence de cas d’utilisation « Consulter les
réclamations » qui nous explique comment l’admin peut consulter les réclamations en
illustrant les interactions avec les différents objets système.
42

Figure 3.10 – Diagramme de séquence« Consulter les réclamations »
3.3.8 Description textuelle de cas d’utilisation « Consulter les
réclamations »
tions impliquées dans le cas d’utilisation « Consulter les réclamations ». Ce cas d’utili-
sation vise à permettre aux administrateurs de consulter les réclamations envoyées par
des clients ou des vendeurs. Le tableau qui suit fournit une vue détaillée des acteurs
impliqués, des pré-conditions, des post-conditions, des scénarios principaux et alternatifs
de ce cas d’utilisation.
Cas d’utilisation Consulter les reclamations
Acteur principal Administrateur
Pré-conditions L’administrateur est connecté à la plateforme .
Scénario nominal 1.L’administrateur accède à la page de gestion des
signalements.
2.L’administrateur demande d’afficher les réclamations.
3.Le système affiche les réclamtions.
4.L’administrateur consulte les réclamations.
Scénario alternatif 4a.L’administrateur choisit de supprimer ou pas la
réclamation consulté.
4b.L’administrateur choisit de filtrer les réclamations
selon la date.
Post-conditions Les réclamations sont afficheé par le système.
Table 3.3 – Description textuelle du cas d’utilisation« Consulter les réclamations »
43

3.3.9 Diagramme de composant « Gestion des utilisateurs »
La figure ci dessous contient le diagramme de composant de service gestion des
utilisateurs, il met l’accent sur les différentes parties qui composent le services « Gestion
des utilisateurs ».
Figure 3.11 – Diagramme de composant « Gestion des utilisateurs »
44

3.3.10 L’architecture logicielle de Microservice « Gestion des
utilisateurs »
La figure 3.12 représente l’architecture logicielle de Microservice « Gestion des utili-
sateurs ».
l’objectif de cette représentation est de fournir une compréhension visuelle de l’inter-
action du Microservice "Gestion des utilisateurs" avec les autres composants du système.
Elle met en évidence les connexions et les relations entre le microservice et les autres
composants :
• L’API Gateway, en tant que composant central de notre architecture, joue le rôle
de point d’entrée principal pour les requêtes des clients.
• Conteneur RabbitMQ pour la communication asynchrone entre les différents ser-
vices.
• Le conteneur de la base de données est responsable du stockage et de la persistance
des données du système.
Figure 3.12 – Architecture logicielle de microservice « Gestion des utilisateurs »
3.4 Microservice de « Gestion des produits »
La conception du service de gestion des produits constitue une étape cruciale de
notre architecture microservices. Ce service est chargé de gérer toutes les fonctionnalités
liées aux produits proposés sur notre marketplace.
45

3.4.1 Diagramme de Cas d’utilisation associés au microservice
« Gestion des Produits »
La figure 3.13 illustre un diagramme de cas d’utilisation qui contient les principaux
fonctionnalitées du microservices « Gestion des Produits ».
Figure 3.13 – Diagramme de cas d’utilisation associés au microservice « Gestion des
produits »
46

3.4.2 Description détaillée des cas d’utilisations associé au mi-
croservices « Gestion des Produits »
Dans cette section nous allons présenter une description textuelle de quelques cas
d’utilisation
Cas
d’utilisation
Acteur Description
Evaluer un
produit
Client Permet aux clients de soumettre des évaluations pour
un produit donné, en fournissant une note et un
commentaire.
Consulter les
produits
Client Consiste à fournir aux utilisateurs une vue d’ensemble
des produits disponibles, en affichant des détails tels
que les images, les descriptions, les prix et les
évaluations .
Rechercher
un produit
Client Permet aux clients de rechercher des produits en
fonction de différents critères tels que le nom, le prix,
la catégorie, etc .
Gérer panier Client Permet aux clients d’ajouter des produits à son panier
en vue d’un achat ultérieur. De plus, l’utilisateur a la
capacité de supprimer des produits et modifier la
quantité .
Gérer les
stocks
Vendeur Le vendeur peut surveiller les niveaux de stock de ses
produits, mettre à jour les quantités disponibles en
fonction des ventes ou des arrivées de nouveaux stocks,
et recevoir des notifications lorsque les niveaux de
stock sont bas.
Ajouter un
produit
Vendeur,
Admin
Consiste à ajouter un nouveau produit à la vente sur la
Marketpalce .
Modifier un
produit
Vendeur,
Admin
Permet aux vendeurs, Administrateurs de mettre à
jour les informations d’un produit existant, telles que
le prix, la quantité en stock, la description, les images,
etc .
Supprimer
un produit
Vendeur,
Admin
Cette fonctionnalité permet aux vendeurs,
Administrateurs de supprimer un produit qui n’est
plus disponible à la vente.
Gérer les
avis
Admin L’administrateur peut modérer les évaluations et les
commentaires pour s’assurer qu’ils sont pertinents et
utiles pour les autres utilisateurs.
Gérer les
catégories
Admin permettre aux administrateurs de gérer les catégories
de produits disponibles, Ils peuvent créer de nouvelles
catégories, modifier ou supprimer des catégories
existantes .
Table 3.4 – Les cas d’utilisation associés au microservice « Gestion des produits »
47

3.4.3 Diagramme de séquence « Ajouter produit »
La Figure ci-dessous décrit le diagramme de séquence de cas d’utilisation « Ajouter
un produit » qui nous explique comment le vendeur peut ajouter son nouveau produit
dans la platforme en illustrant les interactions avec les différents objets système.
Figure 3.14 – Diagramme de séquence « Ajouter un produit »
3.4.4 Description textuelle du cas d’utilisation « Ajouter un
produit »
La description textuelle suivante présente en détail les différentes étapes et inter-
actions impliquées dans le cas d’utilisation « Ajouter un produit ». Ce cas d’utilisation
permet aux vendeurs d’ajouter un produit. Le tableau qui suit fournit une vue détaillée
des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux
48

et alternatifs de ce cas d’utilisation.
Cas
d’utilisation
Ajouter un produit
Acteur
principal
Vendeur
Pré-
conditions
Le vendeur est connecté à la plateforme avec un
compte actif et a accès à la page d’ajout de produit.
Scénario
nominal
1.Le vendeur accède à la page d’ajout de produit.
2.Le vendeur entre les détails du produit, y compris le
nom, la description, les images et le prix.
3.Le vendeur choisit une catégorie appropriée pour le
produit.
4.Le vendeur sauvegarde le produit.
5.Le service de gestion de produits vérifie que toutes les
informations obligatoires ont été saisies correctement.
6.Le produit est ajouté à la liste des produits
disponibles sur la plateforme de microservices de place
de marché.
Scénario
alternatif
5a Le service de gestion de produits détecte des
informations manquantes ou incorrectes et demande au
vendeur de les corriger avant de pouvoir ajouter le
produit.
Post-
conditions
Le produit est ajouté à la liste des produits disponibles
sur la plateforme de microservices de place de marché
et est visible pour les acheteurs potentiels. Le vendeur
peut également accéder au produit pour le modifier ou
le supprimer si nécessaire.
Table 3.5 – Description textuelle du cas d’utilisation « Ajouter Produit »
3.4.5 Diagramme de séquence « Evaluer produit »
La Figure 3.15 représente le diagramme de séquence de cas d’utilisation « Evaluer
un produit » qui nous explique comment le client peut attribuer une note à un produit
dans la platforme en illustant les interactions avec les différents objets système.
49

Figure 3.15 – Diagramme de séquence « Evaluer produit »
3.4.6 Description textuelle du cas d’utilisation « Evaluer pro-
duit »
tions impliquées dans le cas d’utilisation « Evaluer produit ». Ce cas d’utilisation permet
aux clients de notter un produit. Le tableau qui suit fournit une vue détaillée des acteurs
impliqués, des pré-conditions, des post-conditions, des scénarios principaux et alternatifs
de ce cas d’utilisation.
50

Cas d’utilisation Evaluer produit
Pré-conditions Le client est connecté à la plateforme avec un compte
actif
Scénario nominal 1.Le client accède à la page de notation et de
commentaire du produit.
2.Le client donne une note (sur 5) et un commentaire
pour le produit.
3.Le service de gestion des produit vérifie que la
notation et le commentaire sont conformes aux règles
de la plateforme
5.Le service de gestion des produits ajoute la note au
produit
Scénario alternatif 2a.Si le client a noté deja le produit il modifie son
ancien note ou le supprime.
3a.Si la notation ou le commentaire ne respecte pas les
règles de la plateforme le service de gestion des
produits demande au client de les modifier.
Post-conditions La notation et le commentaire sont publiés/supprimé
sur la page du produit pour les autres clients à voir.
Table 3.6 – Description textuelle du cas d’utilisation « Evaluer produit »
3.4.7 Diagramme de composant associé au microservice « Ges-
tion des produits »
La figure ci dessous contient le diagramme de composant de service Gestion des
produits, il met l’accent sur les différentes parties qui composent le services « Gestion des
utilisateurs ».
51

Figure 3.16 – Diagramme de composant associé au microservice « Gestion des produits »
3.4.8 L’architecture logicielle de microservice « Gestion des pro-
duits »
La figure 3.17 présente l’architecture logicielle de microservice Gestion des produits
l’objectif de cette représentation est de fournir une compréhension visuelle de l’in-
52

teraction du Microservice "Gestion des produits" avec les autres composants du système.
Figure 3.17 – Architecture logicielle de microservice « Gestion des produits »
3.5 Microservice de « Gestion des commandes »
Dans le contexte des microservices, le service de gestion des commandes peut être
traité comme un service autonome, responsable de toutes les opérations liées à la gestion
des commandes.
3.5.1 Diagramme de cas d’utilisation associé au microservice
« Gestion des commandes »
Figure 3.18 – Diagramme de cas d’utilisation associé au Microservice « Gestion des
commendes »
53

3.5.2 Description détaillée des cas d’utilisation associé au mi-
croservice « Gestion des commandes »
Dans cette section nous allons présenter une description de quelques cas d’utilisation
Cas
d’utilisation
Acteur Description
Passer une
commande
Client Le client peut passer une nouvelle commande en
sélectionnant les produits souhaités, en fournissant les
informations de livraison
Consulter
l’historique
des
commandes
Client Le client peut consulter l’historique de ses commandes
précédentes, y compris les détails de chaque
commande, l’état actuel, les produits commandés et les
informations de livraison.
Suivre l’état
de la
commande
Client Le client peut suivre l’état en temps réel de sa
commande, de la préparation à la livraison. Il peut
savoir à quelle étape se trouve sa commande et obtenir
des mises à jour sur son statut.
Gérer les
commandes
entrantes
Vendeur Le vendeur peut consulter les commandes entrantes, y
compris les détails des produits commandés, les
informations de livraison et les coordonnées du client.
Le vendeur peut prendre les mesures nécessaires pour
traiter et préparer les commandes.
Mettre à
jour l’état de
la commande
Vendeur Le vendeur peut mettre à jour l’état des commandes en
fonction de leur progression
Table 3.7 – Tablau des cas d’utilisation associés au microservice « Gestion des com-
mendes »
3.5.3 Diagramme de séquence « Passer une commande »
La Figure 3.18 et la tableau 3.8 décrivent le diagramme de séquence de cas d’uti-
lisation « Passer une commande » qui nous explique comment le client peut passer une
commande dans la platforme en illustrant les interactions avec les différents objets sys-
tème.
54

Figure 3.19 – Diagramme de sequence « Passer une commande »
55

3.5.4 Description textuelle du cas d’utilisation « Passer une
commande »
tions impliquées dans le cas d’utilisation « Passer une commandet ». Ce cas d’utilisation
permet aux clients de passer une commande. Le tableau qui suit fournit une vue détaillée
des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux
et alternatifs de ce cas d’utilisation.
Cas d’utilisation Passer une commande
Pré-conditions Le client est connecté à la plateforme de commerce
électronique et a des produits dans son panier.
Scénario nominal 1.Le client sélectionne les produits dans son panier.
2.Le client fournit les informations de livraison
3.Le client choisit une option de paiement
4.Le client confirme la commande
5.Le système de gestion des commandes vérifie la
disponibilité des produits chez les vendeurs respectifs.
6.Le système de gestion des commandes enregistre la
commande pour chaque vendeur.
7.Le client reçoit une confirmation de commande.
Scénario alternatif 2a.Le client modifie les informations de livraison ou
choisit une autre option de livraison.
5a.L’un des produits sélectionnés par le client n’est pas
disponible.
Post-conditions La commande est enregistrée dans le système pour
chaque vendeur, les paiements sont traités, et le client
reçoit une confirmation de commande. Les vendeurs
sont notifiés des commandes et prêts à traiter et
expédier les produits commandés.
Table 3.8 – Description scénariste du cas d’utilisation « Passer une commande »
3.5.5 Diagramme de composant associé au microservice « Ges-
tion des produits »
La figure 3.20 représente le diagramme de composants du microservice de gestion de
commandes. Ce diagramme met en évidence les différents composants et leur intercon-
nexion, permettant de comprendre la structure et l’organisation du service de gestion des
commandes. Il montre comment les différents composants du système se connectent et
56

interagissent pour assurer le bon fonctionnement du service de gestion des commandes.
Figure 3.20 – Diagramme de composant associé au microservice « Gestion des com-
mandes »
57

3.5.6 L’architecture logicielle de microservice « Gestion des com-
mandes »
La figure 3.21 présente l’architecture logicielle de microservice « Gestion des com-
mandes »
Le composant Message Broker est responsable de la communication avec les autres
microservices
Figure 3.21 – Architecture logicielle de microservice « Gestion des produits »
Conclusion
Dans le chapitre de conception de notre projet, nous avons adopté une approche de
conception en microservices. Cette approche nous a permis de diviser notre application en
plusieurs services indépendants, chacun se concentrant sur une fonctionnalité spécifique.
Dans le chapitre de la réalisation qui suivra, nous mettrons en œuvre la conception que
nous avons élaborée. Nous aborderons les détails techniques de la mise en place des
microservices et les interfaces web et mobile .
58

Chapitre 4
Réalisation
Introduction
Dans ce chapitre, nous aborderons en détail les aspects pratiques de la mise en place
de notre solution, on va présenter l’environnement matériel et logiciel ainsi que les outils
de développement.
4.1 Environnement de développement
Dans cette partie, nous présentons les différents outils matériels et logiciels néces-
saires pour le développement de notre application.
4.1.1 Environnement matériel
Pour la réalisation de ce projet on a disposé d’ :
1. Un ordinateur :
• Marque Dell
• Processeur : 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
• RAM : 12 GO
• Système d’exploitation : Windows 10
59

CHAPITRE 4. RÉALISATION
2. Un ordinateur :
• Marque Dell
• Processeur : 8th Gen Intel(R) Core(TM) i7-8650U @2.10GHz
• RAM : 16 GO
• Système d’exploitation : Windows 10
4.1.2 Environnement logiciel
Cette section décrit l’environnement logiciel avec lequel nous avons réalisé ce projet
.
Figure 4.1 – Visual Studio Code
Visual Studio Code : est un éditeur de code source léger, mais puissant, qui s’exécute
sur votre bureau et est disponible pour Windows, macOS et Linux[12].
Figure 4.2 – Git
Git : est un système de contrôle de version distribué et open-source largement utilisé
pour le suivi des modifications apportées aux fichiers et aux projets de développement
logiciel[13].
Figure 4.3 – Docker
Docker : est une plateforme open-source qui permet de créer, de déployer et d’exécuter
des applications dans des conteneurs[14].
60

Figure 4.4 – Postman
Postman : est un outil populaire utilisé par les développeurs pour tester, documenter
et collaborer sur les API (Interfaces de programmation d’application)[15].
Figure 4.5 – Swagger
Swagger (OpenAPI Specification) est un ensemble de spécifications et d’outils pour
concevoir, documenter et tester des API RESTful.
Figure 4.6 – Nginx
Nginx : est un serveur web léger, performant et open-source, ainsi qu’un proxy
inverse[16].
Figure 4.7 – LYX
Pour rédiger ce rapport, nous avions utilisé LyX pour cette tâche, c’est un éditeur
de texte gratuit, open source et multiplateforme qui permet l’édition de texte à base de
LaTeX [17].
61

Figure 4.8 – LucidChart
LucidChart est un outil pour créer des diagrammes,des figures et des illustrations[18].
Figure 4.9 – RabbitMQ
RabbitMQ est un courtier de messages open-source qui permet à différents systèmes
logiciels de communiquer et d’échanger des messages. Il met en œuvre le protocole de
messagerie avancée (AMQP), qui est un protocole standardisé pour la messagerie entre
applications.[19].
4.2 Présentation de la solution
Cette partie dédiée à la mise en valeur de notre solution, nous explorons en détail
les aspects clés qui la composent. Nous abordons la solution web, la solution mobile et la
réalisation des microservices, mettant en évidence leur importance et leur contribution à
l’expérience utilisateur. Chaque sous-partie apporte une dimension unique à notre solu-
tion, créant ainsi une plateforme attrayante, conviviale et évolutive pour nos utilisateurs.
4.2.1 Présentation de la solution web
Cette partie présente certaines interfaces de l’application Web et montre les carac-
téristiques les plus importantes de notre travail.
62

La page d’acceuil
L’utilisateur a un accès à l’application via la page d’acceuil, il peut naviguer dans les
produits, les catégories, effectuer une recherche sur un produit spécifique une boutique,
ou une catégorie, il peut aussi s’authentifier et ajouter des produits à un panier et com-
mander ces produits. La figure 4.10 présente l’interface d’acceuil implémentée dans notre
application web.
Figure 4.10 – Interface d’acceuil Web
La page de commande
L’utilisateur peut consulter les produits ajoutées au panier il peut les modifier en
supprimant quelques-uns ou en augmentant leurs quantité. Il peut aussi passer une com-
mande avec les produits du panier en ajoutant son adresse et en passant par le payement.
La figure 4.11 ci-dessous présente l’interface de commande implémentée dans notre ap-
plication web.
63

Figure 4.11 – Interface d’acceuil Web
La page de création de compte
L’interface de création de compte dans notre projet offre une expérience conviviale
et intuitive pour les utilisateurs. Elle permet aux visiteurs d’accéder rapidement à la
fonctionnalité d’inscription en fournissant les informations nécessaires(tels que le nom
complet, l’adresse e-mail, le mot de passe, et d’autres informations pertinentes) pour
créer un compte personnel. La figure 4.12 présente l’interface de création de compte
implémentée dans notre application web.
Figure 4.12 – Interface SignIn Web
64

La page se connecter
La page de connexion est conçue de manière à ce que les utilisateurs puissent accéder
rapidement à leur compte personnel en fournissant leurs informations d’identification(leur
adresse e-mail, ainsi que leur mot de passe associé). La figure 4.13 ci-dessous présente
l’interface de connexion au compte implémentée dans notre application web dans le cas
ou l’utilsateur a un compte.
Figure 4.13 – Interface Login Web
La page de l’espace vendeur
Chaque vendeur a un espace composé d’un ensemble des fonctionalités(services) tel
qu’un affichage de ses produits, l’ensembles des commandes recus , les cordonnées de son
boutique ,etc. Cette interface est accessible au utilisaeur via
La figure 4.14 présente l’interface de l’espace vendeur implémentée dans notre appli-
cation web.
65

Figure 4.14 – Interface vendeur-dashboard
4.2.2 Présentation de la solution Mobile
Cette partie présente certaines interfaces de l’application Mobile et montre les ca-
ractéristiques les plus importantes de notre travail.
La page d’authentification
Pour qu’un utilisateur ait un accès à l’application, une phase d’authentification est
nécessaire.
1. L’interface de connexion capturée présente un formulaire de connexion élégant et
simple. L’écran affiche un champ pour l’adresse e-mail et un champ pour le mot
de passe.
2. L’interface d’inscription capturée présente un formulaire convivial permettant aux
utilisateurs de créer un nouveau compte. L’écran propose des champs pour saisir
les informations nécessaires, tels que le nom, l’adresse e-mail, le mot de passe et
numéro de téléphone.
3. L’interface de vérification d’e-mail capturée est conçue pour permettre aux utili-
sateurs de confirmer leur adresse e-mail après leur inscription.
66

La figure 4.15 ci-dessous présente les interfaces d’authentification implémentée dans notre
application.
Figure 4.15 – Interface authentification application mobile.
Lorsque les utilisateurs saisissent des identifiants incorrects ou rencontrent un pro-
blème de connexion, un message d’erreur clair et concis est affiché à l’écran. Ce message
les informe de la nature de l’erreur et les invite à vérifier leurs informations de connexion.
La figure 4.16 ci-dessous illustre cette interface d’erreur.
67

Figure 4.16 – Authentification cas d’erreur
Page d’accueil
Dans notre application MarketHive, la page d’accueil est conçue pour offrir aux
utilisateurs un aperçu complet des produits disponibles, des catégories et des publicités.
La figure 4.17 ci-dessous présente l’interface de la page d’accueil.
Figure 4.17 – Interface d’accueil application mobile
68

Interface catégorie
L’interface des catégories dans notre application est conçue pour permettre aux uti-
lisateurs de naviguer facilement parmi les différentes catégories de produits disponibles.
1. Au sommet de l’interface, vous trouverez une vue en liste affichant les catégories
parentes. Chaque catégorie est représentée par son nom .
2. Lorsque vous cliquez sur l’une des catégories parentes, l’interface se met à jour pour
afficher les sous-catégories associées à cette catégorie. Cela permet de présenter une
hiérarchie des catégories.
3. lorsque vous cliquez sur l’une des sous-catégories présentées dans l’interface pré-
cédente. Elle présente une grille (grid view) de produits liés à cette sous-catégorie
spécifique. Chaque produit est représenté par une image, un nom, un prix et un
notation. La figure 4.18 ci-dessous présente cette interface.
Figure 4.18 – Interface catégorie application mobile
Interface produit
L’interface de détails du produit offre une vue détaillée et complète d’un produit
spécifique. Elle est organisée de manière à fournir toutes les informations nécessaires aux
utilisateurs pour prendre une décision d’achat éclairée. La figure 4.19 ci-dessous présente
cette interface.
69

Conception et développement d'une marketplace basée sur l'architecture microservices

Conception et développement d'une marketplace basée sur l'architecture microservices

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Conception et développement d'une marketplace basée sur l'architecture microservices

Similaire à Conception et développement d'une marketplace basée sur l'architecture microservices (20)

Dernier

Dernier (20)

Conception et développement d'une marketplace basée sur l'architecture microservices