Mémoire M2ecom Amani

RÉPUBLIQUE TUNISIENNE
Ministère de l'Enseignement Supérieurs et de La Recherche Scientifique
Faculté des Sciences Juridiques, Economiques et de Gestion De Jendouba

Département Informatique
Mémoire de mastère
Présenté en vue d'obtention du
Mastère professionnel en commerce électronique
Conception et réalisation d’une

Plateforme des agences de fêtes
Réalisé par :
Mlle. Ayari Ameni
Sous la direction de :
Mr. Khemiri Nabil
Année universitaire : 2018/2019

Signatures
Encadrant de FSJEGJ
Mr. Khemiri Nabil
Dédicaces
A mes parents : Aucun mot si sacré soit-il, ne suffira à apprécier à sa juste valeur, le soutien
matériel et spirituel, les sacrifices que vous ne m'avez cessé de déployer. On vous offre en guise
de reconnaissance, ce modeste travail en vous souhaitant santé, bonheur et longue vie qu'on
puisse combler à nous tour.
A mon frère et ma sœur : Je vous dédie ce travail en témoignage des liens solides et intimes
qui nous unissent et pour leurs soutiens, encouragements en vous souhaitant un avenir plein de
succès et de bonheur
.
A tous mes professeurs
Qui m’ont soutenu
De près ou de loin tout au long de ce projet
A tous mes amis
A toute personne
Qui m’a aidé à franchir un horizon dans ma vie…
A tous ceux qui m'ont soutenu et qui me soutient encore ...
☺ Ayari Ameni
Remerciements
On remercie dieu le tout puissant de nous avoir donné la santé et la volonté

D’entamerait de Terminer ce projet
J'adresse mes remerciements à mon professeur, Mr Nabil Khemiri de la Faculté

Sciences Juridiques Economies Jendouba qui m'a beaucoup aidé dans ma recherche.
Son écoute et ses conseils m'ont permis de cibler mes candidatures. Je le remercie pour la
qualité de son encadrement exceptionnel, pour sa patience, durant ma Préparation de ce projet.
☺ Ayari Ameni
Table des matières
Introduction Générale ................................................................................................................. 1
Chapitre 1 ................................................................................................................................... 3
Présentation du cadre de Projet .................................................................................................. 3
Introduction ................................................................................................................................ 3
1.1. Vue générale sur le commerce électronique ................................................................ 3
1.1.1. Définition ............................................................................................................. 3
1.1.2. Les types du commerce électronique ................................................................... 4
1.1.3. La vente en ligne .................................................................................................. 4
1.2. Présentation du projet .................................................................................................. 6
1.2.1. Étude de l’existant ................................................................................................ 6
1.2.2. Critique de l'existant ............................................................................................. 9
1.2.3. Solution proposée ............................................................................................... 10
1.2.4. Choix du modèle de développement .................................................................. 10
1.3. Langage de modélisation (UML) .............................................................................. 14
1.4. Analyse et spécification des besoins ......................................................................... 15
1.4.1. Identification des acteurs .................................................................................... 15
1.4.2. Spécification des Besoins fonctionnels .............................................................. 16
1.4.3. Définition des Besoins non fonctionnels ............................................................ 17
1.5. Les cas d’utilisations ................................................................................................. 18
1.5.1. Diagramme de cas d’utilisation globale ............................................................. 18
1.6. Pilotage du projet avec Scrum ................................................................................... 19
1.6.1. Les outils Scrum utilisés .................................................................................... 19
1.6.2. Équipe et rôles .................................................................................................... 20
1.6.3. Equipe « scrum » du notre projet ....................................................................... 21
1.6.4. Le Backlog du produit ........................................................................................ 21
1.6.5. Planification des sprints ..................................................................................... 23
1.7. Environnement de développement ............................................................................ 23
1.7.1. Environnement matériel ..................................................................................... 23
1.7.2. Environnement technique ................................................................................... 24
1.8. Architecture de la solution ......................................................................................... 27
1.8.1. Architecture Applicatives ................................................................................... 27
1.8.2. Architecture logicielle ........................................................................................ 28
Conclusion ................................................................................................................................ 29
Chapitre 2 ................................................................................................................................. 29
Sprint 1 : Les cas de priorité 1.................................................................................................. 29
2.1. Spécification des besoins ........................................................................................... 29
2.1.1. Raffiner les modèles des cas d’utilisation de priorité « 1 » ............................... 30
2.2. Conception des cas d'utilisations de priorité « 1 »..................................................... 36
2.2.1. Diagrammes des séquences détaillés .................................................................. 37
2.2.2. Diagrammes de collaboration............................................................................. 42
2.2.3. Diagrammes d’état-transitions ........................................................................... 44
2.2.4. Diagrammes d’activités ...................................................................................... 45
2.2.5. Diagramme de classes ........................................................................................ 46
2.2.6. Implémentation des cas d'utilisation prioritaires ................................................ 51
Conclusion ................................................................................................................................ 54
Chapitre 3 ................................................................................................................................. 55
Sprint 2 : les cas de priorité 2 ................................................................................................... 55
Introduction .............................................................................................................................. 55
3.1.1. Raffiner les modèles des cas d'utilisation de priorité « 2 » ................................ 56
3.2.1. Diagramme de séquence ........................................................................................ 61
3.2.2. Diagramme de séquence pour le scénario « ajouter produit » ........................... 62
3.2.3. Diagramme de séquence pour le scénario "modifier produit" ........................... 63
3.2.4. Diagramme de séquence « supprimer produit » ................................................. 64
3.2.5. Diagramme de séquence pour le scénario « ajouter promotion » ...................... 65
3.2.6. Diagramme de séquence pour le scénario « supprimer promotion » ................. 66
3.3. Diagramme de collaboration ..................................................................................... 67
3.3.1. Diagramme de collaboration « ajouter produit »................................................ 67
3.3.2. Diagramme de collaboration « supprimer promotion » ..................................... 67
3.4. Diagramme d’activités ............................................................................................... 68
3.4.1. Diagramme d’activité pour le cas d’utilisation « Modifier produit » ................ 68
3.5. Diagramme des classes .............................................................................................. 68
3.5.1. Dictionnaire de données ......................................................................................... 69
3.6. Implémentation des cas d'utilisation prioritaires ....................................................... 71
3.6.1. Interface authentification prestataire .................................................................. 71
3.6.2. Interface ajouter produit ..................................................................................... 71
3.6.3. Interface modifier produit .................................................................................. 72
3.6.4. Interface consulter statistique ............................................................................. 73
Conclusion ................................................................................................................................ 75
Chapitre 4 ................................................................................................................................. 74
Sprint 3 : les cas de priorité 3 ................................................................................................... 74
Introduction .............................................................................................................................. 74
4.1.1. Raffiner les modèles des cas d'utilisation de priorité « 3 » ................................ 75
4.2. Conception des cas d'utilisation de priorité « 3 » ...................................................... 77
4.2.1. Diagramme de déploiement ............................................................................... 77
4.2.2. Diagramme de séquence ..................................................................................... 78
4.3. Diagramme de collaboration ..................................................................................... 80
4.3.1. Diagramme de collaboration de sous cas d'utilisation « supprimer client » ...... 80
4.3.2. Diagramme de collaboration de sous cas d’utilisation « supprimer prestataire 81
4.4. Diagramme de classes ............................................................................................... 81
4.5. Modèle relationnel ..................................................................................................... 82
4.6. Implémentation des cas d'utilisation prioritaires ....................................................... 83
4.6.1. Interface authentification administrateur ........................................................... 83
4.6.2. Interface supprimer client................................................................................... 83
4.6.3. Interface supprimer client................................................................................... 84
Conclusion et perspectives ....................................................................................................... 74
Liste des figures
FIGURE 1:INTERFACE D’ACCUEIL DU SITE « ZIFEF.COM » ........................................................... 8
FIGURE 2:INTERFACE D’ACCUEIL DU SITE "FAR7A.COM » ........................................................... 9
FIGURE 3:MODELE DE DEVELOPPEMENT AGILE ........................................................................ 11
FIGURE 4 : SCHEMA DE METHODE CLASSIQUE ET METHODE AGILE........................................... 13
FIGURE 5:DIAGRAMME DES CAS D’UTILISATION GLOBALE ........................................................ 19
FIGURE 6:IMPRIME D'ECRAN D'UN TABLEAU COLLABORATIVE .................................................. 20
FIGURE 7:SCRUM ROLES ............................................................................................................ 21
FIGURE 8: LOGO DE VISUAL PARADIGM .................................................................................... 24
FIGURE 9:LOGO DE MYSQL...................................................................................................... 24
FIGURE 10:LOGO DE NOTEPAD ++ ............................................................................................. 25
FIGURE 11: LOGO D’APACHE ..................................................................................................... 25
FIGURE 12:LOGO DE BOOTSTRAP .............................................................................................. 25
FIGURE 13 : LOGO DE PHP5 ....................................................................................................... 25
FIGURE 14:LOGO DE HTML5 .................................................................................................... 26
FIGURE 15: LOGO DE CSS3........................................................................................................ 26
FIGURE 16 : LOGO DE JAVASCRIPT ............................................................................................. 26
FIGURE 17:LOGO DE WAMPSERVER .......................................................................................... 27
FIGURE 18:LE MODELE MVC [22] ............................................................................................. 28
FIGURE 19:ARCHITECTURE MATERIELLE DU SYSTEME [23] ....................................................... 29
FIGURE 21:DIAGRAMME DE CAS D’UTILISATION « S’INSCRIRE »................................................ 31
FIGURE 22:DIAGRAMME DE CAS D’UTILISATION « RECHERCHER PRODUIT » .............................. 32
FIGURE 23:DIAGRAMME DE CAS D'UTILISATION" GERER PANIER" ............................................. 33
FIGURE 24: DIAGRAMME DE CAS D’UTILISATION « S’AUTHENTIFIER » ...................................... 34
FIGURE 25:DIAGRAMME DE CAS D’UTILISATION « SUIVRE COMMANDE » .................................. 35
FIGURE 26: DIAGRAMME DE CAS D’UTILISATION « PASSER COMMANDE » ................................. 36
FIGURE 27:EXEMPLE DE DIAGRAMME DE SEQUENCE DETAILLE ................................................. 37
FIGURE 28:DIAGRAMME DE SEQUENCE « S’AUTHENTIFIER » ..................................................... 38
FIGURE 31:DIAGRAMME DE SEQUENCE « RECHERCHER PRODUIT » ........................................... 39
FIGURE 30:DIAGRAMME DE SEQUENCE « ENVOYER RECLAMATION » ........................................ 40
FIGURE 31:DIAGRAMME DE SEQUENCE « S’INSCRIRE » ............................................................. 41
FIGURE 32:DIAGRAMME DE SEQUENCE « PASSER COMMANDE » ................................................ 42
FIGURE 33:DIAGRAMME DE COLLABORATION POUR LE CAS D’UTILISATION « S’INSCRIRE » ...... 43
FIGURE 34:DIAGRAMME DE COLLABORATION POUR LE CAS D’UTILISATION « S’AUTHENTIFIER »....... 43
FIGURE 35:DIAGRAMME DE COLLABORATION POUR LE CAS D’UTILISATION « ENVOYER RECLAMATION » ............. 44
FIGURE 36:DIAGRAMME DE COLLABORATION POUR LE CAS D’UTILISATION « RECHERCHER PRODUIT » ................ 44
FIGURE 37:DIAGRAMME D’ETAT DE TRANSITION « COMMANDE » ............................................. 45
FIGURE 38:DIAGRAMME D’ACTIVITE POUR LE CAS D’UTILISATION « S’INSCRIRE » ................... 46
FIGURE 39:DIAGRAMME D’ACTIVITE POUR LE CAS D’UTILISATION « S’AUTHENTIFIER »........... 46
FIGURE 40:DIAGRAMME DE CLASSES DU PREMIER SPRINT ......................................................... 47
FIGURE 41:INTERFACE « S'INSCRIRE » ....................................................................................... 51
FIGURE 42:INTERFACE "S'AUTHENTIFIER" ................................................................................. 52
FIGURE 43:INTERFACE PASSER COMMANDE .............................................................................. 52
FIGURE 44:INTERFACE COMMENTER ET NOTER PRODUIT ........................................................... 53
FIGURE 45:DIAGRAMME DE CAS D’UTILISATION « S’INSCRIRE » ............................................... 56
FIGURE 46:DIAGRAMME DE CAS D’UTILISATION « S’AUTHENTIFIER »....................................... 57
FIGURE 47:DIAGRAMME DU CAS D’UTILISATION « GERER PRODUIT » ....................................... 58
FIGURE 48:DIAGRAMME DU CAS D'UTILISATION « GERER PROMOTION »................................... 60
FIGURE 49:DIAGRAMME DE SEQUENCE « INSCRIPTION PRESTATAIRE » ..................................... 61
FIGURE 50:DIAGRAMME DE SEQUENCE « AUTHENTIFICATION » ................................................ 62
FIGURE 51:DIAGRAMME DE SEQUENCE" AJOUTER PRODUIT" ..................................................... 63
FIGURE 52:DIAGRAMME DE SEQUENCE "MODIFIER PRODUIT" .................................................... 64
FIGURE 53:DIAGRAMME DE SEQUENCE "SUPPRIMER PRODUIT" .................................................. 65
FIGURE 54:DIAGRAMME DE SEQUENCE "AJOUTER PROMOTION" ................................................ 66
FIGURE 55:DIAGRAMME DE SEQUENCE POUR LE SCENARIO « SUPPRIMER PROMOTION » ........... 67
FIGURE 56:DIAGRAMME DE COLLABORATION « AJOUTER PRODUIT » ....................................... 67
FIGURE 57:DIAGRAMME DE COLLABORATION « SUPPRIMER PROMOTION » ............................... 68
FIGURE 58:DIAGRAMME D’ACTIVITE POUR LE CAS D’UTILISATION « MODIFIER PRODUIT »....... 68
FIGURE 59:DIAGRAMME DE CLASSES DU DEUXIEME SPRINT ..................................................... 69
FIGURE 60:INTERFACE AUTHENTIFICATION PRESTATAIRE ......................................................... 71
FIGURE 61:INTERFACE AJOUTER PRODUIT ................................................................................. 72
FIGURE 62:INTERFACE MODIFIER/SUPPRIMER PRODUIT ............................................................. 72
FIGURE 63:INTERFACE MODIFIER PRODUIT ................................................................................ 73
FIGURE 64:INTERFACE CONSULTER STATISTIQUE ...................................................................... 73
FIGURE 65:DIAGRAMME DE CAS D'UTILISATION « GERER MEMBRE » ......................................... 75
FIGURE 66:DIAGRAMME DE CAS D'UTILISATION « GERER RECLAMATION » ............................... 76
FIGURE 67:DIAGRAMME DU CAS D'UTILISATION « ETUDIER DEMANDE INSCRIPTION PRESTATAIRE » .................... 77
FIGURE 68:DIAGRAMME DE DEPLOIEMENT ................................................................................ 78
FIGURE 69:DIAGRAMME DE SEQUENCE "SUPPRIMER CLIENT".................................................... 79
FIGURE 70:DIAGRAMME DE SEQUENCE « SUPPRIMER PRESTATAIRE » ....................................... 80
FIGURE 71 : DIAGRAMME DE COLLABORATION « SUPPRIMER CLIENT » ..................................... 81
FIGURE 72:DIAGRAMME DE COLLABORATION « SUPPRIMER PRESTATAIRE » ............................. 81
FIGURE 73:DIAGRAMME DE CLASSE DE SPRINT 3....................................................................... 82
FIGURE 74:INTERFACE AUTHENTIFICATION ADMIN ................................................................... 83
FIGURE 75:INTERFACE ETUDIER DEMANDE PRESTATAIRE .......................................................... 84
FIGURE 76:INTERFACE SUPPRIMER CLIENT ................................................................................ 84
Liste des tableaux
TABLEAU 1: DENOTATIONS ET CONNOTATIONS DU SITE"ZIFEF.COM" .................................................... 7
TABLEAU 2: DENOTATIONS ET CONNOTATIONS DU SITE"FAR7A.COM" .................................................. 9
TABLEAU 3 : LES DEUX GRANDES FAMILLES DE METHODES DE GESTION DE PROJET : LES METHODES 12
TABLEAU 4 : AVANTAGES ET INCONVENIENTS DE METHODE SCRUM................................................... 14
TABLEAU 5: IDENTIFICATION DES ACTEURS AVEC LEUR DESCRIPTIONS ............................................... 15
TABLEAU 6: ROLES SCRUM ................................................................................................................. 21
TABLEAU 7 : EQUIPE « SCRUM » DU NOTRE PROJET.............................................................................. 21
TABLEAU 8 : BACKLOG DU PRODUIT ..................................................................................................... 22
TABLEAU 9: DESCRIPTION DE MACHINE DE DEVELOPPEMENT .............................................................. 24
TABLEAU 10:PRODUCT BACKLOG DU SPRINT 1 .................................................................................... 29
TABLEAU 11: FICHE DESCRIPTIVE DU CAS D'UTILISATION « S'INSCRIRE » ............................................ 31
TABLEAU 12:FICHE DESCRIPTIVE DU CAS D’UTILISATION « RECHERCHER PRODUIT » ......................... 32
TABLEAU 13:FICHE DESCRIPTIVE DU CAS D'UTILISATION « AJOUTER PRODUIT » ................................. 33
TABLEAU 14: FICHE DESCRIPTIVE DU CAS D’UTILISATION « S’AUTHENTIFIER » .................................. 34
TABLEAU 15:FICHE DESCRIPTIVE DU CAS D’UTILISATION « SUIVRE COMMANDE » .............................. 35
TABLEAU 16:FICHE DESCRIPTIVE DU CAS D’UTILISATION « PASSER COMMANDE ».............................. 36
TABLEAU 17:TABLEAU DE REGLES DE PASSAGE DU DIAGRAMME DE CLASSES VERS LA BASE DE DONNEES RELATIONNELLE.......... 47
TABLEAU 18:LE DICTIONNAIRE DES DONNEES POUR LA TABLE « CLIENT » ......................................... 48
TABLEAU 19: LE DICTIONNAIRE DES DONNEES POUR LA TABLE" PRODUIT" ......................................... 48
TABLEAU 20:LE DICTIONNAIRE DES DONNEES POUR LA TABLE "COMMANDE" .................................... 49
TABLEAU 21:LE DICTIONNAIRE DES DONNEES POUR LA TABLE « RECLAMATION ».............................. 49
TABLEAU 22:LE DICTIONNAIRE DES DONNEES POUR LA TABLE « COMMENTAIRE » ............................. 50
TABLEAU 23:LE DICTIONNAIRE DES DONNEES POUR LA TABLE « FAVORIS » ....................................... 50
TABLEAU 24:LE DICTIONNAIRE DES DONNEES POUR LA TABLE « CATEGORIES_PRODUIT » ................. 50
TABLEAU 25:LE DICTIONNAIRE DES DONNEES POUR LA TABLE « LIGNE_COMMANDE » ...................... 50
TABLEAU 26:LE DICTIONNAIRE DES DONNEES POUR LA TABLE « PHOTOS_PRODUIT » ......................... 51
TABLEAU 27: BACKLOG DU SPRINT 2 .................................................................................................... 55
TABLEAU 28:FICHE DESCRIPTIVE DU CAS D’UTILISATION « S’INSCRIRE » ........................................... 56
TABLEAU 29: FICHE DESCRIPTIVE DU CAS D’UTILISATION « S’AUTHENTIFIER » .................................. 57
TABLEAU 30: FICHE DESCRIPTIVE DU SOUS CAS D'UTILISATION « AJOUTER PRODUIT » ...................... 58
TABLEAU 31: FICHE DESCRIPTIVE DU SOUS CAS D'UTILISATION « MODIFIER PRODUIT » .................... 58
TABLEAU 32: FICHE DESCRIPTIVE DU SOUS CAS D'UTILISATION « SUPPRIMER PRODUIT » .................. 59
TABLEAU 33: FICHE DESCRIPTIVE DU CAS D’UTILISATION « GERER PROMOTION (AJOUTER PROMOTION) » ........... 60
TABLEAU 34:DICTIONNAIRE DE DONNEES POUR LA TABLE « PRESTATAIRE » ...................................... 69
TABLEAU 35: DICTIONNAIRE DES DONNEES POUR LA TABLE « PROMOTION » ...................................... 70
TABLEAU 36:DICTIONNAIRE DES DONNEES POUR LA TABLE « TYPE » .................................................. 70
TABLEAU 37:PRODUCT BACKLOG DE TROISIEME SPRINT ..................................................................... 74
TABLEAU 38:RAFFINEMENT DE CAS D'UTILISATION « SUPPRIMER CLIENT » ........................................ 75
TABLEAU 39:RAFFINEMENT DE CAS D'UTILISATION « REPONDRE RECLAMATION » ............................. 76
TABLEAU 40: FICHE DESCRIPTIVE DU SOUS CAS D'UTILISATION « ETUDIER DEMANDE INSCRIPTION PRESTATAIRE » ..................... 77
Tableau d’abréviation
Abréviation Désignation
HTML HyperText Markup Language
CSS Cascading Style Sheets
UML Unified Modeling Language
MVC Modèle Vue Contrôleur
BD Base de Données
IHM Les interactions homme-machine
PHP Personal Home Page.
WYSIWYG What you see is what you get
OOSE Object Oriented Software Engineering
VP Visual Paradigm
Introduction Générale
L
e commerce classique est une rencontre face à face entre le client et le vendeur, d’où
la nécessité de présence des deux membres dans un même milieu. Le client reste alors
limité aux horaires de présence du commerçant. Ce qui limite le nombre des clients.
De ce fait, le commerce classique ne répond plus aux besoins des clients.
Or, les nouvelles technologies communication (NTIC), telle que <<Internet>>, offre le service
du commerce électronique. En effet, Internet, comme étant une des technologies d’information
et de communication, a permis de créer un nouveau support qui a résolu le problème de la
distance.
Le choix du canal Internet pour l’achat et les locations des produits des fêtes explique
principalement le confort et la capacité de ce mode d’achat et de location à toute heure, gain de
temps et a prix plus au moins bas.
Il a fourni une nouvelle technique efficace pour la communication à travers des applications et
des sites web modifient l’approche traditionnelle.
Internet permet d’établir un dialogue continu avec le consommateur et cela de façon

