République Algérienne Démocratique et Populaire

Ministère de l'Enseignement Supérieur et de la Recherche Scientifique

Université M'Hamed Bougara - Boumerdès

Faculté des Sciences

Département d’Informatique

Domaine : Mathématiques Informatique

Filière : Informatique
Spécialité : systèmes d’informatique
N° de l’Arrêté d’habilitation de la spécialité : arrêté n °872 du 26/07/2016

Mémoire de fin d’études en vu de l’obtention du

Diplôme de Licence Académique

Thème

Réalisation d’une application mobile de

gestion de stock

Présenté par :
GHERNOUTI OUSSAMA
ZETCHI YOUVA
LOUBAR WALID

Soutenu le …../…./2022 Devant le jury composé de

MME BOUSTIL AMEL : Examinateur
MME DJEDDAI SELMA : Encadreur
Développement d’une application de gestion
de stock

Zetchi youva
Loubar walid
Ghernouti oussama

13 octobre 2022
 Remerciement
Avant tout développement sur cette expérience professionnelle, il apparaît
opportun de commencer ce rapport de projet de fin d’études par des remer-
ciements à tous ceux qui nous ont appris au cours de ce projet et à ceux qui
ont eu la gentillesse d’en faire un moment très profitable.

Nous tenons, tout d’abord à remercier Dieu le tout puissant, le tout mi-
séricordieux, qui nous a donné la force et la patience d’accomplir ce modeste
travail.

Nous voudrions présenter nos remerciements à notre promotrice interne

Mme. Djeddai Selma pour tout les efforts qu’elle a fait, pour les paroles et
les mots qu’elle a utilisé afin de nous booster et nous tirer vers le haut aussi ;
et pour son intransigeance afin de sortir le meilleur de nous, sans oublier ses
précieux conseils et son aide durant toute la période du travail.

Nous voudrions présenter nos remerciements à notre promoteur externe

notre encadreur au sein d’ENAGEO Mr. KERDIOUI Mohamed Hi-
cham pour son aide et la confiance qu’il nous a accordé pour réaliser ce
projet.

Ces remerciements vont tout d’abord au corps professoral et administratif

de l’université M’hamed Bougara-Boumerdès, plus particulièrement au corps
professoral du département de l’informatique, pour la richesse et la qualité
de leur enseignement et qui déploient de grands efforts pour assurer à leurs
étudiants une formation actualisée.

Nous n’oublions pas, nos parents pour leur contribution, leur soutien et
leur patience.

Nous adressons, aussi, nos vifs remerciements à notre jury Mme. Bous-
til pour l’honneur qu’elle nous fait en acceptant de juger notre travail.

i
 Résumé
Dans un monde de plus en plus concurrentiel, l’informatique est devenu un
outil de gestion et donc de production pour les entreprise, grâce aux logi-
ciels qui font circuler l’information aisément au sein de cette dernière. Ce
mémoire s’inscrit dans le cadre d’un projet de fin d’étude (PFE), et a pour
thème : "conception et réalisation d’une application mobile dédiée à l’entre-
prise ENAGEO", dont le but est d’organiser la gestion des stock

Mots clés
Application Mobile, Gestion de stock, Développement, Informa-
tique, Entreprise, Produit, Flatter, Dart, firestore.

Abstract
In an increasingly competitive world, IT has become a management tool and
therefore a production tool for companies, thanks to software that ease in-
formation circulation in these companies. This work is about the design and
production of a mobile application dedicated to the ENAGEO company, ai-
ming the organisation of the stock.

ii
Table des matières

Liste des figures vi

Liste des tableaux viii

Liste des abréviations x

Introduction générale 1

1 Présentation de l’organisme d’accueil 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Présentation de l’ENAGEO . . . . . . . . . . . . . . . . . . . 2
1.2.1 Historique de l’ENAGEO . . . . . . . . . . . . . . . . 3
1.2.2 Missions de l’ENAGEO . . . . . . . . . . . . . . . . . 3
1.2.3 Domaines d’activités de l’ENAGEO . . . . . . . . . . 4
1.2.4 L’organigramme de l’ENAGEO . . . . . . . . . . . . . 5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Définition des gestions de stock d’une entreprise . . . 5
1.3.2 Contexte de notre travail . . . . . . . . . . . . . . . . 6
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Étude de l’existant 7
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Étude des postes de travail : . . . . . . . . . . . . . . . . . . . 7
2.2.1 Définition : . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Liste des postes de travail : . . . . . . . . . . . . . . . 8
2.2.3 Description des postes de travail . . . . . . . . . . . . 8
2.3 Étude documentaire . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Liste des document . . . . . . . . . . . . . . . . . . . 10
2.3.3 Description des document . . . . . . . . . . . . . . . . 10
2.4 Flux d’information . . . . . . . . . . . . . . . . . . . . . . . . 13

iii
 2.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 Diagramme de flux de données . . . . . . . . . . . . . 13
2.5 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Analyse de besoins 16
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Présentation d’UML . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . 17
3.3.2 Les besoins non fonctionnels . . . . . . . . . . . . . . 17
3.4 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . 17
3.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2 Diagramme de cas d’utilisation Général . . . . . . . . 18
3.4.3 Diagramme de cas d’utilisation détailler . . . . . . . . 19
3.5 Descriptions textuelles . . . . . . . . . . . . . . . . . . . . . . 21
3.5.1 Inscription . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.2 Authentification . . . . . . . . . . . . . . . . . . . . . 22
3.5.3 Consulter demande(s) matériel . . . . . . . . . . . . . 23
3.5.4 Consulter la liste matériel . . . . . . . . . . . . . . . . 24
3.5.5 Effectuer demande d’acquisition . . . . . . . . . . . . 24
3.5.6 Voir la liste des demandes . . . . . . . . . . . . . . . . 25
3.5.7 Faire une commande . . . . . . . . . . . . . . . . . . . 26
3.5.8 Ajouter une facture . . . . . . . . . . . . . . . . . . . 27
3.5.9 Ajouter un fournisseur . . . . . . . . . . . . . . . . . . 28
3.5.10 Modifier la liste du matériel . . . . . . . . . . . . . . . 28
3.5.11 Gérer les comptes . . . . . . . . . . . . . . . . . . . . 30
3.5.12 Gérer fournisseurs . . . . . . . . . . . . . . . . . . . . 31
3.5.13 Gérer factures . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Diagrammes De Séquences . . . . . . . . . . . . . . . . . . . 33
3.6.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6.2 Composition d’un diagramme de séquences . . . . . . 33
3.6.3 Diagramme de séquence "d’inscription" . . . . . . . . 33
3.6.4 Diagramme de séquence"d’authentification" . . . . . . 34
3.6.5 Diagramme de séquence "Consulter demande matériel" 35
3.6.6 Diagramme de séquence "Effectuer une demande d’ac-
quisition" . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6.7 Diagramme de séquence "Faire une commande" . . . . 37
3.6.8 Diagramme de séquence "ajouter facture" . . . . . . . 38
3.6.9 Diagramme de séquence "Modifier la liste du matériel" 39

iv
 3.6.10 Diagramme de séquence "gérer les comptes" . . . . . . 41
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Conception 43
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Dictionnaire de donnée . . . . . . . . . . . . . . . . . . . . . 44
4.3 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Définition de diagramme de classe . . . . . . . . . . . 45
4.3.2 Présentation de diagramme de classe . . . . . . . . . . 45
4.4 Les règles de gestion . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Passage du modèle conceptuel au modèle relationnel . . . . . 47
4.5.1 Règle 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.2 Règle 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.3 Règle 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.4 Règle 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6 Modèle logique de données relationnel . . . . . . . . . . . . . 48
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Implémentation 49
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Environnement de développement . . . . . . . . . . . . . . . 49
5.3 Les interfaces de l’application . . . . . . . . . . . . . . . . . . 54
5.3.1 Authentification . . . . . . . . . . . . . . . . . . . . . . 54
5.3.2 Interface d’inscription . . . . . . . . . . . . . . . . . . 55
5.3.3 Interface MainPageAdmin . . . . . . . . . . . . . . . . 56
5.3.4 Interface gérer utilisateurs . . . . . . . . . . . . . . . . 57
5.3.5 Interface pour valider les items . . . . . . . . . . . . . 58
5.3.6 Interface Items déjà validés . . . . . . . . . . . . . . . 59
5.3.7 Interface Catégories . . . . . . . . . . . . . . . . . . . 60
5.3.8 Interface Liste des fournisseurs . . . . . . . . . . . . . . 61
5.3.9 Interface Liste des factures . . . . . . . . . . . . . . . . 62
5.3.10 L’interface MainPageEmployé . . . . . . . . . . . . . . 63
5.3.11 L’interface items de catégorie . . . . . . . . . . . . . . 64
5.3.12 L’interface demander un matériel . . . . . . . . . . . . 65
5.3.13 Interface Historique de demandes de matériel . . . . . 66
5.3.14 L’interface Profil . . . . . . . . . . . . . . . . . . . . . 67
5.3.15 L’interface track item . . . . . . . . . . . . . . . . . . . 68
5.3.16 Interface de Notifications . . . . . . . . . . . . . . . . . 69
5.3.17 Interface Ajouter une nouvelle catégorie . . . . . . . . 70
5.3.18 Interface Ajouter un nouveau item . . . . . . . . . . . 71

