Conception Et Développement D'un Module ERP Gestion de La Production

République Tunisienne Cycle de Formation d’Ingénieurs dans
Ministère de l’Enseignement Supérieur la Discipline Génie Informatique

et de la Recherche Scientifique
ST-EN07/00
Université de Sfax Projet de Fin d’Etudes
École Nationale d’Ingénieurs de Sfax N° d’ordre: 2019 / DIMA-016
MEMOIRE
Présenté à
L’Ecole Nationale d’Ingénieurs de Sfax

(Département de Génie Informatique et Mathématiques Appliquées)
En vue de l’obtention
Du Diplôme National d’Ingénieur en Génie Informatique
Par
Mahdi NEIFAR
CONCEPTION ET DÉVELOPPEMENT
D’UN MODULE ERP :
GESTION DE PRODUCTION
Soutenu le 14 novembre 2019, devant la commission d'examen:
Mme. Fadoua DRIRA Présidente

Mme. Manel ELLEUCHI Examinatrice
M. Riadh BEN HALIMA Encadrant académique
Mme. Nouha BESBES Invitée de Spark-it
I
DEDICACE
Du profond de mon cœur, je dédie ce travail à tous ceux qui me
sont chers,
A mes très chers parents
Que ce travail soit l’expression de ma reconnaissance pour vos
sacrifices consentis, votre soutien moral et matériel que vous n’avez
cessé de prodiguer. Vous avez tout fait pour mon bonheur et ma
réussite. Que dieu vous préserve en bonne santé et vous accorde une
longue vie,
A MES FRERES, SŒURS, LEURS EPOUX ET LEURS ENFANTS
Vous étiez toujours présents pour m’aider et m’encourager. Sachiez
que vous serez toujours dans mon cœur,
A toute ma famille
Que ce travail soit l’expression de ma grande affectation et mon
profond amour et attachement,
A tous mes amis, au nom de la belle amitié qui nous réunit, je vous
exprime toute ma gratitude.
Au de la des mots, Merci, je vous aime.
A tous mes amis qui n’ont cessé de m’encourager et de me soutenir
Neifar Mahdi
II
REMERCIEMENT
Je tiens à remercier tous ceux qui m’ont aidé pour la réalisation de ce
travail et en premier lieu, mon encadrant Monsieur Riadh BEN
Halima pour son aide, sa disponibilité, et ses qualités humaines m'ont
profondément touché. Je vous remercie pour votre accueil et vos
conseils. Veuillez trouver ici, l’expression de mes gratitudes et de ma
grande estime.
Ma gratitude s'adresse, aussi, à Madame Fadoua Drira pour m’avoir
fait le grand honneur d'accepter d'être la présidente de ce jury. Qu'elle
trouve ici l'expression de mon profond respect.
Je tiens à exprimer a vive gratitude à Madame Manel Elleuchi qui a
bien voulu faire partie du jury de ce projet et pour l'intérêt qu'elle a
porté à ce travail. Qu'elle soit remerciée.
Je souhaite aussi adresser mes remerciements les plus vifs à M. Amin
Ben Abdallah, Mme Nouha Besbes, Mme Farah Sallem, Mme Fedia
Karray et toute l’équipe de Spark-it pour leurs conseils pratiques et leur
assistance continue qu’ils m’ont apportée tout au long de la période du
stage.
Mes remerciements s’adressent aussi à ma famille, mes amis, pour leurs
aides à mener à terme ce travail. Finalement, je tiens à remercier tous
ceux qui, de près ou de loin, m’ont apporté un soutien moral ou matériel.
III
Table de matières :
Introduction générale............................................................................................................ 1
Chapitre I : Présentation du projet........................................................................................ 2
Introduction ...................................................................................................................... 3
1.1. Présentation de l’organisme d’accueil .................................................................. 3
1.1.1. Présentation générale de Spark-it.................................................................. 3
1.1.2. Domaines d’activité ...................................................................................... 3
1.1.3. Les références de Spark-it ............................................................................. 4
1.2. Présentation générale du projet ............................................................................ 4
1.2.1. Contexte ........................................................................................................ 4
1.2.2. Objectif du projet .......................................................................................... 4
1.3. Etude de l’existant ................................................................................................ 4
1.3.1. Analyse des solutions existantes ................................................................... 5
1.3.2. Critique des applications existantes .............................................................. 6
1.3.3. Solution proposée.......................................................................................... 6
1.4. Méthodologie de travail ....................................................................................... 7
1.4.1. Méthode Scrum ............................................................................................. 7
1.4.2. Les principaux rôles de la méthode scrum .................................................... 8
Conclusion ........................................................................................................................ 8
Chapitre II : Etude préalable ................................................................................................ 9
Introduction : .................................................................................................................. 10
2.1. Etude de l’art ...................................................................................................... 10
2.1.1. Progiciel de gestion ..................................................................................... 10
2.1.2. Fonctionnalités et modularités .................................................................... 10
2.1.3. Les avantages d'un ERP .............................................................................. 11
2.1.4. Les inconvénients d’un ERP ....................................................................... 11
IV
2.1.5. Architecture modulaire d'un ERP ............................................................... 11
2.2. Principe de fonctionnement de GPAO ............................................................... 12
2.2.1. Système de Production (SP)........................................................................ 12
2.2.2. Gestion de production (GP) ........................................................................ 13
2.2.3. Gestion de Production Assistée par Ordinateur (GPAO) ........................... 14
2.3. Etudes de technologies existantes ...................................................................... 15
Framework front-end ........................................................................................ 15
Conclusion ...................................................................................................................... 17
Chapitre III : Analyse et spécification des besoins ............................................................ 18
Introduction .................................................................................................................... 19
3.1. Analyse des besoins ........................................................................................... 19
Identifications des acteurs .......................................................................................... 19
3.2. Contexte général du projet ................................................................................. 20
3.3. Exigences des besoins : ...................................................................................... 22
3.3.1. Exigences fonctionnelles : .......................................................................... 22
3.3.2. Exigences non fonctionnelles ..................................................................... 24
3.4. Spécification des besoins ................................................................................... 25
3.4.1. Le cas d’utilisation global du système ........................................................ 25
3.4.2. Diagramme de cas d’utilisation « S’authentifier » ..................................... 27
3.4.3. Diagramme de cas d’utilisation « Gérer produits » .................................... 28
3.4.4. Diagramme de cas d’utilisation « Gérer nomenclatures » .......................... 31
3.4.5. Diagramme de cas d’utilisation « Gérer ateliers » ...................................... 34
3.4.6. Diagramme de cas d’utilisation « Gérer machines » .................................. 37
3.4.7. Diagramme de cas d’utilisation « Gérer gammes de fabrication » ............. 39
3.4.8. Diagramme de cas d’utilisation « Gérer ordres de fabrication » ................ 42
3.4.9. Diagramme de cas d’utilisation « Traiter les opérations de fabrication » .. 45
Conclusion ...................................................................................................................... 47
V
Chapitre IV : Architecture et conception détaillée du système .......................................... 48
Introduction .................................................................................................................... 49
4.1. Architecture globale du système ........................................................................ 49
4.1.1. Architecture logicielle ................................................................................. 49
4.1.1.1. Couche de présentation ........................................................................... 50
4.1.1.2. Couche de métier .................................................................................... 51
4.1.1.3. Couche persistance ................................................................................. 51
4.1.2. Architecture physique ................................................................................. 51
4.2. Aspect statique du système ................................................................................ 52
4.2.1. Diagramme de paquetage ............................................................................ 52
4.2.2. Diagramme de classes de la couche « fr.sparkit.controller » ...................... 55
4.2.3. Diagramme de classes de la couche « fr.sparkit.service » .......................... 56
4.2.4. Diagramme de classes de la couche « fr.sparkit.repository » ..................... 59
4.2.5. Diagramme de classes de la couche « fr.sparkit.entity » ............................ 61
4.3. Diagrammes des séquences ................................................................................ 63
4.4. Diagramme d’activité ......................................................................................... 66
Conclusion ...................................................................................................................... 66
Chapitre V : Réalisation ..................................................................................................... 67
Introduction .................................................................................................................... 68
5.1. Environnement de travail ................................................................................... 68
Environnement matériel ............................................................................................. 68
5.2. Choix technologiques ................................................ Erreur ! Signet non défini.
5.3. Environnement de développement et Framework utilisés ................................. 70
5.4. Travail réalisé ..................................................................................................... 72
Conclusion ...................................................................................................................... 85
Conclusion générale ........................................................................................................... 86
Annexe : Backlog du produit : ........................................................................................... 88
VI
Table des figures :
Figure 1: Quelques partenaires de Spark-it ......................................................................... 4
Figure 2 : Présentation générale de Scrum .......................................................................... 8
Figure 3: Vision systémique d'un système de production ................................................. 13
Figure 4: Les flux informationnels et physiques .............................................................. 14
Figure 5: Volume de recherche Web pour les technologies Angular et ReactJS .............. 16
Figure 6 : Diagramme de modélisation de contexte.......................................................... 21
Figure 7 : Diagramme de cas d’utilisation global ............................................................. 26
Figure 8 : Cas d’utilisation de l’authentification............................................................... 27
Figure 9 : Diagramme de cas d'utilisation : Gérer les produits ......................................... 29
Figure 10 : Diagramme de cas d'utilisation : Gérer nomenclatures .................................. 31
Figure 11 : Diagramme de cas d'utilisation : Gérer ateliers .............................................. 35
Figure 12 : Diagramme de cas d'utilisation : Gérer machine ............................................ 37
Figure 13 : Diagramme de cas d 'utilisation : Gérer gammes de fabrication .................... 40
Figure 14 : Diagramme de cas d 'utilisation : gérer ordres de fabrication ........................ 43
Figure 15 : Diagramme de cas d 'utilisation : Traiter les opérations de fabrication.......... 45
Figure 16 : Architecture logicielle .................................................................................... 49
Figure 17 : Architecture de la couche présentation ........................................................... 50
Figure 18 : Architecture physique ..................................................................................... 51
Figure 19 : Diagramme de package de la partie front-end ................................................ 53
Figure 20 : Diagramme de package de la partie back-end ................................................ 55
Figure 21 : Structure de la couche « fr.sparkit.controller » .............................................. 56
Figure 22 : Structure d’une partie de la couche « fr.sparkit.service» ............................... 58
Figure 23: Structure d’une partie de la couche « fr.sparkit.repository»............................ 60
Figure 24 : Structure de la couche « fr.sparkit.entity» ...................................................... 62
Figure 25 : Diagramme de séquence système ˝ Gestion des nomenclatures ˝ .................. 64
Figure 26 : Diagramme de séquence système ˝ Gestion de l’ordre de fabrication ........... 65
Figure 27 : Diagramme d'activité « Traiter une opération» .............................................. 66
Figure 28 : Interface liste des nomenclatures .................................................................... 73
Figure 29: Interface consultation nomenclature ................................................................ 74
Figure 30 : Interface liste des composants avec pagination .............................................. 75
Figure 31 : Interface structure nomenclature sous forme d’une arbre .............................. 76
Figure 32 : Interface suppression d'une nomenclature ...................................................... 77
Figure 33 : Interface notification de suppression d'une nomenclature .............................. 77
VII
Figure 34 : Interface de modification d'une gamme de fabrication .................................. 78
Figure 35 : Interface de création d'un ordre de fabrication ............................................... 79
Figure 36 : Interface :liste des composants manquants en stock ...................................... 80
Figure 37 : Interface de suivi d'un ordre de fabrication ................................................... 81
Figure 38 : Interface :recherche d'une opération de fabrication ........................................ 82
Figure 39 : Interface export informations d'un ordre de fabrication sous forme d'un fichier
.................................................................................................................................................. 83
Figure 40 : Demande de tirage code front-end.................................................................. 84
Figure 41 : Build sur l'environnement d'intégration continue ........................................... 85
Table des logos :

