Rapport - Rami BEN HADJYAHYA - Ala AWADHI

CONCEPTION ET DEVELOPPEMENT D’UN MARKETPLACE
Introduction générale
Des ventes de mains en mains, vers des ventes virtuelles, passent les priorités des
opérations de ventes des biens et des services, ce qui nous rend obligés de donner plus
d’importance à la vente électronique.
Les boutiques en ligne sont depuis des années, largement conseillées pour les sociétés
qui se basent sur la vente des produits et même des services. Ces types de sites web
représentent un dispositif global fournissant aux clients un pont de passage à l’ensemble des
informations, des produits, et des services à partir d’un portail unique en rapport avec son
activité.
Notre projet est réalisé dans le cadre du Projet de Fin d’Etudes ayant comme objectif
principal : la conception et le développement d’un site de type MarketPlace pour le compte
de TIT.
Ce rapport est composé de quatre chapitres :
Le premier chapitre consiste à présenter le cadre général du projet à travers la
présentation de la société d’accueil, une étude de l’existant suivie d’un aperçu de la
méthodologie adoptée.
Le deuxième chapitre présente la spécification et l’analyse des besoins.
Pour le troisième chapitre, il montre la conception de l’application à travers les
diagrammes UML.
Enfin, le quatrième chapitre présente l’environnement de réalisation de l’application,
le déploiement de l’application, les principales interfaces réalisées, un aperçu de
l’implémentation de l’application ainsi que la planification du projet.
Le rapport est clôturé par une conclusion qui synthétise notre travail.
1
CHAPITRE I : PRESENTATION DU CADRE DU PROJET
Chapitre I : Présentation du cadre général du projet
Introduction
Dans cette partie, nous allons faire une présentation de l’entreprise puis nous allons effectuer
une étude des Marketplaces existants, définir les grands axes de travail et désigner la
méthodologie à adopter.
I- Présentation de la société
Fondée en 2015, TIT est une SSII (Société de Services en Ingénierie Informatique) qui offre
ses solutions business basées sur le Cloud. Son but est l'augmentation significative de la
collaboration entre les agents et leur productivité, afin d’assurer un rapide RSI (Retour Sur
Investissement).
II- Etude de l’existant

La société a obtenu un marché de la part d’un client Allemand pour le développement d’un
Marketplace, nous sommes donc amenés à devoir faire une étude comparative des principaux
MarketPlaces existants sur la toile.
1- Etude comparative de quelques MarketPlaces
Nous avons effectué une étude comparative de 10 Marketplaces bien ancrés sur le marché du
E-commerce d’après « alexa.com » : site connu par fournir des statistiques sur le trafic du web
mondial, afin d’identifier les grands axes qui définissent un Marketplace et les points à
améliorer pour être plus compétitif. [11]
L’étude a porté sur les sites suivants : [1]:
 Amazon.com : C’est une entreprise de commerce électronique américaine basée

à Seattle. Sa spécialité la plus connue est la vente de livres, mais elle est diversifiée dans
d'autres produits.
 Cdiscount.com : C’est un distributeur français de produits high-tech, de loisirs,
d'équipements de la maison sur Internet.
2
CHAPITRE I : PRESENTATION DU CADRE GENERAL DU PROJET
 Ebay.com : C’est une entreprise américaine de courtage en ligne, connue par son site
web de ventes aux enchères du même nom.
 Fnac.com : est une chaîne de magasins française spécialisée dans la distribution de
produits culturels (musique, littérature, cinéma, jeu vidéo) et électroniques (Hi-
fi, informatique, télévision), à destination du grand public.
 Laredoute.com : C’est une enseigne française de vente à distance créée en 1837 par
Joseph Pollet. Multi-spécialiste en prêt-à-porter et décoration maison, La Redoute est le
deuxième vendeur d’habillement féminin et le troisième vendeur de linge de maison en
France.
 Pixmania.com : C’est un des acteurs majeurs du commerce électronique en France mais

aussi dans 14 pays européens, créé par les frères Rosenblum. Son cœur de métier est la
distribution de produits techniques (Photo numérique, électronique, informatique,
électroménager, jeux vidéo) vendus à travers un site web mais l'enseigne est aussi
présente sur d'autres univers produits comme la puériculture, le jouet, la maison et Jardin.
 ETSY.com : C’est un site de vente en ligne fondé en 2005.
 DaWanda.com : Ou « Bon d'achat » en Français, c’est un portail en ligne e-commerce

comprennent les vêtements, bijoux, accessoires, sacs, articles pour bébés, jouets, matériel
et mobilier. DaWanda.com est en ligne depuis 2006 et actuellement le plus grand marché
en ligne en Allemagne.
 AlittleMarket.com : C’est une plateforme française de produits faits à la main lancée en

décembre 2008. Des créateurs, au statut particulier ou professionnel, peuvent vendre en
ligne leurs créations directement à des acheteurs. Le but est de réduire les intermédiaires
et favoriser les circuits courts en prêt-à-porter, bijoux, accessoires, et décoration.
 PrimaCréa.com : C’est une plateforme pour acheter ou vendre des objets uniques et
faits main. [2]
L’analyse des sites existants a été élaborée sur deux axes, dans un premier temps, nous
avons décortiqué les données générales relatives aux plus grandes enseignes, puis nous
sommes passés à une analyse plus détaillée de quelques-unes de ces enseignes afin de
connaître leurs fonctionnements et leurs lacunes.
3
ALittle Primacr
Amazon Cdiscount Ebay Fnac Laredoute Pixmania ETSY Dawanda
Market éa
Visiteurs
(million/ 14.7 10.5 10 10.2 7.9 4.2 3.9 8.5 1.8 0.1
mois)
Commission
sur vente(en 5 à 15 4 à 13 5à9 8 à 12 Variable 7 à 12 3.5 5 variable gratuit
%)
Frais
d’abonnemen gratuit gratuit gratuit 10 € /
39 35 24.95 39.99 49.90 39.99
t par mois (en mois
€)
Nb catégories 23 21 30 20 14 39 12 11 11 10
Panier 90 110 54 60 90 200 N/D N/D N/D N/D
Frais
0.10 à
d’insertion Gratuit Gratuit Gratuit Gratuit Gratuit 0.20 Gratuit Gratuit Gratuit
0.15
produits
Monde : Monde :
Monde : Monde : Monde :
Classement Monde : Monde : Monde : 1539 Monde : 2207
25550 10578 10821
des sites par 4 775 18 France : 142 Allemagne N/D
Suisse : France : France :
popularité USA : 4 France : 20 USA : 8 56 USA : 42 :
289 531 329
113
N/D : Non Disponible
Tableau 1 : Analyse générale des sites de renommée
Dans cette partie, une sélection de quelques sites a été faite afin d’identifier les détails qui les
caractérisent et qui ont un impact significatif sur leurs succès [3].
ETSY DAWANDA A LITTLE MARKET PRIMACRÉA

Trafic déclaré 3.9 mio / mois 8.5 mio / mois 1.8 mio / mois 100.000 / mois
(visiteurs)
Nb de boutiques 800.000 + 140.000 + 29000 + 2000 +
Nb de membres 14 moi 1.8 moi 191000 9730
Langues EN, FR, DE, NL EN, FR, DE, ES, FR FR
IT, NL, PL
Inscription Gratuit Gratuit Gratuit 10 € / mois
Ouverture boutique gratuit gratuit gratuit gratuit
Insertion 1 article 0,20 $ gratuit gratuit gratuit
Insertion de photos gratuit (5) gratuit (4) gratuit (5) gratuit (4)
Durée d'insertion d'1 4 mois 3 mois Illimitée Gratuit
article
Prolongation auto non gratuit non gratuit
d'une insertion
4
Frais de prolongation 0.20 $ / article gratuit gratuit gratuit

Vente d'1 article 3,50% 5% < 10 €, frais = 0.50 € gratuit
> 10 €, frais = 5%
Moyens de paiement virement, virement, virement, Paypal, virement, Paypal,
des frais Paypal Paypal chèque chèque
Monnaie Dollars Euros Euros euros
Mailings personnels non non oui non
Tableau 2: Sélection détaillée de quelques sites caractérisés par leurs succès dans le marché
2- Critique des solutions

