Rapport de Projet

3ème année
Ingénierie Informatique et Réseaux

Sous le thème

StockMaster – Système de gestion des stocks

Réalisé par :

- EL OUALFI Meriem
- BOUTARFA Wafae
- AAYD Amjad

Encadré par :

- Pr. OUADOUD Oumaima

Année universitaire 2024/2025

Année universitaire 2024/2025
 Dédicaces

Nous dédions ce travail à toutes celles et ceux qui, de près ou de

loin, ont contribué à sa concrétisation.

À nos enseignants, pour la qualité de leur supervision, leur écoute

attentive et leurs conseils judicieux qui ont jalonné notre parcours.
Leur soutien a été un pilier de notre progression.

À nos camarades de promotion et partenaires de projet, pour

leur esprit collaboratif, leur implication sans faille et leur appui
constant durant les phases de conception et d'analyse.

À nos amis, pour leurs encouragements précieux et leur présence

stimulante, notamment dans les moments d'incertitude.

Enfin, à toute personne ayant participé, même de manière indirecte,

à l'aboutissement de cette œuvre, nous exprimons notre profonde
gratitude.

Ce projet est le résultat d'un effort collectif, et cette dédicace est le

témoignage de notre reconnaissance envers tous ceux qui nous ont
épaulés.

i
 Remerciement

Nous tenons à exprimer nos sincères remerciements à toutes les

personnes qui ont contribué à la réalisation de ce projet.

Nos remerciements vont en premier lieu à Madame OUADOUD

Oumaima, notre encadrante, pour son accompagnement, sa
disponibilité et ses conseils précieux tout au long de ce travail. Sa
rigueur et son implication ont été d’un grand soutien.

Nous remercions également l’ensemble du corps enseignant et

administratif de l’École Marocaine des Sciences de
l’Ingénieur de Rabat, pour la qualité de la formation qu’ils nous
ont dispensée et pour l’encadrement pédagogique dont nous avons
bénéficié tout au long de notre parcours.

Nous adressons aussi nos remerciements à nos camarades de classe

et collègues de projet pour leur esprit d’équipe, leur entraide et
leur collaboration.

Enfin, nous remercions toutes les personnes qui, de près ou de loin,

ont contribué à l’aboutissement de ce projet. Votre soutien nous a
été précieux.

Merci à toutes et à tous.

ii
 Résumé

Le projet StockMaster vise à développer une application web pour

la gestion des stocks au sein des entreprises commerciales et
industrielles.
Actuellement, la gestion manuelle des stocks entraîne souvent des
ruptures ou du surstockage, causant des pertes financières.
Le système proposé permettra de centraliser, suivre en temps réel,
et automatiser la gestion des stocks, des commandes et des
fournisseurs.
L'application sera développée en Python à l'aide d'un framework
Django, avec une base de données MySQL. Le projet suit plusieurs
étapes : analyse des besoins, conception technique, développement,
tests et déploiement final. L'objectif principal est d'optimiser la
gestion des stocks, d'améliorer la performance des entreprises et
d'offrir une plateforme intuitive, sécurisée et innovante.

Mots clés : Gestion des stocks, Application web, StockMaster,

Automatisation, Suivi en temps réel, Python, Django, MySQL,
Optimisation, Entreprises, Gestion des commandes, Gestion des
fournisseurs, Plateforme intuitive, Sécurité.

Abstract

iii
The StockMaster project aims to develop a web application for
efficient stock management within commercial and industrial
enterprises.
Current manual stock management practices often result in
stockouts or overstocking, leading to financial losses.
The proposed system will enable centralization, real-time tracking,
and automation of stock, order, and supplier management.
The application will be developed using Python with the Django
framework and a MySQL database. The project encompasses
several phases: requirements analysis, technical design,
development, testing, and final deployment. The primary objective
is to optimize stock management, enhance business performance,
and provide an intuitive, secure, and innovative platform.

Keywords: Stock Management, Web Application, StockMaster,

Automation, Real-time Tracking, Python, Django, MySQL,
Optimization, Enterprise Software, Order Management, Supplier
Management.

iv
 Table des matières

Table des matières

vi
 Liste des figures

Liste des figures

Figure 1 : Le processus de développement Y..........................................................................................8
Figure 2 : Diagramme de Gantt............................................................................................................11
Figure 3 : Diagramme des cas d'utilisation...........................................................................................35
Figure 4 : Diagramme de classe............................................................................................................38
Figure 5 : Diagramme de séquence ''Admin valide les commandes ''..................................................39
Figure 6 : Diagramme de séquence ''Admin gère les clients''...............................................................40
Figure 7 : Diagramme de séquence ''Admin gère les fournisseurs''.....................................................41
Figure 8 : Admin génère les rapports...................................................................................................42
Figure 9 : Diagramme de séquence ''Admin gère les catalogues produits''..........................................43
Figure 10 : Diagramme de séquence ''Admin surveille le stock ''.........................................................44
Figure 11 : Diagramme de séquence ''Le client modifie son profile ''...................................................45
Figure 12 : Diagramme de séquence ''Le client consulte l'historique''.................................................46
Figure 13 : Diagramme de séquence ''Le client passe une commande ''..............................................46
Figure 14 : Diagramme de séquence ''Le fournisseurs enregistre une livraison ''................................47
Figure 15 : Diagramme de séquence ''Le fournisseur propose des produits''......................................48
Figure 16 : Diagramme de séquence ''Le fournisseur met à jour ces coordonnées''............................49
Figure 17 : Diagramme de séquence ''Le fournisseur suit les retards''.................................................49

xi
 Liste des tableaux

Liste des tableaux

Tableau 1 : Tableau des Taches..............................................................................................................9
Tableau 2 : Les principales fonctionnalités du module ‘Nom du site’...................................................28

xiv
 Liste des abréviations

Liste des abréviations

xxv
Introduction Générale

1
 Introduction générale

D
ans un environnement commercial et industriel de plus en plus compétitif et dynamique, la
gestion efficace des stocks est devenue un levier stratégique majeur pour la pérennité et la
croissance des entreprises. Une maîtrise optimisée des flux de marchandises permet non
seulement de réduire les coûts opérationnels, mais aussi d'améliorer la satisfaction client et la réactivité face
aux fluctuations de la demande.
Cependant, de nombreuses organisations, notamment les petites et moyennes structures, s'appuient encore
sur des méthodes manuelles ou des outils rudimentaires pour cette gestion cruciale. Ces approches
traditionnelles sont souvent sources d'erreurs, de retards, et conduisent à des déséquilibres coûteux tels que
les ruptures de stock, pénalisant les ventes, ou, à l'inverse, le surstockage, immobilisant inutilement du
capital et augmentant les risques d'obsolescence.

C'est dans cette optique que s'inscrit notre projet, baptisé « StockMaster ». Il vise à répondre à cette
problématique en proposant le développement d'une application web dédiée à la gestion des stocks. Le but
principal de ce projet est de concevoir et de réaliser une solution logicielle permettant de centraliser les
informations, d'offrir un suivi en temps réel des niveaux de stock, et d'automatiser certains processus liés
aux entrées, sorties, commandes et fournisseurs. L'ambition est de fournir aux entreprises un outil
performant, intuitif et sécurisé, contribuant ainsi à une meilleure prise de décision, à une réduction des
pertes financières et à une amélioration globale de la performance opérationnelle.

Ce rapport vous accompagnera à travers trois chapitres pour mieux comprendre la démarche adoptée,
l'analyse effectuée et la solution développée pour répondre aux besoins identifiés.

Dans le premier chapitre, intitulé « Contexte Général », nous commencerons par présenter plus en détail le
contexte général de la gestion des stocks en entreprise, en soulignant ses enjeux et les défis rencontrés.
Nous définirons ensuite clairement la problématique à laquelle notre projet entend répondre, et nous
exposerons les objectifs spécifiques fixés pour l'application StockMaster. Une analyse des besoins
fonctionnels et non fonctionnels sera également détaillée.

Dans le deuxième chapitre, « Modélisation et Implémentation », nous allons voir en détail les
fonctionnalités du projet afin de spécifier les langages et technologies qui seront utilisés pour la réalisation
de l’application, notamment Python avec le framework Django et une base de données MySQL. Nous
présenterons ensuite le processus de développement sur lequel nous nous sommes basés pour organiser et
planifier notre projet, puis la conception de notre système d'information que nous avons modélisé en UML,
incluant les diagrammes de cas d'utilisation, de classes et le schéma de la base de données.

