République Algérienne Démocratique et Populaire

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

Université Abderrahmane Mira – Bejaïa

Faculté des Sciences Exactes
Département d’Informatique
Master 2, Option Génie Logiciel
Projet de fin de cycle

Thème

Conception et Réalisation d’une Application WEB pour

la gestion des Pannes des Equipements Informatiques.
Cas d’étude : « NAFTAL »

Réalisé par :

KAHOUADJI Wassila

KEZIZ Amel

Mémoire examiné par :

Présidente Mme. TIAB Amel

Examinateur Mme. BESSAAD Feriel

Encadrant Mr. OUZEGGANE Redouane

Années Universitaire 2019/2020

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

En second lieu, nous tenons à remercier notre encadrant [Link]

Redouane pour avoir bien voulu nous accompagner tout au long de ce projet, pour
son aide inestimable ses conseils et recommandations qui nous ont permis de réaliser
ce travail. Qu’il trouve ici l’expression de notre profonde gratitude.

Et en formule de ce travail, nous tiendrons à remercier également le personnel

de NAFTAL spécialement [Link] HALIM qui a eu l’amabilité de répondre à
nos questions et de nous fournir ses précieux conseils.

Nos remerciements vont aussi à tous les membres de jury qui nous ont fait
l’honneur d’accepter d’examiner ce travail et de l’enrichir.

Enfin nous tenons à remercier toutes les personnes qui ont contribué de près
ou de loin au succès de ce présent projet, trouvant aussi l’expression de nos profonds
gratitudes et respects.
 Dédicaces
C’est avec une très grande joie que je dédie ce travail
à ma mère qui ne cesse jamais de m’encourager et son soutien qu’elle
m’a accordé tout au long de mon chemin. Que dieu tout-puissant la
garde pour moi, A mes sœurs pour leur amour
et leur soutien inconditionnel, A toute ma famille, Et a tous mes amis où
qu’ils soient.

K. WASSILA
 Dédicaces
C’est avec une très grande joie que je dédie ce travail à mes chers
parents pour leurs encouragements, leurs soutiens et leur
patience, surtout ma mère à qui j’espère qu’elle est fière de moi.
A mes frères, mes sœurs et toute ma famille.
Et a tous mes amis où qu’ils soient.

K. AMEL
 TABLE DE MATIERES

Table des Matières

Table des Matières __________________________________________________________ i
Liste des Figures ___________________________________________________________ iii
Liste des Tableaux__________________________________________________________ iv
Liste des AbréviationsListe des tableaux _________________________________________ v
Introduction Générale _______________________________________________________ 1
Chapitre I : Présentation de l’organisme d’Accueil et le Recueil des besoins_____________ 5
I.1- Introduction ________________________________________________________________ 5
I.2- Présentation de l’organisme d’accueil ___________________________________________ 5
I.2.1- Historique ________________________________________________________________________ 5
I.2.2- Les activités de l’entreprise __________________________________________________________ 6

I.3- District GPL _________________________________________________________________ 6

I.3.1 Missions de la branche GPL ___________________________________________________________ 6

I.4- L’organigramme de District GPL ________________________________________________ 9

I.4.1- Département d’informatique ________________________________________________________ 10
I.5- Etude de l’existant __________________________________________________________ 10
I.6- Les équipements du NAFTAL __________________________________________________ 11
I.6.1- Les équipements matériels _________________________________________________________ 11
I.6.2- Les équipements logiciels___________________________________________________________ 12

I.7- Problématique et Objectifs ___________________________________________________ 12

I.7.1- Problématique ___________________________________________________________________ 12
I.7.2-Objectifs _________________________________________________________________________ 13

I.8-les Besoins fonctionnels et non fonctionnels _____________________________________ 14

I.9- Langage et Processus de développement ________________________________________ 16
I.10-Conclusion ________________________________________________________________ 16
Chapitre II : Analyse des besoins ______________________________________________ 18
II.1- Introduction ______________________________________________________________ 18
II.2- Identification des acteurs ____________________________________________________ 18
II.3- Diagramme de contexte _____________________________________________________ 19
II.3.1- identifications des messages________________________________________________________ 20
II.3.2- Relation entre les acteurs __________________________________________________________ 21

II.4- Identification des cas d’utilisation _____________________________________________ 22

II.4.1- Diagramme de cas d’utilisation ______________________________________________________ 23
II.4.2-Diagramme de cas d’utilisation – Technicien ___________________________________________ 24
II.4.3-Diagramme de cas d’utilisation – chef service – chef département _________________________ 25
II.4.4-Diagramme de cas d’utilisation –administrateur ________________________________________ 25

II.5- Description textuelle des cas d’utilisation _______________________________________ 26

i
 II.5.1- Description de Cas d’utilisation « S’authentifier » _______________________________________ 26
II.5.2-Description de Cas d’utilisation «lister les demandes d’intervention» _______________________ 27
II.5.3-Description de Cas d’utilisation « créer un OT » _________________________________________ 28
II.5.4-Description de Cas d’utilisation « accès à la maintenance préventive»_______________________ 29

II.6- Diagrammes de séquence système ____________________________________________ 31

II.6.1-Diagramme de séquence système cas d’utilisation «s’authentifier » ________________________ 31
II.6.2- Diagramme de séquence système du cas d’utilisation «créer une DI » ______________________ 32
II.6.3- Diagramme de séquence système du cas d’utilisation «créer un OT» _______________________ 33
II.6.4- Diagramme de séquence système du cas d’utilisation « Planification» ______________________ 34

II.7-Conclusion ________________________________________________________________ 35
Chapitre III : conception et élaboration du schéma relationnel ______________________ 37
III.1- Introduction ______________________________________________________________ 37
III.2- Diagrammes d’interactions __________________________________________________ 37
III.2.1- Les Diagrammes d’interaction des cas d’utilisation _____________________________________ 38
III.2.1.1- Diagramme d’interaction de cas d’utilisation «S’authentifier » ________________________ 38
III.2.1.2- Diagramme d’interaction de cas d’utilisation « Demande d’intervention » ______________ 39
III.2.1.3- Diagramme d’interaction de cas d’utilisation « créer un ordre de travail » ______________ 40
III.2.1.4- Diagramme d’interaction de cas d’utilisation « planifier » ____________________________ 42

III.3- Diagramme de classe de domaine_____________________________________________ 42

III.3.1- Description détaillée des attributs de classes __________________________________________ 44
III.3.2- Description détaillée des attributs des classes d'associations _____________________________ 49

III.4- Schéma relationnel ________________________________________________________ 49

III.4.1- Règles de passage au modèle relationnel _____________________________________________ 50
III.4.2- Le passage au modèle relationnel ___________________________________________________ 50

III.5- Conclusion _______________________________________________________________ 51

Chapitre IV : Réalisation _____________________________________________________ 53
IV.1- Introduction ______________________________________________________________ 53
IV.2- Langage et environnement de développement __________________________________ 53
IV.2.1- Les langages utilisés ______________________________________________________________ 53
IV.2.2- Outils et bibliothèque ____________________________________________________________ 54

IV.3-Implémentation de JEE suivant le modèle MVC __________________________________ 56

IV.4- Schéma physique de la base de données _______________________________________ 57
IV.5- Diagramme de déploiement _________________________________________________ 59
IV.6- Présentation des IHM ______________________________________________________ 59
IV.7- Conclusion _______________________________________________________________ 64
Conclusion Générale ________________________________________________________ 66
Bibliographie______________________________________________________________ 68
Annexe A: Processus UP _____________________________________________________ 71
Annexe B : Descriptions textuelles des cas d’utilisation ____________________________ 75
Annexe C : Diagrammes d’Interaction __________________________________________ 94

ii
 LISTE DES FIGURES

Liste des Figures

Figure I.1: Organigramme de District GPL Bejaia.................................................................. 9
Figure I.2: L’Organigramme de département informatique. .................................................. 10

Figure II.1: diagramme de contexte. ..................................................................................... 19

Figure II.2 : les relations d’héritage entre les acteurs. ........................................................... 21
Figure II.3: Diagramme de cas d’utilisation global du système.............................................. 23
Figure II.4: Diagramme des cas d’utilisation de l’acteur technicien. ...................................... 24
Figure II.5: Diagramme des cas d’utilisation de l’acteur chef service -chef département. ...... 25
Figure II.6: Diagramme des cas d’utilisation de l’acteur administrateur ............................... 25
Figure II.7: Diagramme de séquence système du cas d’utilisation « S’authentifier». ............. 32
Figure II.8: Diagramme de séquence système du cas «créer une DI»..................................... 33
Figure II.9: Diagramme de séquence système du cas d’utilisation «créer un OT». ................ 34
Figure II.10: Diagramme de séquence système du cas d’utilisation « Planification». ............. 35

Figure III.1: Diagramme d’interaction de cas d’utilisation «S’authentifier ». ........................ 39

Figure III.2: Diagramme d’interaction de cas d’utilisation «Demande d'intervention». ......... 40
Figure III.3: Diagramme d’interaction de cas d’utilisation « créer un ordre de travail ». ...... 41
Figure III.4: Diagramme d’interaction de cas d’utilisation «planifier». ................................. 42
Figure III.5: Diagramme de classe de domaine. ..................................................................... 43

Figure IV.1: Les composants JEE. ........................................................................................ 56

Figure IV.2 : Schéma physique de la base de données. .......................................................... 58
Figure IV.3: Diagramme de Déploiement. ............................................................................. 59
Figure IV.4: l’interface Homme-Machine « S’authentifier ». ................................................. 60
Figure IV.5: l’interface Homme-Machine « Accueil Administrateur ». .................................. 61
Figure IV.6: l’interface Homme-Machine « Ajouter un utilisateur ». .................................... 62
Figure IV.7: L’interface Homme-Machine « Créer un ordre de travail ». .............................. 63
Figure IV.8 : L’interface Homme-Machine « Créer une demande d’intervention ». ............... 64

iii
 LISTE DES TABLEAUX

Liste des Tableaux

Tableau I. 1 - les équipements informatiques matériels. ........................................................ 12
Tableau I. 2 - Les équipements informatiques logiciels.......................................................... 12

Tableau II. 1 - Identification des messages échangés. ........................................................... 20

Tableau II. 2 - Identification des messages échangés. ........................................................... 22
Tableau II. 3 - Description de cas d’utilisation « S’authentifier »......................................... 27
Tableau II. 4 - Description de cas d’utilisation «lister les demandes d’intervention ». .......... 28
Tableau II. 5 - Description de cas d’utilisation «créer un OT». ............................................ 29
Tableau II. 6 - Description de cas d’utilisation« accès à la maintenance préventive » .......... 31

Tableau III. 1 - Description des classes d’objets et leurs attributs. ................................................ 48

Tableau III. 2 - Descriptions des classes d’associations et leurs attributs. ................................... 49

iv
 LISTE DES ABREVIATIONS

Liste des AbréviationsListe des tableaux

AJAX Asynchronous JavaScript And XML

API Application Programming Interface

BD Base de Données

CRUD Create Read Update Delete

CSS Cascade Style Sheet

DAO Data Access Object

DI Demande d’intervention

DMR Direction Maintenance et réalisation « DMR »

DOM Document Object Model

EJB Entreprise Java Bean

ERDP l’entreprise de raffinage des produits pétroliers

GPL Gaz de Pétrole Liquéfié

HTML Hyper Text Markup Languag

HTTP Hyper Text Transfer Protocol

IDE Integrated Development Environment

IHM Interface Homme Machine

ING Service information de gestion

JEE Java Edition Entreprise

JPA Java Persistence Aannotation

JS JavaScript

JSP Java Sserver Pages

MVC Modele Vue Controleur

MySQL My Structured Query Language

v
OT Ordres de travaux

SGBD Système de Gestion de Base de Données

UML Unifed Modeling Language

XAMPPX (across) Apache MariaDB Perl Php

vi
INTRODUCTION
GENERALE
 INTRODUCTION
GENERALE
Introduction Générale

De nos jours, la gestion des données d'une façon automatisée occupe une place
privilégiée dans le monde des entreprises et organismes. Grâce à cette gestion
automatisée, à travers les technologies d’information et de communication (TIC), le
temps de traitement, de recherche et de filtre des données a été réduit d’une manière
considérable, ce qui permet aux gestionnaires d’améliorer leur rendement de travail
tout en évitant, ou au moins de diminuer, les erreurs.

C’est dans ce contexte que plusieurs sociétés essayent de profiter au maximum

possible de ces technologies afin d’améliorer leurs productivités et de faire face à
quelques problèmes pénibles qui peuvent constituer un obstacle de progression.

Dans ce cadre, l’entreprise NAFTAL souhaite développer une application web

permettant de gérer les équipements informatiques. La naissance de cette idée est due
pour répondre à un ensemble des besoins notamment : la gestion des équipements
(l’ajout des équipements - modification - suppression ...), et leurs maintenances.
Ainsi, et dans le contexte de notre projet de fin de cycle Master en Informatique,
nous avons effectué notre stage, d’une durée de 2 mois, au niveau du service
Informatique de l’entreprise NAFTAL. Ceci nous a permis de comprendre
l’environnement et l’organisation de travail pour la gestion de maintenance de
matériels informatiques (Ordinateurs, Imprimantes, Projecteurs ….).

En plus de ce qui a été ci-dessus dressé, le stage au Sein de service nous a

permis de déceler quelques problèmes de gestion des équipements informatiques et
leurs maintenances. Nous pouvons citer, parmi ces problèmes, la gestion manuelle, à
travers des fiches de maintenances, des ordres de travail, la difficulté de traçabilité
des tâches effectuées par les techniciens de maintenance et le temps perdu entre
l’émission d’un ordre de travail et sa réalisation par un technicien.