v
Conclusion Générale : 72

Bibliographie 74

vi
Table des figures

1.1 Organigramme de l’ENAGEO . . . . . . . . . . . . . . . . . . 5

2.1 Demande d’acquisition . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Diagramme de flux . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Diagramme des cas d’utilisations générale . . . . . . . . . . . 18

3.2 Diagramme de cas d’utilisation (responsable) . . . . . . . . . 19
3.3 Diagramme de cas d’utilisation (magasinier) . . . . . . . . . . 20
3.4 Diagramme cas d’utilisation (admin) . . . . . . . . . . . . . . 21
3.5 Diagramme de séquence Inscription . . . . . . . . . . . . . . . 34
3.6 Diagramme de séquence Authentification . . . . . . . . . . . . 35
3.7 Diagramme de séquence Consulter demandes matériel . . . . 36
3.8 Diagramme de séquence Effectuer une demande d’acquisition . 37
3.9 Diagramme de séquence Effectuer une commande . . . . . . . 38
3.10 Diagramme de séquence Ajouter une facture . . . . . . . . . . 39
3.11 Diagramme de séquence Modifier la liste du matériel . . . . . 40
3.12 Diagramme de séquence gérer les comptes . . . . . . . . . . . 41

4.1 Dictionnaire de données . . . . . . . . . . . . . . . . . . . . . 44

4.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Logo de Umlet . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Logo de Android Studio . . . . . . . . . . . . . . . . . . . . . 50
5.3 Logo de virsual studio code . . . . . . . . . . . . . . . . . . . 50
5.4 Logo de flutter . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5 Logo de Google emulator . . . . . . . . . . . . . . . . . . . . . 51
5.6 Logo de firebase . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.7 Logo de Google auth . . . . . . . . . . . . . . . . . . . . . . . 51
5.8 Logo de firestore . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.9 Logo de Github . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.10 Logo de Figma . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.11 Logo de SQlite . . . . . . . . . . . . . . . . . . . . . . . . . . 53

vii
5.12 Logo de Dart . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.13 Interface authentification . . . . . . . . . . . . . . . . . . . . . 54
5.14 Interface inscrire . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.15 MainPage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.16 Liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . 57
5.17 Items pour les validé . . . . . . . . . . . . . . . . . . . . . . . 58
5.18 Items validé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.19 Hangar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.20 Fournisseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.21 Factures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.22 MainPage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.23 Liste des items . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.24 Faire une demande matériel . . . . . . . . . . . . . . . . . . . 65
5.25 Historique de demande . . . . . . . . . . . . . . . . . . . . . . 66
5.26 Profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.27 Tracking item . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.28 Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.29 Ajouter catégorie . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.30 Ajouter item . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

viii
Liste des tableaux

2.1 Différentes rubriques . . . . . . . . . . . . . . . . . . . . . . . 10

Liste des abréviations

— SONATRACH : societe nationale de transport et de traitement des

hydrocarbures(algeria).
— AGIP : A grape in place.
— BP : British petroleum.
— JNOC : Japen national oil company.
— COHO : Communities organized for health options.
— SITEP : Societe italo-tunisienne d’exploitation pétrolière.
— BDD : Base de données.
— MVC : Modèle-Vue-Contrôleur.
— SGBD : Système de Gestion de Base de Données.
— UML : Unified Modeling Language.
— SI : Système informatique.
— ENAGEO : Entreprise National de Géophysique.
— NTIC : Nouvelles technologies de l’information et la communication.
— PFE : Projet de fin d’étude.
— XML : Extensible Markup Language.
— TVA : Taxe sur la valeur ajoutée .
— Numéro SIREN : Numéro Système d’identification du répertoire
des établissements.
— RCS : Registre de commerce et des sociétés .
— Prix HT : Prix hors taxe .
— prix TTC : Prix toutes taxes comprises .

x
Introduction générale

L’informatique est une nouvelle technologie qui entre en force dans les
faits et mentalités de tous les jours. Mais bien plus que d’autres "technolo-
gies nouvelles", elle impose peu à peu des changements de méthodes et des
changements de points de vue, qui constituent les éléments d’une nouvelle
culture. Cette dernière a pénétré le système éducatif depuis quelque temps
et fait partie des savoirs à transmettre, qu’ils soient optionnels ou non. Sui-
vant les dates de référence et le niveau de leurs applications, le statut de
ces savoirs a évolué, d’abord et principalement reliés à la programmation des
ordinateurs et aux méthodes algorithmiques de résolution de problèmes.

La gestion de stock est une activité incontournable qui touche vraiment

le cœur des préoccupations de tout gestionnaire ayant pour but de piloter
son entreprise vers la performance et l’efficacité. Cependant le volume im-
portant des informations liées à cette activité dans une entreprise complexe
beaucoup cette tâche, ce qui rend l’utilisation d’un système de gestion de
stock indispensable.

Dans ce projet, nous nous intéresserons au développement d’une applica-

tion mobile pour assurer une bonne gestion des stocks au profit de l’entreprise
nationale de géophysique (ENA-GEO).
Nous notons que le parc informatique n’est pas pris en considération dans ce
projet.

Afin de mener à bien ce travail, nous avons décomposé notre mémoire en

quatre chapitres :

— Le premier chapitre s’attache à mettre en avant notre projet en faisant

une présentation de l’ENAGEO, ainsi qu’une description du contexte
de notre projet.
— Le deuxième chapitre est consacré à l’étude de l’existant et décrit les
problèmes liés à la gestion des stocks.

xi
— Le troisième chapitre est dédié à la description des besoins du projet
en utilisant le langage UML ainsi que les différents diagrammes de
cas d’utilisation et de séquences.
— Le quatrième chapitre décrit la conception architecturale du projet. Il
présente le dictionnaire de données, le diagramme de classe, les règles
de gestion ainsi que le modèle relationnel.
— Dans le dernier chapitre, nous passons à la phase de réalisation où
nous décrivons les différents outils de développement utilisés ainsi que
la présentation de notre application. Nous clôturons le rapport avec
une conclusion générale et des perspectives.

1
Chapitre 1

Présentation de l’organisme
d’accueil

1.1 Introduction
Avant de se lancer dans le vif du sujet, il est essentiel de connaître le
terrain sur lequel nous allons travailler et les objectifs à atteindre. Nous
allons, alors, dans ce chapitre, présenter l’organisme d’accueil ainsi que notre
projet.

1.2 Présentation de l’ENAGEO

L’entreprise National de Géophysique est une SPA (Société Par Actions)
dont le siège est situé à Hassi Messaoud, Filiale 100 SONATRACH. En 2014,
son chiffre d’affaire s’élevait à 18.8 milliard de dinars, disposant d’un potentiel
humain de plus de 6500 employés (moyenne annuelle) et d’équipement de
dernière technologie. Présente sur la majeur partie du territoire national et
agissant pour le compte de clients aussi bien algériens que étrangers [7],
ENAGEO dispose de :
1. 16 chantiers pour la réalisation d’études sismiques en 2D ou 3D au
niveau du terrain.
2. Deux centres de calcul, à Ouled Fayet (Alger) et a Boumerdès, pour
le traitement et l’interprétation des données sismiques.
3. 10 Appareils de forage pouvant atteindre jusqu’à 600 m de profondeur.
4. Tout matériel nécessaire à la sismique de puits, à la topographie et à
la géophysique général (méthodes électriques, gravimétrie,...).