Enfin, dans le troisième chapitre, « Réalisation et Interfaces de l'Application », nous présenterons toutes
les interfaces et le fonctionnement de l’application StockMaster, accompagnée d’une description de
chacune d’elles. Des captures d'écran illustreront les différentes fonctionnalités implémentées et la manière
dont elles interagissent pour offrir une expérience utilisateur cohérente et efficace.

2
 Chapitre 1 : Contexte Générale

Chapitre 1 : Contexte
générale

3
 Chapitre 1 : Contexte Générale

Introduction
Ce premier chapitre est consacré à l'établissement du cadre général et des fondations sur
lesquelles repose l'intégralité du projet StockMaster. Avant de plonger dans les aspects
techniques de la conception et du développement, il est primordial de bien cerner la
problématique qui a motivé cette initiative, de comprendre le contexte dans lequel elle
s'inscrit, et d'expliciter la démarche méthodologique qui a guidé nos efforts.
Ce chapitre vise donc à fournir au lecteur une vision claire des origines, des justifications et
de l'organisation initiale du projet, éléments indispensables pour appréhender la pertinence et
la structuration de la solution proposée. Nous y explorerons ainsi les motivations derrière
StockMaster et la manière dont nous avons planifié sa concrétisation.

1. Présentation du projet

Cette section a pour objectif d'introduire le projet StockMaster, en commençant par une
analyse du contexte actuel de la gestion des stocks et des lacunes des systèmes ou
méthodes existants. Cette analyse justifie la nécessité et la pertinence de la solution que
nous proposons.

1.1 Etude de l’existant

Avant de détailler la solution StockMaster, il est essentiel de comprendre l'environnement

actuel de la gestion des stocks dans les entreprises cibles et d'identifier les pratiques
courantes ainsi que leurs limitations.

 Description de L’existant

Actuellement, la gestion des stocks au sein de nombreuses entreprises commerciales et

industrielles, particulièrement les petites et moyennes entreprises (PME) ou les structures
de taille intermédiaire, repose souvent sur des méthodes manuelles ou des outils
informatiques basiques et non intégrés.
On observe fréquemment l'utilisation de :
 Systèmes manuels et papier : Utilisation de fiches de stock cartonnées, de registres
manuscrits pour les entrées/sorties, de bons de commande et de livraison remplis à la
main. Le suivi est souvent effectué de manière périodique (inventaires physiques
sporadiques) plutôt qu'en continu. La communication entre les différents acteurs

4
 Chapitre 1 : Contexte Générale

(magasinier, service achat, service commercial) se fait par des échanges verbaux ou
des documents papier.
 Fichiers tableurs (Excel, Google Sheets, etc.) : Beaucoup d'entreprises utilisent des
tableurs pour lister leurs articles, suivre les quantités, et parfois calculer les valeurs
de stock. Bien que plus structurés que le papier, ces systèmes atteignent vite leurs
limites en termes de volume de données, de partage d'informations en temps réel, de
sécurité des données, et de complexité des formules pour des analyses avancées. Les
mises à jour sont souvent manuelles et peuvent être effectuées par plusieurs
personnes sans véritable contrôle de cohérence.
 Logiciels de gestion généralistes ou modules de base d'ERP : Certaines
entreprises disposent de logiciels de comptabilité ou de gestion commerciale incluant
un module de gestion de stock basique. Cependant, ces modules peuvent manquer de
fonctionnalités spécifiques, de flexibilité pour s'adapter aux processus métier
particuliers, ou ne pas offrir une granularité suffisante pour un suivi précis (par
exemple, gestion des lots, dates de péremption, emplacements multiples).
 Absence de centralisation : Les informations peuvent être dispersées entre
différents services ou différents outils, rendant difficile l'obtention d'une vue
d'ensemble consolidée et fiable de l'état des stocks.

 Critique de l’existant

Les méthodes de gestion des stocks décrites ci-dessus présentent plusieurs

inconvénients et limitations significatifs qui impactent négativement la performance et
la rentabilité des entreprises :
 Manque de visibilité en temps réel : L'information sur les niveaux de stock n'est
souvent pas à jour, ce qui empêche une prise de décision rapide et éclairée
concernant les réapprovisionnements ou les disponibilités pour les clients.
 Risque élevé d'erreurs humaines : La saisie manuelle des données, que ce soit
sur papier ou dans des tableurs, est intrinsèquement sujette aux erreurs (omissions,
fautes de frappe, doublons), conduisant à des inventaires inexacts.
 Pertes de temps et d'efficacité : Les processus manuels sont chronophages et
mobilisent des ressources humaines qui pourraient être affectées à des tâches à
plus forte valeur ajoutée. La recherche d'informations peut être longue et
fastidieuse.

5
 Chapitre 1 : Contexte Générale

 Difficulté de planification et de prévision : L'absence de données fiables et

centralisées rend difficile l'analyse des tendances de consommation, la prévision de
la demande, et donc l'optimisation des niveaux de stock.
 Conséquences financières directes :
o Ruptures de stock : Un mauvais suivi peut entraîner des
ruptures, se traduisant par des ventes perdues, des retards de
production, et une dégradation de la satisfaction client.
o Surstockage : La crainte de manquer, combinée à une mauvaise
visibilité, peut conduire à un surstockage. Cela immobilise
inutilement du capital, augmente les coûts de stockage (espace,
assurance, manutention) et accroît les risques d'obsolescence ou
de péremption des produits.
 Manque de traçabilité : Il est souvent difficile de suivre l'historique complet d'un
