REPUBLIQUE TUNISIENNE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

ET
DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE DE JENDOUBA

Institut Supérieur d’Informatique de Kef

RAPPORT DE PROJET DE FIN D’ETUDES

Présenté en vue de l’obtention du
DIPLÔME DE LICENCE EN SCIENCES INFORMATIQUE

Sujet : Conception et développement d'un

module Odoo 17 web et mobile pour la
gestion de production.

Réalisé par :
Nom : Ghofran Nom : Khaled
Prénom : Rajhi Prénom : Hjila

Organisme d’accueil:
Warzzez Solution

Encadré par : Dr. Haithem Hayouni

Soutenu le : Devant le jury composé de :

Président : Mr. Ahmed Toujani

Rapporteur :

Année Universitaire 2023-2024

Signature de l’encadrant ISI :

Signature de l’encadrant de l’entreprise :

‫إلى فلسطين‪ ،‬يا درة الشرق ومهد الحضارات‪ ،‬يا أرض األنبياء وأم الشهداء‪ ،‬أقدم هذا‬
‫لك‪ .‬إلى تلك األرض الطيبة التي تزهر بالشجاعة والتضحية والصمود‬ ‫‪.‬العمل إهدا ًء ِ‬

‫إلى شعب فلسطين العظيم‪ ،‬إلى األمهات اللواتي يغرسن في قلوب أبنائهن حب الوطن‬
‫والصبر‪ ،‬إلى اآلباء الذين يقدمون الغالي والنفيس في سبيل حرية وكرامة وطنهم‪ .‬إلى‬
‫الشباب والشابات الذين يحملون شعلة األمل والتغيير في كل خطوة يخطونها‪ ،‬وإلى‬
‫األطفال الذين يكبرون في حضن فلسطين الحبيبة وهم يحملون في قلوبهم آمال المستقبل‬
‫‪.‬الواعد‬

‫إلى الشهداء األبرار الذين ارتقوا إلى السماء دفاعا ً عن أرضهم وعرضهم‪ ،‬إلى األسرى‬
‫األبطال الذين يعانون في ظالم الزنازين وهم يحملون في قلوبهم نور الحرية والكرامة‪.‬‬
‫إلى كل من يحمل في قلبه حب فلسطين ويعمل بجد وإخالص من أجل تحقيق حلم العودة‬
‫‪.‬وبناء دولة العدل والسالم‬

‫بإهدائي هذا العمل المتواضع‪ ،‬أقول لكم أنكم لستم وحدكم في هذا النضال النبيل‪ .‬قلوبنا‬
‫ت خفق معكم‪ ،‬وأرواحنا تواسيكم‪ ،‬وعقولنا تنبض بتضحياتكم‪ .‬سنظل نذكر مآثركم ونستلهم‬
‫‪.‬من شجاعتكم األمل والعزيمة لنحقق معا ً العدالة والحرية التي تستحقونها‬

‫ت رمز الصمود واألمل‪ ،‬وإلى األبد ستظل مكانك في قلوبنا محفوظاً‪ ،‬وفي‬ ‫فلسطين‪ ،‬أن ِ‬
‫‪.‬عقولنا متوجاً‪ ،‬وفي تاريخ اإلنسانية صفحةً مشرقةً تروي قصةً ال تُنسى‬
 Dédicace

“Je dédie ce travail ..

À ma défunte mère "Ghzela"

Maman, Ton absence est un vide immense, mais ton souvenir
lumineux continue d’illuminer mon chemin. Ce travail est un
humble hommage à ton amour inconditionnel et à ton soutien
indéfectible. Tu as été ma source d’inspiration, mon guide et
mon rocher tout au long de ma vie. Je t’aime et te remercie
pour tout ce que tu as fait pour moi. Tu me manque
profondément..

À mon cher père "Fathi"

Vous avez toujours été mon école de patience, de confiance

et surtout d’espoir et d’amour. J’implore Dieu, tout puissant,
de vous accorder une bonne santé, une longue vie et de
bonheur.

A mes chères sœurs "Nada" et "Nadine"

En témoignage de ma profonde gratitude qu’il trouve ici mes

souhaites d’une heureuse plaine d’amour et bonne santé.

À tous ceux qui me sont chers, à vous tous Merci

Rajhi Ghofran
 Dédicace

“Je dédie ce travail ..

À ma chère mère "Fouzia"

Mon bonheur, la source de mes efforts. Aucune dédicace très

chère maman, ne pourrait exprimer la profondeur des
sentiments que j’éprouve pour vous.
Puisse Dieu, tout puissant vous combler de santé, de bonheur
et vous procurer une longue vie.

À mon cher père "Lotfi"

Vous avez toujours été mon école de patience, de confiance et

surtout d’espoir et d’amour. J’implore Dieu, tout puissant, de
vous accorder une bonne santé, une longue vie et de bonheur.

À tous ceux qui me sont chers, à vous tous Merci.

Hjila
Khaled
 Remerciements

Côté professionnelle
Je tiens à remercier toutes les personnes qui ont contribué au succès de mon stage et qui
m'ont aidé lors de la rédaction de ce rapport. Tout d'abord, je tiens à remercier vivement
mon maître de stage, M. Imed Sadok, ainsi que M.Chedi Mezni, développeur dans la
startup dans laquelle j'ai effectué mon stage, pour leur accueil, leur soutien continu, leurs
conseils et leur aide précieuse dans la compréhension de la méthodologie nécessaire au
développement de cette plateforme.

Côté académique
J'adresse mes remerciements aussi à mon encadreur M.Haithem Hayouni qui m'a
orienté et guidé. Son écoute et ses conseils m'ont permis de cibler mes candidatures et
de trouver ce stage qui était en totale adéquation avec mes attentes, il fut d'une aide
précieuse dans les moments les plus délicats pour réussir mon stage dans j’avais d’abord
l’intention de connaitre le domaine du développement web, ensuite cette expérience était
pour moi essentielle dans l’objectif d’apprendre des nouvelles connaissances.
 Sommaire

Introduction générale .......................................................................................................................... 1

Chapitre 1 : Cadre général du projet ...................................................................................................3
Introduction ....................................................................................................................................3
1.1 Présentation de l’organisme d’accueil ................................................................................... 3
1.1.1 Présentation de Warzeez Solutions ................................................................................ 3
1.1.2 Filiales de Warzeez Solutions ........................................................................................ 4
1.1.3 Clientèle ........................................................................................................................ 5
1.2 Présentation générale du projet ............................................................................................. 6
1.2.1 Objectif du projet .......................................................................................................... 6
1.3 Étude de l’existant ................................................................................................................ 6
1.3.1 Analyse des solutions existantes .................................................................................... 6
1.3.2 Critique de l’existant .....................................................................................................7
1.3.3 Solution proposée .......................................................................................................... 7
1.4 Méthodologie de travail ........................................................................................................ 8
1.4.1 Méthodologie Agile .......................................................................................................8
1.4.2 Méthode Scrum ............................................................................................................. 9
1.4.3 Les principaux rôles de la méthode Scrum .....................................................................9
1.4.4 Concepts Scrum .......................................................................................................... 10
1.5 Langage de modélisation .................................................................................................... 10
Conclusion.................................................................................................................................... 11
Chapitre 2 : Sprint 0 : Préparation des bases de projet ....................................................................... 12
Introduction .................................................................................................................................. 12
1.1 Capture des besoins ............................................................................................................ 12
1.1.1 Identification des acteurs ............................................................................................. 12
1.2 Contexte général du projet .................................................................................................. 13
1.2.1 Besoins Fonctionnels ................................................................................................... 13
1.2.2 Besoins non Fonctionnels ............................................................................................ 14
1.3 Diagramme de cas d’utilisation global ................................................................................ 15
1.4 Backlog Product ................................................................................................................. 16
 1.5 Planification des Sprints ..................................................................................................... 20
1.6 Diagramme de classe .......................................................................................................... 20
1.7 Environnement de travail .................................................................................................... 22
1.7.1 Environnement matériel .............................................................................................. 22
1.7.2 Environnements logiciels ............................................................................................ 23
1.8 Architecture du système ..................................................................................................... 25
1.8.1 Service web ................................................................................................................. 26
Conclusion.................................................................................................................................... 26
Chapitre 3 : Sprint 1« Gestion des comptes, authentification » ............ Error! Bookmark not defined.
Introduction .................................................................................................................................. 27
1.1 Backlog du Sprint 1 ............................................................................................................ 27
1.2 Diagrammes des cas d’utilisations détaillée du Sprint
n°1 28
1.2.1 Description textuelle du cas de « s’authentifier »
28
1.2.2 Gérer les comptes ............................................................................................................. 30
1.2.3 Gérer les Rôles ............................................................................................................ 32
1.3 Diagrammes de séquence du Sprint n°1 ................................................................................... 33
1.3.1 Diagramme de séquence du cas « s’authentifier » ............................................................. 33
1.3.2 Diagramme de séquence du cas « Gérer les
Utilisateurs »............................................................................................................................. 34
1.3.3 Diagramme de séquence du cas « Gérer rôle » ................................................................. 35
1.4 Diagramme de classe .............................................................................................................. 37
1.4.1 Composants d'un diagramme de classes ............................................................................ 37
1.4.2 Diagramme de classe de conception S’authentifier ........................................................... 38
1.4.3 Diagramme de classe de conception Gérer Compte .......................................................... 38
Conclusion.................................................................................................................................... 39
Chapitre 4 : Sprint 2 « Gestion des produits, Gestions des
nomenclatures, Gestion des postes de travail » .................................................................................. 40
Introduction .................................................................................................................................. 40
1.1 Backlog Sprint .................................................................................................................... 40
1.2 Diagramme de cas d’utilisation Gérer produits ................................................................... 41
1.3 Diagramme de cas d’utilisation Gérer nomenclatures .............................................................. 44
1.4 Diagramme de cas d’utilisation Gérer poste de travail ............................................................. 46
1.5 Diagrammes de séquence du Sprint n°2 ................................................................................... 48
 1.5.1 Diagramme de séquence du cas « Gérer produit »............................................................. 48
1.5.2 Diagramme de séquence du cas « Gérer
nomenclature » ......................................................................................................................... 49
1.5.3 Diagramme de séquence du cas « Gérer poste de
travail » .................................................................................................................................... 50
1.6 Diagramme de classe .............................................................................................................. 51
1.6.1 Diagramme de classe de conception Gérer produit............................................................ 52
1.6.2 Diagramme de classe de conception Gérer
Nomenclature ........................................................................................................................... 53
1.6.3 Diagramme de classe de conception Gérer Poste de
travail ....................................................................................................................................... 53
Conclusion.................................................................................................................................... 54
Chapitre 5 : Sprint 3 « Gestion des ordres de fabrication,
Gestion des opérations » ................................................................................................................... 55
Introduction .................................................................................................................................. 55
1.1 Backlog Sprint ........................................................................................................................ 55
1.2 Diagramme de cas d’utilisation Gérer les ordres de
fabrication .................................................................................................................................... 56
1.3 Diagramme de cas d’utilisation Gérer les opérations ............................................................... 58
1.4 Diagrammes de séquence du Sprint n°3 ................................................................................... 60
1.4.1 Diagramme de séquence du cas « Gérer ordre de
fabrication ».............................................................................................................................. 60
1.4.2 Diagramme de séquence du cas « Gérer les
opérations » .............................................................................................................................. 61
1.5 Diagramme de classe .............................................................................................................. 62
1.5.1 Diagramme de classe de conception Gérer ordre de
fabrication ................................................................................................................................ 62
1.5.2 Diagramme de classe de conception Gérer les
opérations ................................................................................................................................. 63
Conclusion.................................................................................................................................... 63
Chapitre 6 : Sprint 4 « Gestion des ordres de travail » ....................................................................... 64
Introduction .................................................................................................................................. 64
1.1 Backlog Sprint ........................................................................................................................ 64
1.2 Diagramme de cas d’utilisation Traiter opérations de
fabrication .................................................................................................................................... 65
1.3 Diagramme de classe .............................................................................................................. 67
 1.3.1 Diagramme de classe de conception Quantité