L’étude effectuée nous a permis de détecter plusieurs points communs ainsi que des points de
divergences entre ces différents sites, de nombreux services proposés par les sites sont offerts
de façon gratuite, nous citons notamment les frais d’insertion d’un produit qui sont inexistants
sur 80% des Marketplace analysés, ainsi il est judicieux de ne pas déroger à cette règle pour
pouvoir concurrencer avec ces derniers.
D’un autre côté, si nous nous approfondissons dans les détails, nous remarquons que plusieurs
fonctionnalités sont payantes, tous ces frais une fois cumulés nous montrent que l’utilisation
de ces sites devient assez rapidement assez onéreuse que ce soit pour le vendeur que pour
l’acheteur, nous citons à titre d’exemple, les frais d’abonnement au site, les commissions
excessives ou même les frais de transactions sur les payements. De cette analyse, nous avons
synthétisé en un seul tableau les grands axes qui définiront notre site pour qu’il puisse faire
face à la concurrence.
3- Présentation des solutions de paiement

Pour notre MarketPlace, nous allons utiliser PayPal comme solution de paiement, nous allons
d’abord la présenter puis citer ses avantages :
 Présentation de PayPal
PayPal est un système de paiement en ligne permettant aux surfeurs du Web d'acheter en toute
sécurité sur Internet.
Principe : PayPal est en quelques sortes une banque virtuelle. L’utilisateur y dépose de
l'argent par chèque, ou par virement bancaire par exemple.
Ensuite, lorsque ce dernier souhaite acheter quelque chose sur Internet et que le site en
question propose de payer par PayPal, L’intéressé vire le montant de son achat directement
sur le compte du vendeur.
5
Le vendeur n'a plus qu'à faire l'opération inverse pour récupérer l'argent de son compte
PayPal. Bien entendu il peut le laisser sur son compte s'il souhaite à son tour acheter quelque
chose sur Internet.
 Avantages de PayPal
 Le paiement en ligne par PayPal est probablement le plus connu des services de paiement
par Internet dans le monde. Il peut donc jouer en faveur du vendeur qui veut vendre un
bien ou un service sur Internet. Si le visiteur a déjà un compte sur PayPal, il sera plus
disposé à acheter quelque chose que s'il doit encore s'inscrire sur un autre site qu'il ne
connaît pas.
 Paypal permet le paiement direct par carte de crédit. Si le visiteur ne connaît pas le site, il
n'aura pas très confiance et ne souhaitera pas laisser son numéro de carte de crédit. Alors
qu'en passant par PayPal, il a la certitude que personne ne peut faire usage de sa carte de
crédit à son insu, puisque c'est PayPal qui gèrera la transaction.
 PayPal est simple d'utilisation (pour le client qui achète).
4- Solution proposée
La synthèse qui découle de l’étude faite puise ces atouts dans les avantages de chaque site et
remédie aux lacunes de ces derniers, nous la présentons sous la forme d’un tableau qui
englobe les grands axes qui caractérisèrent notre site.
Commission sur vente(en %) Paramétrable

Frais d’abonnement par mois (en €) Gratuit
Frais d’inscription Gratuit
Frais d’ouverture d’une boutique Gratuit
Frais d’insertion d’un produit Gratuit
Frais d’insertion de photos Gratuit
Durée d'insertion d'un produit 2 mois (max)
Moyens de paiement des frais PayPal
Monnaie Monnaies utilisées par PayPal
Langue Anglais
Tableau 3: Liste des grands axes qui caractérisent notre marketplace
6
III- Méthodologie adoptée

Lors du développement d’un logiciel, désigner une méthodologie à suivre est primordial pour
créer des applications robustes tout en respectant les délais impartis.
Nous avons opté pour le modèle en cascade comme modèle du cycle de développement
logiciel. Ce choix se base sur plusieurs avantages qui nous permettent de mieux contrôler
l’avancement du projet ; le développement répété offre une meilleure gestion des risques dans
la mesure où les développeurs identifient les grandes lignes du projet ou les priorités et de
concevoir un prototype basé sur ces informations, ensuite, ce prototype évolue au fur et à
mesure que le projet avance et il peut accueillir des changements à n’importe quel moment
sans mettre en péril l’avancement.
Nous avons opté pour le langage de modélisation UML (UNIFIED MODELING

LANGUAGE) pour la conception du projet, plusieurs facteurs entrent en jeu dans ce choix,
nous citons entre autres le fait que UML est devenu, au fil des ans, un standard dans la
conception orientée objet, le fait que UML prend en charge divers paramètres comme le
langage choisi, les interactions entre les différents composants, etc.
Conclusion
Dans ce chapitre, nous avons présenté la société d’accueil. Ensuite, nous avons mené une
étude et une critique de l’existant suivie d’une description de la solution proposée. Enfin, nous
avons présenté la méthodologie adoptée. Dans le chapitre suivant, nous procédons à la
spécification des besoins.
7
CHAPITRE II : SPECIFICATION DES BESOINS
Chapitre II : Spécification des besoins
Introduction
La spécification des besoins établit ce que notre MarketPlace doit fournir comme
fonctionnalités et les contraintes sous lesquelles il doit opérer.
Dans cette partie, nous allons faire une étude des besoins pour dégager les besoins
fonctionnels et non fonctionnels, puis nous détaillons les cas d’utilisations et les diagrammes
de séquences.
I- Etude des besoins

La spécification des besoins permet de décrire ce que doit faire le système en énumérant les
besoins fonctionnels et non fonctionnels.
1- Besoins fonctionnels
Il s'agit des fonctionnalités du système d’un site de type MarketPlace. Les besoins
fonctionnels listent les opérations réalisables par notre application
Nos besoins fonctionnels consistent à :
- Consultation du site
 Consulter les produits
 Rechercher des produits par nom, catégorie, prix et boutique
 Trier les résultats de recherche par date d’ajout et prix
 Contacter un administrateur
 Commenter un produit
- Accès au compte de l’abonné
 S’inscrire.
 Gérer son compte :
1- Modifier les informations personnelles.
2- Modifier ou récupérer le mot de passe
8
- Gestion des boutiques

Pour ajouter un produit à vendre, un abonné doit avoir ou créer une boutique
associée à son compte avec un nom unique pour pouvoir faciliter la gestion de ses
produits. L’application doit fournir les moyens de
 Ajouter, Modifier, Supprimer une boutique.
 Visualiser l’historique des ventes.
 Gérer les produits d’une boutique
1- Ajouter, Modifier, Supprimer des produits d’une boutique
2- Attribuer un prix promotionnel à un produit
3- Faire le suivi des ventes en cours
- Achat des produits
 Gérer le panier :
1- Ajouter un produit au panier
2- Modifier la quantité du/des produit(s) dans le panier
3- Supprimer un produit du panier
 Payer un ou des produits
 Editer la facture
 Consulter l’historique des achats
- Administration du site
 Gérer les abonnés
1- Visualiser la liste des abonnés
2- Contacter un abonné
3- Bloquer ou supprimer un abonné
 Désactiver ou supprimer une boutique ou un produit en vente.
 Gérer les catégories :
1- Consulter les catégories
2- Ajouter une catégorie
3- Modifier une catégorie
4- Supprimer une catégorie
 Consulter l'historique des ventes de tous les utilisateurs.
 Définir les conditions de vente.
9
2- Besoins non fonctionnels
Une identification est une bonne considération des besoins non fonctionnels est tout aussi
importante et doit être bien étudiée afin d’assurer un bon fonctionnement du site.
Ces exigences se traduisent par :
 Fiabilité :
L’application doit fonctionner de façon cohérente sans erreurs.
 Gestion des erreurs :
Une gestion des erreurs est nécessaire dans un site pour pouvoir contrôler chaque erreur et
donner un sens à chacune. Concernant notre MarketPlace toutes les erreurs doivent être gérées
par des messages d’erreurs.
 Ergonomie et simplicité :
C'est la capacité qu'aura le site à être pratique, fonctionnel quelles que soient les capacités de
l'internaute, son mode de consultation.
 Sécurité :
Notre MarketPlace doit garantir une authentification sécurisée, un cryptage des informations
et une gestion des rôles des utilisateurs qui sont tous nécessaires pour garantir la sécurité des
informations de l’utilisateur.
 Compatibilité :
Un site Internet peut être consulté par de nombreux outils différents, des ordinateurs aux
smart phones en passant par les tablettes ... Il est nécessaire de prendre en compte ces
nouveaux modes de consultation. En respectant les standards d’intégration (HTML5)
garantissant l’interopérabilité.
Pour mettre en évidence ces fonctionnalités, celles-ci seront illustrées par les diagrammes des
cas d’utilisation ainsi que les diagrammes de séquence.
II- Cas d’utilisation
Un cas d'utilisation définit une manière d'utiliser le système et permet d'en décrire les
exigences fonctionnelles.
10
1- Présentation des acteurs
Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système dans le
but de réaliser une plus value. [4]
Les acteurs en interaction avec notre système sont :
 Un internaute : C’est un utilisateur non authentifié qui peut seulement consulter le site,