article (date d'entrée, fournisseur, lot, date de sortie), ce qui est problématique pour
la gestion de la qualité ou les rappels de produits.
 Difficulté de collaboration : Les informations non centralisées et non partagées
en temps réel entravent la coordination entre les différents services (achats, ventes,
logistique).

 Solution de l’existant

Face à ces constats et pour pallier les insuffisances des systèmes existants, notre
projet, StockMaster, propose le développement d'une application web moderne et dédiée à
la gestion des stocks. Cette solution vise à offrir aux entreprises une plateforme
centralisée, intuitive et performante, capable d'automatiser et de fiabiliser le suivi des flux,
d'offrir une visibilité en temps réel sur les niveaux de stock, les mouvements et la valeur
de l'inventaire. StockMaster ambitionne ainsi d'optimiser les processus de commande
auprès des fournisseurs et de gestion des réapprovisionnements, tout en réduisant
significativement les erreurs grâce à des interfaces de saisie contrôlées et une base de
données unique et cohérente. En facilitant la prise de décision par la mise à disposition de
rapports clairs et d'indicateurs clés de performance, et en améliorant la collaboration entre
les différents utilisateurs et services de l'entreprise, cette application est conçue pour être
un véritable levier d'efficacité opérationnelle. Elle sera accessible via un navigateur web,
assurant une facilité de déploiement et d'accès, et s'appuiera sur des technologies robustes
comme Python avec le framework Django et une base de données MySQL pour garantir
sa fiabilité et sa capacité d'évolution

6
 Chapitre 1 : Contexte Générale

2. Organisation du projet

Une gestion de projet structurée est essentielle pour assurer la réussite du développement
d'une application telle que StockMaster. Cette section détaille la méthodologie de
développement choisie ainsi que la planification opérationnelle mise en œuvre.

2.1 Processus de Développement

Pour la conduite de notre projet StockMaster, nous avons opté pour le processus de
développement 2TUP (Two-Track Unified Process). Ce choix a été motivé par sa capacité
à concilier une approche rigoureuse de la conception architecturale avec la flexibilité du
développement itératif des fonctionnalités. Le 2TUP est particulièrement adapté aux
projets où la robustesse de l'architecture est un enjeu clé, tout en permettant des livraisons

incrémentales et une adaptation aux besoins qui peuvent évoluer.

 Processus 2TUP

Le processus 2TUP, ou "Processus Unifié à Deux Chemins", est une méthode de

développement logiciel qui se distingue par la séparation et la synchronisation de deux
axes (ou "chemins", "pistes", "branches") principaux de travail, complétés par un axe de
pilotage :
1. La Branche "Capture et Réalisation Technique" (ou Axe Technique) :
Cette branche se concentre sur la définition, la construction et la validation de
l'architecture logicielle du système. Son objectif est de s'assurer que les fondations
techniques sont solides, stables et capables de supporter l'ensemble des
fonctionnalités attendues. Elle permet de lever les risques techniques majeurs le
plus tôt possible dans le cycle de vie du projet. Les activités typiques incluent
l'identification des contraintes techniques, la sélection des technologies, la
conception de l'architecture (composants, interfaces, infrastructure), et la
réalisation de preuves de concept ou de prototypes architecturaux.
2. La Branche "Capture et Réalisation Fonctionnelle" (ou Axe Fonctionnel) :
Cette branche est dédiée au développement incrémental des fonctionnalités du
système, en s'appuyant sur l'architecture établie par la branche technique. Elle suit
une approche itérative, où chaque itération vise à produire une version du logiciel
enrichie de nouvelles fonctionnalités testées et potentiellement livrables. Les
activités comprennent l'analyse des besoins utilisateurs, la spécification

7
 Chapitre 1 : Contexte Générale

fonctionnelle, la conception détaillée des fonctionnalités, leur implémentation, et

les tests associés.
3. La Branche "Pilotage" (ou Axe de Gestion de Projet) :
Transversale aux deux autres, cette branche assure la gestion globale du projet :
planification, suivi de l'avancement, gestion des risques, gestion de la qualité,
gestion des configurations, communication et coordination entre les équipes et les
parties prenantes.

L'interaction entre ces branches est cruciale. L'architecture guide le développement

fonctionnel, tandis que les retours du développement fonctionnel peuvent influencer et
affiner l'architecture. Le processus 2TUP favorise ainsi une approche équilibrée, réduisant
les risques d'une architecture inadaptée découverte tardivement, tout en maintenant
l'agilité nécessaire pour répondre aux besoins fonctionnels.

Figure 1 : Le processus de développement Y

2.2 Planification Opérationnelle

2.2.1 Tableau des tâches

8
 Chapitre 1 : Contexte Générale

Tableau 1 : Tableau des Taches

Tâche Désignation Prédécesseur Durée Durée Durée Durée
optimiste normal pessimiste moyenne
A Tâche 1 4 6 7 6
(Formation du
groupe)
B Tâche 2 (Analyse A 7 8 11 8
des besoins
utilisateurs)
C Tâche 3 B 6 7 8 7
(Présentation du
projet)
D Tâche 4 C 6 7 9 7
(Préparation de
la
documentation)
E Tâche 5 B 6 7 9 7
(Modélisation
des données)
F Tâche 6 E 8 10 12 10
(Développement
de la base de
données)
G Tâche 7 E,F 8 13 9 12
(Intégration des
fonctionnalités)
H Tâche 8 (Test des G 10 11 12 11
fonctionnalités)
I Tâche 9 (Codage) H 10 11 15 12
J Tâche 10 (Test de I 5 6 7 6
l’application)

NB : La valeur de la durée moyenne Dpk est calculée par la loi Bêta [40] :

D. opt +4 D. nor + D . pess

Dpk=
6

Description des Tâches

 Tâche A – Formation du groupe

Cette première étape consiste à constituer l’équipe projet, clarifier les rôles de chacun
et poser les bases de la collaboration.
 Tâche B – Analyse des besoins utilisateurs
Elle vise à recueillir et formaliser les attentes et les exigences fonctionnelles des
utilisateurs finaux.

9
 Chapitre 1 : Contexte Générale

 Tâche C – Présentation du projet

Cette tâche consiste à élaborer une synthèse des objectifs, du périmètre et des livrables
du projet pour les parties prenantes.
 Tâche D – Préparation de la documentation
Rédaction des documents nécessaires à la bonne compréhension et à la gestion du
projet (cahier des charges, spécifications, etc.).
 Tâche E – Modélisation des données
Conception du modèle de données pour structurer les informations manipulées par
l’application.
 Tâche F – Développement de la base de données
Implémentation de la base de données selon le modèle validé, avec création des tables,
relations et contraintes.
 Tâche G – Intégration des fonctionnalités
Développement des différentes fonctionnalités principales de l'application selon les
spécifications définies.
 Tâche H – Test des modules
Vérification unitaire des modules développés pour garantir leur bon fonctionnement
avant l’intégration finale.
 Tâche I – Codage
Phase de codage complète de l’application, regroupant les modules testés et validés,
avec respect des normes de développement.
 Tâche J – Test de l’application
Tests globaux de l’application (fonctionnels, ergonomiques, de performance) pour
s'assurer de sa conformité aux besoins utilisateurs.

2.2.2 Diagramme de GANTT

Le diagramme de Gantt permet de visualiser de manière chronologique la planification

des différentes tâches du projet, en tenant compte de leurs durées estimées et de leurs
dépendances.
Dans ce projet, le diagramme a été construit à partir des durées moyennes de chaque
tâche, calculées à partir des durées optimistes, normales et pessimistes fournies. Le point
de départ du projet est fixé au 18 mars 2025.

10
 Chapitre 1 : Contexte Générale

Chaque barre horizontale représente une tâche, positionnée selon sa date de début et sa
durée. Les dépendances entre les tâches sont respectées, de sorte qu'une tâche ne peut
commencer que lorsque toutes ses tâches prédécesseures sont terminées.

Figure 2 : Diagramme de Gantt

Conclusion
ce premier chapitre a permis de poser les fondations de notre projet StockMaster. Nous avons
commencé par présenter le projet et son contexte, en effectuant une étude de l'existant pour
identifier les lacunes des systèmes actuels et justifier ainsi la nécessité de notre solution. Par
la suite, nous avons détaillé l'organisation mise en place pour mener à bien ce projet, en
expliquant notre choix pour le processus de développement 2TUP et en présentant notre
planification.

11
 Chapitre 2 : Analyse & conception

Chapitre 2 : Analyse &

Conception

24
 Chapitre 2 : Analyse & conception

Introduction
Après avoir établi, dans le chapitre précédent, le contexte général, la problématique et
l'organisation de notre projet StockMaster, ce deuxième chapitre est consacré à la phase
cruciale d'analyse et de conception. C'est ici que nous allons traduire les besoins identifiés et
les objectifs fixés en une spécification détaillée du système à construire, puis en une
architecture logicielle et une structure de données concrètes.

Ce chapitre est donc le pont entre la compréhension du problème et la définition technique de

la solution. Nous y détaillerons les fonctionnalités attendues, modéliserons les interactions des
utilisateurs et la structure interne de l'application, afin de fournir un plan directeur clair et
précis pour la phase de réalisation qui suivra.

1. Description des besoins fonctionnels

La définition claire des besoins fonctionnels est une étape primordiale pour s'assurer que
l'application StockMaster répondra efficacement aux attentes des utilisateurs et aux objectifs
du projet. Cette section détaille les fonctionnalités que le système devra offrir pour résoudre la
problématique identifiée.

1.1 Périmètre de projet

Ce travail a pour objectif de développer une application web, StockMaster, capable de :

 Automatiser les tâches de la gestion des stocks, incluant le suivi précis des entrées et
sorties de marchandises, ainsi que la gestion des niveaux d'alerte pour anticiper les
réapprovisionnements.
 Fournir une visibilité en temps réel et centraliser les informations concernant l'état des
stocks, les fiches articles (descriptions, références, prix), les données fournisseurs et
l'historique des commandes.
 Optimiser le processus de gestion des commandes fournisseurs, depuis la demande
d'achat jusqu'à la réception des articles, en assurant une traçabilité complète.
 Faciliter la prise de décision opérationnelle grâce à des outils de reporting basiques (par
exemple, état des stocks, historique des mouvements, articles à faible rotation) et une
meilleure traçabilité des flux de marchandises.

25
 Chapitre 2 : Analyse & conception

 Offrir une interface utilisateur intuitive et sécurisée, permettant une prise en main rapide
par les différents utilisateurs et garantissant la confidentialité et l'intégrité des données.

1.2 Description de la structure générale du site

StockMaster est conçu pour offrir une expérience utilisateur ciblée et sécurisée, structurée
autour de pages publiques informatives et d'espaces dédiés à ses trois principaux types
d'utilisateurs après authentification : l'Administrateur, le Fournisseur, et le Client.
1.3 Pages Publiques :
a. Page d'accueil : Présentation de la solution StockMaster et de ses bénéfices pour la
gestion des stocks.
b. Page "Fonctionnalités" : Détail des capacités offertes par StockMaster.
c. Page de contact / Support : Moyens de joindre l'équipe StockMaster.
d. Accès à l'espace de connexion/inscription.
1.4 Espace d’authentification :
Tous les utilisateurs (Administrateurs, Fournisseurs, Clients) doivent s'authentifier avec
un identifiant (Email) et un mot de passe pour accéder à leurs espaces respectifs. Chaque
utilisateur pourra gérer ses informations de profil.
a. Espace Administrateur :
Cet espace est le centre de contrôle pour l'utilisateur principal de l'entreprise gérant ses
stocks avec StockMaster. Il permet :
1. Le paramétrage global du compte entreprise (informations, préférences).
2. La gestion complète du catalogue d'articles (création, modification, suppression,
catégorisation, prix, seuils d'alerte).
3. La gestion des fournisseurs (création de comptes fournisseurs, gestion des
informations de contact et conditions).
4. La gestion des clients (création de comptes clients, gestion des informations).
5. Le suivi intégral des mouvements de stock (entrées, sorties, transferts).
6. La création et le suivi des bons de commande auprès des fournisseurs.
7. La gestion des commandes clients (si l'application inclut cette fonctionnalité).
8. La réalisation et la validation des inventaires.
9. La génération de rapports d'analyse (état des stocks, rotation, valeur, etc.).
10. La gestion des autres utilisateurs internes si l'admin peut créer des sous-comptes
(magasinier, etc.) avec des droits restreints (cela peut être une fonctionnalité
avancée de l'admin).

26
 Chapitre 2 : Analyse & conception

b. Espace Fournisseur :
Dédié aux partenaires fournisseurs de l'entreprise, cet espace leur permet de :
1. Consulter les bons de commande qui leur ont été adressés par l'entreprise (via
l'Admin).
2. Mettre à jour le statut de traitement de ces commandes (ex : "En préparation",
"Expédiée").
3. Soumettre des informations de livraison (date estimée, numéro de suivi).
4. Consulter l'historique des commandes traitées.
5. Gérer leurs informations de profil et de contact.
6. (Optionnel) Proposer des mises à jour de catalogue ou de prix (soumis à
validation par l'Admin).
c. Espace Client :
Conçu pour les clients de l'entreprise, cet espace leur offre la possibilité de :
[Link] le catalogue des produits disponibles (géré par l'Admin).
[Link] des commandes directement via la plateforme (si applicable).
[Link] l'état de leurs commandes en cours (ex : "Validée", "En préparation",
"Expédiée").
[Link] leur historique de commandes.
5.Gérer leurs informations personnelles, adresses de livraison et de facturation.
6.(Optionnel) Accéder à des factures ou des bons de livraison.

1.5 Fonctionnalités de projet

Après avoir identifié les besoins généraux et les acteurs de notre application StockMaster, il
est maintenant nécessaire de détailler plus précisément les fonctionnalités spécifiques que le
système offrira. Ces fonctionnalités découlent directement des besoins exprimés et des
objectifs du projet.

27
 Chapitre 2 : Analyse & conception

Tableau 2 : Les principales fonctionnalités du module ‘Nom du site’

Fonctionnalités Description

Permet d'ajouter, de modifier, de supprimer et de consulter les produits

Gestion des produits
du stock.

Permet d'enregistrer et de gérer les informations sur les fournisseurs, y

Gestion des fournisseurs compris leurs commandes.

Suivi des commandes passées par les clients et reçues des fournisseurs,
Suivi des commandes
avec état de la commande.
Création et gestion des profils d’utilisateurs avec gestion des rôles et
Gestion des utilisateurs
des permissions.
Rapports de stock Génération de rapports détaillés sur les niveaux de stock, les ventes, les
achats et autres indicateurs.
Envoi d’alertes pour les stocks faibles, les retards de commande, ou
Alertes et notifications toute autre situation critique.

Vue d'ensemble du système avec les informations clés, les indicateurs

Tableau de bord
et les alertes.
Permet aux utilisateurs de rechercher et de filtrer les produits et
Recherche et filtres
commandes selon divers critères.

[Link] des besoins ergonomiques

Au-delà des fonctionnalités pures, l'ergonomie de l'application StockMaster est un facteur clé
de son succès et de son adoption par les utilisateurs. Une interface bien conçue, intuitive et
agréable à utiliser permet de réduire le temps d'apprentissage, de minimiser les erreurs et
d'augmenter la productivité et la satisfaction des utilisateurs. Cette section se concentre sur les
principes et les règles qui guideront la conception de l'interface utilisateur (UI) et de
l'expérience utilisateur (UX) de StockMaster.

2.1 Définir les règles ergonomiques

La conception de StockMaster s'appuiera sur des principes ergonomiques fondamentaux pour

garantir une expérience utilisateur de qualité. Nous veillerons notamment à :

28
 Chapitre 2 : Analyse & conception

Assurer un guidage clair : L'application utilisera un langage simple et des libellés explicites.
Un feedback constant sera fourni à l'utilisateur pour l'informer du résultat de ses actions et de
l'état du système. La lisibilité des informations sera une priorité.
Optimiser la charge de travail : Les interfaces seront conçues pour présenter uniquement les
informations pertinentes à la tâche en cours, évitant ainsi toute surcharge cognitive. La saisie
de données sera minimisée grâce à des mécanismes tels que les listes déroulantes ou les
valeurs par défaut lorsque cela est pertinent.
Garantir le contrôle de l'utilisateur : Les actions critiques (suppressions, validations
importantes) nécessiteront une confirmation. L'utilisateur devra sentir qu'il maîtrise ses
interactions avec le système.
Maintenir la cohérence et la standardisation : Une charte graphique et ergonomique
définira l'apparence et le comportement des éléments d'interface (boutons, menus,
formulaires) afin d'assurer une homogénéité à travers toute l'application. L'utilisation de
conventions reconnues facilitera la familiarisation.
Prévenir et gérer les erreurs : La conception visera à anticiper et à prévenir les erreurs de
saisie ou de manipulation. En cas d'erreur, des messages clairs et constructifs guideront
l'utilisateur vers une solution.

2.2 Formaliser une charte ergonomique

Afin de formaliser ces intentions et de garantir leur application cohérente tout au long du
développement, une charte ergonomique sera établie pour StockMaster.
Cette charte servira de document de référence pour la conception des interfaces. Elle précisera
les standards à respecter concernant :
La structure générale des pages : Définition des zones principales (en-tête, menu, zone de
contenu, pied de page) et leur disposition.
La navigation : Principes de navigation entre les différentes sections de l'application pour
chaque profil utilisateur.
La présentation visuelle de l'information : Règles pour l'affichage des listes, des tableaux
de données, et la hiérarchisation des informations.
Les composants d'interface : Spécification de l'apparence et du comportement des éléments
interactifs clés (boutons, champs de formulaire, messages de notification, icônes).
Les interactions et le feedback : Définition des réponses du système aux actions de
l'utilisateur pour une expérience fluide.

29
 Chapitre 2 : Analyse & conception

[Link] des besoins graphiques

L'identité visuelle de StockMaster sera conçue pour véhiculer professionnalisme, clarté et

fonctionnalité, en accord avec son rôle d'outil de gestion d'entreprise. Nous opterons pour une
esthétique épurée et moderne, privilégiant une palette de couleurs sobre et professionnelle,
dominée par des nuances neutres comme le bleu ou le gris, rehaussée par des couleurs
d'accentuation ciblées pour les appels à l'action et les alertes. La typographie sera choisie pour
sa lisibilité optimale, avec des polices sans-serif modernes et une hiérarchie claire pour
structurer l'information. Un jeu d'icônes significatives et au style cohérent facilitera la
reconnaissance des fonctionnalités, tandis qu'une mise en page structurée et aérée, respectant
des principes de grille et des espacements suffisants, garantira une bonne organisation
visuelle. L'apparence des composants d'interface, tels que les boutons, formulaires et tableaux,
sera standardisée pour assurer une expérience utilisateur intuitive et homogène.

[Link] des besoins techniques

4.1 Outils de développement

Le développement de l'application StockMaster s'est appuyé sur un ensemble d'outils et de

technologies choisis pour leur efficacité, leur robustesse et leur capacité à répondre aux
exigences d'un projet web moderne. Ces outils ont facilité les différentes phases de
conception, de codage, et de gestion des données. Voici une description des principaux
éléments de notre environnement de développement :

 Visual Studio Code (VS Code)

Un éditeur de code source polyvalent et léger, qui a servi d'environnement de

développement principal pour l'écriture et le débogage du code de l'application, grâce à
ses nombreuses extensions et fonctionnalités intégrées.

30
 Chapitre 2 : Analyse & conception

 Python

Ce langage de programmation de haut niveau, reconnu pour sa syntaxe claire et sa

vaste bibliothèque standard, a été utilisé comme langage principal pour le
développement de toute la logique métier et du backend de StockMaster.

 Django

En tant que framework web Python de haut niveau, Django a fourni la structure et les
outils nécessaires pour un développement rapide et organisé de l'application. Il a
notamment facilité la gestion des modèles de données, des vues et des templates, ainsi
que la sécurité et l'administration du site.

 MySQL

Ce système de gestion de bases de données relationnelles open source a été utilisé pour
stocker de manière persistante toutes les données de l'application StockMaster, telles
que les informations sur les articles, les stocks, les utilisateurs et les transactions.

 HTML (HyperText Markup Language)

31
 Chapitre 2 : Analyse & conception

Ce langage de balisage standard a été employé pour structurer le contenu sémantique

de toutes les pages web de l'application, formant le squelette de chaque interface
utilisateur.

 CSS (Cascading Style Sheets)

Ce langage de feuille de style a permis de définir l'apparence visuelle et la présentation

des pages HTML de StockMaster, en contrôlant la mise en page, les couleurs, les
polices et autres aspects esthétiques.

 Bootstrap

Ce framework CSS front-end a été intégré pour accélérer le développement des

interfaces utilisateur. Il a fourni un système de grille responsive et des composants
préconçus, permettant de créer rapidement des pages web modernes, adaptatives et
esthétiques.

[Link]élisation UML

Pour la phase d'analyse et de conception de notre projet StockMaster, nous avons eu recours à
la modélisation UML (Unified Modeling Language). UML est un langage de modélisation
graphique standardisé, largement utilisé en ingénierie logicielle pour spécifier, visualiser,

32
 Chapitre 2 : Analyse & conception

construire et documenter les artefacts d'un système logiciel. L'objectif principal de l'utilisation
d'UML dans ce projet est de fournir une représentation claire et non ambiguë de la structure et
du comportement de l'application StockMaster, facilitant ainsi la compréhension commune
entre les membres de l'équipe et servant de base solide pour la phase d'implémentation.
Les résultats obtenus grâce à UML sont une meilleure compréhension des besoins, une
conception plus structurée et une documentation visuelle du système [1].
UML propose un ensemble de diagrammes, chacun offrant une vue spécifique du système.
Une vue peut être constituée d'un ou de plusieurs diagrammes. On distingue principalement
deux types de vues :
 Les vues statiques, qui représentent la structure physique et logique du système à un
instant donné. Elles décrivent les éléments du système et leurs relations. Les principaux
diagrammes statiques que nous avons considérés ou utilisés incluent :
o Diagramme de cas d'utilisation (pour décrire les fonctionnalités du point de vue de
l'utilisateur)
o Diagramme de classes (pour décrire la structure des objets et leurs relations)
o Diagramme d'objets (pour montrer des instances de classes à un moment donné)
o Diagramme de composants (pour montrer l'organisation des composants logiciels)
o Diagramme de déploiement (pour décrire l'architecture physique du déploiement)
 Les vues dynamiques, qui montrent le fonctionnement et le comportement du système
au fil du temps. Elles décrivent comment les éléments du système interagissent. Les
principaux diagrammes dynamiques incluent :
o Diagramme de séquence (pour montrer les interactions entre objets ordonnées dans
le temps)
o Diagramme de collaboration (ou de communication, pour montrer les interactions
entre objets en mettant l'accent sur leurs liens)
o Diagramme d'états-transitions (pour décrire les différents états d'un objet et les
transitions entre ces états)
o Diagramme d'activités (pour modéliser le déroulement des processus ou des
opérations)
L'utilisation d'UML s'avère bénéfique à toutes les étapes de conception du projet.

 Avantages de l'utilisation d'UML pour StockMaster

L'adoption d'UML pour le projet StockMaster présente plusieurs avantages significatifs :

33
 Chapitre 2 : Analyse & conception

 Descriptions graphiques claires : UML offre un moyen visuel et standardisé de

représenter des concepts complexes, facilitant la communication et la compréhension
au sein de l'équipe et avec d'éventuelles parties prenantes.
 Vues multiples et adaptées : Il permet d'aborder le système sous différents angles
(statique, dynamique) et à différents niveaux d'abstraction, ce qui est utile à diverses
étapes du cycle de vie du projet.
 Détection précoce des problèmes : La formalisation de la conception avec UML aide
à mettre en évidence des incomplétudes, des ambiguïtés ou des incohérences dans les
spécifications initiales, avant même de commencer le codage.
 Support à la conception et à la documentation : Les diagrammes UML constituent
une documentation précieuse du système, facilitant sa compréhension, sa maintenance
et son évolution future.
 Adaptabilité aux méthodes : Bien qu'ayant ses propres fondations, UML peut être
intégré et adapté à différentes méthodologies de développement logiciel.
 Un bon outil de démarrage : Pour un projet comme StockMaster, UML fournit un
cadre structurant pour démarrer la phase de conception de manière organisée.

[Link] Fonctionnelles (diagrammes des cas d’utilisation)

Le diagramme de cas d'utilisation ci-dessus modélise les interactions principales entre les
utilisateurs et le système de gestion de stock. Trois types d’acteurs sont représentés :
l’Administrateur, le Client et le Fournisseur, chacun ayant accès à des fonctionnalités
spécifiques selon son rôle.
1. Administrateur
L’administrateur dispose d’un accès étendu aux fonctionnalités du système, notamment :
 Validation des commandes : processus étendu par d'autres fonctionnalités selon les
besoins du système.
 Gestion des clients : ajout, modification ou suppression des comptes clients.
 Gestion des fournisseurs : gestion des informations et relations avec les fournisseurs.
 Génération de rapports : permet de produire des rapports analytiques sur l’état des
stocks, les commandes, etc.
 Gestion du catalogue produits : ajout, mise à jour ou suppression de produits.
o Cette fonctionnalité inclut la Surveillance des stocks, qui assure une veille
continue sur les niveaux de stock.

34
 Chapitre 2 : Analyse & conception

2. Client
Le client interagit avec le système principalement pour :
 Modifier son profil : gestion des informations personnelles.
 Consulter l’historique : visualisation des commandes passées.
 Passer une commande : processus incluant :
1. Sélection des produits
2. Validation du panier
3. Paiement
4. Ce cas d’utilisation est inclus dans l’interaction principale du client avec le
système.
3. Fournisseur
Le fournisseur a accès à des fonctionnalités permettant de :
 Proposer des produits : soumettre des articles pour approvisionnement.
 Mettre à jour ses coordonnées : modification des informations de contact.
 Suivre les retards : suivi des délais de livraison ou de traitement.
 Enregistrer une livraison : confirmation des produits livrés au stock.

35
 Chapitre 2 : Analyse & conception

Figure 3 : Diagramme des cas d'utilisation

5.2. Vue Logique (Diagramme de classes)

Le diagramme de classes présenté ci-dessus modélise la structure statique du système de

gestion de stock, en illustrant les entités principales, leurs attributs, leurs méthodes, ainsi que
les relations entre elles. Ce modèle conceptuel facilite la compréhension du fonctionnement
interne de l’application et la répartition des responsabilités entre les différentes classes.

 Classe Admin
La classe Admin représente l’administrateur du système, qui possède les privilèges les plus
étendus. Elle contient des attributs d'identification de base comme id, nom, email,
motDePasse et dateInscription. L’administrateur a la responsabilité de gérer l’ensemble des
utilisateurs et des entités du système. Il peut ainsi ajouter, modifier ou supprimer des clients
et des fournisseurs, archiver des produits, valider des commandes, et générer des rapports
sur les stocks. Cette classe joue un rôle central dans la supervision et la cohérence du
système.
 Classe Client

36
 Chapitre 2 : Analyse & conception

La classe Client décrit les utilisateurs qui passent des commandes sur la plateforme. Elle
contient des informations personnelles telles que l’identifiant, le nom, l’email, le téléphone,
l’adresse et la date d’inscription. Un client peut interagir avec le système via trois
principales actions : passer une commande (passerCommande), consulter son historique
d’achats (consulterHistorique), et modifier son profil (modifierProfil). Chaque client est
associé à plusieurs commandes clients, ce qui permet de tracer ses activités dans le système.
 Classe Fournisseur
La classe Fournisseur représente les partenaires commerciaux qui livrent des produits au
système de stock. Chaque fournisseur est identifié par un id, un nom, un contact, un email,
une adresse et un delaiLivraison. Le fournisseur peut proposer de nouveaux produits via la
méthode ajouterProduit, et peut mettre à jour ses informations de contact
(mettreAJourContact). Les interactions entre le système et les fournisseurs sont cruciales
pour maintenir l'approvisionnement du stock.
 Classe CommandeClient
La classe CommandeClient correspond aux commandes passées par les clients. Elle contient
des informations essentielles comme l’identifiant de la commande, la date, le statut, le
montant total, et le mode de paiement. Des méthodes associées permettent de calculer le
total de la commande (calculerTotal), de changer son statut (changerStatut), et de générer
une facture (genererFacture). Une commande client est composée de plusieurs lignes de
commande, chacune décrivant un produit commandé avec ses quantités et remises
éventuelles.
 Classe CommandeFournisseur
La classe CommandeFournisseur modélise les commandes émises par le système vers les
fournisseurs. Elle inclut l’identifiant, la date de commande, le statut, le montant total et la
date de livraison prévue. Elle offre des fonctionnalités permettant de recevoir une
commande (recevoirCommande) et de calculer un éventuel retard de livraison
(calculerRetard). Comme les commandes clients, une commande fournisseur est composée
de plusieurs lignes de commande.
 Classe LigneCommande
La classe LigneCommande représente les éléments constitutifs d’une commande, qu’elle
soit client ou fournisseur. Chaque ligne contient un identifiant, une quantité, un prix unitaire,
une remise, et un sous-total. Deux méthodes permettent de gérer les calculs associés :
calculerSousTotal, qui calcule le montant avant remise, et appliquerRemise, qui applique

37
 Chapitre 2 : Analyse & conception

une réduction selon un pourcentage donné. Cette classe est essentielle pour détailler le
contenu des commandes.
 Classe Produit
La classe Produit décrit les articles gérés dans le stock. Chaque produit est défini par un
identifiant, un nom, une description, un prix, une catégorie, une quantité disponible, et un
seuil minimum. Cette dernière valeur permet de déterminer à partir de quel niveau une alerte
de réapprovisionnement doit être déclenchée. Le produit dispose de deux méthodes
principales : mettreAJourStock, pour ajuster la quantité disponible, et verifierDisponibilite,
pour vérifier s’il est encore en stock.
 Classe Stock
La classe Stock représente l’emplacement physique ou logique où les produits sont
entreposés. Elle contient un id, un emplacement, une capacité, et la dateDernierInventaire.
Elle permet de gérer l’état général des stocks à travers des méthodes telles que verifierStock,
lancerInventaire, et genererAlerteStockBas, cette dernière étant utilisée pour alerter
automatiquement en cas de baisse critique des quantités.

38
 Chapitre 2 : Analyse & conception

Figure 4 : Diagramme de classe

39
 Chapitre 2 : Analyse & conception

5.3. Vue Dynamique (Diagramme de séquence)

5.3.1 Admin

[Link] Admin valide les commandes

Figure 5 : Diagramme de séquence ''Admin valide les commandes ''

Ce diagramme de séquence UML illustre le processus chronologique de validation d'une

commande par un administrateur, détaillant les interactions entre les différents composants du
système, depuis l'action initiale de l'administrateur jusqu'à la confirmation finale.
L'administrateur initie le processus en cliquant sur "Valider commande" dans l'Interface
Admin, ce qui déclenche un appel à la méthode validerCommande(idCommande) sur le
Controller Commande. Ce dernier orchestre la suite en demandant au Service Commande de
vérifier la commande via verifierCommande, amenant le Service à récupérer les données de la
commande concernée depuis la Base de Données en utilisant getCommande. Si la commande
est jugée valide, le Service Commande procède à la mise à jour de son statut en appelant la
méthode mettreAJourStatut(idCommande, "Validée") sur la Base de Données, laquelle
confirme cette opération (par exemple, via updateStatutCommande). Finalement, un message
de succès est renvoyé à l'Interface Admin, qui l'affiche à l'administrateur via la méthode
afficherMessage, confirmant la réussite de la validation.

[Link] Admin gère les clients

40
 Chapitre 2 : Analyse & conception

Figure 6 : Diagramme de séquence ''Admin gère les clients''

Ce diagramme illustre trois cas d'usage essentiels à la gestion des clients au sein d'une
application, démontrant les interactions entre un administrateur et les composants logiciels
structurés selon une architecture MVC (Vue, Contrôleur, Modèle, Base de Données). Pour la
création d'un client, l'administrateur remplit un formulaire dans la Vue, laquelle transmet les
données au Contrôleur (submitForm(data)); ce dernier sollicite le Modèle (createClient(data))
qui persiste les informations en BDD, supposant une validation préalable, avant qu'un
message de succès ne soit affiché par la Vue. Lors de la consultation de la liste des clients,
une action de l'administrateur dans la Vue (getClients()) amène le Contrôleur à interroger le
Modèle (getAll()), lequel récupère une Liste<Client> de la BDD, souvent convertie en DTO

41
 Chapitre 2 : Analyse & conception

(Data Transfer Object) pour séparer la logique métier de l'affichage, avant d'être présentée
sous forme de tableau dans la Vue. Enfin, la suppression d'un client est initiée par la sélection
d'un client (client[x]) et une demande de suppression (deleteClient(id)) depuis la Vue vers le
Contrôleur, qui fait appel au Modèle (delete(id)); la BDD exécute la suppression, et en cas de
succès (confirmé par un booléen), la Vue actualise la liste (refreshList()), gérant
implicitement les échecs si la suppression n'est pas confirmée et suggérant une possible
interaction asynchrone pour l'attente de confirmation.

[Link] Admin gère les fournisseurs

Figure 7 : Diagramme de séquence ''Admin gère les fournisseurs''

42
 Chapitre 2 : Analyse & conception

Ce diagramme illustre les interactions entre un administrateur et un système de gestion des

fournisseurs, structuré selon une architecture MVC (Modèle-Vue-Contrôleur), et détaille
quatre cas d'usage principaux. Pour l'ajout d'un fournisseur, l'administrateur saisit les
informations dans la Vue, qui les transmet au Contrôleur via ajouterFournisseur(data) ; ce
dernier sollicite le Modèle (creerFournisseur(data)) pour enregistrer les données en BDD,
avant qu'un message de succès ("Fournisseur ajouté") ne soit affiché, illustrant un flux
CREATE standard. La consultation de la liste des fournisseurs est initiée par un clic de
l'administrateur sur "Liste" dans la Vue, qui via listeFournisseurs() demande au Contrôleur
d'interroger le Modèle (getAllFournisseurs()); la BDD retourne alors une Liste<Fournisseur>,
potentiellement convertie en DTO, affichée sous forme de tableau par la Vue dans une
opération de lecture seule. La mise à jour d'un fournisseur implique que l'administrateur
sélectionne et modifie un fournisseur dans la Vue, qui envoie les nouvelles données via
updateFournisseur(id, data) au Contrôleur; ce dernier invoque le Modèle
(modifierFournisseur(id, data)) pour que la BDD mette à jour l'enregistrement, et en cas de
succès (confirmé par un retour true/false), la Vue actualise la liste. Enfin, la désactivation d'un
fournisseur, privilégiant un 'soft delete', est déclenchée par un clic sur "Désactiver" dans la
Vue, qui envoie la requête désactiver Fournisseur(id) au Contrôleur ; celui-ci demande au
Modèle (desactiver(id, false)) de marquer le fournisseur comme inactif en BDD, ce qui est
suivi d'une confirmation et d'un feedback visuel masquant le fournisseur dans l'interface.

[Link] Admin génère des rapports

Figure 8 : Admin génère les rapports

Ce diagramme illustre le processus de génération d'un rapport par un administrateur au sein

d'un système suivant une architecture MVC (Modèle-Vue-Contrôleur), décrivant les
interactions séquentielles entre les composants pour produire un rapport personnalisé, tel que

43
 Chapitre 2 : Analyse & conception

les ventes ou les stocks, et le présenter à l'utilisateur. Le processus est initié lorsque
l'administrateur clique sur "Générer rapport" dans la Vue (Interface Admin), laquelle capture
alors les paramètres nécessaires comme la période, le type de rapport et les filtres. Ces
paramètres sont transmis au Contrôleur (Système de Rapport), qui orchestre la génération en
appelant le Modèle (Gestion des Rapports). Le Modèle est responsable de récupérer les
données brutes pertinentes (par exemple, une liste des ventes) depuis la Base de Données
(BDD), puis d'effectuer les calculs et la mise en forme requis, comme les totaux ou la
génération de graphiques. Une fois traité, le rapport est converti dans un format exploitable,
tel qu'un PDF ou un tableau, et finalement, la Vue affiche ce rapport finalisé à l'administrateur
ou lui propose de le télécharger.

[Link] Admin gère les catalogues produits

Figure 9 : Diagramme de séquence ''Admin gère les catalogues produits''

Ce diagramme de séquence illustre trois opérations de gestion de produits (Ajouter, Modifier,

Supprimer) effectuées par un Administrateur via une Interface Admin, suivant une

44
 Chapitre 2 : Analyse & conception

architecture impliquant un Contrôleur (Gestion Produits), un Modèle (Catalogue Produits) et

une Base de Données (BDD). Pour l'ajout d'un produit, l'Admin clique sur "Ajouter produit",
l'interface envoie les données (nom, prix, stock) au Contrôleur qui les transmet au Modèle
pour un INSERT en BDD, suivi d'une confirmation de succès à l'Admin. Concernant la
modification, l'Admin sélectionne un produit, l'interface envoie les nouvelles informations au
Contrôleur qui demande au Modèle d'effectuer un UPDATE en BDD, et une confirmation est
affichée. Enfin, pour la suppression, l'Admin initie la suppression, l'interface envoie l'ID du
produit au Contrôleur, qui instruit le Modèle d'exécuter un DELETE en BDD, l'opération
étant confirmée à l'Admin. Chaque opération se conclut par l'affichage d'un message de
succès.

[Link] Admin surveille le stock

Figure 10 : Diagramme de séquence ''Admin surveille le stock ''

Ce diagramme de séquence dépeint plusieurs interactions d'un 'Administrateur' avec un

système de gestion des stocks via une 'Vue Dashboard', impliquant un 'Contrôleur Stocks', un
'Modèle Stock' et une 'BDD'. Initialement, l'ouverture du tableau de bord par l'administrateur
déclenche la récupération des niveaux de stock actuels depuis la BDD, via le Contrôleur et le
45
 Chapitre 2 : Analyse & conception

Modèle, pour les afficher sous forme de jauges. Parallèlement, une tâche planifiée
automatique surveille les stocks critiques : le Modèle scanne la BDD pour identifier les
produits en rupture, et des alertes sont notifiées à l'administrateur par un popup en cas de seuil
atteint. L'administrateur peut également initier une analyse de la rotation des stocks, où le
système calcule les taux à partir des mouvements de stock en BDD et génère un rapport sous
forme d'histogramme. Enfin, une fonctionnalité de prévision de réapprovisionnement permet à
l'administrateur de demander une estimation des besoins futurs ; le Modèle analyse la
consommation et les délais pour générer des prévisions et une liste de commandes suggérées,
affichée dans un tableau "À commander".

5.3.2 Le Client

[Link] Le Client modifie son profile

Figure 11 : Diagramme de séquence ''Le client modifie son profile ''

Ce diagramme de séquence illustre l'interaction d'un Client avec une Interface Web (Vue)
pour consulter puis modifier son profil, processus orchestré par un ClientController et un
ClientModel qui communique avec une Base de Données Client (BDD Client).
Initialement, lorsque le client accède à sa page de profil, l'interface web initie une requête via
le contrôleur vers le modèle pour récupérer les données du client depuis la base de données ;
ces informations sont ensuite transformées en un objet client et utilisées pour pré-remplir un
formulaire affiché à l'utilisateur. Subséquemment, si le client modifie et soumet ses

46
 Chapitre 2 : Analyse & conception

informations, l'interface web transmet ces nouvelles données au contrôleur, qui charge le
modèle de mettre à jour l'enregistrement correspondant dans la base de données. Une fois la
modification effectuée avec succès, une confirmation remonte du modèle, à travers le
contrôleur, jusqu'à l'interface web qui affiche alors un message de succès au client.
L'ensemble du processus met en évidence une séparation claire des responsabilités typique
d'une architecture Modèle-Vue-Contrôleur (MVC), où la vue gère l'interaction, le contrôleur
orchestre les flux et le modèle s'occupe de la logique métier et de l'accès aux données.

[Link] Le Client consulte l’historique

Figure 12 : Diagramme de séquence ''Le client consulte l'historique''

Ce diagramme de séquence détaille les interactions entre un Client, une Vue Web,
un ClientController, un CommandeModel et une base de données (BDD Commandes)
lorsqu'un client souhaite consulter son historique de commandes. L'interaction commence
lorsque le Client clique sur le lien ou le bouton « Mes commandes » sur la Vue Web. Cette
action incite la Vue Web à appeler la méthode getHistorique(clientId) du ClientController,
qui à son tour sollicite le CommandeModel vial 'appel getCommandes(clientId). Le
CommandeModel interroge ensuite la BDD Commandes pour « Récupérer l'historique des
commandes pour clientId ». En retour, la base de données fournit une « Liste des données
commandes » brutes au CommandeModel. Après un éventuel traitement, le CommandeModel
renvoie une « Liste des objets Commande » au ClientController. Ce dernier transmet cette
liste à la Vue Web avec l'instruction d’ « Affiche les commandes ». Finalement, la Vue Web
présente l'historique des commandes au Client, qui peut alors le « Visualise l'historique »

[Link] Le Client passe une commande

47
 Chapitre 2 : Analyse & conception

Figure 13 : Diagramme de séquence ''Le client passe une commande ''

Ce diagramme de séquence illustre le processus complet de passage de commande par un

Client via une Vue Web. Après que le client ait sélectionné des produits et cliqué sur
"Valider commande", la Vue Web transmet la demande au CommandeController. Ce
dernier orchestre les étapes suivantes : il sollicite d'abord le ProduitModel pour vérifier la
disponibilité du stock des articles du panier en consultant la BDD Produits. Si le stock est
jugé suffisant ("OK"), le CommandeController demande au CommandePersistenceModel de
créer la commande. Ce modèle interagit alors avec la BDD Commandes pour y insérer la
nouvelle commande, puis avec la BDD Produits pour mettre à jour les quantités en stock.
Une fois ces opérations réussies et la commande enregistrée, une confirmation et le numéro de
commande sont renvoyés via le CommandeController à la Vue Web, qui les affiche au Client.
Dans le cas où le stock serait insuffisant ou une autre erreur surviendrait lors de la
vérification, un message d'erreur approprié serait retourné au Client via la Vue Web.

5.3.3 Fournisseur

[Link] Le Fournisseur enregistre une livraison

Figure 14 : Diagramme de séquence ''Le fournisseurs enregistre une livraison ''

48
 Chapitre 2 : Analyse & conception

Ce diagramme de séquence décrit le processus par lequel un Fournisseur enregistre une

nouvelle livraison de produits. L'interaction commence lorsque le Fournisseur accède au
formulaire de livraison via la Vue Web, qui lui affiche alors ledit formulaire. Après avoir
rempli les informations relatives aux produits et quantités livrés, le Fournisseur soumet ces
données à la Vue Web. Celle-ci transmet la requête enregistrerLivraison au
LivraisonController, incluant l'identifiant du fournisseur et les détails de la livraison. Le
LivraisonController orchestre ensuite la création de la livraison en appelant la méthode
creerLivraison du LivraisonModel. Ce dernier interagit avec la BDD Livraisons pour y
insérer les détails de la nouvelle livraison. Suite à cette insertion, le LivraisonModel initie la
mise à jour du stock en appelant la méthode mettreAJourStock du ProduitModel, qui à son
tour modifie les quantités dans la BDD Produits. Une fois la livraison enregistrée et le stock
mis à jour, une confirmation est renvoyée en cascade, du ProduitModel au LivraisonModel,
puis au LivraisonController, qui informe la Vue Web du succès de l'opération. Finalement, la
Vue Web affiche une confirmation au Fournisseur.

[Link] Le Fournisseur propose des produits

Figure 15 : Diagramme de séquence ''Le fournisseur propose des produits''

Ce diagramme de séquence illustre le processus par lequel un 'Fournisseur' propose un

nouveau produit via une application [Link], le Fournisseur accède à un formulaire
via la 'Vue Web'. La 'Vue Web' lui présente alors un 'Formulaire vide'. Le Fournisseur remplit
les informations du produit sur ce formulaire. Une fois les informations saisies, la 'Vue Web'
envoie une requête 'proposerProduit', contenant l'identifiant du fournisseur et les données du
produit, au 'ProduitController’. Le 'ProduitController' prend en charge cette requête et appelle

49
 Chapitre 2 : Analyse & conception

la méthode 'validerEtAjouter' sur le 'ProduitModel'. Le 'ProduitModel' interagit ensuite avec la

'BDD Produits' (Base de Données Produits) en appelant la méthode 'enregistrerProduit', lui
transmettant les données du produit avec un état initial de 'proposé'. La base de données
confirme l'enregistrement ('ConfirmationEnregistrement' ou 'OK') au 'ProduitModel'.Suite à
cette confirmation, le 'ProduitModel' notifie le 'ProduitController' que le 'Produit proposé' (le
produit a été proposé/enregistré avec succès). Le 'ProduitController' renvoie alors un 'Message
confirmation' à la 'Vue Web'. Finalement, la 'Vue Web' 'Affiche succès' (affiche un message
de succès) au Fournisseur, indiquant que sa proposition de produit a bien été enregistrée.

[Link] Le fournisseur met à jour ces coordonnées

Figure 16 : Diagramme de séquence ''Le fournisseur met à jour ces

coordonnées''

Ce diagramme de séquence décrit le processus par lequel un 'Fournisseur' met à jour ses
coordonnées via une application web. Initialement, le Fournisseur 'Accède à son profil' via la
'Vue Web'. Celle-ci initie une requête 'getFournisseur', transmettant l'identifiant du
fournisseur, au 'FournisseurController'. Le contrôleur sollicite alors le 'FournisseurModel'
pour obtenir les informations du fournisseur. Le 'FournisseurModel' interroge la 'BDD
Fournisseurs' avec la méthode 'recupererInfosFournisseur(id)' et reçoit en retour les 'Données
actuelles'. Ces données sont ensuite transmises au 'FournisseurController' sous forme d'un
'Objet fournisseur', qui les relaie à la 'Vue Web' pour qu'elle 'Affiche formulaire' pré-rempli.
Une fois que le Fournisseur 'Modifie coordonnées' sur ce formulaire, la 'Vue Web' envoie une
requête 'updateCoordonnees' au 'FournisseurController'. Ce dernier demande au
FournisseurModel de mettre à jour les coordonnées. 'FournisseurModel' effectue alors
l'opération 'mettreAJourInfosFournisseur(id, nouvellesCoordonnees)' sur la 'BDD
Fournisseurs'. Après avoir reçu une confirmation ('OK') de la base de données, le modèle
notifie le contrôleur que les 'Coordonnées [sont] mises à jour'. Finalement, le

50
 Chapitre 2 : Analyse & conception

'FournisseurController' envoie un 'Message succès' à la 'Vue Web', qui informe le Fournisseur

que ses 'Coordonnées [ont été] modifiées'.

[Link] Le Fournisseur suit les retards

Figure 17 : Diagramme de séquence ''Le fournisseur suit les retards''

Ce diagramme de séquence illustre comment un 'Fournisseur' consulte les livraisons en retard

via une application web. Le processus commence lorsque le Fournisseur 'Accède à la page
suivi des livraisons' sur l''Interface Web (Vue)'. L'interface web envoie alors une requête
'getLivraisonsAvecRetard', avec l'identifiant du fournisseur, au 'RetardController
(Contrôleur)'. Ce dernier sollicite le 'LivraisonModel (Modèle Livraison)' en appelant la
méthode 'getLivraisonsRetardées(fournisseurId)'. Le 'LivraisonModel' interroge ensuite la
'BDD Livraisons' avec la requête 'rechercherLivraisonsEnRetard(fournisseurId)' pour obtenir
la 'Liste livraisons en retard'. Cette liste est retournée au 'LivraisonModel', qui la transmet au
'RetardController' sous forme de 'Données livraisons en retard'. Le contrôleur envoie ces
données à l''Interface Web', lui demandant d''Afficher la liste des retards'. Finalement,
l''Interface Web' 'Affiche [les] livraisons en retard avec détails' au Fournisseur.

Conclusion
À l’issue de ce chapitre, nous avons pu transformer les besoins exprimés en une modélisation
claire et structurée du futur système StockMaster. L'analyse fonctionnelle a permis de préciser
les rôles de chaque acteur et les interactions attendues avec l'application, tandis que la
conception a jeté les bases techniques solides sur lesquelles s’appuiera la mise en œuvre. Les
choix d’architecture, de structure de données et de modélisation des processus garantissent
une cohérence globale du système et facilitent son développement futur. Ainsi, ce travail
d’analyse et de conception constitue une étape fondamentale qui guide efficacement la
transition vers la phase de réalisation.

51
 Chapitre 3 : Interface de l’application

Chapitre 3 : Interfaces de
l’application

67
 Chapitre 3 : Interface de l’application

Introduction
À travers ce chapitre, nous avons présenté de manière détaillée les différentes interfaces de
l’application StockMaster, en précisant les fenêtres propres à chaque type d’utilisateur ainsi
que les fonctionnalités qui leur sont associées. Cette étape marque l’aboutissement de la phase
de développement en illustrant concrètement la traduction des besoins en éléments visuels et
interactifs. Elle prépare ainsi le terrain pour les phases de test et de validation, en garantissant
que la solution développée est conforme aux exigences spécifiées.

[Link]

[Link] Admin
 Page login

 Dashboard Admin

68
 Chapitre 3 : Interface de l’application

 Gestion des produit

 Liste des produits

 Ajouoter un produit

69
 Chapitre 3 : Interface de l’application

 Modifier un produit

 Supprimer un produit

70
 Chapitre 3 : Interface de l’application

 Rapport du produit

 Rechercher un produit

 Gestion des Client

 Liste des clients

71
 Chapitre 3 : Interface de l’application

 Ajouter un client

 Modifier un client

 Supprimer un client

72
 Chapitre 3 : Interface de l’application

 Rechercher un client

 Gestion des Fournisseurs

 Liste des fournisseurs

73
 Chapitre 3 : Interface de l’application

 Ajouter un fournisseur

 Modifier un fournisseur

 supprimer un fournisseur

74
 Chapitre 3 : Interface de l’application

 Rechercher un fournisseur

 Gestion des Stock

 Liste des Stock

75
 Chapitre 3 : Interface de l’application

 Ajouter un stock

 Ajouter des produits dans le stock

 Rapport du stock

76
 Chapitre 3 : Interface de l’application

 Gestion des Commandes

 Liste des commandes avec les actions

Conclusion
Nous avons exploré dans ce chapitre les différentes interfaces et les fenêtres utilisées pour
chaque utilisateur, ensuite, nous avons détaillé en particulier les fonctionnalités offertes pour
chacune d’elle.

77
 Conclusion

Conclusion Générale

93
 Conclusion

Présentation générale de votre travail

Avantage et objectif de votre solution proposé
Votre avancement au niveau de la réalisation de cette solution (à quel niveau vous vous êtes
arrivés dans le développent de votre site web)
Parlez de votre expérience vis-à-vis de ce projet de fin d’année : qu’est ce que vous avez
appris
Présentation de vos perspectives

94