personnalisée.
Il faut bien sur vérifier que le site de commerce sur lequel on réalise nos ses ventes et locations
est équipé d’un système de paiement sécurisé.
Tous ces arguments nous ont guidés vers le choix d’un projet de mémoire de mastère au sein
de la Faculté des Sciences Juridique Economique et de Gestion de Jendouba, et ce pour
l’obtention du mastère professionnel en Commerce Electronique. Afin de concrétiser nos
connaissances théoriques par la pratique, nous étions chargés de développer une plateforme
des agences de fêtes.
Tout au long de ce rapport, nous détaillerons la démarche à suivre pour réaliser ce projet.
Nous pouvons, à ce propos, citer comme suit quatre chapitres :
1
1. Premier chapitre : Présentation du cadre de projet.
2. Deuxième chapitre : Sprint 1 : les cas de priorité 1.
3. Troisième chapitre : Sprint 2 les cas de priorité 2.
4. Quatrième chapitre : Sprint 3 les cas de priorité 3.
Nous clôturons ce manuscrit par une conclusion générale et quelques perspectives futures qui
peuvent ouvrir des horizons pour d'éventuelles améliorations ou maintenances de la plateforme
que nous l'avons mis en place.
2
CHAPITRE 1. PRÉSENTATION DU CADRE DE PROJET
Chapitre 1
Présentation du cadre de Projet
Introduction
’expression commerce électronique fait référence au processus d’achat et de vente de

L produits ou de services sur Internet. Le magasinage en ligne est devenu de plus en plus
populaire à cause de sa rapidité et sa facilité d’utilisation pour les consommateurs. s
Nous avons réalisé ce rapport afin de mettre en œuvre les étapes de la création d’une application
de gestion ainsi que les différents critères suivis pour aboutir à une application finale.
Une étude complète et efficace conduit généralement à la réussite d’un projet. Cette étude fera
donc l’objet de notre premier chapitre qui sera consacré à une étude de l'existant suivie d'une
critique qui permet de dégager le dysfonctionnement dans ce domaine et ceci est dans le but de
remédier aux problèmes détectés et d’apporter les solutions requises ainsi et les suggestions
d'améliorations. La définition de notre méthodologie de développement sera également
discutée.
1.1. Vue générale sur le commerce électronique

1.1.1. Définition
Le commerce électronique est défini comme étant tout échange de donnes par l’intermédiaire
d’un réseau de télécommunication à des fins commerciales. En d’autres termes le e-commerce
désigne d’un média électronique pour la réalisation de transaction commerciale. Dans la plupart
de temps il s’agit de la vente de produit et/ou service à travers le réseau internet. Donc on peut
dire que le commerce électronique est fondé essentiellement sur le traitement électronique et la
transmission des données y compris textuelles, sonores et vidéo. Il couvre ainsi des activités
multiples et diverse, et notamment le commerce de bien, la livraison en ligne d’information
3
numérique de fond, les activités boursières électroniques, les marches publiques, la vente
directe au consommateur et le service après-vente.
Les principaux objectifs pour s’intégrer dans le commerce électronique sont :
− Améliorer la compétitivité des entreprises ;

− Favoriser et permettre l’accès à de nouveaux marchés ;
− Maximiser les marges commerciales par la réduction des intermédiaires ;
− Promouvoir de nouveaux services et produit à l’export ;
− Créer de nouvelles filières pour l’emploi des diplômes ;
1.1.2. Les types du commerce électronique
Il est tout d'abord possible de distinguer différentes formes de commerce électronique en fonction
des acteurs impliqués.
− Business to consumer (B to C)
Le B to C ou Business to Consumer concerne l'utilisation des supports électroniques pour toute
partie des relations commerciales entre une entreprise et les particuliers. Bref, B to C, fait référence
aux transactions intervenant entre une entreprise et un consommateur.
− Business to business (B to B)
Le B to B, Business to Business, fait référence aux transactions intervenant entre deux entreprises,
c'est-à-dire les activités concernant les relations entre des entreprises et de ses différents modèles.
− Consumer to consumer (C to C)
Le Consumer to Consumer C to C désigne l’ensemble des transactions commerciales réalisées entre
particuliers. Les sites d’enchères ou les petites annonces de particuliers en presse ou des ventes
d’occasion sur internet appartiennent au secteur du Consumer to Consumer.
− Business to Administration (B to A)
Le B to A ou Business to Administration correspond aux échanges commerciaux réalisés entre une
entreprise et des administrations.
− Administration to Consumer (A to C)
Le A to C ou Administration to Consumer correspond aux échanges commerciaux entre
l'administration et les particuliers.
1.1.3. La vente en ligne
L'amélioration de la connectivité internet et la création d'outils en ligne plus puissants a entraîné
une nouvelle ère de commerce, la vente en ligne.
La vente en ligne offre de nombreux avantages aux entreprises et aux clients, mais elle est aussi la
cause de nombreux problèmes.
4
1.1.3.1. Les avantages de vente en ligne

La raison principale de s’intéresser au commerce électronique : il nous ouvre les portes à
quelques dizaines de millions de client potentiels pour une très modique somme. En plus elle
possède un multiple avantage :
− La vitesse : De plus en plus, les délais se compriment entre le moment où le besoin se

manifeste et le moment où le bien ou service est livré. Pour demeurer compétitives, les
entreprises devront assibiler cette nouvelle réalité. Avec internet, l’information voyage
plus rapidement.
− Les économies : Les couts d’exploitation (marketing, production) ; de distribution et de
livraison peuvent être réduits significativement avec l’usage de commerce électronique.
− Nouveau marché : Pour les PME, le commerce électronique ouvre les portes sur le
marché international, un marché pratiquement équivalent à celui des grandes
entreprises.
− Réduction de la chaine de distribution : Les entreprises qui fabriquant des bien ont
intérêt à les vendre directement au client final au lieu de passer par des intermédiaires.
− La flexibilité : Internet procure à vos client un accès facile et rapide à vos produits et
ce 7 jours sur 7 jours. 24 heures sur 24 heures.
1.1.3.2. Les inconvénients de vente en ligne
− Gare aux frontières :
L’absence de frontières sur le Net peut engendrer des situations juridiques extrêmement
complexes (notamment pour le tabac ou les alcools)
− Le commerce électronique victime de son succès :
Devant l’immense demande, les sites autres ont engendre des retards de livraison, des ruptures
de stock, des commande parfois égarées, des sites devenus incroyablement lents ou bloqués
− L’image de marque :
Cela peut paraitre très étonnant, mais certaines marques refusent d’être présentes sur le web
pour ne peut pas tenir leur image.
− La vente en VAD pour le B to B, tous systèmes confondus :
Les entreprises apprécient moins le nombre élève de catalogues, l’impossibilité de voir avant
de commander, l’absence de réelles relation commerciales, la marque de conseils et l’absence
5
d’antennes commerciales locales. Mais le web peut améliorer grandement ce qui est
principalement reproché à la vente à distance.
1.2. Présentation du projet

L’idée est de créer une plateforme des agences de fêtes permettant aux clients de commander
ou de louer des articles selon le type de fête (mariage, anniversaire… etc.), ils peuvent,
également, laisser des commentaires et noter les produits, ainsi, cette plateforme permet aux
prestataires d’ajouter leurs produits dans le site et des promotions.
1.2.1. Étude de l’existant

