Rapport Shay Mab WG Mao

Ministère de l’Enseignement supérieur et de la Recherche scientifique
UNIVERSITÉ DE TUNIS EL MANAR

Faculté des sciences mathématiques, physiques et naturelles de Tunis
Projet de Fin d’Etudes
Présentée par :
Shayma BEN OUAHMA
Conception et développement d’une

GMAO orientée pour la maintenance
technique des bâtiments
Réalisé au sein de : Ooredoo Tunisie
Encadrant universitaire Encadrant professionnel

M. khalil Gargouri M. Ahmed SAMAALI
Année universitaire : 2017-2018
Dédicaces
C’est grâce à Allah que j’ai élaboré ce modeste travail que je dédie à toutes les personnes
que je porte dans mon cœur, qui m’ont soutenue et qui m’ont permis, par leur amour
d’en arriver jusqu’à là.
Je me vois dans l’obligation de nommer en particulier :

Mon père MOHAMED EL HEDI
Qui n’a jamais cessé de m’assister, de me soutenir, et de m’encourager. En espérant qu’il
trouve ici le résultat de longues années de sacrifices et de privations pour m’aider à
avancer dans la vie. Puisse Dieu faire en sorte que ce travail porte son fruit.
Merci pour les valeurs nobles venu de vous Papa.
Ma mère LATIFA
Pour toute son assistance, ses sacrifices et sa présence dans ma vie, reçois à travers ce
travail aussi modeste soit-il, l’expression de mes sentiments et de mon éternelle gratitude.
Ma soeur IMEN
Mes deux frères AHMED et KARIM
Mes chers amis
Que ce travail soit l’illustration de mon respect et mon amour. En témoigne de mon
profond amour et ma gratitude pour les sacrifices qu’ils m’avaient consentis, qu’Allah
leurs gratifie d’une longue vie débordant de santé et de bonheur.
Shayma ben ouahma

Remerciements
Il me tient sincèrement à cœur, de signifier ma reconnaissance et de présenter mon

remerciement le plus respectueux à Monsieur. Ahmed SAMAALI, mon encadrant à
Ooredoo Tunisie , qui m’a fait part de ses connaissances et m’a accordé tout le temps et
les conseils nécessaires durant le stage.
Mon plus grand remerciement s’adresse aussi à Monsieur. khalil Gargouri, mon encadrant
à la faculté des sciences Tunis El Manar, pour sa disponibilité, pour l’énergie qu’il a
dépensé, pour ses conseils avisés qu’il n’a pas cessé d’apporter tout au long du travail.
Mes remerciement vont à tout l’équipe de maintenance, pour leurs encouragements et

leurs conseils en milieu professionnel et au niveau relationnel.
Je tiens ensuite à exprimer mes remerciement aux membres du jury d’avoir fait l’honneur
de juger mon travail.
Mes remerciements vont aussi à tous les enseignants de la faculté des sciences Tunis El
Manar, pour la formation qu’ils m’ont procurée durant mes années d’études.
Enfin, je tiens à gratifier tout individu qui m’a donné de son temps et son effort pour
mener à bien mon travail.
iii
Table des matières
Dédicaces ii
Introduction générale 1
1 Cadre général du projet 3

1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 La maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Rôles de la maintenance . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Objectifs de la maintenance . . . . . . . . . . . . . . . . . . . . . . 5
1.2.4 Les différentes formes de maintenance . . . . . . . . . . . . . . . . 5
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Etat de l’art 7
2.1 Définition GMAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Les Objectifs de la GMAO . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Concept de GMAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Les fonctionnalités du système GMAO . . . . . . . . . . . . . . . . 9
2.3.2 Les raisons à la mise en place d’une GMAO . . . . . . . . . . . . . 9
2.4 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Les solutions GMAO utilisés : . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . 11
iv
TABLE DES MATIÈRES v
2.4.4 Langages de modélisation . . . . . . . . . . . . . . . . . . . . . . . 12
3 Analyse et spécification des besoins 13

3.1 Les rôles de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Identifications des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6 Modélisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . 18
3.6.1 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . 18
4 Etude Conceptuelle 20
4.1 Description des diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1 Diagramme des paquetages . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.3 Diagramme de séquences . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Vue statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1.1 Diagramme de paquetages . . . . . . . . . . . . . . . . . . 21
4.2.1.2 Diagramme de classes général . . . . . . . . . . . . . . . . 27
4.2.2 Vue fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2.1 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . 28
4.2.2.2 Diagramme de séquence . . . . . . . . . . . . . . . . . . . 38
5 Réalisation et test 43
5.1 Environnement du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.2 Environnement de développement . . . . . . . . . . . . . . . . . . 44
5.1.3 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
vi TABLE DES MATIÈRES
5.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Conclusion 56
Table des figures
2.1 GMAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Logo OptiMaint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Logo ManageMaint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Diagramme de Cas d’utilisation global . . . . . . . . . . . . . . . . . . . . 18
4.1 Figure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Diagramme de classes pour Batiment . . . . . . . . . . . . . . . . . . . . . 22
4.3 Diagramme de classes pour Article . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Diagramme de classes pour Equipement . . . . . . . . . . . . . . . . . . . 24
4.5 Diagramme de classes pour Stock . . . . . . . . . . . . . . . . . . . . . . . 25
4.6 Diagramme de classes pour Budget . . . . . . . . . . . . . . . . . . . . . . 26
4.7 Diagramme de classes général . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.8 Diagramme de cas d’utilisation «Gérer parc équipement» . . . . . . . . . . 28
4.9 Diagramme de cas d’utilisation «Gérer les bâtiments»» . . . . . . . . . . . 32
4.10 Diagramme de cas d’utilisation «Gérer les articles» . . . . . . . . . . . . . 34
4.11 Diagramme de cas d’utilisation «Gérer le stock» . . . . . . . . . . . . . . . 35
4.12 Diagramme de cas d’utilisation «Gérer le budget» . . . . . . . . . . . . . . 37
4.13 Diagramme de séquence «Créer une nouvelle intervention» . . . . . . . . . 39
4.14 Diagramme de séquence « Changer etat equipement » . . . . . . . . . . . . 40
4.15 Diagramme de séquence « Créer un nouveau planning intervention » . . . . 41
5.1 Logo «HTML5» et «CSS3» . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Logo « Bootstrap» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
vii
viii TABLE DES FIGURES
5.3 Logo « Symfony» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4 Logo « PHP» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.5 Logo « Twig» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.6 Logo « MySQL» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7 Logo « Doctrine» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8 Logo « APACHE» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.9 Logo « WampServer» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.10 Logo « Netbeans » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.11 Architecture «MVC» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.12 Interface "Authentification" . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.13 Interface "Dashboard" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.14 Interface "Gestion du parc equipement" . . . . . . . . . . . . . . . . . . . . 50
5.15 Interface "Consulter fiche equipement" . . . . . . . . . . . . . . . . . . . . 50
5.16 Interface "Gestion des interventions" . . . . . . . . . . . . . . . . . . . . . . 51
5.17 Interface "Gestion des contrats de maintenance" . . . . . . . . . . . . . . . 51
5.18 Interface "Créer le planning de maintenance" . . . . . . . . . . . . . . . . . 52
5.19 Interface "Consulter la liste des interventions" . . . . . . . . . . . . . . . . 52
5.20 Interface "Imprimer fiche intervention" . . . . . . . . . . . . . . . . . . . . 53
5.21 Interface "Consulter le stock" . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.22 Interface "Gérer le budget" . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Liste des tableaux
3.1 Backlog du produit relatif à notre application . . . . . . . . . . . . . . . . 17
4.1 Description textuelle du cas d’utilisation «Gérer parc équipement» . . . . 29

4.2 Description textuelle du cas d’utilisation «Gérer parc équipement» . . . . 29
4.3 Description textuelle du cas d’utilisation «Gérer les interventions équipe-
ment» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Description textuelle du cas d’utilisation «Gérer les plannings équipement» 31
4.7 Description textuelle du cas d’utilisation «Gérer les articles» . . . . . . . . 34
4.8 Description textuelle du cas d’utilisation «Gérer le stock entrant» . . . . . 36
4.9 Description textuelle du cas d’utilisation «Gérer le stock sortant» . . . . . 36
4.10 Description textuelle du cas d’utilisation «Gérer le stock entrant» . . . . . 38
ix
Liste des acronymes
GMAO Gestion de maintenance assistée par ordinateur

