Version Final MM

DÉDICACES
“ À mes parents Lotfi et Monia,

Vous avez toujours privilégié la persévérance et l’excellence dans
nos études. Vous nous avez comblés d’amour. Que ce travail soit
la récompense de vos efforts et sacrifices.
À mon frère Mohamed,

Votre amour et votre attention m’ont toujours été d’un réel
réconfort moral et sentimental. Santé, bonheur et réussite, tels
sont mes vœux pour vous.
À mon amie et ma binôme Mariem,

Que cette collaboration soit l’épreuve de ma reconnaissance et
ma sincère amitié.Je te souhaite une excellente carrière pleine de
réussite.
”
- Malek Ben Rabah
i
DÉDICACES
“ À mes parents Salem et Monia,

Vous avez toujours privilégié la persévérance et l’excellence dans
nos études. Vous nous avez comblés d’amour. Que ce travail soit
la récompense de vos efforts et sacrifices.
À mes sœurs Sarah et Salma,

Votre amour et votre attention m’ont toujours été d’un réel
réconfort moral et sentimental. Santé, bonheur et réussite, tels
sont mes vœux pour vous.
À mon amie et ma binôme Malek,

Que cette collaboration soit l’épreuve de ma reconnaissance et
ma sincère amitié.Je te souhaite une excellente carrière pleine de
réussite.
”
- Mariem Essghaier
ii
REMERCIEMENTS
Nous adressons dans un premier temps nos sincères remerciements et notre profond respect à
notre encadrant Moez Ben Rkaya de l’Institut Supérieur de l’Informatique pour la qualité de
son encadrement. Veuillez trouver dans ce travail notre profond respect et notre infinie gratitude.
Nous tenons à remercier et à témoigner toute notre reconnaissance également à notre encadrant
de la société de nutrition animale (SNA) Yassine Dammak, Responsable développement infor-
matique industrielle/Automatisme et digitalisation, pour l’expérience enrichissante que nous
avons vécu durant notre stage et pour sa bienfaisance continue.
Nous adressons aussi un remerciement à toute l’équipe de la société SNA pour leur accueil cha-
leureux et leur coopération professionnelle.
Nos remerciements et notre gratitude s’adressent, également, au membre du jury qui a accepté
de siéger parmi le jury de notre travail. Qu’il nous soit permis ici de vous exprimer notre cordiale
gratitude et notre haute considération.
Finalement, nous remercions tous ceux qui ont contribué, de près ou de loin, à l’élaboration
de ce travail.
iii
TABLE DES MATIÈRES
Introduction générale 1
1 Étude préalable 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Cadre et contexte du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Cadre du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 eCommerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Analyse concurrentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Etude des solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2 Bilan et synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6.1 Méthodologies de développement de logiciel . . . . . . . . . . . . . . . . 12
1.6.2 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 Planification et capture des besoins 19

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
iv
TABLE DES MATIÈRES
2.1.2 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.3 Contraintes de conception . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.4 Identification des acteurs et des cas d’utilisation . . . . . . . . . . . . . . 22
2.1.4.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . 22
2.1.4.2 Identification des cas d’utilisation . . . . . . . . . . . . . . . . . 23
2.1.5 Model de cas d’utilisation structurée en package . . . . . . . . . . . . . . 24
2.1.6 Élaboration des prototypes des interfaces utilisateurs . . . . . . . . . . . 25
2.2 Pilotage du projet avec scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Équipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.2 Backlog Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3 Plan de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Sprint0 31
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4 Étude et réalisation du release 39

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 Sprint1- Cas d’utilisation du webmaster . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Backlog du Sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2.1 Diagramme de cas d’utilisation du sprint1 . . . . . . . . . . . . 42
4.1.2.2 Raffinement des cas d’utilisation du sprint1 . . . . . . . . . . . 42
4.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.3.1 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . 46
4.1.3.2 Diagrammes d’états-transitions . . . . . . . . . . . . . . . . . . 49
4.1.3.3 Diagramme de classes du sprint1 . . . . . . . . . . . . . . . . . 50
v
TABLE DES MATIÈRES
4.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.5 Mêlée quotidienne du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.6 Rétrospective de sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Sprint2- Cas d’utilisation du Technico-commercial . . . . . . . . . . . . . . . . . 57
4.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.6 Rétrospective de Sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3 Sprint3- Cas d’utilisation des clients . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Annexes 88
Conclusion générale 93
Références bibliographiques 96
vi
TABLE DES FIGURES
1.1 Logo SNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 La céréalerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Alliance-Elevage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Modèle de cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Structuration en packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Structuration en packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Connexion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Tableau de bord utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Recherche et découverte de produits . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Gestion de panier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7 Gestion de la clientèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8 Gestion de profil webmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9 Plan de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Balsamiq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Pacestar UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Visual Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Architecture mvc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
vii
TABLE DES FIGURES
3.7 Diagramme de déploiement de l’architecture 3 tiers . . . . . . . . . . . . . . . . 36

3.8 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.10 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.11 jQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.12 Laravel 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.13 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Diagramme de cas d’utilisation du sprint1 . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Raffinement du cas d’utilisation - S’authentifier . . . . . . . . . . . . . . . . . . . 42
4.3 Raffinement du cas d’utilisation - Maintenir catalogue . . . . . . . . . . . . . . . 43
4.4 Diagramme de séquences du cas d’utilisation - S’authentifier . . . . . . . . . . . 47
4.5 Diagramme de séquences du cas d’utilisation - Ajouter un article . . . . . . . . . 47
4.6 Diagramme de séquences du cas d’utilisation - Chercher un article . . . . . . . . 48
4.7 Diagramme de séquences du cas d’utilisation - Supprimer un article . . . . . . . 49
4.8 Diagramme d’états-transitions - Chercher un technico-commercial . . . . . . . 50
4.9 Diagramme d’états-transitions - Ajouter un article . . . . . . . . . . . . . . . . . 50
4.10 Diagramme de classe du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.11 Authentification webmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.12 Tableau de bord Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.13 Gestion des technico-commerciaux . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.14 Suivi des commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.15 Ajouter un produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.16 Message de succès d’ajout de produit . . . . . . . . . . . . . . . . . . . . . . . . 54
4.17 Suivi des réclamations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.18 Mêlée quotidienne du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.19 Rétrospective de sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.21 Raffinement du cas d’utilisation - Consulter les articles . . . . . . . . . . . . . . . 58
4.22 Raffinement du cas d’utilisation - Gérer les clients . . . . . . . . . . . . . . . . . 58
4.23 Diagramme de séquences du cas d’utilisation - Consulter les articles . . . . . . . 61
4.24 Diagramme de séquences du cas d’utilisation - Ajouter un client . . . . . . . . . 62
4.25 Diagramme de séquences du cas d’utilisation - Chercher un client . . . . . . . . 63
viii
TABLE DES FIGURES
4.26 Diagramme de séquences du cas d’utilisation - Supprimer un client . . . . . . . 63

4.27 Diagramme d’états-transitions - Chercher un client . . . . . . . . . . . . . . . . 64
4.28 Diagramme d’états-transitions - Supprimer un client . . . . . . . . . . . . . . . . 64
4.29 Diagramme de classes du sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.30 Gestion du compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.31 Gestion des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.32 Consulter les détails du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.33 Suivi des commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.34 Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.35 Ajouter un sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.36 Soumettre un commentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.37 Message de succès d’ajout d’une réponse . . . . . . . . . . . . . . . . . . . . . . 70
4.38 Supprimer une réponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.40 Rétrospective de Sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.42 Raffinement du cas d’utilisation «Créer un compte client» . . . . . . . . . . . . . 73
4.43 Raffinement du cas d’utilisation - Gérer son panier . . . . . . . . . . . . . . . . . 74
4.44 Raffinement du cas d’utilisation - Effectuer une commande . . . . . . . . . . . . 75
4.45 Raffinement du cas d’utilisation - Calculer la ration alimentaire . . . . . . . . . . 76
4.46 Diagramme de séquences du cas d’utilisation - Créer un compte client . . . . . . 77
4.47 Diagramme de séquences du cas d’utilisation - Gérer son panier . . . . . . . . . 78
4.48 Diagramme de séquences du cas d’utilisation - Effectuer une commande . . . . 79
4.49 Diagramme de séquences du cas d’utilisation - Calculer ration alimentaire . . . . 80
4.50 Diagramme d’états-transitions global de la navigation de client . . . . . . . . . . 80
4.51 Diagramme de classes du sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.52 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.53 Inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.54 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.55 Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.56 Recherche et sélection des produits . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.57 Gestion de panier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
ix
TABLE DES FIGURES
4.58 Effectuer une commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.60 Rétrospective de Sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
x
LISTE DES TABLEAUX
1.1 Avantages et risques de la solution Céréalerie . . . . . . . . . . . . . . . . . . . . 8

1.2 Avantages et risques de la solution Alliance-Elevage . . . . . . . . . . . . . . . . 9
1.3 Comparatif autour des solutions concurrentes . . . . . . . . . . . . . . . . . . . 9
1.4 Avantages et inconvénients de la méthode méthode Scrum . . . . . . . . . . . . 15
2.1 Équipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2 Backlog Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Matériels utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1 Backlog du Sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 S’authentifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Ajouter un article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Chercher un article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Supprimer un article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Sprint2 backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7 Consulter les articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.8 Ajouter un client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.9 Chercher un client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.10 Supprimer un client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.11 Backlog du Sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.12 Créer un compte client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
xi
LISTE DES TABLEAUX
4.13 Gérer son panier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.14 Effectuer une commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.15 Calculer la ration alimentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.16 Table Webmaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.17 Table Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.18 Table Newsletter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.19 Table Avis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.20 Table Réclamation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.21 Table Article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.22 Table Catégorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.23 Table Commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.24 Table UsersCommande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.25 Table ArticleCommande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.26 Table Panier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.27 Table lignePanier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
xii
ACRONYMES
CMV Composés Minéreaux Vitaminés. 5
CSS Feuilles de style en cascade. 36
CU Cas d’Utilisation. 45
HTML Hypertext Markup Language. 36
IHM Interface Homme Machine. 33
MVC Modèle Vue Contrôleur. 34
PHP PHP Hypertext Preprocessor. 37
SGBDR Systèmes de Gestion de Base de Données Relationnels. 38
SN Scénario Nominal. 43
SNA Société de Nutrition Animale. 4, 10
UML Langage de Modélisation Unifié. 11, 16, 24
VS Visual Studio. 32
xiii
INTRODUCTION GÉNÉRALE
“
Traditionnellement, ce qui sépare les entreprises moyennes d’une
grande fut la technologie. Nous sommes au milieu de la
transformation. Aujourd’hui, ce qui différencie une entreprise
moyenne d’une grande c’est le talent !”
”
Wades Burgress
E développement technologique a entraîné de différentes mutations dans l’environnement
L économique des entreprises. De plus, le eCommerce demeure en développement dans les
divers secteurs économiques. En effet, durant les années récentes, le « marché virtuel » a émergé
comme une nouvelle procédure. De nombreux avantages ont été associés à l’utilisation de com-
merce électronique aussi bien pour les entreprises que pour les clients. Le eCommerce offre la
mise à la disposition d’une vaste clientèle illimitée géographiquement pour les entreprises ; ren-
forçant la concurrence inter-entreprises et participant ainsi à l’accélération de la globalisation
des marchés. Concernant les clients, ils ont l’opportunité d’avoir l’embarras du choix des diffé-
rents produits en consultant leurs caractéristiques et en comparant leurs prix correspondants.
De surcroît, ils ont la possibilité d’avoir toujours accès à la plateforme (24h/24h), sans être obligé
de se déplacer évitant ainsi les files d’attente.
1
INTRODUCTION GÉNÉRALE
Dans le cadre de notre Licence Fondamentale en Science de l’Informatique à l’Institut Supé-

rieur de l’Informatique, la société de nutrition animale (SNA) nous a confié de mettre en place
une plateforme eCommerce. C’est pour cela, nous avons mené un projet dans le département
informatique de la SNA sur une période de trois mois allant de Février 2021 à Juin 2021.
L’objectif principal de notre travail était d’exposer à notre clientèle les différents aliments dispo-
nibles en ligne, de faciliter le processus de l’achat et de les mieux guider à assurer une meilleur
alimentation pour leurs ruminants.
Le présent rapport se focalise sur la description des différentes phases de la réalisation de notre
projet. Il est structuré selon quatre chapitres.
Le premier chapitre intitulé «Etude préalable» comporte la description de l’organisme d’accueil

et du projet, avec une étude des problématiques et des solutions proposées. Nous présenterons
aussi la méthodologie de travail adoptée pour la gestion du projet.
Le deuxième chapitre intitulé «Planification et capture des besoins» décrit l’identification des
besoins fonctionnels et non fonctionnels, la méthodologie Scrum adoptée et le «Backlog Scrum».
Finalement, nous aborderons la planification des sprints.
Le troisième chapitre intitulé «Sprint0» détermine la vue architecturale et conceptuelle globale