Page | 1
 Pour remédier à ces problèmes rencontrés au sein de l’organisme d’accueil,
nous avons, proposé, comme solution, une application web pour la gestion des pannes
du matériels informatique de NAFTAL. Pour atteindre cet objectif, nous avons suivi
une démarche basée sur une méthode allégée du processus UP et en utilisant les
formalismes de UML pour la modélisation des différents aspects de notre application.

Pour mieux présenter notre travail, notre mémoire est structuré en quatre
chapitres. Le premier s’articule sur la présentation générale de l’organisme d’accueil,
à savoir l’entreprise NAFTAL. Par la suite, nous avons présenté le district GPL
(Service au sein de l’entreprise), ses missions et son organisation, et son patrimoine
informatique (matériels et logiciels) qui se trouve dans l’entreprise NAFTAL. Par la
suite, en étudiant le processus de gestion des pannes informatiques, nous avons établi
une liste de problèmes liés à cette gestion, et par conséquent, nous avons proposé
notre solution qui consiste en la conception et développement d’une application web
pour la gestion de maintenance des équipements informatiques. Cette application doit
répondre à un certain nombre de besoins énumérés dans le recueil des besoins.

Dans le chapitre suivant, la phase d’analyse des besoins, énumérés dans le

recueil ci-dessus cité, sera effectué. Ceci nous permettra de définir les acteurs de notre
application, leurs différents cas d’utilisation, qui modélisent l’aspect fonctionnel de
l’application ainsi que leurs descriptions textuels et à travail le diagramme de
séquence.

La phase de conception du système sera détaillée en quatrième chapitre, en

élaborant les diagrammes d’interaction qui mettent l’accent sur les messages entre un
ou plusieurs acteurs et le système qui est fragmenté en différents objets qui
interviennent pour réaliser un cas d’utilisation. Ces objets sont de natures
différentes : Objets d’interface, objets de contrôle et objets entités. Ces derniers, objet
d’entités, nous permettent d’établir le diagramme de classe qui modélise un aspect
statique important de notre système. En fin de ce chapitre, et en appliquant les
différentes règles de passage du diagramme de classe vers le schéma relationnel de
données.

Comme dernière étape de notre démarche, la phase de réalisation sera détaillée

dans le quatrième chapitre, en présentant les différents outils et langages de
programmation utilisés, le schéma physique de données, sous forme de table et des
relations à travers les clés étrangère, le diagramme de déploiement qui schématise la

Page | 2
répartition physique des modules logiciel du système. Et nous terminons ce chapitre
avec quelques captures d’écran des interfaces homme-machine de notre application.

Page | 3
 CHAPITRE I
PRESENTATION DE L’ORGANISME
D’ACCUEIL ET LE RECUEIL DES BESOINS
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

CHAPITRE I
PRESENTATION DE L’ORGANISME
D’ACCUEIL ET LE RECUEIL DES BESOINS

Chapitre I : Présentation de l’organisme d’Accueil et le Recueil des besoins

I.1- Introduction
Dans ce chapitre, nous allons nous intéresser à la présentation de l’organisme
d’accueil, la description de ses diverses activités dans les différents domaines, Ensuite,
nous décrivons brièvement le Contexte du projet et la problématique à résoudre et
nous proposons une solution informatique qui répond à un certain nombre de besoins
fonctionnels et non fonctionnels du client.

I.2- Présentation de l’organisme d’accueil

NAFTAL est une entreprise pétrolière algérienne, spécialisée dans la
distribution des produits pétroliers.

I.2.1- Historique
L’entreprise ERDP (l’entreprise de raffinage des produits pétroliers) issue de
SONATRACH a été créée par le décret n° 80/101 du 06/04/1982, elle est chargée
de l’industrie du raffinage et la distribution des produits pétroliers. En 1987, l’activité
de raffinage est séparée de l’activité de distribution, la raison sociale de la société
change suite à cette séparation des activités.

NAFTAL est désormais chargée de la commercialisation et de la distribution

des produits pétroliers et dérivés. A partir de 1998, elle change de statut et devient
société par action filiale à 100% de SONATRACH, l’organisation de NAFTAL depuis
2001 n’est pas stable, le seul statut qui reste inchangé est le district GPL de Bejaia.

NAFTAL est réparti en 19 districts sur le plan national, dont le district de

bejaia. Elle intervient dans les domaines :

• de l’enfûtage des GPL « Gaz de Pétrole Liquéfié»,

Page | 5
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

• de la formulation de bitumes,
• de la distribution, stockage et commercialisation des carburants, GPL,
lubrifiants, bitumes, pneumatiques, GPL/carburant, produits spéciaux,
• du transport des produits pétroliers.

I.2.2- Les activités de l’entreprise

Les principes activités de l’entreprise NAFTAL sont :

a) La commercialisation de carburants pour la motrice essence et diesel :

• Essence normale.
• Essence Super.
• Essence Super Sans plomb.
• Gaz Oïl/CPL/C.
b) Commercialisation des pneumatiques de grandes marques.
c) Commercialisation d’une gamme de lubrifiants : ce dernier couvre toutes
les applications d’un secteur automobile et industriel.
d) Le traitement du gaz naturel où gaz associés.
e) Le raffinage du pétrole.
f) La liquéfaction du gaz naturel.

I.3- District GPL

I.3.1 Missions de la branche GPL
La branche GPL est chargée des activités liées au transport, stockage,
enfûtage, distribution, promotion et développement des GPL sur tout le territoire
national. Elle a pour missions de :

• Commercialiser les GPL vrac et conditionnés leurs emballages et

accessoires.
• Veiller au respect des normes et consignes de sécurité sur toute la chaîne
GPL (transport, installation d’enfûtage et de stockage, bouteilles,
citernes, accessoires, etc.…).
• Organiser et développer le réseau commercial et de distribution.
• Développer et valoriser les GPL sous toutes ses formes particulièrement
vrac et gaz carburant.

Page | 6
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

• Distribuer les GPL aux utilisateurs aux meilleures conditions de coût, de

qualité, de délais et de sécurité.
• Moderniser les infrastructures pour améliorer la productivité, la sécurité
et la gestion.
• Développer le partenariat et la coopération dans domaine des GPL.

I.3.2 Organisation de la branche GPL

La Branche GPL est une structure interne à NAFTAL, chargée totalement de

l’activité GPL, possède sa propre organisation nous illustrons les principaux
activités :

Au niveau central

La branche GPL comprend les directions suivantes :

• Direction des ressources humaines.

• Direction administration et moyens.
• Direction finances et comptabilités.
• Direction technique et maintenances.
• Direction hygiène sécurité et environnement.
• Direction marketing et exploitation.
• Groupe juridique et informatiques plus Audit.

Au niveau opérationnel

A travers le territoire national l’activité est organisée en 19 districts

(régionaux) couvrant les centres opérationnels qui sont :

• les centres emplisseurs (CE et MCE)

• centre vrac (CV)
• dépôt relais (DR).
• Direction Maintenance et réalisation « DMR » assiste les districts pour les
nouvelles installations et les gros travaux de maintenance des véhicules,
chariots élévateurs pompes et autres équipements.

Les districts fonctionnent dans l’optique de décentralisation, responsabilisation.

Ils sont entièrement autonomes, sur le plan opérationnel de la distribution. Et sur le

Page | 7
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

plan comptable et personnel. Ils exécutent et animent toutes les fonctions stockages,
livraison, vente, assistance technique, entretien, gestion financière et gestion des
ressources humaines.

Activité commerciale et marketing du district

Parmi ces activités on cite :

• Organiser et développer la commercialisation et la distribution des

produits GPL.
• Connaitre les différents marchés du GPL et les besoins actuels.
• Satisfaire sa clientèle dans les meilleures conditions d’efficacité et de
couts.
• Organiser et coordonner les activités de programmation des
approvisionnements, de ravitaillement et de distribution des différents
centres de stockage répartis à travers les quatre wilayas (BEJAIA, JIJEL,
BOUIRA et BBA).
• Assurer l’approvisionnement et la commercialisation des produits GPL
sur l’ensemble des quatre wilayas.
• Elaborer des plans en liaisons avec d’autre district visant la couverture
du marché national en produits GPL.

Page | 8
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

I.4- L’organigramme de District GPL

Le schéma suivant illustre le nouvel organigramme arrêté par la branche GPL
d’Alger depuis 2001 :

Directeur district

Sureté interne
Département informatique
Sécurité industrielle

Juriste
Service système et réseau Service ING

Département Département Département Département Département

personnel et finances et commercial Technique Exploitation
comptabilité
«moyen
e
commun
Service Service maint- Service
Service
comptabilité inst-fixe transport
Service ventes
RH
Service Service Service
Service planification et approvisio
Service trésorerie
marketing méthode nnement et
personnel
distributio
n
Service matériel
Service
roulant Service
budgets et
production
coûts
Service MC

MCE
Centre MCE Taher
DR d’Akbou Emplisseur Chorfa(Bouira
Béjaia

Figure I.1: Organigramme de District GPL Bejaia.

Page | 9
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

I.4.1- Département d’informatique

Le département d’informatique est une branche importante, il est constitué de
deux services à savoir :

a) Service information de gestion (ING)

Parmi ces missions :
• Il s’occupe de la maintenance du logiciel.
• il gère les flux d’information.
b) Service Réseaux et systèmes
Sa mission consiste à :
• gérer la maintenance du matériel et réseaux.

Dans notre cas on s’intéresse au service ING.

La figure ci-dessous illustre l’organigramme de ce département :

Chef département

Service Réseaux et Service

Systèmes Information de
gestion

Figure I.2: L’Organigramme de département informatique.

I.5- Etude de l’existant

Lors de notre stage au niveau du centre NAFTAL de Bejaia au sein du bureau
de la maintenance, nous nous sommes basés sur le processus de la maintenance des
équipements informatiques ainsi que la procédure de la gestion des pannes des
équipements .Cette procédure consiste à :

1) Lors d’une panne d’un équipement, l’utilisateur va former une demande de

travail, il passe ensuite la demande au chef de service
2) Ce dernier va analyser puis signer la demande de travail.

Page | 10
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

3) L’utilisateur passe l’équipement amené de la demande de travail au technicien

pour le réparer.
4) Ce dernier remplira les demandes suivantes :
• demande de travail : il spécifier dans cette demande le type de
l’intervention et la nature de travaux.
• ordre de travail : il précise le numéro de l’ordre, le nombre des agents,
la durée de la réparation et les résultats du test.
• fiche de travaux : elle contient en général les détails de facturation.

5) A la fin de la réparation, le technicien signe la fiche « SERVICE FAIT» si

l’équipement est réparé, Sinon il passe l’équipement au prestataire, et dans ce cas
il précise dans la fiche de travaux que la réparation n’a pas été faite sur place et
que l’équipement passera au prestataire.
L’équipement passe au service réformé si le cout de la réparation est supérieur
au cout d’achat.

I.6- Les équipements du NAFTAL

Les équipements informatiques sont répertoriés en équipements matériels et
logiciels dans lequel Chaque département du NAFTAL contient des d’équipements
informatiques matériels (tableau I.1) et logiciels (tableau I.2)

I.6.1- Les équipements matériels

Le tableau suivant illustre les équipements informatiques matériels (Chaque
équipement matériel identifié par un numéro d’inventaire unique) :

EQUIPEMENT CDS MARQUE N°

Inventaire
INF DELL I250600002
DESKTOP FIN ACER I350600099
TEC HP I350600122
COM LENOVO I350600044
CE061 MGE I506000009
ONDULEUR DIR INFOSEC I550600085
EXP APC I550600048

Page | 11
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

MCE181 CANON I450600088

IMPRIMANTE PAIE EPSON I450600115
PMC LEXMARK I450600062
Equipements réseaux
SWITCH MCE101 CISCO 2960G I350600089
ROUTEUR DR063 CISCO 892FSP I250600010

Tableau I. 1 - les équipements informatiques matériels.

I.6.2- Les équipements logiciels

Le tableau suivant illustre certains logiciels qui se trouvent dans l’entreprise
NAFTAL :

APPLICATION CDS TYPE

CONSOLE INF réseaux
NAFTCOMPTA FIN mono
IMMOSYS G TEC réseaux
NAFTPDR MRO/MIF MCE101 réseaux
SDCOM CE061 réseaux
GES FTE-A EXP réseaux
FTP MCE181 réseaux
TBG FIN réseaux
NOVACH PMC réseaux
NAFTMRO MCE101 réseaux

Tableau I. 2 - Les équipements informatiques logiciels.

I.7- Problématique et Objectifs

Après avoir fait l’étude de l’organisme d’accueil, nous allons analyser les
problèmes rencontrés par l’agent de maintenance informatique pour tenter d’apporter
des solutions.

I.7.1- Problématique
Lors de notre étude au sein du bureau de maintenance nous avons constaté
que ce système souffre de plusieurs problèmes qui ne devraient pas exister dans une
époque d’émergence de la technologie.

Page | 12
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

La gestion de la maintenance se fait presque manuellement en s’appuyant sur

certains documents Word et Excel aucun logiciel existant dans l’entreprise ne la gère,
ce qui engendre plusieurs problèmes.

Parmi ses problèmes nous notons :

• La gestion manuelle des pannes (création d’une demande d’intervention,

suivi de l’état des demandes envoyées, ...).
• Utilisation de plusieurs documents (rapport d’activité de maintenance
mensuelle, suivi des demandes clients, fiche de suivi-objectifs qualité,
demande de travail, fiche de travaux) ce qui entraine une mauvaise
organisation de ces derniers.
• Perte de temps a trouvé l’historique de toutes les tâches effectuées par le
technicien travaillant sur une panne.
• Une perte de temps dans la recherche des documents des équipements déjà
traités pour le suivie.
• Perte du temps à trouver les interventions effectuées sur un équipement
pour réaliser une demande de payement qui sera redirigé vers le centre de
frais.