Produite .................................................................................................................................... 67
1.4 Diagrammes d'activité du Sprint n°4 ....................................................................................... 68
1.4.1 Diagrammes d'activité Gérer ordre de travail .................................................................... 69
Conclusion.................................................................................................................................... 69
Chapitre 7 : « Réalisation » ............................................................................................................... 70
Introduction .................................................................................................................................. 70
1.1 Présentation des interfaces .................................................................................................. 70
1.1.1 Présentation des Interfaces Web ....................................................................................... 70
1.1.1.1 Dashboard ..................................................................................................................... 70
1.1.1.2 Authentification............................................................................................................. 71
1.1.1.3 Gestion des comptes ...................................................................................................... 71
1.1.1.4 Ajouter un utilisateur ..................................................................................................... 72
1.1.1.5 Supprimer un utilisateur ................................................................................................ 72
1.1.1.6 Gestion des rôles ........................................................................................................... 73
1.1.1.7 Ajouter rôle ................................................................................................................... 73
1.1.1.8 Gestion de nomenclature ............................................................................................... 74
1.1.1.9 Ajouter une nomenclature .............................................................................................. 74
1.1.1.10 Supprimer une nomenclature ....................................................................................... 75
1.1.1.11 Gestion des produits .................................................................................................... 75
1.1.1.12 Ajouter un produit ....................................................................................................... 76
1.1.1.13 Gestion des postes de travail ....................................................................................... 76
1.1.1.14 Ajouter une poste de travail ......................................................................................... 77
1.1.1.15 Gestion des opérations ................................................................................................ 77
1.1.1.16 Ajouter une opération .................................................................................................. 78
1.1.1.17 Gestion des ordres de fabrication ................................................................................. 78
1.1.1.18 Ajouter un ordre de fabrication .................................................................................... 79
1.1.1.19 Suivi d'un ordre de fabrication .................................................................................... 79
1.1.1.20 Ajouter la quantité produite chaque heure .................................................................... 80
1.2 Présentation des interfaces mobile ...................................................................................... 80
1.2.1 L’interface de l’application .............................................................................................. 80
1.2.3 S’authentifier.................................................................................................................... 81
1.2.4 Suivi d'un ordre de fabrication ..................................................................................... 82
1.2.5 Ajouter la quantité produite chaque heure .................................................................... 82
Conclusion générale ......................................................................................................................... 83
Webographie .................................................................................................................................... 85
 Les figures

Figure 1 : Logo de la société d'accueil................................................................................................. 3

Figure 2: Groupe Warzeez Solutions ...................................................................................................5
Figure 3 : Équipe de Scrum................................................................................................................. 9
Figure 4 : Présentation générale de Scrum........................................................................................ 10
Figure 5 : Logo langage de modélisation UML ................................................................................. 11
Figure 6 : Diagramme de modélisation de contexte ........................................................................... 13
Figure 7: Diagramme de cas d'utilisation .......................................................................................... 16
Figure 8 : Diagramme de classe ........................................................................................................ 22
Figure 9: Architecture de la solution ................................................................................................. 25
Figure 10 : Architecture de la service web ........................................................................................ 26
Figure 11 : Diagramme du cas d’utilisation ....................................................................................... 28
Figure 12 : Raffinement de cas d’utilisation « ................................................................................... 30
Figure 13 : Raffinement de cas d’utilisation « ................................................................................... 32
Figure 14: Diagramme de séquence de cas ........................................................................................ 34
Figure 15: Diagramme de séquence .................................................................................................. 35
Figure 16 : Diagramme de séquence de ............................................................................................. 36
Figure 17: Diagramme de classe du .................................................................................................. 38
Figure 18 : Diagramme de classe du « Gérer les comptes » ............................................................... 39
Figure 19 : Diagramme de cas d'utilisation ........................................................................................ 42
Figure 20: Diagramme de cas d'utilisation......................................................................................... 44
Figure 21 : Diagramme de cas d'utilisation ........................................................................................ 46
Figure 22: Diagramme de séquence de cas ........................................................................................ 49
Figure 23 : Diagramme de séquence de cas ....................................................................................... 50
Figure 24 : Diagramme de séquence de cas ....................................................................................... 51
Figure 25: Diagramme de classe du .................................................................................................. 52
Figure 26 : Diagramme de classe du ................................................................................................. 53
Figure 27 : Diagramme de classe du ................................................................................................. 54
Figure 28 : Diagramme de cas d'utilisation ........................................................................................ 56
Figure 29 : Diagramme de cas d'utilisation ........................................................................................ 58
Figure 30 : Diagramme de séquence de cas ....................................................................................... 60
Figure 31 : Diagramme de séquence de ............................................................................................. 61
Figure 32 : Diagramme de classe du « ............................................................................................... 62
Figure 33 : Diagramme de classe du ................................................................................................. 63
Figure 34 : Diagramme de cas........................................................................................................... 65
Figure 35 : Diagramme de classe du ................................................................................................. 68
Figure 36 : Diagramme d’activité du ................................................................................................. 69
Figure 37 : Interface de Tableaux de bord ......................................................................................... 70
Figure 38 : Interface d’authentification ............................................................................................. 71
Figure 39 : Interface de Gestion des comptes .................................................................................... 71
Figure 40 : Interface d’ajouter ........................................................................................................... 72
Figure 41 : Interface de supprimer .................................................................................................... 72
Figure 42 : Interface de ..................................................................................................................... 73
Figure 43: Interface d’ajouter ............................................................................................................ 73
Figure 44: Interface de Gestion ......................................................................................................... 74
Figure 45 : Interface d’ajouter ........................................................................................................... 74
Figure 46 : Interface de supprimer .................................................................................................... 75
Figure 47 : Interface de Gestion ........................................................................................................ 75
Figure 48 : Interface d’ajouter ........................................................................................................... 76
Figure 49: Interface de Gestion ......................................................................................................... 76
Figure 50 : Interface d’ajouter ........................................................................................................... 77
Figure 51: Interface de Gestion ......................................................................................................... 77
Figure 52 : Interface d’ajouter ........................................................................................................... 78
Figure 53 : Interface de Gestion ........................................................................................................ 78
Figure 54 : Interface d’ajouter ........................................................................................................... 79
Figure 55: Interface de Suivi d'un ..................................................................................................... 79
Figure 56: Interface d’ajouter ............................................................................................................ 80
Figure 57 : Interface de l’application................................................................................................. 81
Figure 58 : Interface de S’authentifier ............................................................................................... 81
Figure 59 : Interface de Suivi d'un .................................................................................................... 82
Figure 60 : Interface d’ajouter la Quantité produite ........................................................................... 82
 Liste des tableaux

Tableau 1: Étude comparative des solutions existante ......................................................................... 7

Tableau 2: Backlog Product .............................................................................................................. 17
Tableau 3: Planification des sprints ................................................................................................... 20
Tableau 4: Tableau des langages utilisés ........................................................................................... 23
Tableau 5: Tableau des logiciels utilisés ........................................................................................... 24
Tableau 6 : Tableau de serveur utilisé ............................................................................................... 25
Tableau 7 : Backlog sprint 1 ............................................................................................................. 27
Tableau 8 : Description textuelle du cas de ....................................................................................... 29
Tableau 9 : Description textuelle du cas de ....................................................................................... 30
Tableau 10: Description textuelle du cas de ...................................................................................... 31
Tableau 11 : Description textuelle du cas de ..................................................................................... 31
Tableau 12 : Description textuelle du cas de ..................................................................................... 32
Tableau 13 : Backlog sprint 2 ........................................................................................................... 40
Tableau 14 : Description textuelle du cas de ..................................................................................... 42
Tableau 15: Description textuelle du cas de ...................................................................................... 44
Tableau 16 : Description textuelle du cas de ..................................................................................... 46
Tableau 17: Backlog sprint 3 ............................................................................................................ 55
Tableau 18 : Description textuelle du cas de ..................................................................................... 56
Tableau 19 : Description textuelle du cas de ..................................................................................... 58
Tableau 20 : Backlog sprint 4 ........................................................................................................... 64
Tableau 21: Description textuelle du cas de ...................................................................................... 65
 Introduction générale

Les entreprises sont prêtes à investir significativement dans l'adoption de technologies

logicielles pour améliorer leurs services, renforcer leur agilité et leur flexibilité, réduire les coûts,
augmenter la production et répondre aux défis du marché.

En effet, vu la croissance des activités au sein des entreprises, la tâche de gérer efficacement
toutes ces fonctions s’avère de plus en plus complexe et difficile.

Avec l'évolution des outils technologiques, l'augmentation des données à gérer et l'émergence de
nouveaux besoins, il devient crucial pour les entreprises de repenser leur système d'information. Pour
relever ces défis, il est essentiel d'utiliser des outils optimisés et adaptés qui simplifient les tâches et
offrent des fonctionnalités riches et utiles. Parmi ces outils, les ERP (Enterprise Resource Planning) se
démarquent en tant que solutions intégrées de gestion. Les ERP sont des systèmes de gestion et
d'analyse qui améliorent la circulation des informations en interne, optimisent les processus de gestion
et automatisent les tâches, ce qui accroît considérablement la réactivité et l'agilité des entreprises. C'est
dans ce contexte que s'inscrit notre projet de fin d'études, qui vise à concevoir et développer un module
ERP dédié à la gestion de production.

Notre objectif est de concevoir un module qui automatise les divers processus de production, tels
que la gestion des nomenclatures, la planification des ordres de fabrication, la gestion des processus de
fabrication et le suivi des ordres de fabrication.

Notre rapport présente les différentes phases à travers lesquelles nous sommes passés pour
réaliser notre projet. Le premier chapitre intitulé « Cadre général du projet » est consacré à la
présentation du contexte du projet et le choix de la méthodologie Scrum pour la phase de
développement. Le deuxième chapitre, « Sprint 0 : Préparation des bases du projet » s’articule autour
de l’identification des acteurs et la description des besoins fonctionnels et non fonctionnels. Puis, nous
élaborons le Backlog du produit et nous terminons par la présentation des architectures et
l’environnement de développement de notre application.

1
 Le troisième, le quatrième, le cinquième et le sixième chapitre « Réalisation du Sprint » mettent
en œuvre les sprints Backlog associés à chaque sprint, les diagrammes de cas d’utilisations et par les
diagrammes de séquences et diagramme de classe et d’activité.

Dans le septième chapitre, intitulé « Réalisation », nous abordons l’implémentation de

l’application et présentons les différentes interfaces de notre solution proposée. Finalement, le rapport
est clôturé par une conclusion générale qui résume notre travail.

2
 Chapitre 1 : Cadre général du projet

Introduction
Avant la mise en production, l’étude du projet est une tâche importante pour la définition
d’une démarche rationnelle et stratégique menant au bon déroulement et à la réussite du projet.
Cette étude fera donc l’objet de notre premier chapitre qui sera consacré à la présentation de
l’organisme d’accueil dans lequel ce travail a été effectué, les missions qui nous ont été confiées
et les pratiques adoptées pour réaliser notre travail, la problématique qui a urgé l’aboutissement
de cette solution ainsi que les objectifs de notre application. Nous le conclurons par la mention
de la problématique, la solution proposée et les objectifs à atteindre pour réussir la réalisation
de l’application.