Logo 1: Spark-it ................................................................................................................... 3
Logo 2 : Intellij Idea ........................................................................................................... 68
Logo 3 : WebStorm ............................................................................................................ 69
Logo 4 : SQL Server 2016 ................................................................................................. 69
Logo 5 : Swagger ............................................................................................................... 69
Logo 6 : TFS ...................................................................................................................... 69
Logo 7 : Git ........................................................................................................................ 70
Logo 8 : SonarQube ........................................................................................................... 70
Logo 9 : Java Entreprise Edition ........................................................................................ 71
Logo 10 : Maven ................................................................................................................ 71
Logo 11 : Hibernate............................................................................................................ 71
Logo 12 : Spring Boot ........................................................................................................ 72
Logo 13 : Angular 5 ........................................................................................................... 72
VIII
Liste des tableaux :
Tableau 1 : Etude comparative des solutions existantes ...................................................... 5

Tableau 2: Etude comparative entre Angular et ReactJS ................................................... 15
Tableau 3: Besoins fonctionnels organisés selon les acteurs ............................................. 22
Tableau 4 : Description textuelle du cas d’utilisation « S’authentifier » .......................... 28
Tableau 5 : Description textuelle du cas d’utilisation « Gérer produits » .......................... 29
Tableau 6 : Description textuelle du cas d’utilisation « Gérer nomenclatures»................. 32
Tableau 7 : Description textuelle du cas d’utilisation « Gérer ateliers » ........................... 35
Tableau 8 : Description textuelle du cas d’utilisation « Gérer machine » ......................... 37
Tableau 9 : Description textuelle du cas d’utilisation « Gérer gammes de fabrication » .. 40
Tableau 10 : Description textuelle du cas d’utilisation « Gérer ordre de fabrication » ..... 43
Tableau 11 : Description textuelle du cas d’utilisation « Traiter opérations de fabrication »
.................................................................................................................................................. 46
Tableau 12 : Environnement matériel utilisé ..................................................................... 68
IX
Introduction générale
Toute entreprise est prête à investir des sommes considérables dans l’implantation des
technologies logicielles afin d’améliorer ses services, d’accroitre son agilité et sa flexibilité, de
réduire les coûts, d’augmenter la production et de faire face 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.
En parallèle, avec les améliorations des outils technologiques, l’augmentation des données
à stocker et l’apparition des nouveaux besoins de l’entreprise, la refonte du système
d’information semble être assez importante. Pour surpasser ces difficultés, une entreprise doit
utiliser des outils optimisés et adaptés facilitants les tâches et offrants des fonctionnalités riches
et utiles. Parmi ces outils nous trouvons les systèmes intégrés de gestion tel que les ERP
(Entreprise Ressources Planning). Les ERP sont des outils de gestion et d’analyse permettant
d’optimiser la diffusion des informations en interne, d’améliorer les processus de gestion et
d’automatiser les tâches ce qui augmente énormément la réactivité des entreprises et leurs
agilités. C’est dans ce cadre s’inscrit notre projet de fin d’études qui a pour objectif de concevoir
et de développer un module ERP de gestion de production.
Ce module doit automatiser les différents processus de production à savoir la gestion des
nomenclatures, la planification des ordres des fabrications, la gestion des processus de
fabrication et le suivi des ordres de fabrications.
Notre rapport présente les différentes phases à travers lesquelles nous sommes passés pour
réaliser notre projet. Le premier chapitre intitulé « Présentation du projet », est consacré,
d’abord, à une présentation générale du projet. Ensuite, la problématique est présentée ainsi que
la méthodologie adoptée. Dans le chapitre suivant, intitulé « Étude préalable », nous passons
par un tour d’horizon sur les notions théoriques des ERP. Ensuite, nous faisons une étude de
l’existant et nous finissons par mettre en valeur les technologies utilisées. Dans le troisième
chapitre intitulé « Analyse et spécification des besoins », nous présentons le contexte du projet
à l’aide d’un diagramme de contexte en identifiant l’environnement extérieur au système de
gestion de production avec lequel ce dernier communique suivi par une analyse des besoins
fonctionnels et non fonctionnels de la solution proposée ainsi que la modélisation de ces besoins
par le recours aux diagrammes de cas d’utilisation.
1
A partir de la spécification dégagée, nous abordons, dans le quatrième chapitre,
l’architecture générale de l’application et offrons un aperçu des diagrammes de conception
utilisés.
Cet aperçu mènera à la conception générale des différentes fonctionnalités offertes. Cette
conception est réalisée en utilisant le langage de modélisation UML touchant le comportement
statique de la solution proposée. Ensuite, le cinquième chapitre intitulé « Réalisation » qui est
réservé à l’implémentation de l’application, où nous récapitulons les différents outils utilisés,
présentons les différentes interfaces homme/machine de notre solution proposée. Finalement,
le rapport est clôturé par une conclusion générale qui résume notre travail et propose les
éventuelles perspectives de ce travail.
2
Chapitre I : Présentation du projet
Plan du chapitre :
1.1. Présentation de l’organisme d’accueil .................................................................. 3
1.2. Présentation générale du projet ............................................................................ 4
1.3. Etude de l’existant ................................................................................................ 4
1.4. Méthodologie de travail ....................................................................................... 7
2
Introduction
Dans ce premier chapitre, nous allons présenter le cadre général du projet. Nous
commencerons d’abord par une présentation générale de l’organisme d’accueil, à savoir Spark-
it. Par la suite, nous allons expliquer et détailler le sujet du projet. Nous allons aussi faire une
étude des solutions existantes et expliquer leurs limites. Enfin, nous présenterons la
méthodologie de travail utilisée pour la réalisation du projet.
1.1. Présentation de l’organisme d’accueil

1.1.1. Présentation générale de Spark-it
Spark-it est une Société de Services et d’ingénierie Informatique et d’édition logicielle créée
en France en 2013. Elle a développé ses activités et a créé sa filiale Tunisienne en 2014 et est
devenue société-mère de « Further Technology ».
Spark-it a pour mission de concevoir et de mettre en œuvre les meilleures solutions

technologiques afin d’améliorer la performance des processus d’affaire de ses clients. Dotée de
son savoir-faire, elle est aujourd’hui reconnue auprès de ses clients pour son innovation dans
les technologies de l’information et la mise en place de procédures strictes garantissant des
solutions de qualité.
Logo 1: Spark-it
Spark-it garantit aussi un ensemble de services associés, tel que le consulting, la formation
et le support technique. De nombreuses entreprises étrangères de secteurs différents tels que les
secteurs bancaires, de télécommunications, des assurances, et industriels font confiance à
Spark-it pour la conception et la mise en place des systèmes d'informations décisionnels.
1.1.2. Domaines d’activité
Spark-It accompagne ses clients dans leurs projets liés aux technologies de l’information.
En effet, Spark-it est une ESN qui propose une large gamme de solutions personnalisés telles
3
que le développement Front et Back End (Web, CRM, Progiciels, etc.), la stratégie E-Business
et Business Intelligence.
1.1.3. Les références de Spark-it
Spark-it a réussi à accompagner des grandes entreprises dans la mise en place de leurs
solutions décisionnelles. Parmi ces entreprises nous citons le cabinet de recrutement mondial
HAYS, le groupe VALEO qui est l’un des premiers équipementiers mondiaux, spécialiste dans
la conception, la fabrication et la vente de composants, de systèmes intégrés et de modules pour
l’industrie automobile, aussi SERVIER qui est le premier groupe pharmaceutique Français
indépendant et le deuxième groupe pharmaceutique Français au niveau mondial.
Figure 1: Quelques partenaires de Spark-it
1.2. Présentation générale du projet

1.2.1. Contexte
Le projet « Conception et développement d’un module ERP : gestion de la production » est

réalisé dans la cadre d’un projet de fin d’études en vue d’obtention du diplôme d’ingénieur en
informatique de l’Ecole Nationale d’Ingénieurs de Sfax.
Ce projet est réalisé au sein de l’équipe Java de l’entreprise Spark-it durant la période allant
du 4 Février 2019 jusqu’au 30 juin 2019.
1.2.2. Objectif du projet
Le projet a pour objectif la conception et le développement d’une application web

présentant un module ERP : gestion de la production. Cette application doit être flexible à toutes
les évolutions et les améliorations qui peuvent avoir lieu ultérieurement et doit aussi garantir
une bonne qualité de code.
1.3. Etude de l’existant

L’étude de l’existant est une étape primordiale pour la réalisation d’un projet. Cette étape a
pour objectif de détecter et d’analyser les points forts et les points faibles des solutions
4
existantes. Ces analyses sur les solutions existantes permettent de bien définir les besoins et des
fonctionnalités que nous pouvons intégrer dans notre application.
1.3.1. Analyse des solutions existantes
Dans cette partie, nous allons mentionner quelques applications existantes avant d’analyser
leurs points forts et leurs points faibles.
 Odoo (www.odoo.com) : progiciel open-source de gestion intégré comprenant de très

nombreux modules permettant de simplifier la gestion d’entreprise dans son ensemble.
 Open-prod (www.open-prod.com) : logiciel de gestion industrielle dédié à la gestion de
la production assistée par ordinateur.
 Gpmi (www.gpmi.com) : logiciel développé par GPMI qui répond aux besoins de
gestion de la production.
Dans le tableau 1, nous allons récapituler les fonctionnalités de chacune des solutions
proposées. Les applications citées assurent les fonctionnalités de base comme la gestion des
produits, la gestion des nomenclatures et la gestion des ordres de fabrication. Mais d’autres
fonctionnalités assez importantes telle que la planification des ordres de fabrication et la gestion
des rôles des utilisateurs ne sont pas disponibles dans ces applications.
Tableau 1 : Etude comparative des solutions existantes[1]
Odoo Open-prod gpmi Stark
Authentification Compte Compte Aucune Compte

spécifique à spécifique à authentification spécifique à
l’application l’application n’est exigée l’application
Ecrit en Python Python .net .net et java
Multilingue Oui Oui Non Oui
Gestion des rôles des Oui

Non Non Non
utilisateurs
Planification des Oui

Non Oui Oui
ordres de fabrication
Calcul de charge Non Oui Non Oui
5
Calcul du prix de Oui

Non Non Oui
reviens sur un article
Application mobile Non Oui Non Oui
1.3.2. Critique des applications existantes
Le tableau 1 nous a présenté les limites des applications existantes :
 Limites dans la gestion des rôles des utilisateurs.

 Complexité de la planification des ordres de fabrication sur certains sites.
 Absence de fonctionnalités importantes dans la gestion de la production telles que le
calcul de charge de travail dans certains sites.
 Absence du coût de fabrication d’un produit.
 Manque d’ergonomie de certaines applications.
1.3.3. Solution proposée
Afin de garantir la réussite du projet, la solution proposée doit pallier aux limites des
applications existantes. La solution proposée doit moderniser 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.

 Gestion des utilisateurs.
 Gestion des rôles des utilisateurs.
 Gestion des produits.
 Gestion des nomenclatures.
o Ajouter des composants à une nomenclature
o Afficher la hiérarchie des composants d’une nomenclature en tant qu’un arbre.
 Gestion des ordres de fabrication.
 Planification des ordres de fabrication
o Recherche des ordres planifiés par jour, semaine ou mois.
o Afficher les ordres planifiés sur un agenda.
o Calculer la charge de travail de chaque jour et l’afficher sur l’agenda.
La solution proposée doit aussi assurer des besoins non fonctionnels tel que :
6
 L’ergonomie
 Sécurité
 Performance
La complexité de ce projet se trouve dans la communication entre les différents micro-

services. En effet, la table produit se trouve dans la base de données du module commercial
d’où le besoin de collecter des informations de cette table avec des requêtes à cette base de
données à l’aide de web-services.
1.4. Méthodologie de travail