2
1.2.1 Historique de l’ENAGEO
L’ENAGEO a été créé en aout 1981(décret 81-172 du 01/08/1981) à par-
tir :
• D’ALGEO qui était une société mixte entre SONATRACH et Teledyne
(américaine) depuis le 01/03/1967.
• Du département géophysique et de service topographie de la Direction
des Travaux Pétroliers (DTP) de SONATRACH.
• Du service de traitement sismique de SONATRACH.
Sous tutelle du Ministère de l’énergie et des Mines jusqu’en février 1989
acquiert alors le statut d’entreprise autonome dont les actionnaires sont les
trois participations :
— Mines, Hydrocarbure et Hydraulique : 40%.
— Industries agro-alimentaires : 30%.
— Chimie, Pétrochimie et Pharmacie : 30%.
En 1998 après le remplacement des fonds de participation par des Holding,
SONATRACH rachète 51% du capital d’ENAGEO qui devient alors la pro-
priété :
— • Du Holding Sonatrach Service Para-pétroliers (SPP) : 51%.
— • De la société de Gestion des Participations Travaux Énergétiques
(SGP-TRAVEN). Depuis 2005, elle est une filiale SONATRACH à
100%. ENAGEO était actionnaire à 50% dans la société Libyo-Algérienne
de géophysique (ALAGCO) jusqu’au 31/12/2007. Cette participation
a évolué vers la création d’une représentation directe d’ENAGEO sur
le marché libyen par le rachat d’ALGCO. Parmi les principaux associés
de aux quels ENAGEO offert ses services sur le territoire national, ci-
tons AGIP, BP, JNOC. L’entreprise a également travaillé à l’étranger
pour le compte d’AGIP, COHO, SITEP .

1.2.2 Missions de l’ENAGEO

SONATRACH L’entreprise à des missions essentielles :
— La recherche des hydrocarbures par la sismique réflexion , dont elle
tire 91% de son chiffre d’affaires.
— Les études géotechniques, la topographie et les forages hydrauliques.
— Les études du sous-sol par des méthodes géophysiques dites poten-
tielles. L’acquisition, le traitement et l’interprétation sismique, phase
importante dans tout processus d’exploitation pour une meilleure connais-
sance des réservoirs qui fournit aux industries pétrolières et minières
des moyens de prospection et de suivi des gisements par cette tech-
nique.

3
1.2.3 Domaines d’activités de l’ENAGEO
L’entreprise ENAGEO travail sur plusieurs domaines d’activités qui sont :
• Topographie : Les études topographiques couvrent toutes les applications
de la topographie notamment :
— levé des profils et études pour l’ensemble des activités géophysique.
— Implantation des forages pétroliers et hydrauliques.
— Reconnaissance et choix de pistes d’accès aux puits.
— Étude de projets de pipe pétrolière.
— Études des routes et levée des terrains.
• Réflexion Sismique : ENAGEO possède une expérience de plusieurs dé-
cennies dans le domaine de la recherche des hydrocarbures par la réflexion
sismique, une des méthodes les plus utilisées en algerie et dans le monde, Une
maîtrise parfaite dans l’utilisation d’instruments tels que les laboratoires télé-
métrique a grand nombre de canaux pour la sismique 3D. ENAGEO dispose
de seize (16) équipes sismiques autonomes. Les matériels utilisés dans cette
étape sont : bulldozer, camion vibreur,camion labo, serveurs, camion câbliers
, câble d’enregistrement.
• Sismique de puits :L’introduction du profil sismique vertical, permet
d’étudier la réponse sismique des formations géologiques traversées par un
puits. Le traitement des données se fait sur site pour le contrôle de qualité.
Les matériaux utilises dans cette étape sont : bulldozer, camion vibreur, ca-
mion labo.
• Forage hydraulique :Le Forage hydraulique c’est l’aboutissement de
l’ensemble des études hydrogéologique ,ENAGEO est dotée d’appareils de
forage performantes, d’une unité d’essai entièrement équipée d’appareils so-
phistiquer, d’une unité de digraphie et de camps de vie équipée et autonome.
l’ensemble du parc est exploiter par un personnel spécialiser et jouissant
d’une longue expérience pour satisfaire les exigences de ses clients.
• Traitement et interprétation des données géophysique : l’entreprise
ENAGEO dispose de deux centres de calcul située a Ouled Fayet, wilaya d’Al-
ger et boumerdes, dotée d’équipement informatiques de pointe lui permettant
un traitement de données sismique de très haute qualité. des géophysiciens de
haut niveau sont a la disposition des clients pour résoudre tout les problèmes
technique dans le domaine du traitement. Ce département réalise aussi des
opérations de scanning et vectorisation des données sismiques.
les équipements utiliser sont : : Serveurs ultra puissant,Baie de stockage,Cartouches
de données, Ordinateurs.

4
1.2.4 L’organigramme de l’ENAGEO
Afin de déterminer les liens hiérarchique et fonctionnelle existants entre
les différents métiers de la société ENAGEO, la figure 1.2.4 représente l’or-
ganigramme général de l’ENAGEO.

Figure 1.1 – Organigramme de l’ENAGEO

1.3 Présentation du projet

1.3.1 Définition des gestions de stock d’une entreprise
La gestion de stock est une organisation et un contrôle de l’ensemble des
biens physique qu’une entreprise entrepose dans sont entrepôt, c’est a dire

5
organiser l’enregistrement l’approvisionnement et l’expédition des produit
[9]. La gestion de stock est une opération des plus importantes pour une
entreprise car elle impacte les autres activités de l’entreprise.

1.3.2 Contexte de notre travail

Nous envisageons de développer une application mobile pour faciliter la
gestion des stock de notre société hôte ; une application aussi fiable que ef-
ficace, qui permettrait à l’utilisateur de faire une demande de matériel, de
s’assurer que cette dernière parvienne aux instances responsables, et assure-
rai aussi une bonne gestion des biens physiques de la société en évitant les
erreurs.

1.4 Conclusion
Ce chapitre a servi à mettre notre projet dans son cadre, de présenter
notre organisme d’accueil, sa mission et son but. Il nous a aussi permis de
présenter notre projet de manière générale. Le chapitre suivant nous permet-
tra de faire l’étude de l’existant.

6
Chapitre 2

Étude de l’existant

2.1 Introduction
Chaque système qui vise la résolution d’un problème rencontré par l’hu-
main, passe par une étape primordiale pour mieux comprendre ce qui est
nécessaire et qu’on appelle : l’étude de l’existant.
Cette phase a pour but décrire le déroulement des processus et de définir les
frontières du domaine d’étude, ainsi que la communication entre les acteurs.
Cette étude apportera beaucoup d’informations et va faciliter l’élaboration
de l’analyse des besoins.
Nous avons décompose cette phase a 3 points principaux :
-Étude des postes de travail
-Étude des documents
-Le flux d’information.
Une fois ces étapes accomplies, nous pourrons critiquer le système de ges-
tion existant, et conclure en proposant des solutions pragmatique et faisable.

2.2 Étude des postes de travail :

2.2.1 Définition :
Le poste de travail est une cohérence d’organisation d’une personne ou
plus , a comme objectif l’exécution des taches donné.
- Pour recenser les postes existants , on doit faire une étude de poste de
travail , et ainsi pour décrire les missions de chacun.

7
2.2.2 Liste des postes de travail :
Les différents postes de la société en relation avec notre projet sont les
suivantes :

1. Administrateur.
2. Magasinier.
3. Fournisseur.
4. Responsable.
5. Employer (simple).

2.2.3 Description des postes de travail

Dans ce qui suit nous décrivons les taches de chaque poste de travail cité
précédemment.

Administrateur
— Gérer les systèmes informatique de l’entreprise (ajouter,modifier ou
supprimer des données du système ).
— Donner aux utilisateur l’accès au système.
— Vérifier les document comme les facture et les transmettre à la direc-
tion générale.
— Régler les pannes et les défaillances du système de l’entreprise.

Magasinier
— Être en charge de la réception de l’entreposage des marchandises dans
le hangar.
— Assurer les entrées et sorties de tous les produits de l’entreprise.
— Prendre en considération les mise à jour du stock.
— Le regroupement des produits destinés à une commande faite par le
responsable.
— Gérer tous les bons d’entrées et de sorties.
— Vérifier le chargement avant l’expédition et l’établissement de tous les
documents reliés à cette dernière.

Fournisseur (externe)
— Réceptionner des listes et bons de commandes faites par le magasinier.

8
 — Fournir les produits commandés par la société est assurer leurs livrai-
son à l’entrepôt .
— Générer la facture liée à la transaction d’achat .

Responsable
— Assurer le lien entre les employés, les propriétaires de cette entreprise
et les membres de l’équipe.
— Encourager l’esprit d’équipe et les relations interpersonnelles positives.
— Diriger la planification du travail quotidien pour s’assurer l avance-
ment vers l’objectif de l’entreprise.
— Vérifier les fiches de demande des employeurs et émettre une demande
d’acquisition de matériel auprès du magasinier.

Employer
Nous nous intéressons uniquement aux taches des employés en relation
avec notre étude et qui sont :

— Remplir la fiche de demande de matériel.

2.3 Étude documentaire