1.1 Présentation de l’organisme d’accueil

1.1.1 Présentation de Warzeez Solutions

Warzeez solutions est un groupe polyvalent d'entreprises qui englobe une gamme complète
gamme de services pour répondre à vos besoins commerciaux à 360°. Warzeez a développé des
expertise dans les domaines clés de la transformation numérique, du développement
commercial, de l'apprentissage et de suivi pour vous proposer des solutions complètes et
intégrées.

Figure 1 : Logo de la société

d'accueil

3
1.1.2 Filiales de Warzeez Solutions

Warzeez solutions compte actuellement 4 filiales : Warzeez Digital, Warzeez Business,

Warzeez Sécurité et Warzeez Academy.

• Warzeez Digital : La filiale numérique Warzeez est une société de marketing digital
agence spécialisée dans le développement WordPress, la conception graphique et l'optimisation
des moteurs de recherche. L'équipe crée et conçoit des solutions uniques
pour aider votre l'entreprise développe sa réputation et sa visibilité en ligne.

• Warzeez Business : La filiale Business est spécialisée dans les solutions technologiques
avancées pour les entreprises évoluant dans divers secteurs industriels. Warzeez combine
une expertise informatique approfondie avec une connaissance approfondie des
défisspécifiques auxquels sont confrontées les industries modernes.

• Warzeez Academy : L'Académie est un centre de formation professionnelle dédié

à la valorisation des compétences et au développement personnel. Ils offrent une large gamme
de programmes de formation dans différents domaines, conçus pour aider les individus et les
entreprises à atteindre l'excellence dans leurs activités.

• Warzeez Security : La filiale Warzeez Security est spécialisée dans la surveillance

et de sécurité, offrant des solutions complètes et entièrement gérées pour répondre aux besoins
de surveillance et de protection des entreprises et des particuliers. Avec Warzeez Sécurité,
profitez d'un confort absolu dans un environnement sécurisé.

4
 Figure 2: Groupe Warzeez Solutions

1.1.3 Clientèle

Warzeez Solutions a gagné la confiance de nombreux clients et partenaires en élaborant

des solutions sur mesure qui répondent précisément à leurs besoins. Parmi les satisfaits
la clientèle est :
• Stafim

• Sagemcom

• Maghreb Emballage

• FlashApp

• TIS circuit

• World Wide Trade Source

• Generale Energie

• Ingenieurie Invest

5
1.2 Présentation générale du projet

1.2.1 Objectif du projet

L'objectif du projet est de créer un module Odoo 17, à la fois web et mobile, dédié à la gestion
de production. Cette application devra être conçue de manière flexible pour intégrer facilement
les évolutions et les améliorations futures, tout en assurant une qualité de code optimale.

1.3 Étude de l’existant

L’étude de l’existant est une étape très importante pour la bonne réalisation du projet, C'est la
phase du projet pendant laquelle le Business Analyste va auditer les processus et les solutions
informatiques existants. Elle est réalisée avant l'initialisation du changement. Elle permet de
préparer l'analyse des besoins de la solution cible et de réaliser l'analyse des écarts.

1.3.1 Analyse des solutions existantes

Avant d'entrer dans l'analyse détaillée, nous allons énumérer quelques applications existantes
afin d'étudier leurs points forts et leurs points faibles.
 Open-prod ( www.open-prod.com) : logiciel de gestion industrielle dédié à la gestion
de la production assistée par ordinateur.
 Gpmi ( www.gpmi.net ) : logiciel développé par GPMI qui répond aux besoins de
gestion de la production.

Dans le tableau, nous allons récapituler les fonctionnalités de base de chaque solution,
telles que la gestion des produits, des nomenclatures et des ordres de fabrication. Cependant,
certaines fonctionnalités importantes comme l’ordonnancement des ordres de fabrication et
la gestion des rôles des utilisateurs ne sont pas incluses dans ces solutions.

6
 Tableau 1: Étude comparative des solutions
existante

Fonctionnalité Open-prod Gpmi

Authentification Compte spécifique à l’application Aucune
authentification n’est
exigée
Multilingue Oui Non
Gestion des rôles des utilisateurs Non Non
Calcul de la quantité produite chaque Non Non
heure
Application mobile Oui Non
Ordonnancement des ordres de Non Non
fabrication

1.3.2 Critique de l’existant

Le tableau 1 nous a présenté les limites des applications existantes, plusieurs défis
complexes peuvent entraver l'efficacité des processus. La gestion des rôles des utilisateurs peut
être limitée, ce qui complique la délégation des responsabilités et la collaboration. De plus, la
planification des ordres de fabrication peut être particulièrement complexe sur certains sites,
rendant difficile la coordination des différentes étapes de production. Les fonctionnalités
essentielles telles que le calcul de la charge de travail peuvent faire défaut, ce qui entrave la
prise de décision éclairée. De même, l'absence d'estimation précise du coût de fabrication d'un
produit peut impacter la rentabilité globale de l'entreprise. Enfin, l'ergonomie de certaines
applications de gestion de production peut être insatisfaisante, affectant la productivité des
utilisateurs.

1.3.3 Solution proposée

Face à ces limitations mentionnées précédemment, il est nécessaire d'explorer d'autres options
ou améliorations d'Odoo 17 pour garantir une approche plus fiable et plus complète de la gestion
de la production.
Nous allons citer dans la suite les objectifs de ce projet :
 Accès sécurisé avec l’authentification des utilisateurs.

7
  Gestion des utilisateurs.
 Gestion des rôles des utilisateurs.
 Gestion des produits.
 Gestion des nomenclatures.
 Ajouter des composants à une nomenclature
 Gestion des ordres de fabrication.
 Gestion des ordres de travail.
La solution proposée doit aussi assurer des besoins non fonctionnels tel que :
 L’ergonomie
 Sécurité
 Performance
La complexité de ce projet réside dans la nécessité d'établir une communication efficace entre les
différents micro-services. En particulier, la table des produits étant située dans la base de données du
module commercial, il est essentiel de collecter des informations de cette table en utilisant des requêtes
à cette base de données via des web services.

1.4 Méthodologie de travail

La mise en place de systèmes d'information devient de plus en plus complexe avec des
systèmes de plus en plus sophistiqués en termes d'interfaces utilisateur, d'interconnexion entre
les systèmes et de traitement de l'information. Une part de cette complexité réside dans le fait
que la conception et la mise en place d'un système reposent largement sur la collaboration entre
les personnes. À l'origine, les entreprises se sont tournées vers des méthodes prédictives qui ont
montré leur efficacité, mais celles-ci atteignent aujourd'hui leurs limites en raison de l'évolution
constante des marchés, des besoins et des technologies.

1.4.1 Méthodologie Agile

"La méthodologie Agile est une approche de gestion de projet qui met l'accent sur la
collaboration transversale et l'amélioration continue. Elle divise les projets en phases plus
petites et guide les équipes à travers les cycles de planification, d'exécution et d'évaluation. [1]
Après une analyse comparative approfondie des méthodes agiles et traditionnelles, nous avons
constaté que la méthode agile était la mieux adaptée à nos besoins. En effet, en utilisant des

8
 informations brèves et des itérations contrôlées, elle permet d'éliminer l'effet tunnel que les
approches traditionnelles peuvent provoquer, elle favorise la gestion des risques en ne résistant
pas aux changements, et elle accorde la priorité à la participation des clients tout au long du
processus de développement."

1.4.2 Méthode Scrum

Notre choix s’est porté sur la méthode Scrum de gestion de projet car elle répond aux
caractéristiques des méthodes agile définies dans la section précédente. Elle est basée sur les
principes des méthodes agiles précédemment définis, elle privilégie la livraison rapide d’un
prototype, opérationnel par définition, afin d’avoir un retour rapide des clients et des donneurs
d’ordre par minimiser les pertes de temps.

1.4.3 Les principaux rôles de la méthode Scrum

 Product Owner : c’est le représentant des clients. Il définit la liste des fonctionnalités
du produit et choisit la date contenu de chaque sprint.
 Scrum master : il veuille à assurer que le processus Scrum est respecté et il est
responsable de l’application quotidienne des directives Scrum.
 L’équipe de développeurs : se compose de développeurs qui doivent identifier leurs
tâches en cours et les tâches achevées dans le « Sprint Backlog ».

Figure 3 : Équipe de Scrum

9
1.4.4 Concepts Scrum

 Sprint : Le Sprint est une période qui varie entre deux et quatre semaines au maximum.
Durant cette période, l’équipe délivre un livrable du produit. La durée fixée reste
constante pendant toute la durée du développement.
 Product Backlog (ou carnet de produit) : est défini par le guide Scrum comme étant
“une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit”.
 Scrum Meeting : Le Scrum Meeting n’est qu’une réunion pendant laquelle nous
cherchons à résoudre les problèmes, mais uniquement à les identifier et les exprimer.
 Revue de Sprint : À la fin du Sprint, l’Équipe, le Scrum Master et le Product Owner
se réunit pour effectuer la revue du sprint dont le but est de valider le livrable qui a été
produit durant le Sprint. L’équipe commence par énoncer les user story du Backlog de
produit qu’elle a réalisé.
 Rétrospective de Sprint : La rétrospective du sprint est faite en interne à l’équipe.
L’objectif est de détecter les erreurs commises et de prendre des décisions pour les
améliorer.

Figure 4 : Présentation générale de Scrum

Durant un développement d’un projet avec la méthode Scrum il y a plusieurs étapes à suivre avec
une démarche spécifique et une interaction avec plusieurs intervenants. [2]

1.5 Langage de modélisation

Nous avons choisi d’utiliser UML « Unified Modeling Language » comme langage de la
conception. UML est un langage de modélisation objet et non une démarche d’analyse. Il

10
 représente des concepts abstraits de manière graphique. Un modèle est une abstraction de la
réalité. L’abstraction est un des piliers de l’approche objet. Il s’agit d’un processus qui consiste
à identifier la caractéristique intéressante d’une entité en vue utilisations précise. UML est donc
un langage universel et visuel qui permet d’exprimer et d’élaborer des modèles objet,
indépendamment de tout langage de programmation. Et comme UML n’impose pas de méthode
de travail particulière, il peut être intègre à n’importe quel processus de développement logiciel
de manière transparente. Le langage de modélisation le plus utilise est UML qu’on a choisi pour
la conception de notre application. Un des tout premiers avantages d’UML est de faire se
rencontrer et communiquer utilisateurs et informaticiens, ce qui n’est pas le moindre des
bénéfices du langage. UML permet également outre le fait de se concentrer sur l’utilisateur de
documenter très clairement les besoins exprimés par ces derniers, dans le cadre d’une gestion de
projet de développement qui va de la conception jusqu’au déploiement de l’application dans le
réseau. [3]

Figure 5 : Logo langage de modélisation UML

Conclusion
Ce chapitre est une partie introductive de notre projet, au cours duquel nous avons présenté le
cadre général de notre travail. Nous avons introduit, en premier lieu, l’organisme d’accueil,
ensuite, nous avons cité les solutions existantes et critiqué l’existant, puis, nous avons proposé
une solution et enfin nous avons mis l’accent sur la méthode du travail adoptée.

11
 Chapitre 2 : Sprint 0 : Préparation des bases de projet

Introduction
Pour amorcer le développement de notre application, nous débutons par la phase de
spécification afin d'organiser efficacement notre projet, identifier les tâches nécessaires et
mettre en place la méthodologie Scrum. Cette étape consiste à définir les besoins fonctionnels
et non fonctionnels, les différents intervenants du projet, le product backlog de et l'architecture
technique de notre application. De plus, nous allons élaborer un diagramme général des cas
d'utilisation et un diagramme de classes. Enfin, nous allons présenter l'environnement de
développement ainsi que les technologies que nous allons utiliser.