Dans cette partie, nous attaquerons une étude de l'existant, une description du système actuel.
Ensuite, nous poserons la problématique qui va nous ramener à proposer une solution selon le
contexte de notre projet.
1.2.1.1. Description de l'existant
Actuellement, pour satisfaire ses besoins, le client doit effectuer des recherches chez des
vendeurs. Il doit alors se déplacer en respectant l’emploi du temps du vendeur pour aboutir à
un résultat plus au moins satisfait et peut être il ne trouve pas tous les choix disponibles.
La procédure ainsi définie ne fait que perdre du temps et son organisation demeure donc
fructueuse. En effet, cette procédure n’utilise pas une base de données qui sauvegarde les choix
des utilisateurs, les mises à jour faites au niveau des données client et le produit.
L’organisation du travail et le problème de distance sont très importants, mais malheureusement

ils ne sont pas pris en compte dans la procédure de vente au bien de location de n’importe quel
produit.
1.2.1.2. Présentation du site « zifef.com »

Le Site « zifef.com » a été créé par un groupe d’ingénieur en informatique en 2016, D'où leur
initiative de créer ce site dont la vocation est de faciliter les recherches des services et
professionnels qui peuvent aider les internautes à mieux préparer leurs mariages dans la joie et
le bonheur.
1.2.1.3. Analyse fonctionnelle de site « zifef.com »

Ce site permet aux internautes de :
—S’inscrire ;
—Chercher des traiteurs ;
6
—Contacter des traiteurs ;
—Réserver salle de fête ;
—Acheter des produits ;
—Gérer panier ;
1.2.1.4. Analyse technique du site « zifef.com »

Dans cette section, nous présenterons une analyse technique du site « zifef.com ».
De ce fait, le tableau 1 reporte les dénotations et les connotations pour chaque élément de la
plateforme. Ainsi l’interface 1 représente la page d’accueil du site étudié.
Dénotations Connotations
Disposition horizontale Elle donne un sens de lecture qui rend la page plus simple
de la page d’accueil
Disposition verticale de Bien organisée, elle rend l’accès aux autres espaces du sites facile.
la liste du menu
Gamme de couleur : -Le rouge pour les boutons
Le bleu pétrole, le blanc -le blanc, couleur de barre de menus.

et le rouge
-Le bleu pétrole exprime la fiabilité et la sécurité.
Haute définition des Les images, de haute définition, donnent une description pour les
images différentes annonces, influant sur la clarté de la page (rendant la
page plus claire).
Tableau 1: Dénotations et connotations du site"zifef.com"
Voici l’imprimes d’écran de site zifef.com :
7
Figure 2:Interface d’accueil du site « zifef.com » [1]
1.2.1.5. Présentation du site « far7a.com »

-le site « far7a » lancé en 2015. Il été créé par un groupe d’ingénieur en informatique permet
de permet aux clients de chercher et de consulter les profils des prestataires et les contacter
seulement par l’envoi d’un mail.
1.2.1.6. Analyse fonctionnelle du site « far7a.com »

Les principaux usages du site pour les prestataires sont :
—S’inscrire, créer et gérer son profil
—Rechercher produit
—Donner des avis sur un produit
1.2.1.7. Analyse technique du site « far7a.com »
Dans cette section, nous présenterons une analyse technique du site « far7a.com ».
Le tableau 2 Reporte les dénotations et les connotations pour chaque élément du site.
L’interface Représente la page d’accueil du site étudié.
Dénotations Connotations
Le police La taille de police est variable, les titres sont en gras et en majuscule
pour attirer l’attention de l’utilisateur. Les paragraphes sont de petite
taille.
La page d’accueil Devisée en des rubriques, elle permet d’accéder aux d’autres pages
du site facilement et rapidement.
8
La liste du menu La disposition horizontale en haut de la page, rend la navigation vers

d’autres pages rapides.
Tableau 2: Dénotations et connotations du site"far7a.com"
Voici l’imprime d’écran de site Far7a.com :
Figure 3:Interface d’accueil du site "far7a.com » [2]
1.2.2. Critique de l'existant

Avant de plonger dans l’étude proprement dite de la solution, il est indispensable de prendre du
recul et de faire un résumé des problèmes concrets existants que rencontrent au jour le jour nos
différents acteurs :
− Absence de promotions sur les produits ;
− Choix indisponible et moins de services ;
− Manque de location de produit dans les sites existants ;
− Le manque de traçabilité et de suivi de commande ;
− Le traitement des commandes prend un temps assez lent ;
− Manque du contrôle d’autorisation de demande d’inscription des prestataires ;
− Absence d’organisation de fête ;
− On ne peut pas trouver tout un site qui contient tous les produits de différentes fêtes ;
− Mauvaise exposition des produits ;
9
1.2.3. Solution proposée

Après une étude approfondit de l’existant, plusieurs limites des applications sont représentées
sur le marché ont été identifiées, toutes les solutions ne sont pas parfaites car elles ne tiennent
pas compte tous les besoins.
Dans ce qui suit, nous détaillons les solutions de la problématiques, notre projet propre de
concevoir et de développer une plateforme des agences des fêtes permettent de répondre plus
rapidement aux besoins des clients et des prestataires, citons :
− Le client peut choisir le type de fête et toutes ses composantes facilement.

− Le client a la possibilité de faire le paiement à distance.
− Le service après-vente.
− L’accès rapide aux informations.
− La simplification de circuit d’information.
− Le prestataire peut ajouter des différents produits sur le site
− Le prestataire peut ajouter des promotions sur les produits
1.2.4. Choix du modèle de développement

La méthodologie est une démarche organisée rationnellement et pour aboutir à un résultat.
Lorsqu'on démarre un projet, il est normal de se questionner sur l'organisation que l'on va
adapter pour sa mise en place et sa réalisation. Combien de réunions ? Quel rôle va jouer chaque
personne de l'équipe ? Comment faire pour éviter de recommencer le travail depuis le début si
le client change d'avis ? Depuis quelque temps, on entend parler de la méthode Agile, ou encore
Scrum (La méthodologie Agile la plus utilisée)
Nous détaillons ces modèles :
1.2.4.1. Les méthodes classiques et les méthodes agiles de la gestion de projet
Dans cette partie, nous proposons de comparer les deux grandes familles de méthodes de
gestion de projet : les Méthodes traditionnelles et les méthodes agiles. Il ne s'agit pas de
discréditer l'une ou l'autre mais de comprendre les finalités et les différences qu'elles présentent.
Tout d'abord, définissons-les.
− Les méthodes classiques : Rigidité du développement. Ces méthodes se caractérisent d'une
part, par leur aspect séquentiel, elle suit le cycle de vie standard d'un projet et d'autre part,
par la relation « client/fournisseur » entre la maitrise d'ouvrage et la maitrise d'œuvre. Elles
présentent les caractéristiques suivantes : Proposition de solutions complètes. Suivi d'un
processus de développement linéaire et définition de l'ensemble de contraintes dès le début
10
du projet. Le risque d'échec se comprend aisément. En effet, quelle entreprise a un périmètre

et des besoins fonctionnels stables pendant toute la durée d'un projet.
Nous citons quelques noms des modèles appartenant aux méthodes classiques : Modèle
Cascade, Modèle en v, etc.
− Les méthodes agiles : Elles privilégient les quatre notions suivantes premièrement les
personnes et les interactions, d'avantage que les processus et les outils, deuxièmement des
logiciels opérationnels, plus qu'une documentation complète troisièmement la collaboration
avec le client, d'avantage que la négociation contractuelle, quatrièmement l'adaptation au
changement, plus que le suivi d'un plan. Nous citons quelques noms des modèles appartenant
aux méthodes Agiles : Méthode Processus Unifié, Méthode eXtreme Programming. Cette
figure représente le modèle de développement Agiles :
Figure 4:Modèle de développement agile [3]
Dans ce tableau on trouve une comparaison entre les méthodes classiques et les méthodes
agiles :
11
Tableau 3 : Les deux grandes familles de méthodes de gestion de projet : les méthodes
Éléments du projet Méthodes classiques Méthodes agiles
Cycle de vie Phases séquentielles rendant les Développement itératif et

retours en arrière au niveau du incrémental permettant
paramétrage très difficiles. des ajustements pendant
les sprints.
Planification Prédictive et relativement Adaptative tout au long
Détaillée. Définie dès le début du projet en fonction des
du projet sur la base d’un évolutions avec plusieurs
périmètre et d’exigences stables. niveaux de planification
(macro/micro).
Documentation Produite en quantité importante Réduite au strict
à chaque étape : minimum au profit
contractualisation, d’incrémentations ayant
spécifications, validation, pour objectif d’obtenir un
communication, … feedback du client.
Qualité Contrôle qualité à la fin du Un contrôle qualité dès le
cycle de développement (effet début du projet et
tunnel). Le client découvre le permanent. Les futurs
produit fini à la fin du projet. utilisateurs visualisent les
résultats du paramétrage
en continu.
Changement Arrive d’un coup à la fin de la Changement intégré au
phase de mise en œuvre => processus de paramétrage
Anxiogène. => faible résistance des
utilisateurs.
Mesure du succès Respect des engagements Satisfaction client.
Initiaux sur la base du triptyque Valeur ajoutée apportée.
Coûts/ Délais/Qualité. Rapidité
d’implémentation.
Cette figure représente un schéma explicatif de la méthode Agile, ou plus particulièrement de

la méthode Scrum, comparée à la méthodologie Classique de gestion de projet.
12
Figure 5 : Schéma de Méthode classique et méthode Agile [4]
13
1.2.4.2. Justification du Choix (Méthode Scrum)

En résumé SCRUM est un processus agile qui permet de produire la plus grande valeur métier
dans la durée la plus courte. Ce choix au fait que SCRUM est plus simple avec son principe de
travail, logique, bien adapté pour mon projet et facilite la planification des étapes et des délais.
C’est une méthode de développement pour les logiciels orientés objets qui répondent aux
exigences fondamentales préconisées par les créateurs d’UML.
Dans ce tableau on trouve les avantages et les inconvénients du modèle de développement de
scrum :
Avantages Inconvénients
-Possibilité de commencer le projet avec un -Grande disponibilité d tous les acteurs.
Budget limité. -Peu, voire pas, de documentation écrite
-Plus grande autonomie des développeurs.
-Meilleure collaboration entre les équipes.
-Meilleure gestion globale des risques
-Amélioration permanente.
Tableau 4 : Avantages et inconvénients de méthode Scrum
D’après ces deux tableaux comparatifs on peut conclure que le Scrum est plus efficace pour
piloter mon projet car ce processus assure le bon déroulement des différents Sprints.
1.3. Langage de modélisation (UML)
Scrum ne préconise aucune technique particulière d’ingénierie, mais :
• La modélisation agile est encouragée, au lieu d’une modélisation UML extensive
− Les modèles aident à comprendre, ils ne sont pas considérés comme une documentation
obligatoire
• Documentez le produit quand il est stable.
− Si une documentation est requise, il vaut mieux la construire après que le code ait été
testé (reverse engineering)
Certains experts préconisent :
• Un peu de modélisation au début de chaque itération
− Pour mieux communiquer le but à tous les intervenants
• Un modèle métier lors de la réunion de planification en début de Sprint
− Améliore la discussion sur les « user stories ». [5]
14
1.4. Analyse et spécification des besoins

Cette partie présente l'étude des besoins qui constitue une phase d'analyse du projet. Nous allons
présenter tout d'abord, les acteurs principaux de l'application. Puis, nous allons présenter les
besoins fonctionnels. Ensuite, nous allons identifier les besoins non fonctionnels. En fin nous
allons clôturer cette partie par la modélisation du diagramme de cas d'utilisation global du
projet.
1.4.1. Identification des acteurs
« Un acteur est l'idéalisation d'un rôle joué par une personne externe, un processus ou une
chose qui interagit avec un système. Il présente une entité externe qui interagit avec le système.
Une même personne (ou robot ...) peut être plusieurs acteurs pour un système, c'est pourquoi
les acteurs doivent surtout être décrits par leur rôle. Ce dernier décrit les besoins et les
capacités de l'acteur » [6]
Les acteurs qui interagissent avec notre futur système sont : visiteur, client, prestataire,
administrateur.
Ce tableau représente la liste des acteurs avec leur descriptions :
Tableau 5: Identification des acteurs avec leur descriptions
Acteur Description
Visiteur Un simple visiteur qui peut naviguer sur le site sans avoir besoin de
s’identifier pour devenir un client.
Client Les clients sont les acteurs principaux de site : ils sont au centre de la
réflexion et de l'action du système. L’utilisation des technologies de
communication mises à leur disposition par le système leur permet de
communiquer. Il procède une authentification qui lui permet d’accéder
aux différents services présents sur le site.
Prestataire Un prestataire a plusieurs types, son rôle est de fournir des prestations et
des solutions aux clients.
Administrateur Son rôle, comme tout web master, tourne autour de la gestion et
l’administration du contenu de site.
15
1.4.2. Spécification des Besoins fonctionnels

« Un besoin fonctionnel est un besoin spécifiant une action qu'un système doit être capable
d'effectuer, sans considérer aucune contrainte physique ; besoin spécifiant un comportement
d'entrée sortie d'un système » [7]
Nous allons énumérer dans cette partie les besoins fonctionnels ou les exigences fonctionnelles
que le système doit être capable d’effectuer.
De ce fait, un besoin fonctionnel spécifie un besoin qu’un système doit être capable d’effectuer
sans considérer aucune contrainte physique. Généralement, notre projet offrira les différentes
fonctionnalités suivantes. Nous les détaillons dans la section suivante en mettant l’accent sur
leur principe de fonctionnement.
• Visiteur
—S’inscrire : S'inscrire pour pouvoir bénéficier les fonctionnalités de notre système, il doit tout
d'abord s'inscrire.
—Rechercher produit : à travers lequel il peut chercher un produit
—Gérer panier : à travers lequel le visiteur peut ajouter un produit au panier, modifier la
quantité de produit, supprimer un produit au panier.
• Client
—S'authentifier : Lors de l'accès au site, le client doit s'authentifier pour accéder aux différentes
fonctionnalités du site.
—Passer commande : à travers lequel le client peut commander un produit
—Envoyer réclamation : à travers lequel le client peut envoyer une réclamation aux
prestataires en cas du problème
—Suivre commande : à travers lequel le client peut suivre la commande en cours.
—Noter produit : à travers lequel le client peut donner un avis sur chaque produit
—Commenter produit : à travers lequel le client peut commenter un produit.
—Gérer favoris : à travers lequel le client peut ajouter, supprimer un produit aux favoris.
• Prestataire
—Gérer produits : à travers lequel le prestataire peut ajouter, modifier, supprimer, rechercher
un produit
16
—Gérer promotion : à travers lequel le prestataire peut ajouter, modifier, supprimer, rechercher
une promotion
—Consulter statistique : à travers lequel le prestataire peut consulter les statistiques de vente
des produits vendues.
• Administrateur
—Etudier demande inscription prestataire : à travers lequel l’administrateur peut accepter ou