2.3.1 Définition
L’étude des documents est une partie très importante de l’existant, elle
permet de mettre en évidence toutes les informations qui circulent de fa-
çons simple et claire et de faire l’analyse de chaque document intervenant
dans notre projet. Pour chaque fiche décrite dans de notre étude nous avons
procédé à l’organisation des données qu’elle contient comme suit :
— La désignation.
— Le rôle.
— La destination.
— Le code.
— Le format.

9
 code désignation
A Alphabétique
N Numérique
AN Alphanumérique
D Date
S Signature

Table 2.1 – Différentes rubriques

2.3.2 Liste des document

La listes des documents en relation avec l’étude que nous menons sont :
— La demande d’acquisitions.
— Le bon de commande.
— La facture des achats

2.3.3 Description des document

La demande d’acquisition
La demande d’acquisition est un document interne qui est remplie par les
employés de la société en besoin de matériel. Elle peut même être remplie
par le directeur, le document en question est en suite signé et cacheté par
le directeur de la l’entreprise. Nous illustrons ce type de documents par un
exemple de demande d’acquisition dans la figure ci-dessus 2.1

10
 Figure 2.1 – Demande d’acquisition

Le bon de commande
Le bon de commande est un document reprenant les éléments d’une com-
mande donnant lieu à une vente entre un vendeur et un acheteur. Ce do-
cument a, donc, une valeur d’engagement dès qu’il est signé par les deux
parties. En effet, le vendeur s’engage à fournir la commande et l’acheteur

11
s’engage à la régler, dans l’étude que nous menons l’acheteur n’est autre que
le magasinier et le vendeur est le fournisseur.
Le bon de commande doit contenir les éléments suivants pour être valide :
— Identité de l’émetteur (adresse, numéro de TVA, raison so-
ciale, capital social, numéro SIREN et RCS ) .
— Identité du destinataire (adresse, raison sociale, numéro RCS
et SIREN) .
— Détails des produits/services et quantité .
— Prix HT et prix TTC .
— Montant de la TVA .
— Date et numéro de la commande .
— Date de livraison .
— Mode de paiement ( facultatif ) .
— Conditions de livraison .
— Délai et modalités du droit de rétractation .
Pour des raisons administratives, nous ne pouvons pas illustrer avec une
figure un exemple d’un bon de commande de la société.

La facture des achats :

La facture d’achat est un document à la fois, juridique, commercial, comp-
table et fiscal, qui prouve un achat ou une vente de services réalisés ou de
marchandises. La facture est générée par le fournisseur, elle est vérifiée par le
magasinier puis est réglée au niveau du comptable de la société mère (société
principale) .
Elle doit contenir la mention de produits, le prix ainsi que les éléments sui-
vants :
— Identité de l’émetteur (adresse, numéro de TVA, raison so-
ciale, capital social, numéro SIREN et RCS ) .
— Identité du destinataire (adresse, raison sociale, numéro RCS
et SIREN) .
— Prix unitaire Hors Taxe (HT) du produit ou service vendu
.(pour chaque prodit)
— Montant total à payer HT et TTC .
— Taux de TVA
Pour des raisons administratives, nous ne pouvons pas illustrer avec une
figure un exemple d’une facture d’achat de la société.

12
2.4 Flux d’information
2.4.1 Définition
Le flux d’information est le transfère d’information entre deux acteur du
système d’information, généralement représenté par des flèches, un flux part
d’un acteur source pour aboutir à un de finalité [10].

2.4.2 Diagramme de flux de données

La figure2.4.2 représente le diagramme de flux du système de l’entreprise
d’accueil concernant la gestion des stocks.

Figure 2.2 – Diagramme de flux

Circulation des information

Les différentes tâches de gestion de stock de l’entreprise s’effectuent ma-
nuellement comme suite :
1 La demande d’acquisition de matériel peut être remplie par un employer
de l’établissement ou par le chef de l’entreprise, elle est signée et cachetée
par se dernier puis transmise vers le magasinier.
2 Le magasinier envoi un document avec le matériel figurant dans la demande
et confirme l’émission du colis.
3 Le responsable transmet le matériel demandé par l’employer avec un accusé

13
de réception.
4 En cas de non disponibilité ou de rupture de stock du matériel suite a la
demande d’acquisition (1) le magasinier rédige une commande et la transmet
au fournisseur.
5 Le fournisseur transmet le matériel figurant dans la commande (4) avec la
facture de vente du matériel transmit.
6 Le magasinier vérifie le matériel envoyé par le fournisseur ainsi que la fac-
ture (5), puis la transmet à l’administrateur .

2.5 Problématique
Après l’étude de sujet la majorité des problèmes constatés lors de la vi-
sualisations de l’utilisation du gestionnaire (existant) mis en service :
1. Logiciel mono-poste : la gestion se fait sur une seule machine.
2. Données non-sécurisées
3. Stock non-inventorié : tel que les pièces de rechange des voitures,
les meubles, les produits alimentaires,les produits électroniques.
4. Erreurs de gestion : le logiciel provoque des erreurs alors qu’il est
sensé en résoudre
5. Gestionnaire lent : le logiciel prend beaucoup de temps pour des
taches sensé être rapide à faire .
6. Gestion complexe ce qui rend le travaille difficile a gérer .
7. Prise en compte partielle des demandes.

2.6 Objectifs
L’objectif de notre approche est de satisfaire les contraintes suivantes :
1. Une sécurité accrue et efficace .
2. Enregistrement des produit achetées est bien définir leur
emplacement.
3. Suivi en temps réel des évolutions par exemple : les évolutions
des demandes, évolution des produits expédier .
4. Anticipation des besoins futures.
5. Accès simple au service.
6. Gain du temps.
7. Interaction rapide aux probable incidents.
8. Réalisation des taches sans erreurs.

14
2.7 Conclusion
Tout d’abord ce chapitre nous aura permis de bien comprendre le che-
minement des informations dans la société, de définir les postes de travail
ainsi que tout les documents liés au processus auquel nous nous intéressons.
Il nous a aussi permis de constater les défaillances au niveau de la gestion
du stock au niveau de la société. Ces défaillances nécessitent la mise en place
d’une solution de gestion de stock qui doit être en mesure de satisfaire les
objectifs citées.
Le prochaine chapitre sera consacre a l’analyse des besoins.‘

15
Chapitre 3

Analyse de besoins

3.1 Introduction
Au démarrage d’un projet, le client et les futurs utilisateurs finaux ont une
idée brute de ce qu’ils souhaitent qui peut mêler des attentes plus ou moins
précises avec des idées de conception. Les besoins analysés décrivent ce que
l’application doit faire dans l’environnement qui est le sien, les principaux
services qu’elle doit rendre (besoins fonctionnels), les exigences qualitatives
souhaitées et les contraintes sous lesquelles l’application doit s’exécuter et
être développée [11].
Ce chapitre nous permettra donc de définir les principaux besoin de notre
application, le diagramme de cas d’utilisation ainsi que le que les diagrammes
de séquence qui schématisent les actions de notre système par rapport dans
le temps.

3.2 Présentation d’UML

L’UML est l’acronyme de ’Unified Modeling Language’, est un langage
graphique conçu pour représenter, spécifier, construire et documenter les arte-
facts d’un système à dominante logicielle. Il permet de faire une modélisation
d’une manière claire et précise la structure et le comportement d’un système
indépendamment de toute autre méthode ou langage de programmation.
UML[1] est un langage standard de modélisation objet qui peut se substituer
aux notations d’autres méthodes objets. Ce n’est pas une méthode .

16
3.3 Spécification des besoins
3.3.1 Les besoins fonctionnels
Cette partie présente les fonctionnalités du système. Ce sont les besoins
spécifiant un comportement d’entrée -sortie du système illustrée dans les
diagrammes de cas d’utilisation. Les besoins fonctionnels de notre système
se résument comme suit :
— La gestion des comptes des responsables
— La gestion des fournisseurs
— La gestion des factures
— La gestion du matérielle
— Le gestion des demandes d’acquisition
— Gestion des consultation des demandes

3.3.2 Les besoins non fonctionnels

Ce sont des exigences qui ne concernent pas spécifiquement le comporte-
ment du système mais plutôt identifient des contraintes internes et externes
du système. Les principaux besoins non fonctionnels de notre système ce
résument dans les points suivants :
— Le code : doit être clair et commenté pour permettre les futures évo-
lutions et maintenances.
— L’ergonomie : l’application offre une interface convenable et facile à
utiliser. De plus, elle doit respecter le code couleurs de l’entreprise.
— La fiabilité : les données fournis par l’application doivent être fiable.
— La sécurité : l’application doit respecter la confidentialité des données.
— L’integrité : l’application doit garantir l’intégrité et la cohérence des
données à chaque mise à jour et à chaque insertion.