1.1 Capture des besoins

1.1.1 Identification des acteurs

Un acteur est toute entité, réelle ou conceptuelle, qui interagit avec le système pour
satisfaire un besoin spécifique.
Dans notre application, nous avons identifié quatre acteurs principaux, que nous décrirons
ci-dessous.

Administrateur : L'administrateur détient le plus haut privilège dans l'application.

Cette personne est habilitée à gérer toutes les fonctionnalités de l'application, notamment
la gestion des utilisateurs et les Rôles.
Responsable technique : est celui qui rassemble toutes les informations décrivant la structure
du système de production. Il élabore la fiche technique des produits, incluant leurs composants,
ainsi que les postes de travail.
Responsable de production : est chargé de gérer les ordres de fabrication (O.F). Il planifie et
optimise les méthodes de production, ainsi que la gestion de la production. Il joue un rôle
d'orchestrateur pour tout ce qui entre et sort des ateliers, en organisant et coordonnant la
production. De plus, il attribue à chaque charge de travail (machine, homme) une charge de
travail spécifique.

12
 Opérateur : L'opérateur est celui qui exécute les opérations au sein de l'atelier.
Il est responsable de lancer les opérations, de le mettre en pause et de le valider. De plus,
il a la possibilité de consulter les informations relatives aux opérations qu'il traite.

1.2 Contexte général du projet

Le diagramme de contexte représente les interactions entre un système et ses acteurs,
en mettant en évidence les flux d'informations entre le système et ses acteurs externes
représentés à la figure 6.

Figure 6 : Diagramme de modélisation de contexte

1.2.1 Besoins Fonctionnels

Les acteurs définissent les fonctionnalités du système à développer, tandis que les besoins
spécifient les interactions d'entrée/sortie du système. Notre application doit offrir aux divers
utilisateurs.

13
L’application doit permettre au acteurs de :
Administrateur :
 S’authentifier
 Gérer les utilisateurs
 Accès sur toutes les fonctionnalités de l’application
 Gérer les rôles.
Responsable technique :
 S’authentifier
 Gérer produits
 Gérer nomenclatures
 Gérer les postes de travail
Responsable de production :
 S’authentifier
 Gérer les opérations de fabrication
 Affecter les opérations de fabrication
 Gérer ordre de fabrication
Opérateur :
 Traiter les opérations

1.2.2 Besoins non Fonctionnels

Les besoins non fonctionnels sont des exigences implicites que le système doit respecter pour
garantir le bon fonctionnement et la qualité de ses fonctionnalités. Ils représentent des
contraintes et des caractéristiques. Dans ce qui suit, nous présentons les besoins non
fonctionnels par ordre prioritaire comme suit :

L'extensibilité et la maintenabilité : du système sont essentielles pour garantir sa pérennité et

sa capacité à évoluer. Le code source doit être commenté et bien documenté, conformément aux
bonnes pratiques de développement, pour faciliter la compréhension et la mise à jour de
l'application. Un code bien structuré permettra d'ajouter de nouvelles fonctionnalités sans
nécessiter de modifications majeures de l'architecture existante. En assurant ces aspects,

14
 l'application pourra être évolutive et extensible pour supporter l'ajout de nouvelles
fonctionnalités dans le futur.
Confidentialité des données : La plateforme doit garantir que seuls les utilisateurs authentifiés
et autorisés ont accès à certaines fonctionnalités. Cela nécessite un processus d'identification et
d'authentification sécurisé pour chaque utilisateur, afin de garantir la traçabilité des opérations
et de limiter l'accès aux données sensibles.

L’ergonomie : L'application doit offrir des interfaces simples, conviviales et non complexes,
afin de garantir une facilité d'utilisation des différentes fonctionnalités. Cela implique une
conception centrée sur l'utilisateur, avec une disposition logique des éléments de l'interface, des
indications claires sur les actions à effectuer et une navigation intuitive.

L’intégrité des données : Il faut garantir la cohérence, la fiabilité, et la pertinence des données.

Internationalisation : Avoir une application multilingue est un critère nécessaire.

1.3 Diagramme de cas d’utilisation global

Dans le diagramme général des cas d'utilisation de la figure 7, tous les cas d'utilisation de base
sont regroupés pour donner une vue d'ensemble du fonctionnement du système. Cela permet
également de mettre en évidence les relations qui peuvent exister entre ces différents cas
d'utilisation.
Le diagramme de cas d’utilisation de la figure 7 schématise les fonctionnalités du module
gestion de production.

15
 Figure 7: Diagramme de cas d'utilisation
global

1.4 Backlog Product

Le backlog est une liste ordonnée des fonctionnalités à développer dans une application.
Ces fonctionnalités sont décrites sous forme de besoins et sont priorisées par le Product
Owner pour définir l'ordre dans lequel elles doivent être réalisées. Le tableau ci-dessous
montre toutes les histoires utilisateurs, chacune étant identifiée par un identifiant, un nom
et une estimation de l'effort nécessaire.
Le backlog comprend les champs de base suivants :
 Le champ ID qui détermine un identifiant unique pour l’histoire en question.
 Le champ User story qui décrit de manière claire et succincte la fonctionnalité désirée
par l’utilisateur.

16
  La priorité définit l'ordre de développement, Il peut être exprimé en termes de niveaux
tels que Haute(1), moyen(2) et faible(3).
Le champ estimation estime charge de travail, Elle peut être exprimée en termes de temps
(heures, jours) ou d'effort relatif (points d'histoire). [4]

Tableau 2: Backlog Product

Prior
Sprint Fonctionnalité ID User Story Estimation
ité
1.1 En tant qu’administrateur, je dois 1
pouvoir m’authentifier.

1.2 En tant qu’administrateur, je dois 1

pouvoir gérer les rôles.
1.3 En tant qu’administrateur, je dois 1
pouvoir gérer les comptes. Moyenne
Authentification
1.4 En tant que responsable technique, 1
Sprint 1 , Gérer
je dois pouvoir m’authentifier.
les comptes
1.5 En tant que responsable de 1
production, je dois pouvoir
m’authentifier.
1.6 En tant qu’un opérateur, je dois 1
pouvoir m’authentifier.
2.1 En tant que responsable technique, 1
je peux créer un produit.

Elevée
2.2 En tant que responsable technique, 1
je peux éditer les informations
Sprint 2 Gestion des
d’un produit.
produits
2.3 En tant que responsable technique, 2
je peux supprimer un produit.

17
 2.4 En tant que responsable
technique, je peux créer une
1 Elevée
nomenclature.

2.5 En tant que responsable

technique, je peux éditer les
informations d’une 2
nomenclature.

2.6 En tant que responsable

technique, je peux supprimer 2
nomenclature.
Gestion des
Sprint 2 2.7 En tant que responsable
nomenclatures
technique, je peux ajouter les 2
composants à une
nomenclature.
2.8 En tant que responsable
Moyenne
technique, je peux éditer les 2
composants à d’une
nomenclature.
2.9 En tant que responsale
technique, je peux supprimer 2
des composants à d’une
nomenclature.
3.1 En tant que responsable
technique, je peux créer une
1
poste de travail.
Gestion des
3.2 En tant que responsable
postes de travail technique, je peux éditer les Moyenne
informations d’une poste de
travail. 2

3.3 En tant que responsable 2

technique, je peux supprimer
une poste de travail.

18
 4.1 En tant que responsable de
production, je peux créer un 1
ordre de fabrication.
4.2 En tant que responsable de
Production, je peux éditer les 1
informations d’un ordre de
Elevée
fabrication.
Gestion des
Sprint 3 4.3 En tant que responsable
ordres de
fabrication, de production, je peux 2
supprimer un ordre de
fabrication.

En tant que responsable de

4.4 production, je peux créer une
opération et l’affecter à un 1
Gestion des ordre de fabrication.
opérations Moyenne
4.6 En tant que responsable de
production, je peux éditer une 1
opération de fabrication.
4.7 En tant que responsable de
production, je peux supprimer 1
une opération de fabrication.

5.1 En tant qu'opérateur, je peux 1

démarrer un ordre de travail
depuis ma tablette.
Gestion de
Sprint 4 5.2 En tant qu'opérateur, je peux
ordre de travail Elevée
mettre en pause un ordre de 1
travail en cours depuis ma
tablette.

19
 En tant qu'opérateur, je peux
terminer un ordre de travail
depuis ma tablette.
5.4 En tant qu'opérateur, je peux 1
déclarer la quantité produite
chaque heure depuis ma
tablette.

1.5 Planification des Sprints

La planification du sprint est une cérémonie Scrum qui lance le sprint. Elle a pour objectif de
définir ce qui peut être livré dans le sprint et comment y parvenir. La planification du sprint est
effectuée en collaboration avec toute l’équipe Scrum.

Tableau 3: Planification des sprints

Sprint Date de début Date de fin

Sprint 1 : Gestion des comptes des 15/02/2024 1/03/2024
utilisateurs, authentification.
Sprint 2 : Gestion des produits, Gestion des 2/03/2024 20/03/2024
nomenclatures,Gestion des postes de travail.
Sprint 3 : Gestion des ordres de fabrication. 21/03/2024 10/04/2024
Sprint 4 : Gestion des ordres de travail. 11/04/2024 10/05/2024

1.6 Diagramme de classe

Les diagrammes de classes sont l'un des types de diagrammes UML les plus utiles,
car ils décrivent clairement la structure d'un système particulier en modélisant ses classes,
ses attributs, ses opérations et les relations entre ses objets.

20
 User : Chaque utilisateur a un rôle à savoir un responsable technique, un

responsable de production, opérateur et l’administrateur.

 Nomenclature : Regroupe les informations relatives à une nomenclature.

 Composant : Définit les composants d’une nomenclature avec la quantité

requise.

 Poste de travail : Contient des informations relatives à une machine de fabrication.

 Opération : Contient des informations relatives à une opération de fabrication

contenant la durée ainsi que la machine sur laquelle se déroule l’opération.

 Fabrication : Contient des informations relatives à un ordre de fabrication.

 ListeOpération: Garde le suivi de chaque opération effectuée avec l’état démarrée,

En pause et terminée.

21
 Figure 8 : Diagramme de classe
globale

1.7 Environnement de travail

Dans le cadre de la mise en place de notre système, nous avons opté pour un environnement
de développement robuste, combinant des équipements matériels performants avec des logiciels
spécialisés. Cette configuration nous a permis d'assurer la cohérence et la fluidité de notre
processus d'implémentation, en garantissant la compatibilité et l'efficacité des outils utilisés tout
au long du développement.

1.7.1 Environnement matériel

Pour réaliser notre travail, nous avons utilisé comme environnement matériel un ordinateur
portable de marque « HP » avec un système d’exploitation Windows 11 de 64 bits, ayant
processeur Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz 1.99 GHz, doté d’une Ram de 16
GO..

22
1.7.2 Environnements logiciels

Dans cette partie, nous présentons l’environnement logiciel de notre application de point de
vue langages, Framework, Logiciels et technologies.

1. Langages et Technologies

Dans le tableau suivant, Il y’a une description des langages et technologies utilisés lors du
développement tels que Flutter, HTML et CSS3 dans l’aspect graphique de l’application.

Tableau 4: Tableau des langages utilisés

Langages Description
Un Framework open source pour le développement d'applications
mobiles multiplateformes avec Dart.

Un langage de programmation polyvalent et largement utilisé, idéal