Afin d’assurer la réussite d’un projet informatique, il est primordial de déterminer une
méthodologie de travail et de l’adopter. Bien qu’il existe plusieurs méthodologies, nous avons
choisi d’adopter les méthodes agiles[2] afin d’atteindre plus facilement et plus rapidement les
besoins et les demandes évolués de l’utilisateur au cours du cycle de développement des projets.
1.4.1. Méthode Scrum
Pour la gestion de notre projet, nous avons opté pour Scrum[3] en tant que méthode agile
dédiée à la gestion de projet.
Il s’agit d’un modèle itératif de développement logiciel utilisé pour le développement des
logiciels complexes. La première étape de la méthode Scrum consiste à formaliser la vision du
produit en décrivant les principaux objectifs, jalons et utilisateurs visés. La suite consiste à
spécifier la liste des exigences fonctionnelles et non fonctionnelles du produit sous forme de
Product Backlog d’une manière ordonnée selon la priorité fixée par le Product Owner.
Le Product Backlog permettra de diriger l’équipe sur les objectifs du produit tout au long
du projet, et à partir de ce Backlog l’équipe de développement choisit les tâches qui seront
développées au cours du sprint prochain lors de la réunion de planification du sprint.
Un sprint est une période de 2 à 4 mois au cours de laquelle l’équipe de développement

réalise un élément du backlog du produit. A la fin du sprint, un incrément du produit doit être
délivré.
Une revue de sprint est planifiée à la fin de chaque sprint afin d’inspecter l’avancement du
produit au cours du sprint précédent. Le Product Owner donne ses impressions à l’équipe de
développement, il accepte ou refuse les fonctionnalités présentées et donne les changements
qui doivent être faites sur le produit.
7
Une réunion quotidienne appelée Daily Stand-up Meeting doit se dérouler entre les
membres de l’équipe de développement pour se synchroniser, remonter les obstacles rencontrés
et vérifier l’avancement du sprint.
Figure 2 : Présentation générale de Scrum[4]
1.4.2. 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 et contenu de chaque sprint.
 Le « 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 ».
Conclusion
Dans ce premier chapitre, nous avons présenté l’organisme d’accueil et ses domaines
d’activité. Ensuite, nous avons décri le contexte général du projet et ses objectifs. Dans la suite,
nous avons fait une étude comparative des solutions existantes, cette étude nous a permis de
définir les besoins et les fonctionnalités à intégrer dans notre projet. Enfin, nous avons défini la
méthodologie de travail adoptée tout au long de la réalisation du projet.
8
Chapitre II : Etude préalable
Plan du chapitre :
2.1. Etude de l’état de l’art ........................................................................................ 10
2.2. Principe de fonctionnement de GPAO ............................................................... 12
2.3. Etudes de technologies existantes ...................................................................... 15
9
Introduction :
Afin d'assurer la bonne compréhension du projet, il est nécessaire de faire le retour des
différents concepts et technologies utilisés et de détailler l'existant fonctionnel. Ce chapitre se
compose de trois parties : L'état de l'art, une étude des ERP existants, une étude du marché des
logiciels de gestion de production et une étude comparative sur les technologies existantes.
2.1. Etude de l’état de l’art

Après avoir défini le cadre du projet, un retour sur les données bibliographiques relatives à
notre sujet est nécessaire pour comprendre et assimiler les bases théoriques de l’ERP ainsi que
la gestion de production.
2.1.1. Progiciel de gestion
Suite au progrès technologiques, les entreprises ont eu recourt pendant des années à
plusieurs solutions afin d'automatiser la gestion des ressources telles que la gestion des
ressources humaines, la gestion de production, la gestion des ventes, etc… C'est là qu'ont
commencé à apparaître les systèmes d'informations qui avaient pour but de gérer les bases de
données des différentes entreprises jusqu'à l'apparition des ERP, l'abréviation en anglais de
(Entreprise Ressources Planning) traduite en français par PGI qui veut dire Progiciel de Gestion
Intégré mais ERP reste le terme le plus couramment utilisé.
- Définition
L’ERP (Entreprise Ressource Planning), est une solution informatisée qui offre la
possibilité de gérer l’ensemble des moyens de l’entreprise,[5] en privilégiant deux aspects : une
communication entre les différents acteurs métiers et une cohérence de l’information. C’est le
centre nerveux du système d’information. Un « Entreprise Ressource Planning » (ERP ou
Progiciel de Gestion Intégré) est un logiciel qui englobe toutes les fonctionnalités d’une
entreprise (gestion de stock, gestion de ventes, gestion de ressources humaines, gestion de
maintenance, gestion de production…).
2.1.2. Fonctionnalités et modularités
Pour bien comprendre les aspects fonctionnels de l'ERP, la concentration du marché sur
certains éditeurs permet d'identifier clairement cinq domaines généraux de compétence gérée
par les progiciels de gestion intégrée :
10
 Gestion de la production
 Gestion des stocks, des approvisionnements et des achats
 Gestion commerciale
 Gestion des ressources humaines
 Gestion comptable et financière
Ces différentes catégories se retrouvent dans les différentes offres du marché. Ils constituent
le noyau du système d’information et serviront les différents acteurs de l’entreprise.
L’adaptation à la société de ces progiciels s’effectue par un paramétrage important, ce qui
nécessite un effort considérable de structuration de la société pour "coller" son mode de
fonctionnement aux possibilités du package.
2.1.3. Les avantages d'un ERP
Concrètement, les avantages de la mise en œuvre d'un ERP sont nombreux. Outre le fait
que l’ERP est utilisé dans le monde entier, il permet de :
 Garantir l'intégrité et l’unicité des informations : tous les utilisateurs du système

développé travaillent dans la même base de données.
 Effectuer une mise à jour dans la base de données en temps réel.
 Gérer les stocks : meilleure gestion du stock.
2.1.4. Les inconvénients d’un ERP
 Mise en place lourde, toujours longue

 Problème du choix des ERPs (changement ou sortie difficile)
 Impact sur l’organisation (il faut s’adapter à l’ERP)
 Dépendance d’un éditeur, de sa capacité de suivi, de sa vision de la gestion
 Évolution non maîtrisée.
 Coût très cher.
2.1.5. Architecture modulaire d'un ERP
Un ERP est un ensemble dont toutes les parties fonctionnent ensemble, d'où l'ergonomie et
le caractère unique des informations et donc la cohérence du système d'information. Un ERP
est modulaire en ce sens qu'il est possible d'avoir une ou plusieurs applications à la fois le temps,
ou petit à petit. Les applications modulaires telles que les ERP permettent de s'assurer de la
compatibilité des modules entre eux, ils s'emboîtent comme des blocs Lego et fonctionnent
11
ensemble (aucun contrôle de compatibilité à effectuer). La figure 3 présente un exemple

d'architecture modulaire qui a tendance à représenter tous les ERP.
Figure 3: Architecture modulaire d'un ERP
2.2. Principe de fonctionnement de GPAO

2.2.1. Système de Production (SP)
La production consiste en une transformation de ressources (humaines ou matérielles) en

vue de la création de biens ou services.
La production d'un bien s'effectue par une succession d'opérations consommant de

ressources et transformant les caractéristiques de la matière.
12
La production d'un service s'effectue par une succession d'opérations consommant des
ressources sans qu'il n'y ait nécessairement une transformation de matière.
Figure 4: Vision systémique d'un système de production

La figure 4 présente une vision systémique d’un système de production en spécifiant la
synchronisation entre les données techniques jusqu’au stock.
2.2.2. Gestion de production (GP)
La gestion de la production consiste à assurer l'organisation du système de production afin

de produire des produits dans des quantités et dans des délais appropriés, en fonction des
moyens (humains ou technologiques).
Au sens industriel, la production peut être définie comme un flux ayant deux composants
principaux montré par la figure 5 :
 Le flux physique
 Le flux d'informations
L’objectif principal du GP est d’assurer une bonne régulation du flux de produits dans
l’entreprise (flux de pièces du fournisseur au premier, la production et le stock de produits finis).
Le GP permet de :
 Minimiser les risques de l'entreprise.

 Optimiser les stocks.
13
 Diminuer les encours.

 Réduire le prix de revient des produits.
 Réduire les délais.
Figure 5: Les flux informationnels et physiques[6]

Abréviation :
OF : Ordre de fabrication
OA : Ordre d’approvisionnement
2.2.3. Gestion de Production Assistée par Ordinateur (GPAO)
La gestion de la production consiste à optimiser les délais, les coûts, la qualité ainsi que les
ressources de l'entreprise afin d'assurer sa durabilité, son développement et sa compétitivité.
Le GPAO n’est donc qu’un support informatique pour ce type de gestion, visant à :
 Rationaliser l'utilisation des ressources de l'entreprise (physiques, humaines et

financières)
 Simplifier les circuits d'information et faciliter la communication.
 Mettre en place un système d'information pour donner à l'entreprise des avantages
concurrentiels.
14
2.3. Etudes de technologies existantes

Nous consacrons cette section pour étudier des langages à adopter pour la mise en place du
notre application.
Toute au long de cette partie, nous allons établir une comparaison entre différentes
technologies à adopter pour le développement de notre solution dans sa partie front-end et
notamment dans la partie back-end.
2.3.1. Framework front-end
Aujourd’hui, le nombre des Framework de développement et des bibliothèques basé en java

script est en croissance continue. En effet, les technologies client les plus reconnu sont Angular,
le Framework de Google et son concurrent fondé par Facebook qui s’appelle ReactJS. Une
comparaison entre les technologies Angular et ReactJS est résumée par le tableau 2 selon divers
critères à savoir la facilité d’apprentissage, la consommation de mémoire, le degré d’abstraction
et autres.
Tableau 2: Etude comparative entre Angular et ReactJS
Caractéristiques ReactJS Angular
Se repose sur plusieurs Se repose sur le

librairies, principalement le typeScript, ECMAScript 6,
Langages
JSX syntaxe pré de html compilé en java script
Complexité élevée réduite
Complétion de code faible élevée
Taille en production 144 KO 117 KO
Taille en développement 1 MO 559 KO
Courbe d’apprentissage Faible Moyenne
Abstraction fort fort
Débogage javascript fort/ html javascript fort/ html

faible faible
Binding des données unidirectionnel multidirectionnel
15
Modèle des composants fort passable

(réutilisation des
composants)
Support du design pattern oui view element

MVC
Angular utilise l’outil CLI qui permet de générer une squelette d’application avec des bouts
de code (composant, module, route), de faire tourner un serveur de développement, d’exécuter
les tests, de déployer l’application.
Figure 6: Volume de recherche Web pour les technologies Angular et ReactJS
La figure 6 illustre le volume de recherche pour les technologies front-end Angular et

ReactJS, elle est faite par Google-Trends.
ReactJS est plus orienté vers le JavaScript avec tous ses avantages alors qu’Angular offre
plus de maturité que celle de ReactJS.
Pour cela, nous avons adopté le Framework Angular pour développer la partie front end
qui nous a permis de construire une architecture robuste qui inclut toutes les briques nécessaires
16
à la création d’une application professionnelle à savoir routeur, requêtage HTTP, gestion des
formulaires, internationalisation. Le Framework lui-même est découpé en modules
correspondant aux grandes aires fonctionnelles (core, forms, router, http. . .). Mise à part son
caractère de modernité conçu pour le web de demain à travers l’utilisation des évolutions
récentes du langage JavaScript (ECMAScript 6 et TypeScript) architecture inspirée des Web
Components. Enfin, il s’agit d’un Framework qui est soutenu par Google.
Conclusion
Tout au long de cette partie, nous avons diffusé une revue de la littérature théorique sur les
solutions ERP et gestion de production. Nous avons ensuite réalisé une étude de marché sur le
logiciel de gestion de production et présenté la relation entre ERP et ses produits. Et pour
terminer ce chapitre nous avons effectué une étude comparative sur les technologies front-end
et back-end.
Afin de suivre la méthodologie adoptée dans la dernière partie, une étude fonctionnelle et
technique fera l’objet du prochain chapitre.
17
Chapitre III : Analyse et spécification des besoins
Plan du chapitre :
3.1. Analyse des besoins ........................................................................................... 19
3.2. Contexte général du projet ................................................................................. 20
3.3. Exigences des besoins : ...................................................................................... 22
3.4. Spécification des besoins ................................................................................... 25
18
Introduction
Le présent chapitre est consacré à l’identification, l’analyse et la spécification des besoins
qui représentent une phase importante dans le cycle de développement d’un logiciel. Pour ce
faire, Nous présentons, en premier lieu nous définissons les acteurs de notre système. Par la
suite, nous présentons le contexte du projet à travers un diagramme de contexte. Ensuite, nous
entamons une spécification des besoins fonctionnels et non fonctionnels. Ainsi, nous
modélisons ces besoins à l’aide des diagrammes des cas d’utilisation en décrivant leurs
fonctionnalités majeures.
3.1. Analyse des besoins