3.4 Diagramme des cas d’utilisation

3.4.1 Définition
Le Diagramme de cas d’utilisation exprime l’organisation de l’utilisation
du système par ses acteurs ,il Décrit la fonctionnalité que le système délivre
à ses utilisateurs (humains ou autre système) et les liens qui peuvent exister
entre eux (include, uses ou extends). [8]

17
3.4.2 Diagramme de cas d’utilisation Général
La figure ci-dessous représente le diagramme des cas d’utilisations géné-
rale de notre système 3.4.2

Figure 3.1 – Diagramme des cas d’utilisations générale

18
3.4.3 Diagramme de cas d’utilisation détailler
Diagramme de cas d’utilisation (responsable)
Le diagramme de cas d’utilisation représentent le responsable est dans la
figure 3.4.3

Figure 3.2 – Diagramme de cas d’utilisation (responsable)

Diagramme de cas d’utilisation (magasinier)

Le diagramme de cas d’utilisation représentent le magasinier est dans la
figure 3.4.3

19
 Figure 3.3 – Diagramme de cas d’utilisation (magasinier)

Diagramme de cas d’utilisation (admin)

Le diagramme de cas d’utilisation représentent l’admin est dans la figure
3.4.3

20
 Figure 3.4 – Diagramme cas d’utilisation (admin)

3.5 Descriptions textuelles

Dans cette partie nous décrivons en détails les cas d’utilisations présentés
dans la figure 3.4.2

3.5.1 Inscription
Sommaire d’inscription :
— Titre : S’inscrire .
— But : Permet de crée un compte.
— Acteurs : Visiteur (nouveaux utilisateurs).

Pré-Conditions :
— L’utilisateur ne possède pas un compte.

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :s’inscrire :
— Le visiteur accède a l’application .

21
 — Le visiteur choisit d’ouvrir un nouveau compte .
— Le système affiche le formulaire d’inscription .
— Le visiteur rempli le formulaire .
— Le système vérifie que le formulaire a était rempli correctement
— Le système affiche un message que le compte a était créer et en attente
de validation .

Enchaînement alternatif :
— Si les champs ne sont pas remplis ou que la syntaxe des champs n’est
pas respecter le système affiche un message d’erreur puis réinitialise
la page du formulaire .
— Si il existe déjà un compte avec le même nom d’utilisateur le système
affiche un message qui demande a l’utilisateur d’entre un nouveau nom
d’utilisateur et réinitialise les champs du formulaire .

Poste-Condition :
Création d’un nouveau compte .

3.5.2 Authentification
Sommaire d’authentification :
— Titre : authentification .
— But : permet d’accéder a son compte .
— Acteurs : Responsable,magasinier,admin .

Pré-Conditions :
— L’utilisateur doit être en possession d’un compte .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :s’inscrire :
— L’utilisateur accède a l’application et choisi de se connecter (s’authen-
tifier).
— Le système affiche le formulaire d’authentification .
— L’utilisateur rempli les champs du formulaire puis choisi de soumettre
les informations rempliés .
— La BDD confirme la correspondance correcte entre les donnes remplis
par L’utilisateur et les donnes d’un compte existent.

22
 — Le système affiche la page d’accueil attribuer .

Enchaînement alternatif :
— Si la BDD ne trouve pas de correspondance entre les donnes remplis
par l’utilisateur et les donnes d’aucun compte le système affiche un
message d’erreur.

Poste-Condition :
Le système affiche la page d’accueil .

3.5.3 Consulter demande(s) matériel

Sommaire de consultation des demandes matériel :
— Titre : Consulter demande(s) matériel .
— But : permet de consulter les demandes matériel que l’utilisateur a
effectuer .
— Acteurs : Responsable .

Pré-Conditions :
— L’utilisateur doit être authentifier .
— L’utilisateur doit au moins avoir fait une demande .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :consulter demande(s) :
— L’utilisateur accède a sa page d’accueil puis choisi de consulter les
précédente demande matériel qu’il a effectuer .
— Le système dirige l’utilisateur vers une page qui contient la liste des
demandes faites par l’utilisateur .
— L’utilisateur consulte les demande qu’il a fait .

Enchaînement alternatif :
—

Poste-Condition :
L’utilisateur consulte ses anciennes demandes .

23
3.5.4 Consulter la liste matériel
Sommaire de Consultation de la liste matériel :
— Titre : Consulter la liste matériel .
— But : s’informer du matériel disponible dans l’entrepôt .
— Acteurs : Responsable, Magasinier, Admin .

Pré-Conditions :
— L’utilisateur doit s’autentifier a son compte .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement Consulter la liste matériel :
— Les étapes de la description textuelle de se cas d’utilisation sont les
mêmes que celle du cas présenter a savoir Consulter demandes
matériel .

Poste-Condition :
Consultation du matériel disponible .

3.5.5 Effectuer demande d’acquisition

Sommaire d’effectuer une demande d’acquisition :
— Titre : Effectuer demande d’acquisition .
— But : permet de formuler une demande pour l’acquisition de matériel
.
— Acteurs : Responsable, Admin .

Pré-Conditions :
— L’utilisateur doit s’être authentifier .
— Le matériel demander doit figurer dans la liste matériel .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :Effectuer demande d’acquisition :
— L’utilisateur accède a sa page d’accueil et choisit de consulter la liste
du matériel .
— Le système le dirige vers la page de la liste .
— L’utilisateur choisit de faire une demande de matériel .

24
 — Le système permet a l’utilisateur de sélectionner le matériel choisi .
— L’utilisateur sélection un produit .
— A chaque sélection le système affiche un formulaire de demande lie au
produit choisi .
— L’utilisateur rempli le formulaire de la demande puis confirme .
— Le système vérifie que les champs sont rempli correctement sauve-
garde les information de la demande puis enlève le formulaire d’où
l’utilisateur peut choisir d’autre produit .
— L’utilisateur choisit de finir sa demande .
— Le système affiche la liste des produits sélectionner par l’utilisateur et
demande a l’utilisateur de confirmer sa demande .
— L’utilisateur confirme sa demande .
— Le système affiche un message de succès lance la demande et la sau-
vegarde dans la listes des demandes effectuer .

Enchaînement alternatif :
— Si les champs du formulaire ne sont pas bien rempli le système affiche
un message d’erreur et réinitialise les champs du formulaire .
— Si l’utilisateur demande un nombre supérieur a celui indiquer dans un
produit le système affiche un message d’erreur et réinitialise le champs
.
— Si l’utilisateur annule la demande avant que le système ne la lance
le système affiche un message d’échec puis dirige l’utilisateur vers la
page d’accueil .

Poste-Condition :
Effectuer une demande d’acquisition de matériel .

3.5.6 Voir la liste des demandes

Sommaire de visualisation des demandes :
— Titre : Voir la liste des demandes .
— But : permet de consulter les demandes reçus pour pouvoir les traiter
.
— Acteurs : Magasinier .

Pré-Conditions :
— L’utilisateur doit s’être authentifier .

25
 — Il doit y avoir au moins une demande non traiter .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :Voir la liste des demandes :
— Les étapes de la description textuelle de se cas d’utilisation sont les
mêmes que celle du cas présenter a savoir Consulter demande ma-
tériel .

Poste-Condition :
Voir la liste des demandes reçus .

3.5.7 Faire une commande

Sommaire d’effectuer une demande :
— Titre : Faire une commande .
— But : permet de formuler une commande pour remplir le stock ou
acquérir un nouveau matériel .
— Acteurs : magasinier .

Pré-Conditions :
— L’utilisateur dois s’être authentifier .
— Le stock doit être épuiser ou besoin d’un nouveau produit .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :Faire une commande :
— L’utilisateur accède a sa page d’accueil puis choisi de faire une com-
mande .
— Le système dirige l’utilisateur vers un formulaire ou il noter les pro-
duits a commander ainsi que leurs caractéristique .
— L’utilisateur rempli le formulaire puis confirme
— Système vérifie que le formulaire ne contient pas de faute puis sauve-
garde les informations puis dirige l’utilisateur vers la liste des fournis-
seurs.
— L’utilisateur choisi un fournisseur .
— Le système affiche les coordonnes du fournisseur .
— L’utilisateur contacte le fournisseur grâce a ses coordonner puis choisit
de finir la commande .

26
 — Le système affiche un message de succès puis dirige l’utilisateur vers
la page d’accueil.

Enchaînement alternatif :
— Si les champs du formulaire continents des fautes (par exemple un
champs de nombre contient des caractères) le système affiche un mes-
sage d’erreur puis réinitialise les champs du formulaire
— Si l’utilisateur annule la commande avant que cette dernière ne soit
achever le système affiche un message d’échec puis dirige l’utilisateur
vers la page d’accueil