pour le développement back end, l'analyse de données et
l'automatisation.
Un langage de marquage standard pour l'organisation et le partage
de données.

Langage de balisage utilisé pour la création de pages web,

permettant notamment de définir des liens hypertextes.

Le langage CSS est employé pour déterminer le style de

l’application. Le CSS (ou feuille de style), est un document au
travers duquel nous avons défini le choix de couleurs, type de
police, positions.
JavaScript, souvent abrégé en JS, est un langage de programmation
de scripts léger, interprété et versatile. Il est couramment utilisé pour
ajouter des fonctionnalités interactives aux pages Web.

23
2. Logiciels

Dans le tableau qui suit, Il y’a une description des logiciels utilisés lors du développement de
l’application.
Tableau 5: Tableau des logiciels utilisés

Logiciels Description
Un environnement de développement intégré (IDE) populaire pour
Python et d'autres langages.

Un progiciel de gestion intégré (ERP) open source, offrant une suite

d'outils pour la gestion d'entreprise. [5]

Visual Studio Code est un éditeur de code extensible développé par

Microsoft par Windows, Linux et MacOs.

Google chrome : C’est un navigateur internet développé par Google.

Ce navigateur est sur le marché depuis 2008 et fonctionne sur
différentes plateformes (PC, tablettes, smartphone ...) et sous différents
OS (Windows, mac, Linux, Android). [6]

Canva est une plate-forme de conception graphique australienne,

utilisée pour créer des graphiques de médias sociaux, des
présentations, des affiches, des documents et d'autres contenus visuels.
L'application comprend des modèles que les utilisateurs peuvent
utiliser.

3. Serveur SGBDRO

Dans le tableau suivant, Il y’a une description de SGBDRO utilisés lors du développement
de l’application.

24
 Tableau 6 : Tableau de serveur utilisé

Serveur Description
PostgreSQL, abrégé en Postgres, est un système de gestion de base de
données relationnelle et objet (SGBDRO) libre, puissant et open
source. Il est comparable aux autres SGBD, qu'ils soient libres ou
propriétaires, et se distingue par plusieurs atouts.

1.8 Architecture du système

L'application doit impérativement être capable de communiquer entre ses composants. Par
conséquent, le travail sera divisé en deux parties :
 Une application Odoo où se trouvent les différents modules composant notre
système.
 La partie mobile servira d'interface utilisateur pour les opérateurs, leur permettant
de consulter et de traiter les ordres de fabrication directement depuis leurs appareils
mobiles, en synchronisation avec l'application Odoo.

Figure 9: Architecture de la solution

Odoo adopte le modèle MVC avec une séparation stricte entre le modèle de données, la vue et
les traitements, alors on peut appliquer cette sémantique de Model-View-Controller avec :
•Modèle : les modèles sont les objets déclarés dans Odoo. Ils sont également des tables
PostgreSQL.
•Vue : les vues sont définies en fichiers XML dans Odoo.
•Sécurité : Elle est assurée par un système d’authentification et d’autorisation pour protéger les
données personnelles.

25
 •Contrôleur : le contrôleur est Python qui contrôle Odoo. L’avantage majeur apporté par ce
modèle est la clarté de l’architecture qu’il impose, ce qui simplifie la tâche pour les développeurs
souhaitant effectuer une maintenance ou une prochaine amélioration sur le projet. [7]
1.8.1 Service web

Notre application mobile communique de manière transparente avec Odoo grâce

à l'API REST. Cette technologie nous permet d'échanger efficacement des données entre
les deux systèmes, assurant ainsi une intégration fluide et une expérience utilisateur optimale.

 l'API REST est une architecture logicielle qui définit un ensemble de conventions pour
la création de services web. Cette architecture repose sur plusieurs principes, tels que
l'utilisation des méthodes HTTP, l'identification des ressources par des URI, l'utilisation
de formats de données standard comme XML, et la gestion de l'état de manière stateless.
[8]

Figure 10 : Architecture de la service web

Conclusion
Pendant ce chapitre, nous avons établi un plan de travail,
identifié les besoins fonctionnels et non fonctionnels de notre
application, défini les rôles des utilisateurs, puis présenté le
backlog de notre système. Ensuite, nous avons détaillé la
planification des sprints. Nous allons maintenant passer à notre
premier déploiement dans le prochain chapitre.

26
 Chapitre 3 : Sprint 1« Gestion des comptes,
authentification »

Introduction
Ce premier sprint est centré sur l'analyse, la conception des fonctionnalités d'authentification pour
l'administrateur, l’opérateur, responsable de production, responsable technique. Son but est de leur
permettre d'accéder aux différentes fonctionnalités de l'application.

1.1 Backlog du Sprint 1

Tableau 7 : Backlog sprint 1

Fonctionnalité ID User story Acteurs

1.1 En tant qu’administrateur, je dois  Administrateur

S’authentifier pouvoir m’authentifier.  Opérateur
 Responsable
1.2 En tant qu’un opérateur, je dois Technique
pouvoir m’authentifier.  Responsable de
1.3 En tant que responsable technique,
Production
je dois pouvoir m’authentifier.

1.4 En tant que responsable de

production, je dois pouvoir
m’authentifier.
2.1 En tant qu’administrateur, je dois  Administrateur
Gérer les
pouvoir gérer les rôles.
utilisateurs
En tant qu’administrateur, je dois
pouvoir gérer les comptes.

27
1.2 Diagrammes des cas d’utilisations détaillée du Sprint n°1

Figure 11 : Diagramme du cas d’utilisation

détaillé « Sprint1 »

1.2.1 Description textuelle du cas de « s’authentifier »

 Le tableau présente la description textuelle du cas de « s’authentifier »

28
 Tableau 8 : Description textuelle du cas de

« s’authentifier »

Titre S’authentifier
Acteurs Administrateur, responsable de production, responsable technique, operateur

Objectif L’acteur introduit son login et mot de passe pour accéder au système.

Pré condition L’acteur doit avoir un login et un mot de passe.

Post condition L’utilisateur se connecte au système et peut ainsi accéder aux différentes
fonctionnalités.

Scénario nominal -Le système affiche l’écran d’authentification.

-L’utilisateur saisit le login et le mot de passe.
-Il clique sur le bouton « Login »
-Le système vérifie la validité des champs et s'ils ne sont pas vides.
-Le système vérifie si le login et le mot de passe sont correctement saisis.
-Si l’identifiant et le mot de passe sont valides alors le système redirige
l’acteur vers sa page d’accueil spécifique selon son rôle

Scénario -Si les informations saisies ne sont pas valides, le système affiche un
alternatif
message d’erreur et affiche de nouveau l’écran d’authentification.
-Exception : Le système affiche le message : « Wrong login/password»

29
1.2.2 Gérer les comptes

Figure 12 : Raffinement de cas d’utilisation «

gérer les comptes »

 Le tableau présente la description textuelle du cas d’utilisation consulter les comptes

Tableau 9 : Description textuelle du cas de

« Consulter les comptes »

Titre Consulter les comptes

Acteur Administrateur

Objectif L’admin a la possibilité de consulter les comptes.

Pré condition -Acteur authentifié.

-Opération de consultation choisie.
Post condition - Compte consulté.

Scénario de base -s’authentifier.

-L’acteur choisit la consultation de son compte.
- Le système fournit l’interface de consultation du compte.

30
  Le tableau présente la description textuelle du cas d’utilisation Modifier les comptes

Tableau 10: Description textuelle du cas de

« Modifier les comptes »

Titre Modifier les comptes

Acteur Administrateur

Objectif L’acteur est permis de modifier les coordonnées relatives à les

comptes.

Pré condition -Acteur authentifié.

-Opération de modification choisie.

Post condition Compte modifié.

Scénario de base -S’authentifier.

- Consulter les Comptes.
-L’acteur saisit les modifications souhaitées.
-L’acteur valide les modifications.
-Le système vérifie les modifications.
-Le système enregistre les modifications.

 Le tableau présente la description textuelle du cas d’utilisation Suppression des comptes

Tableau 11 : Description textuelle du cas de

« Supprimer les comptes »

Titre Supprimer les comptes

Acteur Administrateur

Objectif L’acteur peut supprimer les comptes.

31
 Pré condition -Acteur authentifié.
-Opération de suppression choisie.

Post condition Compte supprimer.

Scénario de base -S’authentifier.

- Consulter les Comptes.
- L’acteur choisit la suppression des comptes.
- Le système demande la confirmation de l’opération.
- L’acteur valide l’opération.
- Le système supprimer le compte de l’acteur.

1.2.3 Gérer les Rôles

Figure 13 : Raffinement de cas d’utilisation «

gérer les rôles »

 Le tableau présente la description textuelle du cas de « Ajouter rôle »

Tableau 12 : Description textuelle du cas de

« Ajouter rôle »

32
 Titre Ajouter rôle

Acteur Administrateur

Objectif L’acteur peut gérer les rôles.

Pré condition -L’admin doit être authentifié.

- Une connexion au serveur doit être établie
Scénario de - L’admin appuie les boutons « Technique puis Rubriques »
base
- Le système affiche l’interface de la liste des rôles.
- L’admin renseigne les données nécessaires
- Le système vérifie la saisie des données
- Le système traite la requête d’ajout.
Post condition Le rôle ajouté avec succès.

1.3 Diagrammes de séquence du Sprint n°1

Dans cette étape, nous allons créer des diagrammes de séquence pour différents cas
d'utilisation. Cela nous permettra de détailler les scénarios de notre application en mettant
l'accent sur la chronologie des événements.

1.3.1 Diagramme de séquence du cas « s’authentifier »

Le diagramme de séquence du cas d’utilisation s’authentifier est présenté par la figure

suivante :

33
 Figure 14: Diagramme de séquence de cas
« S’authentifier »

1.3.2 Diagramme de séquence du cas « Gérer les Utilisateurs »

Le diagramme de séquence du cas d’utilisation de gérer les utilisateurs est présenté par la
figure suivante :

34
 Figure 15: Diagramme de séquence

de cas « Gérer les utilisateurs »

1.3.3 Diagramme de séquence du cas « Gérer rôle »

35
Le diagramme de séquence du cas d’utilisation de gérer les rôles est présenté par la figure
suivante :

Figure 16 : Diagramme de séquence de

cas « Gérer les rôles »

36
1.4 Diagramme de classe

Un diagramme de classes est un outil visuel utilisé en génie logiciel pour représenter la
structure d'un système orienté objet. Il permet de modéliser les classes, leurs attributs, leurs
méthodes et les relations entre elles.

1.4.1 Composants d'un diagramme de classes

 Classes : Les classes sont représentées par des rectangles. Elles regroupent les objets qui
partagent les mêmes caractéristiques et le même comportement. Le nom de la classe est écrit
en haut du rectangle.
 Attributs : Les attributs représentent les propriétés des objets d'une classe. Ils sont listés dans
le rectangle de la classe, sous son nom. Chaque attribut est décrit par son nom, son type de
données et sa visibilité (public, privé, etc.).
 Méthodes : Les méthodes représentent les actions que les objets d'une classe peuvent effectuer.
Elles sont également listées dans le rectangle de la classe, sous les attributs. Chaque méthode
est décrite par son nom, ses paramètres de retour et ses paramètres d'entrée.
 Relations : Les relations représentent les liens entre les classes. Elles sont représentées par des