Identifications des acteurs
Un acteur est toute entité physique ou abstraite qui interagit avec le système afin de répondre
à un besoin bien défini.
Nous avons identifié quatre acteurs majeurs dans notre application. Nous les détaillons dans
la suite.
Administrateur : C'est la personne qui a le privilège le plus élevé. Cet acteur est capable
de gérer toutes les fonctionnalités offertes par l'application, et plus précisément la gestion des
utilisateurs.
Responsable technique : C’est la personne qui constitue l’ensemble des informations

décrivant la structure du système de production. Il définit la fiche technique des produits ainsi
que ses composants, les machines et les ateliers.
Responsable de production : C'est la personne qui a pour rôle de gérer les ordres de
fabrication (O.F). Il planifie et optimise les méthodes de production et la gestion de la
production, il est l’orchestrateur de tout ce qui entre et sort des ateliers. Il organise et coordonne
la production (planification), attribue à chaque charge de travail (machine, homme) une charge
de travail.
Opérateur : C’est la personne qui traite les opérations au sein de l’atelier : c’est lui qui
initie l’opération, la valide en pause, il peut également consulter les informations concernant
l’opération qui les traite.
19
3.2. Contexte général du projet

Le diagramme de contexte résume les échanges de messages entre le système et ses
différents acteurs, représentés à la figure 7.
20
Figure 7 : Diagramme de modélisation de contexte 21

3.3. Exigences des besoins :

Dans cette partie, nous allons entamer tout d’abord par la spécification des besoins
fonctionnels et non fonctionnels.
3.3.1. Exigences fonctionnelles :
Les acteurs décrivent les fonctionnalités du système à développer. Ce sont les besoins qui
spécifient le comportement d’entrée/sortie du système. Notre application doit fournir aux
différents utilisateurs les fonctionnalités que nous spécifions dans le tableau 3.
Tableau 3: Besoins fonctionnels organisés selon les acteurs
Acteur Description des besoins fonctionnels
L’application doit permettre au responsable technique de :
-S’authentifier.
- Créer un produit.
-Editer fiche produit.
-Supprimer un produit.
-Chercher un produit.
-Créer une nomenclature.
-Editer une nomenclature.
Responsable technique -Supprimer une nomenclature.
-Chercher une nomenclature.
-Consulter une nomenclature sous forme d’arbre.
- Créer un atelier de fabrication.
- Editer un atelier de fabrication.
- Supprimer un atelier de fabrication.
- Chercher un atelier de fabrication.
- Créer fiche machine de fabrication
22
-Editer fiche machine de fabrication.
-Supprimer fiche machine de fabrication.
-Chercher fiche machine de fabrication.
- Affecter les pièces de rechanges de chaque machine.
L’application doit permettre au responsable de production de :
-S’authentifier.
- Créer une gamme de fabrication.
- Editer une gamme de fabrication.
- Supprimer une gamme de fabrication.
Responsable de production - Chercher une gamme de fabrication.
- Créer une opération de fabrication.
-Editer une opération de fabrication.
-Supprimer une opération de fabrication.
-Chercher une opération de fabrication.
- Créer un ordre de fabrication.
-Editer un ordre de fabrication.
-Supprimer un ordre de fabrication.
-Chercher un ordre de fabrication.
L’application doit permettre à l’opérateur de :
-S’authentifier.
Operateur - Commencer une opération de fabrication.
- Mettre en pause une opération de fabrication.
- Terminer une opération de fabrication.
23
Administrateur L’application doit permettre à l’administrateur de :
-Gérer les utilisateurs.
-Accès sur toutes les fonctionnalités de l’application.
3.3.2. Exigences non fonctionnelles
Les besoins non fonctionnels représentent les exigences implicites auxquelles le système
doit répondre de telle sorte que toutes les fonctionnalités offertes par l’ERP doivent obéir à un
ensemble de contraintes. Dans ce qui suit, nous présentons les besoins non fonctionnels par
ordre prioritaire comme suit :
•La confidentialité du code source : Le code source de l’application est propriétaire à la

société. Il ne doit pas être partagé.
• L’extensibilité et la maintenabilité : Le code source doit être commenté et bien documenté

pour garantir une facilité de mises à jour et de réutilisation. En effet, : Un code qui suit les
bonnes pratiques de développement permettant la compréhension et la mise à jour de
l’application. Par conséquent, l’application pourrait être évolutive et extensible en supportant
l’ajout des nouvelles fonctionnalités dans le futur.
• La confidentialité des données : La plateforme doit assurer un accès privilégié, c’est à dire
chaque utilisateur ne peut accéder qu’à certaines fonctionnalités qu’après connexion
(identification et authentification) pour garantir la traçabilité des opérations.
• L’ergonomie : L’application doit fournir des interfaces simples, non complexes et

conviviales qui garantissent une facilité d’utilisation des différentes fonctionnalités
• 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.
24
3.4. Spécification des besoins

3.4.1. Le cas d’utilisation global du système
Le diagramme de cas d’utilisation de la figure 8 schématise les fonctionnalités du module

gestion de production.
Dans le diagramme du cas d’utilisation général de la figure 8, nous regroupons tous les cas
d’utilisation de base afin d’avoir une vue globale du fonctionnement de notre système ainsi que
mettre en évidence les éventuelles relations qui peuvent les lier.
25
Figure 8 : Diagramme de cas d’utilisation global
26
3.4.2. Diagramme de cas d’utilisation « S’authentifier »
La figure 9 illustre le diagramme de cas d’utilisation d’une authentification. Il sera détaillé

par le tableau 4.
Figure 9 : Cas d’utilisation de l’authentification
27
Tableau 4 : Description textuelle du cas d’utilisation « S’authentifier »
Identification
Titre : S’authentifier
Acteurs : Administration, responsable de production, responsable technique, operateur
Objectif : Ce CU est utilisé pour identifier les utilisateurs et sécuriser l’accès à l’application.
Description des scénarios :
Pré condition : Aucune
Post condition : L’utilisateur se connecte au système et peut ainsi accéder aux différentes
fonctionnalités.
Le cas d’utilisation débute quand l’utilisateur ouvre l’application.
Scénario nominal :
Le système affiche l’écran d’authentification.
L’utilisateur saisit le login et le mot de passe.
Le système vérifie si le login et le mot de passe sont correctement saisis. En cas d’anomalie,
le système affiche « Exception1 ».
Le système ouvre le formulaire principal.
Scénario alternatif :
Au niveau de l’étape 3, si les informations saisies ne sont pas valides, le système affiche un
message d’erreur et affiche de nouveau l’écran d’authentification.
Exception :
Exception1 : Le système affiche le message : « Login ou mot de passe erroné »
3.4.3. Diagramme de cas d’utilisation « Gérer produits »
Le diagramme illustré par la figure 10 montre les fonctionnalités liées à la gestion des
produits. La description textuelle associée est récapitulée au tableau 5.
28
Figure 10 : Diagramme de cas d'utilisation : Gérer les produits
Tableau 5 : Description textuelle du cas d’utilisation « Gérer produits »
Identification :
Titre : Gérer 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é.
29
Post-conditions :
-Nouveau produit validé figure dans la liste des produits.
- Le produit supprimé n’existe plus dans la liste des produits.
Scénario nominal :
a. Ajouter un produit :
1. L’utilisateur demande au système d’ajouter un produit.
2. Le système affiche le formulaire de gestion des produits.
3. L’utilisateur saisit toutes les informations du produit (description, unité de stock,

fournisseur, prix d’achat.). Puis, il demande au système de valider les informations saisies.
4. 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.
b. Modifier fiche produit :
1. L’utilisateur accède au formulaire de gestion des produits.
2. L’utilisateur parcourt la liste des produits, sélectionne un produit selon un critère de

recherche (description) et demande au système de le modifier.
3. Le système affiche l’interface de modification.
4. L’utilisateur modifie les informations qui peuvent être modifiées. Puis, il demande au
système de valider les informations saisies.
5. Le système vérifie les informations modifiées et les enregistre. Sinon, le cas reprend à
l’écran initial de modification.
c. Supprimer un produit :
1. L’utilisateur parcourt la liste des produits, sélectionne un produit et demande au

système de supprimer ce produit.
30
2. Le système affiche l’interface de suppression.
3. Si l’utilisateur confirme la suppression alors le système vérifie si le produit possédé

une nomenclature dans ce cas le système interdit la suppression et d’éclanche l’exception2
sinon le système valide la suppression et retourne à l’écran initial.
Exceptions :
Exception 1 : Le système affiche un message indiquant « Produit existe déjà ».
Exception 2 : Le système affiche un message indiquant « Produit affecté à une

nomenclature ».
3.4.4. Diagramme de cas d’utilisation « Gérer nomenclatures »
nomenclatures. La description textuelle détaillée est récapitulée dans le tableau 6.
Figure 11 : Diagramme de cas d'utilisation : Gérer nomenclatures
31
Tableau 6 : Description textuelle du cas d’utilisation « Gérer nomenclatures»
Identification :
Titre : Gérer nomenclatures
Objectif : L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, consulter et de supprimer une
nomenclature.
Post-conditions :
-La nouvelle nomenclature validée figure dans la liste des nomenclatures.
- La nomenclature supprimée n’existe plus dans la liste des nomenclatures.
Scénario nominal :
a. Ajouter une nomenclature :
1. L’utilisateur demande au système d’ajouter une nomenclature.
2. Le système affiche le formulaire de création d’une nomenclature.
3. L’utilisateur saisit toutes les informations générales du nomenclature (référence, produit, type
nomenclature).
4.Par la suite, l’utilisateur sélectionne les composants de la nomenclature tout en spécifiant les
quantités pour chaque composant, puis il demande au système de valider les informations saisies.
5. Le système vérifie que toutes les données obligatoires sont saisies correctement sinon le système
déclenche l’exception 1.
6. Le système vérifie que la référence de la nomenclature est unique sinon il déclenche l’exception
2.
7. Le système vérifie que produit sélectionnée de la nomenclature ne possède pas déjà de

nomenclature sinon le système il déclenche l’exception 3.
32
8. Le système vérifie que produit sélectionnée de la nomenclature est différent des produits
composants sinon le système il déclenche l’exception 4.
Si toutes les informations sont validées, le système enregistre la nouvelle nomenclature puis affiche
la liste des nomenclatures.
b. Editer nomenclature :
1. L’utilisateur accède au formulaire de gestion des nomenclatures.
2. L’utilisateur parcourt la liste des nomenclatures, sélectionne une nomenclature selon un critère
de recherche (description) et demande au système de le modifier.
4. L’utilisateur modifie les informations qui peuvent être modifiées, Puis il demande au système de
valider les informations saisies.
5. Le système vérifie que toutes les données obligatoires sont saisies correctement sinon le système
6. Le système vérifie que la référence de la nomenclature est unique sinon il déclenche l’exception
2.
7. Le système vérifie que produit sélectionnée de la nomenclature ne possède pas déjà de