Poste-Condition :
Effectuer une commande au profil de l’entrepôt de la société mère .

3.5.8 Ajouter une facture

Sommaire d’ajout d’une une facture :
— Titre : Ajouter une facture .
— But : permet la confirmation de la réception de la commande a bon
compte et permettre aux instance concerner de gérer la facture .
— Acteurs : Magasinier .

Pré-Conditions :
— L’utilisateur doit s’être authentifier .
— La facture doit être vérifier (ne contient aucune erreur ou produit
manquant) .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :Ajouter une facture :
— L’utilisateur accède a la page d’accueil puis choisi d’ajouter une fac-
ture .
— Le système dirige l’utilisateur vers le formulaire d’ajout d’une facture.
— L’utilisateur rempli le formulaire puis confirme a la fin la soumission
des informations lies a la facture .
— Le système vérifie que le formulaire ne contient pas d’erreur puis sau-
vegarde les information soumises et affiche un message que sauvegarde
réussi en attente de validation .

27
Enchaînement alternatif :
— Si le formulaire contient une ou plusieurs erreurs le système affiche un
message d’erreur et réinitialise les champs du formulaire .
— Si l’utilisateur annule la tache avant qu’elle ne soit achever le sys-
tème affiche un message d’échec puis dirige l’utilisateur vers la page
d’accueil .

Poste-Condition :
Ajout d’une facture .

3.5.9 Ajouter un fournisseur

Sommaire d’ajout un fournisseur :
— Titre : Ajouter un fournisseur .
— But : ajouter un nouveau fournisseur .
— Acteurs : Magasinier .

Pré-Conditions :
— L’utilisateur doit s’être authentifier .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :Ajouter un fournisseur :
— Les étapes de la description textuelle de se cas d’utilisation sont les
mêmes que celle du cas présenter a savoir Ajouter une facture .

Poste-Condition :
Ajout d’un fournisseur .

3.5.10 Modifier la liste du matériel

Sommaire Modification de la liste du matériel :
— Titre :Modifier la liste du matériel . o
— But :mettre a jour la liste du matériel
— Acteurs : Magasinier, Admin

28
Pré-Conditions :
— L’utilisateur doit s’être authentifier .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :Modifier la liste du matériel :
— L’utilisateur accède a la page d’accueil puis choisit de modifier la liste
du matériel .
— Le système dirige l’utilisateur vers la liste du matériel avec les options
d’ajouter de modifier et de supprimer un produit .
— En choisissant d’ajouter un produit le système affiche le formulaire
d’ajout de produit
— L’utilisateur rempli le formulaire et confirme l’ajout du produit .
— Le système vérifie le formulaire puis ajout le produit tout en affichant
un message de succès .
— En choisissant de modifier un produit le système dirige l’utilisateur
vers le formulaire qui contient les informations du matériel en question
.
— L’utilisateur modifie les informations du matériel puis confirme les
modifications .
— Le système vérifie que les modification ne continents pas d’erreur puis
modifie le produit et affiche un message de succès
— L’utilisateur choisit de supprimer un produit .
— Le système demande a l’utilisateur de confirmer la suppression du
matériel .
— L’utilisateur confirme l’action .
— Le système supprime le produit en affichant le message produit sup-
primer.

Enchaînement alternatif :
— Si les champs du formulaire d’ajout contiennent des erreurs le système
affiche un message d’erreur et réinitialise le formulaire
— Si les modifications des informations d’un produit contiennent des
erreurs le système affiche un message d’erreur puis demande a l’utili-
sateur de corriger les erreurs .
— Si l’utilisateur décide d’annuler une tache avant qu’elle ne soit achever
le système affiche un message d’échec et dirige l’utilisateur vers la page
d’accueil .

29
Poste-Condition :
Mise a jour la liste du matériel .

3.5.11 Gérer les comptes

Sommaire de gestion des comptes :
— Titre : Gérer les comptes .
— But : permet la bonne distribution des accès aux utilisateurs .
— Acteurs : Admin .

Pré-Conditions
— L’utilisateur doit être authentifier en tant que Admin .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :Gérer les comptes :
— L’utilisateur accède a sa page d’accueil puis choisi de gérer les compte.
— Le système le dirige vers une page contenant de catégories qui sont les
comptes actifs et les compte en attentes .
— Si l’utilisateur choisi la catégorie des comptes actifs .
— Le système dirige l’utilisateur vers la liste des compte en activité .
— L’utilisateur peut choisir un compte de la liste.
— Le système affiche les informations du compte.
— L’utilisateur peut choisir de supprimer le compte
— Le système demande a l’utilisateur de confirmer la suppression
— L’utilisateur confirme la suppression
— Le système supprime le compte et dirige l’utilisateur vers la liste des
comptes valide .
— Si l’utilisateur choisit d’accéder a la catégorie des compte en attente.
— Le système dirige l’utilisateur vers la liste des compte en attente .
— L’utilisateur choisi un compte .
— Le système affiche les informations lies au compte .
— L’utilisateur peut choisir de valider le compte .
— Le système demande a l’utilisateur de confirmer la validation .
— L’utilisateur confirme de valider le compte .
— Le système valide le compte, le place dans la catégorie des compte
valide puis dirige l’utilisateur vers la liste des compte en attente .
— En choisissant de supprimer un compte le même cas de la suppression
de compte valide se répète .

30
Enchaînement alternatif :
— Si l’utilisateur décide d’annuler la validation d’un compte avant que
la tache soit accomplie le système marque l’échec de l’action par un
message puis dirige l’utilisateur vers la liste des comptes .
— Si l’utilisateur décide d’annuler la suppression d’un compte avant que
la tache soit accomplie le système marque l’échec de l’action par un
message puis dirige l’utilisateur vers la liste des comptes .

Poste-Condition :
Gestion des comptes des utilisateurs .

3.5.12 Gérer fournisseurs

Sommaire de gestion des fournisseurs :
— Titre : Gérer fournisseurs .
— But : mettre a jours la liste des fournisseurs .
— Acteurs : Admin .

Pré-Conditions :
— L’utilisateur doit s’être authentifier .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :Gérer fournisseurs :
— Les étapes de la description textuelle de se cas d’utilisation sont les
mêmes que celle du cas présenter a savoir Gérer les comptes .

Poste-Condition :
Liste des fournisseurs mise a jour .

3.5.13 Gérer factures

Sommaire de gestion des factures :
— Titre : Gérer factures .
— But : mettre a jours la liste des factures .
— Acteurs : Admin .

31
Pré-Conditions :
— L’utilisateur doit s’être authentifier .

Description de l’enchaînement (Enchaînement nominale) :

Enchaînement :Gérer factures :
— Les étapes de la description textuelle de se cas d’utilisation sont les
mêmes que celle du cas présenter a savoir Gérer les comptes . la
seule différence est que si l’admin supprime une facture non valide il
contacte le Magasinier et lui indique de la re-ajouter.

Poste-Condition :
Les factures sont gérer .

32
3.6 Diagrammes De Séquences
3.6.1 Définition
Un diagramme de séquences est un diagramme d’interaction qui expose
en détail la façon dont les opérations sont effectuées : quels messages sont
envoyés et quand ils le sont. Les diagrammes de séquences sont organisés
en fonction du temps qui s’écoule au fur et à mesure que nous parcourons
la page. Les objets impliqués dans l’opération sont répertoriés de gauche à
droite en fonction du moment où ils prennent part dans la séquence [12].

3.6.2 Composition d’un diagramme de séquences

Ce type des diagrammes est composé par les éléments suivants :
— Les lignes de vie : Une ligne verticale qui représente la séquence
des événements, produite par un participant, pendant une interaction,
alors que le temps progresse en bas de ligne,Ce participant peut être
une instance d’une classe, un composant ou un acteur.
— Les messages : Deux types de messages dans le diagramme de sé-
quences, le premier est dit message synchrone utilisé pour représenter
des appels de fonction ordinaires dans un programme, le deuxième est
appelé message asynchrone, étant utilisé pour représenter la communi-
cation entre des threads distincts ou la création d’un nouveau thread.
Les occurrences d’exécution : Représente la période d’exécution d’une
opération.
— Les commentaires : Un commentaire peut être joint à tout point
sur une ligne de vie.
— Les itérations : Représente un message de réponse suite à une ques-
tion de vérification.

3.6.3 Diagramme de séquence "d’inscription"

33
 Figure 3.5 – Diagramme de séquence Inscription

3.6.4 Diagramme de séquence"d’authentification"

Remarque : Diagramme de séquence ”authentification” couvre les 3 ac-
teurs qui sont : l’admin, magasinier et responsable .

34
 Figure 3.6 – Diagramme de séquence Authentification