de notre application. Nous énumérerons ainsi les outils et les technologies utilisés pour le déve-
loppement.
Le quatrième chapitre intitulé «Etude et réalisation du release» comprend les sprint1, sprint2 et
sprint3. Ces derniers sont consacrés au développement des différents modules de notre système
en respectant les principes fondamentaux du Scrum. Pour chaque sprint, nous commencerons
par définir son «Backlog Scrum» qui décrit les tâches à réaliser. Nous présenterons ensuite les
diagrammes de séquence et le diagramme de classe correspondant. En définitive, l’exécution de
notre application a été modélisée par des captures écrans.
Finalement, nous terminerons par une conclusion générale qui résume l’ensemble des connais-
sances acquises et évoque les perspectives qui peuvent étendre notre projet.
2
CHAPITRE 1
ÉTUDE PRÉALABLE
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Cadre et contexte du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Cadre du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 eCommerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Analyse concurrentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Etude des solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2 Bilan et synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6.1 Méthodologies de développement de logiciel . . . . . . . . . . . . . . . . 12
1.6.2 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3
CHAPITRE 1. ÉTUDE PRÉALABLE
Introduction
Ce chapitre introductif est la pierre angulaire pour la compréhension de notre sujet. Nous com-
mençons tout d’abord par présenter le contexte et le cadre général du sujet.
Ensuite, nous élaborons une analyse concurrentielle présentant les différentes solutions eCom-
merce existantes sur le marché : le but est de cibler les insuffisances et de combler les carences.
En définitive, nous consacrons la dernière partie de ce chapitre à la définition de la méthodologie
préconisée pour la réalisation de ce travail.
1.1 Cadre et contexte du sujet
1.1.1 Cadre du sujet
Ce présent travail s’inscrit dans le cadre d’un sujet de fin d’études en vue de l’obtention du
diplôme de Licence Fondamentale en Science de l’Informatique au sein de l’Institut Supérieur
d’Informatique.
Durant un stage de trois mois au sein de la Société de Nutrition Animale (SNA), notre mission
s’est rapportée essentiellement à la conception et la réalisation d’une plateforme eCommerce
répondant aux besoins de ladite société.
1.1.2 Présentation du sujet
Il est indispensable pour une entreprise telle que SNA de se doter d’une plateforme eCom-
merce de qualité pour fidéliser ses clients et surtout en attirer de nouvelle clientèle pour ac-
croître son chiffre d’affaires.
Une plateforme eCommerce, nous permet donc d’ouvrir d’autres horizons et s’orienter vers
les marchés extérieurs et internationaux.
De plus, une plateforme eCommerce facilite les achats en ligne et séduit la clientèle par les
produits et les qualités de services sans qu’ils aient besoin de se déplacer.
En outre, une plateforme eCommerce apporte des données sur le comportement des clients,
ce qui favorise l’optimisation des fonctionnalités de notre plateforme pour mieux les satisfaire.
De surcroît, un calcul correcte des quantités d’aliments à distribuer à un animal permet aux
éleveurs d’alimenter correctement leurs ruminants et d’assurer au mieux la couverture de ses
4
besoins nutritionnels. C’est pour cela la mise en place d’une assistance numérique rapide et
simplifiée est un besoin fondamental.
1.2 Organisme d’accueil

La Société de Nutrition Animale SNA présente sur le marché des aliments des animaux depuis
1976, elle est la propriété de Poulina Group Holding, premier groupe avicole du Maghreb [1].
FIGURE 1.1 – Logo SNA
SNA assure un élevage gagnant, ses principales activités sont :
j Proposer une gamme complète d’aliments composés destinés à tous les animaux d’élevage
notamment les volailles, les ruminants et les lapins ;
j Proposer une gamme complète des Composés Minéreaux Vitaminés (CMV), destinée aux
industriels d’aliments ;
j Offrir une assistance et un suivi dans sa gamme de CMV.
1.3 eCommerce
La plupart des commerçants ou futurs entrepreneurs prévoient de démarrer ou d’étendre leur
activité en ligne. C’est une industrie à croissance rapide. Par rapport au commerce traditionnel,
le eCommerce a complètement changé les règles du jeu.
Posséder une plateforme sur laquelle il est faisable de vendre ses produits est une véritable
chance pour chaque entreprise. Par conséquent, la mise en place d’une telle plateforme est équi-
valente à une réussite garantie. Les avantages sont multiples [2], à citer :
j Pour les entreprises :
k Mise à la disposition d’une vaste clientèle illimitée géographiquement ;
k Exposer ses produits de manière distincte ;
5
k Acquérir de différentes données sur ses clients, ce qui permettra de mettre en place
des actions de marketing direct ;
k Se développer sur de nombreux marchés ;
k Assurer l’interactivité entre l’entreprise et ses clients (sons, images,vidéos,etc).
j Pour les internautes :
k Faciliter les achats, sans être obligé de se déplacer évitant ainsi les files d’attente ;
k Gagner du temps ;
k Chercher le meilleur prix ;
k Accéder au magasin de n’importe où dans le monde, 24h/24 et 7j/7 ;
k Comparer directement les prix des articles ;
k Passer sa commande à tout moment de la journée ;
k Accomplir un marquage avant d’acheter en magasin.
Les limites de cette solution sont [3] :
j Pour les entreprises :
k Interactions limitées avec les clients. En effet, sans être face à face, il peut être plus
difficile de comprendre les désirs et les besoins des clients ;
k Les pannes technologiques peuvent avoir une incidence sur la capacité de vente ;
k Problèmes de connexion Internet.
j Pour les internautes :
k Aucune possibilité de test ou d’essai ;
k Le manque de relations humaines dans les transactions peut manquer aux clients ;
k La possibilité de tomber sur un site malveillant est envisageable ;
k La difficulté de faire appel au service après-vente en cas de problème ;
k Les délais de livraison, ainsi que les tarifs associés peuvent parfois être relativement
conséquents ;
k Ce genre de site enregistre l’ensemble des actions de l’internaute, ce qui permet de

suivre les habitudes de consommation des clients.
6
1.4 Analyse concurrentielle
1.4.1 Etude des solutions existantes
De nos jours, la concurrence tend à s’accroître et les différentes entreprises confrontées à ce

défi essaient de le surmonter en suivant une démarche d’analyse concurrentielle. Durant cette
partie d’étude des solutions existantes on présente une analyse des sites et des applications que
l’on considère concurrents ou comparables, afin d’en extraire les points positifs et / ou négatifs.
Parmi les solutions existantes sur le marché nous citons :
La céréalerie
La Céréalière, propose la vente directe et en ligne de céréales et fourrages produits à la ferme,
destinés à l’alimentation animale.
FIGURE 1.2 – La céréalerie
La Céréalerie vend les produits issus de l’exploitation familiale : céréales et mélanges pour
l’alimentation animale, fourrages, litières.
La céréalerie dispose ainsi un concept du libre-service qui s’adapte aux besoins des clients.
De plus, un agriculteur est disponible pour l’accueil et pour fournir des conseils.
7
TABLE 1.1 – Avantages et risques de la solution Céréalerie
Avantages Risques
ÜUne vaste gamme de céréales et fourrages ÜPas de catégorisation du catalogue produit.

pour les animaux.
ÜUne variété de mode de paiement. ÜPas d’avis utilisateur sur les pages produits.
ÜNombreux modes de livraison. ÜManque de communication interne justifié

par l’absence de forum.
Alliance-Elevage
Le Groupe Alliance offre la vente en ligne des fourrages pour les différents ruminants (ovins, ca-
prins, bovins, etc)
FIGURE 1.3 – Alliance-Elevage
Le groupe Alliance présente différent type de produits catégorisés. Ovins, caprins, bovins,
équins ou cervidés, le Groupe Alliance s’est peu à peu diversifié pour répondre aux demandes du
8
terrain. De plus, il apporte un soutien technique par téléphone et un approvisionnement à ses

adhérents.
TABLE 1.2 – Avantages et risques de la solution Alliance-Elevage
Avantages Risques
ÜFonctionnalité de recherche permettant ÜAbsence d’information concernant l’actua-

aux utilisateurs de trouver les produits. lité de l’entreprise.
ÜDescriptif complet des produits et photos ÜAbsence de retour des utilisateurs.

de qualité.
ÜPrésente un catalogue produit très impor- ÜInterfaces non ergonomiques.

tant.
ÜPas de risques flagrants à mentionner. ÜAbsence d’un espace consacré aux discus-
sions et aux interventions sur des sujets.
1.4.2 Bilan et synthèse
Comme le montre le tableau 1.3, un récapitulatif autour des solutions concurrentes est pré-
senté. La comparaison se base sur des critères clés (modules) pour bien aider à implémenter
notre future solution.
Nous marquons respectivement les puces 3-Satisfait et 5-Insatisfait.
TABLE 1.3 – Comparatif autour des solutions concurrentes
Fonctionnalités Céréalière Alliance-Elevage
Inscription Newsletter 5 3
Recherche de produits 5 3
Avis et commentaires 5 5
Actualités 3 5
Forum de discussion 5 5
Ergonomie 3 5
Gestion de la clientèle 5 5
– Page suivante
9
TABLE 1.3 – Comparatif autour des solutions concurrentes
Fonctionnalités Céréalière Alliance-Elevage

Gestion des produits 3 3
Gestion des paniers 3 3
Gestion des commandes 5 5
Suivi des commandes 5 3
Suite à cette synthèse, nous remarquons que les deux solutions présentent des lacunes au
niveau de la gestion de la clientèle et des commandes. En outre, l’aspect ergonomique reste in-
satisfaisant.
Nous allons remédier à ces insuffisances à travers la projection d’une nouvelle solution.
1.5 Solution proposée

Nous envisageons la réalisation d’une plateforme eCommerce au profil de la société SNA,
caractérisée par la simplicité et la facilité.
La plateforme regroupe une gamme de fonctionnalités côté «Back-End» et «Front-End».
«Front-End»
Lorsque l’on parle de «Front-End», il s’agit finalement des éléments de la plateforme que nous
voyons à l’écran et avec lesquels nous pouvons interagir. Ces éléments sont composés de HTML5,
CSS3 et de JQuery, contrôlés par le navigateur web de l’utilisateur.
Nous proposons une panoplie de fonctionnalités pour le côté de développement «Front-End»,
à savoir :
j Un module pour les inscriptions des internautes ;
j Un module pour la gestion des accès ;
j Un tableau de bord personnalisé aux profils des clients afin de profiter des multiples fonc-
tionnalités de la plateforme ;
j Un module pour la recherche et la consultation des produits ;
j Un module pour la gestion de panier ;
j Un module pour le passage des commandes ;
j Un module pour le calcul des rations alimentaires ;
10
j Un module pour le passage des réclamations ;
j Un forum de discussion ;
j Un module pour l’inscription aux newsletter ;
j Un module pour la publication des avis sur les produits.
«Back-End»
Le «Back-End», c’est la partie invisible pour les internautes mais représente une grande partie
du développement d’un projet web. Sans elle, la plateforme reste une coquille vide.
On peut décomposer le «Back-End» en trois parties essentielles :
j Un serveur Apache (ou hébergement web) ;
j Une application (en l’occurrence la plateforme) ;
j Une base de données Mysql (où nous stockons les données).
Le serveur est comme un disque dur virtuel accessible 24 heures sur 24 (via l’adresse 127.0.0.1),
sur lequel les pages de la plateforme sont enregistrées.
Pour pouvoir conserver les mots de passe, les articles, les commandes, les avis clients, il est
nécessaire de les enregistrer dans une base de données MySQL.
Les fonctionnalités proposées pour le développement de la partie «Back-End» sont citées comme
suit :
j Un module pour la gestion des accès ;
j Un module pour la gestion des produits, ainsi que leurs catalogues ;
j Un module pour la gestion des nouveautés ;
j Un module pour la gestion de la clientèle ;
j Un module pour la gestion des paniers et des commandes ;
j Un module pour la gestion du suivi des commandes effectuées par les clients ;
j Un module pour la gestion des réclamations, des avis clients et des newsletters ;
j Un module pour le maintien de la plateforme.
1.6 Gestion du projet

Dans cette section, nous présentons les méthodologies de développement de logiciel « Cycle
en V » et « Scrum », puis le langage de modélisation Langage de Modélisation Unifié (UML).
11
1.6.1 Méthodologies de développement de logiciel
La méthode « Cycle en V »
Le cycle en V est un modèle de gestion de projet qui implique toutes les étapes du cycle de vie
d’un projet : conception, réalisation et validation.
Cette méthode comporte une phase descendante, puis une phase ascendante, illustrées par les
deux branches du V. La méthode du cycle en V repose sur des étapes séquentielles et linéaires,
allant de l’analyse des besoins au test d’acceptation [4].
FIGURE 1.4 – Modèle de cycle en V
La partie descendante du «V» correspond aux quatre actions de conception et de développe-

ment du système, tandis que la partie ascendante reprend les quatre phases d’assurance qualité
qui lui sont associées. Le point de jonction, le bas du V, correspond quant à elle à l’étape de réa-
lisation. Les neuf étapes peuvent être regroupées en trois phases :
j La conception (la partie descendante) :
k L’expression des besoins et l’étude de faisabilité ;
k La définition des spécifications et du cahier des charges fonctionnel ;
k La conception générale/architecturale ;
k La conception détaillée.
j La mise en œuvre (codage)
j La validation (la partie ascendante) :
k Les tests unitaires, pour chaque composant ou fonctionnalité ;
12
k Les tests d’intégration, sur le produit final ;
k La validation, c’est-à-dire la conformité fonctionnelle du produit ou du logiciel par

rapport aux spécifications communiquées par le client ;
k La recette ou le test d’acceptation par le client (validation de la conformité face à l’ex-

pression des besoins).
Avantages et inconvénients de la méthode cycle en V
j Les avantages [5] :
k L’intégralité du projet est définie et planifiée dès le départ, et par conséquent que le
budget global est connu ;
k Met en face de chaque étape de réflexion une étape de test et de validation ;
k Permet d’arriver à un enchaînement des tâches assez naturel et en principe à un li-

vrable de bonne qualité ;
k Il suffit de tenir quelques réunions régulières pour la gestion de projet et le suivi bud-
gétaire.
Cette méthode a pour avantages les points forts cités précédemment bien qu’il existe aussi plu-
sieurs inconvénients.
j Les inconvénients [6] :
k Méthodologie rigide : en cas de mauvaise maîtrise du périmètre, elle sera inadaptée