traits reliant les rectangles des classes. Il existe différents types de relations, notamment :
o Association : Une association représente une relation simple entre deux classes. Elle
est représentée par un trait non dirigé.
o Agrégation : Une agrégation est un type d'association où une classe (partie) est
composée d'objets d'une autre classe (tout). Elle est représentée par un trait avec un
diamant à l'extrémité de la partie.
o Composition : Une composition est un type d'agrégation plus forte où la vie des objets
de la partie est liée à la vie de l'objet du tout. Elle est représentée par un trait avec un
losange noir à l'extrémité de la partie.
o Héritage : L'héritage est une relation entre une classe (classe fille) et une autre classe
(classe parente). Elle permet à la classe fille d'hériter des attributs et des méthodes de
la classe parente. Elle est représentée par un triangle inversé reliant la classe fille à la
classe parente. [9]

37
1.4.2 Diagramme de classe de conception S’authentifier

Ce diagramme décrit les attributs et les méthodes de chaque classe du cas d’utilisation
S’authentifier ainsi que les relations entre ces classes.

Figure 17: Diagramme de classe du

« s’authentifier»

1.4.3 Diagramme de classe de conception Gérer Compte

Ce diagramme décrit les attributs et les méthodes de chaque classe du cas d’utilisation Gérer les
Comptes ainsi que les relations entre ces classes.

38
 Figure 18 : Diagramme de classe du « Gérer
les comptes »

Conclusion

Pendant ce premier Sprint , nous avons d'abord structuré notre Backlog Sprint pour définir les
user stories à réaliser, puis nous avons créé les diagrammes de cas d'utilisation, de classes et de
séquences correspondant à ce sprint. Dans le prochain chapitre, nous entamerons le Sprint n°2,
qui se concentrera sur Gestion des produits, Gestion des nomenclatures et Gestion des poste de
travail.

39
Chapitre 4 : Sprint 2 « Gestion des produits, Gestions des
nomenclatures, Gestion des postes de travail »

Introduction

Ce chapitre est consacré pour décrire l’analyse, la conception du deuxième sprint. Ce sprint a pour
objectif de permettre à responsable technique de gérer gestion des produits, gestion des nomenclatures
et gestion des postes de travail.

1.1 Backlog Sprint

Tableau 13 : Backlog sprint 2

Fonctionnalité ID User story Acteurs

1.1 En tant que responsable

technique, je peux créer un
produit.
1.2 En tant que responsable
technique, je peux éditer les
Gestion des informations d’un produit.
produits 1.3 En tant que responsable
technique, je peux supprimer
un produit.  Responsable
technique

Gestion des 2.1 En tant que responsable

nomenclatures technique, je peux créer une
nomenclature.
2.2 En tant que responsable
technique, je peux éditer les
informations d’une
nomenclature.

40
 2.3 En tant que responsable
technique, je peux supprimer
nomenclature.

2.4 En tant que responsable

technique, je peux ajouter les
composants à une
nomenclature.

2.5 En tant que responsable

technique, je peux éditer les
composants à d’une
nomenclature.

2.6 En tant que responsale

technique, je peux supprimer
des composants à d’une
nomenclature.

3.1 En tant que responsable

technique, je peux créer une
poste de travail.

Gestion 3.2 En tant que responsable

des postes technique, je peux éditer les
informations d’une poste de
de travail
travail.

3.3 En tant que responsable

technique, je peux supprimer
une poste de travail.

1.2 Diagramme de cas d’utilisation Gérer produits

Le diagramme illustré par la figure 19 montre les fonctionnalités liées à la gestion des produits.

41
z

Figure 19 : Diagramme de cas d'utilisation

« Gérer les produits »

 Le tableau présente la description textuelle du cas de « Gérer les produits »

Tableau 14 : Description textuelle du cas de

« Gérer les produits »

Titre Gérer les produits

Acteur Responsable technique

Objectif L’objectif de ce cas d’utilisation est d’ajouter, d’éditer et de supprimer

un produit.
Pré condition L’utilisateur est authentifié.

Post conditions -Nouveau produit validé figure dans la liste des produits.
- Le produit supprimé n’existe plus dans la liste des produits.

42
  Ajouter un produit :
- L’utilisateur demande au système d’ajouter un produit.
Scénario
nominal - Le système affiche le formulaire de gestion des produits
- L’utilisateur saisit toutes les informations du produit (Nom de produit,
unité de stock, fournisseur, type de produit, prix d’achat...). Puis, il
demande au système de valider les informations saisies.
- Le système vérifie que toutes les données obligatoires sont saisies
correctement, et vérifie l’existence du produit. Dans le cas où ce dernier
existe déjà, le système déclenche l’exception 1. Si toutes les
informations sont validées, le système enregistre le nouveau produit
puis affiche la liste des produits.
 Modifier fiche produit :
- L’utilisateur accède au formulaire de gestion des produits.
- L’utilisateur parcourt la liste des produits, sélectionne un produit selon
un critère de recherche.
- Le système affiche l’interface de produit.
- L’utilisateur modifie les informations qui peuvent être modifiées.
Puis, valider les informations saisies.
- Le système vérifie les informations modifiées et les enregistre.
 Supprimer un produit :
- L’utilisateur parcourt la liste des produits, sélectionne un produit et
demande au système de supprimer ce produit.
- Le système affiche l’interface de suppression.
- Si l’utilisateur confirme la suppression alors le système vérifie et
supprimer.

43
1.3 Diagramme de cas d’utilisation Gérer nomenclatures

Le diagramme illustré par la figure 20 montre les fonctionnalités liées à la gestion des nomenclatures.

Figure 20: Diagramme de cas d'utilisation

« Gérer Nomenclatures »

 Le tableau présente la description textuelle du cas de « Gérer nomenclatures »

Tableau 15: Description textuelle du cas de

« Gérer Nomenclatures »

Titre Gérer nomenclatures

Acteur Responsable technique

Objectif L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, consulter et de

supprimer une nomenclature.
Pré L’utilisateur est authentifié.
condition

Post -La nouvelle nomenclature validée figure dans la liste des

conditions
nomenclatures.
- La nomenclature supprimée n’existe plus dans la liste des
nomenclatures.

44
  Ajouter une nomenclature :

- L’utilisateur demande au système d’ajouter une nomenclature.

- Le système affiche le formulaire de création d’une
nomenclature.
- L’utilisateur saisit toutes les informations générales du
nomenclature (référence, produit, quantité, type nomenclature).
- Par la suite, l’utilisateur sélectionne les composants de la
Scénario nominal
nomenclature tout en spécifiant les quantités pour chaque
composant, puis il demande au système de valider les
informations saisies.
- Le système vérifie que toutes les donnée obligatoires sont saisies
correctement.
- Si toutes les informations sont validées, le système enregistre la
nouvelle nomenclature puis affiche la liste des nomenclatures.
 Modifier nomenclature :
- L’utilisateur accède au formulaire de gestion des nomenclatures.
- L’utilisateur parcourt la liste des nomenclatures, sélectionne une
nomenclature selon un critère de recherche.
-. Le système affiche l’interface de nomenclature.
-L’utilisateur modifie les informations qui peuvent être modifiées,
Puis valider les informations saisies.
-Le système vérifie que toutes les obligatoires sont saisies
correctement et les enregistre.
 Supprimer une nomenclature :
-L’utilisateur parcourt liste des nomenclatures sélectionne et
demande au système de supprimer cette nomenclature.
-Le système affiche l’interface de suppression.
-l’utilisateur confirme la suppression.
-le système vérifie et supprimer.

45
1.4 Diagramme de cas d’utilisation Gérer poste de travail

Le diagramme illustré par la figure 21 montre les fonctionnalités liées à la gestion de poste de
travail.

Figure 21 : Diagramme de cas d'utilisation

« Gérer poste de travail »

 Le tableau présente la description textuelle du cas de « Gérer poste de travail »

Tableau 16 : Description textuelle du cas de

« Gérer poste de travail »

46
 Titre Gérer poste de travail

Acteur Responsable technique

Objectif L’objectif de ce cas d’utilisation est d’ajouter, d’éditer,

chercher et de supprimer une poste de travail.
Pré condition l’utilisateur est authentifié.

-Nouvelle poste validée figure dans la liste des postes.

Post conditions - La poste supprimée n’existe plus dans la liste de poste de
travail.

 Ajouter une poste de travail:

- L’utilisateur demande au système d’ajouter une poste de

Scénario nominal
travail.
- Le système affiche le formulaire de création d’une poste.
- L’utilisateur saisit toutes les informations générales du
poste (nom, Heures de travail..).

- Le système vérifie que toutes les donnée obligatoires sont

saisies correctement.
- Si toutes les informations sont validées, le système
enregistre la nouvelle poste puis affiche la liste de poste .
 Modifier poste de travail :
- L’utilisateur accède au formulaire de gestion de poste.
- L’utilisateur parcourt la liste de poste, sélectionne une
poste selon un critère de recherche.
-. Le système affiche l’interface de poste.
-L’utilisateur modifie les informations qui peuvent être
modifiées, Puis valider les informations saisies.

47
 -Le système vérifie que toutes les obligatoires sont saisies
correctement et les enregistre.

 Supprimer une nomenclature :

-L’utilisateur parcourt liste de poste sélectionne et demande
au système de supprimer cette nomenclature.
-Le système affiche l’interface de suppression.
-l’utilisateur confirme la suppression.
-le système vérifie et supprimer.

1.5 Diagrammes de séquence du Sprint n°2

Dans cette partie nous allons modéliser les diagrammes de séquences pour certains cas
d’utilisation, ce qui permettra de mieux détailler les scénarios de notre application en mettant
l’accent sur l’aspect chronologique de la séquence.

1.5.1 Diagramme de séquence du cas « Gérer produit »

48
 Le diagramme de séquence du cas d’utilisation de gérer les produits est présenté par la figure
Suivante:

Figure 22: Diagramme de séquence de cas

« Gérer produit »

1.5.2 Diagramme de séquence du cas « Gérer nomenclature »

Le diagramme de séquence du cas d’utilisation de gérer nomenclature est présenté par la figure
suivante :

49
 Figure 23 : Diagramme de séquence de cas
« Gérer nomenclature »

1.5.3 Diagramme de séquence du cas « Gérer poste de travail »

Le diagramme de séquence du cas d’utilisation de gérer poste de travail est présenté par la figure
suivante :

50
 Figure 24 : Diagramme de séquence de cas
« Gérer poste de travail »

1.6 Diagramme de classe

Un diagramme de classes est un outil visuel utilisé en génie logiciel pour représenter la
structure d'un système orienté objet. Il permet de modéliser les classes, leurs attributs, leurs
méthodes et les relations entre elles.

51
1.6.1 Diagramme de classe de conception Gérer produit

Ce diagramme décrit les attributs et les méthodes de chaque classe du cas d’utilisation Gérer
Produit ainsi que les relations entre ces classes.

Figure 25: Diagramme de classe du

« Gérer les produits »

52
1.6.2 Diagramme de classe de conception Gérer Nomenclature

Ce diagramme décrit les attributs et les méthodes de chaque classe du cas d’utilisation Gérer
Nomenclature ainsi que les relations entre ces classes.

Figure 26 : Diagramme de classe du

« Gérer nomenclatures »

1.6.3 Diagramme de classe de conception Gérer Poste de travail

Ce diagramme décrit les attributs et les méthodes de chaque classe du cas d’utilisation Gérer Poste
de travail ainsi que les relations entre ces classes.

53
 Figure 27 : Diagramme de classe du
« Gérer les postes »

Conclusion

Pendant ce deuxième Sprint, nous avons d'abord structuré notre Backlog Sprint pour définir les
user stories à réaliser, puis nous avons créé les diagrammes de cas d'utilisation, de classes et de
séquences correspondant à ce sprint. Dans le prochain chapitre, nous entamerons le Sprint n°3,
qui se concentrera sur Gestion de ordre de fabrication, Gestion des opération.