refuser une demande d’inscription de prestataire.
—Gérer membres : à travers lequel l’administrateur peut supprimer prestataire, supprimer client
—Gérer réclamation : à travers lequel l’administrateur peut répondre aux réclamations.
1.4.3. Définition des Besoins non fonctionnels

« Un besoin non fonctionnel est un besoin spécifiant des priorités du système, telles les
contraintes liées à l'environnement et à l'implémentation, et les exigences en matière de
performances, de dépendances de plateforme, de facilité de maintenance, d'extensibilité et de
fiabilité » [8]
Nous allons présenter dans cette section les besoins non fonctionnels qui spécifient les
propriétés du système, telles que les contraintes liées à l’environnement et à l’implémentation,
et les exigences en matière de performances, de dépendances de site web, de facilité de
maintenance, d’extensibilité et de fiabilité. Parmi ces besoins, nous pouvons insister sur :
• Ergonomie : la plateforme doit respecter le critère selon Étude des conditions de
travail et de l'adaptation des machines à l'homme.
• Performance : la plateforme doit respecter le critère en assurant un temps de
réponse minimum et des fonctionnalités répondant aux besoins de l'utilisateur.
• Fiabilité : Comme exigence principale, le système à développer doit être fiable. En
effet, le système doit permettre à l'utilisateur de bénéficier de ses fonctionnalités
anticipées dans la section d'analyse des besoins.
• L'efficacité : la plateforme doit fournir des réponses exactes et fiables.
• Sécurité : Dans le cadre de la cryptographie, les algorithmes de hachage pour
sécuriser les mots de passes.
17
1.5. Les cas d’utilisations

Un cas d’utilisation est un ensemble de séquences d’actions réalisées par le système et
produisant un résultat intéressant pour un acteur particulier. Il permet de décrire ce que le futur
système devra faire.
Les Relations Il existe quatre types de relations qui sont prises en charge par UML :
—Inclusions : « L’inclusion ou « Include » en anglais c’est une relation entre cas d’utilisation
; un cas A inclut un cas B si le comportement d’écriture par A inclut le comportement de B
c'est-à-dire le cas A dépend de B. Cette relation est présentée par une flèche interrompue avec
le terme « Include » ».
—Extensions :« L’extension ou « extends » en anglais. C’est une relation entre cas d’utilisation
; un cas d’utilisation A étend un cas d’utilisation B lorsque A peut être appelé au cours de
l’exécution de B. Ce type de relation est présenté par une flèche interrompue avec le terme «
extends » »
—Généralisation :« C’est le fait de relier deux acteurs. Un acteur A est une généralisation d’un
acteur B si l’acteur A peut-être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation
accessibles à A sont aussi à B, mais l’inverse n’est pas vrai. Cette relation est présentée par une
flèche »
—Association :« C’est une relation qui relie un acteur au cas d’utilisation. Elle est présentée
par un trait continu ou une flèche »
1.5.1. Diagramme de cas d’utilisation globale

Voici le diagramme de cas d'utilisation globale :
18
Figure 6:Diagramme des cas d’utilisation globale
1.6. Pilotage du projet avec Scrum

1.6.1. Les outils Scrum utilisés
1.6.1.1. Trello
Trello est un outil d'organisation collaboratif simple et gratuit.
Trello est un outil collaboratif qui organise tous vos projets en une série de listes partagées.
D'un seul coup d'œil Trello vous renseignera sur tous vos projets, sur leur état d'avancement et
vous dira qui travaille sur quoi dans votre équipe.
19
Figure 7:Imprime d'écran d'un tableau collaborative
1.6.2. Équipe et rôles

SCRUM définit trois rôles principaux. Ces rôles seront expliqués dans le tableau suivant :
Product Owner Il s’agit du représentant officiel du client au sein d’un projet Scrum.
(Directeur du Il est l’interlocuteur principal du Scrum Master et des membres de
produit) l’équipe. Il définit les besoins du produit et rédige les spécifications.
Il peut se faire aider de responsables fonctionnels pour la rédaction
des spécifications. Il est également chargé de définir et prioriser
laisser stories pour chaque sprint.
Scrum Master Il s’agit d’une personne chargée de veiller à la mise en application de

(Meneur de l’équipe, la méthode et au respect de ses objectifs. Il ne s’agit pas d’un chef de
facilitateur) projet, mais d’une personne chargée de lever les obstacles éventuels
qui empêcherait l’avancement de l’équipe et du projet pendant les
différents sprints.
Développement Ce sont les personnes chargées de la réalisation du sprint et d’un

Team (L’équipe) produit utilisable en fin de sprint. Il peut s’agir de développeurs,
architectes, personnes chargées de faire des tests fonctionnels.
L’équipe s’adresse directement au client
20
Tableau 6: Rôles SCRUM
Figure 8:scrum rôles [9]
1.6.3. Equipe « scrum » du notre projet
Tableau 7 : Equipe « Scrum » du notre projet
Détails de l’équipe
Nom Projet Site de vente d’une agence de fête
Propriétaire (Product Owner) Ayari Ameni
Directeur de produit (Scrum Master) Khemiri Nabil
Membre de l’équipe (Team members) Ayari Ameni
1.6.4. Le Backlog du produit

Le Backlog du produit correspond à une liste priorisée des besoins et des exigences du client.
Les éléments du Backlog de produit, appelé aussi les histoires utilisateurs, sont formulés en une
ou deux phrases décrivant de manières claires et précises la fonctionnalité désirée par le client,
Généralement, écrit sous la forme suivante En tant que X, je veux Y, an de Z.
Le Backlog de produit présenté dans le tableau 1 comprend les champs suivants :
• ID : C'est un nombre unique et auto-incrémenté pour chaque histoire utilisateur.
• User story : C'est une phrase décrivant la fonctionnalité désirée par le client.
21
• Priorité : C'est la valeur métier qui dirige la priorité du développement des histoires
utilisateurs suivant les attentes et les besoins du client, allant de 0 à 100.
• Story point : C'est l'effort nécessaire à la réalisation d'une histoire utilisateur.
Nous avons pu établir une étude an de répartir ces stories par priorité.
Les normes sur lesquelles nous nous sommes basés, sont :
Priorité : par rapport au client (Entreprise) représentée suivant la méthode "MoSCoW" qui est
une technique possédant un objectif qui s'articule autour d'un accord entre le maître
D’œuvre (MOE) et le maître d'ouvrage (MOA) sur l'importance des tâches que l'on va réaliser
par rapport aux délais prévus. MoSCoW a pour signification :
. M : doit être fait (vital).
. S : devrait être fait dans la mesure du possible (essentiel).
. C : pourrait être fait dans la mesure où cela n'a pas d'impact sur les autres tâches (confort).
. W : ne sera pas fait cette fois mais sera fait plus tard (luxe, c'est la zone d'optimisation
budgétaire). [10]
Dans ce tableau on trouve Backlog :
Tableau 8 : backlog du produit
ID Histoire Utilisateur Priorité Estimation

(Jour(s))
1 En tant que client et que visiteur, je veux pouvoir s’inscrire 1 2
2 En tant que client et que visiteur, je veux pouvoir rechercher 1 2
un produit
3 En tant que client et que visiteur, je veux pouvoir gérer mon 1 8
panier
4 En tant que client, je veux pouvoir passer une commande 1 8
5 En tant que client, je veux pouvoir envoyer une réclamation 1 2
6 En tant que client, je veux pouvoir suivre une commande 1 2
7 En tant que client, je veux pouvoir commenter un produit 1 1
8 En tant que client, je veux pouvoir noter un produit 1 1
9 En tant que prestataire, je veux pouvoir gérer produit 2 12
10 En tant que prestataire, je veux pouvoir gérer une promotion 2 8
11 En tant que prestataire, je veux pouvoir consulter les 2 2

statistiques
22
12 En tant qu’administrateur, je veux pouvoir gérer membre 3 8

(client, prestataire)
13 En tant qu’administrateur, je veux pouvoir gérer une 3 2
réclamation.
14 En tant qu’administrateur, je veux pouvoir étudier une 3 1
demande s’inscription d’un prestataire.
1.6.5. Planification des sprints

Une fois nous avons terminé le backlog du produit, nous avons établi la réunion de planification.
Le but de cette réunion est de construire le backlog de sprint en se basant sur le backlog de
produit réalisé par le Product owner. A la fin, nous avons identifié, les durées prévisionnelles
du travail à effectuer durant chaque sprint. Pour notre projet nous avons devisé le travail sur
trois chapitres. Pour le premier contient un deux sprints d’une durée de 3 semaine alors que le
deuxième chapitre contient un seul sprint caractérisé par une durée de 3 semaine de même pour
le dernier sprint.
1.7. Environnement de développement

L’environnement de développement est un terme qui désigne l’ensemble d’outils et de langages
utilisés pour l’implémentation d’une solution informatique. Nous allons commencer par
introduire l’environnement matériel et nous nous intéressons par la suite à présenter
l’environnement logiciel.
1.7.1. Environnement matériel
Cette section consiste à présenter l’environnement matériel qui a été employé pour la mise en
œuvre de notre application. Il s’agit d’un ordinateur portable de la marque Acer possédant les
caractéristiques suivantes :
Composant Caractéristiques
Processeur Intel® Core™ i3-4005U CPU
Horloge 2.16 GHz
Mémoire 4.00 Go
Disque dur 500 G
23
Ecran 15.4’’
Tableau 9: description de machine de développement
1.7.2. Environnement technique

Nous avons énuméré au cours de cette partie les différents outils utilisé tout au long de projet
pour l'étude et la mise en place de notre plateforme.
— Visual Paradigm : Permet la création des diagrammes UML et des modèles qui en sont à
l’origine. Ceux-ci peuvent alors générer du code dans un langage de programmation déterminé.
Il propose également la création d’autres types de diagrammes, comme celui qui permet la
modélisation des bases de données pouvant, lui aussi, générer des canevas d’applications basés
sur des Framework et Pattern mais en plus, générer du code SQL qu’il peut ensuite déployer
automatiquement dans différents environnements [11]
Figure 9: logo de Visual Paradigm
— MySQL : est un système de gestion de base de données. Son rôle est de stocker les données,
sous forme de tables, et de permettre la manipulation de ces données à travers le langage de
requête SQL. Le SQL dans "MySQL" signifie "Structured Query Language" le langage
standard pour les traitements de bases de données. [12]
Figure 10:Logo de MySQL
— Notepad++ : est un éditeur de texte libre générique, fonctionnant sous Windows, codé en
C++, qui intègre la coloration syntaxique de code source pour les langages informatiques. Ce
logiciel, a pour but de fournir un éditeur léger, et efficace. Le projet est sous licence GPL
version 2. Un équivalent sous Linux serait Gedit ou encore Kate. [13]
24
Figure 11:logo de Notepad ++
— Apache : C’est le serveur Web le plus utilisé sur Internet. Dans une architecture en
production, il est recommandé d'utiliser un serveur Web en frontal d'un serveur d'applications.
Ces recommandations sont également appliquées dans le cas de l'utilisation d'un conteneur Web
comme Tomcat. [14]
Figure 12: logo d’Apache
1.7.2.1. Technologies et langages utilisées

— Bootstrap : est une collection d’outils utile à la création du design de sites et d’applications
web. Elle contient des codes HTML et CSS, des formulaires, boutons, outils de navigation et
autres éléments ainsi que des extensions JavaScript en option. [15]
Figure 13:Logo de Bootstrap
— PHP : est un langage de programmation, orienté objet, principalement utilisé pour produire
des pages Web dynamiques via un serveur HTTP. Il est extrêmement puissant et destiné pour
le développement des applications web. PHP5 est l’un des langages de programmation les plus
populaire. Le point fort de ce langage c’est qu’il est portable et simple à utiliser. [16]
Figure 14 : logo de Php5
— HTML5 : est un langage de balisage conçu pour représenter les pages web. C’est un langage
permettant de définir les éléments des pages web, indique leur sens, leur importance et leur
hiérarchie tel que les titres, les paragraphes, les liens, les images etc. Le html5 est la dernière
25
révision majeure du html, caractérisé par l’ajout d’une multitude de nouvelles fonctionnalités
au langage html ainsi qu’au JavaScript. [17]
Figure 15:logo de HTML5
— CSS3 : est un langage de présentation qui sert à appliquer un style graphique aux éléments
définis par le html : police, couleur, taille de caractères etc. La présentation permet de rendre le
html plus lisible. [18]
Figure 16: logo de CSS3
— Javascript : est un langage de script incorporé dans un document HTML. C’est un langage
de programmation qui permet de créer des animations ou gérer l’interaction entre l’utilisateur
et la page. Il est fortement dépendant du navigateur appelant la page web dans laquelle le script
est incorporé. [19]
Figure 17 : logo de javascript
— WampServer : est une plateforme de développement Web de type WAMP, permettant de

faire fonctionner localement (sans se connecter à un serveur externe) des scripts PHP.
WampServer n'est pas en soi un logiciel, mais un environnement comprenant deux serveurs
(Apache et MySQL), un interpréteur de script (PHP), ainsi que phpMyAdmin pour
l'administration Web des bases MySQL.[20]
26
Figure 18:logo de WampServer
1.8. Architecture de la solution