Afin de palier à ces problèmes, nous proposons de développer une application web
permettant à l’entreprise NAFTAL d’atteindre les objectifs présentés dans les
points suivants.

I.7.2-Objectifs
La phase d’analyse a pour objectif de décrire de manière précise, concise,
correcte et compréhensible les besoins et les exigences du client. Il s’agit de livrer des
spécifications pour permettre la conception de la solution.

La phase d’analyse permet de s’accorder sur « ce que doit faire le système ? »

l’entreprise NAFTAL veut se doter d’un logiciel pour la maintenance qui pourra lui
permettra de :

• Offrir un meilleur système de gestion des équipements (ajout, modification

et suppression).
• Automatiser la procédure usuelle utilisée dans la réparation des
équipements.

Page | 13
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

• Automatiser l’ensemble des documents utilisés.

• Offrir un suivi de la maintenance des équipements.
• Offrir la possibilité d’avoir l’état des équipements (pièces de rechange,
historique des pannes, intervenants, caractéristiques techniques, stock pièces
de rechange disponibles etc.) Dans chaque service pour en garantir leurs
fonctionnements pendant les périodes de travail.
• Visualiser les demandes à distance.
• Gérer la réparation de logiciels.
I.8-les Besoins fonctionnels et non fonctionnels
• Les Besoins fonctionnels
Les besoins fonctionnels se rapportent aux fonctionnalités que l'application doit offrir
pour satisfaire les utilisateurs.
Les fonctionnalités que doit intégrer l'application à développer sont :

Gestion des utilisateurs

Il s’agit d’un outil permettant d’effectuer les opérations de gestion tel que l’ajout, la
suppression, la modification et la consultation des informations caractérisant chacun
des utilisateurs.
Notification de panne d’équipement
Le chef de service aura la possibilité de signaler une panne d’un équipement lorsque
celle-ci se produit.
Consultation de l’état des équipements
Le technicien aura la possibilité d’avoir un suivi sur l’état des équipements qui leur
permet de connaître les pannes qui se sont produites, la date de réparation, et leurs
états actuels.
Gestion des pannes

Le technicien aura la possibilité de gérer les demandes d’intervention signalées.

Gestion des travaux

L’application permet :

— La gestion des ordres d’intervention.

— La gestion de la maintenance préventive.
— La gestion des contrats de sous-traitance.
— La gestion des équipements.

Page | 14
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

Consultation des statistiques des équipements

L’application fournit une vue pour qu’un utilisateur puisse consulter les statistiques
des couts de maintenance et le nombre d’opérations de réparation sur un équipement.
Gestion de la documentation technique
Ce module est l’équivalent d’un gestionnaire bibliographique grâce auquel il est
possible de faire la saisie et la recherche d’informations.
Consultation et confirmation des demandes d’intervention
Permet d'afficher la liste des demandes d’intervention et de les confirmées.

• Les Besoins non-fonctionnels

Les besoins non fonctionnels sont indispensables et permettent l'amélioration

de la qualité logicielle de notre système. Ils agissent comme des contraintes sur les
solutions, mais leurs prises en considération fait éviter plusieurs incohérences dans le
système. Ce dernier doit répondre aux exigences suivantes :

L’extensibilité
Dans le cadre de ce travail, l’application devra être extensible, c’est-à-dire qu’il
pourra y avoir une possibilité d’ajouter ou de modifier de nouvelles fonctionnalités.
La sécurité
L’application devra être hautement sécurisée, les informations ne devront pas être
accessibles à tout le monde, c’est-à-dire que le site web est accessible par un
identifiant et un mot de passe attribués à une personne physique.
L’interface
Avoir une application qui respecte les principes des interfaces Homme/Machine
(IHM) tels que l’ergonomie et la fiabilité.
La performance
L’application devra être performante c’est-à-dire que le système doit réagir dans un
délai précis, quel que soit l’action de l’utilisateur
La convivialité
L’application doit être simple et facile à manipuler même par des non experts.
L’ergonomie
Le thème adopté par l’application doit être inspiré des couleurs et du logo type de
l’entreprise d’accueil.

Page | 15
 Chapitre I – Présentation de l’Organisme d’accueil et Recueil des besoins.

I.9- Langage et Processus de développement

En ce qui concerne le formalisme et l’enchaînement des étapes d‘analyse et de
Conception que nous avons adopté, nous nous sommes basés sur le langage de
modélisation UML et une démarche décrite dans (Voir Annexe A).

I.10-Conclusion
Dans ce premier chapitre nous avons présenté l’organisme d’accueil, déterminé
la problématique et la solution optimale proposée pour améliorer les différentes tâches
de la maintenance matérielle et logicielle de l’entreprise à l’aide des besoins
fonctionnels et non fonctionnels du client.

Page | 16
CHAPITRE II
ANALYSE DES BESOINS
 Chapitre II - Analyse des besoins

CHAPITRE II
ANALYSE DES BESOINS
Chapitre II : Analyse des besoins

II.1- Introduction
Dans ce chapitre nous allons présenter les différents acteurs de notre système,
leurs rôles, les différentes interactions avec le système ainsi que les besoins qui seront
modélisés par un diagramme de cas d’utilisation, la description textuelle de ces cas
d’utilisation et des diagrammes de séquence système.

II.2- Identification des acteurs

Un acteur représente l'abstraction d'un rôle joué par des entités externes
(utilisateur, Dispositif matériel ou autre système) qui interagissent directement avec
le système étudié.

En ce qui concerne notre système, nous présentons les acteurs suivants :

Chef département : Cet utilisateur s’authentifie à l’application via son compte

avec un login et un mot de passe. Il peut consulter le rapport mensuel et aussi
accéder à l’historique des équipements.
Chef service : son rôle consiste à gérer les demandes d’interventions, envoyer et
recevoir des notifications il peut aussi consulter le rapport mensuel et cela après
authentification
Technicien : Cet utilisateur gère les sous-traitances, les équipements, consulte leurs
historiques, crée des ordres de travaux (OT), ainsi il analyse les statistiques, cela
après authentification et la réception d’une notification d’une panne.
Administrateur : l’administrateur aura comme mission de créer ou supprimer des
comptes utilisateurs.

Page | 18
 Chapitre II - Analyse des besoins

II.3- Diagramme de contexte

Cette étape consiste à analyser la situation pour tenir compte des contraintes,
des risques et de tout autre élément pertinent afin de développer un système qui
permet de répondre aux besoins du client.

Nous allons présenter dans ce qui suit l’interaction entre le système, qui est
considéré comme une boite noire et les différents acteurs identifiés précédemment, en
identifiant les différents messages échangés entre chaque acteur et le système.

Figure II.1: diagramme de contexte.

Page | 19
 Chapitre II - Analyse des besoins

II.3.1- identifications des messages

Le tableau ci-dessous, permet d’expliquer les différents messages échangés
entre le système et les acteurs :

N° Message Acteur->Système N° Message Système->Acteur

M1 Demande d’authentification M2 Affichage de l’interface d’accueil

correspondant à chaque acteur

M3 Demande de création de compte M4 Affichage de l’interface de création

construire une demande d’intervention M6 notification d’une panne.

M5 M7 notification de l’envoi de message

M9 notification de prise en charge.

confirmer la prise en charge.
M8 M10 Affichage des détails de la panne.

M11 demande de création d’un ordre de M12 Affichage de l’interface de création

travail
M13 confirmation de la réparation M14 notification de la réparation

M15 demande de consultation du rapport M16 affichage de l’interface de consultation

mensuel

Tableau II. 1 - Identification des messages échangés.

Page | 20
 Chapitre II - Analyse des besoins

II.3.2- Relation entre les acteurs

En plus des acteurs définis dans le diagramme de contexte, nous avons ajoutés
un acteur abstrait (acteur généralisé) appelé utilisateur qui permet de représenter
tout personne non encore identifié par le système (Voir [01] page 79). Un héritage en
terme de fonctionnalités a était défini dans la figure ci-dessous :

Figure II.2 : les relations d’héritage entre les acteurs.

Une relation d’héritage entre acteurs signifie que l’acteur du côté opposé à la
pointe de la flèche il peut réaliser tout ce que l’acteur générale peut réaliser, plus
d’autres fonctionnalités.

Page | 21
 Chapitre II - Analyse des besoins

II.4- Identification des cas d’utilisation

Dans ce qui suit, nous allons énumérer les différents cas d’utilisation pour
chaque acteur du système. Pour mieux présenter ces cas d’utilisation.

N° Cas d’utilisation Acteur

1 S’authentifier Utilisateur

2 Lister des équipements Consulter l’état des équipements

Ajouter équipement
Modifier équipement
Supprimer équipement
3 Lister des ordres de travaux Créer des OT
Clôturer un OT Technicien
4 Accès à la sous-traitance Ajouter une facture
5 Analyse des statistiques
6 Accès à la maintenance préventive
7 Créer OT Confirmer la prise en charge d’une
panne
8 Recevoir une notification d’une panne
Chef service
Chef
9 Accès à l’historique des équipements département
Technicien
10 Accès à la maintenance Planifier un programme
préventive Modifier un programme préventif Technicien
Consulter un programme préventif
Supprimer un programme préventif
11 Recevoir une notification Chef service
12 Créer demande d’intervention et recevoir une notification

Chef service

13 Consulter le rapport mensuel Chef

département
Technicien

14 Lister des utilisateurs Ajouter un utilisateur Administrateur

Supprimer un utilisateur

Tableau II. 2 - Identification des messages échangés.

Page | 22
 Chapitre II - Analyse des besoins

II.4.1- Diagramme de cas d’utilisation

Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour
donner une vision globale du comportement fonctionnel d'un système logiciel. Ils sont
utiles pour des présentations auprès de la direction ou des acteurs d'un projet.

Un cas d'utilisation représente une unité discrète d'interaction entre un

utilisateur (humain ou machine) et un système. Dans un diagramme de cas
d'utilisation, les utilisateurs sont appelés acteurs, ils interagissent avec les cas
d'utilisation [02].

Pour notre système, le diagramme de cas d’utilisation global est représenté

dans la figure II.3

Figure II.3: Diagramme de cas d’utilisation global du système.

Page | 23
 Chapitre II - Analyse des besoins

II.4.2-Diagramme de cas d’utilisation – Technicien

Le diagramme suivant représente les cas d’utilisation associé à un Technicien,
ce dernier peut réaliser toutes les tâches représentées dans la Figure ci-dessous.

Figure II.4: Diagramme des cas d’utilisation de l’acteur technicien.

Page | 24
 Chapitre II - Analyse des besoins

II.4.3-Diagramme de cas d’utilisation – chef service – chef département

Le diagramme suivant représente les différentes tâches réalisées par le chef
service et chef département.

Figure II.5: Diagramme des cas d’utilisation de l’acteur chef service -chef
département.

II.4.4-Diagramme de cas d’utilisation –administrateur

Le diagramme ci-dessus représente les tâches spécifiées à un administrateur.

Figure II.6: Diagramme des cas d’utilisation de l’acteur administrateur

Page | 25
 Chapitre II - Analyse des besoins

II.5- Description textuelle des cas d’utilisation

Chaque cas d'utilisation d'un système doit être défini textuellement, cela
consiste à :

Identifier le cas : résumé de son objectif, les acteurs impliqués.

Décrire un scénario nominal : un ensemble de messages échangés entre les
acteurs et le système. Il s’agit ici de décrire le déroulement idéal des actions, où tout
va pour le mieux.
Un scenario alternatif : un ensemble d'actions qui s'exécutent si les conditions
dans le Scénario nominal ne sont pas validées.
Un scenario d’exception :
On parlera de scénario d’exception lorsqu’une étape du déroulement pourrait être
perturbée à cause d’un événement anormal.
Nous allons donner une description textuelle pour chaque cas d'utilisation :
II.5.1- Description de Cas d’utilisation « S’authentifier »
Le tableau suivant représente la description des cas d’utilisation
« s’authentifier » :

Cas d’utilisation « S’authentifier »

But Permet d’identifier l’utilisateur et de savoir son rôle dans l’application
(privilèges accordés à cet utilisateur).
Acteur Utilisateur
L’utilisateur doit fournir un identifiant et un mot de passe puis valide le
formulaire d’authentification.
Description Le système utilise l’identifiant et le mot de passe pour vérifier si ces
informations sont correctes. Dans le cas d’erreur, le système affiche un
message d’erreur et invite l’utilisateur à refaire l’authentification, sinon
(dans le cas de succès), le système affiche l’interface adéquate pour
l’utilisateur.
Précondition /
Ce cas d’utilisation est déclenché lorsqu’un utilisateur veut accéder au
système.
Scénario S’authentifier : ce cas permet à l’utilisateur d’accéder au système selon
nominal l’enchaînement suivant :
1-Le système affiche l’interface de l’authentification
2- L’utilisateur saisit son login et son mot de passe et valide l’opération.

Page | 26
 Chapitre II - Analyse des besoins

3- Le système effectue des vérifications.

-Si l’utilisateur a omis l’identifiant ou le mot de passe alors il faut exécuter
[Exception01 : Champs V ides]
-Si l’identifiant et/ou mot de passe ne sont pas corrects alors il faut exécuter
[Exception02 : ChampsIncorrects]
4- Dans le cas de succès, le système affiche l’interface d’accueil
correspondante à chaque utilisateur.
Scénario /
alternatif
Exception 1 : Le système notifie une erreur à l’utilisateur lui indiquant
Scénario qu’il a oublié, un ou plusieurs champs à saisir (identifiant ou mot de passe),
d’exception et l’invite à compléter les champs manquants.
Exception 2 : Le système indique à l’utilisateur qu’une erreur est détectée
liée à son identifiant et/ou à son mot de passe, il l’invite à ressaisir son
identifiant et/ou son mot de passe.