54
Chapitre 5 : Sprint 3 « Gestion des ordres de fabrication,
Gestion des opérations »
Introduction

Ce chapitre est consacré pour décrire l’analyse, la conception du troisième sprint. Ce sprint a pour
objectif de permettre à responsable de production de gérer gestion de ordre de fabrication et gestion des
opération.

1.1 Backlog Sprint

Tableau 17: Backlog sprint 3

Fonctionnalité ID User story Acteurs

1.1 En tant que responsable de

production, je peux créer un ordre
de fabrication.
Gestion des
1.2 En tant que responsable de
ordres de
fabrication, Production, je peux éditer les
informations d’un ordre de
fabrication.
1.3 En tant que responsable
 Responsable
de production
de production, je peux supprimer un
ordre de fabrication.
2.1 En tant que responsable de
Gestion des production, je peux créer une
opérations opération et l’affecter à un ordre de
fabrication.
2.2 En tant que responsable de
production, je peux éditer une
opération de fabrication.

55
 2.3 En tant que responsable de
production, je peux supprimer une
opération de fabrication.

1.2 Diagramme de cas d’utilisation Gérer les ordres de fabrication

Le diagramme illustré par la figure 28 montre les fonctionnalités liées à la gestion de ordre de
fabrication.

Figure 28 : Diagramme de cas d'utilisation

« Gérer ordre de fabrication »

 Le tableau présente la description textuelle du cas de « Gérer ordre de fabrication »

Tableau 18 : Description textuelle du cas de
« Gérer ordre de fabrication »

Titre Gérer ordre de fabrication

Acteur Responsable de production

Objectif L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, chercher

et de supprimer un ordre de fabrication.

56
Pré condition L’utilisateur est authentifié.

Post conditions -Nouvel ordre de fabrication validée figure dans la liste des
ordres de fabrication.
- L’ordre de fabrication supprimée n’existe plus dans la liste
des ordres de fabrication.
Scénario nominal  Ajouter ordre de fabrication :
-L’utilisateur demande au système d’ajouter un ordre de
fabrication.
- Le système affiche le formulaire de création d’un ordre de
fabrication.
- L’utilisateur saisit toutes les informations nécessaires (date
planifiée, quantité, responsable).
- Par la suite l’utilisateur sélectionne le produit à fabriquer.
- L’utilisateur sélectionne un responsable pour cet ordre de
fabrication.
- Le système vérifie que le produit sélectionné possède déjà une
nomenclature sinon il déclenche l’exception 1.
-Si toutes les informations sont validées, le système enregistre
le nouvel ordre de fabrication puis affiche la liste des ordres de
de fabrications.
 Modifier ordre de fabrication :
- L’utilisateur accède au formulaire de gestion des ordres de
fabrications.
- L’utilisateur parcourt la liste des ordres de fabrications,
sélectionne un ordre de fabrication selon un critère de
recherche.
- Le système affiche l’interface de ordre.
-L’utilisateur modifie les informations qui peuvent être
modifiées, Puis valider les informations saisies.
-Le système vérifie que toutes les obligatoires sont saisies
correctement et les enregistre.

57
  Supprimer ordre de fabrication :
-L’utilisateur parcourt liste de ordre sélectionne et demande au
système de supprimer cette ordre de fabrication.
-Le système affiche l’interface de suppression.
-l’utilisateur confirme la suppression.

1.3 Diagramme de cas d’utilisation Gérer les opérations

Le diagramme illustré par la figure 29 montre les fonctionnalités liées à la gestion des opérations.

Figure 29 : Diagramme de cas d'utilisation

« Gérer les opérations »

 Le tableau présente la description textuelle du cas de « Gérer les opérations »

Tableau 19 : Description textuelle du cas de

« Gérer les opérations »

58
 Titre Gérer les opérations

Acteur Responsable de production

Objectif L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, chercher

et de supprimer une opération.
Pré condition L’utilisateur est authentifié.

Post conditions -Nouvel opération validée figure dans la liste des opérations.
- L’opération supprimée n’existe plus dans la liste des opérations.
Scénario  Ajouter une opération :
nominal
-L’utilisateur demande au système d’ajouter une opération.
- Le système affiche le formulaire de création d’une opération.
- L’utilisateur saisit toutes les informations nécessaires (opération,
durée).
- Par la suite l’utilisateur sélectionne nomenclature.
- L’utilisateur sélectionne une poste de travail pour cette
opération.
-Si toutes les informations sont validées, le système enregistre la
nouvelle opération puis affiche la liste des opération.
 Modifier une opération :
- L’utilisateur accède au formulaire de l’opération.
- L’utilisateur parcourt la liste des opérations, sélectionne une
opération selon un critère de recherche.
- Le système affiche l’interface de l’opération .
-L’utilisateur modifie les informations qui peuvent être modifiées,
Puis valider les informations saisies.
-Le système vérifie que toutes les obligatoires sont saisies
correctement et les enregistre.
 Supprimer une opération :
-L’utilisateur parcourt liste de l’opération sélectionne et demande
au système de supprimer cette opération.
-Le système affiche l’interface de suppression.
-l’utilisateur confirme la suppression.

59
1.4 Diagrammes de séquence du Sprint n°3

Dans cette partie nous allons modéliser les diagrammes de séquences pour certains cas
d’utilisation, ce qui permettra de mieux détailler les scénarios de notre application en mettant
l’accent sur l’aspect chronologique de la séquence.

1.4.1 Diagramme de séquence du cas « Gérer ordre de fabrication »

Le diagramme de séquence du cas d’utilisation de gérer les ordres de fabrication est présenté par
la figure suivante :

Figure 30 : Diagramme de séquence de cas

« Gérer ordre de fabrication »

60
1.4.2 Diagramme de séquence du cas « Gérer les opérations »

Le diagramme de séquence du cas d’utilisation de gérer les opérations est présenté par la figure
suivante :

Figure 31 : Diagramme de séquence de

cas « Gérer les opérations »

61
1.5 Diagramme de classe
Un diagramme de classes est un outil visuel utilisé en génie logiciel pour représenter la
structure d'un système orienté objet. Il permet de modéliser les classes, leurs attributs, leurs
méthodes et les relations entre elles.

1.5.1 Diagramme de classe de conception Gérer ordre de fabrication

Ce diagramme décrit les attributs et les méthodes de chaque classe du cas d’utilisation Gérer ordre
de fabrication ainsi que les relations entre ces classes.

Figure 32 : Diagramme de classe du «

Gérer les ordres de fabrications »

62
1.5.2 Diagramme de classe de conception Gérer les opérations

Ce diagramme décrit les attributs et les méthodes de chaque classe du cas d’utilisation Gérer les
opérations ainsi que les relations entre ces classes.

Figure 33 : Diagramme de classe du

« Gérer les opérations »

Conclusion

Pendant ce troisième Sprint, nous avons d'abord structuré notre Backlog Sprint pour définir les
user stories à réaliser, puis nous avons créé les diagrammes de cas d'utilisation, de classes et de
séquences correspondant à ce sprint. Dans le prochain chapitre, nous entamerons le Sprint n°4,
qui se concentrera sur Gestion de ordre de travail.

63
 Chapitre 6 : Sprint 4 « Gestion des ordres de travail »

Introduction

Ce chapitre est consacré à décrire l’analyse et la conception du quatrième sprint. Ce sprint a pour
objectif de permettre à l'opérateur de gérer les ordres de travail. Dans ce chapitre, nous allons aborder
la gestion des ordres de travail, en distinguant les parties web et mobile de l'application. Nous avons
déjà intégré la partie mobile avec Odoo pour assurer une communication fluide et efficace entre les
différentes composantes du système.

1.1 Backlog Sprint

Tableau 20 : Backlog sprint 4

Fonctionnalité ID User story Acteurs

1.1 En tant qu'opérateur, je peux

démarrer un ordre de travail
depuis ma tablette.

1.2 En tant qu'opérateur, je peux

mettre en pause un ordre de
 Opérateur
Gestion des travail en cours depuis ma
ordres de tablette.
travail

1.3 En tant qu'opérateur, je

peux terminer un ordre de
travail depuis ma tablette.

1.4 En tant qu'opérateur, je

peux déclarer la quantité
produite chaque heure
depuis ma tablette.

64
1.2 Diagramme de cas d’utilisation Traiter opérations de fabrication

Le diagramme illustré par la figure 34 montre les fonctionnalités liées à Traiter opérations de
fabrication.

Figure 34 : Diagramme de cas

d'utilisation « Traiter les opérations
»

 Le tableau présente la description textuelle du cas de « Traiter opérations de fabrication »

Tableau 21: Description textuelle du cas de

« Traiter opérations de fabrication »

Titre Traiter opérations de fabrication

Acteur Opérateur

Objectif L’objectif de ce cas d’utilisation est de commencer, mettre en pause,

terminer une opération de fabrication et de déclarer la quantité produite
chaque heure.
Pré condition L’utilisateur est authentifié.

65
Post -Effectué un traitement sur une opération de fabrication.
conditions - La quantité produite est enregistrée dans le système.
- Les données de production sont mises à jour en temps réel.
Scénario  Commencer opération de fabrication
nominal - L’utilisateur demande au système de consulter un ordre de
fabrication.
- Le système affiche les informations relatives à l’ordre de fabrication
sélectionné.
- L’utilisateur clique sur un bouton pour accéder à l’interface de suivi
des opérations de suivi des opérations.
- L’utilisateur clique sur le bouton lancer pour démarrer une opération
- L'utilisateur accède à l'option pour déclarer la quantité produite.
- L'utilisateur entre la quantité produite pour l'heure en cours.
- L'utilisateur valide la déclaration.
-Le système enregistre l’opération avec la date courante puis affiche la
liste des opérations de fabrications avec le nouvel état de l’opération.
-Le système enregistre la quantité produite et met à jour les données
de production.
 Mettre en pause une opération de fabrication :
- L’utilisateur demande au système de consulter un ordre de
fabrication.
- Le système affiche les informations relatives à l’ordre de fabrication
sélectionné.
- L’utilisateur clique sur un bouton pour accéder à l’interface de suivi
des opérations.
- L’utilisateur clique sur le bouton mettre en pause pour arrêter une
opération.
- Le système enregistre l’opération avec la date courante puis affiche
la liste des opérations de fabrications avec le nouvel état de l’opération.
 Terminer opération de fabrication :
- L’utilisateur demande au système de consulter un ordre de
fabrication.

66
 - Le système affiche les informations relatives à l’ordre de fabrication
sélectionné.
- L’utilisateur clique sur un bouton pour accéder à l’interface de suivi
des opérations.
- L’utilisateur clique sur le bouton terminer pour achever une
opération.
Le système enregistre l’opération avec la date courante puis affiche la
liste des opérations de fabrications avec le nouvel état de l’opération.

1.3 Diagramme de classe

Un diagramme de classes est un outil visuel utilisé en génie logiciel pour représenter la
structure d'un système orienté objet. Il permet de modéliser les classes, leurs attributs, leurs méthodes
et les relations entre elles.

1.3.1 Diagramme de classe de conception Quantité Produite

Ce diagramme décrit les attributs et les méthodes de chaque classe du cas d’utilisation Quantité
produite ainsi que les relations entre ces classes.

67
 Figure 35 : Diagramme de classe du

« Quantité produite »

1.4 Diagrammes d'activité du Sprint n°4