Nous décrivons dans cette partie le fonctionnement de notre application. En globe le trois
architecture (Architecture logique, Architecture logicielle et Architecture de dossiers).
1.8.1. Architecture Applicatives
Architecture de dossiers MVC : Un des plus célèbres design patterns s'appelle MVC, qui
signifie Modèle - Vue - Contrôleur. C'est celui que nous allons découvrir maintenant.
Le pattern MVC permet de bien organiser son code source. Il va vous aider à savoir quels
fichiers créer, mais surtout à définir leur rôle. Le but de MVC est justement de séparer la logique
du code en trois parties que l'on retrouve dans des fichiers distincts.
· Modèle : cette partie gère les données de votre site. Son rôle est d'aller récupérer les
informations brutes dans la base de données, de les organiser et de les assembler pour qu'elles
puissent ensuite être traitées par le contrôleur. On y trouve donc entre autres les requêtes SQL.
· Vue : cette partie se concentre sur l'affichage. Elle ne fait presque aucun calcul et se contente
de récupérer des variables pour savoir ce qu'elle doit afficher. On y trouve essentiellement du
code HTML mais aussi quelques boucles et conditions PHP très simples, pour afficher par
exemple une liste de messages.
· Contrôleur : cette partie gère la logique du code qui prend des décisions. C'est en quelque
sorte l'intermédiaire entre le modèle et la vue : le contrôleur va demander au modèle les
données, les analyser, prendre des décisions et renvoyer le texte à afficher à la vue. Le
contrôleur contient exclusivement du PHP. C'est notamment lui qui détermine si le visiteur a le
droit de voir la page ou non (gestion des droits d'accès). [21]
La figure suivante schématise le rôle de chacun de ces éléments.
27
Figure 19:le modèle MVC [22]
Voici l’ordre d’exécution :

1. Le navigateur du client va envoyer une requête http lors de la demande d’une page ;
2. Le contrôleur traite cette requête et invoque l’état du modèle
3. Ce dernier retourne les données requises.
4. Une fois les données récupérées, le contrôleur les transmet à la vue qui se chargera de
retourner la réponse HTML au navigateur du client.
1.8.2. Architecture logicielle
La définition de l'architecture de l'application constitue une étape importante dans le processus
de conception. Elle dépend d'un certain nombre de facteurs dont on cite les exigences en matière
de performance, les perspectives, d'évolutivité, modularité et extensibilité. Cette section permet
de bien comprendre l'architecture en expliquant ses différentes couches : présentation, métier,
persistance.
· Présentation : C'est la première couche qui compose l'infrastructure trois tiers : il s'agit de la
partie rendu logiciel. Elle est rendue possible grâce aux langages de rendus, en l'occurrence
pour une application Web, le HTML5, le CSS3 et le JavaScript pour ajouter une partie
fonctionnelle à ce rendu.
· Métier : C'est la seconde couche qui compose l'infrastructure trois tiers : elle correspond à un
ensemble de composants métiers qui permettent de traiter un ensemble d'actions sur un serveur,
et de faire éventuellement appel à des services externes pour envoyer une réponse au client. Le
client communique donc avec le serveur grâce à l'interface graphique, puis le serveur fait son
traitement et renvoie la réponse au client. Les langages serveurs les plus utilisés sont : le PHP,
le Ruby, le C/C++/C#, mais également le Python.
28
· La couche d'accès aux données : C'est la troisième couche qui compose l'infrastructure trois-
tiers : elle correspond au serveur de base de données. Il s'agit de la couche d'accès aux données.
Sur ce troisième tiers, un SGBD (Système de Gestion de Base de Données) est installé, comme
par exemple MySQL ou Microsoft SQL Server, et ce serveur est requêté par le serveur applicatif
afin d'utiliser un certain nombre de données.
Figure 20:Architecture matérielle du système [23]
Conclusion
A la fin de ce chapitre, on a bien étudié les besoins du client : on a présenté l'ensemble des
fonctionnalités du futur portail de manière organisée dans les différents cycles de l'application
soit fonctionnel ou non fonctionnel, les livrables ainsi que les risques du projet. Ainsi qu’on a
organisé notre projet en utilisant la méthode SCRUM et en faisant un planning bien détaillé
avec la définition d'équipe de projet
29
CHAPITRE 2. SPRINT 1 : LES CAS DE PRIORITÉ 1
Chapitre 2
Sprint 1 : Les cas de priorité 1
2. Introduction
Ce chapitre fait l'objet d'une présentation du premier réalise du projet. Il peut être composé d'un
nombre défini de sprints. L'étude de chaque sprint couvre l'analyse, la conception et la
réalisation.
2.1. Spécification des besoins

Le Backlog du sprint contient une liste des tâches qui devront être réalisées avant la fin de
sprint.
Dans ce tableau on trouve la liste des tâches du premier Sprint :
Tableau 10:Product backlog du Sprint 1
ID User Story Tâche Priorité Estimation (jour(s))
1 En tant que client et S’inscrire 1 2

que visiteur, je veux
pouvoir s’inscrire
2 En tant que client et Rechercher produit 1 2

pouvoir rechercher un
produit
3 En tant que client et Ajouter produit 1 8

Modifier quantité
29
pouvoir gérer mon Supprimer produit

panier
4 En tant que client, je Choisir mode livraison 1 8

veux pouvoir passer
Payer
une commande
5 En tant que client, je Envoyer réclamation 1 2

veux pouvoir envoyer
une réclamation
6 En tant que client, je Suivre commande 1 2

veux pouvoir suivre
une commande
7 En tant que client, je Commenter produit 1 1

veux pouvoir
commenter un produit
8 En tant que client, je Noter produit 1 1

veux pouvoir noter un
produit
2.1.1. Raffiner les modèles des cas d’utilisation de priorité « 1 »

2.1.1.1. Diagramme de cas d’utilisation spécifiant « s’inscrire »
Pour pouvoir bénéficier les fonctionnalités de notre plateforme, le visiteur doit tout d’abord
s’inscrire.
Cette figure représente le digramme de cas d'utilisateur spécifiant « S'inscrire ».
30
Figure 21:diagramme de cas d’utilisation « S’inscrire »
2.1.1.2. Description des cas d'utilisation « S’inscrire »

Ce tableau décrit les acteurs, pré-condition, Post-condition, le scénario et les exceptions pour
le cas d’utilisation « s’inscrire »
Tableau 11: Fiche descriptive du cas d'utilisation « S'inscrire »
Acteur Le visiteur
Objectif S’inscrire sur la plateforme
Pré-condition(s) - Le visiteur dit accéder à la page d’inscription.
Post-condition(s) Le visiteur est devenu membre et peut accéder à son espace
personnel.
Scénario-Nominal 1. Le visiteur demande la page d’inscription ;
2.a. Le système lui affiche la page demandée ;
2. Le visiteur remplit le formulaire d’inscription ;
4.a. Le système vérifie les données saisies ;
5.a. Le système ajoute le visiteur dans la base de données et
affiche le message suivant : « votre inscription a été effectuée avec
succès. Merci de votre confiance ».
2.b. Le visiteur quitte la page d’inscription.
Scénario(s)
4.b. Le système affiche un message d’erreur et signale au visiteur de
alternatif(s)
recommencer la saisie.
Et d’exception :
5.b. Le cas d’utilisation reprend à l’étape 3 du scénario nominal.
2.1.1.3. Diagramme de cas d’utilisation spécifiant « rechercher produit »

Cette figure représente le diagramme de cas d’utilisation : rechercher produit
31
Figure 22:diagramme de cas d’utilisation « rechercher produit »
2.1.1.4. Description des cas d'utilisation « Rechercher produit »

Ce tableau décrit les acteurs, pré-condition, Post-condition, le scenario et les exceptions pour
le cas d’utilisation « Rechercher produit ».
Tableau 12:Fiche descriptive du cas d’utilisation « rechercher produit »
Acteur Le visiteur
Objectif Rechercher un produit
Pré-condition(s) Le visiteur doit accéder à la page d’accueil.
Post-condition(s) -Le visiteur trouve le produit rechercher
Scénario-Nominal 1. Le visiteur saisie le contenu de recherche
2. Le système doit vérifier l’existence de produit
3. Le système affiche le produit recherché
2.a. Le cas d’utilisation se termine avec échec si le produit n’existe
Scénario(s)
pas
alternatif(s)
Le cas d’utilisation reprend à l’étape 3 du scénario nominal.
Et d’exception :
2.1.1.5. Diagramme du cas d’utilisation « gérer panier »
Cette figure présente le diagramme du cas d’utilisation « Gérer panier » relatif à l’acteur «
visiteur ».
Notre plateforme permet au visiteur de gérer son panier, où il peut ajouter produit au panier,
modifier quantité de produit, supprimer produit au panier.
Ce tableau montre la fiche descriptive pour le sous cas d’utilisation : Ajouter produit au panier
32
Figure 23:Diagramme de cas d'utilisation « gérer panier »
2.1.1.6. Description du cas d’utilisations « Ajouter produit »

Ce tableau représente le raffinement de cas d'utilisation : « Ajouter produit »
Tableau 13:Fiche descriptive du cas d'utilisation « Ajouter produit »
Acteur Le visiteur
Objectif Ajouter un produit au panier
Pré-condition(s) - Le visiteur dit accéder à la page d’accueil
Post-condition(s) Le visiteur ajoute un produit dans son panier
Scénario-Nominal 1. Le visiteur choisit le produit a ajouté
2. Le système lui affiche la page demandée
3. Le visiteur clique sur le bouton ajouter au panier
4. Le système ajoute le produit dans la base de données et affiche
le message suivant : « votre produit a été ajoutée avec succès.
Merci de votre confiance »
3.a. Le visiteur quitte la page d’ajout de produit au panier
Scénario(s)
Le cas d’utilisation reprend à l’étape 3 du scénario nominal.
alternatif(s)
Et d’exception :
2.1.1.7. Diagramme du cas d’utilisation « s’authentifier »
Pour la sécurité de site, nous avons proposé une interface d’authentification manipulée par le
client. En effet, à travers ce cas d’utilisation, le client pouvoir se connecter au système en
composant un login et un mot de passe, le système va s’assurer de l’existence de client avant
de lui donner l’accès au système.
Cette figure illustre le diagramme de cas d’utilisation « s’authentifier »
33
Figure 24: Diagramme de Cas d’utilisation « s’authentifier »
2.1.1.8. Description du cas d'utilisation « s’authentifier »

Ce tableau représente le raffinement de cas d'utilisation « s’authentifier »
Tableau 14: Fiche descriptive du cas d’utilisation « s’authentifier »
Acteur Le client
Objectif Accès au site
Pré-condition(s) − Le client doit être inscrit,
− Le client doit connaitre ses identifiants,
− Le client doit accéder à la page d’accueil.
Post-condition(s) Le client doit accède à son espace personnel.
Scénario-Nominal 1. Le client demande l’accès à l’interface d’authentification ;
2. Le système afficher le formulaire d’inscription ;
3. Le client saisit son login et son mot de passe ;
4. Le système vérifie l’existence de données dans la base de
données ;
5. Le Système rédige le client envers son espace personnel.
Le client quitte la page d’authentification
Scénario(s)
Système affiche un message d'erreur en cas d'inexistence du mot de
alternatif(s)
passe et d'adresse Introduit.
Et d’exception :
2.1.1.9. Diagramme de cas d’utilisation « suivre commande »

Cette figure illustre le diagramme de cas d’utilisation « suivre commande »
34
Figure 25:diagramme de Cas d’utilisation « suivre commande »
2.1.1.10. Description du cas d’utilisation « suivre commande »

Ce tableau représente le raffinement de cas d'utilisation « suivre commande »
Tableau 15:Fiche descriptive du cas d’utilisation « suivre commande »
Acteur Le client
Objectif Le client suivre la commande
Pré-condition(s) S’authentifier
Post-condition(s) Le client accède à la liste de commande en cours
Scénario-Nominal 1. Le client sélectionne où chercher la commande en cours
2. Le système accédé à la base et affiche la commande
sélectionner
3. Le client consulte les commandes en cours
3. a. Le client quitte la page de suivre commande
Scénario(s)
Le cas d’utilisation se termine avec échec.
alternatif(s)
Et d’exception :
2.1.1.11. Diagramme du cas d’utilisation « passer commande »
Cette figure illustre le diagramme de cas d’utilisation « passer commande »
35
Figure 26: Diagramme de cas d’utilisation « passer commande »
2.1.1.12. Description du cas d’utilisation « passer commande »

Ce tableau représente le raffinement de cas d'utilisation « passer commande »
Tableau 16:Fiche descriptive du cas d’utilisation « passer commande »
Acteur Le client
Objectif Commander un produit
Pré-condition(s) S’authentifier
Post-condition(s) Le client passe une commande
Scénario-Nominal 1. Le client choisit le mode de livraison
2. Le client remplit les informations de la carte bancaire
3. Le système bancaire vérifie les informations de la carte
bancaire et renvoi l’autorisation
3.a. les informations de la carte bancaire non valide
Scénario(s)
3.b. Ou Le solde de la carte bancaire inferieur au total à payer
alternatif(s)
Et d’exception :
2.2. Conception des cas d'utilisations de priorité « 1 »

Cette partie consiste à présenter l'aspect statique de notre système. Pour ce faire, nous allons
utiliser le diagramme des classe, diagramme de séquence et le dictionnaire des données.
36
2.2.1. Diagrammes des séquences détaillés

Un diagramme de séquence détaillé est un diagramme d'interaction qui expose en détail la façon
dont les opérations sont effectuées : quels messages sont envoyés et quand ils le sont. Les
diagrammes de séquence sont organisés en fonction du temps.
Le principe de ce diagramme est de détailler le diagramme de séquence système, il permet de
découper le « système » en trois objets :
− Interface ;
− Contrôle ;
− Entité ;
Les objets impliqués dans l'opération sont répertoriés de gauche à droite en fonction du moment
où ils prennent part dans la séquence de messages.
− Message simple : le message n'a pas de spécificité particulière d'envoi et de réception.
− Message avec durée de vie : l'expéditeur attend une réponse du récepteur pendant un
certain temps et reprend ses activités si aucune réponse n'a lieu dans un délai prévu.
− Message synchrone : l'expéditeur est bloqué jusqu'au signal de prise en compte par le
destinataire. Les messages synchrones sont symbolisés par des flèches barrées.
− Message asynchrone : le message est envoyé, l'expéditeur continue son activité que le
message soit parvenu ou pris en compte ou non. Les messages asynchrones sont symbolisés
par des demi-flèches.
− Message dérobant : le message est mis en attente dans une liste d'attente de traitement chez
le récepteur.
Figure 27:exemple de diagramme de séquence détaillé
2.2.1.1. Diagramme de séquence pour le cas d’utilisation « s’authentifier »

Cette figure expose le scénario relatif à l’authentification suite à laquelle le client peut
bénéficier des différentes fonctionnalités de notre système. D’abord, il demande l’interface de
l’authentification. Suite à l’affichage de la page demandée. L’utilisateur saisit son login et son
37
mot de passe. Le système vérifie les données saisies, si elles sont correctes, il autorise le client
à se connecter en lui redirigeant vers son espace personnel.
Figure 28:Diagramme de séquence « s’authentifier »
2.2.1.2. Diagramme de séquence pour le cas d’utilisation « rechercher produit »

Cette figure modélise le scénario de la recherche d’un produit. Le client saisie le contenu de
rechercher dans la zone de recherche puis clique sur le bouton rechercher, le système va pour
vérifier l’existence de produit recherché dans la base de données, s’il existe, le système affiche
le produit, sinon, il affiche un message de non existence du produit.
38
Figure 29:Diagramme de séquence « rechercher produit »
2.2.1.3. Diagramme de cas d’utilisation « envoyer réclamation »

En cas de problème, un client accédé au site, puis il demande d’envoyer une réclamation à
l’administrateur, il remplit par la suite le formulaire affiché dans la page. En cliquant sur le
bouton « envoyer », un message de confirmation s’affiche.
39
Figure 30:Diagramme de séquence « envoyer réclamation »
2.2.1.4. Diagramme de séquence « s’inscrire »

La figure ci-dessous décrit les messages démarche de l’opération inscription, âpres être
connecter ou posséder un espace dans le site web, le visiteur peut faire une inscription. Lors
de cliquer sur le bouton inscription le système renvoie un formulaire d’inscription contenant
des informations personnels (nom, prénom, adresse, ville, sexe, téléphone, etc.) et des
informations de connexion (login et mot de passe) le visiteur remplit ce formulaire et puis clic
sur valider, le système vérifier la requête d’insertion lors de l’enregistrement à la base de
données, et revoie un message de confirmation (inscription réussite ).
40
Figure 31:Diagramme de séquence « s’inscrire »
2.2.1.5. Diagramme de séquence « passer commande »

Le client accédé au site puis il demande de commander un produit, le système affiche un
formulaire, le remplit le formulaire, puis le système vérifie l’existence de produit dans la base
de données, en cas où il trouve le produit, il va afficher un message de confirmation sur
l’interface de commander un produit.
41
Figure 32:Diagramme de séquence « passer commande »
2.2.2. Diagrammes de collaboration

Comme les diagrammes de séquence, les diagrammes de collaboration sont également des
diagrammes d'interaction. Les diagrammes de collaboration véhiculent les mêmes informations
que les diagrammes de séquence, mais ils se concentrent sur les rôles des objets plutôt que sur
les moments où les messages sont envoyés. Dans un diagramme de séquence, les rôles d'objets
sont les sommets et les messages sont les liens de connexion.
Dans un diagramme de collaboration (voir ci-après), les rectangles rôle d'objet sont libellés avec
les noms de classe ou d'objet (ou les deux). Le symbole deux-points (:) précède les noms de
classe.
Cette figure illustre le diagramme de collaboration du cas d’utilisation « s’inscrire »
42
Figure 33:Diagramme de collaboration pour le cas d’utilisation « s’inscrire »
2.2.2.1. Diagramme de collaboration pour le cas d’utilisation « s’authentifier »

La figure illustre le diagramme de collaboration du cas d’utilisation « S’authentifier ».
Dans ce diagramme, nous montrons les interactions entre les objets :
— Le client saisit ses paramètres (login, Mot de passe) et clique sur le bouton se connecter
— le système vérifie les paramètres saisis par l’utilisateur et affiche la page d’accueil selon le
droit d’accès.
Figure 34:Diagramme de collaboration pour le cas d’utilisation « s’authentifier »
2.2.2.2. Diagramme de collaboration pour le cas d’utilisation « envoyer réclamation »

Cette figure illustre le diagramme de collaboration du cas d’utilisation « envoyer réclamation
».
Dans ce diagramme, nous montrons les interactions entre les objets :
—Le client remplit le formulaire pour l’envoyer en cliquant sur le bouton envoyer
—Le système doit vérifier les champs de saisie puis renvoie au client un message de
confirmation « réclamation envoyé avec succès »
43
Figure 35:Diagramme de collaboration pour le cas d’utilisation « envoyer réclamation »
2.2.2.3. Diagramme de collaboration pour le cas d’utilisation « rechercher produit »

Cette figure illustre le diagramme de collaboration du cas d’utilisation « rechercher produit ».
Dans ce diagramme, nous montrons les interactions entre les objets suivants :
—Le client saisie le contenu de recherche dans la zone de recherche
—Le client clique sur le bouton rechercher
—Le système affiche le produit recherché
Figure 36:Diagramme de collaboration pour le cas d’utilisation « rechercher produit »
2.2.3. Diagrammes d’état-transitions

Les diagrammes d’états-transitions permettent de décrire les changements d’états d’un objet ou
d’un composant, en réponse aux interactions avec d’autres objets/composants ou avec des
44
acteurs. Un état se caractérise par sa durée et sa stabilité, il représente une conjonction

instantanée des valeurs des attributs d’un objet.
2.2.3.1. Diagramme d’états-transitions pour l’objet « commande »
La figure ci-dessous présente le diagramme d’états-transitions pour l’objet « commande »
Figure 37:Diagramme d’état de transition « commande »
2.2.4. Diagrammes d’activités

Un diagramme d'activité permet de modéliser le comportement du système, dont la séquence
des actions et leurs conditions d'exécution. Les actions sont les unités de base du comportement
du système.
Un diagramme d'activités permet de grouper et de dissocier des actions. Si une action peut être
divisée en plusieurs actions en séquence, vous pouvez créer une activité les représentant
Cette figure présente le diagramme d’activité pour le cas d’utilisation « S’inscrire »
45
Figure 38:Diagramme d’activité pour le cas d’utilisation « S’inscrire »
Cette figure présente le diagramme d’activité pour le cas d’utilisation « S’authentifier ».
Figure 39:Diagramme d’activité pour le cas d’utilisation « S’authentifier »
2.2.5. Diagramme de classes

Le diagramme de classes est la représentation graphique de la structure interne d'un Système.
Les principaux éléments de cette vue statique sont les classes et les différentes relations entre
celles-ci.
2.2.5.1. Les règles de passage
Un diagramme de classes va être retransformé en une base de données relationnelle. Chaque
information dégagée sera renommée sans avoir changé son contenue. Ces transformations doivent
s'appliquer en respectant les règles suivantes :
46
Tableau 17:Tableau de règles de passage du diagramme de classes vers la base de données relationnelle
Modèle d’objet Modèle relationnel
Identifiant Clé primaire
Classe Table
Association « un à un » Intégrer une clé étrangère
Association « un à plusieurs » Intégrer une clé étrangère dans la table
Associations « plusieurs à plusieurs » Créer une nouvelle table qui admet comme clé
primaire la concaténation des clés primaires des deux
tables issues des deux classes de la relation
Héritage Étendre les propriétés de la classe mère pour les

sous-classes
Cette figure présente le diagramme de classe du premier sprint :
Figure 40:Diagramme de classes du premier sprint
2.2.5.2. Dictionnaire de données

Ce tableau représente le dictionnaire des données pour la table « client »
47
Tableau 18:Le dictionnaire des données pour la table « client »
Nom de l’attribut Type de données Taille Contrainte
Id_client Int 11 Clé primaire
Login Varchar 16 _
Password Varchar 30 _
Nom Varchar 20 _
Prénom Varchar 20 _
Email Varchar 50 _
Adresse Text _
Téléphone Varchar 12 _
Photo Longtext _
Sexe Varchar 20 _
Ville Varchar 100 _
Ce tableau représente le dictionnaire des données pour la table « produit »
Tableau 19: Le dictionnaire des données pour la table" produit"
Reference Varchar 50 Clé primaire
Id_prestataire Int 11 Clé étrangère
Id_catégorie Varchar 50 Clé étrangère
Désignation Varchar 100 _
Description Longtext _ _
Prix Double _ _
48
Quantité Int 11 _
Etat Varchar 100 _
Image_path Text _ _
Ce tableau représente le dictionnaire des données pour la table « commande »
Tableau 20:Le dictionnaire des données pour la table "Commande"
Reference_commande Int 11 Clé primaire
Id_client Varchar 20 Clé étrangère
Etat_commande Varchar 20 _
Date_commande Varchar 10 _
Ce tableau représente le dictionnaire des données pour la table « réclamation »
Tableau 21:Le dictionnaire des données pour la table « réclamation »
Id Int 11 Clé primaire
Id_client Varchar 20 Clé étrangère
Id_prestataire Int 11 Clé étrangère
Date Date _ _
Objet Varchar 200 _
Message Longtext _ _
Réponse Longtext _ _
Ce tableau représente le dictionnaire des données pour la table « commentaire »
49
Tableau 22:Le dictionnaire des données pour la table « commentaire »
Référence_produit Varchar 20 Clé étrangère
Email Varchar 100 _
Texte Longtext _ _
Date Varchar 20 _
Ce tableau représente le dictionnaire des données pour la table « favoris »
Tableau 23:Le dictionnaire des données pour la table « favoris »
Id_client Int 11 Clé étrangère
Id_produit Varchar 100 Clé étrangère
Ce tableau représente le dictionnaire des données pour la table « catégories_produit »
Tableau 24:Le dictionnaire des données pour la table « catégories_produit »
Description Varchar 100 _
Ce tableau représente le dictionnaire des données pour la table « ligne_commande »
Tableau 25:Le dictionnaire des données pour la table « ligne_commande »
Reference_commande Varchar 20 Clé étrangère
Id_produit Varchar 20 Clé étrangère
50
Quantité Int 10 _
Ce tableau représente le dictionnaire des données pour la table « photos_produit »
Tableau 26:le dictionnaire des données pour la table « photos_produit »
Référence Varchar 100 Clé primaire
Image_path Varchar 500 _
Color Varchar 100 _
2.2.6. Implémentation des cas d'utilisation prioritaires

2.2.6.1. Interface « inscription »
Pour pouvoir bénéficier des différentes fonctionnalités offertes par notre application, le visiteur
devra s’inscrire : il saisit ses données personnelles pour pouvoir connecter ensuite en tant que
client. Cette figure représente l’interface d’inscription.
Figure 41:interface « s'inscrire »
2.2.6.2. Interface « s’authentifier »

Chaque utilisateur doit s'authentifier via son pseudo et son mot de passe. Si l'utilisateur est
connecté, la page d'accueil est affichée. Si le pseudo et le mot de passe sont incorrects, un
message d'erreur sera affiché.
51
Cette figure représente l'interface « s’authentifier »
Figure 42:interface "s'authentifier"
2.2.6.3. Interface « passer commande »

Après avoir s’authentifier, le client saisit les informations de la carte bancaire et payer la
commande.
Cette figure représente l’interface de « passer commande »
Figure 43:Interface passer commande
2.2.6.4. Interface « commenter » et « noter produit »

Le client écrit un commentaire sur un produit ou le noter par une étoile.
52
Cette figure représente l’interface de commenter/noter un produit.
Figure 44:Interface commenter et noter produit
2.2.6.5. Interface envoyer réclamation

Le client peut envoyer une réclamation en cas du non satisfaction du produit
Cette figure représente l’interface d’envoyer réclamation
Figure 45:Interface envoyer réclamation
53
2.3. Test
Le tableau ci-dessous présente un ensemble de cas de tests relatif au sprint 1.
Tableau 27:Tests du sprint 1
Cas de test Démarche Comportement Résultats

attendu
Test d’inscription du Remplir formulaire Le client s’inscrire Conforme
client d’inscription avec succès
Test d’authentification Remplir le Le client Conforme

du client formulaire s’authentifier
d’authentification
Test de passer Sélectionner les Commande passée Conforme

commande produits puis cliquer avec succès
sur le bouton passer
commande
Test de commenter et Commenter un Commentaire Conforme

noter un produit produit/ donner une ajouter avec succès
note pour un produit
Test d’envoyer Remplir le Réclamation Conforme

réclamation formulaire d’envoi envoyée avec
de réclamation succès
Conclusion
Dans ce chapitre nous avons présenté les différents diagrammes modélisant l'aspect dynamique
et statique de notre plate-forme, dans cette partie nous avons présenté la première phase de notre
projet : la réalisation.
54
Chapitre 3
Sprint 2 : les cas de priorité 2
Introduction
Ce chapitre fait l'objet d'une présentation du deuxième réalise du projet. Il peut être composé
d'un nombre défini de sprints. L'étude de chaque sprint couvre l'analyse, la conception et la
réalisation.
Sprint.
Dans ce tableau on trouve la liste des tâches du deuxième Sprint :
ID Histoires Tâche Priorité Estimation
(jour(s)
9 En tant que 1. Ajouter produit 2 2

prestataire, je veux 2. Modifier produit
pouvoir gérer produit 3. Supprimer produit
4. Rechercher produit
10 En tant que 1. Ajouter promotion 2 2
prestataire, je veux 2. Modifier promotion
pouvoir gérer une 3. Supprimer promotion
promotion 4. Rechercher promotion
11 En tant que 1. Consulter statistique 2 2
prestataire, je veux
pouvoir consulter les
statistiques
Tableau 28: Backlog du sprint 2
55
3.1.1. Raffiner les modèles des cas d'utilisation de priorité « 2 »

3.1.1.1. Diagramme de cas d’utilisation spécifiant « S’inscrire »
La figure décrit le cas d’utilisation (s’inscrire). En effet, un acteur ne peut accéder à la
plateforme qu’une fois inscrire à travers l’interface inscription, en saisissant ces informations.
Figure 46:Diagramme de cas d’utilisation « S’inscrire »
3.1.1.2. Description du cas d’utilisation : « s’inscrire »

Ce tableau représente la description du cas d’utilisation « s’inscrire »
Tableau 29:Fiche descriptive du cas d’utilisation « S’inscrire »
Acteur Le prestataire
Objectif Le prestataire remplit le formulaire d’inscription pour effectuer son
inscription.
Pré-condition(s) Le prestataire doit accéder à la page d’accueil.
Post-condition(s) Le prestataire est devenu membre et peux accéder à son espace
personnel.
Scénario-Nominal 1. Le prestataire demande la page d’inscription ;
2. Le système lui affiche la page demandée ;
3. Le prestataire remplit le formulaire d’inscription ;
4. Le système vérifie les données saisies ;
5. Le système ajoute le prestataire dans la base de données et
affiche le message suivant : « Vous êtes déjà inscrit. Merci de
votre confiance ».
3. a. Le prestataire quitte la page d’inscription :
Scénario(s)
1. Le cas d’utilisation se termine avec échec.
alternatif(s) 4. a. Les données saisies sont incorrectes ou manquantes :
Et d’exception : 1. Le système affiche un message d’erreur et signale au prestataire
de recommencer la saisie.
2. Le cas d’utilisation reprend à l’étape 3 du scénario nominal.
3.1.1.3. Diagramme du cas d’utilisation « S’authentifier »

Cette figure décrit le cas d’utilisation (s’authentifier). En effet, le prestataire ne peut accéder à
la plateforme qu’une fois authentifié à travers l’interface authentification, en saisissant un
« login » et un « mot de passe ».
56
Figure 47:Diagramme de cas d’utilisation « S’authentifier »
3.1.1.4. Description des cas d'utilisation : « s’authentifier »

Ce tableau décrit les acteurs, pré-condition, Post-condition, le scenario et les exceptions pour
le cas d’utilisation « s’authentifier ».
Tableau 30: Fiche descriptive du cas d’utilisation « S’authentifier »
Objectif Lors de l’accès au site, le prestataire doit s’authentifier pour accéder
aux différentes fonctionnalités du site.
Pré-condition(s) - Le prestataire doit être inscrit,
- Le prestataire doit connaitre ses identifiants,
- Le prestataire doit accéder à la page d’accueil.
Post-condition(s) Le prestataire accède à son espace personnel
Scénario-Nominal 1. Le prestataire demande la page d’authentification ;
2. Le système lui affiche la page demandée ;
3. Le prestataire saisit son login et son mot de passe ;
5. Le système affiche l’espace personnel du prestataire
3. a. Le prestataire quitte la page d’authentification :
Scénario(s)
alternatif(s) 4. a. Le prestataire n’a pas saisi les bons identifiants (contrôle de
Et d’exception : saisie) :
1. Le système affiche un message d’erreur et signale au prestataire
de recommencer la saisie.
3.1.1.5. Diagramme du cas d’utilisation « Gérer les produits »

Cette figure représente le diagramme de cas d'utilisateur spécifiant « gérer produit »
57
Figure 48:Diagramme du cas d’utilisation « Gérer produit »
3.1.1.6. Description du cas d'utilisation « Ajouter produit »

Ce tableau représente le raffinement de sous cas d'utilisation « Ajouter produit »
Tableau 31: Fiche descriptive du sous cas d'utilisation « Ajouter produit »
Pré-condition(s) - Le prestataire doit être authentifié.
- Le prestataire doit accéder à l’interface « Gérer produit ».
Post-condition(s) Produit est ajoutée avec succès
Scénario-Nominal 1. Le prestataire demande l’interface « Ajouter produit » ;
2. Le système affiche l’interface demandée ;
3. Le prestataire remplit le formulaire d’ajout d’un produit ;
5. Le système ajoute le produit dans la base de données et affiche
le message suivant : « Produit ajouté avec succès ».
3. a. Le prestataire quitte la page d’ajout d’un produit :
Scénario(s)
alternatif(s) 4. a. Les données saisies sont incorrectes ou manquantes :
Et d’exception : 1. Le système affiche le message d’erreur et signale à Le
prestataire de corriger les erreurs mentionnées dans le message.
3.1.1.7. Description du cas d'utilisation « Modifier produit »
Ce tableau représente le raffinement de sous cas d'utilisation « Modifier produit »
Tableau 32: Fiche descriptive du sous cas d'utilisation « Modifier produit »
Post-condition(s) Le produit est modifié avec succès
Scénario-Nominal 1. Le prestataire sélectionne un produit et demande l’interface
« Modifier produit » ;
2. Le système affiche l’interface demandée avec les informations
du produit sélectionné ;
58
3. Le prestataire saisit les nouvelles données ;

5. Le système met à jour les informations du produit dans la base
de données et affiche le message suivant : « Produit modifié
avec succès ».
3. a. Le prestataire quitte la page de modification d’un produit :
Scénario(s)
alternatif(s)
4. a. Les données saisies sont incorrectes ou manquantes :
de corriger les erreurs mentionnées dans le message.
3.1.1.8. Description du cas d'utilisation « Supprimer produit »

Ce tableau représente le raffinement de sous cas d'utilisation « Supprimer produit »
Tableau 33: Fiche descriptive du sous cas d'utilisation « Supprimer produit »
- Le prestataire doit accéder à la liste des produits.
Post-condition(s) Produit supprimé avec succès
Scénario-Nominal 1. Le prestataire sélectionner un produit ;
2. Le prestataire demande de supprimer le produit sélectionné ;
3. Le système demande une confirmation de suppression ;
4. Le prestataire confirme la suppression du produit ;
5. Le système supprime le produit de la base de données et affiche
le message suivant : « Produit supprimé avec succès ».
4. a. Le prestataire annule la suppression du produit :
Scénario(s)
alternatif(s) 5. a. Le produit sélectionné existe dans une ou plusieurs
commandes en cours :
qu’il est impossible de supprimer ce produit.
3.1.1.9. Diagramme du cas d’utilisation « Gérer promotion »
Cette figure représente le diagramme de cas d'utilisateur spécifiant « Gérer promotion »
59
Figure 49:Diagramme du cas d'utilisation « Gérer promotion »
3.1.1.10. Description des cas d'utilisation : « Ajouter promotion »

Ce tableau représente le raffinement de sous cas d'utilisation « Ajouter promotion »
Tableau 34: Fiche descriptive du cas d’utilisation « Gérer promotion (ajouter promotion) »
Post-condition(s) Une nouvelle promotion est ajoutée à la liste de promotions
Scénario-Nominal 1. Le prestataire demande au système la page de mise à jour
de ses promotions
2. Le système affiche la page ainsi que la liste de promotions
et les différentes opérations possibles
3. Le prestataire choisit l’opération d’ajout
4. Le système affiche le formulaire d'ajout
5. Le prestataire remplit le formulaire et valide
6. Le système met à jour la liste de promotions et par défaut
la liste des promotions les plus récentes
Scénario(s) alternatif(s)
5.a. Le système affiche un message d’échec si les paramètres non
Et d’exception : valides ;
3.2.Conception des cas d'utilisations de priorité « 2 »

Cette partie consiste à présenter l'aspect dynamique de notre système. Pour ce faire, nous allons
utiliser le diagramme de classe d'analyse, diagramme de séquence, diagramme de collaboration,
diagramme d'activité.
60
3.2.1. Diagramme de séquence

3.2.1.1.Diagramme de séquence « inscription » pour l’acteur « prestataire »
Cette figure représente le diagramme de séquence inscription pour l’acteur prestataire
Figure 50:Diagramme de séquence « inscription prestataire »
3.2.1.2. Diagramme de séquence « S’authentifier »
Cette figure représente le diagramme de séquence « S’authentifier » permettant au prestataire

de se connecter pour réaliser certains services.
61
Figure 51:Diagramme de séquence « S’authentifier »
3.2.2. Diagramme de séquence pour le scénario « ajouter produit »

Le prestataire accédé au site pour ajouter un nouveau produit, donc le prestataire accéder à le
formulaire d’authentification traite les démarches de l’authentification, clic sur le lien ajouter
produit, faire le remplissage de le formulaire et envoyer le demande, le contrôleur de le
formulaire vérifier les champs de saisir si les donnes sont correctes le requête envoyer à la
base et vérifier l’existence de la requête , le système renvoie un résultat a l’interface d’insertion
de produit contenant un message sinon le requête d’insertion va à la base de données , le
système vérifie la requête et renvoie un résultat de confirmation l’insertion de produit.
La figure ci-dessous représente le diagramme de séquence « ajouter produit »
62
Figure 52:diagramme de séquence" ajouter produit"
3.2.3. Diagramme de séquence pour le scénario "modifier produit"

Nous allons exposer dans la figure ci-dessous le diagramme de séquence « gérer les produits »
qui permet au prestataire de modifier un produit.
Le prestataire accédé au site pour modifier un produit, donc le prestataire accéder à le formulaire
d’authentification traite les démarches de l’authentification, clic sur le lien modifier produit,
faire le remplissage de le formulaire et envoyer le demande, le contrôleur de le formulaire
vérifier les champs de saisir si les donnes sont correctes le requête envoyer à la base et vérifier
l’existence de la requête , le système renvoie un résultat a l’interface de MAJ de produit
contenant un message sinon le requête de mise à jour va à la base de données , le système
vérifie la requête et renvoie un résultat de confirmation de la modification de produit.
63
Figure 53:diagramme de séquence "modifier produit"
3.2.4. Diagramme de séquence « supprimer produit »

Nous allons exposer dans la figure ci-dessous le diagramme de séquence « gérer les produits »
qui permet au prestataire de supprimer un produit.
Le prestataire accédé au site pour supprimer un produit, donc le prestataire accéder au

formulaire d’authentification traite les démarches de l’authentification, clic sur le lien
supprimer produit, le système renvoie un résultat de requête contenant un message « produit
supprimer avec succès »
64
Figure 54:diagramme de séquence "supprimer produit"
3.2.5. Diagramme de séquence pour le scénario « ajouter promotion »

Le prestataire accédé au site puis il demande d’ajouter une promotion, le système lui affiche un
formulaire d’ajout, le prestataire remplit le formulaire, le système vérifie les données envoyées
puis il envoie un message de confirmation au prestataire.
Nous allons exposer dans la figure ci-dessous le diagramme de séquence « gérer les
promotion » qui permet au prestataire d’ajouter une promotion
65
Figure 55:diagramme de séquence "ajouter promotion"
3.2.6. Diagramme de séquence pour le scénario « supprimer promotion »

Le prestataire accédé au site puis il demande de supprimer une promotion, le système vérifie la
requête envoyée puis il envoie un message de confirmation au prestataire.
Nous allons exposer dans la figure ci-dessous le diagramme de séquence « gérer promotion »
qui permet au prestataire de supprimer une promotion.
66
Figure 56:Diagramme de séquence pour le scénario « Supprimer promotion »
3.3.Diagramme de collaboration
3.3.1. Diagramme de collaboration « ajouter produit »
Cette figure illustre le diagramme de collaboration de cas d'utilisation « ajouter produit »
Figure 57:Diagramme de collaboration « Ajouter produit »
3.3.2. Diagramme de collaboration « supprimer promotion »

Cette figure illustre le diagramme de collaboration de cas d'utilisation « supprimer promotion »
67
Figure 58:Diagramme de collaboration « Supprimer promotion »
3.4.Diagramme d’activités
3.4.1. Diagramme d’activité pour le cas d’utilisation « Modifier produit »
Cette figure présente le diagramme d’activité pour le cas d’utilisation « modifier produit »
Figure 59:Diagramme d’activité pour le cas d’utilisation « Modifier produit »
3.5.Diagramme des classes

Cette figure représente un modèle de diagramme classes que nous avons conçu lors du
deuxième Sprint.
68
Figure 60:Diagramme de classes du deuxième Sprint
3.5.1. Dictionnaire de données

Cette partie représenté les dictionnaires de la principale table de Sprint 2 :
Ce tableau présente le dictionnaire de données pour la table « Prestataire »
Tableau 35:dictionnaire de données pour la table « Prestataire »
Id_prestataire Int 8 Clé primaire
Type Int 11 Clé étrangère
Nom Varchar 30 _
Prénom Varchar 20 _
Adresse Text _
69
Sexe Varchar 20 _
Password Varchar 50 _
Email Varchar 100 _
Téléphone Int 8 _
Photo Varchar 500 _
Etat Varchar 50 _
Ce tableau présente le dictionnaire des données pour la table « promotion »

Tableau 36: dictionnaire des données pour la table « promotion »
Titre Text _ _
Référence_produit Varchar 100 Clé étrangère
Solde Varchar 20 _
Prix Long Int 20 _
Date début Date _ _
Date fin Date _ _
Ce tableau présente le dictionnaire des données pour la table « Type »

Tableau 37:dictionnaire des données pour la table « Type »
Titre Text _ _
70
3.6.Implémentation des cas d'utilisation prioritaires

3.6.1. Interface authentification prestataire
A travers cette interface, le prestataire doit s’authentifier via son login et son mot de passe. Si
le prestataire est connecté, l’espace personnel est affichée. Si le Login et le mot de passe sont
incorrects, un message d’erreur sera affiché.
Figure 61:Interface authentification prestataire
3.6.2. Interface ajouter produit

Pour pouvoir ajouter un produit, le prestataire doit saisie le formulaire d’ajout comme
l’indique cette figure.
71
Figure 62:Interface ajouter produit
3.6.3. Interface modifier produit

A travers cette interface, les prestataires peuvent modifier ou supprimer un produit comme
l'illustre la figure.
Figure 63:Interface modifier/supprimer produit
72
Figure 64:Interface modifier produit
3.6.4. Interface consulter statistique

A travers cette interface, le prestataire peut consulter la statistique de vente de ses produits.
Figure 65:Interface consulter statistique
3.6.5. Interface ajouter promotion

A travers cette interface, le prestataire peut ajouter une promotion
73
Figure 66: Interface ajouter promotion
3.6.6. Interface modifier promotion

A travers cette interface, le prestataire peut modifier ou supprimer une promotion
Figure 67:Interface modifier promotion
3.7. Test
Le tableau ci-dessous présente un ensemble de cas de tests relatif au sprint 2 :
74

attendu
Test d’inscription du Remplir formulaire Le prestataire Conforme
prestataire d’inscription s’inscrire avec
succès
Test d’ajouter un Remplir le formulaire Produit ajouté Conforme

produit d’ajout avec succès
Test de modifier un Sélectionner les Produit modifié Conforme

produit produits puis cliquer avec succès
sur le bouton modifier
Test de supprimer un Sélectionner les Produit supprimé Conforme

produit produits puis cliquer avec succès
sur le bouton
supprimer
Test d’ajout une Remplir le formulaire Promotion ajoutée Conforme

promotion d’ajout du promotion avec succès
Test de modifier une Remplir le formulaire Promotion Conforme

promotion de modification du modifiée avec
promotion succès
Test supprimer une Choisir la promotion Promotion Conforme

promotion puis cliquer sur le supprimée avec
bouton supprimer succès
Test de consulter Commenter un produit/ Commentaire Conforme

statistique donner une note pour ajouter avec
un produit succès
Conclusion
Dans ce chapitre nous avons présenté les différents diagrammes modélisant l'aspect dynamique
et statique de notre plate-forme, dans cette partie nous avons présenté la deuxième phase de
notre projet : la réalisation.
75
Chapitre 4
Sprint 3 : les cas de priorité 3
Introduction
Ce chapitre fait l'objet d'une présentation du troisième réalise du projet. Il peut être composé
d'un nombre défini de sprints. L'étude de chaque sprint couvre l'analyse, la conception et la
réalisation.
sprint.
Dans ce tableau on trouve la liste des tâches du troisième Sprint :
Tableau 39:Product backlog de troisième Sprint
ID Histoires Tâche Priorité Estimation

(jour(s)
12 En tant qu’administrateur, Supprimer client 3 2

je veux pouvoir gérer Supprimer prestataire
membre (client,
prestataire)
13 En tant qu’administrateur, Consulter réclamation 3 2
je veux pouvoir gérer une Supprimer réclamation
réclamation. Répondre réclamation
14 En tant qu’administrateur, Etudier demande 3 1
je veux pouvoir étudier inscription prestataire
une demande s’inscription
d’un prestataire.
74
4.1.1. Raffiner les modèles des cas d'utilisation de priorité « 3 »

4.1.1.1. Diagramme de cas d'utilisation « gérer membre »
Cette figure représente le raffinement de cas d'utilisation « gérer membre ».
Figure 68:Diagramme de cas d'utilisation « gérer membre »
4.1.1.2. Description de cas d'utilisation : fiche de cas d'utilisation

Ce tableau représente le raffinement de sous cas d'utilisation « supprimer client »
Tableau 40:Raffinement de cas d'utilisation « supprimer client »
Acteur L’administrateur
Pré-condition(s) - L’admin doit être authentifié.
Post-condition(s) Client supprimé
Scénario-Nominal 1. L’administrateur demande de mise à jour client
2. Le système affiche liste des clients
3. L’administrateur sélectionne un client et clique sur supprimer
4. Le système vérifier l’action de suppression et affiche un
message succès de suppression
Scénario(s)
4.a. Le système affiche un message d’échec si le client n’existe pas
alternatif(s)
Et d’exception :
4.1.1.3. Diagramme de cas d'utilisation spécifiant « gérer réclamation »

Cette figure représente le raffinement de cas d'utilisation « gérer réclamation »
75
Figure 69:Diagramme de cas d'utilisation « gérer réclamation »
4.1.1.4. Description de cas d'utilisation « répondre réclamation »

Ce tableau représente le raffinement de sous cas d'utilisation « répondre réclamation »
Tableau 41:Raffinement de cas d'utilisation « répondre réclamation »
Pré-condition(s) - Session ouverte
Post-condition(s) Répondre au réclamation
Scénario-Nominal 1. L’administrateur consulte liste de réclamation
2. Le système affiche l’interface ;
3. L’admin répondre aux réclamations ;
4. Le système enregistrer la modification ;
Le système affiche un message d’échec si les paramètres non valides
Scénario(s)
;
alternatif(s)
Et d’exception :
4.1.1.5. Diagramme de cas d'utilisation « Etudier demande inscription prestataire »

Cette figure représente le raffinement de cas d'utilisation « Etudier demande inscription
prestataire »
76
Figure 70:Diagramme du cas d'utilisation « Etudier demande inscription prestataire »
4.1.1.6. Description de cas d'utilisation « Etudier demande inscription prestataire »

Ce tableau représente le raffinement de sous cas d'utilisation « Etudier demande inscription
prestataire »
Tableau 42: Fiche descriptive du sous cas d'utilisation « Etudier demande inscription prestataire »
Pré-condition(s) - Session ouverte
Post-condition(s) L’administrateur géré demande prestataire
Scénario-Nominal 1. L’administrateur affiche la liste de demande de prestataire
2. L’administrateur clique sur annuler pour supprimer la
demande
3. L’administrateur clique sur accepter pour ajouter un
prestataire
Le système affiche un message d’échec si les paramètres non
Scénario(s)
valides ;
alternatif(s)
Et d’exception :
4.2. Conception des cas d'utilisation de priorité « 3 »

4.2.1. Diagramme de déploiement
Les diagrammes de déploiement modélisent l'architecture physique d'un système. Les
diagrammes de déploiement affichent les relations entre les composants logiciels et matériels
du système, d'une part, et la distribution physique du traitement, d'autre part. Présentent la
disposition physique des nœuds dans un système réparti, les artefacts qui sont stockés sur
chaque nœud et les composants et autres éléments que les artefacts implémentent. Les nœuds
représentent des périphériques matériels tels que des ordinateurs, des détecteurs et des
imprimantes, ainsi que d'autres périphériques qui prennent en charge l'environnement
77
d'exécution d'un système. Les chemins de communication et les relations de déploiement

modélisent les connexions dans le système
Figure 71:Diagramme de déploiement
Le diagramme ci-dessus représente L’architecture utilisée (3-tiers) et spécifie les composants

physiques nécessaires pour le site web.
• Tier 1 : Il s’agit des postes administrateur, prestataire et client
• Tier 2 : Le serveur de base de données : Il permet de fournir les données au serveur web.
• Tiers : Un serveur d’application qui permet la communication entre les postes et le serveur
de base de données.
4.2.2. Diagramme de séquence
4.2.2.1. Diagramme de séquence de cas d’utilisation « supprimer client »
Nous allons exposer dans la figure ci-dessous le diagramme de séquence « supprimer client »
qui permet à l’administrateur de supprimer un client
78
Figure 72:Diagramme de séquence "supprimer client"
4.2.2.2. Diagramme de séquence « supprimer prestataire »

Nous allons exposer dans la figure ci-dessous le diagramme de séquence « gérer membres » qui
perme t à l’administrateur de supprimer un prestataire.
79
Figure 73:Diagramme de séquence « supprimer prestataire »
4.3. Diagramme de collaboration

4.3.1. Diagramme de collaboration de sous cas d'utilisation « supprimer client »
Cette figure illustre le diagramme de collaboration de sous cas d'utilisation « supprimer client »
80
Figure 74 : Diagramme de collaboration « supprimer client »
4.3.2. Diagramme de collaboration de sous cas d’utilisation « supprimer prestataire »

Cette figure illustre le diagramme de collaboration de sous cas d'utilisation « supprimer
prestataire »
Figure 75:Diagramme de collaboration « supprimer prestataire »
4.4. Diagramme de classes

Cette figure représente un modèle de diagramme de classes que nous avons conçu lors du
troisième Sprint.
81
Figure 76:Diagramme de classe de sprint 3
4.5. Modèle relationnel

—Client (id_client, login, Password, nom, prenom, email, adresse, téléphone, photo, sexe,
ville)
—Commande (ref_cmd, etat_cmd, date_cmd, # id_client)
—Commentaire (id, email, texte, date, #id_produit)
—Facture (id, total, date, #id_client, #ref_cmd)
—Favoris (id, #id_client, #id_produit)
—Ligne_commande (#ref_cmd, #id_produit, quantité)
—Location (id, date, heure, acompte, reste, #id_client, #id_produit)
—Photos_produit (reference, Image_path, color)
82
—Prestataire (id_prestataire, nom, prenom, email, adresse, téléphone, photo, sexe, état,
Password, #type)
—Produit (id_produit, catégorie, désignation, description, prix, quantité, état, Image_path,
#id_prestataire)
—Promotion (id, titre, #id_produit, solde, prix, date_début, date_fin)
—Réclamation (id, #id_client, #id_prestataire, date, objet, message, réponse)
—Type (id_type, nom_type)
—Catégories_produit (id, description)
4.6. Implémentation des cas d'utilisation prioritaires

4.6.1. Interface s’authentifier administrateur
A travers cette interface l’administrateur doit s’authentifier via son login et son mot de passe.
Si l’admin est connecté, l’espace personnel est affichée. Si le Login et le mot de passe sont
incorrects, un message d’erreur sera affiché.
Figure 77:Interface s’authentifier administrateur
4.6.2. Interface supprimer client

A travers cette interface l’administrateur peut accepter ou refuser la demande de l’inscription
de prestataire.
83
Figure 78:interface étudier demande prestataire
4.6.3. Interface supprimer client

A travers cette interface, l’administrateur peut supprimer un prestataire avec un simple clic sur
le bouton supprimer comme l’indique la figure ci-dessous
Figure 79:interface supprimer client
4.7. Test
Le tableau ci-dessous présente un ensemble de cas de tests relatif au sprint 3
84

attendu
Test de suppression Sélectionner un client Client supprimer Conforme
un client puis cliquer sur avec succès
supprimer
Test d’Etudier Afficher liste de Demande accepter Conforme

demande inscription demande d’inscription
prestataire de prestataire Demande refuser
(accepter/refus)
Test de supprimer un Sélectionner un Prestataire Conforme

prestataire prestataire puis cliquer supprimé avec
sur le bouton succès
supprimer
85
Conclusion et perspectives
Ce rapport est le fruit d'un travail réalisé dans le cadre de mémoire mastère. Nous avons pu
mettre en pratique nos connaissances théoriques acquises durant notre formation, pour
concevoir et développer une plate-forme.
Pour accomplir ce travail, nous avons adopté la méthode Scrum comme méthode
développement, l'UML comme langage de modélisation. Notre application est développée en
langage PHP. Ainsi, afin de créer la base de données, nous avons exploité le système de gestion
de base de données MySQL.
Nous avons commencé par la présentation du cadre du projet. Par la suite nous avons passé à
la spécification des besoins et l'identification des acteurs afin de garantir une conception fiable.
Ceci a fait l'objet de l'étape suivante afin de pouvoir enchainer avec l'implémentation et la
réalisation. Pour ce faire, nous étions amenés à étudier, développer et mettre en place ce site en
respectant une architecture claire et standardisée.
Les perspectives d'évolution d'un tel système sont certes infinies vue le progrès technologique
de plus en plus rapide et l'adaptation aussi rapide des utilisateurs à ses technologies.
De ce fait, l'application développée peut être étendue et améliorée par la possibilité de la
migration vers une distribution mobile pour mettre des services à travers le réseau mobile.
Nous tenons à préciser que ce projet nous a été bénéfique, dont la mesure où il nous a permis
de découvrir un champ d'application à la fois pratique, vaste et riche en procédures. De même
qu'il nous a offert l'occasion d'approfondir les connaissances acquises durant notre formation à
la faculté des sciences juridiques, économiques et de gestion de Jendouba.
74
Bibliographie et Nétographie
Sites Internet
[1] http://www.zifef.com/mariage-tunisie (consulté le 01/01/2019)
[2] http ://www.far7a.com/fr /(consulté le 02/01/2019)
[3] https ://www.blogdumoderateur.com/voyages-sncf-com-en-mode-agile/(consulté le

06/01/2019)
[4] https ://www.marine-guyot.ovh/methode-agile-ou-classique/(consulté le 08/01/2019)
[5]https ://openclassrooms.com/fr/courses/2035826-debutez-lanalyse-logicielle-avec-
uml/2035851-uml-c-est-quoi(consulté le 10/02/2019)
[8] https://laurent-audibert.developpez.com/Cours-UML/ (consulté le 11/02/2019)
[9] https ://www.scrum.org/resources/blog/various-levels-services-3-scrum-roles(consulté le

14/03/2019)
[10] https ://fr.popularhowto.com/your-product-backlog-and-scrum(consulté le 015/03/2019)
[12] http ://www.webcky.fr/blog/2016/09/16/developpement-site-web-avec-larchitecture-

mvc-en-isere/(consulté le 25/04/2019)
[13] https ://www.memoireonline.com/02/17/9661/m_Conception-et-realisation-dun-robot-

virtuel-marketiste11.html(consulté le 30/04/2019)
[14] https ://developer.mozilla.org/fr/docs/Web/Guide/HTML/HTML5 (consulté le

01/05/2019)
[15] https ://www.w3schools.com/css/ (consulté le 01/05/2019)
[16] https ://www.w3schools.com/js/ (consulté le 11/05/2019)
[17] http ://www.informatique.systems/sites/default/files/WAMP/ (consulté le 15/06/2019)
Ouvrages
[6] Pascal Roques, UML2 par la pratique, 5éme édition, ÉDITIONS EYROLLES. Septembre
2001, 359 PDF. (Consultée le 03-02-2019)
74
[7] Pascal Roques. Modéliser une application web, 4ème édition. ÉDITIONS EYROLLES.
Juin 2008, 264. PDF. Disponible sur :
(https://www.academiepro.com/uploads/cours/2015_10_07)
[EYROLLES_UML2_-_Modeliser_une_application_web.pdf). (Consulté le 04/02/2019)
75
Résumé
Ce projet vise à développer une plateforme des agences de fêtes. Mais, pour aboutir à ce
dernier, nous allons tout d’abord effectuer une étude conceptuelle de site. Cette dernière nous
permettra, en effet, d’accéder facilement à la réalisation de plateforme en organisant les idées
et en structurant le processus de codage suivant des diagrammes. La plateforme a été
implémentée par diverses technologies en se basant sur l’étude conceptuelle. Le système de
gestion de base de données choisi fut MySQL.
Mots clés : UML, MySQL, Plateforme,
Abstract
This project aims to develop a platform of holiday agencies. But, to arrive at the latter, we will
first make a conceptual site study. The latter will allow us, in fact, easy access to the realization
of platform by organizing the ideas and structuring the process of coding according to
diagrams. The platform has been implemented by various technologies based on the concept
study. The database management system chosen was MySQL.
Keywords : Platform
Faculté des sciences juridiques, économiques et de gestion,

Jendouba
76

Mémoire M2ecom Amani

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

Mémoire M2ecom Amani

Transféré par

Droits d'auteur :

Formats disponibles

RÉPUBLIQUE TUNISIENNE

Ministère de l'Enseignement Supérieurs et de La Recherche Scientifique

Faculté des Sciences Juridiques, Economiques et de Gestion De Jendouba

Mastère professionnel en commerce électronique

Conception et réalisation d’une

Mr. Khemiri Nabil

Année universitaire : 2018/2019

Qui m’ont soutenu

De près ou de loin tout au long de ce projet

A tous mes amis

Qui m’a aidé à franchir un horizon dans ma vie…

A tous ceux qui m'ont soutenu et qui me soutient encore ...

On remercie dieu le tout puissant de nous avoir donné la santé et la volonté

J'adresse mes remerciements à mon professeur, Mr Nabil Khemiri de la Faculté

HTML HyperText Markup Language

CSS Cascading Style Sheets

UML Unified Modeling Language

MVC Modèle Vue Contrôleur

IHM Les interactions homme-machine

PHP Personal Home Page.

WYSIWYG What you see is what you get

OOSE Object Oriented Software Engineering

De ce fait, le commerce classique ne répond plus aux besoins des clients.

Internet permet d’établir un dialogue continu avec le consommateur et cela de façon

Présentation du cadre de Projet

’expression commerce électronique fait référence au processus d’achat et de vente de

1.1. Vue générale sur le commerce électronique

Les principaux objectifs pour s’intégrer dans le commerce électronique sont :

− Améliorer la compétitivité des entreprises ;

1.1.3.1. Les avantages de vente en ligne

− La vitesse : De plus en plus, les délais se compriment entre le moment où le besoin se

1.1.3.2. Les inconvénients de vente en ligne

− Gare aux frontières :

− Le commerce électronique victime de son succès :

− La vente en VAD pour le B to B, tous systèmes confondus :

1.2. Présentation du projet

1.2.1. Étude de l’existant

L’organisation du travail et le problème de distance sont très importants, mais malheureusement

1.2.1.2. Présentation du site « zifef.com »

1.2.1.3. Analyse fonctionnelle de site « zifef.com »

—Chercher des traiteurs ;

—Contacter des traiteurs ;

—Réserver salle de fête ;

—Acheter des produits ;

1.2.1.4. Analyse technique du site « zifef.com »

Le bleu pétrole, le blanc -le blanc, couleur de barre de menus.

Voici l’imprimes d’écran de site zifef.com :

Figure 2:Interface d’accueil du site « zifef.com » [1]

1.2.1.5. Présentation du site « far7a.com »

1.2.1.6. Analyse fonctionnelle du site « far7a.com »

La liste du menu La disposition horizontale en haut de la page, rend la navigation vers

Voici l’imprime d’écran de site Far7a.com :

Figure 3:Interface d’accueil du site "far7a.com » [2]

1.2.2. Critique de l'existant

1.2.3. Solution proposée

− Le client peut choisir le type de fête et toutes ses composantes facilement.

1.2.4. Choix du modèle de développement

du projet. Le risque d'échec se comprend aisément. En effet, quelle entreprise a un périmètre

Figure 4:Modèle de développement agile [3]

Éléments du projet Méthodes classiques Méthodes agiles

Cycle de vie Phases séquentielles rendant les Développement itératif et

Cette figure représente un schéma explicatif de la méthode Agile, ou plus particulièrement de

Figure 5 : Schéma de Méthode classique et méthode Agile [4]