car toute dérive reviendrait à effectuer de nouvelles phases de conception ;
k Manque de communication : absence de collaboration entre les différents membres

de l’équipe, dont chacun a un rôle bien défini et s’appuie sur la documentation lors-
qu’il rencontre un problème ;
k Manque de souplesse : la phase suivante ne peut commencer que lorsque la phase

précédente a été conclue. Par conséquent, cela peut conduire à une déviation des
plans, ce qui peut entraîner une augmentation des coûts.
k Péremption du produit : risque que le produit dans sa version finale ne soit pas adapté
aux évolutions apparues au cours de sa conception donc la durée de réalisation du
projet va être importante.
13
La méthode Scrum
Le choix des approches est relativement large, mais nous nous intéresserons à la méthode Agile,
et plus particulièrement à la méthode Scrum.
C’est une méthode itérative incrémentale centrée sur la réalisation d’un produit fonctionnel (plu-
tôt des produits non directement utiles comme par exemple certaines documentation) [7].
Cette méthode est articulée autour de trois acteurs clés :
j Le Product Owner : qui a une vision complète du produit ;
j Le Scrum master : qui assure le bon déroulement du projet et rappelle la méthode ;
j L’équipe Scrum : qui développe le produit.
FIGURE 1.5 – Méthode Scrum
Le Product Owner définit le backlog du produit, c’est-à-dire la liste valorisée des fonctionnalités
cibles du produit. Cette liste a pour vocation d’évoluer, au fur et à mesure que la définition du
produit se construit.
L’équipe Scrum doit définir et prioriser les fonctionnalités auxquelles elle s’attaquera durant
cette itération. L’ensemble de ces tâches est appelé «Backlog Scrum».
Lors du sprint, l’équipe, accompagnée d’un Scrum Master, itère sur les développements et
débute chaque journée par une «mêlée quotidienne» durant laquelle elle rappelle les objectifs
du jour.
À la fin de chaque sprint, le client ainsi que le Product Owner évaluent le produit partielle-
ment livrable afin de le valider ou d’indiquer les modifications à réaliser (elles seront alors ajou-
tées au backlog Scrum).
14
Avantages et inconvénients de la méthode Scrum

Les avantages et les risques de cette méthode sont décrits dans le tableau 1.4 [8].
TABLE 1.4 – Avantages et inconvénients de la méthode méthode Scrum
Avantages Risques
Simplicité des processus. Absence de documentation écrite.
Règles définies clairement.
Entièrement développé et testé pour de

courtes itérations.
Augmentation de productivité.
Chaque équipe a son lot de responsabilité.
Organisation personnelle.
Amélioration de la communication.
Justification du choix de la méthode Scrum

La méthode Scrum est plus adaptée aux projets complexes sur lesquels on n’a pas de visibilité :
elle apporte d’avantage de flexibilité et d’adaptabilité aux évolutions demandées ainsi qu’une
meilleure gestion des risques.
La méthode Scrum permet de mieux cadrer un projet industriel, pour lequel on a une vision
très précise de ce que le client souhaite (besoins, planning détaillé et anticipation des risques).
Par conséquent, Scrum est la méthode qui convient avec notre projet parce qu’elle permet
d’obtenir un produit proche des besoins client en prenant en compte l’évolution de ces besoins
et de maximiser ainsi la valeur du produit livré.
En effet, le choix de Scrum comme une méthodologie de pilotage pour notre projet s’est basé
sur les atouts de ce dernier. Il se résume comme suit :
j Plus de souplesse et de réactivité ;
j Une grande capacité d’adaptation au changement grâce à des itérations courtes ;
j Rassemble les deux cotés théorique et pratique et se rapproche beaucoup de la réalité.
15
1.6.2 Langage de modélisation
Comme n’importe quel type de projet, un projet informatique nécessite une phase d’analyse,
suivi d’une étape de conception.
Dans la phase d’analyse, nous cherchons d’abord à bien comprendre et à décrire de façon
précise les besoins des utilisateurs ou des clients. Que souhaitent-ils faire avec le logiciel ? Quelles
fonctionnalités veulent-ils ? Pour quel usage ? Comment l’action devrait-elle fonctionner ? C’est
ce qu’on appelle «l’analyse des besoins». Après validation de notre compréhension du besoin,
nous imaginons la solution. C’est la partie analyse de la solution.
Dans la phase de conception, nous apportons plus de détails à la solution et nous cherchons à
clarifier des aspects techniques, tels que l’installation des différentes parties logicielles à installer
sur le matériel.
Pour réaliser ces deux phases dans un projet informatique, nous utilisons des méthodes, des
conventions et des notations. UML fait partie des notations les plus utilisées aujourd’hui.
Nous allons dans cette section définir UML et ses outils : les diagrammes. Nous allons voir
ainsi comment ce langage peut contribuer à la phase d’analyse des besoins et du domaine d’un
projet informatique.
Définition
UML, c’est l’acronyme anglais pour «Unified Modeling Language». On le traduit par «Langage de
modélisation unifié». La notation UML est un langage visuel constitué d’un ensemble de sché-
mas, appelés des diagrammes, qui donnent chacun une vision différente du projet à traiter.
UML nous fournit donc des diagrammes pour représenter le logiciel à développer : son fonction-
nement, sa mise en route, les actions susceptibles d’être effectuées par le logiciel, etc [9].
Les différents types de diagrammes
UML est constitué de 13 diagrammes, ils sont tous réalisés à partir du besoin des utilisateurs
et peuvent être regroupés selon les deux aspects suivants :
Ü Les aspects fonctionnels : Qui utilisera le logiciel et pour quoi faire ? Comment les actions
devront-elles se dérouler ? Quelles informations seront utilisées pour cela ?
ÜLes aspects liés à l’architecture : Quels seront les différents composants logiciels à utiliser
(base de données, librairies, interfaces, etc.) ? Sur quel matériel chacun des composants sera ins-
tallé ?
j Les besoins des utilisateurs
k Le diagramme de packages : permet de décomposer le système en catégories ou par-
16
ties plus facilement observables, appelés «packages» [10].
k Le diagramme de cas d’utilisation : représente les fonctionnalités (ou dit cas d’utilisa-
tion) nécessaires aux utilisateurs. Nous pouvons faire un diagramme de cas d’utilisa-
tion pour le logiciel entier ou pour chaque package [11].
j L’aspect fonctionnel du logiciel
k Le diagramme de classes : dans la phase d’analyse, ce diagramme représente les en-

tités (des informations) manipulées par les utilisateurs, dans la phase de conception,
il représente la structure objet d’un développement orienté objet [12].
k Le diagramme d’objets : sert à illustrer les classes complexes en utilisant des exemples
d’instances [13].
k Le diagramme de séquence : permet de décrire les différents scénarios d’utilisation

du système [14].
k Le diagramme d’activité : représente le déroulement des actions, sans utiliser les ob-
jets. En phase d’analyse, il est utilisé pour consolider les spécifications d’un cas d’uti-
lisation [15].
k Le diagramme de collaboration : permet de mettre en évidence les échanges de mes-

sages entre objets. Cela nous aide à voir clair dans les actions qui sont nécessaires pour
produire ces échanges de messages. Et donc de compléter, si besoin, les diagrammes
de séquence et de classes [16].
k Le diagramme d’état-transition : permet de décrire le cycle de vie des objets d’une

classe [17].
k Le diagramme global d’interaction : permet de donner une vue d’ensemble des inter-
actions du système [18].
k Le diagramme de temps : est destiné à l’analyse et la conception de systèmes ayant

des contraintes temps-réel [19].
j L’aspect lié à l’architecture du logiciel
k Le diagramme de composants : décrit tous les composants utiles à l’exécution du sys-

tème (applications, librairies, instances de base de données, exécutables, etc.) [20].
k Le diagramme de structure composite : décrit un objet complexe lors de son exécu-

tion [21].
17
k Le diagramme de déploiement : correspond à la description de l’environnement d’exé-

cution du système (matériel, réseau, etc.) et de la façon dont les composants y sont
installés [22].
Conclusion
Tout au long de ce chapitre, nous avons présenté l’organisme d’accueil et la description du projet
à accomplir. De plus, nous avons effectué une analyse concurrentielle des solutions existantes en
présentant notre perception d’alternatives qui vont atténuer à ses déficiences. Par la suite, nous
avons choisi la méthodologie adoptée par notre système en se basant sur les données de quelques
méthodologies de développement existant dans la conception.
Par la suite nous nous rendons au prochain chapitre qui est dédié à la planification des besoins de
notre système.
18
CHAPITRE 2
PLANIFICATION ET CAPTURE DES

BESOINS
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.3 Contraintes de conception . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.4 Identification des acteurs et des cas d’utilisation . . . . . . . . . . . . . . 22
2.1.5 Model de cas d’utilisation structurée en package . . . . . . . . . . . . . . 24
2.1.6 Élaboration des prototypes des interfaces utilisateurs . . . . . . . . . . . 25
2.2 Pilotage du projet avec scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Équipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.2 Backlog Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3 Plan de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
19
CHAPITRE 2. PLANIFICATION ET CAPTURE DES BESOINS
Introduction
Nous commençons tout d’abord par dresser la liste des exigences fonctionnelles et non fonction-
nelles du système. Nous détaillons par la suite les différentes étapes de la démarche adoptée pour
arriver à la construction du modèle des cas d’utilisation.
Une fois le modèle est prêt, et suite à des négociations avec les différents intervenants du projet (col-
laborateurs, chefs de projets, développeurs et clients) nous planifions les sprints et nous les priori-
sons selon les attentes et les besoins du client.
En définitive, nous exposons le plan de la release présentant les différentes séquences de sprints à
venir en matière de semaine.
2.1 Capture des besoins

La figure 2.1 schématisée ci-dessous, décrit les étapes de la démarche adoptée afin d’aboutir
au modèle de cas d’utilisation.
FIGURE 2.1 – Structuration en packages
2.1.1 Exigences fonctionnelles
Nous définissons à travers cette sous-section les fonctionnalités du système à développer.

La plateforme eCommerce de la société SNA doit regrouper toutes les fonctionnalités néces-
saires de recherche, de découverte détaillée, de sélection et de commande d’articles.
j Recherche : la première étape pour l’internaute consiste à trouver le plus vite possible un
article recherché dans l’ensemble du catalogue.
20
Les résultats de la recherche sont disponibles sur une page particulière et doivent pouvoir
être facilement consultés.
j Découverte : chaque article vendu sur la plateforme est présenté en détail sur sa propre
page qui contient une image de l’article en question, son prix et sa disponibilité.
j Sélection : lorsque l’internaute choisit un article bien défini par ses caractéristiques et son
prix, il peut l’enregistrer dans son panier avec l’avantage de le pouvoir modifier à tout mo-
ment avant de passer la commande.
j Prise de la commande : le client doit pouvoir accéder au formulaire de commande, dans

lequel il saisit ses coordonnées et les informations nécessaires à la livraison. Le client doit
pouvoir ensuite suivre ses commandes récentes.
2.1.2 Exigences non fonctionnelles
À part les exigences fonctionnelles, les exigences non-fonctionnelles sont les besoins qui ca-
ractérisent les propriétés (qualités) désirées du système telles que :
j Exigences de qualité
k Ergonomie sobre et efficace : les applications trop riches et trop complexes n’incitent
pas à l’achat, car ils demandent un effort intellectuel important et non souhaité ;
k Formulaire simple : la présentation d’un formulaire doit être particulièrement sim-

pliste pour ne pas repousser le client ;
k Aide en ligne puissante : l’internaute peut consulter des pages d’aide contextuelle lors-
qu’il en a besoin.
j Exigences de performance :
k La plateforme doit pouvoir gérer un nombre important de comptes clients ;
k La plateforme doit supporter plusieurs connexions simultanées ;
k Aucune recherche ne doit prendre plus de 2 secondes.

j Exigences de sécurité : définir les niveaux d’accès possibles à la plateforme pour les utili-
sateurs de l’application à travers un login et un mot de passe. De même, toute information
confidentielle fournie par les clients via l’Internet doit être cryptée.
j Besoins de déploiement : décrivent la façon dont la plateforme sera livrée à l’utilisateur

final. Tous les logiciels du côté client vont être téléchargés à partir du navigateur, sans que
le poste du client ne soit configuré manuellement.
21
j Besoins matériels : définissent les configurations matérielles minimales nécessaires au

fonctionnement de la plateforme.
j Besoins de disponibilité/fiabilité : le niveau de disponibilité qui doit être explicitement

défini pour les applications (24h/24 , 7j/7).
2.1.3 Contraintes de conception
j Mise à jour des données de référence : les informations relatives aux articles présentés
sur la plateforme proviennent essentiellement de deux sources complémentaires.
La première sert à alimenter la base avec tous les nouveaux articles, la seconde à mettre à
jour les données qui concernent le prix des articles du catalogue.
j Mise à jour depuis les formulaires de la plateforme : les coordonnées des clients ainsi
que les caractéristiques de leurs commandes sont enregistrées dans la base et leur confi-
dentialité est garantie. Les commandes sont enregistrées, puis traitées ultérieurement par
le service clientèle. Le client peut aussi consulter l’historique de toutes ses commandes.
j Panier : le panier du visiteur n’est pas sauvegardé dans la base de données. Sa durée de vie
n’excède pas celle de la visite de l’utilisateur.
2.1.4 Identification des acteurs et des cas d’utilisation
2.1.4.1 Identification des acteurs
Les acteurs figurant dans le système sont :
j Webmaster : rôle des employés qui sont en charge du bon fonctionnement et de la main-
tenance du site web.
j Internaute
Nous distinguons deux profils :
k Visiteur : la personne qui visite la plateforme pour consulter des articles et découvrir
les actualités.
k Client : la personne qui visite la plateforme pour chercher des articles et éventuelle-
ment passer une commande rapide et pratique grâce à une assistance adéquate .
22
j Technico-Commercial : en disposant des connaissances techniques, le technico-commercial