Tableau II. 3 - Description de cas d’utilisation « S’authentifier ».

II.5.2-Description de Cas d’utilisation «lister les demandes

d’intervention»
Le tableau suivant illustre la description de cas d’utilisation « lister les
demandes d’intervention »

Cas d’utilisation «lister les demandes d’intervention»

But Ce cas d’utilisation permet au chef de service de créer des demandes
d’intervention.
Acteur Chef de service
Description Dès qu’une panne survient l’agent demandeur la réclame au chef service. Ce
dernier construit à travers le système une demande d’intervention qui sera
envoyé au technicien sous forme de notification.
Pré- Etre authentifier
condition
Ce cas d’utilisation s’effectue lors d’une détection d’une panne.
Création d’une demande d’intervention (DI) : permet de créer une
Scénario demande d’intervention selon l’enchaînement suivant :
nominal 1- Le chef de service demande de créer une demande d’intervention.

Page | 27
 Chapitre II - Analyse des besoins

2- Le système affiche une fiche de création d’une demande d’intervention.

3- Le chef service remplit les champs du formulaire (numéro DI, date DI,
numéro inventaire, nom de demandeur, fonction, description de la panne, Le
service ou se trouve l’équipement...).
4- Le système effectue des vérifications :
-Si le chef de service a omis de remplir un des champs alors il faut exécuter
[Exception01 : ChampsVides]
5- Dans le cas de succès, le système sauvegarde les informations saisies, et
l’envoi au technicien sous forme de notification.
Scénario /
alternatif
Scénario Exception1 : Le système notifie une erreur au chef de service lui indiquant
d’exception qu’il a oublié un ou plusieurs champs à saisir, et l’invite à compléter les
champs manquants.

Tableau II. 4 - Description de cas d’utilisation «lister les demandes d’intervention

».

II.5.3-Description de Cas d’utilisation « créer un OT »

Le tableau ci-dessous représente la description des cas d’utilisation «créer un
ordre de travail» :

Cas d’utilisation «créer un ordre de travail»

But Ce cas d’utilisation permet au technicien de gérer les pannes signalées et créer
des ordres de travaux après avoir reçu une notification.
Acteur Technicien
Description Dès la réception d’une demande d’intervention envoyée par un chef de service,
le technicien valide la prise en charge de cette demande et crée un ordre de
travail propre à cet équipement.
Pré- Etre authentifier
condition
Ce cas d’utilisation s’effectue lors de la réception d’une notification d’une
panne corrective.
Scénario Valider la prise en charge :
nominal Le technicien valide la prise en charge de la demande pour signaler aux autres
techniciens que cette panne est en traitement.
Création d’un ordre de travail (OT) : permet de créer un ordre de
travail selon l’enchaînement suivant :

Page | 28
 Chapitre II - Analyse des besoins

1- Le technicien demande de créer un ordre de travail.

2- Le système affiche une fiche de création d’un ordre de travail.
3- Le technicien remplit les champs du formulaire (numéro OT, date OT,
numéro d’inventaire, désignation, numéro de la demande de travail,...).
4- Le système effectue des vérifications :
-Si le technicien a omis de remplir un des champs alors il faut exécuter
[Exception01 : ChampsVides]
5- Dans le cas de succès, le système sauvegarde les informations saisies, et
affiche un message correspondant à la réussite de l’opération.

Scénario /
alternatif
Scénario Exception1 : Le système notifie une erreur au technicien lui indiquant qu’il a
d’exception oublié un ou plusieurs champs à saisir, et l’invite à compléter les champs
manquants.

Tableau II. 5 - Description de cas d’utilisation «créer un OT».

II.5.4-Description de Cas d’utilisation « accès à la maintenance

préventive»
Le tableau ci-dessous représente la description des cas d’utilisation «accès à la
maintenance préventive» :

Cas d’utilisation «accès à la maintenance préventive »

But Ce cas d’utilisation permet au technicien de planifier et de consulter un
programme Préventif pour le suivi des équipements (surveiller l'état du
matériel, contrôler la consommation de pièces de rechange….) pour déterminer
l'évolution de la dégradation du matériel et la période d'intervention cela
permettra de réduire les risques et probabilités de dysfonctionnements des
équipements.
Acteur Technicien
Description Ce cas d’utilisation aide le technicien à planifier et à consulter un programme
préventif des équipements.
Pré- Etre authentifier
condition
Ce cas d’utilisation est déclenché lorsque le technicien veut soumettre un
équipement à la maintenance préventive.
Scénario Planifier :

Page | 29
 Chapitre II - Analyse des besoins

nominal 1- Le technicien demande au système le formulaire de planification de la

maintenance préventive.
2- Le système affiche le formulaire de planification de la maintenance
préventive des équipements.
3- Le technicien saisit les informations nécessaires (numéro de programme
préventif, l’équipement soumis à la maintenance préventive et les éléments à
maintenir, les actions de maintenance à réaliser, les pièces à utiliser, la
périodicité) et valide l’opération de planification.
4- Le système effectue des vérifications :
-Si le technicien a omis de remplir un des champs alors il faut exécuter
[Exception01 : ChampsVides]
5- Dans le cas de succès, le système sauvegarde les informations saisies par le
technicien.
Modifier le programme préventif :
1- Le technicien saisit dans le champ « rechercher » le numéro du programme
préventif à modifier.
2- Le système affiche le programme préventif correspondant à la recherche
effectuée.
3- le technicien clique sur le bouton modifier.
4- Le système affiche le formulaire de modification correspondant au
programme préventif sélectionné.
5- Le technicien effectue les modifications souhaitées et valide l’opération.
6- Le système effectue des vérifications :
-Si l’un des champs n’est pas correct alors il faut exécuter
[Exception02 : ChampsIncorrects]
7- Dans le cas de succès, le système sauvegarde les nouvelles informations.
Consulter le programme préventif :
1- Le technicien demande la consultation du programme préventif.
2- Le système affichera une fiche de consultation.
3- Le technicien sélectionne la date ou la période voulue et lancera la
recherche.
4- Le système affiche tous les programmes préventifs correspondant à la date
où à la période souhaitée.
5- Le technicien choisit un programme préventif et demande au système
d'afficher le détail correspondant au programme sélectionné.
6- Le système affiche toutes les informations correspondantes au programme
choisi.

Page | 30
 Chapitre II - Analyse des besoins

Scénario /
alternatif

Exception1 : Le système notifie une erreur au technicien lui indiquant qu’il a

Scénario oublié un ou plusieurs champs à saisir, et l’invite à compléter les champs
d’exception manquants.
Exception 2 : Le système indique au technicien qu’une erreur est détectée en
signalant le(s) champ(s) incorrect(s), et l’invite à ressaisir une autre fois.

Tableau II. 6 - Description de cas d’utilisation« accès à la maintenance

préventive »

Pour Le reste des Description textuelle des cas d’utilisation voir Annexe B.

II.6- Diagrammes de séquence système

Un diagramme de séquence 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 [03].

En ce qui suit, nous présenterons quelques diagrammes de séquences relatifs

aux cas d’utilisation présentés :

II.6.1-Diagramme de séquence système cas d’utilisation «s’authentifier

»
Pour accéder à son espace de travail, l’utilisateur entre son login et son mot de
passe et valide l’opération, le système effectue une vérification. Si l’un des champs est
vide ou incorrecte un message d’erreur est envoyé, si non l’interface correspondante à
l’utilisateur s’affiche.

Page | 31
 Chapitre II - Analyse des besoins

Figure II.7: Diagramme de séquence système du cas d’utilisation « S’authentifier».

II.6.2- Diagramme de séquence système du cas d’utilisation «créer une

DI »
Lors de la présence d’une panne le chef service remplit le formulaire
« demande d’intervention » et valide l’opération. Le système vérifie la saisie, En cas
d’erreur il le signale au chef service. Sinon la création de la demande est faite avec
succès et le système envoie une notification au technicien.

Page | 32
 Chapitre II - Analyse des besoins

Figure II.8: Diagramme de séquence système du cas «créer une DI».

II.6.3- Diagramme de séquence système du cas d’utilisation «créer un

OT»
Lorsque le technicien reçoit une notification d’une [Link] consulte la liste des
demandes d’interventions, sélectionne la panne à réparer il confirme ensuite la prise
en charge de la panne, il remplira un formulaire « Ordre de travail » puis validera
l’opération. Le système vérifie la saisie, En cas d’erreur il lui signale si l’un des
champs est incomplet ou vide sinon la création de l’OT est faite avec succès.

Page | 33
 Chapitre II - Analyse des besoins

Figure II.9: Diagramme de séquence système du cas d’utilisation «créer un OT».

II.6.4- Diagramme de séquence système du cas d’utilisation «

Planification»
Pour la gestion de maintenance préventive, le technicien remplit un formulaire
de planification préventive et valide l’opération. En cas d’erreur dans la saisie. Le
système lui signale une erreur. Sinon la planification est faite avec succès.

Page | 34
 Chapitre II - Analyse des besoins

Figure II.10: Diagramme de séquence système du cas d’utilisation « Planification».

Pour le reste des diagrammes de séquence système voir Annexe B

II.7-Conclusion
Nous avons, dans ce chapitre, analysé les besoins de notre application via des
diagrammes de cas d’utilisation, suivi par des diagrammes de séquence système. Cette
phase d’analyse nous a permis de décrire de manière globale les besoins de nos
utilisateurs, le fonctionnement désiré du système afin d’en faciliter la réalisation et la
maintenance. Dans le chapitre suivant, nous entamons une phase très importante
dans laquelle nous décrirons de manière détaillée comment ces besoins seront réalisés
dans notre application.

Page | 35
 CHAPITRE III
CONCEPTION ET ELABORATION DU
SCHEMA RELATIONNEL.
 Chapitre III – Conception et élaboration du schéma relationnel

CHAPITRE III
CONCEPTION ET ELABORATION DU
SCHEMA RELATIONNEL
Chapitre III : conception et élaboration du schéma relationnel

III.1- Introduction
La phase de la conception est une étape importante de réflexion dans le cycle
de développement logiciel après la phase de l’analyse et de spécification. Elle permet
de structurer, organiser, planifier le projet. Dans ce chapitre, nous allons présenter en
détails la conception du projet à travers les diagrammes d’interaction, le diagramme
de classes et aussi le modèle relationnel.

III.2- Diagrammes d’interactions

Le diagramme d’interaction permet de décrire les différents scénarios
d’utilisation du système. Pour chaque diagramme de séquence système définit
précédemment nous établirons un diagramme d’interaction. Ce diagramme comprend
un groupe d’objets représentés par des lignes de vie et des messages que ces objets
échangent lors de l’interaction [01].

Dans ce diagramme nous allons nous servir de trois types de classes :

• Classes d’interface (boundary) : Des classes qui permettent l’interaction

entre l’application et ses utilisateurs. Pour chaque cas d’utilisation, il y a au
moins une classe d’interface. Ce type de classe est schématisé comme suit :

• Classes de Contrôle (Control) : Ce sont des classes qui contiennent les

traitements et la cinématique de l’application. Elles font la transition entre les
classes d’interface et les classes entités. Elles sont schématisées comme suit :

Page | 37
 Chapitre III – Conception et élaboration du schéma relationnel

• Classes entités (entity) : Elles représentent les objets métiers, et ce sont

très souvent des entités persistantes, c’est-à-dire qui vont garder leurs
informations (données) après l’exécution d’un cas d’utilisation particulier. En
général, elles sont enregistrées dans une base de données. Leurs schématisation
se fait grâce à ce stéréotype :

III.2.1- Les Diagrammes d’interaction des cas d’utilisation

III.2.1.1- Diagramme d’interaction de cas d’utilisation «S’authentifier »

L’utilisateur de l’application doit s’authentifier pour accéder à l’application, et

de profiter de ces fonctionnalités, et ceci en saisissant le login et le mot de passe.

Page | 38
 Chapitre III – Conception et élaboration du schéma relationnel

Figure III.1: Diagramme d’interaction de cas d’utilisation «S’authentifier ».

III.2.1.2- Diagramme d’interaction de cas d’utilisation « Demande

d’intervention »

Le chef service signale une panne en saisissant les informations

correspondantes à la panne, le système envoie la notification de panne vers la page
d’accueil du technicien et cella après authentification.

Page | 39
 Chapitre III – Conception et élaboration du schéma relationnel

Figure III.2: Diagramme d’interaction de cas d’utilisation «Demande

d'intervention».

III.2.1.3- Diagramme d’interaction de cas d’utilisation « créer un ordre de

travail »

Le technicien doit s’authentifier pour pouvoir créer un ordre de travail.

Page | 40
 Chapitre III – Conception et élaboration du schéma relationnel

Figure III.3: Diagramme d’interaction de cas d’utilisation « créer un ordre de

travail ».

Page | 41
 Chapitre III – Conception et élaboration du schéma relationnel

III.2.1.4- Diagramme d’interaction de cas d’utilisation « planifier »

Le technicien il aura la possibilité d’ajouter un programme préventif et cela

après authentification.

Figure III.4: Diagramme d’interaction de cas d’utilisation «planifier».

Pour le reste des diagrammes d’interactions voir Annexe C

III.3- Diagramme de classe de domaine

Le diagramme de classes représente les classes constituant le système et les
associations entre elles. Les diagrammes de classes expriment de manière générale la
structure statique d’un système, en termes de classes et de relations entre ces
dernières. La figure III.5, en page suivante, illustre le diagramme de classe de
domaine qui représente les données de l’application.

Page | 42
 Chapitre III – Conception et élaboration du schéma relationnel