PDR Piece De Rechange
KPI Key Performance Indicator
OMG Object Management Group
UML Unified Modeling Language
MVC Modèle-vue-contrlôeur
PHP Hypertext Preprocessor
HTML HyperText Markup Language
CSS Cascading Style Sheets
x
Introduction générale
L’informatique est devenue indispensable dans tous les domaines et secteur en rendant
le travail plus facile, plus précis et surtout bien géré. Spécialement dans le domaine de la
maintenance et particulièrement, la gestion de maintenance des infrastructures bâtiments
qui est une tâche capitale qui présente un nombre important de sous tâches réalisés ma-
nuellement et qui joue un rôle important dans la continuité de service et d’exploitation
des bâtiments des entreprises qui cherche à améliorer la performance de cette activité par
l’adoption des outils informtisés.
La gestion de maintenance assistée par ordinateur (souvent abrégée en GMAO) est
une méthode de gestion assistée destiné aux services de maintenance d’une entreprise afin
de l’aider dans ses activités. Parmi ces entreprises, Ooredoo Tunisie essaye d’adopter un
système de gestion de maintenance assistée par ordinateur qui est sur mesure adapté à
ses propres besoins. C’est dans ce contexte que s’inscrit ce projet de fin d’études qui a
pour objectif de mettre en place une GMAO pour la direction de maintenance bâtiments
et services techniques.
L’implantation d’un système de gestion de maintenance dans une entreprise doit être
considérée comme un projet stratégique qui, à ce titre, doit respecter une méthodologie
rigoureuse de conduite de projet. Celui-ci relève à la fois du domaine de l’organisation et
du domaine de l’informatique. Dans le cadre de mon projet j’ai développé une solution
GMAO orientée pour la maintenance des infrastructures techniques des bâtiments.
Le travail à réaliser consiste à concevoir et intégrer une solution permettant la gestion
des interventions, les contrats de maintenance, le stock des équipements et leurs mainte-
nances en se basant sur les concepts de la GMAO.
Le présent document s’articulant autour de cinq chapitres synthétise le travail effectué
durant ce stage de fin d’études.
• Chapitre 1 : Cadre général du projet : nous présentons l’organisme d’accueil, la
problématique et les solutions de travail.
• Chapitre 2 : Etat de l’art : Nous présenterons le concept de la GMAO ainsi que
ses fonctionnalités, nous allons par la suite faire une étude de l’existant que nous allons
critiquer et enfin nous introduisant la méthodologie de travail à suivre.
1
2 Introduction
• Chapitre 3 : Analyse et spécification : Nous dégagerons les besoins de notre client

dans un Backlog de produit et nous définirons par la suite le planning des Sprints. Nous
spécifierons également les besoins non fonctionnels et les besoins fonctionnels illustrés par
des diagrammes de cas d’utilisation du langage de modélisation unifié UML avec quelques
scénarios.
• Chapitre 4 : Conception : Nous présenterons la conception en détaillant quelques
diagrammes utiles pour bien modéliser les besoins fonctionnels de notre application.
• Chapitre 5 : Réalisation et test : Ce chapitre est consacrés pour la réalisation, il
comportera la conception architecturale ainsi que l’environnement de développement, et
nous détaillerons la réalisation des cinq sprints répartis entre la phase de développement
et de test.
Enfin, je clôture par une conclusion générale ainsi par la proposition de quelques pers-
pectives sur lesquels peut s’ouvrir le présent travail.
Chapitre 1
Cadre général du projet
Introduction
Le présent chapitre a pour objectif de situer le projet dans son cadre général. D’abord,
nous présenterons l’entreprise d’accueil, son organisation et ses principales activités. En-
suite, nous allons expliquer le sujet du projet, la problématique et les objectifs à atteindre.
1.1 Cadre du projet

Le projet présent est intitulé «GMAO» et s’inscrit dans le cadre de projet de fin d’études
en vue de l’obtention du diplôme de Master professionnel en Systèmes de Télécommunica-
tions et Réseaux (STR) à la Faculté des Sciences El-Manar de Tunis. Le stage a été effectué
au sein de l’opérateur Ooredoo Tunisie.
Organisme d’accueil
Tunisiana est le premier opérateur privé de télécommunication en Tunisie. Le 11 mai
2002, tunisiana signe avec l’État tunisien une convention de licence pour l’installation
et l’exploitation d’un deuxième réseau de téléphonie mobile dans le pays. 6 mois après
son lancement commercial, son réseau couvre 60% de la population tunisienne. Acteur
3
4 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET
essentiel du secteur des nouvelles technologies, elle s’est appuyée sur les progrès rapides
de la technique pour développer des services adaptés, innovants et de qualité. Depuis
son lancement commercial le 27 décembre 2002, tunisiana avait bouleversé le paysage des
nouvelles technologies en Tunisie en proposant une gamme d’offre et de service novateurs
en respect avec les standards internationaux. En juillet 2012, tunisiana a lancé les services
3G destiné à plus de 6.6 millions d’abonnés et couvrant 48% de la population. En 2014, le
réseau s’est étendu à près de 90% de la population. La licence délivrée par l’état permet
à tunisiana de déployer un réseau HSPA+ à la fois sur 900Mhz et 2100Mhz assurant une
couverture plus étendue couvrant les régions de l’intérieur et une qualité vocale en haute
définition <HD hide Band AMR> le réseau permet des débits atteignant les 42 Mbps
pour assurer le meilleur service à ses abonnées. Tout en prônant le changement dans la
continuité, Tunisiana, devenue Ooredoo le 24 avril 2014, est la filiale tunisienne du Groupe
Ooredoo. Aujourd’hui Ooredoo est un opérateur universel qui répond à tous les besoins de
ses clients.
1.2 Présentation du projet

Mon travail consiste à concevoir et à développer une application de gestion de mainte-
nance assistée par ordinateur permettant de faire le contrôle et le suivie de maintenance
au sein de l’entreprise Ooredoo Tunisie.
1.2.1 La maintenance
D’après l’AFNOR (Association Française de Normalisation), la maintenance c’est « un
ensemble des actions permettant de maintenir ou de rétablir un bien dans un état spécifié
ou dans des conditions données de sûreté de fonctionnement, pour accomplir une fonction
requise. »[1] Ce qui fait que la maintenance regroupe l’ensemble des actions de dépannage,
de réparation, de réglage, de révision, de contrôle et de vérification des équipements dans le
but d’aboutir à l’amélioration du gestion orientée pour la maintenance des infrastructures
bâtiment.
1.2.2 Rôles de la maintenance

La maintenance joue plusieurs rôles :
— Un rôle productif : la maintenance permet de garder un taux de disponibilité maxi-

mum, il en résultera un meilleur potentiel de production.
— Un rôle économique : la maintenance vise à diminuer les pannes et les pertes de

production associées. Le stockage ou remplacement de pièces inutiles et la main
CHAPITRE 1. CADRE GÉNÉRAL DU PROJET 5
d’œuvre consommée pour les interventions des équipements.
— Un rôle d’assurance qualité : la maintenance contribue à la qualité par un fonction-

nement correct et des réglages adéquats.
— Un rôle de sécurité : Les dépannages, la maintenance préventive et les modifica-

tions réglementaires sont réalisés dans le but de garantir un bon état et un bon
fonctionnement du matériel avec toutes les protections nécessaires.
1.2.3 Objectifs de la maintenance

Les objectifs de la maintenance sont :
— la disponibilité et la durée de vie du bien.
— la qualité de la production.
— la protection de l’environnement.
— l’optimisation des coûts de maintenance.
1.2.4 Les différentes formes de maintenance

— La maintenance préventive :
Elle consiste à intervenir sur un équipement avant d’avoir une défaillance, C’est une
prévention à la panne pour des raisons de sûreté de fonctionnement.
— La maintenance corrective :
Elle consiste à intervenir sur un équipement une fois que celui-ci est défaillant.
— La maintenance curative :
Elle consiste à remettre l’équipement à son état initial.
— La maintenance planifiée :
Elle consiste à effectuer des opérations systématiquement, soit selon un calendrier
c’est à dire à périodicité temporelle fixe, soit selon une périodicité d’usage par
exemple heures de fonctionnement, nombre de mouvements effectués.
1.3 Problématique
Compte tenu du coût croissant de la technicité des équipements maintenus, l’importance
de la maintenance dans l’entreprise n’est plus à démontrer. Le suivie et le traitement
des données d’une façon manuelle et non informatisé devient impossible vu le nombre
important d’informations (techniques et budgétaires) dans le domaine de la maintenance ce
qui implique des moyens de saisie, de stockage et de traitement que seul l’outil informatique
permet. Les questions qu’on se pose au regard d’un tel projet sont les suivantes :
6 CHAPITRE 1. CADRE GÉNÉRAL DU PROJET
— Comment mettre à disposition aux responsables au sein d’une entreprise un outil

devant aider à gérer le parc des équipements ?
— Comment assurer une bonne gestion du processus de maintenance ?
— Comment peut-on modéliser la solution tout en tenant compte des besoins des
utilisateurs ?
Dans ce cadre, le service bâtiment d’Ooredoo souhaite une nouvelle solution de gestion de
maintenance qui répond à cette nécessité.
1.4 Solution
Nous allons réaliser une application de gestion de maintenance assisté par ordinateur
pour la maintenance des infrastructures technique des bâtiments qui offre toutes les fonc-
tionnalités efficaces pour obtenir une meilleure organisation du service et un suivi continu
de l’activité de la maintenance .
Conclusion
Le long de ce chapitre, nous avons abordé d’une façon générale le cadre de notre projet
de fin d’études. Tout d’abord, nous avons présenté l’organisme d’accueil, ensuite, nous
avons abordé la solution à notre problème. Nous y avons exposé les différentes raisons de
ce choix comme solution pour la maintenance technique des bâtiments en précisant le choix
méthodologique de développement. Dans le chapitre suivant, nous allons entamer la phase
de l’état de l’art.
Chapitre 2
Etat de l’art
Introduction
Avant de se lancer dans le développement d’une nouvelle solution pour offrir la gestion
de maintenance, il est primordial de bien étudier les notions de base qui nous aiderons à
comprendre la suite du projet. Dans une première partie nous allons présenter la définition,
les objectifs et le concept d’une GMAO, La seconde partie nous allons élaborer une étude de
solutions existantes que nous allons par la suite critiquer ce qui nous permettra d’avoir une
vision plus claire vise à vis les solutions existantes dans le marché et enfin nous introduisant
la démarche de la réalisation du projet qu’on a opté pour.
2.1 Définition GMAO