nomenclature sinon le système il déclenche l’exception 3.
8. Le système vérifie que produit sélectionnée de la nomenclature est différent des produits
composants sinon le système il déclenche l’exception 4.
9. Le système vérifie les informations modifiées et les enregistre. Sinon, le cas reprend à l’écran
initial de modification.
c. Supprimer une nomenclature :
1. L’utilisateur parcourt la liste des nomenclatures, sélectionne une nomenclature et demande au

système de supprimer cette nomenclature.
3. Si l’utilisateur confirme la suppression alors le système vérifie si la nomenclature courante

possède un ordre de fabrication dans ce cas le système déclenche l’exception 5 ensuite le système vérifie
33
si la nomenclature courante est déjà utilisée dans une autre nomenclature dans ce cas le système interdit
la suppression et déclenche l’exception 6 sinon le système valide la suppression et retourne à l’écran
initial.
Exceptions :
Exception 1 : Le système affiche un message indiquant « Veuillez insérer les composants ».
Exception 2 : Le système affiche un message indiquant « Cette référence existe déjà ».
Exception 3 : Le système affiche un message indiquant « Produit possède déjà une nomenclature ».
Exception 4 : Le système affiche un message indiquant « Veuillez insérer un composant diffèrent

du produit parent ».
Exception 5 : Le système affiche un message indiquant « Cette nomenclature est déjà utilisée dans
un ordre de fabrication ».
Exception 6 : Le système affiche un message indiquant « Cette nomenclature est déjà utilisée dans
une autre nomenclature».
3.4.5. Diagramme de cas d’utilisation « Gérer ateliers »
ateliers. La description textuelle détaillée est récapitulée dans le tableau 7.
34
Figure 12 : Diagramme de cas d'utilisation : Gérer ateliers
Tableau 7 : Description textuelle du cas d’utilisation « Gérer ateliers »
Identification :
Titre : Gérer ateliers
Objectif : L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, chercher et de supprimer un

atelier.
Post-conditions :
-Le nouvel atelier validé figure dans la liste des ateliers.
35
- L’atelier supprimé n’existe plus dans la liste des ateliers.
Scénario nominal :
a. Ajouter atelier :
1. L’utilisateur demande au système d’ajouter un atelier.
2. Le système affiche le formulaire de création d’un atelier.
3. L’utilisateur saisit toutes les informations nécessaires (référence, description).
4. Le système vérifie que la référence de l’atelier est unique sinon il déclenche l’exception 1.
Si toutes les informations sont validées, le système enregistre le nouvel atelier puis affiche la liste
des ateliers.
b. Editer atelier :
1. L’utilisateur accède au formulaire de gestion des ateliers.
2. L’utilisateur parcourt la liste des ateliers, sélectionne un atelier selon un critère de recherche
(description) et demande au système de le modifier.
4. L’utilisateur modifie les informations qui peuvent être modifiées. Puis, il demande au système de
c. Supprimer atelier :
1. L’utilisateur parcourt la liste des ateliers, sélectionne un atelier et demande au système de

supprimer cet atelier.
3. Si l’utilisateur confirme la suppression alors le système vérifie si l’atelier courant possède une
machine dans ce cas le système interdit la suppression et déclenche exception 2 sinon le système valide
la suppression et retourne à l’écran initial.
36
Exception :
Exception 2 : Le système affiche un message indiquant « Impossible de supprimer un atelier qui

possède déjà une machine».
3.4.6. Diagramme de cas d’utilisation « Gérer machines »
machines. La description textuelle détaillée est récapitulée dans le tableau 8.
Figure 13 : Diagramme de cas d'utilisation : Gérer machine
Tableau 8 : Description textuelle du cas d’utilisation « Gérer machine »
37
Identification :
Titre : Gérer machine
Objectif : L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, chercher et de supprimer une
machine.
Pré-condition : l’utilisateur est authentifié.
Post-conditions :
-Nouvelle machine validée figure dans la liste des machines.
- La machine supprimée n’existe plus dans la liste des machines.
Scénario nominal :
a. Ajouter machine :
1. L’utilisateur demande au système d’ajouter une machine.
2. Le système affiche le formulaire de création d’une machine.
3. L’utilisateur saisit toutes les informations nécessaires (référence, description).
4. Le système vérifie que la référence de la machine est unique sinon il déclenche l’exception 1.
Si toutes les informations sont validées, le système enregistre la nouvelle machine puis affiche la
liste des machines.
b. Editer machine :
1. L’utilisateur accède au formulaire de gestion des machines.
2. L’utilisateur parcourt la liste des machines, sélectionne une machine selon un critère de recherche
(description) et demande au système de le modifier.
38
4. L’utilisateur modifie les informations qui peuvent être modifiées. Puis, il demande au système de
c. Supprimer machine :
1. L’utilisateur parcourt la liste des machines, sélectionne une machine et demande au système de
supprimer cette machine.
3. Si l’utilisateur confirme la suppression alors le système vérifie si la machine courante possède

des opérations de fabrication dans ce cas le system interdit la suppression et déclenche exception 2
sinon le système valide la suppression et retourne à l’écran initial.
Exceptions :
Exception 2 : Le système affiche un message indiquant « Impossible de supprimer une machine qui
possède déjà des opérations de fabrications».
3.4.7. Diagramme de cas d’utilisation « Gérer gammes de fabrication »
gammes de fabrications. La description textuelle détaillée est récapitulée dans le tableau 9.
39
Figure 14 : Diagramme de cas d 'utilisation : Gérer gammes de fabrication
Tableau 9 : Description textuelle du cas d’utilisation « Gérer gammes de fabrication »
Identification :
Titre : Gérer gammes de fabrication
Acteur : Responsable de production.
Objectif : L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, chercher et de supprimer une
gamme de fabrication.
Post-conditions :
40
- Une nouvelle gamme de fabrication validée figure dans la liste des gammes de fabrication.
- La gamme de fabrication supprimée n’existe plus dans la liste des gammes de fabrication.
Scénario nominal :
a. Ajouter gamme de fabrication :
1. L’utilisateur demande au système d’ajouter une gamme de fabrication.
2. Le système affiche le formulaire de création d’une gamme de fabrication.
3. L’utilisateur saisit toutes les informations nécessaires (référence gamme, description gamme).
4. L’utilisateur saisit toutes les informations relatives aux opérations de fabrication (description
opération, durée opération).
5. Par la suite l’utilisateur sélectionne la machine sur laquelle s’exécute cette opération.
6. L’utilisateur sélectionne un responsable pour cette opération.
7. Le système vérifie que la référence de la gamme de fabrication est unique sinon il déclenche
l’exception 1.
Si toutes les informations sont validées, le système enregistre la nouvelle gamme de fabrication
puis affiche la liste des gammes de fabrications.
b. Editer gamme de fabrication :
1. L’utilisateur accède au formulaire de gestion des gammes de fabrications.
2. L’utilisateur parcourt la liste des gammes de fabrications, sélectionne une gamme de fabrication
selon un critère de recherche (description) et demande au système de le modifier.
4. L’utilisateur modifie les informations qui peuvent être modifiées, Puis il demande au système de
c. Supprimer gamme de fabrication :
41
1. L’utilisateur parcourt la liste des gammes de fabrications, sélectionne une gamme de fabrications
et demande au système de supprimer cette gamme.
3. Si l’utilisateur confirme la suppression alors le système vérifie si la gamme courante possède des
ordres de fabrication dans ce cas le système interdit la suppression et déclenche exception 2 sinon le
système valide la suppression et retourne à l’écran initial.
Exceptions :
Exception 2 : Le système affiche un message indiquant « Impossible de supprimer une gamme de

fabrication qui possède déjà un ordre de fabrication».
3.4.8. Diagramme de cas d’utilisation « Gérer ordres de fabrication »
Le diagramme illustré par la figure 15 montre les fonctionnalités liées à la gestion des ordres
de fabrications. La description textuelle détaillée est récapitulée dans le tableau 10.
42
Figure 15 : Diagramme de cas d 'utilisation : gérer ordres de fabrication
Tableau 3 : Description textuelle du cas d’utilisation « Gérer ordre de fabrication »
Identification :
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.
43
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 :
a. Ajouter ordre de fabrication :
1. L’utilisateur demande au système d’ajouter un ordre de fabrication.
2. Le système affiche le formulaire de création d’un ordre de fabrication.
3. L’utilisateur saisit toutes les informations nécessaires (date début, heure début, quantité).
5. Par la suite l’utilisateur sélectionne le produit à fabriquer.
6. L’utilisateur sélectionne un responsable pour cet ordre de fabrication.
7. L’utilisateur sélectionne une gamme de fabrication adéquate.
7. Le système vérifie que le produit sélectionné possède déjà une nomenclature sinon il
Si toutes les informations sont validées, le système enregistre le nouvel ordre de fabrication
puis affiche la liste des ordres de fabrications.
b. Editer ordre de fabrication :
1. L’utilisateur accède au formulaire de gestion des ordres de fabrications.
2. L’utilisateur parcourt la liste des ordres de fabrications, sélectionne un ordre de fabrication

selon un critère de recherche (date début, état ordre) et demande au système de le modifier.
4. L’utilisateur modifie les informations qui peuvent être modifiées, Puis il demande au système
de valider les informations saisies.
c. Supprimer ordre de fabrication :
44
1. L’utilisateur parcourt la liste des ordres de fabrications, sélectionne un ordre de fabrication

et demande au système de supprimer cet ordre.
3. Si l’utilisateur confirme la suppression alors le système valide la suppression et retourne à

l’écran initial.
Exceptions :
Exception 1 : Le système affiche un message indiquant « Ce produit ne possède pas de

nomenclature».
3.4.9. Diagramme de cas d’utilisation « Traiter les opérations de fabrication »
Le diagramme illustré par la figure 16 montre les fonctionnalités liées au traitement des
opérations de fabrication La description textuelle détaillée est récapitulée dans le tableau 11.
Figure 16 : Diagramme de cas d 'utilisation : Traiter les opérations de fabrication
45
Tableau 4 : Description textuelle du cas d’utilisation « Traiter opérations de fabrication »
Identification :
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 consulter les informations relatives à cette opération.
Précondition : L’utilisateur est authentifié.
Post-conditions :
-Effectué un traitement sur une opération de fabrication.
Scénario :
Commencer opération de fabrication :
1. L’utilisateur demande au système de consulter un ordre de fabrication.
2. Le système affiche les informations relatives à l’ordre de fabrication sélectionné.
3. L’utilisateur clique sur un bouton pour accéder à l’interface de suivi des opérations.
4. L’utilisateur clique sur le bouton commencer pour démarrer 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.
Mettre en pause une opération de fabrication :
46
4. L’utilisateur clique sur le bouton mettre en pause pour arrêter une opération.
Terminer opération de fabrication :
4. L’utilisateur clique sur le bouton terminer pour achever une opération.
Conclusion
Dans ce chapitre, nous avons analysé les différents besoins de notre projet. Ces besoins ont
été spécifiés à l’aide des diagrammes des cas d’utilisation d’UML. Dans le chapitre suivant,
nous décrivons d’une façon détaillée l’architecture ainsi que la conception de notre système.
47
Chapitre IV : Architecture et conception détaillée du système
Chapitre IV : Architecture et conception détaillée

du système
Plan du chapitre :
4.1. Architecture globale du système ........................................................................ 49
4.2. Aspect statique du système ................................................................................ 52
4.3. Diagrammes des séquences ................................................................................ 63
4.4. Diagramme d’activité ......................................................................................... 66
48
Introduction
Afin de mieux comprendre le système à développer, une démarche structurée s’impose.
Nous avons choisi d’utiliser le langage UML pour la modélisation des différents aspects de
notre système, ce qui permet de structurer le développement. Nous présentons, en premier lieu,
l’architecture globale que nous avons suivi dans notre application. Ensuite, nous présentons une
vue statique du système.
4.1. Architecture globale du système

Dans cette section, nous allons présenter l’architecture logicielle ainsi que l’architecture
physique de notre solution.
4.1.1. Architecture logicielle
L’architecture logicielle s’intéresse au découpage logique de l’application et la façon de