Figure III.5: Diagramme de classe de domaine.

Page | 43
 Chapitre III – Conception et élaboration du schéma relationnel

III.3.1- Description détaillée des attributs de classes

Dans ce qui suit, nous allons décrire les différentes classes schématisées dans le
tableau. Cette description sera présentée sous forme d’un tableau, comme présenté
dans la table ci-dessous.

Classe Responsabilité Attributs

signification Définition type

Utilisateur Classe qui idUtilisateur Identifiant Numérique

enregistre les
informations des
utilisateurs. nom Nom de la Alphabétique
Personne
prenom Prénom de la Alphabétique
Personne
Grade Grade de la Enuméré
Personne
Numtel N° de Chaîne de
téléphone de caractère
la personne
Login Login associé Chaîne de
à un compte caractères
Mdp Mot de passe Chaîne de
associé à un caractères
compte
Administrateur Classe qui idAdmin Identifiant Chaîne de
enregistre caractères
Les informations
des
administrateurs.

Chef service Classe qui idChefService Identifiant Numérique

enregistre
les informations nomService Le nom des Chaîne de
des chefs services caractères
services. aux quel les
chefs services
sont affectés.
Technicien Classe qui idTechnicien Identifiant Numérique
enregistre
les informations

Page | 44
 Chapitre III – Conception et élaboration du schéma relationnel

des techniciens. Fonction La Enuméré

qualification
d’un
technicien
Chef Classe qui idChefDepart Identifiant Numérique
département enregistre
informatique les informations nomDépartemen Le nom de Chaîne de
des chefs t département caractères
départements.
Equipement Description des numInventaire Identifiant Numérique
équipements de nomEquipement Le nom de Chaîne de
tous les services. l’équipement caractères
Etat Etat actuel Enuméré
de
l’équipement
dateMES date de mise Date
en service de
l’équipement
Service Le nom des Chaîne de
services caractères
aux quel les
équipements
sont affectés.
Fournisseur Nom du Chaîne de
fournisseur caractères
Demande Descriptions des numDemande Identifiant Numérique
d’intervent- demandes dateDéclaration Date de Date
ion d’interventions déclaration
d’un équipement d’une panne
anomalies_const Description Chaîne de
atées des anomalies caractères
constatées
dans
l’équipement

Ordre De Description des num_OT Identifiant Numérique

Travail différents DateDebut_OT Date début Date
ordres de d’un ordre de
travaux sur un travail
équipement dateDeClôture Date de Date
clôture d’un
ordre de
travail

Page | 45
 Chapitre III – Conception et élaboration du schéma relationnel

dateReparation Date de Date

réparation
d’une panne
natureDesTrava Description Chaîne de
ux des travaux caractères
effectués sur
une panne
Observation Observation Chaîne de
saisie après caractères
la réparation
d’une panne
Programme Description des numPrg Identifiant Numérique
Préventif différents
programmes titrePrg Le titre du Chaîne de
préventifs programme caractère
auquel les préventif
équipements debutPrg Date de Date
sont soumis. début d’un
programme
préventif
FinPrg Date de Date
terminaison
d’un
programme
préventif
Fréquence Représente le Enuméré
nombre de
fois qu’un
programme
préventif se
reproduit

duréeEstimée La durée Chaîne de

consacrée caractères
pour effectuer
tous les
tâches de ce
programme
Type Représente les num_TypePrv Identifiant Numérique
Programme types des
Préventif programmes

Page | 46
 Chapitre III – Conception et élaboration du schéma relationnel

préventifs nom_TypePrv Le type d’un Enuméré

programme
préventif

Pièce de Représente les numPR Identifiant Numérique

rechange pièces de nomPR Nom de la Chaîne de
rechange pièce de caractère
utilisées rechange
Référence Référence Chaîne de
d’une pièce caractère
de rechange
Marque La marque Chaîne de
d’une pièce caractère
de rechange
Fournisseur Nom du Chaîne de
fournisseur caractère

Facture de Classe qui numFacture Identifiant Numérique

Sous-Traitance enregistre tous Date Date Date
les factures de d’enregistrem
sous-traitance ent de la
facture
nbr_agents Nombre Numérique
d’agents
travaillant
sur la panne
nbr_heures Nombre Numérique
d’heures
consacré à la
réparation de
la panne
main d’œuvre Montant de Numérique
la main
d’œuvre

Niveau Description de numNiv Identifiant Numérique

Maintenance niveau nomNiv Niveau de la Enuméré
maintenance maintenance
Action Représente les idAction Identifiant Numérique
actions ajoutées Libellé Libellé Enuméré
au programme
préventif.

Page | 47
 Chapitre III – Conception et élaboration du schéma relationnel

Notification Description de idNotif Identifiant Numérique

notification Message message Chaîne de
envoyé caractère
Type Type de Chaîne de
notification caractère

Tableau III. 1 - Description des classes d’objets et leurs attributs.

Page | 48
 Chapitre III – Conception et élaboration du schéma relationnel

III.3.2- Description détaillée des attributs des classes d'associations

Le tableau ci-dessous représente les classes d’associations et leurs attributs :

Classe Attributs
d’association Signification Définition Type
nécessite numPR Identifiant Numérique
num_OT Identifiant Numérique
Quantité Quantité de pièces de Numérique
rechange utilisées
prix_unitaire Prix unitaire d’une PR Numérique
nécessite Pr1 numPR Identifiant Numérique
numPrg Identifiant Numérique
Quantité Quantité de pièces de Numérique
rechange utilisées
prix_unitaire Prix unitaire d’une PR Numérique
nécessite Pr2 numPR Identifiant Numérique
numFacture Identifiant Numérique
Quantité Quantité de pièces de Numérique
rechange utilisées
prix_unitaire Prix unitaire d’une PR Numérique
nécessite Pr3 numPR Identifiant Numérique
Num_OT Identifiant Numérique
Quantité Quantité de pièces de Numérique
rechange utilisées
prix_unitaire Prix unitaire d’une PR Numérique
ajouter numPrg Identifiant Numérique
idAction Identifiant Numérique
soumettre numInventaire Identifiant Numérique
numPrg Identifiant Numérique

Tableau III. 2 - Descriptions des classes d’associations et leurs attributs.

III.4- Schéma relationnel

A partir du diagramme de classe nous allons réaliser le modèle relationnel qui
est le modèle logique de données, ce modèle décrit de façon abstraite comment sont
représentées les données dans une base de données. Pour décrire une relation, nous
allons indiquer tout simplement son nom, suivi du nom de ses attributs entre
parenthèses. L’identifiant d’une relation est composé d’un ou plusieurs attributs qui

Page | 49
 Chapitre III – Conception et élaboration du schéma relationnel

forment la clé primaire. Une relation peut faire référence à une autre en utilisant une
clé étrangère, qui correspond à la clé primaire de la relation référencée.

III.4.1- Règles de passage au modèle relationnel

Les règles de passage au modèle relationnel sont :

• Relation (1..*) : il faut ajouter un attribut de type clé étrangère dans la relation
fils de l’association .L’attribut aura le nom de la clé primaire de la relation père de
l’association.
• Relation (1..1) : il faut ajouter une relation qui prend les deux clé primaire des
classes mère comme clé étrangère.
• Relation d’héritage : Trois décompositions sont possibles pour traduire une
association d’héritage en fonction des contraintes existantes :
– Décomposition par distinction : il faut transformer chaque sous-classe en une
relation. La clé primaire de la classe mère, migre dans la (les) relation(s) issue(s) de
la (des) sous-classe(s) et devient à la fois clé primaire et clé étrangère,
– Décomposition descendante (push-down) : Il faut faire migrer tous les attributs de
la classe mère dans la (les) relation(s) issue(s) de la (des) sous classe(s),
– Décomposition ascendante (push up) : Dans ce cas on supprime les relations issues
des sous classes et faire migré tous les attributs dans la relation issue de la classe
mère.

III.4.2- Le passage au modèle relationnel

Après avoir appliqué tous les règles de passage au modèle relationnel, nous
avons obtenu le schéma suivant :

Utilisateur (idUtilisateur, nom, prenom, grade, numtel, role, fonction, nomService,

nom Département, login, mdp)