La gestion de maintenance assistée par ordinateur (souvent abrégée en GMAO) est une
méthode de gestion assistée destiné aux services de maintenance d’une entreprise afin de
l’aider dans ses activités.[2]
7
8 CHAPITRE 2. ETAT DE L’ART
Figure 2.1 – GMAO
2.2 Les Objectifs de la GMAO

— Avoir un meilleur suivi et contrôle des équipements (pas de confusion entre les noms
des équipements et pas d’erreurs).
— Améliorer la qualité de service et assurer la meilleure productivité de l’entreprise.
— la prolongation de la durée de vie des équipements.
— Maîtriser la préparation des interventions, leur planification et leurs coûts
— Optimiser la gestion du stock de pièces de rechange afin de diminuer la valeur de ce
stock tout en maintenant une disponibilité satisfaisante des installations
— Avoir une meilleure visibilité sur les ressources qui permettront de prendre de
meilleures décisions.
2.3 Concept de GMAO

En 1985 M. Gabriel et Y.PIMOR définissaient la gestion de la maintenance assistée par
ordinateur en ces termes : « Un système informatique de management de la maintenance
est un progiciel organisé autour d’une base de données permettant de programmer et de
suivre sous les trois aspects techniques, budgétaire et organisationnel, toutes les activités
d’un service de maintenance et les objets de cette activité (services, lignes, ateliers, ma-
chines, équipements, sous-ensembles, pièces, etc.) à partir de terminaux disséminés dans
les bureaux techniques, ateliers, magasins et bureaux d’approvisionnement ».[3]
La gestion de maintenance assistée par ordinateur(GMAO) est une méthode de gestion
assistée d’un logiciel conçu pour assister aux services de maintenance dans une entreprise
dans leurs missions.
CHAPITRE 2. ETAT DE L’ART 9
2.3.1 Les fonctionnalités du système GMAO

L’outil GMAO se caractérise par cinq fonctionnalités standard :
1. Gestion des équipements : leurs caractéristiques, leurs dates d’installation , . . .
2. Gestion de la maintenance c’est-à-dire des interventions (préventives, curatives) sur
les équipements avec la génération des documents de gestion correspondants. Ces
documents peuvent être des fiches d’intervention, des contrats de maintenance,...
3. Gestion du personnel de maintenance : planning
4. Gestion des stocks de pièces de rechanges : contrôle des stocks en magasin.
5. Gestion des contrats de maintenance : consultation et édition des contrats
2.3.2 Les raisons à la mise en place d’une GMAO

• Connaissance complète des équipements : Pour réaliser une maintenance efficace il
jjjjhjjfaut avoir une bonne connaissance des équipements, la GMAO est une solution qui
jjjjhjjpermettra de centraliser toutes les informations sur les équipements en un référentiel
jjjjhjjunique.
jjjjj• Partage des connaissances : La GMAO assure un partage des connaissances entre les
jjjjhjjdifférentes équipes qui participent dans la maintenance.
jjjjj• Traçabilité des interventions : Pour assurer un suivi précis, ou pour le respect d’une
jjjjhjjnorme (audit, normes ISO, etc.), la traçabilité de l’information est aujourd’hui un
jjjjhjjélément clé, qu’apporte la GMAO.
jjjjj• Plan de maintenance : Dans tout domaine, il faut pouvoir prévoir et anticiper. La
jjjhjjjGMAO apporte une aide précieuse à l’aide d’un plan de maintenance préventif.Cu-
jjhjjjjmulé à un historique qui nous permettra de définir précisément tous les besoins.
jjjjj• Indicateurs divers : La GMAO vous permet d’obtenir très facilement des différents
jjjggjjindicateurs comme le taux préventif, MTTR, le taux de planification et le taux de
jjjjgjjréalisation.
jjjjj• Aide à l’amélioration du service : La GMAO apportera également une aide pour
jjjjgjjaméliorer la qualité du service de maintenance et assurer la meilleure productivité
jjjjggjjcomme par exemple :
— Mieux planifier les interventions curatives et préventives.
— Avoir une meilleure visibilité sur les ressources ce qui permettra de prendre de
meilleures décisions
2.4 Etude de l’existant

Il est important de mentionner que la direction de maintenance bâtiments et services
techniques de l’opérateur Ooredoo Tunisie a essayé de travailler avec des logiciels de GMAO
existants sur le marché.
2.4.1 Les solutions GMAO utilisés :

OptiMaint
jjjjj• Nom : OptiMaint
jjjjj• Editeur : Apisoft international
jjjjj• Avantages : Téléchargement gratuit de la version démonstration en ligne. Gestion du
jjjjjpatrimoine, des interventions, des achats, des stocks, de budget, de projets etc. . .
jjjjj• Ergonomie :Il s’interface avec les logiciels de GPAO, comptabilité, gestion commer-
jjjjjciale, achats, ERP, supervision. . . , et permet les échanges d’informations entre logiciels
jjjjjafin d’éviter des doubles saisies inutiles et sources d’erreurs.
jjjjj• Facilité d’utilisation : Simple à mettre en place et immédiatement opérationnel, il se
jjjjjcaractérise par une grande richesse fonctionnelle avec une facilité d’utilisation. Cepen-
jjjjjdant une formation des employés est proposée.
jjjjj• Cible : Adapté aux petites, moyennes et grandes entreprises.
jjjjjSon logo est représenté dans La figure suivante.[4]
Figure 2.2 – Logo OptiMaint
ManageMaint
jjjjj• Nom : ManageMaint
jjjjj• Editeur : AS-Informatique
jjjjj• Avantages : Gestion des actions préventives / correctives, gestion des stocks et jj-
jjjapprovisionnements, analyse des pannes, traitement statistiques
jjjjj• Ergonomie :Très bonne à en juger par les aperçus visibles sur le site.
jjjjj• Facilité d’utilisation : Très grande facilité et possibilité de paramétrages.
jjjjj• Cible : Adapté à tous type d’entreprises ayant de la maintenance à réaliser.
jjjjjSon logo est représenté dans La figure suivante.[5]
CHAPITRE 2. ETAT DE L’ART 11
Figure 2.3 – Logo ManageMaint
2.4.2 Critique de l’existant

• Gestion incomplète des équipements.
jjjjj• Les logiciels de la GMAO existants ne visent pas les domaines qui ont des caracté-
jjjjjjjristiques particulières ou les fonctionnalités offertes ne sont pas suffisantes pour gérer
jjjjjjjun établissement public ou privé.
jjjjj• L’informatique immédiate et instantanée est absente.
jjjjj• La gestion de budget se fait à travers des fichiers Excel et un logiciel d’analyse
jjjjj« QLIKVIEW »
jjjjj• L’absence de :
— L’historique.
— L’identification des équipements unique (la nomenclature).
— La création des interventions.
— Le calcul des indicateurs de performance.
— La gestion de stock pour les pièces de rechange.
— La notification par mail.
2.4.3 Choix méthodologique

La méthodologie est un procédé adopté afin de nous formaliser les étapes à suivre pour
le développement du projet et pour que ce dernier répond d’une manière efficace aux de-
mandes du client. Dans cette optique, nous avons choisi d’utiliser la méthodologie agile
"Scrum" au cours de notre projet.
Notre choix n’est pas au hasard car cette méthodologie choisie présente des avantages spé-
cifiques par rapport aux méthodes classiques. Dans ce contexte , nous citons les principales
avantages trouvés qui répondent aux nos objectifs souhaités :
— La flexibilité de cette méthode présente son principal avantage surtout la souplesse
avec laquelle elle supporte les changements apportés au projet et aux livrables en
cours de route, ce qui nous permet de produire la version «release» la plus adéquate
possible.
— Le second avantage de Scrum est l’amélioration de la productivité et le partage des
savoirs vu l’importance qu’il donne à l’échange des connaissances surtout lors des
mêlés quotidiennes.
— Le fait d’être basé sur trois unités de travail à la fois indépendantes dans l’exécution
de leurs tâches et inter-régissantes par le partage des savoirs, ce modèle de travail
permet de protéger l’équipe des développeurs des dérangements extérieures ce qui
nous permet de nous concentrer sur nos objectifs à atteindre.
2.4.4 Langages de modélisation

Pour modéliser les fonctionnalités que doit offrir notre système, représenter son ar-
chitecture ainsi que les interactions entre ses différents composants, nous avons choisi le
langage de modélisation unifié UML basé sur des diagrammes bien déterminés. Plusieurs
raisons nous ont conduits à adopter UML dans notre modélisation. En effet :
— Il a été normalisé par l’OMG, qui est une organisation internationale se chargeant
de la standardisation des technologies objets. Il s’agit d’un langage standard com-
préhensible par tout le monde.
— UML permet d’utiliser les principes et les concepts objet pour enrichir la phase de
la conception des systèmes.
— UML est indépendant du domaine d’application et des langages d’implémentation.
Nous avons utilisé pour ce fait la version 15 de l’outil "POWER AMC" vu qu’il
permet de modéliser des systèmes complexes sous un format graphique et textuel
simplifié et normalisé. [8]
Conclusion
Au cours de ce chapitre, nous avons commencé par présenter en premier lieu la
définition, les objectifs et le concept de la GMAO et en deuxième lieu nous avons
illustré l’étude et le critique de l’existant. Dans le chapitre suivant, nous allons
exposer la première étape de notre projet à savoir l’analyse et la spécification des
besoins.
Chapitre 3
Analyse et spécification des