Un diagramme d'activité est un outil visuel utilisé pour modéliser le flux de travail d'un
processus ou d'un système. Il fait partie du langage de modélisation unifié (UML) et permet de
représenter graphiquement les différentes étapes d'un processus, les conditions qui les
déclenchent et les actions qui en découlent.
Fonctionnement d'un diagramme d'activité :
Un diagramme d'activité est composé de plusieurs éléments clés :
 Noeuds d'activité : Ils représentent les différentes étapes du processus. Chaque noeud
d'activité est généralement représenté par une case rectangulaire.
 Bords d'activité : Ils relient les noeuds d'activité et indiquent le flux du processus. Les bords
d'activité peuvent être de différents types, tels que les bords de flux normal, les bords de garde
et les bords de décision.

68
  Objets : Ils représentent les entités sur lesquelles le processus agit. Les objets sont
généralement représentés par des rectangles avec le nom de l'objet en haut.
 Liens : Ils relient les objets aux noeuds d'activité et indiquent comment les objets sont utilisés
dans le processus.

 Swimlanes : Elles permettent de regrouper les noeuds d'activité en fonction des acteurs ou des
rôles impliqués dans le processus. [10]
1.4.1 Diagrammes d'activité Gérer ordre de travail

Figure 36 : Diagramme d’activité du

« Traiter les opérations »

Conclusion

Pendant ce quatrième Sprint, nous avons d'abord structuré notre Backlog Sprint pour définir les
user stories à réaliser, puis nous avons créé les diagrammes de cas d'utilisation, de classes et
d’activité correspondant à ce sprint. Dans le prochain chapitre, nous décrivons la partie
réalisation.

69
 Chapitre 7 : « Réalisation »

Introduction
Dans ce chapitre, nous exposons les différentes étapes de réalisation de notre projet via
l’essentiel des interfaces de notre solution.

1.1 Présentation des interfaces

1.1.1 Présentation des Interfaces Web
1.1.1.1 Dashboard
La figure 37 représente l'interface du tableau de bord offre une vue d'ensemble complète de la
gestion de la production, incluant le suivi des différentes étapes de production, la gestion des
produits, des opérations, des postes de travail, des ordres de fabrication, des ordres de travail, et
des nomenclatures.

Figure 37 : Interface de Tableaux de bord

70
1.1.1.2 Authentification

La figure 38 représente l’interface d’authentification, l'utilisateur doit saisir son identifiant et son mot
de passe.

Figure 38 : Interface d’authentification

1.1.1.3 Gestion des comptes

La figure 39 représente l’interface de gestion des comptes utilisateurs, L’administrateur peut gérer tout
utilisateurs

Figure 39 : Interface de Gestion des comptes

71
1.1.1.4 Ajouter un utilisateur

La figure 40 représente l’interface d’ajout, L’administrateur peut Ajouter un utilisateur

Figure 40 : Interface d’ajouter

un utilisateur

1.1.1.5 Supprimer un utilisateur

La figure 41 représente l’interface de suppression, L’administrateur peut supprimer un utilisateur.

Figure 41 : Interface de supprimer

un utilisateur

72
1.1.1.6 Gestion des rôles

La figure 42 représente l’interface de gestion des rôles, L’administrateur peut gérer les rôles.

Figure 42 : Interface de
Gestion des rôles

1.1.1.7 Ajouter rôle

La figure 43 représente l’interface d’ajout, L’administrateur peut Ajouter rôle.

Figure 43: Interface d’ajouter

les rôles

73
1.1.1.8 Gestion de nomenclature

La figure 44 représente l’interface de gestion de nomenclature, Cette interface permet à responsable

technique de consulter la liste des nomenclatures.

Figure 44: Interface de Gestion

de nomenclature

1.1.1.9 Ajouter une nomenclature

La figure 45 représente l’interface d’ajout, Cette interface permet à responsable technique d’ajouter une
nomenclatures.

Figure 45 : Interface d’ajouter

les nomenclatures

74
1.1.1.10 Supprimer une nomenclature

La figure 46 représente l’interface de suppression d’une nomenclature qui permet au responsable

technique de confirmer la suppression d’une nomenclature sélectionnée.

Figure 46 : Interface de supprimer

les nomenclatures

1.1.1.11 Gestion des produits

La figure 47 représente l’interface de gestion de produit, Cette interface permet à responsable technique
de consulter la liste des produits.

Figure 47 : Interface de Gestion

des produits

75
1.1.1.12 Ajouter un produit

La figure 48 représente l’interface d’ajout, Cette interface permet à responsable technique d’ajouter un
produit.

Figure 48 : Interface d’ajouter

les produits

1.1.1.13 Gestion des postes de travail

La figure 49 représente l’interface de gestion des postes de travail, Cette interface permet à responsable
technique de consulter la liste des postes de travail.

Figure 49: Interface de Gestion

des postes de travail

76
1.1.1.14 Ajouter une poste de travail

La figure 50 représente l’interface d’ajout, Cette interface permet à responsable technique d’ajouter une
poste de travail

Figure 50 : Interface d’ajouter

les postes

1.1.1.15 Gestion des opérations

La figure 51 représente l’interface de gestion des opérations, Cette interface permet à responsable de
production de consulter la liste des opérations.

Figure 51: Interface de Gestion

des opérations

77
1.1.1.16 Ajouter une opération

La figure 52 représente l’interface d’ajout, Cette interface permet à responsable technique d’ajouter une
opération

Figure 52 : Interface d’ajouter

les opérations

1.1.1.17 Gestion des ordres de fabrication

La figure 53 représente l’interface de gestion des ordres de fabrication, Cette interface permet à
responsable de production de consulter la liste des ordres de fabrications

Figure 53 : Interface de Gestion

des ordres de fabrication

78
1.1.1.18 Ajouter un ordre de fabrication

La figure 54 représente l’interface d’ajout, Cette interface permet à responsable de production d’ajouter
un ordre de fabrication

Figure 54 : Interface d’ajouter

les ordres de fabrication

1.1.1.19 Suivi d'un ordre de travail

La figure 55 présente l'interface de l'opérateur ou il peut traiter les opérations de l'ordre de fabrication.
Cette interface contient la liste des opérations ainsi son état (lancer, en cours, en pause, bloquer).

Figure 55: Interface de Suivi d'un

ordre de travail

79
1.1.1.20 Ajouter la quantité produite chaque heure

La figure 56 représente l’interface d’ajout, Cette interface permet à l’opérateur d’ajouter la quantité
produite chaque heure.

Figure 56: Interface d’ajouter

la Quantité produite

1.2 Présentation des interfaces mobile

1.2.1 L’interface de l’application

La figure 57 présente l'interface de l’application.

80
 Figure 57 : Interface de l’application

1.2.3 S’authentifier

La figure 58 représente l’interface d’authentification, l'opérateur doit saisir son identifiant et son mot
de passe.

Figure 58 : Interface de S’authentifier

81
 1.2.4 Suivi d'un ordre de travail

La figure 5 présente l'interface de l'opérateur ou il peut traiter les opérations de l'ordre de fabrication.
Cette interface contient la liste des opérations ainsi son état (lancer, en cours, en pause, bloquer).

Figure 59 : Interface de Suivi d'un

ordre de travail

1.2.5 Ajouter la quantité produite chaque heure

La figure 60 représente l’interface d’ajout, Cette interface permet à l’opérateur d’ajouter la quantité
produite chaque heure

Figure 60 : Interface d’ajouter la Quantité

produite

82
 Conclusion générale
Le capital humain est un facteur de succès au sein des entreprises. De ce fait, savoir gérer efficacement
ses ressources et garantir une communication rapide de l’information joue un rôle stratégique pour
l’entreprise. C’est dans ce cadre que s’inscrit ce projet de fin d’études au sein de la société Warzeez
Solutions. Il consiste à concevoir, implémenter et déployer un module ERP de gestion de production.

Ce module facilite le workflow de fabrication d’un produit depuis la phase de définition des données
techniques jusqu’à la réalisation. Nous avons décomposé cet outil en plusieurs fonctionnalités : la
gestion des postes de travail, la gestion des nomenclatures, la gestion des opérations de fabrication, la
gestion des ordres de fabrication, le suivi de chaque ordre de fabrication, et la déclaration de la quantité
produite chaque heure.

Pour atteindre cet objectif, nous avons commencé par une étude préalable qui a permis de décrire et de
comprendre les principaux concepts des ERP existants sur le marché. Cette étude a également permis
d'identifier les ERP qui automatisent la gestion de production en spécifiant les fonctionnalités
disponibles pour chaque ERP ainsi que les différents choix technologiques adoptés pour la partie web
et la partie mobile.

Nous sommes ensuite passés à l’analyse et la spécification des besoins et exigences. Puis, nous avons
élaboré la forge logicielle de l’outil à développer en commençant par l’architecture adoptée, pour
aboutir par la suite à la conception, qui met l’accent sur l’aspect statique du système. Enfin, nous avons
abordé l’étape de réalisation au cours de laquelle nous avons traduit notre modélisation conceptuelle en
une implémentation physique, en utilisant les différentes technologies et techniques choisies ainsi que
celles exigées par l’entreprise.

Ce travail a été très instructif vu l’énorme quantité de connaissances acquises. Il nous a procuré une
opportunité pour, d’une part, aborder un domaine métier et, d’autre part, confirmer une fois de plus nos
compétences dans le développement web et mobile, en touchant de près plusieurs aspects du cycle de
vie d’un produit logiciel. Par ailleurs, le projet a été une expérience enrichissante et fructueuse puisqu’il
nous a donné l’occasion de mettre à l’épreuve nos connaissances pratiques en matière de conception et
de développement et d’approfondir nos acquis sur le développement web à travers une panoplie de
nouvelles technologies, notamment Odoo. De plus, nous avons intégré Odoo avec une application

83
mobile, permettant une gestion et un suivi des opérations de production directement depuis des
appareils mobiles, ce qui a ajouté une dimension de flexibilité et de réactivité essentielle pour les
utilisateurs sur le terrain.

Dans le cadre des perspectives futures du projet de gestion de production, l'application des techniques
de machine learning pour organiser les ordres de fabrication en fonction des dates de demande des
clients représente une avancée significative. Par exemple, lorsqu'un client fixe une date précise pour la
livraison de sa commande tandis qu'un autre ne spécifie pas de date, le modèle de machine learning
peut organiser les priorités de manière intelligente. Ce modèle contribuera à améliorer l'efficacité du
processus de production en garantissant que les commandes avec des dates fixes soient traitées en
priorité, tout en optimisant l'utilisation des ressources disponibles. En appliquant cette technologie,
nous prévoyons d'obtenir des améliorations tangibles en termes de satisfaction des clients et de
performance globale de l'usine, ouvrant ainsi de nouvelles perspectives pour le développement du
système de gestion de production.

84
 Webographie

[1] mailto:https://slack.com/intl/fr-fr/blog/collaboration/methode-agile projet.

[2] mailto:https://www.journaldunet.fr/web-tech/guide-de-l-entreprise-
digitale/1443834-scrum-maitriser-le-framework-star-des-methodes-agiles/

[3]mailto:https://fr.wikipedia.org/wiki/UML_(informatique)

[4]mailto:https://www.qrpinternational.fr/blog/glossaire/quest-ce-quun-backlog-definition-
etapes-caracteristiques-et-outils/

[5]mailto:https://www.odoo.com/fr_FR

[6]mailto:https://www.google.com/intl/fr/chrome/

[7]mailto:https://odooskills.com/bien-comprendre-architectue-technique-odoo.html

[8]mailto:https://www.talend.com/fr/resources/rest-api/

[9]mailto:https://fr.wikipedia.org/wiki/Diagramme_de_classes

[10] mailto:https://fr.wikiversity.org/wiki/Mod%C3%A9lisation_UML/Le_diagramme

85