Demande D’intervention (numDemande, dateDeclaration, anomalies_constatées,

idUtilisateur#, numInventaire#, idNotif#)

Equipement (numInventaire, nomEquipement, etat, dateMES, service, fournisseur,

idUtilisateur#)

Page | 50
 Chapitre III – Conception et élaboration du schéma relationnel

Ordre De Travail (num_OT, dateDebut_OT, dateDeCloture, dateReparation,

natureDesTravaux, observation, numNiv #, numInventaire#, numDemande#
numFacture#, idUtilisateur#, idNotif#)

Niveau Maintenance (numNiv, nomNiv)

Programme Préventif ( numPrg ,titrePrg ,debutPrg ,finPrg ,fréquence

,duréeEstimée,action ,organe_a_controlé ,consommable , num_TypePrv#)

Type Programme Préventif (num_TypePrv, nom_TypePrv)

Pièce De Rechange (numPR, NomPR, référence, marque, fournisseur)

Facture De Sous-Traitance (numFacture, date, nbr_agents, nbr_heures,

frais_mains_doeuvres, num_OT)

Action (idAction, libellé)

Notification (idNotif, message, type)

Soumettre (numInventaire, numPrg)

Nécessite (numPR, num_OT, quantité, prix_unitaire)

Nécessite Pr1 (numPR, numPrg, quantité, prix_unitaire)

Nécessite Pr2 (numPR, num_OT, quantité, prix_unitaire)

Nécessite Pr3 (numPR, numFacture, quantité, prix_unitaire)

Ajouter (idAction, numPrg)

III.5- Conclusion
Nous avons présenté dans ce chapitre la phase de conception de notre projet
via les diagrammes d’interactions, qui nous ont permis de décrire de manière globale
et détaillée, le fonctionnement désiré du système. Nous avons recensé par la suite les
règles de passage du diagramme de classe vers le modèle relationnel qui nous permet
d'avoir le schéma de la base de données de l'application à réaliser.

Page | 51
CHAPITRE IV
REALISATION
 Chapitre IV- Réalisation

CHAPITRE IV
REALISATION
Chapitre IV : Réalisation

IV.1- Introduction
Dans ce chapitre nous présentons les outils et langages de programmation que
nous avons utilisés pour le développement de notre application. Par la suite, le
schéma physique de la base de données est illustré à travers des tables et des
relations réalisées par des clés étrangères. Cette base de données est hébergée dans
une machine serveur avec les contrôleurs (Servlets) qui permettent de répondre aux
requêtes des clients (Navigateurs), ce schéma de composants et de communication
sera illustré à travers le diagramme de déploiement. Enfin, nous terminons ce
chapitre par quelques interfaces homme-machine.

IV.2- Langage et environnement de développement

Dans cette section, nous allons énumérer les différentes technologies qui sont
utilisées pour développer notre système.

IV.2.1- Les langages utilisés

• Html (HyperText Markup Language)

Le langage HTML est le langage universel utilisé sur les pages web lisibles par
tous les navigateurs web (Internet Explorer, Netscape, Mozilla, etc...). Ce langage
fonctionne suivant l’assemblage et la combinaison de balises permettant de structurer
et donner l’apparence voulue aux données textes, images et multimédias suivant la
mise en page voulue [04].

• CSS (Cascading Style Sheets)

Est un langage de mise en forme d’un document HTML. Il définit les règles de
style et de disposition appliquées aux éléments d’un document html. On utilise le

Page | 53
 Chapitre IV- Réalisation

CSS pour modifier le style de n’importe quel élément html pour corriger ses
dimensions, couleurs, bordures, etc. [05].

• JavaScript

JavaScript, a été créé pour permettre un accès par script à tous les éléments
d’un document HTML. En d’autres termes, il offre une possibilité d’interaction
dynamique de l’utilisateur, comme la vérification de validité d’une adresse courriel
dans des formulaires d’entrée d’informations, et afficher des invites c’est-à-dire des
messages de demande de confirmation [06].

• MySQL

MySQL est un système de gestion de base de données relationnelle (SGBDR)

libre qui vu le jour en 1995. Son rôle consiste à stocker et à gérer une grande quantité
de données en les organisant sous forme de table, et permet aussi la manipulation de
ces données à travers le langage standard du traitement des bases de données SQL
[05].

• JEE (Java Edition Entreprise)

JEE est une norme proposé par SUN qui facilite le développement
d’application d’entreprise distribuer, destiné à des plateformes web, il a été conçu
pour être exploité dans des environnements serveur et distribués. Dans ce cadre, la
sécurité n’a pas été négligée. C’est le langage le plus adopté par les développeurs
grâce à sa fiabilité et sa performance élevé [07].

IV.2.2- Outils et bibliothèque

• Eclipse

Eclipse est un IDE, Integrated Development Environment (EDI environnement

de développement intégré en français), c’est-à-dire un logiciel qui simplifie la
programmation en proposant un certain nombre de raccourcis et d’aide à la
programmation. Il est développé par IBM5. Il est gratuit et disponible pour la
plupart des systèmes d’exploitation.

• AJAX (Asynchronous Javascript And XML)

Page | 54
 Chapitre IV- Réalisation

AJAX (Asynchronous Javascript And XML) est une technique qui permet de
réaliser des requêtes au serveur Web pour obtenir des données ou effectuer des
opérations à distance, et actualiser une partie de la page [08].

• WampServer

Le WampServer est une plateforme de développement Web Sous Windows

permettant de faire fonctionner localement (sans se connecter à un serveur Externe)
des scripts PHP.

WampServer n'est pas en soi un logiciel, mais un environnement comprenant

deux serveurs (Apache et MySQL), un interpréteur de script (PHP), ainsi qu’une
application PhpMyAdmin pour l'administration Web des bases de données MySQL
[05].

• Visual Studio Code

Visual Studio Code est un éditeur de code multiplateforme édité par

Microsoft. Cet outil est destiné aux développeurs supporte plusieurs dizaines de
langages de programmation comme le HTML, C++, PHP, Javascript, CSS, etc.
parmi ces fonctionnalités la prise en charge du débogage, la mise en évidence de la
syntaxe, la complétion intelligente du code, la refacturation du code et Git intégré.
[04]

• Apache tomcat

Tomcat est un serveur http, il est diffusé en open source sous une licence
Apache, il a été écrit en langage JAVA.

Apache Tomcat est une implémentation open source d’un conteneur web qui
permet donc d’exécuter des applications web reposant sur les technologies servlets et
JSP, et inclut des outils pour la configuration et la gestion [09].

• JQUERY

JQUERY Est une bibliothèque JavaScript libre qui simplifie la manipulation

des objets DOM d’une base Web et d’interagir avec le serveur en utilisant AJAX
[10].

Page | 55
 Chapitre IV- Réalisation

• Bootstrap

Bootstrap est un Framework crée par deux développeurs du réseau social

Twitter et mis en open source en 2012, il est destiné à faciliter la création
d’application web. Il regroupe une collection d’outil fournis sous la forme de classes
CSS et de librairies JavaScript et jQuery, permettant aux développeurs de gagner du
temps et de réaliser simplement des codes complexes (animation, tableau,
carrousel,…) tout en réduisant la quantité de caractères requis, et donc le poids du
site web.

IV.3-Implémentation de JEE suivant le modèle MVC

Le modèle MVC est implémenté, JEE, en utilisant les concepts (ou
composants) suivants :

• Servlet : Une servlet est une classe Java capable de recevoir une requête

HTTP envoyée depuis le navigateur de l'utilisateur, et de lui renvoyer

une réponse HTTP [11].

• JSP (Java server pages) : sont les pages servant à générer l’ensemble du

code HTML de l’interface utilisateur [11].

• Les JavaBean : Sont des classes Java conçues pour être réutilisables

lors des développements en Java. Les composants JavaBeans permettent

une séparation entre le code Java et la gestion de l’affichage des données

et même d’éviter que le code des pages JSP devienne trop long et difficile

à manipuler. [11]

La figure suivante illustre les composants de JEE :

Figure IV.1: Les composants JEE.

Page | 56
 Chapitre IV- Réalisation

Tel que :

Partie 1 : représente le système de gestion de base de données (SGBD). Nous

trouvons dans celui-ci les informations stockées.
Partie 2 : représente le conteneur EJB (Entreprise Java Beans), c’est une
architecture de composants logiciels côté serveur pour la plateforme de
développement Java EE, il se compose de :

• JDBC (Java Data Base Connectivity) : est une API (Application

Programming Interface) d’accès aux bases de données relationnelles. [12]
• JPA (Java Persistence API) fournit un langage de requête (également
appelé JPQL), que vous pouvez utiliser pour manipuler des objets sans écrire
de requêtes SQL spécifiques à la base de données avec laquelle vous
travaillez. [12]
• DAO (Data Access Object) : Elle est composée d’un ensemble
d’interfaces locales et distantes. Les DAO (Data Access Object) permettent
d’accéder aux objets et proposent des méthodes de CRUD (Create Read
Update Delete) [13].
Partie 3 : représente les composants décrient précédemment qui sont les pages JSP
et les Servlets.
IV.4- Schéma physique de la base de données
La base de données a été implantée en utilisant l’application Web
PhpMyAdmin (outil dans xampp), qui représente une interface WEB pour
communiquer avec MySQL .Ce dernier nous permet facilement de schématiser les
tables et leurs relations (clés étrangères) comme indiqué à la figure IV.2.

Dans le schéma physique, nous indiquons les types des attributs de chaque
table, les clés primaires, les clés étrangères ainsi que les champs référencés. Et pour
simplifier l’implémentation de clés primaires et étrangères, nous avons mis une clé
artificielle (entier auto-incrémental) pour chaque table, cette clé est nommée « id ».
Par conséquent les clés étrangères seront dénommées id<table étrangère> (exemple :
idEquipement, idDI, idOT, …).

Page | 57
 Chapitre IV- Réalisation

Figure IV.2 : Schéma physique de la base de données.

Page | 58
 Chapitre IV- Réalisation

IV.5- Diagramme de déploiement

La figure suivante illustre les modules logiciels de notre application, et leur
répartition sur différentes machines physiques :

Application
réalisée en
Serveur Machine Serveur
utilisant JEE
MySQL travers le
Base de données serveur Web
Serveur Apache Tomcat.
Contrôle DISCO
(Application Web)

JDBC
Navigateur
affichant des
pages HTML.

Navigateur
HTTP/HTTPS HTTP/HTTPS
affichant des
pages HTML

Téléphone (Smartphone) Ordinateur Personnel

Navigateur Navigateur

Figure IV.3: Diagramme de Déploiement.

Les interfaces sont, dans la mesure du possible, conçu pour qu’elles soient
responsives, c'est-à-dire, adaptable aux différentes tailles d’écrans : Grands, moyens
et petits écrans.

IV.6- Présentation des IHM

Dans cette section nous allons présenter quelques interfaces Homme-Machine
de notre application.

Page | 59
 Chapitre IV- Réalisation

L’interface Homme-Machine « S’authentifier »

Les utilisateurs de l’application (technicien, chef service, chef de département

et l’administrateur) accèdent à l’application via une authentification en saisissant le
login et le mot de passe.

Figure IV.4: l’interface Homme-Machine « S’authentifier ».

L’interface Homme-Machine « Accueil Administrateur »

Après avoir effectué l’authentification, l’administrateur accède à sa page

d’accueil ou il pourra effectuer ses fonctionnalités : l’ajout d’un utilisateur, accéder à
son profil et enfin se déconnecter.

Page | 60
 Chapitre IV- Réalisation

Figure IV.5: l’interface Homme-Machine «Accueil Administrateur».

L’interface Homme-Machine « Ajouter un utilisateur »

Après avoir accéder à la page d’accueil, l’administrateur pourra créer un

compte utilisateur. La figure suivante représente le formulaire et les informations à
remplir pour la création d’un compte utilisateur et le « select »rôle permettra
d’afficher la suite du formulaire correspondant à chaque utilisateur.

Page | 61
 Chapitre IV- Réalisation

Figure IV.6: l’interface Homme-Machine « Ajouter un utilisateur ».

L’interface Homme-Machine « Créer un ordre de travail »

Lorsque le technicien reçoit une notification d’une panne, il consulte la liste

des notifications reçues sélectionne après la demande d’intervention à traiter et valide
sa prise en charge puis remplira un formulaire « Ordre de travail » propre à cette
demande d’intervention.

Page | 62
 Chapitre IV- Réalisation

Figure IV.7: L’interface Homme-Machine « Créer un ordre de travail ».

L’interface Homme-Machine « Créer une demande d’intervention »

Après avoir accédé à sa page d’accueil, Le chef du service pourra déclarer une
demande d’intervention d’une panne lorsque celle-ci se produit et pour cela un

Page | 63
 Chapitre IV- Réalisation

formulaire sera affiché. La figure suivante affiche ce formulaire et les informations à

remplir pour l’envoi de la demande.

Figure IV.8 : L’interface Homme-Machine « Créer une demande d’intervention ».

IV.7- Conclusion
Dans ce chapitre, nous avons présenté les aspects techniques liés à la
réalisation de notre application, à savoir les différents outils et les langages de
programmation pour développer notre application. Nous avons vu aussi la
structuration physique de notre base de données ainsi que le diagramme de
déploiement. Et en dernier, nous avons illustré quelques interfaces de notre
application.

Page | 64
CONCLUSION
GENERALE
 Conclusion Générale

CONCLUSION
GENERALE
Conclusion Générale

Dans le cadre de notre projet de fin d’étude, nous avons conçu et développé
une application de gestion de maintenance des équipements informatiques au niveau
de l’entreprise NAFTAL.

Le point de départ de la réalisation de ce projet était une récolte

d’informations nécessaires pour dresser un état de l’existant, présenter un aperçu sur
la problématique.

Par la suite, nous nous sommes intéressés à l’analyse et la spécification des

besoins qui nous a permis de distinguer les différents acteurs interagissant avec
l’application visée.

L’objectif de la partie suivante était la conception détaillée, dans laquelle nous

avons fixé la structure globale de l’application. Le dernier volet de notre projet était
la partie réalisation qui a été consacrée à la présentation des outils du travail et les
interfaces les plus significatives de notre application.

L’apport de ce travail a été d’une importance très considérable. En effet, il

nous a permis de suivre une méthodologie de travail bien étudiée, d’approfondir nos
connaissances dans le monde de développement des applications. Pour l’organisme
d’accueil à savoir NAFTAL se travail a permet de supprimer la gestion manuelle des
pannes des équipements informatiques.

Finalement notre travail ne s’arrête pas à ce niveau, en effet plusieurs

fonctionnalités peuvent être ajoutées à notre application notamment un système de
messagerie entre les différents acteurs de cette application.

Page | 66
BIBLIOGRAPHIE
 Bibliographie

BIBLIOGRAPHIE
Bibliographie
[01] Roy GILLES. ‘UML2 en action, de l'analyse des besoins en action’. Presses de
l'Université de Québec, 2009, première édition.

[02] ZOURANE Akil, MAMMERI Lydia, ‘Conception et Réalisation d'une

Application Réseau pour le Système ANDROID’, Université de Béjaia ,2013

[03] Embarcadero Page web. URL :

[Link] de
consultation : 05/08/2020.

[04] SADANE Zahir, ZEBABDJA Yassine,’ Conception et Réalisation d'un site Web

Dynamique pour la FAPE de Béjaia’, Université de Béjaia, 2014/2015.

[05] KHELOU.H, ZIANI.N, ‘Conception et réalisation d’une Application web de

vente des pièces détachées automobile’, Université de Béjaia ,2017/2018

[06] Nixon, R. ‘Développer un site web en Php, Mysql et Javascript, Jquery, CSS3
et HTML5’, janvier 2019, premier chapitre, 5eme édition.

[07] Wikibooks. Page web, URL: [Link] JEE.

Date de consultation: 15/08/2020.

[08] Mohamed CHINY‘AJAX (Asynchronous Javascript And XML’.Page Web.

URL : [Link] Date de consultation :
Avril 2018.

[09] Développons en java. Page web, URL :

[Link] de consultation :
12/05/2020.

[10] JS Foundation, ‘JQuery, write less do more’. Page Web. URL :

[Link] Date de consultation : septembre 2020.

Page | 68
 Bibliographie

[11] BRAND UP DIGITAL. Page web, URL:

[Link]
beans. Date de consultation: 20/09/2020.

[12] Philémon Globlehi. Medium. Page [Link] ://[Link]/code-divoire/les-

api-java-ee-642f9ad88d9f. Date de consultation : 19/09/2020.

[13] Alexandre Baillif, Philippe Lacomme et Raksmey Phan, ‘Création d’une

application JEE’, Support de cours concernant la mise en place d’une
application JEE avec client, Juillet 2010. URL :
[Link] Date de
consultation : 23/04/2020.

Page | 69
ANNEXES
 Annexe A

ANNEXE A
PROCESSUS UP

Annexe A: Processus UP
A. Le processus unifié (up)
A.1. Définition du processus unifié
Le processus unifié est un processus de développement logiciel itératif, centré sur
l’architecture, piloté par des cas d’utilisation et orienté vers la diminution des risques.
C’est un patron de processus pouvant être adaptes a une large classe de systèmes
logiciels, à différents domaines d’application, à différente types d’entreprises et à
différents niveaux de compétences.

A.2. Les caractéristiques du processus unifié

_ UP est itératif et incrémental
Le projet est découpé en itérations ou étapes de courte durée qui permettent de
mieux suivre l’avancement globale. A la fin de chaque itération une partie exécutable
du système finale est produite, de façon incrémentale (par ajout).

Figure A.1 :l’itération d’UP.

Page | 71
 Annexe A

_ UP est centré sur l'architecture

Tout système complexe doit être décomposé en partie modulaire afin d’en faciliter
la maintenance et l’évolution. Cette architecture (fonctionnelle, logique, matérielle,
etc.) doit être modéliser en UML, et pas seulement documentée en texte.
_ UP est guidé par les cas d'utilisation d'UML
Le but principal d’un système d’informatique est de satisfaire les besoin de client.
Le processus de développement sera donc accès sur l’utilisateur. Le cas d’utilisation
permettent d’illustrer ces besoins. Ils détectent puis décrivent les besoin fonctionnel
et leur ensemble constitue le modèle de cas d’utilisation qui dicte les fonctionnalités
complètes du système.
_ UP est piloté par les risques
Les risques majeurs du projet doivent être identifiés au plus tôt mais surtout levés le
plus rapidement. Les mesures à prendre dans ce cadre déterminent l’ordre des
itérations
A.3. Cycle de vie du processus unifié
L'objectif d'un processus unifié est de maîtriser la complexité des projets
informatiques en diminuant les risques. UP est un ensemble de principes génériques
adapté en fonctions des spécificités des projets.
_ L’architecture bidirectionnelle : UP gère le processus de développement par
deux axes.
_ L'axe vertical : représente les principaux enchaînements d'activités, qui
regroupent les activités selon leur nature. Cette dimension rend compte l'aspect
statique
du processus qui s'exprime en termes de composants, de processus, d'activités,
d'enchaînements, d'artefacts et de travailleurs.
_ L'axe horizontal : représente le temps et montre le déroulement du cycle de vie
du processus; cette dimension rend compte de l'aspect dynamique du processus qui
s'exprime en terme de cycles, de phases, d'itérations et de jalons.

Pour mener efficacement un tel cycle, les développeurs ont besoins de toutes les
représentations du produit logiciel.
- un modèle de cas d'utilisation.
- un modèle d'analyse : détailler les cas d'utilisation.
- un modèle de conception : finissant la structure statique du système sous
forme de sous systèmes, de classes et interfaces.
- un modèle d'implémentation : intégrant les composants

Page | 72
 Annexe A

- un modèle de déploiement : définissant les nœuds physiques des ordinateurs

- un modèle de test : décrivant les cas de test vérifiant les cas d'utilisation
- une représentation de l'architecture.

A.4. Les activités

_ Expression des besoins
L'expression des besoins comme son nom l'indique, permet de définir les différents
besoins :
- inventorier les besoins principaux et fournir une liste de leurs fonctions ;
- recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à
l'élaboration des modèles de cas d'utilisation.
- appréhender les besoins non fonctionnels (techniques) et livrer une liste des
exigences.
Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur et
représente sous forme de cas d'utilisation et d'acteur, les besoins du client
_ Analyse
L'objectif de l'analyse est d'accéder à une compréhension des besoins et des
exigences du client. Il s'agit de livrer des spécifications pour permettre de choisir la
conception de la solution.
Un modèle d'analyse livre une spécification complète des besoins issus des cas
d'utilisation et les structure sous une forme qui facilite la compréhension (scénarios),
la préparation (définition de l'architecture), la modification et la maintenance du
futur système. Il s'écrit dans le langage des développeurs et peut être considéré
comme une première ébauche du modèle de conception.
_ Conception
La conception permet d'acquérir une compréhension approfondie des contraintes
liées au langage de programmation, à l'utilisation des composants et au système
d'exploitation. Elle détermine les principales interfaces et les transcrit à l'aide d'une
notation commune.
Elle constitue un point de départ à l'implémentation :
- elle décompose le travail d'implémentation en sous-système
- elle créée une abstraction transparente de l'implémentation
_ Implémentation
L'implémentation est le résultat de la conception pour implémenter le système sous
formes de composants, c'est-à-dire, de code source, de scripts, de binaires,
d'exécutable et d'autres éléments du même type.

Page | 73
 Annexe A

Les objectifs principaux de l'implémentation sont de planifier les intégrations des

composants pour chaque itération, et de produire les classes et les sous-systèmes sous
formes de codes sources.
_ Test
Les tests permettent de vérifier des résultats de l'implémentation en testant la
construction. Pour mener à bien ces tests, il faut les planifier pour chaque itération,
les implémenter en créant des cas de tests, effectuer ces tests et prendre en compte le
résultat de chacun.

A.5. Les phases

_ Analyse des besoins
L'analyse des besoins donne une vue du projet sous forme de produit fini. Cette
phase porte essentiellement sur les besoins principaux (du point de vue de
l'utilisateur),
l'architecture générale du système, les risques majeurs, les délais et les coûts.
_ Elaboration
L'élaboration reprend les éléments de la phase d'analyse des besoins et les précise
pour arriver à une spécification détaillée de la solution à mettre en œuvre.
L'élaboration permet de préciser la plupart des cas d’utilisation, de concevoir
l’architecture du système et surtout de déterminer l'architecture de référence.
_ Construction
La construction est le moment où l’on construit le produit. L’architecture de
référence se métamorphose en produit complet. Le produit contient tous les cas
d’utilisation que les chefs de projet, en accord avec les utilisateurs ont décidé de
mettre au point pour cette version.
_ Transition
Le produit est en version bêta. Un groupe d’utilisateurs essaye le produit et détecte
les anomalies et défauts. Cette phase suppose des activités comme la formation des
utilisateurs clients, la mise en œuvre d’un service d’assistance et la correction des
anomalies constatées. Tout simplement la phase de transition permet de faire passer
le système informatique des mains des développeurs à celles des utilisateurs finaux.

Page | 74
 Annexe B

ANNEXE B
DESCRIPTION TEXTUELLE DES CAS

D’UTILISATIONon Textuelle des cas d’utilisation.

Annexe B : Descriptions textuelles des cas d’utilisation

• Description de Cas d’utilisation « lister des Equipements »

Le tableau suivant illustre la description de cas d’utilisation « lister des

équipements »

Cas d’utilisation « lister des équipements »

But Ce cas d’utilisation permet au technicien de lister les équipements.
Acteur Technicien
Description Lors de l’achat d’un nouveau matériel, le changement de
l’emplacement d’un équipement dans un service, ou dans le cas de la
mise en réforme, le technicien procède à l’ajout, à la modification ou à
la suppression de l’équipement. Ce cas permet aussi de consulter l’état
de chaque équipement et connaitre les pannes qui ont été détectés
pour chaque équipement.
Pré- Etre authentifier
condition
Ce cas d’utilisation est déclenché lorsque le technicien veut gérer les
équipements.
Ajouter un équipement : permet d’ajouter un équipement selon
l’enchaînement suivant :
1- Le technicien demande au système d’ajouter un équipement.
2- Le système affiche un formulaire d’information sur l’équipement à
ajouter.
3- Le technicien saisit les informations nécessaires (numéro

Page | 75
 Annexe B

d’inventaire, nom équipement, fournisseur, marque, date de mise en

Scénario service, secteur,...) et valide la saisie.
nominal 4-Le système effectue ces vérifications :
-Si l’utilisateur a omis un champ de saisi alors il faut exécuter
[Exception01 : ChampsVides]
- Si l’équipement existe déjà alors il faut exécuter
[Exception02 : EquipementExistant]
5- Dans le cas de succès, le système sauvegarde le nouveau matériel, et
affiche un message correspondant à la réussite de l’opération.
Modifier un équipement : permet de modifier un équipement selon
l’enchaînement suivant :
1- Le technicien saisi dans le champ « rechercher » le nom ou le
numéro d’inventaire de l’équipement.
2- Le système affiche tous les équipements correspondant à la
recherche effectué.
3- Le technicien sélectionne l’équipement à modifier et clique sur le
bouton modifier.
4- Le système affiche le formulaire de modification.
5- Le technicien modifie les champs souhaités et valide l’opération.
6- Le système effectue des vérifications :
- Si l’un des champs n’est pas correct alors il faut exécuter
[Exception03 : ChampsIncorrects]
7- Dans le cas de succès, le système sauvegarde les nouvelles
informations et confirme la modification.
Supprimer un équipement : permet de supprimer un équipement
selon l’enchaînement suivant :
1- Le technicien saisit dans le champ recherché le nom ou le numéro
d’inventaire de l’équipement.
2- Le système effectue des vérifications :
- Si l’équipement n’existe pas alors il faut exécuter
[Exception04 : EquipementNonTrouvé]
3- Dans le cas de succès, le système affiche tous les équipements
correspondant à la recherche effectué.
4- Le technicien sélectionne l’équipement à supprimer et clique sur le
bouton supprimer.

Page | 76
 Annexe B

5- Le système avertit le technicien en lui affichant une confirmation de

suppression.
6- Dans le cas où le technicien confirme l’annulation, l’équipement
sélectionné sera annulé par le système.
Consulter les équipements :
Le technicien peut accéder à l’état des équipements pour connaitre :
- Les pannes qu’un équipement a subies ;
- L’état d’un équipement (fonctionnel, en traitement, en panne) ;
- La date ou une panne a été signalée ;
- La date ou l’équipement a été réparé.
Consulter un équipement précis :
Dans cet enchainement, le technicien peut connaitre les mêmes
informations vu dans l’enchainement précédant, mais le système devra
effectuer des vérifications :
- Si l’équipement n’existe pas alors il faut exécuter
[Exception04 : EquipementNonTrouvé]
Scénario /
alternatif
Exception 1 : Le système notifie une erreur au technicien lui
indiquant qu’il a oublié un ou plusieurs champs à saisir, et l’invite à
compléter les champs manquants.
Scénario Exception 2 : Le système indique au technicien que l’équipement
d’exception existe déjà et qu’il ne peut pas l’enregistrer.
Exception 3 : Le système indique au technicien qu’une erreur est
détectée en signalant le(s) champ(s) incorrect(s), et l’invite à ressaisir
une autre fois.
Exception 4 : Le système indique au technicien que l’équipement
n’est pas enregistré et l’invite à vérifier les données saisies.

Tableau 1 : description de cas d’utilisation « Lister des équipements».

Page | 77
 Annexe B

• Description de Cas d’utilisation «accès à de la sous-traitance»

Le tableau suivant illustre la description de cas d’utilisation « accès à la sous-

traitance »

Cas d’utilisation «accès à la sous-traitance»

But Ce cas d’utilisation permet au technicien de gérer toutes les actions de
sous-traitance.
Acteur Technicien
Description Après toutes actions de sous-traitance le technicien enregistre et saisit
toutes les informations nécessaires.
Pré- Etre authentifier
condition
Ce cas d’utilisation est déclenché lorsque le technicien récupère
l’équipement chez le prestataire une fois que ce dernier réparé.
Scénario Ajouter une facture de sous-traitance : permet d’ajouter une
nominal facture de sous-traitance selon l’enchaînement suivant :
1- Le technicien demande au système d’afficher le formulaire
correspondant à l’ajout d’une facture de sous-traitance.
2- Le système affiche le formulaire de création.
3- Le technicien remplit les champs du formulaire (N° facture, date
facture, désignation, montant, nombre d’agents, nombre d’heures,
description,….) et valide la saisie.
4- Le système effectue des vérifications :
-Si le technicien a omis de remplir un des champs alors il faut exécuter
[Exception01 : ChampsVides]
5- Dans le cas de succès, le système sauvegarde les informations saisies
et affiche un message de la réussite de l’opération.
6- Le technicien recherche dans la liste des OT non clôturés de la sous-
traitance l’OT correspondant à cette facture, ensuite il va indiquer le
numéro de facture et indique que l’OT est clôturé pour changer son
état de non clôturé vers clôturé et valide l’opération.
7- Le système sauvegarde les informations saisies et affiche un message
de confirmation.
Scénario /
alternatif

Page | 78
 Annexe B

Scénario Exception 1 : Le système notifie une erreur au technicien lui

d’exception indiquant qu’il a oublié un ou plusieurs champs à saisir, et l’invite à
compléter les champs manquants.

Tableau 2 : Description de cas d’utilisation «accès à la sous-traitance».

• Description de Cas d’utilisation «Consulter le rapport mensuel»

Le tableau suivant illustre la description de cas d’utilisation « consulter le rapport

mensuel »

Cas d’utilisation «Consulter le rapport mensuel»

But Ce cas d’utilisation permet au chef de département et le chef service
de consulter le rapport mensuel (la situation des immobilisations des
équipements, le volume horaire et coût des interventions de
maintenance, ou la prestation fournie par les techniciens).
Acteur Chef département et le chef de service
Description Ce cas d’utilisation aide le chef département et le chef de service à
analyser le rapport mensuel pour prendre des décisions.
Pré- Etre authentifier
condition
Ce cas d’utilisation est déclenché lorsque le chef département et chef
de service veulent suivre les activités des techniciens, avoir une vue
Scénario générale sur les coûts de maintenance, etc.
nominal
Consultation du rapport mensuel :
1- Le chef département ou le chef de service demande au système de
consulter le rapport mensuel.
2- Le système affichera une fiche de consultation.
3- Le chef département ou le chef de service sélectionne la période
voulue et la situation souhaitée du rapport mensuel (la situation des
immobilisations des équipements, le volume horaire et coût des
interventions de maintenance, ou la prestation fournie par les
techniciens) et valide l’opération.
4- Le système affiche toutes les informations de la situation
sélectionnée.

Page | 79
 Annexe B

Scénario /
alternatif
Scénario /
d’exception

Tableau 3 : Description de Cas d’utilisation «Consulter le rapport mensuel».

• Description de Cas d’utilisation «Consulter l’historique des

équipements»

Le tableau suivant illustre la description de cas d’utilisation « consulter l’historique

des équipements »

Cas d’utilisation «Consulter l’historique des équipements»

But Ce cas d’utilisation permet au technicien, chef de département et chef
de service d’accéder aux historiques des équipements (historiques des
opérations effectuées, historiques des pièces de rechange utilisées,
historiques des intervenants, et les historiques des ordres de travaux
réalisés).
Acteur Technicien, chef de département et chef de service.
Description Ce cas d’utilisation aide les acteurs à prendre des décisions sur les
équipements (exemple : décision de reformer un équipement).

Pré- Etre authentifier

condition
Ce cas d’utilisation s’effectue lorsque les acteurs veulent connaitre tous
les informations concernant les équipements.
Consulter les historiques : permet d’afficher les historiques des
équipements selon l’enchaînement suivant :
Scénario 1- l’acteur demande des historiques sur les équipements.
nominal 2- le système demande l’historique voulu (historiques des opérations
effectuées, historiques des pièces de rechange utilisées, historique des
intervenants ou des ordres de travaux réalisés).
3- l’acteur choisit l’historique souhaité.
4- le système affiche une fiche de consultation correspondante à
l’historique sélectionné.

Page | 80
 Annexe B

5- l’acteur saisit le code équipement, indique la période (intervalle du

temps) voulu et valide l’opération.
6- le système affiche l’historique souhaité de l’équipement sélectionné.
Scénario /
alternatif
Scénario /
d’exception

Tableau 4 : Description de Cas d’utilisation «Consulter l’historiques des

équipements ».

• Description de Cas d’utilisation «lister les utilisateurs»

Le tableau suivant illustre la description de cas d’utilisation « lister les utilisateurs »

Cas d’utilisation «lister les utilisateurs»

But Ce cas d’utilisation permet à l’administrateur du système d’ajouter ou
supprimer un utilisateur, permet aussi d’affecter un rôle à un
utilisateur lors de la création du compte.
Acteur Administrateur
Description L’administrateur gère les comptes des utilisateurs en ayant la
possibilité d’ajouter ou de supprimer un utilisateur et de définir les
rôles et les privilèges des utilisateurs du système.
Pré- Etre authentifier
condition
Ce cas d’utilisation est déclenché lorsque l’administrateur veut
consulter les comptes existant. Aussi il aura la possibilité de créer et
supprimer un (des) compte(s).
Ajouter un utilisateur : permet d’ajouter un utilisateur à la liste
des utilisateurs selon l’enchaînement suivant :
1- L’administrateur du système demande d’ajouter un utilisateur.
2- Le système affiche la fiche des renseignements pour l’utilisateur à
Scénario ajouter.
nominal 3- L’administrateur du système saisit les informations nécessaires en
indiquant le rôle de l’utilisateur (technicien, chef de service ou chef de
département) et valide la création.

Page | 81
 Annexe B

4- Le système effectue des vérifications :

-Si l’utilisateur a omis un champ de saisi alors il faut exécuter
[Exception01 : ChampsVides]
5- Dans le cas de succès, le système crée un compte pour le nouvel
utilisateur, le sauvegarde, et retourne un avis d’enregistrement.
Supprimer un utilisateur : permet la suppression d’un utilisateur
selon l’enchaînement suivant :
1- L’administrateur du système demande la liste des utilisateurs.
2- Le système retourne la liste des utilisateurs.
3- L’administrateur du système sélectionne l’équipement à supprimer
et valide la suppression.
4- Le système avertit l’administrateur, en lui affichant une
confirmation de suppression.
5- L’utilisateur sera supprimé dans le cas de confirmation.
Scénario /
alternatif
Scénario Exception1 : Le système notifie une erreur à l’administrateur lui
d’exception indiquant qu’il a oublié un ou plusieurs champs à saisir, et l’invite à
compléter les champs manquants.

Tableau 5 : Description de Cas d’utilisation «lister les utilisateurs».

• Description de Cas d’utilisation «lister des ordres de travaux»

Le tableau ci-dessous représente la description des cas d’utilisation « lister des ordres
de travaux » :

Cas d’utilisation «lister des ordres de travaux»

But Ce cas d’utilisation permet au technicien de consulter la liste des
ordres de travaux et d’effectuer des actions (modification, suppression,
clôture) sur un ordre de travail.
Acteur Technicien

Description Ce cas d’utilisation permet au technicien de modifier et de supprimer

des ordres de travaux, à la fin de la réparation d’un équipement, le
technicien aura la possibilité de clôturer son ordre de travail et

Page | 82
 Annexe B

informe le chef service à travers le système en lui envoyant une

notification.

Pré- Etre authentifier

condition
Ce cas d’utilisation est déclenché lorsque le technicien veut lister ou
gérer les ordres de travaux.
Modification d’un ordre de travail (OT) : permet de corriger les
erreurs de saisie selon l’enchaînement suivant :
Scénario 1- Le technicien demande au système les OT d’un équipement par
nominal période, ou par numéro d’inventaire.
2- Le système affiche tous les OT correspondant à la recherche
effectuée.
3- Le technicien sélectionne un OT dans la liste et clique sur le bouton
modifier.
4- Le système affiche le formulaire de modification.
5- Le technicien modifie les champs souhaités et valide l’opération.
6-Le système effectue des vérifications :
- Si l’un des champs n’est pas correct alors il faut exécuter
[Exception01 : Champs Incorrects]
7- Dans le cas de succès, le système met à jour les informations de
l’OT, et affiche un message de confirmation de la modification.
Supprimer d’un ordre de travail : permet de supprimer un ordre
de travail selon l’enchaînement suivant :
1- Le technicien demande au système les OT par période, ou par
numéro d’inventaire.
2- Le système affiche tous les OT correspondant à la recherche
effectuée.
3- Le technicien sélectionne un ou les OT(s) dans la liste et clique sur
le bouton supprimer.
4- Le système avertit le technicien, en lui affichant une confirmation
de suppression.
5- Dans le cas où le technicien confirme la suppression, l’(es) OT(s)
sélectionné(s) sera ou seront supprimé(s) par le système.

Page | 83
 Annexe B

Clôturer un ordre de travail :

• A la fin de la réparation, le technicien indique que cet ordre de
travail est clôturé et notifie au chef de service que la réparation a été
effectuée sur place si l’équipement est réparé sur place, dans le cas où
l’équipement est redirigé a un sous-traitant à la récupération de cet
équipement il notifie que l’équipement est réparé sous-traitance, sinon,
il notifie que l’équipement est reformé.
Scénario /
alternatif
Scénario Exception 1 : Le système indique au technicien qu’une erreur est
d’exception détectée en signalant le(s) champ(s) incorrect(s), et l’invite à ressaisir
une autre fois.

Tableau 6 : Description de Cas d’utilisation « lister des ordres de travaux».

B.1 Diagrammes séquences systèmes

Diagramme de séquence système du cas d’utilisation « Ajouter un

équipement »

Lorsque le technicien consulte la liste des équipements, il a la possibilité

d’ajouter un nouvel équipement. Pour se faire, il remplit un formulaire et clique sur «
Ajouter ». Le système vérifie la saisie. En cas d’erreur, il le signale au technicien. Si
non, il ajoute l’équipement.

Page | 84
 Annexe B

Figure B.1 : Diagramme de séquence système du cas d’utilisation «Ajouter un

équipement».

Diagramme de séquence système du cas d’utilisation « Modifier un

équipement »

Lorsque le technicien veut modifier les informations d’un équipement, celui-ci

accède à la liste des équipements, sélectionne l’équipement a modifié et clique sur
« Modifier », puis remplit un formulaire de modification et valide l’opération. Le
système vérifie les champs saisis, dans le cas d’erreur, il le signale au technicien. Si
non, les informations de l’équipement seront modifiées.

Page | 85
 Annexe B

Figure B.2 : Diagramme de séquence système du cas d’utilisation «modifier un

équipement».

Diagramme de séquence système du cas d’utilisation « Supprimer un

équipement »

Si le technicien décide de supprimer un équipement, il accède donc à la liste

des équipements, puis il sélectionne l’équipement a supprimé et confirme la
suppression.

Page | 86
 Annexe B

Figure B.3 : Diagramme de séquence système du cas d’utilisation «supprimer un

équipement».

Diagramme de séquence système du cas d’utilisation « Ajouter une

facture de sous-traitance»

Pour ajouter une facture de sous-traitance, le technicien accède à la listes des

factures de sous-traitance et clique sur « Ajouter » puis remplit un formulaire et
valide l’opération. En cas d’erreur dans la saisie, le système lui signale une erreur.
Sinon, il ajoute la facture.

Page | 87
 Annexe B

Figure B.4 : Diagramme de séquence système du cas d’utilisation «Ajouter une

facture de sous-traitance».

Diagramme de séquence système du cas d’utilisation « lister des ordres

de travaux »

Le technicien consulte la liste des ordres de travaux, cette interface lui

permettra de modifier, supprimer ou clôturer un ordre de travail.

Page | 88
 Annexe B

FigureB.5 : Diagramme de séquence système du cas d’utilisation «lister les ordres

de travaux».

Page | 89
 Annexe B

Diagramme de séquence système du cas d’utilisation « clôturer un OT

À la fin de la réparation, le technicien procède à la clôture des ordres de

travaux et la saisie des observations. Le système à son tour envoie une notification
vers la page d’accueil de chef service.

Figure B.6 : Diagramme de séquence système du cas d’utilisation «clôturer un OT».

Diagramme de séquence système du cas d’utilisation « lister les

utilisateurs »

L’administrateur consulte la liste des utilisateurs, en ayant la possibilité de

créer un compte utilisateur aux autres acteurs du système (technicien, chef service ou
chef département) ou de le supprimer.

Page | 90
 Annexe B

Figure B.7 : Diagramme de séquence système du cas d’utilisation «lister les

utilisateurs».

Diagramme de séquence système du cas d’utilisation « Ajouter un

utilisateur »

Pour l’ajout d’un utilisateur, l’administrateur doit remplir un formulaire et

valide l’opération. Le système vérifie la saisie, si les champs sont corrects l’ajout est
effectué, sinon, un message d’erreur est affiché.

Page | 91
 Annexe B

Figure B.8 : Diagramme de séquence système du cas d’utilisation «ajouter un

utilisateur ».

Diagramme de séquence système du cas d’utilisation «consulter la liste

des équipements »

Le technicien accède à cette interface pour consulter les équipements.

Page | 92
 Annexe B

Figure B.9 : Diagramme de séquence système du cas d’utilisation «consulter la liste

des équipements».

Diagramme de séquence système du cas d’utilisation «lister les

équipements »

Lorsque le technicien consulte les équipements, cette interface lui permettra de

faire des actions sur les équipements (l’ajout, la suppression ou la modification).

Figure B.10 : Diagramme de séquence système du cas d’utilisation «lister les

équipements»

Page | 93
 Annexe C

ANNEXE C
DIAGRAMMES D’INTERACTION

Annexe C : Diagrammes d’Interaction

Diagramme d’interaction de cas d’utilisation «ajouter un équipements »

La figure suivante représente le diagramme d’interaction « ajouter un

équipement » :

Page | 94
 Annexe C

Figure C.1 : Diagramme d’interaction de cas d’utilisation «ajouter un équipement».

Diagramme d’interaction de cas d’utilisation « Modifier un équipement

La figure suivante représente le diagramme d’interaction « modifier un

équipement » :

Figure C.2 : Diagramme d’interaction de cas d’utilisation «modifier un

équipement».

Page | 95
 Annexe C

Diagramme d’interaction de cas d’utilisation « Supprimer un

équipement »

La figure suivante représente le diagramme d’interaction « supprimer un

équipement » :

Figure C.3 : Diagramme d’interaction de cas d’utilisation «supprimer un

équipement».

Page | 96
 Annexe C

Diagramme d’interaction de cas d’utilisation « Ajouter une facture de

sous-traitance»

La figure suivante représente le diagramme d’interaction «Ajouter une facture de

sous-traitance» :

Figure C.4 : Diagramme d’interaction de cas d’utilisation « ajouter une facture de

sous-traitance»

Page | 97
 Annexe C

Diagramme d’interaction de cas d’utilisation « lister des ordres de

travaux »

La figure suivante représente le diagramme d’interaction «lister des ordres de travaux

»:

Figure C.5 : Diagramme d’interaction de cas d’utilisation «lister des ordres de

travaux »

Diagramme d’interaction de cas d’utilisation « clôturer un OT »

La figure suivante représente le diagramme d’interaction «clôturer un OT» :

Page | 98
 Annexe C

Figure C.6 : Diagramme d’interaction de cas d’utilisation « clôturer un OT»

Page | 99
 Annexe C

Diagramme d’interaction de cas d’utilisation « lister les utilisateurs »

La figure suivante représente le diagramme d’interaction «lister les utilisateurs» :

Figure C.7 : Diagramme d’interaction de cas d’utilisation « lister les utilisateurs »

Page | 100
 Annexe C

Diagramme d’interaction de cas d’utilisation «consulter la liste des

équipements »

La figure suivante représente le diagramme d’interaction «consulter la liste des

équipements» :

Figure C.8 : Diagramme d’interaction de cas d’utilisation «consulter la liste des

équipements»

Page | 101
 Annexe C

Diagramme d’interaction de cas d’utilisation « Ajouter un utilisateur »

La figure suivante illustre le diagramme d’interaction «ajouter un utilisateur»

Figure C.9 : Diagramme d’interaction de cas d’utilisation «ajouter un utilisateur»

Page | 102
 Annexe C

Diagramme d’interaction de cas d’utilisation «lister les équipements »

La figure suivante représente le diagramme d’interaction «lister les équipements»

Figure C.10 : Diagramme d’interaction de cas d’utilisation «lister les équipements »

Page | 103
Résumé
Dans le monde contemporain, l'information est devenue le principal moteur de
progrès économique et social. L'important rôle qu'elle joue dans une organisation lui
fait consacrer des investissements importants et une attention particulière. Notre
travail consiste à concevoir et réaliser une application web pour la gestion de
maintenance des équipements informatiques au sien de l’entreprise NAFTAL de
Bejaïa. L’avantage le plus important de ce travail qu'il permet de passer d'une
manière manuelle à une méthode plus sécuriser et pratique dans la gestion des
pannes. Pour ce faire, nous avons suivi la démarche de développement logiciel UP et
le langage de modélisation UML. La mise en œuvre de notre application a été
effectuée sous l’environnement de développement ECLIPSE, à l’aide du langage de
programmation JAVA. Nous avons utilisé MYSQL comme serveur de base de
données. HTML, CSS, JavaScript et le Framework Bootsrap pour le frontend et JEE
pour les backend.

Mots Clés : Pannes, équipements informatiques, Java, JavaEE, JSP, JSTL, UML,
HTML, web, NAFTAL.

Abstract
In the contemporary world, information has become the main engine of
economic and social progress. The important role it plays in an organization makes it
devote significant investments and special attention. Our job is to design and build a
web application for the maintenance management of computer equipment at the
NAFTAL company in Bejaïa. The most important advantage of this work that it
allows to go from a manual way to a more secure and practical method in the
management of failures .To do this, we followed the UP software development
process and the UML modeling language. The implementation of our application was
carried out under the ECLIPSE development environment, using the JAVA
programming language. We used MYSQL as the database server. HTML, CSS,
JavaScript and the Bootsrap Framework for the frontend and JEE for the backend.

Keywords: breakdowns, computer equipment, Java, JavaEE, JSP, JSTL, UML,

HTML, web, NAFTAL.