besoins
Introduction
Ce chapitre présente l’étude des besoins qui constitue une phase d’analyse du projet.
Nous allons présenter tout d’abord, l’équipe SCRUM ainsi que les acteurs principaux
de l’application. Puis, nous allons présenter le Backlog de produit et la planification
des sprints. Ensuite, nous allons identifier les besoins fonctionnels et non fonction-
nels de l’application. Enfin, nous allons clôturer le chapitre par la modélisation du
diagramme de cas d’utilisation global du projet ainsi que sa description textuelle.
3.1 Les rôles de Scrum

L’équipe Scrum est constituée d’un propriétaire de produit, de l’équipe de déve-
loppement et d’un Scrum Master. Le modèle d’équipe de Scrum est conçu pour
optimiser la flexibilité, la créativité et la productivité. Nous allons tout d’abord ten-
ter de cerner notre équipe Scrum :
• Product Owner : Son rôle est d’assurer la présentation des caractéristiques
et des fonctionnalités du produit à développer et approbation du produit à
livrer.
• Scrum Master : Le Scrum Master assure globalement la Supervision de
l’avance ment du projet et des activités de l’équipe. Il assure également l’or-
ganisation des réunions et la bonne application de la méthode AGILE de par
ce biais.
• Equipe ou Team Members : Elle comporte une ou plusieurs personnes
qui se chargent de la réalisation des histoires utilisateurs et élaboration des
sprints.
13
14 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS
Dans notre cas, les rôles sont répartis comme suit :

Dans notre cas, les rôles sont répartis comme suit :
• Product Owner : Mr. Ahmed SAMAALI.
• Scrum Master : Mr. Ahmed SAMAALI. (Chef service maintenance bâti-
ment).
• Equipe ou Team Members : Mlle. Shayma ben ouahma.
3.2 Identifications des acteurs

Dans le cadre de notre analyse, les acteurs que nous avons pu identifier sont :
• Le chef d’équipe : qui est l’administrateur, il possède tous les droits
et privilèges.
• Le responsable maintenance : c’est l’acteur qui a pour rôle principale le
remplissage des formulaires concernant les équipements et les bâtiments.
• Le financier : c’est l’acteur chargé de la gestion de budget.
3.3 Identification des besoins

L’identification des besoins consiste à traduire les objectifs du projet en un ensemble
de fonctionnalités ciblées par l’outil à réaliser. Ceci procurera une compréhension
plus approfondie des tâches à mettre en œuvre.
3.3.1 Besoins fonctionnels

Besoin fonctionnel 1 : gestion du parc équipements
Effectuer les opérations de gestion telle que l’ajout selon une nomenclature spéci-
fique,la modification, la suppression et la consultation des informations caractérisant
chaque équipement.
Besoin fonctionnel 2 : gestion de stock

Effectuer la gestion des équipements et les pièces de rechanges entrants et sortants.
Besoin fonctionnel 3 : gestion des interventions

Le responsable de maintenance peut gérer les informations des interventions pré-
ventive et curative qu’il a effectuées et mettre à jour l’avancement de son travail.
Besoin fonctionnel 4 : gestion des contrats

Effectuer la gestion des contrats.
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 15
Besoin fonctionnel 5 : gestion des fournisseurs

Effectuer la gestion des fournisseurs.
Besoin fonctionnel 6 : gestion de budget

Affectation de toutes les dépenses en suivant le budget.
Besoin fonctionnel 7 : consultation des indicateurs de performance
— Consulter le MTTR.
— Consulter le taux préventif.
— Consulter le taux réalisation.
— Consulter le taux planification.
Besoin fonctionnel 8 : notification par mail

Comme les alertes sont les plus impactant, l’application doit alerter les responsables
de la maintenance des alertes menés pour qu’il puisse se rendre des éventuels impacts
et ressources indisponibles.
— Les alertes de manque de stock.
— Les alertes des équipements hors service.
— Les alertes avant le dépassement des plannings.
— Les alertes avant le dépassement des contrats.
3.3.2 Besoins non fonctionnels

Ce sont les besoins techniques décrivant toutes les contraintes auxquelles est soumis
le système pour sa réalisation et son bon fonctionnement. La nature du notre projet
exige certaines règles à respecter.
Pour cela l’ensemble des extensions à réaliser doivent respecter les besoins suivants :
• Ergonomie de l’interface : L’interface de notre application doit être
ergonomique et conviviale. Aussi, elle doit être accessible par tous les uti-
lisateurs, quelles que soient leurs caractéristiques et leurs moyens d’accès à
l’information.
• Fiabilité : Les résultats apportés par l’application doivent être fiables et
reflètent effectivement l’état de la base au moment de son interrogation,
c’est-à-dire lors de la mise à jour des données.
• Disponibilité : Notre application doit être disponible à tout instant pour
être utilisée par n’importe quel utilisateur, et doit être facilement accessible
via n’importe quel ordinateur.
• Sécurité : Notre application comporte des informations personnelles et
sensibles, elle doit respecter les règles relatives à la sécurité des systèmes
informatiques. Nous devons avoir un système d’accès sécurisé qui se base

sur l’authentification et le cryptage des mots de passe.
3.4 Backlog produit

Le Backlog de produit correspond à une liste priorisée des besoins et des exigences
du client. Les éléments du Backlog de produit, appelé aussi les histoires utilisateurs,
sont formulés en une ou deux phrases décrivant de manière claire et précises la fonc-
tionnalité désirée par le client, généralement, écrit sous la forme suivante « En tant
que X, je veux Y, afin de Z ».
Le Backlog de produit présenté dans le tableau 1 comprend les champs suivants :
• ID : C’est un nombre unique et auto-incrémenté pour chaque histoire utilisateur.
• Title : C’est le résumé du User Story.
• User Story : C’est une description courte de la tâche à réaliser et qui se définit
de la manière suivante : En tant que «rôle», nous souhaitons «faire quelque chose»
afin de «obtenir de la valeur».
• Priorité : C’est la valeur métier qui dirige la priorisation du développement des
histoires utilisateurs suivant les attentes et les besoins du client, allant de 0 à 100.
• Story point : Evaluation initiale de la charge de travail nécessaire pour l’implé-
mentation de cette tâche. L’unité est en jours.
ID Title User Story Priorité Story

point
1 Authentification En tant que client privé, je souhaite 100 14
et Gestion des m’authentifier à tout moment. Afin de
comptes pouvoir accéder à mon espace.
2 Gestion des uti- En tant qu’administrateur, je peux 100 25
lisateurs ajouter, modifier, supprimer un utilisa-
teur et gérer les droits d’accès.
3 Gestion des En tant qu’utilisateur, je peux gérer les 70 25
fournisseurs fournisseurs, les secteurs, les bâtiments,
les domaines, les gammes d’interven-
tions.
4 Créer la base de En tant qu’utilisateur, je peux créer 90 55
données pour le une base de données avec une nomen-
parc des équipe- clature spécifique des équipements.
ments
5 Gérer le stock En tant qu’utilisateur, je peux gérer les 80 25
stocks entrant et sortant.
6 Gérer les inter- En tant qu’utilisateur, je peux gérer les 80 35

vention intervention pour les equipement et les
bâtiments.
7 Gérer les bud- En tant que financier , je peux gérer le 80 25
gets budget.
8 Gérer les plan- En tant qu’administrateur, je peux gé- 80 35
nings de mainte- rer les plannings de maintenance.
nance
9 Gérer les En tant qu’utilisateur, je peux gérer les 70 25
contrats contrats de maintenance.
10 Consulter les En tant qu’utilisateur, je peux consul- 80 25
KPI ter le MTTR, le taux préventif, le taux
de réalisation et le taux de planifica-
tion.
11 Gérer les alertes En tant qu’administrateur, je peux gé- 90 30
par mail rer les alerte de manque de stock, les
alertes avant le dépassement des plan-
nings, les alertes avant le dépassement
des contrats et des alertes pour les équi-
pements hors service.
Table 3.1 – Backlog du produit relatif à notre application
3.5 Planification des sprints

La réunion de planification des sprints est l’événement le plus important dans Scrum.
Le but de cette réunion est de préparer le planning de travail et d’identifier le ba-
cklog des sprints. L’un des produits de cette réunion est le choix de la durée des
sprints et qui diffère selon la complexité du projet et la taille de l’équipe.
Nom du Sprint Date de début Date de fin

Sprint 0 : Mise en place de l’environnement de travail 05/02/2018 20/02/2018
Sprint 1 : Gestion des arborescences 25/02/2018 30/03/2018
Sprint 2 : Gestion des articles 02/04/2018 28/05/2018
Sprint 3 : Gestion des stocks 03/05/2018 20/06/2018
Sprint 4 : Gestion de parc équipement 23/06/2018 20/07/2018
Sprint 5 : Gestion de budget 25/07/2018 30/08/2018
Table 3.2 – Planification des Sprints
3.6 Modélisation des besoins fonctionnels

Une étude approfondie des besoins fonctionnels, s’avère indispensable avant d’enta-
mer la conception afin d’obtenir, d’une manière plus formelle, une vue globale sur les
exigences de notre application. Cette partie présente alors une modélisation des be-
soins en faisant recours aux concepts fondamentaux d’UML, à savoir le diagramme
de cas d’utilisation.
3.6.1 Diagramme des cas d’utilisation global

Un cas d’utilisation est une abstraction d’une partie du comportement du système
par une instance d’un acteur. Pour l’acteur identifié, il convient de rechercher les
différents profils métier selon lesquels il utilise le système et de les modéliser en
utilisant une notation simple et compréhensible par tous. C’est pour cette raison que
nous allons présenter, sous forme des cas d’utilisation, l’ensemble de fonctionnalités
offertes par le système pour nos acteur.
Figure 3.1 – Diagramme de Cas d’utilisation global