regrouper les composants selon le type de fonction et traitements qu’ils effectuent. Pour notre
solution nous avons opté pour une architecture multicouches illustrée par la figure 17
Figure 17 : Architecture logicielle
49
4.1.1.1. Couche de présentation
Cette couche de plus haut niveau, responsable de l’affichage des données et de l’aspect
visuel et graphique de l’application. Elle fait appel à la couche applicative pour répondre aux
requêtes du client. La figure 18 présente l’architecture de la couche présentation.
Figure 18 : Architecture de la couche présentation
Module : Un module est un fichier de code avec son propre scope. Ce code se concentre
généralement sur une tâche précise.
Component : c’est une classe JavaScript, qui contient la configuration du composant.
Les métadonnées : Les métadonnées est la façon de définir le traitement d’une classe.
Template : Les templates sont la partie visible d’une application Angular. Ils mélangent
code HTML et code Angular.
Directive : c’est similaire à un composant, mais sans template. Elle permet d’ajouter un
comportement à un élément.
Liaison par attributs ou binding des propriétés : écrire dans n’importe quelle propriété
du DOM sur les éléments HTML.
50
Liaison par évènement : c’est un déclenchement des événements qu’on peut écouter :
click, keyup, mousemove qui permet l’exécution d’une méthode déclarée.
Service : Les services représentent une vaste catégorie qui inclut toute valeur, fonction, ou
fonctionnalité dont une application a besoin.
4.1.1.2. Couche de métier
Elle contient tous les traitements métiers de l’application à savoir les services des différents
modules fonctionnels, les services de communication avec la base de données. La couche
Helper définit un service auxiliaire cachée au client et elle est utilisée en interne pour satisfaire
un besoin spécifique la couche service.
4.1.1.3. Couche persistance
Cette couche est la responsable de la récupération et de la persistance des données. La

couche Repository encapsulé dans la couche DAO, d’écrire plus simplement l’accès aux
données à travers une couche d’abstraction commune à de multiples sources de données.
La couche Entity représente une abstraction des tables de la base de données sous forme des
classes java.
4.1.2. Architecture physique
L’architecture physique comprend l’ensemble des composants matériels supportant

l’application ainsi que les composants logiciels implémentés sur ces composants matériels.
L’architecture physique choisie est l’architecture n-tiers comme le montre la figure 19.
Figure 19 : Architecture physique

51
Le choix pour une telle architecture s’explique principalement par ses avantages. En effet
elle permet de :
– avoir un découplage des aspects métier et technique et des services entre eux d’où une
meilleure modularité.
– garantir une facilité d’évolution : en garantissant un couplage faible entre les services ce
qui permet de faire évoluer les services un par un sans modification du reste de l’application.
– garantir une facilité de passage à l’échelle : évolution de certains services.
Pour mettre en place une telle architecture l’équipe a disposé de :
• Un client léger : c’est le navigateur web permettant à l’utilisateur d’accéder aux différentes
interfaces homme-machine de l’application.
• Un serveur d’application front-end : c’est le serveur qui contient l’application frontale

celle-ci utilisée par les utilisateurs finaux et qui communique directement avec l’application
back-end résidente dans le serveur back-end.
• Un serveur d’application back-end : c’est le serveur qui contient l’application back- end
celle qui accède aux données à la demande de l’application front-end afin de retourner un
contenu compréhensible et représenté dans l’application frontale.
• Un serveur de base de données : ce serveur est utilisé pour la partie persistance des données
de l’application.
4.2. Aspect statique du système

Dans cette partie, nous commençons par une illustration des différents packages de notre
application à travers le diagramme de paquetages, puis nous enchainons avec les diagrammes
de classes de chaque package.
4.2.1. Diagramme de paquetage
Nous illustrons les différents paquetages côté client et côté serveur afin de fournir une
représentation graphique de haut niveau de l’organisation de notre application. La figure 20
illustre le diagramme de package côté client.
52
Figure 20 : Diagramme de package de la partie front-end
Le package app.module décrit comment les pièces d’application sont emboîtées. Le package
manufacturing.module décrit le package principale, de l’application qui contient l’ensemble des
composants Angular et leur services et template respectives. Les classes de logique métier sont
définies sous le répertoire Métier.
Le package shared englobe un ensemble des directives, pipes et composants communs par
l’ensemble des templates de notre application décrit par la figure 20.
53
Afin de mieux comprendre notre solution, nous présentons dans la figure 21 le diagramme
de package qui expose la composition de la partie serveur de notre application. Ce diagramme
est composé de dix packages principaux à savoir :
-fr.sparkit.controllor : Ce package regroupe les classes responsables à l’interprétation avec

les requêtes http provenant du couche présentation.
- fr.sparkit.serviceImp : Ce package contient la logique métier de notre application.
-fr.sparkit.service.utils: ce package contient les codes d’erreurs lancés par les exceptions
gérées par les contrôleurs.
- fr.sparkit.repository : ce package communique avec la couche entity pour servi la couche

service.
- fr.sparkit.converters : ce package qui s’occupent de la conversion des entities vers des

DTO et vice-versa.
- fr.sparkit.entity : Il regroupe les entités de notre application. Ces entités permettent le

transfert des données depuis la couche métier jusqu’à arriver à la couche présentation, et vice-
versa.
- fr.sparkit.config : ce package contient la configuration nécessaire de l’application tel que

les informations de sécurité, le schéma de la base de données et la configuration globale.
- fr.sparkit.dto : ce package résume une représentation du modèle de données. Cette couche

servit la couche présentation afin de représenter les entités.
-fr.sparkit.dao.repository : ce package vise à réduire la quantité de code requis pour

implémenter l’accès aux données.
54
Figure 21 : Diagramme de package de la partie back-end
4.2.2. Diagramme de classes de la couche « fr.sparkit.controller »
Le diagramme de paquetages précédant contient les modules ainsi que les couches du
système à réaliser. Afin de mieux présenter la structure de ces couches, nous présentons les
diagrammes « de » classe associés. Dans cette couche, nous trouvons neuf classes java dont
chacune fait référence à un module. Chaque classe est constituée de plusieurs services Web qui
présentent un moyen rapide de distribution de l’information entre le client et sa partie back-end.
La figure 22 représente le diagramme de classe de la couche «fr.sparkit.controller» de notre

solution.
55
Figure 22 : Structure de la couche « fr.sparkit.controller »
4.2.3. Diagramme de classes de la couche « fr.sparkit.service »
En ce qui concerne la couche service, la figure 23 illustre son diagramme de classes. Ce

diagramme comporte les classes suivantes :
NomenclatureService : Il s’agit d’une interface implémentée par la classe

NomenclatureServiceImpl. Cette interface offre les opérations de gestion des nomenclatures
telle que l’ajout, la suppression, la modification ainsi que la consultation.
56
ProductNomenclatureService : Il s’agit d’une interface implémentée par la classe

ProductNomenclatureServiceImp. Cette interface offre la possibilité d’insérer, éditer,
supprimer les composants d’une nomenclature d’un produit à fabriquer.
OperationService : Cette interface implémentée par la classe OperationServiceImpl définit

les opérations liées à la création des opérations d’une gamme de fabrication.
GammeService : Cette interface implémentée par la classe GammeServiceImpl définit les

processus de fabrication de chaque produit à fabriquer.
DetailOperationService : Cette interface implémentée par la classe

DetailOperationServiceImpl offre la possibilité de traiter les opérations de fabrication
(démarrer, mettre en pause, terminer).
AreaService et MachineService : Deux interfaces implémenté par les classes

AreaServiceImpl et MachineServiceImp respective offre des services CRUD.
A noter que tous les services présentés par la figure 23 héritent du service
GenericService.
57
Figure 23 : Structure d’une partie de la couche « fr.sparkit.service»
58
4.2.4. Diagramme de classes de la couche « fr.sparkit.repository »
Cette couche joue l’intermédiaire entre la couche entity et service, permet de faciliter l’accès
aux données exploité par des entity.
La figure 24 illustre la modélisation de la couche à travers un diagramme des classes.

Toutes les classes présentées par la figure 24 héritent de la classe BaseRepository du standard
JPA permettant de traduire des méthodes à des requêtes SQL exécutable sur les classes entity.
59
Figure 24: Structure d’une partie de la couche « fr.sparkit.repository»
60
4.2.5. Diagramme de classes de la couche « fr.sparkit.entity »
-User : Cette classe de stéréotype « entity » encapsule les données relatives au collaborateur
de l’application. Chaque utilisateur a un rôle à savoir un responsable technique, un responsable
de production, opérateur et l’administrateur.
- Nomenclature : Cette classe de stéréotype « entity » regroupe les informations relatives à

une nomenclature.
-ProductNomenclature : Cette classe de stéréotype « entity » définit les composants d’une

nomenclature avec la quantité requise.
-Area : Cette classe de stéréotype « entity » contient des informations relatives à un atelier
de fabrication.
-Machine : Cette classe de stéréotype « entity » contient des informations relatives à une
machine de fabrication
-Opération : Cette classe de stéréotype « entity » contient des informations relatives à une
opération de fabrication contenant la durée et le responsable ainsi que la machine sur laquelle
se déroule l’opération.
-Gamme : Cette classe de stéréotype « entity » contient des informations relatives à une
gamme de fabrication tel que l’ensemble des opérations avec l’ordre de chaque opération.
-FabricationArrangement : Cette classe de stéréotype « entity » contient des informations

relatives à un ordre de fabrication
-DétailOperation : Cette classe de stéréotype « entity » garde le suivi de chaque opération

effectuée avec l’état démarrée, en pause et terminée.
A noter que l’entité Produit existe déjà dans l’ERP dans un module implémenté avec
le langage .net, nous faisons une communication entre le back-end .net pour consommer
les identifiants des produits.
Nous passons l’identifiant du produit sous forme d’une référence faible (week-
reference).
61
Figure 25 : Structure de la couche « fr.sparkit.entity»
62
4.3. Diagrammes des séquences

Le diagramme de séquence représente la succession chronologique des opérations réalisées
par un acteur, il indique les objets que l’acteur va manipuler, et les opérations qui font passer
d’un objet à l’autre, il se concentre sur la séquence des envois de message.
La figure 26 présente le diagramme de séquence de diagramme du cas d’utilisation ˝ gestion

des nomenclatures ˝ .
63
 Gestion des nomenclatures :
Responsable
technique
Figure 26 : Diagramme de séquence système ˝ Gestion des nomenclatures ˝

64
La figure 27 présente le diagramme de séquence du cas d’utilisation ˝gestion des ordres de fabrications ˝.
Gestion des ordres de fabrication
Figure 27 : Diagramme de séquence système ˝ Gestion de l’ordre de fabrication
65
4.4. Diagramme d’activité

Un diagramme d’activités permet de modéliser les traitements. Il permet aussi de
représenter graphiquement le comportement d’une méthode ou la réalisation d’un cas
d’utilisation.
Diagramme d'activité « Traiter opération »
Le diagramme d'activité de la figure 28 permet de modéliser les traitements possibles sur

une opération.
L'opérateur peut commencer une opération, la mettre en pause, continuer une opération et
enfin l’arrêter.
Figure 28 : Diagramme d'activité « Traiter une opération»
Conclusion
Au cours de ce chapitre, nous avons mis en place la partie conception de l’application. Ainsi,
nous avons présenté l’architecture adoptée. Puis, nous avons montré une vue statique du
système. Dans le chapitre suivant, nous décrivons la partie réalisation.
66
Chapitre V : Réalisation
Plan du chapitre :
5.1. Environnement de travail ................................................................................... 68
5.2. Choix technologiques ................................................ Erreur ! Signet non défini.
5.3. Environnement de développement et Framework utilisés ................................. 70
5.4. Travail réalisé ..................................................................................................... 72
67
Introduction
Dans ce chapitre, nous présentons, en premier, lieu l’environnement matériel ainsi que
logiciel de développement de l’application. En second lieu, nous exposons les différentes étapes
de réalisation de notre projet via l’essentiel des interfaces de notre solution
5.1. Environnement de travail

