Memoire 1
Memoire 1
Memoire 1
Octobre 2023
REPUBLIQUE DEMOCRATIQUE DU CONGO
NUMBI/WA KYUNGU/ENOCK
Promotion : BAC 3 IG
Matricule : 2020022169
Octobre 2023
DEDICACE
i
REMERCIEMENT
Le présent travail n'est pas seulement le fruit de nos propres efforts, mais aussi les efforts de bien
de personnes à qui nous exprimons nos vifs remerciements.
Nous ne pouvons pas terminer, sans remercier à nos camarades de promotion qui n'ont cessé de
nous encourager au cours de notre parcours estudiantin.
Enfin, à tous ceux qui de près ou de loin ont contribué moralement ou matériellement à
l'aboutissement de ce travail. Nous disons merci.
ii
TABLE DE MATIERE
INTRODUCTION .......................................................................................................................... 10
iii
2.0.2. Diagramme de processus métier .................................................................... 34
3.1.2 3.1.2. Planification des itérations grâce aux cas d’utilisation ............................... x
3.2.1 xvi
3.2.3 Suivant la description textuelle du cas d’utilisation « créer compte client, l’acteur
client interagit avec le système : ................................................................... xvii
iv
b) Diagramme de séquences système d’authentification ...................................... xvii
3.2.7. Diagramme de classes participantes du cas d’utilisation «Créer compte client» xxvii
Introduction xxxix
v
L'objectif de cette recherche était de confirmer ou d'infirmer les hypothèses
suivantes : .......................................................................................... xxxix
Recommandations ......................................................................................................... xl
vi
LISTE DES FIGURES
vii
Figure 20—Diagramme de séquences système du cas d’utilisation « Mettre à jour le
catalogue ............................................................................................. xix
viii
Figure 34—diagramme de séquences détaillées de l’opération système « éditer un article
»........................................................................................................ xxxv
ix
INTRODUCTION
Vue les réalités du monde actuels et les problèmes au quelle le monde fait face toute entreprises
qui projette à un rendement incomparable et un service plus performent, l’apport de l’outil
informatique s’avérer indispensable pour réaliser ses rêve. Il est vrai qu’une organisation doit
avoir une bonne gestion aussi qu’un bon fonctionnement afin d’atteindre certains objectifs
qu’elle se fixe.
Cette évolution technologique a stimulé des mutations profondes dans le secteur économique
des entreprises et la création d’une nouvelle économie ou d’un nouveau marché dit «marché
virtuel». Ce nouveau commerce à travers Internet se démontre par une croissance très rapide,
touchant des secteurs importants de l’économie: distribution, secteur bancaire, secteur
touristique et hôtelier. Désormais, les chances de développement du commerce électronique
dans un secteur économique sont fortement influencées par ses capacités à apporter des
avantages concurrentiels aux divers acteurs économiques.
1.1.1 Concept 1
1.1.2 Concept 2
1. Expérience Utilisateur : L'expérience utilisateur est cruciale pour le succès d'une plate-
forme e-commerce dans le secteur vestimentaire. La recherche doit se concentrer sur la
10
conception d'interfaces utilisateur conviviales, la personnalisation, les évaluations de
convivialité et les retours des utilisateurs.
1.1.3 Concept 3
Gestion des Commandes et des Stocks : Comprendre les processus de gestion des
commandes, de gestion des stocks et de traitement des retours est essentiel pour garantir une
efficacité opérationnelle. Cela peut inclure la gestion des tailles, des couleurs et des variantes
de produits.
2. Quels sont les besoins métier spécifiques du secteur vestimentaire en ce qui concerne la
gestion des produits, des stocks, des commandes et des paiements ?
3. Comment concevoir une interface utilisateur conviviale et personnalisée pour les clients
cherchant des vêtements en ligne, en intégrant éventuellement des fonctionnalités telles que
l'essai virtuel ?
4. Quelles sont les meilleures pratiques en matière de sécurité des données pour protéger les
informations personnelles et financières des clients lors des transactions en ligne ?
5. Quels sont les choix technologiques et les Framework les plus adaptés pour le développement
d'une plate-forme e-commerce dans le domaine vestimentaire ?
7. Comment appliquer efficacement la méthode Unified Process (UP) pour gérer le projet de
conception et de développement de la plate-forme e-commerce de manière itérative et
contrôlée ?
8. Quelles stratégies de marketing en ligne sont les plus appropriées pour attirer et fidéliser les
clients dans l'industrie de la mode en ligne ?
11
9. Comment garantir la scalabilité et l'évolutivité de la plate-forme pour faire face à la croissance
des utilisateurs et des produits ?
10. Quelles méthodes d'évaluation peuvent être utilisées pour mesurer et améliorer la
performance de la plate-forme e-commerce une fois qu'elle est en production ?
Bien qu'il existe de nombreuses solutions e-commerce dans le domaine vestimentaire, elles
présentent des avantages et des limitations. Concevoir une nouvelle plate-forme e-commerce
dans ce secteur nécessite une analyse minutieuse des besoins métier spécifiques pour répondre
aux défis tout en tirant parti des leçons apprises des solutions existantes.
2. Marchés en Ligne : Des marchés en ligne tels qu'Amazon, eBay et Alibaba permettent aux
vendeurs de mode de lister leurs produits et d'atteindre un public mondial sans avoir à créer
leur propre site web. Cependant, ces marchés ont des règles strictes et des frais associés.
4. Solutions D2C (Direct-to-Consumer) : Les marques de mode D2C se tournent vers des
solutions e-commerce pour établir des relations directes avec leurs clients, éliminant ainsi les
intermédiaires. Cela nécessite des fonctionnalités spécifiques, telles que la personnalisation.
1. Coûts Élevés : Certaines plateformes e-commerce établies ont des coûts mensuels élevés,
ainsi que des frais de transaction. Cela peut représenter une charge financière pour les petites
entreprises.
2. Personnalisation Limitée : Les solutions prêtes à l'emploi peuvent avoir des limites en
termes de personnalisation de l'interface utilisateur, de fonctionnalités spécifiques à l'industrie
de la mode, et de flexibilité.
12
3. Dépendance aux Tiers : L'utilisation de marchés en ligne signifie souvent une dépendance à
l'égard de tiers pour les règles de la plateforme, la visibilité et les frais.
6. Expérience Client : Les plateformes existantes peuvent parfois ne pas offrir une expérience
utilisateur optimale pour la recherche de produits, l'essai virtuel ou les recommandations de
produits personnalisées.
7. Durabilité : Les plateformes existantes peuvent ne pas intégrer efficacement des pratiques
durables pour répondre à la demande croissante de mode éthique et responsable.
Toutefois, il est important de noter que cette étude est délimitée à plusieurs égards afin de cibler
efficacement le sujet et de garantir sa pertinence. Les délimitations suivantes sont énoncées
pour orienter la portée de cette recherche :
2. Méthode UP : Nous utilisons la méthode Unified Process (UP) comme principal cadre
méthodologique pour l'analyse et la conception. D'autres méthodes de développement de
logiciels ne seront pas examinées en profondeur dans cette étude.
3. Conception et Analyse : Notre travail se penche principalement sur la phase d'analyse métier
et de conception de la plate-forme e-commerce. La mise en œuvre et d'autres phases du cycle
de vie du logiciel seront hors du champ d'application.
13
Dans les chapitres à venir, nous plongerons dans l'analyse des besoins métier, la conception de
l'architecture logicielle et les étapes pratiques de la méthode UP pour la création d'une plate-
forme e-commerce performante et compétitive.
L'industrie du commerce électronique a connu une croissance explosive au cours des dernières
années, bouleversant les modèles commerciaux traditionnels et transformant la manière dont
les consommateurs effectuent leurs achats. Parmi les secteurs les plus dynamiques de l'e-
commerce, le domaine vestimentaire occupe une place de choix. L'achat de vêtements en ligne
est devenu courant, offrant aux consommateurs un accès à une variété de styles, de marques et
de tailles, le tout depuis le confort de leur domicile.
14
1.5.2 Objectifs de la recherché
1. Analyse Métier Approfondie : Effectuer une analyse approfondie des besoins et des
exigences métier dans le domaine vestimentaire pour comprendre les défis spécifiques
auxquels les entreprises de mode sont confrontées dans l'environnement e-commerce.
1. Objectif primaire
L’objectif primaire de cette recherche est de créer une plate-forme e-commerce spécifiquement
adaptée au secteur vestimentaire, en utilisant la méthodologie UP comme guide, et de démontrer
comment cette approche peut être bénéfique pour les entreprises opérant dans ce domaine.
L'objectif est de fournir des contributions pratiques et une compréhension approfondie du
processus d'analyse métier et de conception dans le contexte du commerce électronique
vestimentaire
2. Objectif secondaire
15
2. Analyse des Tendances de la Mode : Intégrer une analyse des tendances de la mode
actuelles dans la conception de la plate-forme e-commerce, en mettant en évidence comment
ces tendances influencent les choix de conception et les fonctionnalités de la plate-forme.
3. Mesure de la Performance : Établir des indicateurs clés de performance (KPI) pour évaluer
l'efficacité de la plate-forme e-commerce dans le secteur vestimentaire, notamment en ce qui
concerne la conversion des visiteurs en clients, la rétention des clients, et les taux de
conversion par rapport aux produits vestimentaires.
6. Analyse des Rétroactions des Utilisateurs : Collecter et analyser les commentaires et les
réactions des utilisateurs de la plate-forme pour identifier des améliorations potentielles et des
opportunités d'optimisation continue.
1. Revue de la Littérature
Commencez par une revue de la littérature pour comprendre les tendances actuelles du
commerce électronique dans le secteur vestimentaire. Identifiez les principaux défis et
opportunités.
2. Collecte de Données
16
Collectez des données pertinentes sur le secteur vestimentaire, y compris les données de
marché, les statistiques de vente en ligne, les préférences des consommateurs et les tendances
de la mode actuelles.
3. Analyse des Besoins Métier
Utilisez des méthodes de collecte de données telles que des entretiens avec des experts de
l'industrie et des questionnaires pour analyser les besoins métier spécifiques du secteur
vestimentaire en matière de commerce électronique.
4. Conception de la Plate-forme E-commerce
Documentez de manière exhaustive toutes les étapes de la recherche, y compris l'analyse des
besoins métier, la conception de la plate-forme, les résultats de validation, et les leçons
apprises.
8. Analyse des Résultats
Analysez les résultats de la recherche pour déterminer dans quelle mesure la méthode UP est
efficace pour la conception d'une plate-forme e-commerce dans le domaine vestimentaire.
Identifiez les avantages, les limitations et les domaines d'amélioration potentiels.
9. Recommandations et Implications Pratiques
17
La méthodologie décrite ci-dessus devrait vous permettre de mener une recherche approfondie
et systématique, tout en utilisant la méthode UP comme cadre pour l'analyse métier et la
conception de la plate-forme e-commerce. N'oubliez pas d'adapter cette méthodologie en
fonction de vos ressources et de vos besoins spécifiques de recherche.
Ce travail est subdivisé en chapitres et ils sont en leurs tournes sont subdivisés en
différentes parties :
; dans ce chapitre il est question d’établir un contexte solide et comprendre les travaux antérieurs
liés à notre sujet.
Le second chapitre ; parlera de l’analyse métier de la vente de vêtements chez DEV MODE. Il
s’agit donc de faire connaitre les processus de vente existant et d’en tirer des conclusions sur la
poursuite ou non du projet. *
18
REVUE DE LITERATURE.
1.8 INTRODUCTION
Cette revue de littérature vise à établir un cadre conceptuel solide pour comprendre les enjeux
clés liés à l'analyse métier et à la conception de plateformes e-commerce dans le domaine
vestimentaire, en mettant l'accent sur l'application de la méthodologie Unified Process (UP).
Cette méthodologie, axée sur l'architecture logicielle et le développement itératif, offre un cadre
structuré pour répondre aux besoins complexes des entreprises du secteur vestimentaire.
Explorez les tendances actuelles qui façonnent le commerce électronique dans le secteur
vestimentaire. Cela peut inclure des sujets tels que la personnalisation des achats en ligne, les
technologies de réalité augmentée pour l'essayage virtuel, la durabilité et la mode éthique, la
gestion des retours, ainsi que l'influence des médias sociaux sur les tendances de la mode en
ligne.
19
Analysez différentes méthodologies de conception de plate-forme e-commerce, en mettant
l'accent sur la méthode Unified Process (UP). Comparez UP à d'autres méthodologies de
développement logiciel courantes telles qu'Agile et Waterfall, en identifiant les avantages
spécifiques d'UP pour la conception de plateformes e-commerce dans le domaine vestimentaire.
Explorez comment les entreprises du secteur vestimentaire abordent l'analyse des besoins
métier pour leurs plateformes e-commerce. Mettez en évidence les défis spécifiques tels que la
gestion des stocks, la gestion des tailles et des modèles, la personnalisation des
recommandations de produits, etc.
En raison de la sensibilité des données personnelles des clients, examinez les questions de
sécurité et de confidentialité des données dans le commerce électronique vestimentaire. Incluez
des informations sur les réglementations telles que le RGPD (Règlement général sur la
protection des données) et leur impact sur la collecte et le traitement des données client.
Analysez comment les plateformes e-commerce dans le secteur vestimentaire recueillent les
commentaires des utilisateurs et les intègrent dans leurs processus d'amélioration continue.
Cette revue de littérature devrait vous aider à établir un cadre conceptuel solide pour votre
recherche et à identifier les lacunes dans la littérature existante que vous pourriez explorer dans
20
votre propre étude. Assurez-vous de citer correctement toutes les sources et de les intégrer dans
votre recherche pour étayer vos conclusions
Le cœur de l’architecture technique du Web est le protocole HTTP, qui repose sur un
modèle client-serveur.
Cette architecture est très classique et n’est pas née avec le Web, mais on doit plus
précisément parler d’un serveur et de multiples clients qui s’y connectent. Sur le Web, et dans
HTTP, les serveurs sont conçus pour communiquer systématiquement avec de multiples clients.
On rappelle qu’il est très fréquent qu’un même client parle avec différents serveurs pour des
tâches très courantes, comme la consultation de pages Web dans un navigateur, qui nécessite
de charger des contenus sur différents serveurs HTTP indépendants.
21
Figure 2—Hypertext Transfert Protocol
(a) Le client (navigateur) fait une requête d’accès à une ressource auprès d’un serveur
Web selon le protocole http
Comment : HTTP comme protocole de communication pour un client souhaitant faire des
actions sur les ressources hébergées sur un serveur On parle en fait plutôt d’URI que d’URL
dans les spécifications, même si pour l’instant cette subtilité a peu d’importance.
22
Les ressources référencent d’autres ressources (attribut href dans HTML)
Parcourir la toile :
(d) recommencer …
Les applications Web sont ubiquitaires aujourd’hui, mais on n’a pas forcément toujours
des idées très claires sur ce qui permet de faire fonctionner ces applications. Cette séquence va
nous permettre d’examiner les mécanismes et protocoles nécessaires au fonctionnement d’une
application Web.
- couche de présentation ;
- couche de traitement ;
- couche d’accès aux données.
23
Figure 3—Architecture 3 tiers
24
Faible testabilité du logique métier. Si cette logique est liée à la base de données et au
client, il sera alors très difficile d'écrire des tests automatisés qui puissent être exécutés en
quelques secondes. Si tous les développeurs perdent plusieurs minutes pour vérifier que la
suite de test
Choix techniques erronés. Avec une mauvaise architecture il est impossible de revenir en
arrière comme expliqué dans le point précédent. Si un choix technique se trouve être bloquant
durant le développement, revenir en arrière sera impossible et le projet devra être repris à
partir de zéro.
Duplication du code. Sans architecture cohérente, la duplication de code sera inévitable. Par
exemple, deux éléments de l'application voudront faire la même chose mais l'architecture ne
le permettra pas, la duplication sera la seule solution. Il faut éviter cela à tout prix
En général quand on développe une application web, on utilise une architecture trois
tiers (ou trois couches) incluant : l'interface utilisateur, la logique métier, et l'accès aux
données[4].
25
Les contrôleurs incluent les actions effectuées par les utilisateurs
En séparant le code d'une application web de cette manière, l'accès aux données est
totalement séparé du reste de l'application. Sans dépendance à l'interface utilisateur ou à la
logique des actions de l'utilisateur, il est bien plus simple d'écrire des tests automatisés. De
plus, la duplication de code sera considérablement amoindrie.
Mais ce pattern n'est pas parfait. Premièrement les contrôleurs et les vues restent liés
et un changement d'un côté entrainera souvent un changement de l'autre. De plus, si des
changements d'infrastructure interviennent, comme des modifications de base de données, il
faudra probablement réécrire une partie importante du code. Ces évolutions sont normalement
rares, mais cela arrivera sûrement à un moment ou à un autre.
Pour gagner en maintenance et en évolutivité il peut être nécessaire d'avoir une
architecture où l'infrastructure n'est pas liée aux modèles :
En plus des avantages déjà présents avec le pattern MVC, les changements techniques
vont pouvoir intervenir rapidement et efficacement et des choix techniques problématiques vont
pouvoir être corrigés avec une perte de temps minimum.
26
Figure 5—Architecture Clean
Les applications web ont été pendant longtemps, et le sont encore fréquemment
aujourd'hui, des monolithes. Cela signifie que toutes les parties de l'application sont
interconnectées occasionnant ainsi des problèmes techniques[6] :
Mise en production de tout ou rien. En effet si tout est lié, un petit changement sur une
partie du code demande la mise à production de toutes les parties. Mais si d'autres parties ont
des changements en cours, la mise en production est bloquée.
Duplication des interfaces. Dans le cas où des API ouvertes vers l'extérieur existent, ce qui
est souvent le cas, il y a de possibles duplications d'interface. Les mêmes actions doivent être
programmées pour l'API que pour l'interface utilisateur.
Montée en charge. Certaines fonctionnalités ont tendance à avoir des besoins spécifiques
pour la montée en charge. Mais avec un bloc unique, la montée en charge se fait sur toutes
les parties de l'application, même si le besoin n'est présent que sur une seule.
27
20. Architecture Front-end avec Ajax
Asynchrones JavaScript ans XML (Ajax) constitue de nos jours une architecture pour les
applications web utilisant JavaScript pour faire des requêtes au serveur[7]. Le serveur envoyait
une réponse en XML ou JSON qui était utilisé pour modifier le client. Ajax a permis à de
nouvelles classes d'applications web de voir le jour, notamment Google Maps[8]. Pouvoir
appeler le serveur pour modifier le client sans rechargement permet de répondre aux
actions des utilisateurs bien plus rapidement.
Avec des navigateurs toujours plus puissants et avec toujours plus de fonctionnalités, cette
architecture est toujours utilisée même si le terme l'est beaucoup moins. De plus en plus
d'actions ont été déplacées du backend vers le frontend, ce qui a eu pour effet d'ajouter beaucoup
de code sur le frontend ce qui peut facilement devenir un cauchemar à maintenir sans la
bonne architecture.
[7]
Un Single Page Applications (SPA) est donc une application qui utilise le navigateur de
l’utilisateur pour générer la page qu’il doit afficher[9]. Généralement le code s’exécute côté
28
client. Cela permet de naviguer sur toute l’application web sans rechargement de la page.
L’exécution du code côté client est le concept principalement utilisé par les SPA, au moyen du
langage JavaScript et ses différentes librairies. Le terme signifie que le rendu par le serveur est
fait juste une seule fois, pour charger le code JavaScript. Grâce à cette architecture l'interface
utilisateur est plus réactive, se rapprochant des applications natives.
1) Composants individuels : la page entière est divisée en composants plus petits qui
interagissent les uns avec les autres.
29
Figure 7—Technologie SPA
Le front-end des applications web fonctionne dans ce cas comme les applications mobiles,
ce qui va permettre d'éviter la duplication des interfaces et consolider l'API comme source
unique pour tous les clients[9].
Mais avec des SPAs, le back-end va accéder à la base de données non pas pour faire le
rendu de l'interface utilisateur, mais pour renvoyer les données que le client a demandé via
l'API. Cependant une mauvaise architecture de l'API peut avoir des conséquences désastreuses
sur les performances.
30
Le front-end n'étant plus que du HTML, CSS et JavaScript, il n'a plus besoin d'être sur le
même serveur que le back-end. Cela change l'infrastructure et offre plus de libertés au
back-end.
En effet, les différentes parties du back-end peuvent être séparées en services, toutes
hébergées sur différents serveurs adaptés aux besoins de chaque service pour une optimisation
de la montée en charge maximale.
1. Construire
31
implémentations d’une application Web peuvent être fournies par créer de nouveaux services
Web, transformer des applications existantes en services Web, et composer de nouveaux
services Web à partir d'autres services Web et applications.
2. Déployer
3. Tester
Pendant la phase d'exécution, le service Web est disponible pour l'appel. À ce stade, le Web le
service est entièrement déployé, opérationnel et accessible par le réseau du fournisseur de
services. À présent le demandeur de service peut effectuer les opérations de recherche et de
liaison.
4. Gérer
Les détails de chacune de ces phases du cycle de vie sont abordés dans le développement des
services Web
1.9 Conclusion
En conclusion, cette revue de littérature établit un cadre solide pour la compréhension des
enjeux et des opportunités liés à l'analyse métier et à la conception de plateformes e-commerce
dans le secteur vestimentaire. Elle met en lumière l'importance de la méthodologie UP en tant
qu'outil puissant pour aborder ces défis. Cependant, elle souligne également la nécessité d'une
32
approche adaptée aux besoins spécifiques de ce secteur en constante évolution. Cette revue sert
de base pour la recherche ultérieure qui explorera plus en détail l'application de la méthode UP
dans le contexte du commerce électronique vestimentaire.
33
: ANALYE METIER DU PROCESSUS DE VENTE DES VETEMENTS CHEZ
DEV MODE
Le magasin DEV MODE est parmi ceux qui vendent des bons vêtements.
- SITUATION GEOGRAPHIQUE
DEV MODE est située au numéro 2131, de la commune Lubumbashi avenues Kasa vubu.
34
2.0.3. Diagramme de description de processus métiers
Figure 9—Diagramme de processus métier de vente des vêtements
verfie attendre
edition
disponibilite 2min
facture
reception stock
commande fin
verfier existence
client
35
2.1. Expression de besoins fonctionnels de vente des vêtements
Une application informatique est conçue pour répondre premièrement au besoin des
utilisateurs ; lesquels utilisateurs sont considérés chacun comme un acteur jouant un rôle dans le
système.
Ainsi les acteurs important de notre système de vente et distributions des vêtements sont les
suivants :
1) Le client : le client est toute personne physique ou morale achetant des vêtements
à la boutique DEV MODE. Il touche le système pour effectuer commande, régler facture ou faire
une réclamation.
2) gestionnaire : c’est le rôle joué par un agent de la boutique DEV MODE ayant
dans ses responsabilités la vente et d’étaler des vêtements. Il touche le système pour traiter de
commande client, facturer, ordonner la distribution.
3) caissier : il s’occupe de la caisse du magasin, il reçoit l’argent
Schématiquement nous donnons dans le Figure 2.2 suivant un diagramme de contexte où
chaque acteur est relié par une association trait plein au système, symbolisant ainsi les échanges
d’informations.
DEV MODE
Gestionnaire
Client
caissier
effectuer commande
Client
payer facture
ii
uc cas d'utilisation de l'agent commercial
mettre en
attente
Traiter
commande
Facturer
commande
Agent
Commercial
Encaisser
paiement
ajouter
nouveau client
Gerer client
Service client
modifier client
iii
Figure 13—Cas d’utilisation de l’acteur Service client
uc
verification nouveau
visite boutique
Encaisser paiement
payer facture
caissier
Les activités considérer ici est l’activité de la commande d’un client, ainsi nous pouvons
présenter ce diagramme de la manier suivante :
iv
act Use Case Model
RECHERCHE
VETEMENT
CHOIX VETEMENT
PAYER
v
class Diagramme de classe metier
Client Commande
vetement
- code: int - /total: double: int
- nbrVetement: int
- nom: int passer - date: Date: int
- ref: int
- telephone: int - numero: int: int
- taille: int
+ ajouter(): void + calculer(): void
+ compter(): void
appartenir
Facture
- date: Date
- montant: double
- numero: int
+ valider(): void
Le système actuel fonctionne radicalement bien avec les objectifs poursuivis par
l’Entreprise, ceux qui consiste à vendre, poursuivre à la loupe la gestion du stock ainsi la sécurité
de leurs vêtements dans le stock.
C’est évident que le système actuel pour faire ses achats, il faut se présenter en personne,
c’est un obstacle pour la plupart de personnes à cause du temps, des dépenses du transport, voire
même à cause de leur rang social.
Il est vrai que le système fonctionne à merveille comme il est souhaitable qu’un magasin
puisse fonctionner, certes notre objectif n’est pas celui de livrer les articles en ligne mais à
effectuer les commandes en ligne, où les clients achètent en ligne est la livraison se fait à domicile.
vi
Cependant, nous demandons à l’organisation ciblée ou toute autre qui voudrait un système
d’information qui comprendra également la vente de ses produits via internet, devrait opter pour
ce système qui leur permettra la synchronisation des opérations.
CONCLUSION PARTIELLE
Dans le troisième chapitre suivant, nous allons identifier les besoins fonctionnels tenant
compte de l’aspect technique, analyser et conception notre application MODESOFT.
vii
: CONCEPTION DU NOUVEAU SYSTEME DE COMMANDES MODE SOFT
1.1. Introduction
Dans chapitre, nous allons devoir concevoir l’architecture logicielle de MODE SOFT au moyen
des artéfacts UML afin d’en spécifier le fonctionnement. Pour y parvenir, une enquête de besoins
du nouveau système en termes d’utilisateurs finaux, fonctionnalités ainsi que les contraintes
techniques. Cette conception sera articulée en deux étapes à savoir : la conception préliminaire où
nous présentons les modèles de cas d’utilisations, les descriptions textuelles, les classes
participantes, la description dynamique de cas d’utilisation ; et la conception détaillée où tous les
modèles précédents en intégrant les détails d’implémentation.
Le système doit répondre aux attentes des utilisateurs finaux en termes avec de services. Pour cela
nous avons retenus des acteurs suivants pour le système MODE SOFT :
1) Client : le client touche le système pour consulter le catalogue de vêtements, effectuer une
commande en ligne de vêtements
2) L’Internaute : L’Internaute peut consulter le catalogue, créer un compte et choisir ses
vêtements à commander
3) Administrateur : l’administrateur touche le système pour traiter les commandes de clients
et actionner la livraison
4) Livreur : le livreur touche le système pour consulter les clients et leurs adresses de
livraison.
5) Le Système de paiement : est un système informatique tiers sollicité par le système MODE
SOFT pour autoriser un paiement d’un client avant la livraison ;
Tableau 1—Modélisation du contexte
viii
- Choisir un vêtement
- Commander un vêtement
- Payer un vêtement
Le système émet :
- Catalogue de vêtement
- Panier du client
- Devis de la commande
Client Effectuer commande - Confirmation paiement
Le système reçoit :
- Nouveau produit
- Editer prix
- Editer détails
- Valider catalogue
Le système émet :
Mettre à jour - Liste de produits
catalogue - Version du catalogue
- Tarif de produits
Consulter catalogue
produit Le système permet à l’Internaute de :
Internaute - Rechercher un produit
- Sélectionner un produit
- Créer un compte
ix
1.10.1 3.1.1. Diagramme de cas d’utilisation du système MODE SOFT
uc BPEL Model
Editer Nouveau
S'inscrire
«include»
commander Admin
vetement «include» S'authentifier
Gerer sa «include»
Client
commande
Pour se conformer au principe dit « Itératif et incrémental de la méthode UP, nous allons
spécifier l’ordre de réalisation de chaque cas d’utilisation [12]. Le découpage en itérations obtenu
est illustré dans le Tableau 2 suivant.
Tableau 2—Planification des itérations grâce aux cas d’utilisation
x
Traiter commande Moyenne Bas 6
Ayant fait notre découpage, il est temps de passer à la description textuelle de chaque cas
d’utilisation.
Pour illustrer notre démarche, nous allons détailler les cas d’utilisation des quatre premières
itérations, à savoir, dans l’ordre :
- Scénario nominal
Acteur Système
1 Le Gestionnaire alimente le site avec les 2 Le système MODE SOFT met à jour les
nouveaux vêtements. données qui concernent le prix, le détail du,
image vêtements de la boisson.
xi
- Alternatives
1-2aLe Système détecte un dysfonctionnement du catalogue de vêtement.
1. Le Système signale le dysfonctionnement au Gestionnaire.
2. Gestionnaire invalide la mise à jour du catalogue.
ALTERNATIVES
1a Le visiteur n’a pas d’idée préconçue et préfère flâner dans le catalogue virtuel. Pour
cela, le Système lui propose un ensemble de pages telles que : CHEMISE, T-SHIRT,
2a Le Système n’a pas trouvé produit correspondant à la recherche.
xii
- Objectifs : À tout moment, le client doit pouvoir accéder au formulaire de commande,
dans lequel il peut saisir ses coordonnées et les informations nécessaires au paiement et
recevoir ses articles commandées où qu’il soit.
- Préconditions : Au moins un vêtement a été sélectionné il s’est identifié.
- Post-conditions
• Une Commande a été enregistrée et transmise au Service commercial de DEV MODE.
• Une transaction cryptée a été réalisée avec le système externe de Paiement sécurisé et
sauvegardée qui peut être Mpesa, Airtel Money ou un paiement en espèce.
- Scénario nominal
Acteur Système
xiii
8 Le Système enregistre la commande.
- Alternatives
1-3aLe Client annule sa commande.
d) Traiter commande
- Acteur principal : Service commercial.
- Objectifs : permettre à l’administrateur d’administrer les commandes de clients en ligne
et ordonner la livraison si possible.
- Préconditions
1. L’administrateur est authentifié.
- Post-conditions
Une commande traitée.
Un plan de livraison établie
- Scénario nominal
Acteur Système
xiv
2. Afficher liste de commande en attente
1. Traiter commande
4. Etat paiement affiché
3. Sélection commande
6. Ordre de livraison enregistré et
5. Saisir plan de livraison transmis au Livreur
8. Enregistrer commande
7. Archiver livraison
- Alternatives
3a Paiement non effectué.
e) Créer un compte
- Acteur : visiteur
- Objectif : visiteur veut s’enregistrer afin d’avoir accès à l’espace de commande des
articles en ligne.
- Précondition : la sélection des vêtements déjà effectué
- Post-condition : un compte crée et un nouveau client ajouté
- Scénarios
1. Le visiteur renseigne les informations nécessaires (nom, login, mot de passe, email de
confirmation du compte, téléphone, adresse)
2. Le système vérifie les informations saisies et affiche un récapitulatifs au visiteur et
envoi un email de confirmation
3. Le visiteur valide la création du compte
xv
4a. Echec d’authentification : un message d’erreur est affiché à l’utilisateur pour
réessayer
1.11.1
UML propose deux diagrammes pour répondre à ce besoin de représentation des interactions
entre objets ou en l’acteur et le système à savoir Le diagramme de séquence se focalise sur les
aspects temporels et le diagramme de communication se focalise sur la représentation spatiale[13].
Pour notre cas, seuls les diagrammes de séquences seront utilisés pour illustrer le dynamisme du
système.
xvi
a) Diagramme de séquences système de création compte client
1.11.3 Suivant la description textuelle du cas d’utilisation « créer compte
client, l’acteur client interagit avec le système :
sd CREER COMPTE
System
VISITEUR
creeCompteClient()
formulaire inscription()
verification()
[echec]
recaputilatif compre()
[succé]
creerCompte()
sauvegarde()
email de confirmation()
xvii
sd S'authentifier
SYSTEM
utiliateur
1: seConnecter()
loop 3: LoginMotDePasse()
alt
break
[IF]
verification()
connexion etablie()
[ELSE]
connexion échouée()
xviii
Figure 20—Diagramme de séquences système du cas d’utilisation « Mettre à jour le catalogue
xix
Figure 21—Diagramme de séquences du cas d’utilisation « Consulter catalogue article »
xx
Figure 22—Diagramme de séquences du cas d’utilisation « Passer commande »
Il s’agit de diagrammes de classes UML qui décrivent, cas d’utilisation par cas d’utilisation,
les trois principales classes d’analyse et leurs relations. Nous distinguerons ensuite trois types de
classes d’analyse :
"entity"
Catalogue
Administrateur - date: Date
- nuero:: int
- version: int
"entity'' Article
''dialog'' MiseAjourCatalogue
- designation: Sting
- -designation: Sting - imageArticle: Sting
- -ref: String "control" GestionCatalogue - marque: String
- dateCatalogue: Date - prixUnit: float
- detail: String + ajouterNouvelAticle(): void
+ supprimerArticle(): void - ref: int
- image article: Strig - taille: float
- marque: float + validerCatalogue(): void
- prixUnit: float + vediterPrixArticle(): void
- taille: float
- versionCatalogue: int ''entity" "entity" ''entity"
+ ajouterNouvelArticle(): void Chaussure Vetement accessoire
+ editerArticle(): void
- taille: int - taille: int - taille: int
+ supprimerArticle(): void
+ validerCatalogue(): void
xxii
class BPEL Model
Catalogue
vetement
- article
- rechercher - desciption
- nom
- prix
Utilisateur
- adresse
- consulter
- nom
Figure 24Fig.3. 8—Diagramme de classes participantes du cas d'utilisation « Consulter catalogue vêtement »
xxiii
class BPEL Model
client Commande
- date: Date Article
- adresse: String
- email: String - numero: int - nom: String
- nom: String - total: float - prix: float
- quantite: int
- reference: String
ligne de Catalogue
Mode de
commande
paiement - article: liste
- date: Date
- numero: int
- numero: int
- type: String
- total: float
xxiv
class BPEL Model
Utilisateur
- adresse commande
- consulter - article
- nom - passerCommande()
- suivreLivraison: int - suivreLivaison
- total
Livraison
Catalogue
- dateEstimee
- article
- etat
- rechercher()
Vetement
- description
- nom
- prix
xxv
class BPEL Model
Utilisateur
Commande
- adresse
- gererLivraison() - article
- nom - gererLivraison
- livraison
- total
Livaison Catalogue
- dateEstimee - article
- dateReelle - rechercher()
- etat
Vetement
- description
- nom
- prix
xxvi
Figure 28—Diagramme de classes participantes du cas d'utilisation « S’authentifier»
xxvii
3.2.8. Diagramme d’Etats-transitions
Un objet passe par une succession d’états durant son existence. Un état a une durée finie,
variable selon la vie de l’objet, en particulier en fonction des événements qui lui arrivent. Un état
représente une situation durant la vie d’un objet pendant laquelle :
Nous allons à présent détailler suffisamment les éléments de modèles précédents afin d’être
en mesure d’obtenir toutes les spécifications techniques nécessaires à la réalisation, incluant les
contraintes technologiques. Nous construirons l’aspect dynamique avec de diagrammes de
séquences détaillées contenant les objets techniques ; également une vue statique complétée sous
forme de diagrammes de classes de conception détaillées, intégrant des spécifications
technologiques.
Cette opération a pour objectif de retrouver un Article rapidement à partir du nom ou d’un
autre mot-clé.
Ce diagramme met en interaction les objets suivants :
- Un écran de consultation
xxviii
sd diagrame op
Client
EcranRecherche CtrlCatalogue Categorie produit
HasMap<long_Categorie> HashMap<long_Articlet>
loop
rechercheParId(id): article
produitParId(id); Article
fin(id): article
init(myCate): Categorie
neant()
alt
[[echec]]
neant()
create()
EurreurResultat
[[succé]]
detail()
DetailRecherche()
DetailRecherche
opt mettreDansPanier()
- Un écran de consultation
sd BPEL Model
loop
[nbre article]
consulterAvancee(libelle,taille,model)
rechercheAvancee(libelle,taille,model
rechercheAvancee(P)
trouver()
resultat()
resultats()
"dialogue"
create()
ResultatRecherche
opt
[condition]
selectionerArticle()
selectionArticle()
"entity" Panier
create()
ajouter(article)
Cette opération a pour objectif d’afficher les détails d’un Article afin de faire le choix par
apport au vœu du client.
xxx
Ce diagramme met en interaction les objets suivants :
- Un écran de consultation
sd BPEL Model
loop
[nbr article]
voirDetailsArticle(a)
afficheDetail(ref)
getinfoArticle(ref)
trouver()
resultat()
getdetail()
details()
rsultats()
opt
<<dialogue>>
[condition] create()
ResultatRecherche
xxxi
d) Opération système « valider commande »
Cette opération a pour objectif de commander un panier contenant des articles préalablement
sélectionné.
Ce diagramme met en interaction les objets suivants :
- Un écran de commande
xxxii
sd BPEL Model
saisieCommande(n°,date,adresse)
commande(n°,date,article)
getinfoVetement(ref)
add(c,panier)
afficher()
afficher()
afficher()
attentePaiement()
confirmerCommande(paiement)
infosPaiement()
infosPaiement()
alt Autorisé()
[Autorisé]
afficher()
afficher()
<<dialogue>>
create()
Execption
- Un acteur Administrateur
ref
S'authentifier
creeArticle(ref,prix,details,photo
editerArticle(ref,prix,detail,photo)
<<entity>> a:
create()
Artcle
ajouter(a)
ajouter
(a)
afficher()
- Un acteur Administrateur
- Un contrôleur catalogue
xxxiv
- Une collection d’article.
sd BPEL Model
ref
S'authentifier
rechercheMenu(ref)
getArticle(ref)
getArticle(ref)
find(ref)
article()
article()
afficher()
editerArticle(ref,prix,details,photo
editerArticle(ref,prix,detail,photo)
update()
remplace(a)
editer(a)
afficher()
Ajouter ou préciser les opérations dans les classes (un message ne peut être reçu par un
objet que si sa classe a déclaré l’opération publique correspondante).
xxxv
Ajouter des types aux attributs et aux paramètres et retours des opérations.
Affiner les relations entre classes : associations (avec indication de navigabilité),
généralisations ou dépendances.
Adresse
Paiement PlanLivraison
- commune: String
- mode: String - chauffeur: String
- nomAvenue: String
- montant: double - date: Date
- numRue: String
- motif: int - heure: Time
- quartier: String
- numero: int - numero: int
- reference: String
- plaque: String
+ ajouter(): void
+ modifier(): void + annuler(): boolean
+ modifier(): boolean
+ Planifier(): boolean
Client
- email: String Article
Commande
- nom: String
- prenom: String - /total: int - nom: String
- reference: String - date: Date - prixUnit: float
- telephone: String - modepaiement: String - ref: String
- numero: int - Taille: int
+ afficher(): Client - uniteVente: String
+ nouveau(): Client + annuler(): boolean
+ calculer(): float + afficher(): Article
+ confirmer(): boolean + Creer(): Article
+ Creer(): Commande + editer(): Article Categorie
+ supprimer(): boolean
Facture - detail: String
- idCat: String
- date: Date - nom: String
- montant: double LigneCommande
- numero: int + ajouter()(): int
- id: int Catalogue
+ creer(): void - qte: int
- total: float - id: Date
- unite: String - periode: int
+ ajouter(): LigneCommande + cree(): void
+ editer(): boolean + editer(): boolean
+ enlever(): boolean + supprimer(): boolean
Un Modèle Physique de Données (MLD) nous aide à analyser les tables, les vues et autres
objets d'une base de données, y compris les objets multidimensionnels nécessaires à l'utilisation
d'un entrepôt de données.
Pour obtenir un modèle logique de données à partir d’un modèle de classes, les principes
suivants sont à observer :
- Chaque classe devient une table dont les champs sont les attributs élémentaires de cette
classe
- Une relation d’héritage est soit transformée en une table (push-up), soit push down.
xxxvi
- Une classe associative devient un table dont la clé primaire est la concaténation des
identifiants des entités participants à la relation ;
- Une relation d’agrégation impose une clé étrangère à chaque agrégat ;
- Une association de direction avec multiplicité (1..1, 1..*) impose une contrainte d’intégrité
référentielle à l’entité à coté de laquelle la multiplicité est 1..1.
Ainsi le modèle physique obtenu par génération dans Power AMC est le suivant :
21
Serveur Web
Navigateur GestionClient
80
http
Port_1
80
I_Commabde
GestionComma _
nde s GestionCatalogue
s
ICatalogue
TCP
3306
BaseDonnee
xxxvii
CONCLUSION PARTIELLE
xxxviii
RESULTAT DE LA RECHERCHE.
Introduction
L'analyse métier est un processus essentiel pour la conception d'une plateforme e-commerce
vestimentaire.
La méthode UP est un processus efficace pour la conception d'une plateforme e-commerce
vestimentaire.
Les résultats de la recherche ont confirmé ces hypothèses. En effet, l'analyse métier permet de
comprendre les besoins des utilisateurs et des parties prenantes, ce qui est essentiel pour la
conception d'une plateforme qui répondra à ces besoins. La méthode UP, quant à elle, permet de
développer une plateforme de manière itérative et incrémentale, ce qui permet de réduire les
risques et de garantir la qualité du produit final.
Les recherches menées sont valides car elles sont basées sur une analyse approfondie de la
littérature et de l'expérience pratique. Les résultats sont également cohérents avec les résultats
d'autres études sur le sujet.
Conclusions finales
L'analyse métier et la conception par la méthode UP sont des processus essentiels pour le
développement d'une plateforme e-commerce vestimentaire. Ces processus permettent de
garantir que la plateforme répond aux besoins des utilisateurs et des parties prenantes et qu'elle
est bien conçue et développée.
Les résultats de cette recherche sont limités par le fait qu'ils sont basés sur une étude de cas. Il
serait nécessaire de mener des études plus approfondies pour confirmer ces résultats dans
d'autres contextes.
xxxix
Recommandations
Sur la base des résultats de cette recherche, les recommandations suivantes peuvent être
formulées :
Les entreprises qui souhaitent développer une plateforme e-commerce vestimentaire devraient
accorder une attention particulière à l'analyse métier et à la conception.
La méthode UP est une approche efficace pour la conception d'une plateforme e-commerce
vestimentaire.
Les entreprises devraient tenir compte des limites des résultats de cette recherche lors de
l'application des recommandations.
2. Le serveur web (Apache) cherche dans son arborescence si le fichier existe, et si celui-ci
porte une extension reconnue comme une application PHP (.PHP, .PHP3, .PHP4 par
exemple). Si c'est le cas, le serveur web transmet ce fichier à PHP.
3. PHP parse le fichier, c'est-à-dire qu'il va analyser et exécuter le code PHP qui se trouve
entre les balises <?php et ?>. Si ce code contient des requêtes vers une base de données
MySQL, PHP envoie la requête SQL. La base de données renvoie les informations voulues
au script qui peut les exploiter (pour les afficher par exemple).
4. PHP continue de parser la page, puis retourne le fichier dépourvu du code PHP au serveur
web.
5. Le serveur web renvoie donc un fichier ne contenant plus de PHP, donc seulement du
HTML au navigateur qui l'interprète et l'affiche.
xl
Figure 38—architecture de composant de l'application
xli
CONCLUSION GENERALE
Après ces tournures de langages, nous voici à l’apogée de notre mémoire qui a consisté
sur « l’analyse métier et conception par la méthode up d’une plate-forme E-commerce dans
le domaine vestimentaire (cas de DEV MODE)» qui constitue de nos jours un domaine convoité
de l’ère du numérique. L’objectif de cette étude été de solutionner la problématique de commandes
conditionnées par les empêchements qui occasionnait les manque d’écoulement rapide de articles
de surcroit une perte de la clientèle.
Eu égard à la problématique de cette étude, nous confirmons que les hypothèses ont été
confirmées. Le prototype réalisé n’est qu’une première itération de l’application MODE SOFT, et
dispose les options suivantes : un module de recherche en ligne des articles, une option de sélection
des articles pour constituer sa commande; un module de commande en ligne incluant une
possibilité de payer par Mobil Money, ou en espèce afin d’entrer en possession de sa commande
dans un bref délai ; un module pour suivre en temps réel l’évolution de sa commande ; et un
module de gestion du catalogue. Désormais les clients de Dev Mode ne peuvent plus se déplacer
pour commander un vêtement car désormais un espace client est disponible en ligne pour effectuer
ses achats ou faire de réclamations.
Signalons que le domaine d’e-commerce restent complexe pour nous, sur ce, nous ouvrons
l’ébauche sur la livraison de la commande en temps réel par des drones comme perspectives pour
des recherches futurs.
xlii
BIBLIOGRAPHIE
[2] M. Priestley, T. J. Sluckin, et T. Tiropanis, « Innovation on the web: the end of the S-
curve? », Internet Hist., vol. 4, no 4, p. 390‑412, oct. 2020, doi:
10.1080/24701475.2020.1747261.
[4] S. Agrawal et R. D. Gupta, « Web GIS and its architecture: a review », Arab. J. Geosci.,
vol. 10, no 23, p. 1‑13, 2017.
[5] N. Mérouze, « Architecture des applications web : quelles bonnes pratiques en 2020 ? »
https://www.synbioz.com/blog/architecture-applications-web (consulté le 9 juillet 2022).
[6] V. J. Harward et al., « The ilab shared architecture: A web services infrastructure to build
communities of internet accessible laboratories », Proc. IEEE, vol. 96, no 6, p. 931‑950, 2008.
[8] L. D. Paulson, « Building rich web applications with Ajax », Computer, vol. 38, no 10, p.
14‑17, 2005.
[11] B. Fyama et R. Nyami, « Une approche basée sur les réseaux Pétri pour la vérification et
la validation formelle des modèles de processus métier dans les entreprises congolaises », 2018.
xliii
[12] P. Roques, UML 2: Modéliser une application web. Editions Eyrolles, 2008.
[13] L. Debrauwer et F. Van Der Heyde, « UML 2.5 », Barc. Ed. ENI Obtenido Httpsbooks
Google Com Ecbooks, 2016.
xliv