peut suivre son client, il peut éventuellement consulter les articles et passer une com-
mande pour ses clients.
2.1.4.2 Identification des cas d’utilisation
Pour chaque acteur identifié précédemment, il convient de chercher les différentes inten-
tions métier selon lesquelles il manipule le système. Commençons par l’acteur le plus important :
Le client.
Ces cas d’utilisation principaux ont été bien mis en évidence par l’expression de besoins préli-
minaires de la section précédente, à savoir :
j L’authentification ;
j Le passage d’une commande ;
j La consultation des commandes ;
j La gestion du compte personnel ;
j Le passage d’une réclamation ;
j Le calcul d’une ration alimentaire.
Les cas d’utilisation des internautes (En tant que visiteur et client) sont :
j La consultation des articles ;
j La recherche d’un article ;
j Le contact avec les tiers ;
j La gestion d’un panier.
Les cas d’utilisation des Visiteurs sont :
j La création d’un nouveau compte.
Les cas d’utilisation du webmaster sont comme suit :
j La gestion des avis clients ;
j Le maintien du catalogue ;
j Le maintien des informations éditoriales ;
j Le maintien du site ;
23
j La gestion des profils ;
j La consultation des newsletter ;
j La gestion des réclamations ;
j L’authentification ;
j Le suivi des commandes.
Pour le dernier acteur identifié, le technico-commercial, ses cas d’utilisations sont :
j La gestion des clients ;
j La consultation des articles ;
j La recherche d’un article ;
j Le contact avec les tiers ;
j Le suivi des commandes ;
j La création du compte personnel ;
j L’authentification.
2.1.5 Model de cas d’utilisation structurée en package
Pour améliorer le modèle de cas d’utilisation, nous allons organiser les cas et les regrouper
en ensembles fonctionnels cohérents. Pour ce faire, nous utilisons le concept général d’ UML, le
package.
Les acteurs ont également été regroupés dans un package séparé sur lequel s’appuient les
trois packages de cas d’utilisation. L’organisation générale du modèle dans un outil de modéli-
sation est représentée comme le montre la figure2.2.
Le sigle UC est souvent utilisé pour raccourcir les noms de packages. Dans notre cas nous pro-
posons le découpage suivant :
24
FIGURE 2.2 – Structuration en packages
2.1.6 Élaboration des prototypes des interfaces utilisateurs
La réalisation des maquettes est une étape déterminante dans la création d’une plateforme.
Pour que la plateforme soit agréable, il faut naturellement soigner le design de l’interface
graphique, mais surtout, pour que la plateforme soit efficace, il faut construire une mise en page
intelligente et adaptée à nos objectifs et nos contenus.
Le but est de provoquer des retours de la part des utilisateurs et de bien cerner les fonction-
nalités du système attendues et observables.
Dans ce qui suit, nous allons donner un aperçu sur quelques maquettes réalisées.
FIGURE 2.3 – Connexion des utilisateurs
25
FIGURE 2.4 – Tableau de bord utilisateurs
FIGURE 2.5 – Recherche et découverte de produits
FIGURE 2.6 – Gestion de panier
26
FIGURE 2.7 – Gestion de la clientèle
FIGURE 2.8 – Gestion de profil webmaster
2.2 Pilotage du projet avec scrum
2.2.1 Équipe et rôles
La répartition de l’équipe en fonction de leurs rôles est récapitulée dans le tableau 2.1.
En effet, elle se compose de trois rôles : le Product Owner, le Scrum Master et l’équipe de dé-
veloppement.
Tous les membres de l’équipe Scrum, quels que soient leurs rôles, sont au même niveau, sans
rapport hiérarchique entre eux.
27
L’équipe est auto-organisée, elle peut donc décider comment terminer le travail pour at-
teindre l’objectif de sprint. Tous ses membres sont attachés à cet objectif.
TABLE 2.1 – Équipe et rôles
Personne Rôle Mission
Scrum Master Mr Ben Rkaya Moez Ü Animer et faciliter le travail de l’équipe de

développement ;
Ü Acquitter de toutes les tâches administra-
tives et s’assurer que la méthodologie Scrum
est correctement appliquée.
Product Owner Mr Dammak Yassine Ü Participer à l’élaboration des besoins

client ;
Ü Porter la vision client du produit final ;
Ü Se charger du backlog Scrum ;
Ü Décider les priorités à donner aux dévelop-
pements des différentes user stories.
Équipe Mlle Ben Rabah Malek Ü Mettre en œuvre les solutions techniques ;
Mlle Sghaier Mariem Ü Réaliser les développements ;
Ü Travailler de façon incrémentale ;
Ü Livrer une partie du produit final utilisable
et testable à la fin de chaque sprint ou itéra-
tion.
2.2.2 Backlog Scrum
Le backlog présente une liste de tâches priorisées définissant les caractéristiques d’un pro-
duit. Il est un des éléments fondamentaux de la méthodologie Scrum.
Il s’agit de l’outil de travail principal du Product Owner qui se charge de recueillir les besoins
auprès des parties prenantes et de les transformer en liste de fonctionnalités prêtes à être déve-
loppées par l’équipe de développement.
28
TABLE 2.2 – Backlog Scrum
Id En Tant que Je voudrais (user story) Priorité
1 Visiteur Créer un compte Client Haute
2 Visiteur,Client Contacter un tiers Basse
3 Visiteur,Client Consulter les articles Moyenne
4 Visiteur,Client Chercher un article Haute
5 Visiteur,Client Gérer un panier Moyenne
6 Client Effectuer une commande Haute
7 Client Gérer son compte client Moyenne
8 Client Passer une réclamation Basse
9 Client Calculer la ration alimentaire Moyenne
10 Client Consulter ses commandes Basse
11 Client S’authentifier Haute
12 Technico-commercial Gérer les clients Haute
13 Technico-commercial Consulter les articles Moyenne
14 Technico-commercial Chercher un article Haute
15 Technico-commercial Contacter les tiers Basse
16 Technico-commercial Gérer son compte Moyenne
17 Technico-commercial Suivre les commandes Haute
18 Technico-commercial Créer un compte Haute
19 Technico-commercial S’authentifier Haute
20 Webmaster Gérer les avis clients Basse
21 Webmaster Maintenir le catalogue Haute
22 Webmaster Maintenir les informations éditoriales Moyenne
23 Webmaster Maintenir le site Basse
24 Webmaster Gérer son compte Moyenne
25 Webmaster Gérer les profils Haute
– Page suivante
29
TABLE 2.2 Backlog Scrum
Id En Tant que Je voudrais (user story) Priorité

26 Webmaster Consulter newsletter Basse
27 Webmaster Gérer les réclamations Basse
28 Webmaster S’authentifier Haute
29 Webmaster Suivre les commandes Moyenne
2.2.3 Plan de release
Comme le montre la figure 2.9, le plan de release permet d’avoir la connaissance actualisée
de ce qui va être fourni tout au long des sprints de la release.
FIGURE 2.9 – Plan de release
Conclusion
Dans ce chapitre nous avons présenté les besoins fonctionnels et non fonctionnels du système.
Dans un premier temps, nous avons identifié les différents acteurs de notre solution et leurs tâches
priorisées.
Dans un second temps, nous avons exposé quelques prototypes pour simuler les interfaces que nous
comptons réaliser.
Nous exploitons ensuite le chapitre suivant pour présenter l’environnement logiciel et matériel,
ainsi que l’architecture adoptée pour la réalisation de la solution.
30
CHAPITRE 3
SPRINT0
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
31
CHAPITRE 3. SPRINT0
Introduction
Durant ce chapitre, nous décrivons l’environnement matériel et logiciel. Par la suite, nous pré-
sentons l’architecture logicielle adoptée.
Finalement, nous déterminons les technologies de développement et les choix techniques.
3.1 Environnement matériel

Le tableau suivant illustre la configuration du matériel utilisé lors de la réalisation de la pla-
teforme.
TABLE 3.1 – Matériels utilisés
Matériel Configuration
Serveur BD Mysql Ordinateur portable HP

RAM installée : 12 Go
Disque dur SATA de 1000 Go
Processeur Intel Core i5 8e génération
Serveur Web Apache Ordinateur portable Lenovo

RAM installée : 8Go
Disque dur SATA de 1000 Go
Processeur Intel Core i5 8e génération
3.2 Environnement logiciel

Nous décrivons ci-dessous, les différents outils logiciels déployés lors de la réalisation de la
plateforme.
Visual Studio Code
Visual Studio (VS) est un éditeur de code open-source développé par Microsoft supportant un
très grand nombre de langages grâce à des extensions. Il supporte l’autocomplétion, la coloration
syntaxique, le débogage, et les commandes git [23].
32
CHAPITRE 3. SPRINT0
FIGURE 3.1 – Visual Studio Code
Balsamiq
Balsamiq est un éditeur du produit Balsamiq Mockups. Il nous permet de créer facilement des
prototypes d’Interface Homme Machine (IHM) électronique.
Avec Balsamiq Mockups il est ainsi possible de prototyper tout type d’applications (desktop,
web et smartphone) [24].
FIGURE 3.2 – Balsamiq
Pacestar UML
Pacestar UML nous permet de créer des diagrammes en UML. Il est aussi possible d’insérer des
liens hypertexte vers d’autres diagrammes et fichiers externes. Il peut fonctionner à l’aide d’un
système de glisser-déposer [25].
FIGURE 3.3 – Pacestar UML
Visual Paradigm
Visual Paradigm est un logiciel qui nous permet de mettre en place des diagrammes UML.
Il fournit des capacités de génération de rapports et d’ingénierie de code, y compris la géné-
ration de code.
Il peut faire de l’ingénierie inverse des diagrammes à partir du code et fournir une ingénierie
aller-retour pour divers langages de programmation [26].
33
CHAPITRE 3. SPRINT0
FIGURE 3.4 – Visual Paradigm
Overleaf
Overleaf nous permet d’éditer du texte en latex sans aucun téléchargement d’application. Il est
capable de créer un style de document qui peut être utilisé pour normaliser l’apparence de nom-
breux documents différents [27].
FIGURE 3.5 – Overleaf
3.3 Architecture logique

De nombreux frameworks s’appuient désormais sur l’architecture dite Modèle Vue Contrô-
leur (MVC) y compris Laravel. Le pattern MVC permet de bien organiser le code source.
Avec l’architecture MVC, nous regardons la structure de l’application en ce qui concerne le fonc-
tionnement du flux de données de notre application.
FIGURE 3.6 – Architecture mvc
34
CHAPITRE 3. SPRINT0
Le but de MVC est précisément de diviser la logique du code en trois parties, que l’on peut
retrouver dans des fichiers séparés [28] :
j Modèle : cette partie gère les données du 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. Nous y trouvons donc entre autres les requêtes SQL.
j 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.
Nous y trouvons essentiellement du code HTML mais aussi quelques boucles et conditions
PHP très simples, pour afficher par exemple une liste des articles.
j 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 vi-
siteur a le droit de voir la page ou non (gestion des droits d’accès).
3.4 Architecture physique

Une architecture physique est indispensable pour décrire tous les composants matériels qui
prennent en charge l’application. En effet, l’architecture trois tiers, encore appelée client-serveur
de deuxième génération ou client-serveur distribué, sépare l’application en trois niveaux de ser-
vice distincts [29] :
j Présentation : chargée du traitement de l’interaction avec l’utilisateur. C’est un rôle d’affi-

chage et d’interaction (fenêtres, formulaires, pages Web, etc.)
j Applicative/métier : comporte tous les objets de contrôle et d’entités nécessaires pour faire
les traitements, la vérification des règles, etc. (le cœur de l’application)
j Persistance/données : réalise le stockage, la récupération et la recherche des données.
Cette séparation par couches de responsabilités sert à découpler au maximum une couche de
l’autre afin d’éviter l’impact de futures évolutions de l’application. Par exemple : si nous sommes
amené à devoir changer de base de données relationnelle, seule la couche d’accès aux données
sera impactée, la couche métier et la couche de présentation ne seront pas concernées car elles
auront été découplées des autres.
35
CHAPITRE 3. SPRINT0
FIGURE 3.7 – Diagramme de déploiement de l’architecture 3 tiers
3.5 Choix techniques

Nous décrivons ci-dessous, la liste des choix techniques déployés lors de la réalisation de la
plateforme.
CSS
Le CSS pour Cascading Style Sheets, est un langage informatique utilisé sur Internet pour la mise
en forme des fichiers et des pages HTML[30].
FIGURE 3.8 – CSS
Bootstrap
Bootstrap est un framework développé par l’équipe du réseau social Twitter. Proposé en open
source, ce framework utilisant les langages Hypertext Markup Language (HTML), Feuilles de style
en cascade (CSS) et JavaScript fournit aux développeurs des outils pour créer un site facilement.
Bootstrap nous permet de développer des sites avec un design responsive[31].
36
CHAPITRE 3. SPRINT0
FIGURE 3.9 – Bootstrap
HTML
L’HyperText Markup Language, HTML, désigne un type de langage informatique descriptif. Il
s’agit plus précisément d’un format de données utilisé dans l’univers d’Internet pour la mise en
forme des pages Web.
Il nous permet, entre autres, d’écrire de l’hypertexte, mais aussi d’introduire des ressources mul-
timédias dans un contenu[32].
FIGURE 3.10 – HTML
jQuery
jQuery est une bibliothèque JavaScript gratuite, libre et multiplateforme. Compatible avec l’en-
semble des navigateurs Web (Internet Explorer, Safari, Chrome, Firefox, etc.), elle a été conçue et
développée en 2006 pour faciliter l’écriture de scripts[33].
FIGURE 3.11 – jQuery
Laravel 8
Laravel est un framework web open-source écrit en PHP Hypertext Preprocessor (PHP) respec-
37
CHAPITRE 3. SPRINT0
tant le principe modèle-vue-contrôleur et entièrement développé en programmation orientée