Conclusion
Dans ce chapitre, nous avons passé en revue les différents besoins exprimés pour la
réalisation du projet. Ce qui nous a permis de définir la spécification fonctionnelle
et non fonctionnelle du système visé, ce qui a procuré une vision plus claire du sujet
et une compréhension plus profonde des tâches à réaliser et nous avons planifié la
réalisation des différents Sprints. Nous allons aborder dans le prochain chapitre une
étude détaillée de la conception de l’application.
Chapitre 4
Etude Conceptuelle
Introduction
Après avoir achevé l’étape d’analyse et spécification des besoins, nous allons entamer
dans ce chapitre la partie conception de notre solution.
Nous allons présenter en détails la conception du projet à travers les diagrammes
UML suivants : les diagramme des paquetages,les diagramme des classes, et les
diagrammes de séquence,
4.1 Description des diagrammes

4.1.1 Diagramme des paquetages
Les diagrammes de paquetages sont la représentation graphique des relations exis-
tant entre les paquetages composant un système, dans le langage Unified Modeling
Language (UML).
4.1.2 Diagramme de classes

Le diagramme de classes est généralement considéré comme le plus important dans
un développement orienté objet. Il représente l’architecture conceptuelle du sys-
tème : il décrit les classes que le système utilise, ainsi que leurs liens.
4.1.3 Diagramme de séquences

Le diagramme de séquences représente la succession chronologique des opérations et
des interactions entre les objets du système.Chaque message transitant sur un lien
est symbolisé par une flèche porteuse d’une expression. La lecture se fait de haut en
bas, et l’ordre chronologique doit respecter ce sens.
20
CHAPITRE 4. ETUDE CONCEPTUELLE 21
4.2 Conception
4.2.1 Vue statique
Cette partie met l’accent sur la structure statique du système à l’aide d’objets,
attributs, opérations et relations. Cette partie inclut le diagramme de classes et le
diagramme de paquetages.
4.2.1.1 Diagramme de paquetages

Nous allons présenter le diagramme de paquetages dans la figure ci-dessous.
Figure 4.1 – Diagramme de paquetages du GMAO

22 CHAPITRE 4. ETUDE CONCEPTUELLE
Pour bien comprendre le diagramme de paquetages on va détailler chaque package.
Package Batiment
la figures 4.2 présentes le diagramme de classe pour le module Batiment.
Figure 4.2 – Diagramme de classes pour Batiment
— Un secteur contient plusieurs bâtiments.

— Chaque bâtiment peut avoir une ou plusieurs interventions bâtiment.
— Un bâtiment peut être planifié et affiché dans le planning Batiment.
— Le type d’une intervention bâtiment peut être «Curative», «Préventive» ou
«Améliorative».
Package Article
la figures 4.3 présentes le diagramme de classe pour le module Article.
Figure 4.3 – Diagramme de classes pour Article
— Un article peut avoir un ou seul type.

— Un article peut avoir une seule référence.
— Un article peut avoir une seule marque.
— Un article peut avoir un seul domaine.
— Un article est stocké dans un ou plusieurs magasins.
— Le type d’un article peut être «Equipement» ou «Pièce de rechange».
Package Equipement
la figures 4.4 présentes le diagramme de classe pour le module Equipement.
Figure 4.4 – Diagramme de classes pour Equipement
— Un équipement peut avoir un ou plusieurs interventions équipement.

— Un ou plusieurs plannings équipement peuvent être affectés à un seul equipe-
ment.
— Une ou plusieurs pièce peut appartenir à une seule intervention équipement.
— Une gamme intervention peut appartenir à une seule intervention équipement.
— Le type d’une interventionEquipement peut être «Curative» ou «Préventive».
Package Stock
la figures 4.5 présentes le diagramme de classe pour le module Stock.

jhgggggggggggggggg
jhgggggggggggggggg
Figure 4.5 – Diagramme de classes pour Stock
— Le stock peut contenir une ou plusieurs fiches stocks entrants.

— Le stock peut contenir une ou plusieurs fiches stocks sortants.
Package Budget
la figures 4.6 présentes le diagramme de classe pour le module Budget.

jhgggggggggggggggg
jhgggggggggggggggg
Figure 4.6 – Diagramme de classes pour Budget
— Un budget peut être demandé par un ou plusieurs utilisateurs.

— Un utilisateur peut demander une ou plusieurs demandes.
— Le type d’un budget peut être «OPEX piece», «OPEX Contrat»,«CAPEX Clim»,
«CAPEX Elec», ou «CAPEX Bâtiment».
4.2.1.2 Diagramme de classes général
Figure 4.7 – Diagramme de classes général

4.2.2 Vue fonctionnelle

4.2.2.1 Diagramme des cas d’utilisation
Dans cette partie nous présentons le cas d’utilisation «Gérer parc équipement»
Figure 4.8 – Diagramme de cas d’utilisation «Gérer parc équipement»
La description textuelle du cas d’utilisation «Gérer parc équipement».

Titre : Gérer parc équipement
Acteur : Responsable maintenance, chef d’équipe
Résumer : Ce cas d’utilisation permet à l’utilisateur d’installer un nouvel équipe-
ment .
Pré-condition : L’utilisateur doit s’authentifier.
1- Après avoir consulté la liste des équipements, La GMAO apporte la fiche de

l’utilisateur demande la page de la fiche de l’installation.
l’installation d’un équipement.
2- L’utilisateur saisit les informations
nécessaires qui concerne l’ équipement en
question. Il doit définir son code article , La GMAO affecte à l’équipement
sa marque , son domaine , son emplacement, installé un code et enregistre la fiche .
la date de l’installation, et d’autres informations.
Après, il doit valider l’ajout .
3 - L’utilisateur consulte la liste

des fiches des equipements installés.
Table 4.1 – Description textuelle du cas d’utilisation «Gérer parc équipement»
Scénarios alternatives :
1- L’utilisateur annule la création de la fiche.
2- L’utilisateur modifie la fiche.
3- L’utilisateur imprime la fiche.
4- L’utilisateur supprime la fiche.
5- L’utilisateur quitte la consultation des fiches.
Post-condition :
L’ajout, la modification ou la suppression d’une nouvelle fiche.
1- Après avoir consulté la liste des équipement, La GMAO apporte le fiche de

l’utilisateur demande la page de la fiche de l’installation.
l’installation d’un équipement.
nécessaires qui concerne l’ équipement en
question. Il doit définir son code article , La GMAO affecte à l’équipement
sa marque , son domaine , son emplacement, installé un code et enregistre la fiche .
la date de l’installation, et d’autres informations.
Après il doit valider l’ajout .
3 - L’utilisateur consulte la liste

des fiches des equipements installés.
Table 4.2 – Description textuelle du cas d’utilisation «Gérer parc équipement»
1- L’utilisateur annule la création de la fiche.
5- L’utilisateur consulte la fiche.
3- L’utilisateur imprime la fiche.
4- L’utilisateur supprime la fiche.
5- L’utilisateur quitte la consultation des fiches.
Post-condition :
L’ajout, la modification ou la suppression d’une nouvelle fiche.
La description textuelle du cas d’utilisation « Gérer les interventions équipement».
Titre : Gérer les interventions équipement

Résumer Ce cas d’utilisation permet à l’utilisateur d’écrire l’intervention d’un équi-
pement spécifique.
Pré-condition : L’équipement doit être installé.
1- Après avoir consulté la liste des

équipements installés, l’utilisateur choisi La GMAO apporte le formulaire de
un équipement et demande la page de la l’ajout d’une nouvelle intervention.
création d’une nouvelle intervention.

nécessaires qui concerne le l’équipement La GMAO enregistre la nouvelle
en question. Il doit définir les details de intervention.
l’intervention.
3 - L’utilisateur consulte la liste des intervention.

La GMAO apporte le formulaire de l’ajout
Il demande le formulaire de l’ajout d’une piece
d’un nouvelle piece de rechange.
de rechange si nécessaire.
Table 4.3 – Description textuelle du cas d’utilisation «Gérer les interventions équipement»
1- L’utilisateur annule l’ajout de l’intervention.
2- L’utilisateur modifie une intervention.
3- L’utilisateur supprime une intervention.
4- L’utilisateur annule l’ajout de la piece de rechange.
5- L’utilisateur modifie la piece de rechange.
6- L’utilisateur supprime la piece de rechange.
7- L’utilisateur quitte la consultation des interventions.
Scénario d’erreur :
la suppression de l’intervention n’est pas effectuée et un message d’erreur s’affiche
(cas de jointure).
Post-condition :
L’ajout, la modification ou la suppression d’une intervention.
La description textuelle du cas d’utilisation «Gérer planning équipement».
Titre : Gérer planning équipement

Acteur : Chef d’équipe
Résumer Ce cas d’utilisation permet le chef d’équipe d’affecter des taches aux res-
ponsables de maintenance.
1- Après avoir consulté la liste des

équipements installés, le chef d’équipe La GMAO apporte le formulaire de
choisi un équipement et demande la page l’ajout d’un nouveau planning.
de la création d’un nouveau planning.
2 - Le chef d’équipe saisit les informations

La GMAO enregistre le planning et envoi
nécessaires qui concerne le l’équipement
par E-mail une notification à l’intervenant
en question.
affecté.
Il doit définir les details de l’intervention.
3 - Le chef d’équipe consulte le planning.
Table 4.4 – Description textuelle du cas d’utilisation «Gérer les plannings équipement»
1- Le chef d’équipe annule l’affectation de planning.
2- Le chef d’équipe modifie un planning.
3- Le chef d’équipe supprime un planning.
4- Le chef d’équipe quitte la consultation de planning.
Post-condition :
L’ajout, la modification ou la suppression d’un planning.
La description textuelle du cas d’utilisation «Changer etat équipement»