s’inscrire et remplir son panier sans passer à la partie payement.
 Un abonné : C’est un utilisateur authentifié qui a plus de privilèges que l’internaute
comme vendre et acheter des produits déposés dans le site.
 Un administrateur : C’est un utilisateur qui est chargé de l’administration du site.
 Un utilisateur : C’est un acteur fictif utilisé pour la modélisation et ne pouvant que
consulter et gérer son compte.
2. Diagramme de cas d’utilisation global
S'inscrire
Internaute <<include>>
Gérer son panier Editer la facture

Consulter le site <<include>>
Acheter un produit Payer

<<include>>
Gérer sa boutique <<include>>
Abonné <<include>>
Visualiser l'historique <<include>>

de ses ventes
S'authentifier

de ses achats
Commenter un
produit
<<include>>
Utilisateur Gérer son compte

<<include>>
Administrer le site
<<include>>

Administrateur de toutes les ventes
Figure 1: Diagramme de cas d’utilisation global
11
Ce diagramme représente les activités globales de chaque utilisateur dans notre application.
Un internaute doit pouvoir assurer les activités suivantes :
 Consulter les rubriques du site

 Gérer son panier
 S’inscrire.
Un abonné doit pouvoir assurer aussi les activités suivantes :
 Acheter un ou des produits après le remplissage de son panier.

 Gérer son compte : (mettre à jour ses informations personnelles …).
 Gérer sa boutique : C’est la partie liée à la vente des produits, un abonné doit avoir au
moins une boutique pour pouvoir ajouter/déposer un nouveau produit, le modifier ou
le mettre à jour et peut également consulter les produits associés à chaque boutique…
Un administrateur a les mêmes activités qu’un abonné sauf l’achat et la vente des produits
mais il peut aussi administrer le site (voir diagramme détaillé « administration du site »).
12
3- Raffinement du diagramme de cas d’utilisation relatif à la

consultation du site
Cette partie consiste à définir les fonctionnalités que tous les utilisateurs peuvent faire sans
s’authentifier.
Rechercher par
nom
Rechercher par
Abonné Contacter un catégorie
administrateur
<<extend>>
Rechercher par
Rechercher
prix
produits
<<extend>>
Rechercher
par boutique
Utilisateur
<<extend>>
Visualiser les
Consulter le site
produits
Trier produits
Administrateur <<extend>>
Trier par prix Trier par date
Internaute
Figure 2: Diagramme de cas d’utilisation relatif à la consultation du site
4- Raffinement du diagramme de cas d’utilisation relatif à l’achat des

produits
Pour acheter un produit, un abonné doit bénéficier d’un certain nombre de fonctionnalités
comme le montre le diagramme de cas d’utilisation ci-dessous
<<include>>
Editer la facture Payer
Acheter un produit
Abonné
<<include>>
<<include>> <<include>>
Gérer son
panier
Internaute
S'authentifier
<<extend>>
<<extend>>
<<extend>>
Changer la quatité
d'un ou de plusieurs
Supprimer un <<extend>>
produits
produit
Vider le panier
Ajouter un produit
Figure 3: Diagramme de cas d’utilisation relatif à l’achat des produits
13
Pour acheter un produit, l’abonné doit ajouter le ou les produits à acheter dans son panier, il
peut ainsi modifier la quantité des produits ajoutés, vider son panier ou supprimer un produit
ajouté. Un abonné passe ensuite à l’étape de payement.
Un internaute peut aussi ajouter des produits dans son panier comme l’abonné mais il ne peut
passer à l’étape de payement que lorsqu’il s’authentifie.
Description textuelle :
 Cas d'utilisation "Achat d’un produit"
Titre : Acheter un produit

Objectif : Acheter un produit déposé dans le MarketPlace.
Acteur : Abonné
Pré-condition : L’abonné s’est authentifié.
Enchaînement nominal :
1- Un abonné accède à la liste des produits déposés dans le site.
2- Le système affiche la liste des produits déposés dans le site.
3- L’abonné ajoute un produit dans son panier.
4- L’abonné confirme.
5- Le système demande de saisir les informations nécessaires pour le paiement
6- L’abonné saisit les informations nécessaires pour le paiement.
7- Le système traite le paiement de l’abonné.
8- Le système enregistre la commande.
9- Le système affiche un message de confirmation.
10- Le système envoie une facture.
Post condition : Produit acheté et envoi d’une facture.
Enchaînement alternatif :
A1 : Le panier est vide
L’enchaînement A1 démarre au point 5 du scénario nominal
5- Le système affiche un message d’erreur qui informe que le panier est vide.
Le scénario nominal reprend au point 1.
A2 : Les informations relatives au paiement sont erronées
L’enchaînement A2 démarre au point 7 de l’enchaînement nominal
7-Le système affiche un message d’erreur
14
Le scénario nominal reprend au point 5

Enchaînement d’erreur :
E1 : Les informations introduites sont définitivement erronées ou la transaction n’est
pas autorisée
L’enchaînement E1 démarre au point 7 de l’enchaînement nominal
7- Le système affiche un message d’erreur que les données sont erronées pour la
troisième fois
Le système annule l’achat : le cas d’utilisation se termine en échec
4- Raffinement du diagramme de cas d’utilisation relatif à la vente des

produits
Supprimer sa
<<extend>> boutique
Ajouter une
boutique
<<extend>>
Modifier une
<<extend>> boutique
Consulter ses <<extend>> Ajouter un

<<extend>> boutiques
produit
Gérer ses boutiques <<extend>>

Consulter ses
produits
Abonné
<<extend>> <<extend>> Mettre a jour un

Gérer ses produit
produits
<<extend>> Supprimer un
produit
S'authentifier
<<include>>
Attribuer un prix
<<extend>> promotionnel à un
produit
Figure 4: Diagramme de cas d’utilisation relatif à la mise en vente des produits
Pour déposer un produit à vendre, un abonné doit avoir au moins une boutique associée à son
compte, sinon il doit en créer une, après il peut soit supprimer une de ses boutiques soit la
modifier. En consultant sa boutique, un abonné peut déposer autant qu’il veut de produits à
vendre, il peut ainsi modifier ses produits déjà déposés ou les supprimer ou leur attribuer des
prix promotionnels.
15
Description textuelle :
 Cas d'utilisation "Déposer un produit dans le site"
Titre : Déposer un produit dans le site.

Objectif : Ajouter un produit dans le site pour le vendre.
Acteur : Abonné
Pré-condition : L’abonné s’est authentifié.
Enchaînement nominal :
1- L’abonné demande d’accéder à sa liste des boutiques.

2- Le système affiche l’espace de la liste des boutiques.
3- L’abonné sélectionne une boutique pour déposer un produit.
4- Le système affiche l’espace d’ajout d’un produit en vente.
5- L’abonné saisit les informations de son produit à déposer.
6- Le système vérifie que les données introduites sont correctes et que le produit
n’existe pas
7- Le système ajoute le produit.
8- Le système affiche un message de confirmation.
Post condition : Produit ajouté
Enchaînement alternatif :
A1 : La boutique n’existe pas
4- L’abonné demande d’ajouter une boutique
5- Le système affiche la page d’ajout d’une boutique.
6- L’abonné saisit les informations nécessaires pour l’ajout de sa boutique.
7- Le système affiche un message de confirmation d’ajout de la boutique.
A2 : Les données du produit saisi sont erronées
7-Le système affiche un message d’erreur
16
5- Raffinement du diagramme de cas d’utilisation relatif à

l’administration du site
Pour le bon fonctionnement du site, un administrateur est nécessaire et a des fonctionnalités
comme suit :
Désactiver un Contacter un
Désactiver abonné abonné
une boutique
<<extend>> Consulter la liste

<<extend>> des abonnés
Désactiver un
produit
<<extend>> <<extend>>
<<extend>> Consulter les

<<extend>> catégories
Gérer un abonné
<<extend>>
<<extend>> Ajouter une
catégorie
Administrer le site
Administrateur
<<extend>> <<extend>> Modifier une
Gérer les catégories
catégorie
<<extend>> Supprimer une