objet[34].
FIGURE 3.12 – Laravel 8
MySQL
MySQL est un système de gestion de Systèmes de Gestion de Base de Données Relationnels
(SGBDR).
Il fait partie des logiciels de gestion de base de données les plus utilisés au monde, autant par
le grand public (applications web principalement) que par des professionnels[35].
FIGURE 3.13 – MySQL
Conclusion
Au cours de ce chapitre, nous avons présenté l’environnement matériel nécessaire pour la prépa-
ration du logiciel employé dans notre système. Nous avons aussi exposé les architectures physique
et logique de notre solution ainsi que les différents choix techniques.
Nous enchaînons avec le chapitre suivant présentant les trois sprints de notre système.
38
CHAPITRE 4
ÉTUDE ET RÉALISATION DU RELEASE
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 Sprint1- Cas d’utilisation du webmaster . . . . . . . . . . . . . . . . . . . . . . 41
4.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.6 Rétrospective de sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Sprint2- Cas d’utilisation du Technico-commercial . . . . . . . . . . . . . . . 57
4.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3 Sprint3- Cas d’utilisation des clients . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
39
CHAPITRE 4. ÉTUDE ET RÉALISATION DU RELEASE
4.3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
40
Introduction
Ce présent chapitre présente l’étude et la réalisation de chaque sprint défini dans le plan release.
En effet, nous commençons par présenter son backlog et sa phase d’analyse. Nous effectuons ensuite
une phase de conception du sprint pour arriver finalement à sa phase de développement.
4.1 Sprint1- Cas d’utilisation du webmaster
4.1.1 Backlog du Sprint1
Dans cette section, nous représentons l’ensemble des fonctionnalités (User Stories) écrites
par le product owner dans l’univers du scrum qui ont été prises en charge par l’équipe de déve-
loppement pendant le sprint en cours.
Nous estimons un travail quotidien de six heures pendant quatre semaines pour la réalisation
de ce premier sprint.
Ci après, nous dressons la liste des fonctionnalités en tenant compte de la quantité de travail
restant à effectuer en nombre d’heures.
TABLE 4.1 – Backlog du Sprint1
Id En Tant que Je voudrais (user story) Estimation(/h)
1 Webmaster Gérer les avis clients 10
2 Webmaster Maintenir le catalogue 17
3 Webmaster Maintenir les informations éditoriales 15
4 Webmaster Maintenir le site 10
5 Webmaster Gérer son compte 14
6 Webmaster Gérer les profils 14
7 Webmaster Consulter newsletter 9
8 Webmaster Gérer les réclamations 8
9 Webmaster S’authentifier 10
10 Webmaster Suivre les commandes 13
41
4.1.2 Spécification fonctionnelle
4.1.2.1 Diagramme de cas d’utilisation du sprint1
Nous représentons ci-après le diagramme de cas d’utilisation du premier sprint.
FIGURE 4.1 – Diagramme de cas d’utilisation du sprint1
4.1.2.2 Raffinement des cas d’utilisation du sprint1
Raffinement du cas d’utilisation - S’authentifier
FIGURE 4.2 – Raffinement du cas d’utilisation - S’authentifier
42
Description textuelle du cas d’utilisation - S’authentifier
TABLE 4.2 – S’authentifier
Nom S’authentifier
Acteur Webmaster (acteur principal).
Objectif Accès au tableau de bord.
Pré-condition Le webmaster doit être créé dans la base de données et connaît ses iden-
tifiants.
S.Nominal ÊLe webmaster remplit le formulaire d’authentification avec l’ensemble

des informations nécessaires à son identification ;
ËLe système vérifie les informations saisies par le webmaster ;
ÌLe système renvoie le webmaster vers son espace d’administration.
S.Alternatif A2- Données saisies invalides

ÌLe système renvoie un message d’erreur et signale au webmaster de re-
commencer l’étape1 du Scénario Nominal (SN).
Suppléments ÜLe formulaire d’authentification doit être toujours disponible.

ÜLa qualité des messages d’erreur doit prendre en compte la pertinence,
la facilité de lecture et la possibilité de s’auto-corriger facilement.
Raffinement du cas d’utilisation - Maintenir catalogue
FIGURE 4.3 – Raffinement du cas d’utilisation - Maintenir catalogue
43
Description textuelle du cas d’utilisation - Ajouter un article
TABLE 4.3 – Ajouter un article
Nom Ajouter un article
Objectif Création d’un nouvel article.
Pré-condition ÜLe webmaster doit être authentifié (voir le CU S’authentifier).

ÜLa liste des articles doit être disponible.
S.Nominal ÊLe webmaster remplit le formulaire d’ajout d’un nouvel article avec les
informations nécessaires ;
ËLe système récapitule les informations saisies et vérifie leurs validités ;
ÌLe webmaster confirme l’ajout de l’article ;
ÍLe système valide l’opération effectuée.
S.Alternatif A2- Champ(s) erroné(s)

ÌLe système renvoie un message d’erreur et signale au webmaster de re-
commencer l’étape1 du SN.
Suppléments ÜLa qualité des messages d’erreur doit prendre en compte la pertinence,
Description textuelle du cas d’utilisation - Chercher un article
TABLE 4.4 – Chercher un article
Nom Chercher un article
Objectif Accès à un article bien précis dans l’ensemble du catalogue.

S.Nominal ÊLe webmaster lance la recherche de l’article ;

ËLe système affiche une page de résultats ;
ÌLe webmaster sélectionne un article ;
ÍLe système lui affiche les détails de l’article.
44
S.Alternatif A2-a- Article(s) non trouvé(s)

ËLe système signale l’échec au webmaster. Le Cas d’Utilisation (CU) re-
démarre à l’étape 1 du SN.
A2-b- Article(s) trouvé(s)
ËLe système signale le nombre d’article au webmaster et lui affiche une
première page de résultats ;
ÌLe Webmaster navigue dans les pages et enchaîne éventuellement sur
l’étape 3 du SN.
A3- Le webmaster n’est pas intéressé par les résultats
ÌLe webmaster revient à l’étape1 du SN pour lancer une nouvelle re-
cherche ;
ÌLe webmaster abandonne la recherche. Le CU se termine en échec.
Suppléments Ü Les résultats de la recherche doivent être pertinents, c’est-à-dire cor-

respondre à la requête dans au moins 99% des cas.
Ü Le formulaire de recherche rapide doit être toujours visible quelle que
soit la résolution d’écran du webmaster.
Description textuelle du cas d’utilisation - Supprimer un article
TABLE 4.5 – Supprimer un article
Nom Supprimer un article
Objectif Suppression d’un article.

S.Nominal ÊLe CU commence lorsque le webmaster cherche un article ;

ËLe webmaster sélectionne depuis la page «articles» l’article à supprimer ;
ÌLe système affiche un message de confirmation au webmaster ;
ÍLe webmaster clique sur le bouton «Supprimer un article» ;
ÎLe système confirme la suppression.
45
S.Alternatif A3- Annulation de la suppression

ÊLe webmaster abandonne la tâche de la suppression de l’article. Le CU
se termine en échec.
Suppléments Néant.
4.1.3 Conception
4.1.3.1 Diagrammes de séquences
A l’intérieur d’un système, il existe très souvent des classes qui possèdent un rôle bien parti-
culier qui est intéressant de les visualiser dans nos diagrammes de séquence. C’est le cas notam-
ment :
j Pour les classes qui représentent des composants de l’IHM.
j Pour la classe qui contrôle globalement le système avec la prise en compte de la gestion
événementielle.
j Pour les classes qui implémentent la persistance des attributs (associées à une base de don-
nées).
Jackobson distinguent les trois stéréotypes suivants :
j «boundary» : classes qui servent à modéliser les interactions entre le système et ses acteurs.
j «control» : classes utilisées pour représenter la coordination, l’enchaînement et le contrôle

d’autres objets.
j «entity» : classes qui servent à modéliser des informations durables et souvent persis-
tantes.
Diagramme de séquences du cas d’utilisation - S’authentifier

Le webmaster veut accéder à son tableau de bord. Sur la page d’authentification, il saisit ses
informations personnelles (email et mot de passe). Nous notons que la vérification syntaxique
des informations saisies est de la responsabilité de la classe dialogue EcranConnexion elle-même
(et pas du contrôle ControleurWebmaster associé qui n’est invoqué que dans le cas favorable
où il n’y a pas d’erreur de syntaxe).
Le contrôle ControleurWebmaster délègue ensuite à une étape de recherche. Le Controleur-
Webmaster effectue une recherche parmi l’ensemble des webmaster. L’entité webmaster construit
46
alors une collection dynamique du webmaster qui renvoie le résultat correspondant à la recherche
au ControleurWebmaster.
Celui-ci initialise le dialogue EcranPrinicpal.
FIGURE 4.4 – Diagramme de séquences du cas d’utilisation - S’authentifier
Diagramme de séquences du cas d’utilisation - Ajouter un article
FIGURE 4.5 – Diagramme de séquences du cas d’utilisation - Ajouter un article
47
Une fois authentifié, le webmaster souhaite ajouter un nouvel article. Pour cela, il saisit les
informations relatives au produit à ajouter (infosArticle). La vérification syntaxique des informa-
tions ajoutées est de la responsabilité de la classe dialogue EcranArticle elle-même.
Le ControleurArticle procède à l’enregistrement du nouvel article et affiche un message indi-
quant le succès de l’opération.
Diagramme de séquences du cas d’utilisation - Chercher un article
FIGURE 4.6 – Diagramme de séquences du cas d’utilisation - Chercher un article
Le webmaster veut trouver le plus rapidement possible un article. Suite à une authentifica-
tion, et à travers son tableau de bord, le webmaster choisit d’effectuer une recherche dans la
barre de recherche. Il saisit une phrase de recherche. Nous notons que la vérification syntaxique
de la phrase de recherche est de la responsabilité de la classe dialogue EcranRechrcheArticle
elle-même.
Le contrôle ControleurArticle délègue ensuite à une entité article la recherche proprement dite.
L’entité article construit alors une collection de résultats correspondants à la recherche, qu’il
renvoie au contrôle ControleurArticle. Celui-ci initialise le dialogue EcranResultatRecherche
chargé du résultat, en lui passant la collection en paramètre.
Le webmaster peut ensuite naviguer dans les différentes pages du résultat.
48
Diagramme de séquences du cas d’utilisation - Supprimer un article

Suite à une authentification et une recherche d’article, le webmaster sélectionne sur l’Ecran-
Article l’article à supprimer (par son id). L’EcranArticle envoie au ControleurArticle l’id de l’ar-
ticle correspondant. Le ControleurArticle cherche l’article parmi la collection article.
Une fois l’opération de suppression est confirmée, le ControleurArticle envoie un message in-
diquant le succès de l’opération.
FIGURE 4.7 – Diagramme de séquences du cas d’utilisation - Supprimer un article
4.1.3.2 Diagrammes d’états-transitions
Au cours de cette sous section, nous réalisons les diagrammes d’états-transitions du web-
master qui présentent les pages et les frames principales des différents cas d’utilisation.
Dans ce cas, la représentation graphique aide à faire ressortir dans quel état et sous quelles condi-
tions le cas d’utilisation s’applique.
En effet, ces états correspondent à différentes situations survenues au cours de déroulement du
cas d’utilisation.
Nous présentons ci-dessous les diagrammes d’états-transitions que nous jugeons utiles.
49
Diagramme d’états-transitions - Chercher un technico-commercial
FIGURE 4.8 – Diagramme d’états-transitions - Chercher un technico-commercial
Diagramme d’états-transitions - Ajouter un article
FIGURE 4.9 – Diagramme d’états-transitions - Ajouter un article
4.1.3.3 Diagramme de classes du sprint1
Nous proposons un diagramme de classes relatif au développement du premier sprint. Nous

décrivons alors toutes les classes de ce sprint,leurs attributs,leurs méthodes, ainsi que les rela-
tions qui les relient.
50
FIGURE 4.10 – Diagramme de classe du sprint1
4.1.4 Réalisation
Interface - Authentification webmaster

Avant d’accéder à l’application, le webmaster est invité à s’authentifier en introduisant son
adresse mail et son mot de passe dans le formulaire de connexion.
FIGURE 4.11 – Authentification webmaster
51
Lorsque le webmaster clique sur «Se connecter», il sera dirigé vers la page d’accueil du back
office, véritable tableau de bord de notre plateforme.
Interface - Tableau de bord Administration»
Une fois authentifié, le tableau de bord s’affiche au webmaster.
Non seulement il nous donne un résumé de tout ce que nous devons savoir sur notre plateforme
(la quantité hebdomadaire des commandes effectuées, le nombre des utilisateurs inscrits sur
notre plateforme), mais il nous donne aussi un ensemble de fonctionnalités telles que la gestion
des utilisateurs de la plateforme (technico-commerciaux et clients), la gestion des produits, des
commandes, des avis des clients et des informations éditoriales de la plateforme.
FIGURE 4.12 – Tableau de bord Administration
Interface - Gestion des technico-commerciaux

Le webmaster choisit le lien vers la page de gestion des technico-commerciaux.
Il peut bien évidemment ajouter, supprimer, afficher et voire même modifier un profil technico-
commercial.
52
FIGURE 4.13 – Gestion des technico-commerciaux
Interface - Suivi des commandes