Nous présentons dans cette section, les choix techniques relatifs à l’environnement matériel
et logiciel qui ont contribué à la réalisation du notre plateforme de gestion des missions.
Environnement matériel
Nous mentionnons les caractéristiques de l’ordinateur sur laquelle nous avons développé
notre application pour l’environnement matériel. L’application a été développée en premier
temps sur un ordinateur ayant les caractéristiques illustrées par le tableau 12.
Tableau 5 : Environnement matériel utilisé
Processeur SE RAM Disque dur
Intel Core i7- Windows 10 Professional ,64 8GO 1 TO

8250U bits
5.2. Outils utilisés

Dans cette section, nous illustrons l’architecture générale de notre solution suivant les
technologies adoptées tout en justifiant nos choix pour les langages et technologies adoptés :
L’IDE « Intellij Idea »

C’est un environnement de développement intégré
IDE qui supporte le développement Java EE, il s’agit d’un
produit développé par jetBrains[7].
Logo 2 : Intellij Idea
68
L’IDE « Web Storm »
WebStorm est un IDE pour les langages (HTML,

CSS et JavaScript), dévellopé par l’entreprise JetBrain et
basé sur la plateform Intellij Idea [8].
Logo 3 : WebStorm
Microsoft SQL Server
C’est système de gestion de base de données en

langage SQL incorporant entre autres un SGBDR
(SGBD relationnel ») développé et commercialisé par la Logo 4 : SQL Server 2016
société Microsoft [9].
Swagger
Swagger offre des outils permettant de générer la

documentation pour son API Web. Il offre également une
interface permettant d’explorer et tester les différentes
Logo 5 : Swagger
méthodes offertes par le service [10].
TFS
Team Foundation Server (TFS) est une forge

logicielle éditée par Microsoft permettant la gestion des
sources, la gestion des builds, le suivi des éléments de Logo 6 : TFS
travail, la planification, la gestion de projet et l'analyse des
performances [11].
69
Git
Dans le but de gérer leur code source, les sociétés

sont appelées à utiliser un logiciel de gestion des versions
qui permet de stocker un ensemble de fichiers en conservant
la chronologie de toutes les modifications subies et de
retrouver les différentes versions d'un lot. [12] Logo 7 : Git
Donc, les logiciels de gestion de versions sont
utilisés en développement logiciel pour conserver le code
source relatif aux différentes versions d'un logiciel.
SonarQube
SonarQube [13] est un logiciel open-source