catégorie
<<include>> S'authentifier
Visualiser l'historique
de toutes les ventes
Figure 5: Diagramme de cas d’utilisation relatif à l’administration du site
Dans notre site, un administrateur peut supprimer un utilisateur, supprimer un produit ou une
boutique, consulter l’historique des ventes et des achats de tout les utilisateurs, gérer les
catégories des ventes des produits.
17
6- Raffinement du diagramme de cas d’utilisation relatif à la gestion

du compte
<<extend>> Modifier son mot

Abonné de passe
<<include>>
Gérer son compte S'authentifier
Utilisateur
<<extend>> Mettre à jour les

informations
personnellles
Administrateur
Figure 6: Diagramme de cas d’utilisation relatif à la gestion du compte
L’abonné et l’administrateur peuvent gérer leur compte en modifiant leur mot de passe ou en
modifiant leurs informations personnelles, ils doivent bien sûr être authentifiés pour accéder à
ces interfaces.
18
III- Diagrammes de séquence
Les diagrammes de séquences sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique.
1- Raffinement du diagramme de séquence relatif à l’authentification

Pour pouvoir vendre ou acheter un produit du site un utilisateur doit s’authentifier en
respectant les démarches d’authentification suivantes :
Systéme
Abonné
1: Saisir login et mot de passe
2: Vérification
alt [Utilisateur existant]

3: Message de confiramtion d'
authentification
[Utilisateur non existant]

loop [Utilisateur non existant]
4: Message d'erreur
5: Saisir login et mot de passe
6: Vérification
7: Accés à l'application
Figure 7: Diagramme de séquence relatif à l’authentification
19
2- Raffinement du diagramme de séquence relatif à l’achat d’un

produit
Système
Abonné
1: Consullter les produits à vendre
loop [Pour chaque produit ]
2: Ajouter un produit au panier
3: Enregistrement de la commande ()
4: Saisir informations de payement

5: Vérification
alt [Erreur de paiement]

6: Message d'erreur de paiement
[sinon] 7: Traitement du payement ()
8: Confirmation de payement
9: Envoi d'une facture
Figure 8: Diagramme de séquence relatif à l’achat d’un produit
En achetant un produit l’abonné doit pouvoir remplir son panier d’autant de produits qu’il
veut, puis confirmer et passer à l’étape de payement où il va insérer les informations
nécessaires pour son payement, une fois payé une facture est envoyée à son compte
comportant la liste des produits achetés et le montant total.
20
3- Raffinement du diagramme de séquence relatif à la mise en vente

d’un produit
DiagrammeSequence_1
Système
Abonné
1: Ouvrir une boutique
2: Saisir les informations de la boutique
3: Vérification
alt [Boutique existante]

4: Message d'erreur
[sinon] 5: Ajout de la boutique
6: Message de confirmation
loop [Pour chaque produit]