Le webmaster a la possibilité de suivre les commandes passées soit par le client soit par le
technico-commercial. En effet, il peut consulter les détails d’une commande, ou bien la suppri-
mer.
FIGURE 4.14 – Suivi des commandes
53
Interface - Ajouter un produit

Le webmaster est capable de supprimer et mettre à jour les produits sur la plateforme.
Il a le moyen aussi d’ajouter de nouveaux produits. En cliquant sur le bouton «Ajouter un pro-
duit», une boite de dialogue est ainsi affichée en indiquant les informations correspondantes au
produit à ajouter.
FIGURE 4.15 – Ajouter un produit
Interface - Message de succès d’ajout de produit

Un message de succès s’affiche une fois que le webmaster confirme l’opération de l’ajout
effectuée comme le montre la figure ci-dessous.
FIGURE 4.16 – Message de succès d’ajout de produit
54
Interface - Suivi des réclamations

Le webmaster est informé sur les réclamations accomplies par les utilisateurs. En effet, il a
l’habilité de supprimer, voir les détails de la plainte et même répondre à ceux qui sont concernés.
FIGURE 4.17 – Suivi des réclamations
4.1.5 Mêlée quotidienne du sprint1
FIGURE 4.18 – Mêlée quotidienne du sprint1
La mêlée quotidienne (daily Scrum) est une réunion de 15 minutes qui nous permet de faire
le point sur l’avancement des tâches en cours et de partager les difficultés qui nous freinent dans
l’accomplissement de ces dernières.
55
Pour faciliter la visualisation des missions pendant ces réunions, il est possible d’utiliser un kan-
ban pour voir la liste de toutes les tâches et l’avancement du projet.
Le Daily Scrum est donc l’occasion pour chaque membre de l’équipe de se synchroniser avec
les autres, de demander de l’aide si nécessaire et de préparer dans des conditions optimales une
nouvelle journée de Sprint.
Nous présentons la figure ci-dessus pour bien clarifier notre mêlée quotidienne durant le
sprint1.
4.1.6 Rétrospective de sprint1
Le scrum burndown permet de suivre graphiquement l’avancement des développements du-

rant ce premier sprint.
FIGURE 4.19 – Rétrospective de sprint1
Comme schématisé ci-dessus, sur la première partie du graphique, la courbe réelle (en rouge)
reste au-dessus de la droite idéale (en vert). C’est assez normal puisque durant cette période,
nous prenons connaissance des nouvelles tâches embarquées dans le sprint courant. C’est éga-
lement à ce moment-là que nous nous apercevons que certaines tâches sont finalement plus
complexes à développer que prévu.
56
4.2 Sprint2- Cas d’utilisation du Technico-commercial
Le tableau ci-joint récapitule les différentes tâches effectuées avec la durée estimée en heure.
TABLE 4.6 – Sprint2 backlog
Id En Tant Que Je voudrais (user story) Estimation (/h)
1 Technico-commercial Gérer les clients 20
2 Technico-commercial Consulter les articles 15
3 Technico-commercial Chercher un article 10
4 Technico-commercial Contacter les tiers 22
5 Technico-commercial Gérer son compte 10
6 Technico-commercial Suivre les commandes 25
7 Technico-commercial Créer un compte 10
8 Technico-commercial S’authentifier 8
57
Raffinement du cas d’utilisation - Consulter les articles
FIGURE 4.21 – Raffinement du cas d’utilisation - Consulter les articles
Description textuelle du cas d’utilisation - Consulter les articles
TABLE 4.7 – Consulter les articles
Nom Consulter les articles
Acteur Technico-commercial (acteur principal).
Objectif Consultation de la liste des articles.
Pré-condition ÜLe technico-commercial doit être authentifié.

ÜLe catalogue doit être disponible.
S.Nominal Ê Le CU commence lorsque le technico-commercial cherche un article ;

ËLe technico-commercial sélectionne l’article désiré ;
ÌLe système renvoie l’article correspondant.
S.Alternatif Néant.
Raffinement du cas d’utilisation - Gérer les clients
FIGURE 4.22 – Raffinement du cas d’utilisation - Gérer les clients
58
Description textuelle du cas d’utilisation - Ajouter un client
TABLE 4.8 – Ajouter un client
Nom Ajouter un client
Objectif Ajout d’un client.
Pré-condition Le technico-commercial doit être authentifié.
S.Nominal ÊLe technico-commercial remplit le formulaire d’ajout d’un nouveau

client avec les informations nécessaires ;
ËLe système récapitule les informations saisies et vérifie leurs validités ;
ÌLe technico-commercial confirme l’ajout d’un client ;
ÍLe système valide l’opération effectuée.
S.Alternatif A2-a-Champ(s) erroné(s)

ÌLe système renvoie un message d’erreur et signale au technico-
commercial de recommencer l’étape1 du SN.
A2-b-Champ(s) redondant(s)
ÌLe système renvoie un message d’erreur indiquant que le profil existe
déjà et demande de recommencer l’étape1 du SN.
Suppléments ÜLa qualité des messages d’erreur doit prendre en compte la pertinence,
Description textuelle du cas d’utilisation - Chercher un client
TABLE 4.9 – Chercher un client
Nom Chercher un client
Objectif Accès à un client bien précis.

ÜLe client doit être disponible.
59
S.Nominal ÊLe technico-commercial lance la recherche du client ;

ËLe système affiche une page de résultats ;
ÌLe technico-commercial sélectionne un client ;
ÍLe système lui affiche les détails du client.
S.Alternatif A2-a- Client non trouvé

ËLe système signale l’échec au technico-commercial. Le CU redémarre à
l’étape 1 du SN.
A2-b- Client trouvé
ËLe système affiche au technico-commercial une page de résultats ;
ÌLe technico-commercial navigue dans les pages et enchaîne éventuel-
lement sur l’étape 3 du SN ;
A3- Le technico-commercial n’est pas intéressé par les résultats
ÌLe technico-commercial revient à l’étape1 du SN pour lancer une nou-
velle recherche ;
ÌLe technico-commercial abandonne la recherche. Le CU se termine en
échec.
Suppléments Ü Les résultats de la recherche doivent être pertinents.

Ü Le formulaire de recherche rapide doit être toujours visible et donc se
situer dans la partie supérieure de toutes les pages, quelle que soit la ré-
solution d’écran du technico.
Description textuelle du cas d’utilisation - Supprimer un client
TABLE 4.10 – Supprimer un client
Nom Supprimer un client
Objectif Suppression d’un client.

ÜLe client doit être disponible.
60
S.Nominal ÊLe CU commence lorsque le technico-commercial cherche un client ;

ËLe technico-commercial sélectionne parmi la liste résultats le client à
supprimer ;
ÌLe système affiche un message de confirmation au technico-
commercial ;
ÍLe technico-commercial clique sur le bouton «supprimer» et confirme
la tâche de suppression ;
ÎLe système valide l’opération de suppression.
S.Alternatif A4- Annulation de la suppression

ÊLe technico-commercial abandonne la tâche de la suppression du
client. Le CU se termine en échec.
4.2.3 Conception
Diagramme de séquences du cas d’utilisation - Consulter les articles
FIGURE 4.23 – Diagramme de séquences du cas d’utilisation - Consulter les articles
Suite à une authentification et après une recherche d’article, le technico-commercial choisit

d’afficher les détails d’un article (par son id). L’EcranArticle envoie l’id de ce dernier au Contro-
61
leurArticle qui fait la recherche parmi l’entité article qui retourne le résultat au ControleurAr-
ticle. Celui-ci crée une FicheArticle en lui passant la collection en paramètre.
Le technico-commercial visualise ainsi la fiche de l’article cherché.
Diagramme de séquences du cas d’utilisation - Ajouter un client
Une fois authentifié, le technico-commercial désire ajouter un nouveau client. Pour cela, il
saisit les informations du client à ajouter (infosclient). Nous notons que la vérification syntaxique
est de la responsabilité de la classe dialogue EcranAjoutClient elle-même.
Le ControleurArticle procède à l’enregistrement du nouveau client et affiche un message
indiquant le succès de l’opération.
FIGURE 4.24 – Diagramme de séquences du cas d’utilisation - Ajouter un client
Diagramme de séquences du cas d’utilisation - Chercher un client

Le technico-commercial veut trouver le plus rapidement possible un client. Suite à une au-
thentification, le technico-commercial choisit d’effectuer une recherche dans la barre de recherche.
Pour ce faire, il saisit une phrase de recherche. Nous notons que la vérification syntaxique de la
phrase de recherche est de la responsabilité de la classe dialogue EcranRecherche elle-même
(et pas du contrôle ControleurClient associé qui n’est invoqué que dans le cas favorable où il n’y
a pas d’erreur de syntaxe).
Le contrôle ControleurClient délègue ensuite à une entité users la recherche proprement dite.
62
L’entité users construit alors une collection de résultats correspondants à la recherche, qu’elle
renvoie au contrôle ControleurClient. Celui-ci initialise le dialogue EcranResultatRecherche
chargé du résultat, en lui passant la collection en paramètre.
Le technico-commercial peut ensuite naviguer dans les différentes pages du résultat.
FIGURE 4.25 – Diagramme de séquences du cas d’utilisation - Chercher un client
Diagramme de séquences du cas d’utilisation - Supprimer un client
FIGURE 4.26 – Diagramme de séquences du cas d’utilisation - Supprimer un client
Suite à une authentification et une recherche d’un client, le technico-commercial sélec-

tionne sur l’EcranClient le client à supprimer. L’EcranClient envoie au ControleurClient l’id
63
de ce dernier. Le ControleurClient cherche le client parmi la collection users.

Une fois l’opération de suppression est confirmée, le ControleurClient envoie un message de
succès.
Diagramme d’états-transitions - Chercher un client
FIGURE 4.27 – Diagramme d’états-transitions - Chercher un client
Diagramme d’états-transitions - Supprimer un client
FIGURE 4.28 – Diagramme d’états-transitions - Supprimer un client
64
FIGURE 4.29 – Diagramme de classes du sprint2
4.2.4 Réalisation
Ci-joint les interfaces accomplies durant le sprint 2.

Interface - Gestion du compte
FIGURE 4.30 – Gestion du compte
65
Si le technico-commercial désire modifier son compte, une page est affichée comme le montre
la figure ci-dessus.
Il peut modifier ses informations personnelles telles que son nom, son prénom, son numéro de
téléphone ou son mot de passe. Il a aussi la possibilité d’intégrer une photo de profil s’il le sou-
haite.
Interface - Gestion des clients
FIGURE 4.31 – Gestion des clients
Le technico-commercial accède à la plateforme et choisit le menu «Gestion client». Une liste

exhaustive des clients est alors affichée.
Les informations personnelles relatives des clients sont à la disposition du technico-commercial.
Ce dernier, peut consulter, ajouter, modifier et supprimer des clients.
Interface - Consulter les détails du client
A chaque fois qu’un internaute s’inscrit sur la plateforme, il devient un client. Le technico-
commercial peut donc accéder à sa fiche client pour la consulter.
Il peut éventuellement consulter les informations personnelles du client (nom, prénom, email,
téléphone, adresse) et les informations concernant son usager (le nombre et le type) avec le
nombre d’étable que le client possède.
66
FIGURE 4.32 – Consulter les détails du client
Interface - Suivi des commandes

Le technico-commercial peut suivre aisément les commandes effectuées par le client. En
effet, il peut les modifier , les supprimer et les approuver.
Depuis cette page, lorsque le technico-commercial clique sur l’icône «détails» une fiche dé-
taillant la commande s’affiche.
67
FIGURE 4.33 – Suivi des commandes
Interface - Forum
Le technico-commercial consulte l’espace consacré au forum des technico-commerciaux
dans le but d’assurer une communication interne dans la plateforme.
FIGURE 4.34 – Forum
Plusieurs actions sont possibles, parmi lesquelles on précise :

Interface - Ajouter un sujet
Le technico-commercial est en mesure d’évoquer un sujet qui sera d’un grand apport aux
technico-commerciaux.
En cliquant sur le bouton «Ajouter un sujet», une boite de dialogue est ainsi affichée en indiquant
68
le titre et le contenu du sujet à ajouter.
FIGURE 4.35 – Ajouter un sujet
Une fois cette action d’ajout est confirmée par le technico-commercial, le sujet ajouté est
listé parmi les autres sujets du forum.
Interface - Soumettre un commentaire
Le technico-commercial peut ajouter un commentaire sur le sujet en cliquant sur le bouton
«Soumettre mon commentaire». Par contre, s’il souhaite donner son avis sur un commentaire
quelconque, il peut tout simplement cliquer sur le bouton «Répondre».
FIGURE 4.36 – Soumettre un commentaire
69
Interface - Message de succès d’ajout d’une réponse

Suite à la confirmation de l’ajout d’une réponse, un message indiquant le succès de l’opéra-
tion s’affiche au technico-commercial.
FIGURE 4.37 – Message de succès d’ajout d’une réponse
Interface - Supprimer une réponse

Le technico-commercial a la possibilité aussi de supprimer sa réponse sur un commentaire
donné. Un message s’affiche au technico-commercial une fois que l’opération de suppression
est confirmée.
FIGURE 4.38 – Supprimer une réponse
70
Ci-dessous la figure qui récapitule notre mêlée quotidienne durant le sprint2.
4.2.6 Rétrospective de Sprint2
FIGURE 4.40 – Rétrospective de Sprint2
Ci-dessus est schématisé la courbe traçant la quantité de travail effectué (courbe en rouge)
par rapport à la quantité de travail idéal (courbe en vert). On décrit quelques fluctuations de la
courbe du travail effectué plus marquées durant les premiers jours. Elles pourraient être dues
aux quelques difficultés rencontrées lors de la gestion de nouvelles tâches.
Toutefois, on remarque que la courbe du travail effectué s’approche de celle du travail idéal.
Ceci pourrait être expliqué par le gain d’expérience et la capacité de s’habituer à ces nouvelles
tâches.
71
4.3 Sprint3- Cas d’utilisation des clients
Le tableau 4.11 représente la répartition des fonctionnalités de l’internaute selon la durée en