3.6.5 Diagramme de séquence "Consulter demande ma-

tériel"
Remarque :
Les diagramme de séquence "Consulter liste matériel" , "Voir la
liste des demandes" sont semblables à celui présenté dans le diagramme
suivant

35
 Figure 3.7 – Diagramme de séquence Consulter demandes matériel

3.6.6 Diagramme de séquence "Effectuer une demande

d’acquisition"

36
Figure 3.8 – Diagramme de séquence Effectuer une demande d’acquisition

3.6.7 Diagramme de séquence "Faire une commande"

37
 Figure 3.9 – Diagramme de séquence Effectuer une commande

3.6.8 Diagramme de séquence "ajouter facture"

Remarque :
Le diagramme de séquence ajouter fournisseur est semblable a celui
présenter dans le diagramme suivant

38
 Figure 3.10 – Diagramme de séquence Ajouter une facture

3.6.9 Diagramme de séquence "Modifier la liste du ma-

tériel"

39
Figure 3.11 – Diagramme de séquence Modifier la liste du matériel

40
3.6.10 Diagramme de séquence "gérer les comptes"
Remarque :
Les diagramme de séquence gérer fournisseur,gérer factures est sem-
blable a celui présenter dans le diagramme suivant

Figure 3.12 – Diagramme de séquence gérer les comptes

41
3.7 Conclusion
Le troisième chapitre, «Analyse des besoins» nous a permis d’illustrer le
lancement du projet et cerner les besoins de notre application mobile. Ceci en
déterminant les besoins fonctionnels et non fonctionnels, puis en identifiant
des acteurs ainsi que les différents cas d’utilisations, leurs descriptions et en
fin les diagrammes de séquences.

42
Chapitre 4

Conception

4.1 Introduction
Dans ce chapitre, nous allons décrire la conception du projet.le diction-
naire de données, le diagramme de classe, les règles de gestion ainsi que le
modèle relationnel.

43
4.2 Dictionnaire de donnée
Le dictionnaire de données est un tableau qui regroupe toutes les données
de base,c’est la base pour réalisation du diagramme de classe.

Figure 4.1 – Dictionnaire de données

44
4.3 Diagramme de classe
4.3.1 Définition de diagramme de classe
Le diagramme de classes est un schéma utilisé en génie logiciel pour pré-
senter les classes et les interfaces des systèmes ainsi que leurs relations. Ce
diagramme fait partie de la partie statique d’UML, ne s’intéressant pas aux
aspects temporels et dynamiques.

4.3.2 Présentation de diagramme de classe

Figure 4.2 – Diagramme de classe

45
4.4 Les règles de gestion
Le diagramme de classe général présenté dans la figure se base sur les
règles de gestion suivantes :
— Le Responsable et Magasinier sont des User.
— L’Admin peut être Magasinier.
— L’Admin peut gérer plusieurs comptes et plusieurs fournisseurs.
— Un Responsable peut faire plusieurs demandes. Une demande ne peut
être faite que par un seul Responsable.
— Un Responsable peut consulter plusieurs Matériel. Un matériel peut
être consultée par plusieurs responsables.
— Un Responsable peut consulter plusieurs demandes. Une demande
peut être consultée par plusieurs responsables.
— Un Magasinier peut gérer un seul Hangar. Un Hangar peut être géré
par plusieurs magasiniers.
— Un magasinier peut gérer plusieurs catégories. Une catégorie peut être
gérée par un seul magasinier.
— Une catégorie comprend plusieurs Matériels. Un matériel fait partie
d’une seule catégorie.
— Un magasinier peut faire plusieurs commandes. Une commande est
faite par un seul magasinier.
— Un Magasinier peut valider plusieurs demandes.Une demande peut
être validée par un seul Magasinier.
— Un Magasinier peut ajouter plusieurs fournisseurs. Un fournisseur
peut être ajouter par un seul Magasinier.
— Une commande concerne une demande validé par le magasinier et
envoyée a un fournisseur.

46
4.5 Passage du modèle conceptuel au modèle
relationnel
Le modèle logique de données relationnel est basé sur une organisation des
données sous forme de tables (c’est une manière de modéliser les informations
contenues dans la base de données). Pour passer du diagramme de classes
UML au modèle relationnel, il existe un ensemble de règles à respecter :

4.5.1 Règle 1
Traduction des classes :
— Une classe devient une table.
— Les attributs de la classe deviennent les attributs de la table.
— L’identifiant devient une clé primaire.

4.5.2 Règle 2
Traduction d’une relation d’héritage :
— Créer une table pour chaque sous type.
— Chaque table se fait en migrant la clé de la classe mère vers les classes
filles et ajouter des attributs génériques et d’attributs spécifiques.

4.5.3 Règle 3
Traduction d’une association 1-N :
— Incluant la clé étrangère dans la relation dont la multiplicité maximale
est la clé primaire de l’autre relation.

4.5.4 Règle 4
Traduction d’une association M-N :
— Créer une nouvelle relation dans laquelle les clés primaires des rela-
tions participantes sont les clés étrangères de la nouvelle relation.
— Les attributs de la classe d’association sont insérés dans cette nouvelle
relation si nécessaire.

47
 4.6 Modèle logique de données relationnel