permettant d’analyser la qualité du code source d'un projet
de développement dans de multiples langages (JAVA,
Javascript, PHP, C# …)
Logo 8 : SonarQube
La qualité est analysée sur les points suivants :
- Duplication de code
- Documentation
- Tests unitaires et couverture de code
- Règles de programmation
- Analyse de la complexité
- Bugs potentiel
5.3. Environnement de développement et Framework utilisés
70
Java EE
Java Platform, Enterprise Edition, ou Java EE est un

ensemble de spécifications coordonnées et pratiques qui
permettent des solutions pour le développement, le
déploiement, et de la gestion des applications multi-tiers
Logo 9 : Java Entreprise
centralisées sur un serveur. Construite sur la plateforme de Java Edition
pour édition standard (Java SE), la plateforme Java EE ajoute
les possibilités nécessaires pour fournir une plateforme
complète, stable, sécurisée, et rapide de Java au niveau
entreprise [14].
Maven
Apache Maven est un outil pour la gestion et

l'automatisation de production des projets logiciels Java en
général et Java EE en particulier. L'objectif recherché est
comparable au système make sous Unix : produire un logiciel Logo 10 : Maven
à partir de ses sources, en optimisant les tâches réalisées à cette

fin et en garantissant le bon ordre de fabrication [15].
Hibernate
Hibernate [16] est une solution open source de type

ORM (Object Relational Mapping) qui permet de faciliter le
développement de la couche persistance d'une application.
Hibernate permet donc de représenter une base de données en
objets Java et vice versa.
Logo 11 : Hibernate
Il facilite la persistance et la recherche de données dans une

base de données en réalisant lui-même la création des objets et
les traitements de remplissage de ceux-ci en accédant à la base
de données. Hibernate est très populaire notamment à cause de
ses bonnes performances et de son ouverture à de nombreuses
71
bases de données (Oracle, MySQL, PostgreSQL, SQL Server

…)
Spring Boot
Spring Boot permet de créer facilement des applications

Spring basées sur la production. Il adapte une vision avisée de
la plate-forme Spring et des bibliothèques tierces afin que les
Logo 12 : Spring Boot
développeurs puissent commencer avec un minimum
d'agitation. La plupart des applications Spring Boot nécessitent
très peu de configuration Spring [17].
Angular 5
Angular [18] est une plateforme qui facilite la création

d’applications sur le Web. Il combine des modèles déclaratifs,
des injections de dépendances, des outils de bout en bout et des
meilleures pratiques intégrées pour résoudre les problèmes de
développement. Angular permet aux développeurs de Logo 13 : Angular 5
construire des applications qui vivent sur le web, le mobile ou
le bureau.
5.4. Travail réalisé

Cette partie nous exposons quelques interfaces Homme/Machine afin de montrer les
services offerts par l’application. Grâce à une structuration bien organisée des différentes
fonctionnalités, et grâce aux UX et UI, l’équipe a pu offrir des interfaces simples, lisibles et
faciles à manipuler.
72
Figure 29 : Interface liste des nomenclatures
La figure 29 représente l’interface des nomenclatures qui permet au responsable technique

de :
Afficher la liste des nomenclatures sous forme de page(pagination).
Chercher une nomenclature avec sa référence.
73
Figure 30: Interface consultation nomenclature
La figure 30 représente l’interface de consultation d’une nomenclature qui permet au

responsable technique de :
Consulter le coût de la nomenclature avec la devise par défaut de la société.
Ajouter un composant à la nomenclature courante.
Editer les informations d’un composant de la nomenclature courante.
Supprimer un composant de la nomenclature courante.
Editer les informations de la nomenclature courante.
74
Figure 31 : Interface liste des composants avec pagination
La figure 31 représente l’interface de la liste des composants d’une nomenclature qui permet
au responsable technique de :
Afficher les composants d’une nomenclature sous forme de page (Pagination).
75
Figure 32 : Interface structure nomenclature sous forme d’une arbre
La figure 32 représente l’interface structure nomenclature qui permet au responsable

technique de :
Afficher les composants d’une nomenclature à N niveaux.
Afficher pour chaque niveau le prix d’achat d’un composant.
Afficher pour chaque composant qui possède déjà une nomenclature, à N niveaux, le coût
de sa nomenclature.
76
Figure 33 : Interface suppression d'une nomenclature
La figure 33 représente l’interface de suppression d’une nomenclature qui permet au

responsable technique de :
-Confirmer la suppression d’une nomenclature sélectionnée.
-Annuler la suppression d’une nomenclature sélectionnée.
Figure 34 : Interface notification de suppression d'une nomenclature
77
La figure 34 représente une notification d’exception qui montre que la nomenclature à

supprimer est déjà utilisée dans un ordre de fabrication en cours de fabrication.
Figure 35 : Interface de modification d'une gamme de fabrication
La figure 35 représente l’interface de modification d’une gamme de fabrication qui permet

au responsable de production de :
Ajouter une opération à la gamme fabrication courante.
Editer les informations d’une opération de la gamme de fabrication courante.
Supprimer une opération à la gamme fabrication courante.
Editer les informations relatives à la gamme de fabrication courante.
78
Figure 36 : Interface de création d'un ordre de fabrication
La figure 36 représente l’interface de création d’un nouvel ordre de fabrication.
79
Figure 37 : Interface :liste des composants manquants en stock
La figure 37 représente la liste des composants manquants au moment de la création d’un

ordre de fabrication.
80
Figure 38 : Interface de suivi d'un ordre de fabrication
La figure 38 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 (non lancée, en cours,
en pause, terminée) :
-Pour commencer une opération, l'opérateur sélectionne le bouton " Démarrer ".
-Pour mettre en pause une opération, l'opérateur sélectionne le bouton " Pause ".
-Pour relancer une opération l'opérateur sélectionne le bouton " Continuer ".
-Pour terminer une opération l'opérateur sélectionne le bouton " Terminer ".
81
Figure 39 : Interface :recherche d'une opération de fabrication
La figure 39 présente l'interface de l'opérateur ou il peut chercher une opération à travers sa

référence. Cette interface contient la liste des informations concernant l’ordre de fabrication qui
se présente par :
-La description de produit à fabriquer.
-Le responsable de l’ordre de fabrication.
-Le nombre d’opérations pour fabriquer ce produit.
-La quantité à fabriquer.
82
Figure 40 : Interface export informations d'un ordre de fabrication sous forme d'un fichier
La figure 40 présente l’interface d’export des informations relatives à un ordre de

fabrication qui permet au responsable de production :
Consulter le coût de chaque machine selon la durée de travail de chaque opération de

fabrication.
83
Consulter le coût de main d’œuvre selon la durée de travail de chaque opération.
Consulter le coût total de fabrication d’une nomenclature en matière première et de main

d’œuvre.
Figure 41 : Demande de tirage code front-end
La figure 41 présente une demande de tirage(Pull-request) de la partie front-end du code de

l’ERP.
Un réviseur obligatoire qui fait une vérification sur le code source puis il accepte la
demande pour l’intégrer dans la branche Master.
84
Figure 42 : Build sur l'environnement d'intégration continue
Après une révision de la demande de tirage, un build sur l’environnement d’intégration

continue est lancé.
La figure 42 montre la réussite d’un build d’intégration continue.
Conclusion
Dans ce chapitre, nous nous sommes intéressés à la réalisation des fonctionnalités de notre
solution. Nous avons décelé cette réalisation à travers un ensemble d’interfaces accompagnées
de description et interprétation. Nous clôturons notre travail par une conclusion qui résume
notre travail et avise ses futures perspectives.
85
Conclusion générale
Le capital humain est un facteur de succès au sein des entreprises. De ce fait, savoir gérer
d’une manière efficace ses ressources et garantir une communication rapide de l’information
doit avoir un rôle stratégique pour l’entreprise. C’est dans ce cadre que s’est inscrit ce projet de
fin d’études au sein de la société Spark-it. Il consiste à concevoir, implémenter et déployer
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 technique jusqu’à la réalisation. Nous avons décomposé cet outil en plusieurs
fonctionnalités : la gestion des machines, la gestion des ateliers la gestion des nomenclatures,
la gestion des gammes de fabrication, la gestion des opérations de fabrication, gestion des ordres
de fabrication et le suivi de chaque ordre de fabrication.
Pour atteindre cet objectif, nous avons commencé par l’étude préalable qui a permis de
décrire et de comprendre les principaux concepts des ERPs qui existent dans les marchés en
identifiant les ERPs qui automatise 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 front-end (Angular) et back-end (Java).
Puis nous avons passé à l’analyse et la spécification des besoins et exigences. Ensuite, 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 moyennant les différentes
technologies et techniques aussi bien choisies que celles exigées par l’entreprise. Ce travail
nous 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 Java/JEE et Web, et toucher de près plusieurs
aspects du cycle de vie d’un produit logiciel. Par ailleurs, le projet était 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
(SpringBoot, Angular, Spring data).
86
Hormis le côté technique, ce projet a été une opportunité d’appréhender le travail dans une
hiérarchie professionnelle au sein d’une grande société et, les difficultés inhérentes comme la
répartition du temps et des efforts. Il nous a permis aussi d’apprendre les bonnes pratiques
nécessaires à la réalisation d’un produit de qualité.
Notre application a réussi à mettre en place la majorité des fonctionnalités demandées,

mais, comme tout autre travail, il ne peut prétendre la perfection. Alors, ce travail peut être
amélioré en lui ajoutant une automatisation de la chaine de production par des capteurs dans les
postes des opérateurs et l’amélioration de l'aspect ergonomique et essayant d’augmenter les
performances afin de l’intégrer finalement dans notre système.
87
Annexe : Backlog du produit :
Le backlog est une liste de fonctionnalités à réaliser. Ces fonctionnalités, exprimées sous
forme de besoins, sont priorisées par les Product Owner ce qui permet d’établir un ordre à
respecter lors de la réalisation de l’application. Le tableau présente l’ensemble des histoires des
utilisateurs. Ces histoires sont décrites à l’aide de leur id, noms et l’estimation.
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.
— Le champ Estimation estime charge de travail.
Fonctionnalité ID User Story User Story Estimation
1.1 En tant que responsable technique, je peux

m’authentifier afin d’accéder à l’application
En tant que responsable de production, je

peux m’authentifier afin d’accéder à
1.2
l’application
1Authentification 1.3 En tant qu’un opérateur, je peux 36 heures
1.4 En tant que administrateur, je peux


créer un produit.

éditer les informations d’un produit.
2 Gestion des
produits
supprimer un produit.
48 heures
chercher un produit à travers sa référence.
88
En tant que responsable technique, je peux
consulter la liste des produits sous forme de
2.5
pages.
3.1 En tant que responsable technique, je

peux créer un atelier.

peux éditer les informations d’un atelier.

peux supprimer un atelier.
3 Gestion des 16 heures
En tant que responsable technique, je
ateliers
peux chercher un atelier à travers sa
3.4
référence.

peux consulter la liste des ateliers sous
3.5
forme de pages.

peux créer une machine .

peux éditer les informations d’une
4.2
machine.

peux supprimer une machine.
4 Gestion des En tant que responsable technique, je 16 heures

machines peux chercher une machine à travers sa
4.4
référence

peux affecter un atelier à une machine.
89
peux consulter la liste des machines sous
4.6
forme de pages.

peux créer une nomenclature.

Gestion des
peux éditer les informations d’une
nomenclatures 5.2
nomenclature.

peux supprimer une nomenclature.

peux chercher une nomenclature à
5.4
travers sa référence.

peux ajouter les composants à une
5.5
nomenclature.

peux éditer les composants à d’une
5.6
nomenclature.

peux supprimer des composants à d’une
5.7
nomenclature.

peux consulter les composants d’une
5.8
82 heures
nomenclature.
Gestion des
nomenclatures En tant que responsable technique, je
5 peux consulter les coûts de chaque
5.9
composant .
90
peux consulter les coût total d’une
5.10
nomenclature.

peux consulter les composants d’une
5.11
nomenclature sous forme d’une
TreeView.

peux consulter les composants d’un
5.12
produit fils à partir du TreeView.
En tant que responsable technique,

je peux naviguer vers une nomenclature
5.13
d’un produit qui possède déjà une
nomenclature en cliquant deux fois sur le
composant.

peux consulter la listes des composants
5.14
sous forme de pages.

peux consulter la listes des
5.15
nomenclatures sous forme de pages.
Gestion des
nomenclatures
6.1 En tant que responsable de

production, je peux créer une gamme de
fabrication .
91
En tant que responsable de
production, je peux éditer les
6.2
informations d’une gamme de
fabrication .

Gestion des production, je peux supprimer une
6.3
gammes de gamme de fabrication.
6
fabrication En tant que responsable de
production, je peux consulter une
6.4
gamme de fabrication. 32 heures

production, je peux créer une opération
6.5
et l’affecter à une gamme de fabrication.

production, je peux éditer une opération
de fabrication.

production, je peux supprimer une
opération de fabrication.

fabrication, je peux consulter la liste des
6.8
gammes de fabrication sous forme des
pages

production, je peux créer un ordre de
fabrication.

production, je peux éditer les
7.2
informations d’un ordre de fabrication.
92
production, je peux supprimer un ordre
de fabrication.

production, je peux chercher un ordre de
fabrication

production, je peux consulter les
7.5
composants manquants en stock pour le
produit à fabriquer.

production, je peux consulter le coût de
chaque machine selon la durée de travail
7Gestion des ordres 7.6 de chaque opération de fabrication.
de fabrications
88 heures
production, je peux consulter le coût de
7.7
main d’œuvre de chaque responsable
d’opération selon la durée de travail de
chaque opération de fabrication.

fabrication, je peux consulter le coût
total (coût matière premiers + coût main
d’œuvre)

fabrication, je peux naviguer vers
l’interface de création d’une
7.6 nomenclature si le produit à fabriquer ne
possède pas une nomenclature.

fabrication, je peux consulter la liste des
93
7.7 ordres de fabrications sous forme des
pages.
En tant que responsable production,

je peux consulter l’état d’avancement
8.1
d’un ordre de fabrication .
En tant qu’opérateur, je peux

démarrer une opération de fabrication.
8.2
8.3 En tant qu’opérateur, je peux mettre

en pause une opération de fabrication.
8.5 En tant qu’opérateur, je peux

continuer une opération de fabrication.
8.6 En tant qu’opérateur, je peux

terminer une opération de fabrication.
8 Suivi ordre de 72 heures
fabrication En tant que responsable production,
je peux chercher un opération de
fabrication à travers la référence de
8.7 l’opération.
En tant qu’ opérateur, je peux

chercher un opération de fabrication à
8.8
travers la référence de l’opération.
A noter qu’avant de commencer un UserStory, nous démarrons avec une phase d’analyse et
de conception pour chaque fonctionnalité à implémenter.
94
Bibliographie
[1] [En ligne]. Disponible : https://comparisons.financesonline.com/odoo-vs-microsoft-

dynamics-nav.
[2] [En ligne]. Disponible : https://ineumann.developpez.com/tutoriels/alm/agile_scrum/.
[3] [En ligne]. Disponible : https://fr.wikipedia.org/wiki/Scrum_(d%C3%A9veloppement).
[4] [En ligne]. Disponible : https://www.myagilepartner.com/blog/index.php/2019/02/21/
ceremonies-scrum-sprint/
[5] [En ligne]. Disponible: https://www.choisirmonerp.com/erp/definition-d-un-erp.
[6] [En ligne]. Disponible : https://tel.archives-ouvertes.fr/tel-01059804/document
[7] [En ligne]. Disponible : https://www.jetbrains.com/idea/
[8] [En ligne]. Disponible : https://dev.to/mokkapps/why-i-switched-from-visual-studio-
code-to-jetbrains-webstorm-939
[9] [En ligne]. Disponible : https://fr.wikipedia.org/wiki/Microsoft_SQL_Server
[10] [En ligne]. Disponible: https://www.developpez.com/actu/178434/Comprendre-la-
specification-OpenAPI-Swagger-et-apprendre-a-utiliser-Swagger-Editor-par-Hinault-
Romaric/.
[11] [En ligne]. Disponible: https://fr.wikipedia.org/wiki/Team_Foundation_Server.
[12] [En ligne]. Disponible :
https://www.wikiwand.com/fr/Logiciel_de_gestion_de_versions
[13] [En ligne]. Disponible: https://www.supinfo.com/articles/single/2976-testez-qualite-
votre-code-avec-sonarqube.
[14] [En ligne]. Disponible:
https://javaweb.developpez.com/faq/javaee/?page=Definitions.
[15] [En ligne]. : https://fr.wikipedia.org/wiki/Apache_Maven.
[16] [En ligne]. Disponible: https://www.jmdoudoux.fr/java/dej/chap-hibernate.htm.
[17] [En ligne]. Disponible: https://spring.io/projects/spring-boot.
[18] [En ligne]. Disponible: https://blog.arcoptimizer.com/comment-construire-une-
application-de-nouvelles-avec-angular-6-et-la-conception-materielle.
95

Conception Et Développement D'un Module ERP Gestion de La Production

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Et Développement D'un Module ERP Gestion de La Production

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne Cycle de Formation d’Ingénieurs dans

Ministère de l’Enseignement Supérieur la Discipline Génie Informatique

L’Ecole Nationale d’Ingénieurs de Sfax

Du Diplôme National d’Ingénieur en Génie Informatique

Soutenu le 14 novembre 2019, devant la commission d'examen:

Mme. Fadoua DRIRA Présidente

A mes très chers parents

Que ce travail soit l’expression de ma reconnaissance pour vos

sacrifices consentis, votre soutien moral et matériel que vous n’avez

cessé de prodiguer. Vous avez tout fait pour mon bonheur et ma

A MES FRERES, SŒURS, LEURS EPOUX ET LEURS ENFANTS

Vous étiez toujours présents pour m’aider et m’encourager. Sachiez

que vous serez toujours dans mon cœur,

Que ce travail soit l’expression de ma grande affectation et mon

profond amour et attachement,

exprime toute ma gratitude.

Au de la des mots, Merci, je vous aime.

A tous mes amis qui n’ont cessé de m’encourager et de me soutenir

travail et en premier lieu, mon encadrant Monsieur Riadh BEN

Halima pour son aide, sa disponibilité, et ses qualités humaines m'ont

profondément touché. Je vous remercie pour votre accueil et vos

conseils. Veuillez trouver ici, l’expression de mes gratitudes et de ma

Ma gratitude s'adresse, aussi, à Madame Fadoua Drira pour m’avoir

fait le grand honneur d'accepter d'être la présidente de ce jury. Qu'elle

trouve ici l'expression de mon profond respect.

Je tiens à exprimer a vive gratitude à Madame Manel Elleuchi qui a

bien voulu faire partie du jury de ce projet et pour l'intérêt qu'elle a

porté à ce travail. Qu'elle soit remerciée.

Je souhaite aussi adresser mes remerciements les plus vifs à M. Amin

Karray et toute l’équipe de Spark-it pour leurs conseils pratiques et leur

assistance continue qu’ils m’ont apportée tout au long de la période du

Mes remerciements s’adressent aussi à ma famille, mes amis, pour leurs

aides à mener à terme ce travail. Finalement, je tiens à remercier tous

ceux qui, de près ou de loin, m’ont apporté un soutien moral ou matériel.

Chapitre I : Présentation du projet........................................................................................ 2

1.1. Présentation de l’organisme d’accueil .................................................................. 3

1.1.1. Présentation générale de Spark-it.................................................................. 3

1.1.2. Domaines d’activité ...................................................................................... 3

1.1.3. Les références de Spark-it ............................................................................. 4

1.2. Présentation générale du projet ............................................................................ 4

1.2.1. Contexte ........................................................................................................ 4

1.2.2. Objectif du projet .......................................................................................... 4

1.3. Etude de l’existant ................................................................................................ 4

1.3.1. Analyse des solutions existantes ................................................................... 5

1.3.2. Critique des applications existantes .............................................................. 6

1.3.3. Solution proposée.......................................................................................... 6

1.4. Méthodologie de travail ....................................................................................... 7

1.4.1. Méthode Scrum ............................................................................................. 7

1.4.2. Les principaux rôles de la méthode scrum .................................................... 8

Chapitre II : Etude préalable ................................................................................................ 9

2.1. Etude de l’art ...................................................................................................... 10

2.1.1. Progiciel de gestion ..................................................................................... 10

2.1.2. Fonctionnalités et modularités .................................................................... 10

2.1.3. Les avantages d'un ERP .............................................................................. 11

2.1.4. Les inconvénients d’un ERP ....................................................................... 11

2.2. Principe de fonctionnement de GPAO ............................................................... 12

2.2.1. Système de Production (SP)........................................................................ 12

2.2.2. Gestion de production (GP) ........................................................................ 13

2.2.3. Gestion de Production Assistée par Ordinateur (GPAO) ........................... 14

2.3. Etudes de technologies existantes ...................................................................... 15

Framework front-end ........................................................................................ 15

Chapitre III : Analyse et spécification des besoins ............................................................ 18

3.1. Analyse des besoins ........................................................................................... 19