heure.
TABLE 4.11 – Backlog du Sprint3
Id En Tant que Je voudrais (user story) Estimation(/h)
1 Visiteur Créer un compte client 12
2 Visiteur, Client Contacter un tiers 18
3 Visiteur, Client Consulter les articles 7
4 Visiteur, Client Chercher un article 13
5 Visiteur, Client Gérer son panier 15
6 Client Effectuer une commande 10
7 Client Gérer son compte 11
8 Client Passer une réclamation 10
9 Client Calculer la ration alimentaire 9
10 Client, Technico-commercial Consulter les commandes 7
11 Client S’authentifier 8
Le diagramme de cas d’utilisation ci dessous montre les différentes fonctionnalités de l’in-

ternaute (en tant que visiteur et en tant que client).
Nous mentionnons que l’utilisation de la flèche sur l’association entre le cas d’utilisation «Ef-
fectuer une commande» et l’acteur technico-commercial signale un sens unique de transmis-
sion d’information. En effet, cet acteur ne fait que recevoir des messages du système, sans lui en
envoyer.
72
Raffinement du cas d’utilisation - Créer un compte client
FIGURE 4.42 – Raffinement du cas d’utilisation «Créer un compte client»
Description textuelle du cas d’utilisation - Créer un compte client
TABLE 4.12 – Créer un compte client
Nom Créer un compte client
Acteur Visiteur (acteur principal).
Objectif Création d’un profil client.
Pré-condition Le visiteur est connecté sur le serveur mySQL.
73
S.Nominal Ê Le visiteur saisit les informations nécessaires (nom, prénom, email

etc.) ;
ËLe système vérifie les données saisies.
ÌLe système valide l’inscription.
S.Alternatif A2-a-Données saisies non valides

ÌLe système renvoie un message d’erreur et signale au visiteur de recom-
mencer l’étape 1 du SN .
A2-b-Données saisies redondantes
ÌLe système renvoie un message d’erreur au visiteur en indiquant que le
profil existe déjà et lui signale de recommencer l’étape 1 du SN.
Suppléments ÜLa qualité des messages d’erreur doit être pertinente, la facilité de lec-
ture et la possibilité de s’auto-corriger facilement.
Ü Le formulaire d’inscription doit être toujours disponible.
Raffinement du cas d’utilisation - Gérer son panier
FIGURE 4.43 – Raffinement du cas d’utilisation - Gérer son panier
Description textuelle du cas d’utilisation - Gérer son panier
TABLE 4.13 – Gérer son panier
Nom Gérer son panier
Acteur Internaute (acteur principal).
Objectif Enregistrement d’un article dans le panier.
Pré-condition Néant.
74
S.Nominal ÊL’internaute enregistre les articles qui l’intéressent dans le panier ;

ËLe système affiche à l’internaute le contenu de son panier :
Chaque article qui a été préalablement sélectionné est présenté sur une
ligne.
S.Alternatif A2-a Le panier est vide

ÊLe système affiche un message d’erreur à l’internaute «Votre panier est
vide» et lui propose de revenir à l’étape1 du SN.
A2-bL’Internaute modifie les quantités des lignes du panier, ou en sup-
prime.
ÌL’Internaute confirme la mise à jour du panier, le CU reprend à l’étape 2
du SN.
Suppléments ÜLe panier de l’Internaute est sauvegardé pendant toute la durée de sa

visite sur l’application.
Raffinement du cas d’utilisation - Effectuer une commande
FIGURE 4.44 – Raffinement du cas d’utilisation - Effectuer une commande
Description textuelle du cas d’utilisation - Effectuer une commande
TABLE 4.14 – Effectuer une commande
Nom Effectuer une commande
Acteur Client (acteur principal), technico-commercial (acteur secondaire).
Objectif Effectuation d’une commande.
Pré-condition Ü Le client doit être authentifié.

Ü Le panier du client n’est pas vide.
75
S.Nominal Ê Le client passe sa commande et saisit les informations nécessaires à la

livraison ;
Ë Le système vérifie les données saisies ;
Ì Le système affiche un récapitulatif des données saisies et du panier à
commander ;
Í Le client valide sa commande ;
ÎLe système notifie l’effectuation d’une nouvelle commande au technico-
commercial et confirme la prise de commande au client ;
Ï Le technico-commercial valide la commande.
S.Alternatif A2- Données de livraison saisies non valides

Ì Le système renvoie un message d’erreur et signale au client de recom-
mencer l’étape1 du SN.
A4- Le client annule sa commande
Í Le client abandonne l’effectuation de la commande. Le CU se termine
en échec.
A5- Délai de la prise de la commande > 24h
Ï Le système valide automatiquement la commande.
Raffinement du cas d’utilisation - Calculer la ration alimentaire
FIGURE 4.45 – Raffinement du cas d’utilisation - Calculer la ration alimentaire
Description textuelle du cas d’utilisation - Calculer la ration alimentaire
TABLE 4.15 – Calculer la ration alimentaire
Nom Calculer la ration alimentaire
Acteur Client (acteur principal).
Objectif Calcul de la ration alimentaire.
76
Pré-condition Le client doit être authentifié.
S.Nominal ÊLe client saisit les informations nécessaires pour le calcul ;

ËLe système vérifie les données saisies ;
ÌLe client valide l’opération de calcul ;
ÍLe système lui affiche le résultat.
S.Alternatif Néant.
4.3.3 Conception
Diagramme de séquences du cas d’utilisation - Créer un compte client
FIGURE 4.46 – Diagramme de séquences du cas d’utilisation - Créer un compte client
Le visiteur veut s’inscrire sur la plateforme afin de bénéficier de ses fonctionnalités. À cet
égard, il remplit le formulaire avec ses informations personnelles nécessaires (nom, prénom,
email, etc.). La classe dialogue EcranInscription vérifie les données passées, si elles sont valides,
elle donne l’ordre de la création d’un nouveau client au contrôleur Controleurinscription. Ce
dernier ajoute les données au niveau de l’entité users et dirige le visiteur vers son espace.
Diagramme de séquences du cas d’utilisation - Gérer son panier
Lorsque l’internaute est intéressé par un article, il doit avoir la possibilité de l’enregistrer dans
son panier. Ensuite, il doit pouvoir supprimer ou encore en modifier les quantités avant de passer
sa commande. Le ControleurPanier a la responsabilité de gérer le panier et toutes les lignes du
panier au fur et à mesure. Il est également responsable d’afficher un dialogue particulier récapi-
tulant le panier en cours et permettant à l’internaute de le modifier.Continuons maintenant en
77
considérant un scénario dans lequel l’internaute modifie la quantité d’un article sélectionné, ou
en supprime puis demande l’effectuation de sa commande. L’EcranPanier reçoit alors cet ordre
envoyé par l’internaute.
FIGURE 4.47 – Diagramme de séquences du cas d’utilisation - Gérer son panier
Diagramme de séquences du cas d’utilisation- Effectuer une commande

Rappelons que pour passer une commande, l’internaute doit maintenant s’authentifier s’il
est déjà client, ou bien il doit créer un compte client s’il ne l’était pas.
Une fois que le client a un panier non vide, il peut passer sa commande. Il peut éventuellement
confirmer ou modifier les informations nécessaires à la livraison.
Le contrôle ControleurCommande a la responsabilité de créer la nouvelle commande, qui sera
validée par le technico-commercial.
78
79
FIGURE 4.48 – Diagramme de séquences du cas d’utilisation - Effectuer une commande

Diagramme de séquences du cas d’utilisation - Calculer la ration alimentaire
FIGURE 4.49 – Diagramme de séquences du cas d’utilisation - Calculer ration alimentaire
Le client désire calculer une ration alimentaire. Pour ce faire, il saisit les informations né-
cessaires. L’EcranCalcul vérifie les informations insérées et les envoie au ControleurCalcul. Ce
dernier, envoie ces informations à l’entité ration. Ration construit alors une collection de résul-
tats, qu’elle renvoie au contrôle ControleurCalcul. Celui-ci retourne le résultat à l’EcranCalcul.
Diagramme d’états-transitions global de la navigation de client
FIGURE 4.50 – Diagramme d’états-transitions global de la navigation de client
80
81
FIGURE 4.51 – Diagramme de classes du sprint3
Dès lors que le digramme de classes du sprint3 est accompli, nous proposons le modèle relationnel dans la partie annexe Dictionnaire
de donnees. En effet, ce modèle est basé sur une organisation des données sous forme de tables pour modéliser les informations contenues
dans une base de données.
4.3.4 Réalisation
Ci-dessous les interfaces réalisées au cours du sprint 3.

Interface - Page d’accueil
FIGURE 4.52 – Page d’accueil
La page d’accueil est certes la page la plus examinée de la plateforme. Cette page met en évi-
82
dence tous les produits disponibles et les services assurés par la société. Le client a aussi accès
aux actualités des publications des réseaux-sociaux.
Interface - Inscription
Si un visiteur souhaite profiter de toutes les fonctionnalités offertes par la plateforme, il peut
choisir le menu «S’inscrire» et une page contenant un formulaire s’affiche comme le montre la
figure suivante :
FIGURE 4.53 – Inscription
Le formulaire génère une erreur dans le cas où les champs obligatoires sont vides ou bien le
visiteur introduit des données erronées. Le visiteur doit alors remplir tous les champs indiqués.
Puis, il confirme l’inscription en cliquant sur le bouton «S’inscrire».
Interface - Authentification
FIGURE 4.54 – Authentification
Avant d’accéder à la plateforme, une fois inscrit, l’utilisateur doit s’authentifier en saisissant
83
son adresse mail et son mot de passe dans le formulaire d’inscription.

Interface - Contact
FIGURE 4.55 – Contact
Si le client veut passer une réclamation, il peut sélectionner «Contact» à partir du menu. Un
formulaire est préétabli sur cette page. En remplissant les informations nécessaires et en cliquant
sur le bouton «Envoyer», la réclamation du client est prise en compte.
Interface - Recherche et sélection des produits
Le client est capable d’effectuer une recherche sur les produits disponibles. En saisissant les
informations nécessaires dans la barre de recherche, une liste de résultats s’affiche permettant
ainsi de sélectionner le produit désiré. Le client peut aussi filtrer le résultat selon le prix.
84
FIGURE 4.56 – Recherche et sélection des produits
Interface - Gestion de panier

Le client ajoute à son panier les articles souhaités. Lorsqu’il veut consulter le contenu de
son panier, il clique sur le bouton «Voir panier». Ainsi, une page s’affiche montrant les produits
sélectionnés et le montant total à payer comme le montre la figure ci-dessous.
FIGURE 4.57 – Gestion de panier
85
De plus, une modification du contenu du panier est possible y compris la suppression, l’ajout
des produits et la modification des quantités des produits. Comme dernière étape le client peut
effectuer sa commande en choisissant le bouton «Passer commande».
Interface - Effectuer une commande
Pour passer sa commande, le client doit saisir les informations nécessaires et choisir l’adresse
de livraison.
En cliquant sur le bouton «Passer commande», la commande est enregistrée et un message de
succès est affiché.
FIGURE 4.58 – Effectuer une commande
La figure ci-jointe résume notre mêlée quotidienne du sprint3.
86
ANNEXES
4.3.6 Rétrospective de Sprint3
La figure 4.60 montre la courbe du travail effectué comparée à celle du travail idéal. On décrit
en premier lieu la réduction du nombre de fluctuations par rapport aux figures précédentes. En
effet, on s’est habitué plus facilement à l’exécution de nouvelles tâches.
De plus,les deux courbes s’approchent tellement qu’elles se superposent au bout de 16 jours
de travail. En fait, une meilleure organisation dans la réalisation des différentes opérations et
une maîtrise de la technologie employée représentent les deux facteurs principaux expliquant
l’amélioration de la quantité de travail effectué.
FIGURE 4.60 – Rétrospective de Sprint3
Conclusion
Tout au long de ce chapitre, nous avons réussi à définir les différentes phases de chaque sprint.
Nous avons pu réaliser les diagrammes de CU. Par la suite, nous avons pu mettre en œuvre la fai-
sabilité du système, en modélisant l’aspect dynamique à travers les diagrammes de séquences. Une
fois que la réalisation des diagrammes est accomplie, nous avons exposé des captures d’écran illus-
trant le bon déroulement des sprints.
En définitive, nous arrivons à la fin de ce rapport qui sera clôturé par une conclusion générale.
87
ANNEXES
Les tableaux illustrés ci-dessous, présentent un ensemble de tables dans lesquelles sont sto-
ckées les descriptions des objets de la base de données pour donner des informations sur son
contenu. En effet, on parle du dictionnaire des données qui n’est en fait que le résultat de la
phase de collecte des données.
j Table Webmaster
TABLE 4.16 – Table Webmaster
Attribut Description Clé Type
id Identité du webmaster primaire entier
nom Nom du webmaster - chaîne
prénom Prénom du webmaster - chaîne
email Courrier électronique du webmaster unique chaîne
motDePasse Mot de passe du webmaster - chaîne
image Image du webmaster - chaîne
j Table Users
TABLE 4.17 – Table Users
id Identité de l’utilisateur primaire entier
88
ANNEXES
nom Nom de l’utilisateur - chaîne
prénom Prénom de l’utilisateur - chaîne
rôle Rôle de l’utilisateur - chaîne
email Courrier électronique de l’utilisateur unique chaîne
motDePasse Mot de passe de l’utilisateur - chaîne
téléphone Téléphone de l’utilisateur - entier
image Image de l’utilisateur - chaîne
adrLivraison Adresse de livraison de l’utilisateur - chaîne
codePostal Code Postal de l’utilisateur - entier
idWebmaster Identité du webmaster étrangère- entier