Titre : Changer etat équipement
Résumer : Ce cas d’utilisation permet à l’utilisateur de changer l’état d’un équi-

pement choisi.
1- Après avoir consulté la liste des équipement, La GMAO enregistre la modification de

l’utilisateur modifie l’état d’un équipement l’état
choisi.
2- L’utilisateur consulte la liste des equipements .
1- L’utilisateur annule le changement de l’état.
2- L’utilisateur quitte la consultation de la liste des equipements.
Post-condition :
La modification de l’état de l’equiepement.
Dans cette partie nous présentons le cas d’utilisation «Gérer l’arborescence»
Figure 4.9 – Diagramme de cas d’utilisation «Gérer les bâtiments»»
La description textuelle du cas d’utilisation «Gérer les bâtiments».

Titre : Gérer les bâtiments
Résumer :Ce cas d’utilisation permet à l’utilisateur de créer un bâtiment pour un
secteur spécifique.
Pré-condition : Un secteur doit être crée.
1- Après avoir consulté la liste des secteur,

l’utilisateur demande la page qui affiche la liste
La GMAO affiche la liste des bâtiments.
des bâtiments.
La GMAO apporte le formulaire de

2 - L’utilisateur demande la page de la
l’ajout d’un nouveau bâtiment.
création d’un nouveau bâtiment.
3 - L’utilisateur saisit les informations

nécessaires qui concerne le bâtiment
en question. Il doit définir sa désignation,
La GMAO enregistre le nouveau bâtiment.
sa description, sa surface, le responsable ..
Après il doit valider l’ajout
4 - L’utilisateur onsulte la liste des bâtiments.
1- L’utilisateur annule la création d’un nouveau bâtiment.
2- L’utilisateur modifie le bâtiment.
3- L’utilisateur supprime le bâtiment.
4- L’utilisateur quitte la consultation de la liste des bâtiments Post-condition :
L’ajout, la modification ou la suppression d’un bâtiment.
Remarque : Les scenarios des cas d’utilisation « Gérer les secteurs », « Gérer les
domaines » sont les mêmes comme le scénario « Gérer les bâtiments », Les scenarios
des cas d’utilisation « Gérer les interventions bâtiment» et « Gérer les plannings
bâtiment » sont les mêmes comme «Gérer les interventions equipement» et « Gérer
les plannings equipement »
Dans cette partie nous présentons le cas d’utilisation «Gérer les articles»
Figure 4.10 – Diagramme de cas d’utilisation «Gérer les articles»
La description textuelle du cas d’utilisation «Gérer les articles».

Titre : Gérer les articles
Résumer : Ce cas d’utilisation permet à l’utilisateur d’ajouter un nouvel article .
Pré-condition :Un domaine, un type, un magasin, une référence et une marque
doivent être créé.
1- Après avoir consulté la liste des articles, La GMAO apporte le formulaire de

l’utilisateur demande la page de la création l’ajout d’un nouvel article.
des articles.
nécessaires qui concerne l’article en question.
Il doit définir son type, son domaine, sa marque, La GMAO enregistre l’article avec un
sa référence , son catégorie, sa designation et code selon une nomencalteure spécifique.
sa description et son magasin de stockage.
Table 4.7 – Description textuelle du cas d’utilisation «Gérer les articles»

1- L’utilisateur annule la création de l’article.
2- L’utilisateur modifie l’article.
3- L’utilisateur supprime l’article.
4- L’utilisateur quitte la consultation des articles.
Post-condition :
L’ajout, la modification ou la suppression d’un nouvel article.
Remarque : Les scenarios sont les mêmes pour les cas d’utilisation « Gérer les
types », « Gérer les magasins » et « Gérer les références ».
Dans cette partie nous présentons le cas d’utilisation «Gérer le stock»
Figure 4.11 – Diagramme de cas d’utilisation «Gérer le stock»
La description textuelle du cas d’utilisation «Gérer le stock entrant».

Titre : Gérer le stock entrant
Résumer : Ce cas d’utilisation permet à l’utilisateur de déclarer les articles entrants.
Pré-condition Un article doit être créé.
1- Après avoir consulté la liste articles entrants, La GMAO apporte le formulaire de

l’utilisateur demande la page de la création la fiche.
d’une fiche pour déclarer le nouveau article.
La GMAO enregistre l’article et
incérémente dans la base de données
Il doit définir son code article, le fournisseur,
et ajoute automatiquement la date
le prix unitaire , sa référence..
d’entrée.
Table 4.8 – Description textuelle du cas d’utilisation «Gérer le stock entrant»
1- L’utilisateur annule la crétion de la fiche d’entrée de l’article.
2- L’utilisateur modifie la fiche d’entrée.
3- L’utilisateur supprime la fiche d’entrée.
4- L’utilisateur quitte la consultation de l’historique des articles entrants.
Post-condition :
L’ajout d’une fiche d’entrée d’un article.
La description textuelle du cas d’utilisation «Gérer le stock sortant».

Titre : Gérer le stock sortant
Résumer : Ce cas d’utilisation permet à l’utilisateur de déclarer les articles sortants.
Pré-condition : L’article doit existe dans le stock.
La GMAO apporte le formulaire de

1- L’l’utilisateur demande la page de la création
la fiche.
d’une fiche pour déclarer la sortie de l’article.

La GMAO enregistre l’article et
décrémente dans la base de données
Il doit définir son code article, le bâtiment,
et ajoute automatiquement la date
sa désignation , sa référence et la quantié sortie.
de sortie.
Table 4.9 – Description textuelle du cas d’utilisation «Gérer le stock sortant»

1- L’utilisateur annule la crétion de la fiche de sorite de l’article.
2- L’utilisateur modifie la fiche de sortie.
3- L’utilisateur supprime la fiche de sortie.
4- L’utilisateur quitte la consultation de l’historique des articles sortants.
Post-condition :
L’ajout d’une fiche de sortie d’un article.
Dans cette partie nous présentons le cas d’utilisation «Gérer le budget»
Figure 4.12 – Diagramme de cas d’utilisation «Gérer le budget»
La description textuelle du cas d’utilisation «Gérer le stock entrant».

Titre : Gérer le budget
Acteur : Responsable financier, chef d’équipe
Résumer : Ce cas d’utilisation permet à l’utilisateur de Gérer le budget.
Pré-condition : L’utilisateur doit s’authentifier.
1- l’utilisateur demande la page de la création La GMAO apporte le formulaire.

d’un nouveau budget.
nécessaires pour définir le budget.
Il doit définir son type, sa description, La GMAO enregistre l’ajout de budget.
et le budget,
3- L’utilisateur demande la page de la création La GMAO apporte le formulaire de la

d’une demande budget. demande.

nécessaires pour la demande budget. La GMAO enlever le montant du budget
Il doit définir le demandeur, le montant et total et ajoute la date de
une description, la demande.
Table 4.10 – Description textuelle du cas d’utilisation «Gérer le stock entrant»
1- L’utilisateur annule la création d’un nouveau budget.
2- L’utilisateur modifie le budget.
3- L’utilisateur supprime le budget.
4- L’utilisateur quitte la page de la consultation des budgets.
6- L’utilisateur annule la création d’une nouvelle demande budget.
7- L’utilisateur modifie la demande.
8- L’utilisateur supprime la demande.
9- L’utilisateur consulte la page de la demande budget.
Post-condition :
L’ajout d’un nouveau budget ou d’une demande budget.
4.2.2.2 Diagramme de séquence
Dans cette partie on va présenter quelque diagrammes de séquence pour comprendre

les interactions entre les acteurs et le système.
La figure 4.12 montre le diagramme de séquence « Créer une nouvelle intervention».
Figure 4.13 – Diagramme de séquence «Créer une nouvelle intervention»
Le responsable de maintenance ou le chef d’équipe, demande la liste des équipements

installés dans le parc, une fois la liste est affiché, il doit choisir un équipement
pour écrire une intervention, le système affiche un formulaire, il doit le remplir en
spécifiant les informations nécessaires pour l’équipement en question, il doit insérer
la société, préciser le type de l’intervention curative ou préventive, le coût et la
description, la date début et la date fin de l’intervention. Une fois terminé l’insertion
il doit confirmer l’enregistrement de formulaire mais si il a utilisé une pièce de
rechange il doit demander le formulaire qui ajoute les pièces de rechange utilisé.
La figure 4.13 montre le diagramme de séquence « Changement etat equipement».
Figure 4.14 – Diagramme de séquence « Changer etat equipement »

installés dans le parc, une fois la liste est affiché, il doit choisir un équipement pour
changer son etat.
La figure 4.14 montre le diagramme de séquence « Créer un nouveau planning in-

tervention».
Figure 4.15 – Diagramme de séquence « Créer un nouveau planning intervention »

installés dans le parc, une fois la liste est affiché , il doit choisir un équipement
pour lui affecter un planning, le systeme affiche un formulaire, il doit le remplir en
spécifiant les informations necessaires pour le planning, il doit insérerla societe, et
l’intervenant, la date prévue et le travail demandé.
Conclusion
Au cours de ce chapitre, nous avons présenté les diagrammes de classes, de cas d’uti-
lisations et quelques diagrammes de séquences. La phase de conception est terminée,
nous sommes prêts à entamer la réalisation de notre projet, cette implémentation
sera détaillée dans le prochain chapitre.
Chapitre 5
Réalisation et test
Introduction
Ce chapitre constitue le dernier volet de ce rapport, il traite la phase qui a pour
objectif l’implémentation de notre application. Nous commençons, tout d’abord, par
la description de l’environnement matériel et logiciel utilisés pour développer notre
solution.
5.1 Environnement du travail