7: Demande d'ajout d'un produit
8: Saisir les informations du produit à
ajouter 9: Vérification
alt [Erreur d'ajout]

10: Message d'erreur
[sinon]
11: Ajout du produit
12: Produit ajouté
Figure 9: Diagramme de séquence relatif à la mise en vente d’un produit
21
Pour déposer un produit à vendre dans le site un abonné doit avoir au moins une boutique à
lui-même, sinon, il accède à l’interface d’ajout des boutiques et il y ajoute puis, il accède à
l’interface d’ajout de produit et il dépose son produit.
Conclusion
La spécification des besoins nous a permis de déterminer les principales fonctionnalités de
notre système à travers la présentation des besoins fonctionnels et non fonctionnels, les
diagrammes de cas d’utilisation et de séquences. Par la suite, il est indispensable de passer à
l’étape de conception.
22
CHAPITRE III CONCEPTION
Chapitre III : Conception
Introduction
La conception est une phase importante dans la réalisation d'un projet. Elle permet de
décomposer le système en sous systèmes ce qui facilite la définition des phases
d'implémentation, de validation et de maintenance.
Dans ce chapitre, nous présentons le patron de conception de l’application, la conception
générale et la conception détaillée de l’application.
I- Conception générale
1- Patron de conception adopté
1.1- Présentation de MVC

MVC acronyme de Modèle-Vue-Contrôleur est un patron de conception (design pattern en
anglais) très répandu pour réaliser des sites web. Ce patron de conception est une solution
éprouvée et reconnue permettant de séparer l’affichage des informations, les actions de
l’utilisateur et l’accès aux données.
C’est un patron qui a été conçu au départ pour des applications « client lourd », dont la
majorité des données sont traitées sur le poste client. MVC était tellement puissant pour ces
applications « client lourd », qu’il a été massivement adopté comme modèle pour la création
d’applications web « client léger ». [5]
Le modèle MVC est constitué des éléments suivants :
- Le Modèle : représente la couche métier d’une application, présentant des classes

permettant de créer les objets contenant des données métier manipulées par
l’application au travers de traitements, constituant les services métiers.
- La Vue : elle constitue les éléments d’interface utilisateurs : pages web, contrôles
Web…
23
CHAPITRE III : CONCEPTION
- Le Contrôleur : permettant de piloter l’application, il interprète les actions à réaliser et

ordonne leur exécution (lecture, traitement de données et mises à jour). [6]
MVC n’est pas associé à un langage de programmation, il peut être utilisé avec énormément
de langages. MVC est beaucoup utilisé avec PHP par exemple ou même JAVA. En général
MVC agit comme une couche supplémentaire (qu’on appelle un « Framework ») qui vient se
greffer par-dessus un langage. C’est le cas pour ASP.NET MVC qui est une couche
supplémentaire à ASP.NET. [5]
Figure 10: Architecture du patron MVC
1.2- Choix de MVC

Concernant le choix de MVC pour réaliser ce projet nous allons citer ses avantages et ses
inconvénients, commençons d’abord par son unique inconvénient, qui n’en est souvent pas un
d’ailleurs : MVC apporte un découpage qui demande une certaine gymnastique mentale et qui
multiplie le nombre de fichiers. Donc MVC s’avère souvent disproportionné pour des tous
petits sites qui n’évoluent jamais. Mais comme il y a peu de sites de ce genre, cet
inconvénient est assez minime.
Concernant ses avantages, MVC permet également de concevoir des applications de manière
claire et efficace grâce à la séparation des intentions. Les opérations de maintenance et de
mise à jour sont fortement simplifiées, et on évite plus facilement le syndrome du plat de
spaghetti où la moindre modification à un endroit risque de provoquer des débordements à
d’autres endroits tellement tout est emmêlé.
MVC permet également de répartir plus facilement les tâches entre développeurs. Rares sont
les personnes qui sont capables de transformer des règles métiers complexes en code efficace
tout en étant expertes en design web, que ce soit pour PC, tablette, ou Smartphone… Le
découpage permet à un développeur de s’occuper des règles métiers complexes et à un
designer de faire du beau HTML ergonomique.
24
2- Diagramme de paquetages
Dans ce projet, notre application se présente sous forme de 3 paquetages :
Contrôlleur Vue
Modéle
Figure 11: Diagramme de paquetage MVC
Le contrôleur s’exécutant, peut faire appel au modèle pour consulter la base de données,
exécuter des traitements métiers ou mettre à jour des données… Puis le contrôleur demande à
la vue de s’exécuter, afin de présenter des données à l’utilisateur et recueillir ses futures
demandes.
II- Conception détaillée
1- Présentation du paquetage « Modèle »

Il s’agit des données et de l’état de l’application web. En général, ces données sont
représentées par un ensemble de classes qui permettent d’accéder à une base de données.
1.1- Règles de gestion

Les principales règles de gestion sont :
- Un produit est associé à une seule catégorie.
- Une catégorie peut avoir zéro ou plusieurs produits.
- Un produit peut faire l’objet de zéro ou plusieurs commentaires.
- Un commentaire est associé à un seul produit.
- Un utilisateur peut faire zéro ou plusieurs commentaires.
- Un commentaire est associé à un seul utilisateur.
- Un produit appartient à une seule boutique.
- Une boutique peut avoir zéro ou plusieurs produits.
- Un produit est associé à zéro ou plusieurs paniers.
- Un panier peut contenir zéro ou plusieurs produits.
- Un panier est associé à un seul utilisateur.
25
- Un utilisateur peut remplir zéro ou plusieurs paniers.

- Un utilisateur peut créer zéro ou plusieurs boutiques.
- Une boutique est associée à un seul utilisateur.
1.2- Présentation des classes

Une classe représente la structure d'un objet, c'est-à-dire la déclaration de l'ensemble des
entités qui le composent. Elle est constituée d'attributs dont les valeurs représentent l'état de
l'objet et des méthodes qui sont les opérations applicables aux objets.
Notre application comporte les classes suivantes :
 Account : contient les informations d’un utilisateur de l’application tel que le nom le
pays, téléphone,…
 Product : contient les informations d’un produit déposé dans le site.
 Category : contient les informations d’une catégorie des produits déposés.
 Shop : contient les informations d’une boutique associée à chaque utilisateur.
 Picture : contient les informations d’une image associée à un produit donné.
 ShoppingCart : contient les informations du panier associé à chaque utilisateur.
 Order : contient les informations d’une commande d’un utilisateur.
 OrderDetail : contient les informations détaillées d’une facture.
 Contact : contient les informations de l’ensemble des contacts associés à une
boutique.
 Comment : contient les informations d’un commentaire associé à un produit.
1.3- Diagramme de classe
Le diagramme de classe identifie la structure des classes d’un système, y compris les
propriétés et les méthodes des classes. Les diverses relations, qui peuvent exister entre les
classes y sont également représentées. [7]
26
appartenir Category
Product - CategorieId : int
1..1
- ProductId : int 0..* - Name : string
- Designation : string
- Price : Float
- Quantity : int
- Promotion : Float 1..1
Comment
- Description : string 0..*
0..* - CommentId : int
avoir - InsertionDate : DateTime
- CommentText : string
- PublishDuration : DateTime 0..* faire
- CommentDate : DateTime
- IsAuthorized : Boolean
Pictures
1..5 1..1
- PictureId : int
- PicLink : string
0..*
Panier_Produit
- Count : int
0..*
OrderDetails
1..1
- OrderDetailId : int
Cart
Appartenir - Quantity : int
- UnitPrice : int - RecordId : int Account
- DateCreated : DateTime - UserId : int
+ GetCart () - role : string
1..1 + AddToCart () - FirstName : string
1..1 + RemoveFromCart () - LastName : string
Order + EmptyCart () 0..* - MailAddress : string
+ GetCartItems () Remplir - Passwd : string
- OrderId : int
+ GetCount () - Address : string
- Total : float + GetTotal () - PostalCode : int
1..1
1..1 - OrderDate : Date + CreateOrder () - Country : string
+ GetCartId () - State : string
Shop + MigrateCart () - City : string
...
- ShopId : int 0..1 avoir 1..1
- ShopName : string
- Adress : string
0..* 1..1
- IsAuthorized : Boolean
Créer
Figure 12: Diagramme des classes
Modèle relationnel :
Après avoir établit notre diagramme de classes, nous déduisons le modèle relationnel, placé
en annexe B.
2- Présentation du paquetage « Contrôleur »
Le contrôleur fait le lien entre la vue et le modèle. Il gère les interactions avec l’utilisateur et
détermine quels traitements doivent être effectués pour une action donnée. D’une manière
générale, il va utiliser les données du modèle, les traiter en fonction de l’action de
l’utilisateur, et les envoyer à la vue afin qu’elle les affiche.
La liste des contrôleurs de notre application sont:
 AccountController.cs : Contrôle les opérations faites sur le compte d’un utilisateur.

 AdministratorController.cs : Contrôle les opérations faites par l’administration du
site.
 CommentsController.cs : Contrôle les commentaires associés à chaque produit.
 CategorieController.cs : Contrôle les opérations faites sur une catégorie comme
l’ajout, la modification, la suppression…
27
 CheckoutController.cs : Ajoute les informations d’un produit acheté et du panier dans

la table Order.
 HomeController.cs : qui contrôle l’affichage par défaut de la page d’accueil.
 PayPalController.cs : qui fait l’enregistrement des instructions nécessaires pour payer
une commande.
 SearchController.cs : Contrôle les opérations faites pour la recherche d’un produit
déposé dans le site.
 ShopController.cs : Contrôle les opérations faites sur une boutique d’un utilisateur
comme l’ajout, la modification, la suppression…
 StoreController.cs : Contrôle les recherches des produits d’une catégorie.
 ShoppingCartController.cs : Contrôle les opérations faites sur le panier d’un
utilisateur comme l’ajout d’un produit, la quantité des produits dans le panier, prix
totale …
 ProductController.cs : Contrôle les opérations faites sur un produit comme l’ajout, la
modification, la suppression…
Figure 13: Liste des classes contrôleurs de l’application
3- Présentation du paquetage « Vue »

La vue traite de ce qu’on voit à l’écran dans le navigateur web. Il s’agit globalement de code
HTML et de CSS. Le but de la vue est de présenter les données issues du modèle mais sans
les modifier et sans interpréter le contenu.
28
La liste des views de notre application consiste à :
 Account : qui contrôle l’affichage de toutes les interfaces du compte d’un abonné.
 Administrator : qui contrôle l’affichage des interfaces de l’administration.
 Categorie : qui contrôle l’affichage de toutes les interfaces d’une catégorie (Ajout,
Modification, Suppression)
 Checkout : qui affiche la liste des produits à acheter pour passer à la partie paiement.
 Home : qui contrôle l’affichage de toutes les interfaces de l’accueil.
 PayPal : qui contrôle l’affichage des interfaces de PayPal.
 Search : qui contrôle l’affichage des produits recherchés.
 Shared : qui fait le contrôle du graphique (header, footer …)
 Shop : qui contrôle l’affichage de toutes les interfaces d’une boutique (Ajout,
 ShoppingCart : qui fait le contrôle graphique d’un panier.
 Store : qui fait le contrôle de la recherche d’un produit dans une catégorie.
 StoreManager : qui contrôle l’affichage de toutes les interfaces d’un produit (Ajout,
29
4- Diagrammes d’interaction
4.1- Diagramme de séquence « Ajouter catégorie »

EA 6.5 Unregistered
sd Test Model Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
Administrator Catégorie Create CategorieController Categorie
Afficher les catégories
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version

Index () EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
Categorie
List <categorie>
Liste des catégories
Affichage des catégories
EA 6.5 Unregistered Trial Version

Demande EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
d'ajout de catégorie
Create (categorie)
Confirmation
Affichage de l'interface d'ajout

Saisir les informations correspondantes
Create()
Demander un ajout
Vérification
alt Create New ()
[Pas d'erreur]
Confirmation
Confirmation
Affichage de la nouvelle liste des
EA 6.5 Unregistered catégories

Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
[Sinon]
Erreur
Erreur
EA 6.5 Unregistered Trial Version Message

EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
d'erreur
Figure 14: Diagramme de séquence « ajouter catégorie »
Le diagramme illustré par la figure16 indique l’enchaînement pour ajouter une catégorie.
L’ajout d’une catégorie passe par 3 principales étapes :
L’administrateur
EA 6.5 Unregistered demande
Trial Version EA 6.5l’affichage
UnregistereddeTrial
la Version
liste desEAcatégories, la Trial
6.5 Unregistered vue Version
correspondante
EA 6.5 Unregistered Tria
« Categorie/Index» envoie les informations de la page demandée au contrôleur
« CategorieController » qui va récupérer les informations des catégories à partir de l’entité
« Categorie » et les renvoie à la vue « Categorie » pour l’afficher.
L’administrateur
EA 6.5 Unregistered demande
Trial Version ensuite
EA 6.5 l’ajout Trial
Unregistered d’uneVersion
catégorie, la vue
EA 6.5 « Categorie/Create
Unregistered Trial Version » EA
envoie
6.5 Unregistered Tria
les informations
EA 6.5 Unregistered saisiesEA
Trial Version au6.5
contrôleur desTrial
Unregistered catégories
Version «EA
CategorieController
6.5 Unregistered Trial» Version
pour créer uneUnregistered Tria
EA 6.5
30
nouvelle entité catégorie au niveau du modèle, ce dernier vérifie que les informations entrées
sont valides puis soit il insère une nouvelle catégorie dans l’entité « Categorie » soit il renvoie
un message d’erreur.
4.2- Diagramme de séquence « Ajout d’un produit »

EA 6.5Model
sd Test Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
Abonné ProductManager Create Shop/Create ProductManagerController ShopController Product Shop
Demande d'ajout de produit
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered TrialCreate

Version
() EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
Confirmation
EA 6.5 Unregistered Trial Version
Interface d'ajout EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
EA 6.5 Unregistered Trial

Saisie des Version
informations EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
correspondantes
Create (Product)
EA 6.5
alt
Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
Envoi d'une requete d'ajout
Creation
[Boutique existe]
Confirmation
List <Product>
Affichage de la Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
nouvelle
liste des produits
Redirection
Iterface d'ajout de boutique
EA 6.5 Unregistered TrialSaisie

Version EA 6.5
des informations Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
correspondantes
Create ()
Envoi d'une requete d'ajout Vérification
[Sinon]
EA 6.5optUnregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
[Erreur]
EA 6.5 Unregistered
loop Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
Erreur
[Erreur d'ajout] Erreur
EA 6.5 Unregistered Trial Version EAd'erreur

Message 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
Saisie des nouvelles informations correspondantes
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Create
Unregistered
() Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
Envoi d'une requete d'ajout Vérification
CreateNew ()
Confirmation
EA 6.5 Unregistered Interface

Trial Version EA 6.5 Unregistered Trial VersionRedirection
d'ajout de produit
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria

Saisie des Version
informations EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
correspondantes
Create (Product)
Vérification
alt
EA 6.5[erreur
Unregistered
]
Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
loop
Erreur
[Erreur d'ajout]
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version
Erreur EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
Message d'erreur
Saisir informations correspondantes
Create (Product)
Vérification
[Pas d'erreur]
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered
CreateNew () Trial Version EA 6.5 Unregistered Tria
Confirmation
Redirection
EA 6.5 Unregistered
Affichage de laTrial
nouvelleVersion EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
liste des produits
EA 6.5 Unregistered Trial Version EAFigure

6.5 Unregistered Trial Version
15: Diagramme EA 6.5 Unregistered
de séquence « ajouter Trial Version» EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Tria
produit
31Unregistered Tria
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5
Le diagramme illustré par la figure16 indique l’enchaînement pour ajouter un produit. L’ajout
d’un produit passe par 2 principales étapes :
L’abonné demande l’ajout d’un produit, la vue correspondante « ProductManager » envoie

les informations saisies au contrôleur des produits « ProductManagerController » pour créer
une nouvelle entité « Product » au niveau du modèle.
Si l’abonné n’a pas de boutique, le contrôleur le redirige vers l’interface d’ajout des
boutiques, une fois la boutique ajoutée l’abonné peut continuer l’ajout des informations de
son produit.
L’entité vérifie que les informations entrées sont valides puis soit l’abonné est redirigé vers la
liste de ses produits où il va trouver son nouveau produit soit il reçoit un message d’erreur.
Conclusion
Au niveau de ce chapitre, nous avons présenté la phase de conception qui a permis de faciliter
la phase de la réalisation de notre site web.
32
CHAPITRE IV : REALISATION
Chapitre IV : Réalisation
Introduction
Dans ce chapitre, nous abordons, en premier lieu, l’environnement matériel et logiciel utilisés
pour développer notre site web. En deuxième lieu, nous détaillons le déploiement de
l’application avant de présenter les principales interfaces. Ensuite nous enchaînons avec
l’implémentation et nous clôturons ce chapitre avec le planning de notre projet.
I- Environnement de développement
La présentation de l’environnement de développement de notre site web comporte une

description de l’environnement matériel et logiciel ainsi que des frameworks et bibliothèques
utilisées.
1- Environnement matériel
L’application a été développée sur une machine ayant les caractéristiques suivantes :
 Marque : Toshiba
 Processeur : Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
 Mémoire : 4 GB
 Disque dur : 500 Go
2- Environnement Logiciel
Ces sont les outils logiciels utilisés pour le développement du site web, de la base de données
et la modélisation des différents diagrammes de conception :
 Environnement de développement : Visual Studio 2012

 Système de gestion de bases de données : SQL Server 2012
 Outils de modélisation : PowerAMC 15.1 et Entreprise Architect 6.5 (Unregistered
Trial Version)
 Serveur web IIS
 Outil de planification : MS Project 2010
CHAPITRE4 : REALISATION
3- Framework et bibliothèques utilisées

3.1- ASP.Net MVC 4
Le Framework ASP.NET MVC fournit une alternative au modèle de formulaires Web

ASP.NET, en permettant la création d'applications web basées sur MVC.
Le Framework ASP.NET MVC est un Framework de présentation léger, facilement testable,
qui (comme pour les applications utilisant les Formulaires Web) est intégré avec les
fonctionnalités ASP.NET, dont les pages maîtres et les mécanismes d'authentification [11].
3.2- Entity Framework
L’Entity Framework est une technologie intégrée à ADO.Net qui fait le Mapping Objet
Relationnel et qui permet de développer des applications de gestion de données, sans se
soucier de la conception du schéma de base de données devant contenir les données de
l’application. Le développeur ne sera plus obligé de baser la conception de son application sur
le modèle logique de données, mais sur le modèle conceptuel, prenant ainsi de la distance
avec la manière dont les données sont stockées dans la base de données. [9]
II- Déploiement de l’application

Le diagramme de déploiement décrit la disposition physique des ressources matérielles qui
composent le système et montre la répartition des composants sur ces matériels. Chaque
ressource étant matérialisée par un nœud, le diagramme de déploiement précise comment les
composants sont répartis sur les nœuds et quelles sont les connexions entre les composants ou
les
EA nœuds.
6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial V
EA figure
La 6.5 Unregistered
suivanteTrial Version
illustre EA 6.5 Unregistered
le déploiement Trial application.
de notre Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial V
EA 6.5 Unregistered
deployment Deployment Model Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial V
EA 6.5 Unregistered
«device» Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial«device»
«device» Version EA 6.5 Unregistered Trial V
PC Serv eur Application
Serv eur BDD
EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial V
Nav igateur Serv eur w eb IIS
Base de données SQL
EA 6.5 UnregisteredExpress
EA 6.5 Unregistered Trial Version HTTP Trial Version EA 6.5 Unregistered Trial Serv
TCP/IP Version
er EA 6.5 Unregistered Trial V
* 1 1 1
Application w eb
Figure 16:Diagramme de déploiement
III- Principales interfaces de l’application

Dans cette partie nous allons présenter nos principales interfaces à travers 3 scénarios relatifs
à la mise en vente d’un produit, l’achat d’un produit et l’administration de l’application.
1- Interface d’accueil
La page d’accueil de l’application se présente, comme l’indique la figure 17, à travers laquelle
l’utilisateur peut choisir un produit selon une catégorie spécifiée (1) ou à travers l’interface de
recherche (2), (3). L’internaute peut également ajouter des produits dans son panier puis
s’authentifier en introduisant son login et son mot de passe (4) ou s’inscrire (5) pour procéder
à l’achat.
Figure 17: Liste des principales interfaces d’un internaute

2- Scénario d’ajout de produit

Pour déposer un produit à vendre dans le site, un abonné doit avoir au moins une boutique
pour l’associer à ses produits. Une fois un produit est ajouté, l’abonné peut ainsi accéder à
l’interface d’ajout de produit (1), il doit également saisir les informations nécessaires de ce
produit comme son nom, sa description, son prix … Après l’abonné passe à l’interface d’ajout
des images et fait des drag and drop des images qu’il désire ajouter (2) … comme le montre la
figure 18.
Figure 18:Liste des interfaces pour la mise en vente d’un produit
3- Scénario d’achat d’un produit

Pour acheter un produit, un abonné doit remplir son panier des produits (1), il peut ainsi
accéder à l’interface de son panier pour modifier la quantité d’un produit ajouter ou supprimer
un produit de sa liste (2), sinon il confirme sa liste des produits à acheter et il passe à
l’interface de paiement PayPal (3) comme le montre la figure 19.
Figure 19: Liste des interfaces pour l’achat d’un produit
4- Scénario associé à l’administration de l’application

Un administrateur peut administrer le site à travers les principales interfaces comme le montre
la figure 20, il peut soit gérer les catégories (Ajouter, supprimer ou modifier) (1), soit
désactiver un abonné (2), désactiver une boutique ou désactiver un produit déposé (3).
Figure 20: Liste des principales interfaces de l’administration

IV- Implémentation
Dans cette partie, nous allons expliquer un bout de code écrit en ASP.Net MVC qui fait partie
de l’environnement Visual Studio 2012.
La figure ci-dessous explique comment faire une recherche d’un produit, d’une boutique,
d’une catégorie ou tous ensembles en même temps :
Figure 21: Extrait de code de la recherche d’un produit
V- Planification du projet
Nous présentons dans ce qui suit, le planning de réalisation de notre projet en utilisant le
diagramme de GANTT qui présente un planning présentant une liste de tâches en colonne et
en abscisse l'échelle de temps retenue. Il permet ainsi de visualiser facilement le déroulement
du projet.
Figure 22: Planification du projet
Conclusion
Ce dernier chapitre nous a permis de présenter quelques interfaces réalisées de l’application
selon le profil de l’utilisateur après avoir décrit notre environnement de travail matériel et
logiciel ainsi que la spécification du langage de développement utilisé et du déploiement de
l’application.
Conclusion générale
Au terme de notre projet de fin d’études, nous avons développé une application de type
MarketPlace qui permet à un abonné de vendre et d’acheter n’importe quel type de produit en
ligne.
L’élaboration de ce travail est passée par toutes les étapes constituant le cycle de vie d’un
site web dynamique. Nous avons commencé par l’acquisition de données nécessaires à la
compréhension du projet et l’expression des besoins. Puis, dans un second lieu, nous avons
réalisé une spécification pour exprimer les besoins fonctionnels et non fonctionnels. Ensuite,
nous avons réalisé une conception bien détaillée selon les diagrammes du langage de
modélisation UML et nous avons fait la partie réalisation pour présenter les principales
interfaces de notre site.
Les difficultés surmontées tout au long de la réalisation du projet ont constitué un défi
pour acquérir de nouvelles connaissances techniques. Ces difficultés concernent notamment
l’utilisation et la maîtrise du Framework ASP.net MVC et d’Entity Framework.
Ce projet nous a donné l’opportunité de manipuler des techniques innovantes et évolutives

et nous a permis aussi de tester et d’appliquer nos connaissances acquises au sein de l’Institut
Supérieur des Etudes Technologiques de Charguia et de les améliorer.
Bibliographie et Nétographie
[1] :http://blog.iziflux.com/2014/05/19/comparatif-des-marketplaces-laquelle-la-plus-
avantageuse-pour-marchand-2086698 : étude comparative de quelques Marketplace.
[2] : http://fr.wikipedia.org/wiki/ « nom du MarketPlace »
[3] :http://www.annapika.com/comparaison-entre-etsy-dawanda-a-little-market-et-siandso/ :
étude comparative de quelques Marketplace.
[4] : Pascal, Roques. « UML par la pratique », Paris, éditions Eyrolles, 2009.
[5] : http://openclassrooms.com/courses/apprendre-asp-net-mvc/le-pattern-mvc
[6] : Dotnet France : ASP.Net MVC : Présentation « http://www.dotnet-

france.com/Documents/Web/MVC/Pr%C3%A9sentation%20ASP%20.NET%20MVC »
[7] : http://toubkalit.com/chapitre/85944Suite_2
[8] : https://drive.google.com/file/d/0B65ukNIIimPlSEJseFMxSHhJdUU
[9] :http://www.dotnetfrance.com/Documents/ADOLinq/Presentation%20du%20Framework
%20Entity
[10] Brice-Arnaud GUERIN, « ASP.NET 4.5 avec C# sous Visual Studio 2012 », France,
Editions ENI, 2013, 574p.
[11] : http://www.alexa.com/topsite
ANNEXE
Annexe A :
Cahier de charges
Projet de Fin d’Etudes

Cahier des Charges
1. Nom & Prénom des étudiants

Rami BEN HAJ YAHIA & Aledine AWADHI
2. Organisme d’accueil
Tunisian International Technologies (T.I.T).
3. Tuteur au sein de l’organisme d’accueil

Nom et Prénom : Mr EL ASMI TAREK
Fonction : Directeur technique
Téléphone : 96 37 91 01
Fax : 71 90 63 63 Email : [email protected]
Adresse de l’organisme : Espace Tunis, Bloc H, bureau H3-1, 1073 Mont plaisir – Tunis.
4. Intitulé du projet
Conception et développement d’un site de type Marketplace.
5. Cadre général du travail

Il s’agit de la création d’un site de E-commerce dédié au marché étranger.
L’objectif est de mettre en place une plateforme (Marketplace) qui permettra aux potentiels
clients (Abonnés) d’interagir entre eux dans un cadre commercial. Des exemples tels que EBay,
Kaymu, Etsy nous permettent de mieux nous situer dans le contexte.
Le site devrait permettre de publier des produits pour la vente, d’acheter en ligne et garantir
la sécurité des transactions.
L’efficacité, la sécurité, la simplicité (ergonomie, rapidité, etc.)… sont des facteurs de réussite
majeurs qu’il faut bien soigner pour pouvoir se démarquer et être le plus compétitif possible.
6. Travail demandé
Dans cette partie, nous définirons les fonctionnalités qui doivent être fournis par le
Marketplace.
- Consultation du site :
 Visualiser les produits.
 Rechercher des produits selon différents critères.
 Trier les résultats de recherche par :
1- Catégorie.
2- Date d’ajout.
3- Prix.
4- Vendeur.
- Accès au compte de l’abonné :
 S’inscrire.
 Gérer son compte :
3- Modifier les informations personnelles.
4- Modifier/ récupérer mot de passe.
5- Faire le suivi des ventes en cours.
6- Visualiser l’historique des ventes et des achats.
- Vente de produits :
La mise en vente englobe la gestion des produits, qui consiste à :
4- Ajouter/ Mettre à jour un produit.

5- Gérer son stock de produits.
6- Supprimer un produit.
- L’achat ce fait en plusieurs étapes :

 Gérer le panier :
4- Ajouter/ supprimer un produit depuis le panier.
5- Modifier la quantité du/des produit(s) dans le panier.
 Acheter un/des produit(s) qui consiste à payer.

 Editer la facture.
- Administration du site :
 Interagir avec un abonné :
1- Consulter la liste des abonnés.
2- Contacter un abonné.
3- Supprimer un abonné.
4- Supprimer un produit en vente.
 Gérer les catégories :
5- Consulter les catégories.
6- Ajouter une catégorie.
7- Modifier une catégorie.
8- Supprimer une catégorie.
 Consulter l'historique des ventes et des achats de tous les
utilisateurs.
 Définir les conditions de vente.
7. Environnement de Travail
Environnement matériel :
 Ordinateur : Laptop Samsung RV510.

 Processeur : Pentium® Dual-Core CPU T4500, 2.30 GHz.
 Carte graphique : Mobile Intel(R) 4 Series Express Chipset Family.
 Mémoire vive : 3.00 Go.
Environnement logiciel :
 Système d’exploitation : Windows 7 64 bits Edition familiale premium.
 Environnement de développement : Visual Studio 2013.

i. Technologie: ASP.Net MVC 4.
ii. Langage de programmation : C Sharp.
 Système de gestion de base de données : SQL Server 2010.

 Outil de conception : Power AMC 15.
 Outil de gestion de projet : MS Project 2010.
8. Planning prévisionnel
Le Planning prévisionnel du PFE qui définit les grands axes de travail ainsi que la durée que doit
respecter chaque étape pour s’assurer le respect des délais.
Tuteur pédagogique L’organisme d’accueil

Cachet de l’organisme
Annexe B
Modèle relationnel
Product : (ProductId, Designation, Price, Quantity, Promotoin, Description,
InsertionDate, PublishDate, IsAuthorize, #CategorieId, #idboutique)
Category: (CategorieId, Name)
Picture: (PictureId, PicLink, #ProductId)
Shop: (ShopId, ShopName, contact, Address, IsAuthorized, #userid)
Cart: (RecordId, DateCreated, #userid, #OrderId)
Order: (OrderId, Total, OrderDate, #OrderDetailld)
OrderDetails: (OrderDetailld, Quantity, UnitPrice)
Panier_Produit : (count, #ProductId, #RecordId)
Account: (userid, role, FirstName, LastName, MailAddress, passwd, address, PostalCode,

Country, State, City)
Comment : (CommentId, CommentTexte, CommentDate, #idprod, #userid)

SOMMAIRE
Introduction générale ........................................................................................................................ 1
Chapitre I : Présentation du cadre général du projet ............................................................................... 2
Introduction ......................................................................................................................................... 2
I- Présentation de la société ......................................................................................................... 2
II- Etude de l’existant.................................................................................................................... 2
1- Etude comparative de quelques MarketPlaces ........................................................................................2
2- Critique des solutions............................................................................................................... 5
3- Présentation des solutions de paiement .....................................................................................................5
4- Solution proposée .............................................................................................................................................6
III- Méthodologie adoptée .............................................................................................................. 7
Conclusion........................................................................................................................................... 7
Chapitre II : Spécification des besoins .......................................................................................................... 8
Introduction ......................................................................................................................................... 8
I- Etude des besoins ..................................................................................................................... 8
1- Besoins fonctionnels ........................................................................................................................................8
2- Besoins non fonctionnels ............................................................................................................................ 10
II- Cas d’utilisation ..................................................................................................................... 10
1- Présentation des acteurs ............................................................................................................................... 11
3- Raffinement du diagramme de cas d’utilisation relatif à la consultation du site ....................... 13
4- Raffinement du diagramme de cas d’utilisation relatif à l’achat des produits ........................... 13
4- Raffinement du diagramme de cas d’utilisation relatif à la vente des produits ......................... 15
5- Raffinement du diagramme de cas d’utilisation relatif à l’administration du site .................... 17
6- Raffinement du diagramme de cas d’utilisation relatif à la gestion du compte ......................... 18
III- Diagrammes de séquence ....................................................................................................... 19
1- Raffinement du diagramme de séquence relatif à l’authentification ............................................. 19
2- Raffinement du diagramme de séquence relatif à l’achat d’un produit ........................................ 20
3- Raffinement du diagramme de séquence relatif à la mise en vente d’un produit ...................... 21
Conclusion......................................................................................................................................... 22
Chapitre III : Conception............................................................................................................................. 23
Introduction ....................................................................................................................................... 23
I- Conception générale............................................................................................................... 23
1- Patron de conception adopté ...................................................................................................................... 23
2- Diagramme de paquetages .......................................................................................................................... 25
II- Conception détaillée............................................................................................................... 25

1- Présentation du paquetage « Modèle » ................................................................................................... 25
2- Présentation du paquetage « Contrôleur » ............................................................................................. 27
3- Présentation du paquetage « Vue » .......................................................................................................... 28
4- Diagrammes d’interaction........................................................................................................................... 30
Conclusion......................................................................................................................................... 32
Chapitre IV : Réalisation .............................................................................................................................. 33
Introduction ....................................................................................................................................... 33
I- Environnement de développement ......................................................................................... 33
1- Environnement matériel .............................................................................................................................. 33
2- Environnement Logiciel .............................................................................................................................. 33
3- Framework et bibliothèques utilisées ...................................................................................................... 34
II- Déploiement de l’application ................................................................................................. 34
III- Principales interfaces de l’application ................................................................................... 35
1- Interface d’accueil ......................................................................................................................................... 35
2- Scénario d’ajout de produit ........................................................................................................................ 36
3- Scénario d’achat d’un produit.................................................................................................................... 36
4- Scénario associé à l’administration de l’application .......................................................................... 37
IV- Implémentation ...................................................................................................................... 38
V- Planification du projet ............................................................................................................ 38
Conclusion......................................................................................................................................... 39
Conclusion générale........................................................................................................................................ 40
Bibliographie et Nétographie ....................................................................................................................... 41
ANNEXE ........................................................................................................................................................... 42
Annexe A : ........................................................................................................................................ 42
Annexe B ........................................................................................................................................... 45
Table des figures
Tableau 1 : Analyse générale des sites de renommée ..............................................................................................4

Tableau 2: Sélection détaillée de quelques sites caractérisés par leurs succès dans le marché ...................5
Tableau 3: Liste des grands axes qui caractérisent notre site.................................................................................6
Figure 1: Diagramme de cas d’utilisation global .................................................................................................... 11
Figure 2: Diagramme de cas d’utilisation relatif à la consultation du site ...................................................... 13
Figure 3: Diagramme de cas d’utilisation relatif à l’achat des produits .......................................................... 13
Figure 4: Diagramme de cas d’utilisation relatif à la mise en vente des produits ........................................ 15
Figure 5: Diagramme de cas d’utilisation relatif à l’administration du site ................................................... 17
Figure 6: Diagramme de cas d’utilisation relatif à la gestion du compte ........................................................ 18
Figure 7: Diagramme de séquence relatif à l’authentification ............................................................................ 19
Figure 8: Diagramme de séquence relatif à l’achat d’un produit ....................................................................... 20
Figure 9: Diagramme de séquence relatif à la mise en vente d’un produit..................................................... 21
Figure 10: Architecture du patron MVC ................................................................................................................... 24
Figure 11: Diagramme de paquetage MVC .............................................................................................................. 25
Figure 12: Diagramme des classes .............................................................................................................................. 27
Figure 13: Liste des classes contrôleurs de l’application ..................................................................................... 28
Figure 14: Diagramme de séquence « ajouter catégorie » ................................................................................... 30
Figure 15: Diagramme de séquence « ajouter produit » ....................................................................................... 31
Figure 16:Diagramme de déploiement ....................................................................................................................... 34
Figure 17: Liste des principales interfaces d’un utilisateur ................................................................................. 35
Figure 18:Liste des interfaces pour la mise en vente d’un produit.................................................................... 36
Figure 19: Liste des interfaces pour l’achat d’un produit .................................................................................... 37
Figure 20: Liste des principales interfaces de l’administration .......................................................................... 37
Figure 21: Extrait de code de la recherche d’un produit ...................................................................................... 38
Figure 22: Planification du projet ................................................................................................................................ 39

Rapport - Rami BEN HADJYAHYA - Ala AWADHI

Transféré par

Droits d'auteur :

Formats disponibles

Rapport - Rami BEN HADJYAHYA - Ala AWADHI

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport - Rami BEN HADJYAHYA - Ala AWADHI

Transféré par

Droits d'auteur :

Formats disponibles

CONCEPTION ET DEVELOPPEMENT D’UN MARKETPLACE

Chapitre I : Présentation du cadre général du projet

II- Etude de l’existant

1- Etude comparative de quelques MarketPlaces

L’étude a porté sur les sites suivants : [1]:

 Amazon.com : C’est une entreprise de commerce électronique américaine basée

 Pixmania.com : C’est un des acteurs majeurs du commerce électronique en France mais

 ETSY.com : C’est un site de vente en ligne fondé en 2005.

 DaWanda.com : Ou « Bon d'achat » en Français, c’est un portail en ligne e-commerce

 AlittleMarket.com : C’est une plateforme française de produits faits à la main lancée en

N/D : Non Disponible

Tableau 1 : Analyse générale des sites de renommée

ETSY DAWANDA A LITTLE MARKET PRIMACRÉA

Frais de prolongation 0.20 $ / article gratuit gratuit gratuit

2- Critique des solutions

3- Présentation des solutions de paiement

Commission sur vente(en %) Paramétrable

III- Méthodologie adoptée

Nous avons opté pour le langage de modélisation UML (UNIFIED MODELING

Chapitre II : Spécification des besoins

I- Etude des besoins

Nos besoins fonctionnels consistent à :

- Gestion des boutiques

2- Besoins non fonctionnels

II- Cas d’utilisation

1- Présentation des acteurs

Les acteurs en interaction avec notre système sont :

2. Diagramme de cas d’utilisation global

Gérer son panier Editer la facture

Acheter un produit Payer

Gérer sa boutique <<include>>

Visualiser l'historique <<include>>

Visualiser l'historique <<include>>

Utilisateur Gérer son compte

Visualiser l'historique <<include>>

Figure 1: Diagramme de cas d’utilisation global

Un internaute doit pouvoir assurer les activités suivantes :

 Consulter les rubriques du site

Un abonné doit pouvoir assurer aussi les activités suivantes :

 Acheter un ou des produits après le remplissage de son panier.

3- Raffinement du diagramme de cas d’utilisation relatif à la

Trier par prix Trier par date

Figure 2: Diagramme de cas d’utilisation relatif à la consultation du site

4- Raffinement du diagramme de cas d’utilisation relatif à l’achat des

Figure 3: Diagramme de cas d’utilisation relatif à l’achat des produits

 Cas d'utilisation "Achat d’un produit"

Titre : Acheter un produit

Le scénario nominal reprend au point 5

4- Raffinement du diagramme de cas d’utilisation relatif à la vente des

Consulter ses <<extend>> Ajouter un

Gérer ses boutiques <<extend>>

<<extend>> <<extend>> Mettre a jour un

Figure 4: Diagramme de cas d’utilisation relatif à la mise en vente des produits

 Cas d'utilisation "Déposer un produit dans le site"

Titre : Déposer un produit dans le site.

1- L’abonné demande d’accéder à sa liste des boutiques.

5- Raffinement du diagramme de cas d’utilisation relatif à

<<extend>> Consulter la liste

<<extend>> Consulter les