primaire
j Table Newsletter
TABLE 4.18 – Table Newsletter
idNewsletter Identité de newsletter primaire entier
email Courrier électronique de l’abonné unique chaîne

primaire
j Table Avis
TABLE 4.19 – Table Avis
id Identité du commentaire primaire entier
contenu Contenu de l’avis - texte

primaire
89
ANNEXES
j Table Réclamation
TABLE 4.20 – Table Réclamation
id Identité du commentaire primaire entier
contenu Contenu de la réclamation - texte
type Type de la réclamation - chaîne

primaire
j Table Article
TABLE 4.21 – Table Article
idArticle Identité de l’article primaire entier
nom Nom de l’article - chaîne
description Description de l’article - chaîne
prix Prix de l’article - décimal
image Image de l’article - chaîne

primaire
idCategorie Identité de la catégorie étrangère- entier

primaire
j Table Catégorie
TABLE 4.22 – Table Catégorie
idCategorie Identité de la catégorie primaire entier
nom Nom de la catégorie - chaîne
90
ANNEXES
j Table Commande
TABLE 4.23 – Table Commande
idCommande Identité de la commande primaire entier
dateCommande Date de l’effectuation de la commande - date
totalCommande Montant total de la commande (approuvée - décimal

ou non)
commande Contenu de la commande - texte-

long
état État de la commande (approuvée ou non) - entier
idPanier Identité du panier étrangère- entier

primaire
j Table UsersCommande
TABLE 4.24 – Table UsersCommande
idUsers Identité de l’utilisateur étrangère- entier

primaire
idCommande Identité de la commande étrangère- entier

primaire
j Table ArticleCommande
TABLE 4.25 – Table ArticleCommande
idArticle Identité de l’article étrangère- entier

primaire
idCommande Identité de la commande étrangère- entier

primaire
91
ANNEXES
j Table Panier
TABLE 4.26 – Table Panier
idPanier Identité du panier primaire entier
donnéesPanier Contenu du panier - texte-

long
nombreArticle Nombre total d’article - entier
total Montant total de la commande - décimal
j Table lignePanier
TABLE 4.27 – Table lignePanier
idArticle Identité de l’article étrangère- entier

primaire
idPanier Identité du panier étrangère- entier

primaire
quantité Quantité de l’article - entier
montant Montant de la ligne panier - décimal
92
CONCLUSION GÉNÉRALE
Ans le cadre de notre projet de fin d’études, nous avons conçu et développé une plate-
D forme eCommerce pour la vente en ligne. Notre solution offre à la société un ensemble
de modules de base nécessaires pour bien organiser leur travail avec des interfaces utilisateur
ergonomiques, simples et cohérentes tout en assurant la facilité d’utilisation.
Ce stage nous a permis d’améliorer nos connaissances et nos compétences dans le domaine
de développement des applications Web. En effet, nous avons pu mettre en pratique nos connais-
sances théoriques et pratiques acquises durant notre parcours universitaire.
La société SNA qui nous a agréé pendant ce stage, nous a garanti une impressionnante expé-
rience pour notre parcours. Nous avons bénéficié ainsi d’une équipe de travail performante qui
a des valeurs clairement définies, des méthodes de travail efficaces, un état d’esprit d’excellence,
du respect mutuel et une forte implication des membres dans la réussite du projet.
Tout au long de la période du stage nous avons dédié une période de temps importante pour
maîtriser les outils et les technologies utilisés au niveau de notre solution. En effet, malgré les
différentes difficultés et complexités rencontrées sur le plan conceptuel et technique, nous avons
pu en profiter et enrichir encore plus nos acquis.
En considérant nos résultats encourageants, notre perspective était de continuer ce travail
permettant d’atteindre de meilleures performances.
93
RÉFÉRENCES BIBLIOGRAPHIQUES
[1] SNA. Organisme d’accueil : Présentation. <http://www.sna.com.tn/)>, 2016. [En ligne ;

accès le 16 Février 2021].
[2] actu ecommerce. Avantages d’une plateforme ecommerce. <https://actu-ecommerce.

fr/>, 2019. [ En ligne ; accès le 16 Février 2021].
[3] ARGENTAIRE. Inconvénients d’une plateforme ecommerce. <https://argentaire.com/

>, 2018. [ En ligne ; accès le 16 Février 2021].
[4] Ines Sancelot. Cycle en v en gestion de projet : définition et méthode. <https://blog.

hubspot.fr/marketing/cycle-en-v/>, 2020. [ En ligne ; accès le 20 Février 2021].
[5] Groupe Alma. Cycle en v en gestion de projet : avantages. <https://www.alma.fr/

nos-activites/>, 2020. [ En ligne ; accès le 20 Février 2021].
[6] Groupe Alma. Cycle en v en gestion de projet : inconvénients. <https://www.alma.fr/

nos-activites/>, 2020. [ En ligne ; accès le 20 Février 2021].
[7] Kahina Kabri. Méthode scrum : Présentation. <https://blog.dcube.fr/index.php/>,

2014. [ En ligne ; accès le 23 Février 2021].
[8] Pyxis. Présentation des avantages/risques de scrum. <https://pyxis-tech.com/fr/

approches-agiles/>, 2021. [ En ligne ; accès le 1 Mars 2021].
[9] SmartGecko. Langage de modélisation : définition. <https://www.smartgecko.info/

formation-details/uml-introduction/>, 2014. [ En ligne ; accès le 3 Mars 2021].
[10] Sparx Systems. Les besoins des utilisateurs : Diagrammes de packages. <https://www.
sparxsystems.fr/resources/>, 2018. [ En ligne ; accès le 3 Mars 2021].
94
ANNEXES
[11] Pierre Gérard. Les besoins des utilisateurs : Diagrammes de cas d’utilisation. <https://
lipn.univ-paris13.fr/>, 2013. [ En ligne ; accès le 3 Mars 2021].
[12] RAD Studio. L’aspect fonctionnel du logiciel : Diagrammes de classes. <http://docwiki.

embarcadero.com/RADStudio/Sydney/fr/>, 2016. [ En ligne ; accès le 3 Mars 2021].
[13] Lucidchart. L’aspect fonctionnel du logiciel : Diagrammes d’objets. <https://www.

lucidchart.com/pages/fr/diagramme-dobjets-uml>, 2020. [ En ligne ; accès le 3 Mars
2021].
[14] Autre auteur. L’aspect fonctionnel du logiciel : Diagrammes de séquence. <https://www.

ibm.com/docs/fr/>, 2012. [ En ligne ; accès le 3 Mars 2021].
[15] RAD Studio. L’aspect fonctionnel du logiciel : Diagrammes d’activités. <http://docwiki.

embarcadero.com/RADStudio/Sydney/fr/>, 2013. [ En ligne ; accès le 3 Mars 2021].
[16] Pascal Roques. L’aspect fonctionnel du logiciel : Diagrammes de collaboration. <http:

//www-public.imtbs-tsp.eu/>, 2006. [ En ligne ; accès le 3 Mars 2021].
[17] Lucidchart. L’aspect fonctionnel du logiciel : Diagrammes d’états-transition. <https://

www.lucidchart.com/pages/fr/>, 2006. [ En ligne ; accès le 3 Mars 2021].
[18] Josselin A. L’aspect fonctionnel du logiciel : Diagrammes global d’interaction. <http://

www.netforceteam.com/>, 2015. [ En ligne ; accès le 3 Mars 2021].
[19] Lucidchart. L’aspect fonctionnel du logiciel : Diagrammes de temps. <https://www.

lucidchart.com/pages/fr/langage-uml>, 2020. [ En ligne ; accès le 3 Mars 2021].
[20] Digital Guide. L’aspect lié à l’architecture du logiciel : Diagrammes de composants. <https:
//esi2cisuml.fandom.com/fr/wiki/Le_diagramme_de_structure_composite>, 2020.
[ En ligne ; accès le 3 Mars 2021].
[21] L’aspect lié à l’architecture du logiciel : Diagrammes de structure composite. <https://

esi2cisuml.fandom.com/fr/wiki/Le_diagramme_de_structure_composite>, 2020. [
En ligne ; accès le 3 Mars 2021].
[22] Lucidchart. L’aspect lié à l’architecture du logiciel : Diagrammes de déploiement. <https:

//www.lucidchart.com/pages/fr/>, 2018. [ En ligne ; accès le 3 Mars 2021].
[23] Framalibre. Visual studio code : définition. <https://framalibre.org/content/

visual-studio-code>, 2021. [ En ligne ; accès le 20 Avril 2021].
[24] Adrien Dao-Lena. Balsamiq : définition. <https://blog.zenika.com/>, 2011. [ En ligne ;

accès le 20 Avril 2021].
95
ANNEXES
[25] La Rédaction. Pacestar uml : définition. <https://www.clubic.com/>, 2021. [ En ligne ;

[26] Autre auteur. Visual paradigm : définition. <http://igm.univ-mlv.fr/>, 2020. [ En ligne ;

[27] Autre auteur. Overleaf : définition. <https://fr.overleaf.com/learn/latex/>, 2021. [

En ligne ; accès le 21 Avril 2021].
[28] Mateo. Architecture logique : définition. <https://yard.onl/sitelycee/cours/>, 2020.

[ En ligne ; accès le 1 Mai 2021].
[29] Marie pascale Delamare. Architecture physique : définition. <http://mariepascal.

delamare.free.fr/>, 2021. [ En ligne ; accès le 1 Mai 2021].
[30] La rédaction JDN. Css : définition. <https://www.journaldunet.fr/>, 2019. [ En ligne ;

accès le 20 Mai 2021].
[31] La rédaction JDN. Bootstrap : définition. <https://www.journaldunet.com/>, 2019. [ En

ligne ; accès le 20 Mai 2021].
[32] La rédaction JDN. Html : définition. <https://www.journaldunet.fr/>, 2019. [ En ligne ;

[33] La rédaction JDN. jquery : définition. <https://www.journaldunet.fr/>, 2019. [ En ligne ;

[34] Bestmomo. Laravel 8 : définition. <https://laravel.sillo.org/>, 2020. [ En ligne ; accès

le 20 Mai 2021].
[35] La rédaction JDN. Mysql : définition. <https://www.journaldunet.fr/>, 2019. [ En ligne ;

96

Langue

Version Final MM

Transféré par

Informations du document

Titre original

Copyright

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 :

Version Final MM

Transféré par

Droits d'auteur :

DÉDICACES

“ À mes parents Lotfi et Monia,

À mon frère Mohamed,

À mon amie et ma binôme Mariem,

“ À mes parents Salem et Monia,

À mes sœurs Sarah et Salma,

À mon amie et ma binôme Malek,

2 Planification et capture des besoins 19

2.1.2 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Étude et réalisation du release 39

1.1 Logo SNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Structuration en packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.7 Diagramme de déploiement de l’architecture 3 tiers . . . . . . . . . . . . . . . . 36

4.1 Diagramme de cas d’utilisation du sprint1 . . . . . . . . . . . . . . . . . . . . . . 42

4.26 Diagramme de séquences du cas d’utilisation - Supprimer un client . . . . . . . 63

4.58 Effectuer une commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

1.1 Avantages et risques de la solution Céréalerie . . . . . . . . . . . . . . . . . . . . 8

2.1 Équipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Matériels utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Backlog du Sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.13 Gérer son panier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

CMV Composés Minéreaux Vitaminés. 5

CSS Feuilles de style en cascade. 36

HTML Hypertext Markup Language. 36

IHM Interface Homme Machine. 33

MVC Modèle Vue Contrôleur. 34

PHP PHP Hypertext Preprocessor. 37

SGBDR Systèmes de Gestion de Base de Données Relationnels. 38

SNA Société de Nutrition Animale. 4, 10

UML Langage de Modélisation Unifié. 11, 16, 24

Dans le cadre de notre Licence Fondamentale en Science de l’Informatique à l’Institut Supé-

Le premier chapitre intitulé «Etude préalable» comporte la description de l’organisme d’accueil

Le troisième chapitre intitulé «Sprint0» détermine la vue architecturale et conceptuelle globale

1.1 Cadre et contexte du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Cadre du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Analyse concurrentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.1 Etude des solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.2 Bilan et synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.6 Gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.6.1 Méthodologies de développement de logiciel . . . . . . . . . . . . . . . . 12

1.6.2 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.1 Cadre et contexte du sujet

1.1.1 Cadre du sujet

1.1.2 Présentation du sujet

1.2 Organisme d’accueil

FIGURE 1.1 – Logo SNA

SNA assure un élevage gagnant, ses principales activités sont :

j Offrir une assistance et un suivi dans sa gamme de CMV.

j Pour les entreprises :

k Mise à la disposition d’une vaste clientèle illimitée géographiquement ;

k Exposer ses produits de manière distincte ;

k Se développer sur de nombreux marchés ;

k Assurer l’interactivité entre l’entreprise et ses clients (sons, images,vidéos,etc).

j Pour les internautes :

k Chercher le meilleur prix ;

k Accéder au magasin de n’importe où dans le monde, 24h/24 et 7j/7 ;

k Comparer directement les prix des articles ;

k Passer sa commande à tout moment de la journée ;

k Accomplir un marquage avant d’acheter en magasin.

Les limites de cette solution sont [3] :

j Pour les entreprises :