La création d’une application web implique l’utilisation des différentes technologies
et outils, que ce soit pour la manipulation de la base de données, des opérations (côté
serveur et côté client), ou bien pour la gestion et l’affichage des données provenant
du serveur. Avant de commencer un nouveau projet, tous ces outils ainsi que la
structure du projet doivent être mis en place. Pour ce fait, la phase de la réalisation
de notre application est débutée par l’installation du "Symfony 2.8".
5.1.1 Environnement matériel

Lors de la création d’une application informatique, le choix des outils est une étape
non arbitraire, bien au contraire, elle doit faire l’objet de réflexion. Dans ce qui suit,
nous mettons l’accent sur l’environnement matériel et logiciel utilisé pour Au cours
du développement de notre projet nous avons utilisé un ordinateur portable ASUS
ayant comme configuration :
— Un système d’exploitation Windows 7
43
44 CHAPITRE 5. RÉALISATION ET TEST
— Un processeur Intel(R) Core(TM) i7 CPU @ 2.4GHz, un disque dur de 500 Go

et Une mémoire vive de 8 Go
5.1.2 Environnement de développement

Avant de déclencher l’étape de développement, il faut passer par une partie primor-
diale, qui entraine la configuration des environnements matériels ainsi que logiciels.
Nous présentons les différentes technologies et les langages nécessaires pour la mise
en œuvre du projet.
Notre application est une application web et pour générer des pages web statiques,
il faut passer par deux langages incontournables qui sont HTML5 et CSS3.
• HTML : Est un langage dit de « structuration » ou de « balisage ». L’acronyme

signifie HYPERTEXT MARKUP LANGUAGE, ce qui signifie en français « langage
de balisage d’hypertexte » dont le rôle est de formaliser l’écriture d’un document
avec des balises de formatage. Les balises permettent d’indiquer la façon dont doit
être présenté le document et les liens qu’il établit avec d’autres documents. [11]
• CSS : Est l’acronyme de CASCADING STYLE SHEETS, est un langage de

style qui définit la présentation des documents HTML. Il permet aux concepteurs
de contrôler l’apparence et la disposition de leurs pages web.[12]
Figure 5.1 – Logo «HTML5» et «CSS3»
• Bootstrap : est framework HTML, CSS et JavaScript créé par des développeurs
de Twitter en 2010. Il permet de créer facilement le design d’un site tout en assurant
que celui-ci soit responsive. Son logo s’est affiché dans la figure suivante.[13]
Figure 5.2 – Logo « Bootstrap»

CHAPITRE 5. RÉALISATION ET TEST 45
Nous avons utilisé ces deux langages pour concevoir la partie statique de l’applica-
tion : l’interface principale et les différentes sections qu’elle affiche. Et pour la partie
dynamique Nous avons choisi le Symfony 2.8 comme langage de programmation qui
répondra bien aux besoins d’implémentation de notre application.
• Symfony :«Symfony est un ensemble de composants PHP, un framework d’ap-

plications Web, une philosophie et une communauté - tous travaillant en harmonie.
».[15]
Figure 5.3 – Logo « Symfony»
• PHP : Est un langage de développement web qui génère des pages web dyna-
miques. Le terme PHP est un acronyme récursif de " HYPERTEXT PREPROCES-
SOR". PHP peut également fonctionner comme n’importe quel langage interprété
de façon locale.[12]
Figure 5.4 – Logo « PHP»
• Twig : est un moteur de template php dans la même lignée que smarty et direc-
tement intégré dans Symfony2. Très puissant, twig permettra de gérer de l’héritage
entre templates, séparer les couches de présentation et métiers. Son logo s’est affiché
dans la figure suivante[16]
Figure 5.5 – Logo « Twig»

Pour permettre le stockage des données afin d’être traitées calculées et générées par
le système, il me faut un système de gestion de base de données appelé SGBD. Pour
cela, nous avons utilisé MySQL.
• MySQL : Est un Système de Gestion de Base de Données (SGBD) parmi les plus
populaires au monde. MySQL est un serveur de base de données relationnelles SQL
qui fonctionne sur de nombreux systèmes d’exploitation (dont Linux, Mac OS X,
Windows, Solaris, Free BSD. . . ) et qui est accessible en écriture par de nombreux
langages de programmation, incluant notamment PHP, Java, Ruby, C. [14]
Figure 5.6 – Logo « MySQL»
Pour le mappage des objets et la génération automatique de la base de données nous

avons utilisé qui est Doctrine est l’ORM par défaut du framework Symfony.
• Doctrine : est l’un des ORM (object-relational mapping) les plus connus qui
existent actuellement.Il est utilisé dans des frameworks très connus (symfony, Zend
Framework), et il est aussi simple à prendre en main et puissant. Son logo est
présenté dans la figure suivante[17]
Figure 5.7 – Logo « Doctrine»
Il nous faut aussi un outil qui pourra générer les pages web. C’est bien le rôle
d’APACHE.
• APACHE : C’est ce qu’on appelle un serveur web. Il s’agit du plus important
de tous les programmes, car c’est lui qui est chargé de délivrer les pages web aux
visiteurs. [15]
Figure 5.8 – Logo « APACHE»

Pour assurer le bon déroulement de notre application, nous avons choisi un paque-
tage Windows qui englobe tous ces outils appelé WAMP Server.
• WampServer : C’est une plate-forme de développement Web sous Windows

pour des applications Web dynamiques à l’aide du serveur Apache, du langage de
script (scripts) PHP et d’une base de données MySQL. Il possède également une
interface graphique appelée PHPMyAdmin qui permet de gérer plus facilement la
base de données. [10]
Figure 5.9 – Logo « WampServer»
Enfin, une fois tous ces outils sont bien installés, il nous faut un moyen pour écrire
nos scripts. Pour cela, nous avons choisi NetBeans.
• NetBeans : est un environnement de développement intégré gratuit et open source

pour le développement d’applications sur les systèmes d’exploitation Windows, Mac,
Linux et Solaris. L’IDE simplifie le développement d’applications Web, entreprises,
bureautiques et mobiles qui utilisent les plates-formes Java et HTML5. L’IDE offre
également un support pour le développement d’applications PHP et C / C ++.
Son logo est représenté dans La figure suivante.[18]
Figure 5.10 – Logo « Netbeans »
5.1.3 Architecture de l’application

Le framework Symfony 2.8 est construit sur la base d’une architecture MVC (Modèle
/ Vue / Contrôleur) comme nous indique la figure suivante. Les interactions avec
la base des données et le développement du code métier sont gérés par la partie
Modèle. Le contrôleur est responsable de la logique de contrôle de l’application.[19]
Figure 5.11 – Architecture «MVC»
5.2 Réalisation
Dans cette partie, je vais exposer quelques scénarios d’exécution à travers des cap-
tures d’écran.
la figure 5.12 represente la page d’authentification. C’est la première interface qui
s’affiche pour l’utilisateur. Ce dernier doit saisir son login et son mot de passe pour
pouvoir accéder à l’application. Les identifiants de l’utilisateur seront par la suite
vérifiés par le système.
Figure 5.12 – Interface "Authentification"
la figure 5.13 presente la page d’acceuil.
À travers cette interface, l’utilisateur peut consulter les KPI.
Figure 5.13 – Interface "Dashboard"

Figure 5.14 – Interface "Gestion du parc equipement"
À travers cette interface, l’utilisateur peut consulter, ajouter, modifier ou supprimer

un equipement dans le parc equipement. l’utilisateur doit cliquer sur le bouton nou-
veau pour ajouter, cliquer sur le details pour afficher son details, cliquer sur liste des
interventions pour voir la liste des interventions, cliquer sur affecter pour affecter
un intervenant à cet equipement. Avec cette interface on peut modifier aussi, l’uti-
lisateur clique sur l’icone editer , et on peut aussi supprimer en cliquant sur l’icone
supprimer.
Figure 5.15 – Interface "Consulter fiche equipement"
À travers cette interface, l’utilisateur peut consulter et imprimer la fiche equipement.

Figure 5.16 – Interface "Gestion des interventions"
À travers cette interface, l’utilisateur peut consulter, ajouter, modifier ou suppri-

mer une intervention. Il doit cliquer sur le bouton nouveau pour ajouter, cliquer sur
l’icône édite pour éditer, cliquer sur l’icône supprime pour supprimer. Avec cette
interface aussi on peut consulter les pièces de rechange et les modifier.
Figure 5.17 – Interface "Gestion des contrats de maintenance"
À travers cette interface, l’utilisateur peut consulter , ajouter et imprimer les contrats
de maintenance.
Figure 5.18 – Interface "Créer le planning de maintenance"
À travers cette interface, l’utilisateur doit remplir le formulaire pour affecter les
tâches à des intervenants .
Figure 5.19 – Interface "Consulter la liste des interventions"
À travers cette interface, l’utilisateur permet d’afficher la liste des interventions, une
fois affiché il peut imprimer la liste.
Figure 5.20 – Interface "Imprimer fiche intervention"
À travers cette interface, l’utilisateur imprime la liste des interventions.
Figure 5.21 – Interface "Consulter le stock"
À travers cette interface, l’utilisateur peut consulter la liste des articles en stock.
une fois affiché, il peut imprimer la liste.
Figure 5.22 – Interface "Gérer le budget"
À travers cette interface, l’utilisateur peut consulter, ajouter, modifier ou supprimer