— Admin (idUser)
— Responsable (idUser)
— Magasinier (idUser,#idHangar)
— Materiel (idMat,nomMat,quantiteMat,colorMat,dateAJMAT, #idResponsable,#idC)
— Catégorie (idC ,nomC)
— Demande (idD ,nomMAT ,quantitéNéc,colorMat,dateD,isvalide,
#idResponsable,#idMat)
— Consulter (#idC,#idUser)
— Commande (idCO,dateCO,#idMagazinier)
— Fournisseur (idF,NomF,PhnF,emailF,Facture)
— Hangar(idH,localisationH)

Remarque :
Les premiers attributs de chaque classe sont des clés primaires, et les
clés étrangères commencent par un #.

4.7 Conclusion
Dans ce chapitre nous avons présenté la modélisation de notre application
en utilisant Le diagramme de classe, ce qui permettra dans le chapitre suivant
d’aborder la phase d’implémentation.

48
Chapitre 5

Implémentation

5.1 Introduction
Dans ce chapitre, nous allons parlé des différents moyens logiciels que nous
avons utilisés pour compléter l’application, et nous avons également détaillé
des captures d’écran pour expliquer les fonctionnalités de l’application étape
par étape.

5.2 Environnement de développement

Outil de modélisation UML
umlet

Figure 5.1 – Logo de Umlet

UMLET est un outil UML gratuit et open source avec une interface uti-
lisateur simple : dessinez rapidement des diagrammes UML, créez des dia-
grammes de séquence et d’activité à partir de texte brut, exportez des dia-
grammes vers eps, pdf, jpg, svg et presse-papiers, partagez des diagrammes
à l’aide d’Eclipse. [6]

49
Outil de développement
Android studio

Figure 5.2 – Logo de Android Studio

Android Studio est une plate-forme d’écriture d’applications mobile an-

droid qui permet aux développeurs d’écrire facilement du code source.

Visual studio code

Figure 5.3 – Logo de virsual studio code

Visual Studio Code est un éditeur de code open-source développé par

Microsoft supportant un très grand nombre de langages grâce à des exten-
sions. Il supporte l’autocomplétion, la coloration syntaxique, le débogage, et
les commandes git. [5]

Flutter

Figure 5.4 – Logo de flutter

Flutter est un framework de développement d’applications multiplate-

forme, conçu par Google, dont la première version a été publiée sous forme
de projet open source à la fin de l’année 2018.

50
Google chrome emulator

Figure 5.5 – Logo de Google emulator

Chrome est un navigateur web développé par Google basé sur le projet
open source Chromium. Google Chrome lui-même n’est pas open-source, les
binaires officiels sont eux soumis à un contrat de licence utilisateur final
(CLUF). [4]

Firebase

Figure 5.6 – Logo de firebase

Firebase est une plateforme de développement d’applications web et mo-

biles soutenue par Google, pour aider les développeurs à offrir des expériences
d’applications plus riches.[2]

google auth

Figure 5.7 – Logo de Google auth

Google Authenticator est une application de sécurité mobile basée sur

l’authentification à deux facteurs (2FA) qui permet de vérifier l’identité des
utilisateurs avant de leur accorder l’accès aux sites Web et aux services.[3]

51
Firestore

Figure 5.8 – Logo de firestore

Firestore est une base de données entièrement gérée et native au cloud

qui facilite le stockage.

Github

Figure 5.9 – Logo de Github

Github est une entreprise de développement et services logiciels sise aux

États-Unis. Github développe notamment la plateforme Github.

Figma

Figure 5.10 – Logo de Figma

Figma est une application web d’édition graphique qui permet le partage
en temps réel sur le même fichier.

52
Langages de développement
NOSQL(Not only Sql)

Figure 5.11 – Logo de SQlite

NoSQL est une approche de la conception de bases de données qui peut

s’adapter à une grande variété de modèles de données.

Dart

Figure 5.12 – Logo de Dart

Dart est un langage de programmation optimisé pour les applications sur

plusieurs plateformes. Il est développé par Google et est utilisé pour créer
des applications mobiles, de bureau, de serveur et web. Dart est un langage
orienté objet à ramasse-miettes avec une syntaxe de type C++.

53
5.3 Les interfaces de l’application
5.3.1 Authentification
C’est l’interface qui permet aux utilisateurs de se connecter a l’applica-
tion,en saisissant leur nom et le mot de passe.
Les champs d’entrée sont sécurisés a l’aide d’instructions SQL préparées et
le mot de passe est haché puis comparé a son équivalent dans la base de
données pour vérifier et authentifier l’utilisateur concerné.

Figure 5.13 – Interface authentification

54
5.3.2 Interface d’inscription
Cette interface a été spécialement conçue pour les utilisateur qui utilisent
l’application pour la première fois,en saisissant leur nom et e-mail et mot de
passe.

Figure 5.14 – Interface inscrire

55
5.3.3 Interface MainPageAdmin
La figure ci-dessus représente l’interface dirigée pour l’administrateur.dans
cette interface on peut accéder au comptes des utilisateurs et des fournisseurs
et les gérer,consulter les catégories et les items disponibles,et aussi valider les
items.

Figure 5.15 – MainPage

56
5.3.4 Interface gérer utilisateurs
L’admin peut accédé à cette interface en sélectionnant un utilisateur ins-
crit .

Figure 5.16 – Liste des utilisateurs

57
5.3.5 Interface pour valider les items
Dans cette interface L’admin et le magasinier peuvent consulter les de-
mandes de matériel et peuvent les valider.

Figure 5.17 – Items pour les validé

58
5.3.6 Interface Items déjà validés
L’admin et le magasinier peuvent consulter les demandes qu’ils ont déjà
validé.

Figure 5.18 – Items validé

59
5.3.7 Interface Catégories
Cette interface représente les catégories disponibles dans le hangar, on
peut ajouter des nouvelles catégories si nécessaire.

Figure 5.19 – Hangar

60
5.3.8 Interface Liste des fournisseurs
Cette interface représente la liste des fournisseurs ajoutés par le magasi-
nier et L’admin.

Figure 5.20 – Fournisseurs

61
5.3.9 Interface Liste des factures
Cette interface représente la liste des factures ajoutées par le magasinier
et l’admin.

Figure 5.21 – Factures

62
5.3.10 L’interface MainPageEmployé
La figure ci-dessus représente la page d’accueil après l’authentification qui
représente les catégories des matérielles.L’employé peut rechercher un item
par son nom.il peut aussi voir les catégories qui a déjà consulter en cliquant
sur récent.

Figure 5.22 – MainPage

63
5.3.11 L’interface items de catégorie
Cette interface représente les items d’une catégorie.

Figure 5.23 – Liste des items

64
5.3.12 L’interface demander un matériel
Dans cette interface le responsable doit remplir les données pour effectuer
la demande matériel.

Figure 5.24 – Faire une demande matériel

65
5.3.13 Interface Historique de demandes de matériel
Le Responsable peut voir l’historique de toutes ces demandes matériel.

Figure 5.25 – Historique de demande

66
5.3.14 L’interface Profil
cette interface représente toutes les informations nécessaires de profil.

Figure 5.26 – Profil

67
5.3.15 L’interface track item
Cette interface nous montre l’étape atteint par l’item.

Figure 5.27 – Tracking item

68
5.3.16 Interface de Notifications
Cette interface montre comment tout les utilisateurs de l’application re-
çoivent des notifications, si une nouvelle catégorie ou un item est ajouté.

Figure 5.28 – Notifications

69
5.3.17 Interface Ajouter une nouvelle catégorie
Cette interface doit être remplie par l’utilisateur pour ajouter un nouvel
catégorie.

Figure 5.29 – Ajouter catégorie

70
5.3.18 Interface Ajouter un nouveau item
Cette interface doit être remplie par l’utilisateur pour ajouter un nouveau
item.

Figure 5.30 – Ajouter item

71
Conclusion Générale

Les applications mobiles sont de plus en plus utilisées dans les entreprises.
Elles permettent d’y la communication mais aussi de faciliter beaucoup de
taches au sien de cette dernière .

La gestion de stock est une activité incontournable qui constitue le cœur

des centres d’intérêts des gestionnaire. Elle est nécessaire pour exploiter le
matériel mais aussi pour son impact sur toutes les autres activités de l’en-
treprise.

L’objectif de ce projet de licence était de concevoir et développer une

application mobile qui permet la gestion des stock au profit de la direction
"Conception et développement" de l’ENAGEO.

Durant notre projet, le travail a été organisé en cinq étapes : nous avons
commencé par nous familiariser avec l’organisme d’accueil ainsi que le contexte
de notre projet. En second lieu, il a fallu comprendre comment l’information
et les documents circulaient entre les différents postes de travail au sein de
l’entreprise. Grâce à l’étude de l’existant, nous avons réussi à cerner claire-
ment la problématique que rencontre la société et à fixer l’objectif à atteindre.
Une fois ce dernier déterminé, nous nous sommes dirigé vers la spécification
générale de l’application future à l’aide des diagrammes des cas d’utilisation
et diagrammes de séquences. Lors de la quatrième phase, nous avons modélisé
la structure de l’application à l’aide du diagramme de classe. Tout cela nous
a permis d’aboutir à la réalisation de l’application, en utilisant des outils et
des langages de programmation divers.

Ce projet nous a donné la possibilité de découvrir de nouvelles approches

de développement d’applications mobiles ainsi que de mettre en pratique et
d’approfondir les connaissances théoriques acquises lors de notre formation
académique. En plus, cette expérience nous a aidé à apprendre à commu-
niquer correctement et à travailler en équipe. Aussi, cela nous a permis de

72
découvrir de nouveaux langages tel que "Dart" et la bibliothèque "FLUT-
TER". Enfin, ce fut un moyen d’acquérir une expérience en entreprise et de
se familiariser avec la vie professionnelle.

Nous avons atteint notre objectif initial qui était de développer une ap-
plication mobile pour la direction de conception et développement de L’EN-
AGEO, permettant la gestion des stock d’une manière plus simple et plus
efficace, cependant et en vue probable évolution future, nous avons comme
perspective d’améliorer notre application en ajoutant une discussion instan-
tanée entre les diffèrent utilisateur de l’application, Ceci faciliterait encore
plus la communication entre les différent utilisateur de l’application
de moderniser les méthodes d’authentification et de connections aux compte
par exemple permettre aux utilisateur de se connecter a leurs compte a l’aide
de l’empreinte digitale ce qui permettra de sécuriser encore plus les données
de l’application.
En fin, nous envisageons de rajouter la technologie nommé le Mapping pour
renforcer notre application avec une map pour tracker nos items en temps
réel.

73
Bibliographie

[1] Benoit Charroux, Aomar Osmani et Yann Thierry-Mieg. UML

2 : pratique de la modélisation. Pearson Education Paris, 2010.
[2] Déifinition de Firebase. Sept. 2022. url : https://www.boryl.fr.
[3] Déifinition de Google auth. Juin 2022. url : https % 20 : / / www .
techtarget.com.
[4] Déifinition de Google chrome emulator. Sept. 2022. url : https://
www.techno-science.net.
[5] Déifinition de Visuel studio code. Sept. 2022. url : https://framalibre.
org.
[6] Déifinition Umlet. Sept. 2022. url : www.Umlet.com.
[7] Ahmed Fergani. ENAGEO.DZ@ONLINE. Juin 2022. url : https:
//www.enageo.com/.
[8] Salima Hassas. Langage de modélisation unifié UML. Notes de cours.
2005.
[9] Anastas Kehaioff. « Choix du type de gestion de stock ». In : RAIRO-
Operations Research 14.1 (1980), p. 31-41.
[10] Qing Li et Yu-Liu Chen. « Data flow diagram ». In : Modeling and
Analysis of Enterprise and Information Systems. Springer, 2009, p. 85-
97.
[11] Jacques Lonchamp. « Analyse des besoins ». In : (2015).
[12] Rima MARNISSI et Rahma MEKNI. « Création d’un site web d’al-
phabétisation et d’éducation d’adultes ». Thèse de doct. Université Vir-
tuelle de Tunis, 2018.

74