un budget. Il doit cliquer sur le bouton nouveau pour ajouter un budget et remplir le
formulaire puis enregistrer, Il peut aussi cliquer sur l’icône édite pour éditer, cliquer
sur l’icône supprime pour supprimer. Avec cette interface aussi on peut ajouter,
modifier ou supprimer une demande budget et consulter les la liste des demandes
et imprimer la liste.
5.3 Test
Cette partie est très importante pour les applications web vu que la performance
joue un rôle décisif. Le test est une recherche d’anomalie dans le comportement de
logiciel. C’est une activité paradoxale : il vaut mieux que ce ne soit pas la même
personne qui développe et qui teste l’application développée.
Les principales familles de test :
• Tests unitaire : Ils sont les premiers tests soumis au logiciel cible les composants
élémentaires de l’application à tester.
• Tests d’intégration : La seconde phase de test, les tests d’intégration qui ont pour
but de tester l’application de manière ensembliste. Il correspond à la phase d’inté-
gration progressive des différents composants élémentaires qui ont déjà passés avec
succès l’épreuve des tests unitaires. L’objectif est de mettre en évidence les dysfonc-
tionnements engendrés par leur assemblage.
• Tests fonctionnels : Ils ont pour but de vérifier la conformité de l’application
développée avec le cahier des charges initial. Ils sont basés sur les spécifications
fonctionnelles et techniques.
• Tests système : Ils s’applique à la version complète de l’application déployée dans
son environnement d’exécution, il permet la détections des fautes ou des comporte-
ments incorrects de l’ensemble du système en situation réelle.
Après avoir établi ces phases de test au niveau local et on prenant en considération
que l’application a été intégrée est déja testée et validée, la GMAO a été testé et
tous les résultats étaient relativement concluants
5.4 Conclusion
A ce stade, notre projet d’études atteint sa fin. Tout au long de ce chapitre, nous
avons abordé notre environnement de travail. Par la suite, nous avons présenter les
différentes interfaces de notre application réalisée.
Conclusion générale
La société Ooredoo Tunisie essaye d’adopter un système de gestion de maintenance

assistée par ordinateur qui est sur mesure adapté à ses propres besoins. C’est dans
ce contexte que s’inscrit ce projet de fin d’études qui a pour objectif de mettre en
place une GMAO pour la direction de maintenance bâtiments et services techniques.
Cette GMAO permet de gérer les interventions et les plannings programmés et l’ex-
portation et l’analyse des rapports pour les bâtiments et les équipements. Ainsi
la gestion du parc équipements avec leurs fiches d’installation, la consultation des
indicateurs de performance pour avoir une idée claire sur la situation actuelle du
système par rapport aux objectifs fixés. Egalement la gestion de stock, la gestion de
budget et finalement l’envoi des notifications via un e-mail.
Pour réaliser ce travail, nous avons commencé par une analyse qui consiste à définir
le contexte général ainsi que la méthodologie du travail adoptés. Ensuite nous avons
effectué une étude théorique sur les concepts du GMAO et les logiciels existants sur
le marché afin de proposer une solution qui répond au besoin de l’entreprise.
Par la suite, nous avons analysé et spécifié les besoins fonctionnels et non fonc-
tionnels après avoir étudier l’existant. Dans une étape suivante, nous avons présenté
l’environnement de travail, les outils et les technologies utilisés tout au long de notre
stage. Puis, nous avons détaillé notre conception à travers les diagrammes de sé-
quences, de paquettages et le diagramme de classes. Finalement, nous avons décrit
notre application à travers des captures d’écran.
Ce stage nous a permis d’approfondir nos connaissances théoriques, acquises tous

au long de notre formation, par la pratique des nouvelles technologies et de maî-
triser le langage de modélisation UML, les outils de développement PHP 5 avec le
framework Symfony 2.8 et le système de gestion de base de données mysql. Comme
perspectives, plusieurs fonctionnalités peuvent être ajoutées à notre application no-
tamment l’ajout d’une partie pour la gestion des projets qui sera très importante
dans notre cas pour le suivi de l’avancement des projets.
56
Bibliographie et netographie
[1] http ://www.afnor.org/profils/responsabilite/maintenance/[Consulté le 19/02/2018]
[2] http ://www.marche-public.fr/Marches-publics/Definitions/Entrees/GMAOgestion-
llll maintenance-assistee-ordinateur.html/[Consulté le 22/02/2018]
[3] http ://s3.amazonaws.com/publicationslist.org/data/gelog/ref-507/115.pdf/[Consulté

le 24/02/2018]
[4] http ://www.apisoft.fr/[Consulté le 26/02/2018]
[5] https ://www.as-informatique.com/logiciel/gmao.php/[Consulté le 26/02/2018]
[6] http ://gii.polytech.up.univ-mrs.fr/deuterium/[Consulté le 02/03/2018]
[7] https ://www.cprime.com/resources/what-is-agile-what-is-scrum/[Consulté le 05/03/2018]
[8] Modelisation Objet avec UML, Pierre-Alain Muller[Consulté le 06/03/2018]
[9] L’orienté objet cours et exercices en UML 2/[Consulté le 06/03/2018]
[10] http ://www.aqmanager.com/[Consulté le 10/03/2018]
[11] https ://www.commentcamarche.com/contents/498-html-langage/[Consulté le

12/03/2018]
[12] https ://www.alsacreations.com/astuce/lire/1433-utiliser-php-pour-gerer-vos-styles-

css.html/[Consulté le 15/03/2018]
57
58 Conclusion
[13] https ://www.templatemonster.com/bootstrap-website-templates/[Consulté le

17/03/2018]
[14] https ://www.sql.sh/sgbd/mysql/[Consulté le 18/05/2018]
[15] https ://symfony.com/what-is-symfony[Consulté le 18/05/2018]
[16] https ://twig.symfony.com/[Consulté le 18/05/2018]
[17] https ://www.doctrine-project.org/[Consulté le 18/05/2018]
[18] https ://fr.netbeans.org/produits/[Consulté le 10/06/2018]
[19] https ://openclassrooms.com/en/courses/4670706-adoptez-une-architecture-mvc-

en-php/4678736-comment-fonctionne-une-architecture-mvc/[Consulté le 18/06/2018]

Rapport Shay Mab WG Mao

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Shay Mab WG Mao

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement supérieur et de la Recherche scientifique

UNIVERSITÉ DE TUNIS EL MANAR

Projet de Fin d’Etudes

Shayma BEN OUAHMA

Conception et développement d’une

Réalisé au sein de : Ooredoo Tunisie

Encadrant universitaire Encadrant professionnel

Je me vois dans l’obligation de nommer en particulier :

Shayma ben ouahma

Il me tient sincèrement à cœur, de signifier ma reconnaissance et de présenter mon

Mes remerciement vont à tout l’équipe de maintenance, pour leurs encouragements et

1 Cadre général du projet 3

2.4.4 Langages de modélisation . . . . . . . . . . . . . . . . . . . . . . . 12

3 Analyse et spécification des besoins 13

3.1 Diagramme de Cas d’utilisation global . . . . . . . . . . . . . . . . . . . . 18

5.1 Logo «HTML5» et «CSS3» . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Logo « Symfony» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.1 Backlog du produit relatif à notre application . . . . . . . . . . . . . . . . 17

4.1 Description textuelle du cas d’utilisation «Gérer parc équipement» . . . . 29

GMAO Gestion de maintenance assistée par ordinateur

• Chapitre 3 : Analyse et spécification : Nous dégagerons les besoins de notre client

Cadre général du projet

1.1 Cadre du projet

1.2 Présentation du projet

1.2.2 Rôles de la maintenance

— Un rôle productif : la maintenance permet de garder un taux de disponibilité maxi-

— Un rôle économique : la maintenance vise à diminuer les pannes et les pertes de

d’œuvre consommée pour les interventions des équipements.

— Un rôle d’assurance qualité : la maintenance contribue à la qualité par un fonction-

— Un rôle de sécurité : Les dépannages, la maintenance préventive et les modifica-

1.2.3 Objectifs de la maintenance

1.2.4 Les différentes formes de maintenance

— Comment mettre à disposition aux responsables au sein d’une entreprise un outil

2.1 Définition GMAO

Figure 2.1 – GMAO

2.2 Les Objectifs de la GMAO

2.3 Concept de GMAO

2.3.1 Les fonctionnalités du système GMAO

2.3.2 Les raisons à la mise en place d’une GMAO

2.4 Etude de l’existant

2.4.1 Les solutions GMAO utilisés :

Figure 2.2 – Logo OptiMaint

Figure 2.3 – Logo ManageMaint

2.4.2 Critique de l’existant

2.4.3 Choix méthodologique

2.4.4 Langages de modélisation

Analyse et spécification des

3.1 Les rôles de Scrum

Dans notre cas, les rôles sont répartis comme suit :

3.2 Identifications des acteurs

3.3 Identification des besoins

3.3.1 Besoins fonctionnels

Besoin fonctionnel 2 : gestion de stock

Besoin fonctionnel 3 : gestion des interventions

Besoin fonctionnel 4 : gestion des contrats

Besoin fonctionnel 5 : gestion des fournisseurs

Besoin fonctionnel 6 : gestion de budget

Besoin fonctionnel 7 : consultation des indicateurs de performance

Besoin fonctionnel 8 : notification par mail

3.3.2 Besoins non fonctionnels

informatiques. Nous devons avoir un système d’accès sécurisé qui se base

3.4 Backlog produit

ID Title User Story Priorité Story