~========================================= =c:: : :Jc::::tc::I c:::,·c:: : : lc:: : :Ji=:Jc::J ~==c;,1

0 a
a J
0 REPUBLIQUE DE CÔTE-D'IVOIRE 3
0 a
il Union-Discipline-Travail 0
0 a
0 D
0 Ministère de l'Enseignement Supérieur et de la Recherche Scientifique n
0 a
0 a
1 Université Nangui Abrogoua a
n 0
r, a
[. 0
r 0
[ 2015-2016 0
C 0
n 0
0 0
u n
a 0
a 0
0 a
0 0
a Unité de formation et de 0
0 l'Nl\'l.H'I 11 recherche des Sciences 0
0 NANGUI AfiROGOt.:A Fondamentale 0
a 0
0 C
1
rr,
Thème D
u
r ~
C il
C
r ETUDE ET MISE EN PLACE D'UNE ~
u
l u
a
r-
APPLICATION DE GESTION DES 0
n
a 1
~
0
INCIDENTS INFORMA TIQUES q
~
u il
~ 0
0 0
u n
r MEMOIRE EN VUE DE L'OBTENTION DU DIPLÔME DE MASTER EN METHODES a
fi
INFORMATIQUES APPLIQUEES A LA GESTION ET A L'ECONOMIE (MIAGE)
n
0 a
a 0
a n
a Présenté par : 0
0 LASME AGNIME BENOITE NYSE EMMANUELLE a
0 u
0 Le 22 Décembre 2016 n
u a
n a
0 0
a u
a u
O Le jury Directeur de mémoire: Prof. AKA Boko il
n J
0
0 Co-directeur: Dr. ZEZE DJEDJE Sylvain ~
Président du jury : Prof. AKA Boko, Professeur Titulaire
a 0
0 Membre : Dr. ZEZE DJEDJE Sylvain, Maître Assistant 0
a Membre: Dr. OUATTARA Mory, Assistant l
0
Membre : Ingénieur BOU Kuyo
a
0 0
D 0
0 D
0 0
0 1
0 0
0 r.
a r,
u a
l G

~~~~~~~~~=~~~~~~~~~~=~~=~~=~=~=======~~~dn
[J
~=============~=<>======================================~
0
0
0 a
0 [)
0 0
0 n
0 n
r n
r D
n n
ü n
r 0
r 0
1 n
L ,J
1; 0
a 0
n 0
a 0
0 . 0
n a
ü 0
Q a
1
0
ANNEE UNIVERSITAIRE 2015-2016 a
a
0 a
C 0
0 a
0 0
n ]
u
n
0
Thème J a
0
0
0 n
0 G
0 C
0
"
ETUDE ET MISE EN PLACE D'UNE n
n
a 0
a
0
APPLICATION DE GESTION DES n
0
0
C INCIDENTS INFORMATIQUES C
0
0 u
a 0
a a
a u
0 ]
a MEMOIRE EN VUE DE L'OBTENTION DU DIPLÔME DE MASTER EN METHODES J
a INFORMATIQUES APPLIQUEES A LA GESTION ET A L'ECONOMIE (MIAGE) 1
C J
a 0
a Présenté par : 0
a a
a LASME AGNIME BENOITE NYSE EMMANUELLE a
a Le 22 Décembre 2016 0
1 0
u
a
a n
0 0
a o
o Le jury Directeur de mémoire : Prof. AKA Boko J
a 1
~ Président du jury : Prof. AKA Boko, Professeur Titulaire Co-directeur : Dr. ZEZE DJEDJE Sylvain ~
C Membre : Dr. ZEZE DJEDJE Sylvain, Maître Assistant ~
t Membre: Dr. OUATIARA Mory, Assistant a
~ Membre : Ingénieur BOU Kuyo ~
C 0
a ü
a u
C 0
a o
C U
C D
C
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=~~~~~~~~~~~~~~~~~~===~0
~===~=~~~~~=~=~=~====================~==~~~=~=============••===~~~~======~=~~~~=~~
a a
0 Il
Il Il
0 0
a o
Il 0
Il Il
LI 0
Il 0
LI 0
0 U
LI D
0 LI
LI 0
0 Il
0 0
Il 0
Il Il
0 Il
0 0
n a
0 0
0 0
a o
0 0
LI 0
0 0
a o
n o
0 0
0 0
U 0
u u
u a
0 0
0 0
a a
0 0
0 Il
0 0
0 U
0 Il
D ,1
0 0
0 D
0 D
Il D
D 0
n D
il D
Il D
LI Il
o a
0 [)
~~~~~~~~=====~==~=~~~=~====~====~~========~~~~==~======~=~~=~~~~~~~~~~~===~~~~~~~
 TABLE DES MATIERES

DEDICACES •••••••••••••••••••••••.•••••••••••••••••••••••••••••••••.•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• iii

REMERCIEMENTS •••••••••••.••••••••••••••..••••••••••••••••••••••••••••••••••••••••••••••••••••••••••.••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• iv
RESUME ••••••...••••.•••.....•.•••••.••••••••••••••..••.••••••••••.•••.•.•••••.•••••.••••..•••.•..••.....•••••••••••.••••.••••••••••.•••••••••••••.•••••...••••••••••••••• V

LISTE DES FIGURES •••••••••••.•.•.•••••••••••••••••••••••••••..••••••••••••...•.••••••••••••••••••••••••.••••••••••••••••••••••••••••.•••••••••••••••.•••••••••••••• vi

LISTE DES ABREVIATIONS ••••.•••••••••••••••••••••••••••••••••••••••••••••.•••••••••••••••••••••••••.•.••••••••••••••••••••••••••••••••••••••••••.••••••••••••• vii
INTRODUCTION GENERALE •..••••••••••••••..•••••••••••••••••••••••••.•••••••••••••••••••••••••••••.•••.••••••••••••••••••••••••••••••••••••••••••••••••••••••• 1
CHAPITRR I: CO.NTEXTR 6ENERAL DU PROJET 2

I. I introduction 3

1.2 Présentation du cadre institutionnel , 3

1.2.1 Présentation de Plurielles Entreprises 3
l.2.2 Organisation 3
1.2.3 Présentation du département d'accueil 3
1.2.4 lients 4

1.3 Présentation du cadre général du sujet 4

1.3.1 Description del 'existant. 4
1.3.2 ritique de l'existant 4
1.3.3 Présentation générale du projet 5
1.3.4 Problématique 5
1.3.5 Objectifs du projet 5
f..l onclusion 6

CHAPITRR ll: ETAT DE L'ART ET CHOIX DE LA SOLUTION 7

Il./ Introduction 8

11.2 Gestion des incidents 8

11.2.1 Définition des termes de l'étude 8
11.2.2 Processus de gestion des incidents 9

11.3 Expression des besoins 10

0.3.1 Fonctionnalités requises 11
11.3.2 Contraintes et exigences 11
11.3.3 Identification des acteurs 12
11.3.4 Identification des cas d'utilisation 12
11.3 .5 Diagramme de cas d'utilisation 13
II .3 .6 Solutions existantes sur le marché 14
11.3.6.1 ASTRES 14
11.3.6.2 OSTICKET 15
11.3.6.3 REQUEST TRAC KER 16
11.3.6.4 OTRS 17
11.3.6.5 GESTUP 18
11.3.6.6 GLPI 19

Il . ./ Solution proposée 20

11.5 Objectifs 20
1
11.6 Conclusion : 21
CHltPITIUI m : P.ARllllÉTltA&E 22
Ill./ Introduction 23

111.2 Paramétrage du logiciel 23

IJl.2.1 Configuration d'un client 23
111.2.2 Ajout d'un serveur messagerie 24
1 II .2.3 Les notifications par mai 1 26
(J] .2.4 la création d'une catégorie de ticket 28
111.2.5 Interface ajout d'un équipement. 30

111.3 Interface pour la gestion des incidents 30

Til.3.1 Connexion à l'application 31
111.3.2 Interface de déclaration de l'incident du client 32
II 1.3 .3 l'affectation de l'incident 33
IJI.3.4 la résolution de ) 'incident 34
111.3.5 Clôture de l'incident.. 35
111.3.6 Gabarit de suivi et gabarit de tâches 35
111.3.7 L'envoi de message 39

l/1.4 Conclusion 4/
CONCLUSION GENERALE 42
BIBLIOGRAPHIE ....................................................................•.......••••.••.................•••..••......••..•..•..........•.............••••. 43
ANNEXES 44

Il
 DEDICACES

Je dédie ce travail :

Au Dieu tout puissant qui m'a donné la force de continuer jusqu'au terme de mes études
malgré toutes les difficultés rencontrées.

A mon père Lasme Benoît et à ma mère Lasme née Lasme Loyou Ruth pour leur soutien qui
ne m'a jamais fait défaut. Que ce travail soit le gage de votre confiance et de votre amour pour
nous.

A mes frères, à mes sœurs, à mes oncles et tantes, pour votre soutiens sans faille et votre amour
fraternel, vous qui ne m'avez pas éloigné de la tristesse. Recevez le fruit de mes efforts.

A tous mes amis pour leurs prières et conseils qui m'ont guidé tout le long de mon parcours.

A toutes les personnes qui se sont rendues disponible pour moi, qui m'ont encouragé à ne pas
baisser les bras.

En témoignage de ma gratitude et de mon amour pour vous.

111
 REMERCIEMENTS

< li faut toujours remercier l'arbre à karité sous lequel on a ramassé de bons fruits
pendant la bonne saison>. Ahmadou Kourouma; Extrait de Allah n'est pas obligé.

Le mémoire est un effort qui ne peut être réalisé par une seule personne. Par conséquent nous
remercierons ici, ceux qui nous ont aidés au cours de ces derniers mois de travail. D'avance,
merci à ceux que nous aurions oubliés.

Au terme de ce projet, nous tenons à exprimer notre profonde gratitude et notre immense respect
au directeur de master et responsable de la filière Génie informatique de l'UFR SFA, le
professeur AKA Boko.

Nos remerciements également au docteur EDI Hilaire, responsable de la filière MIAGE de

l'UFR SFA.

Nous sommes très reconnaissants à docteur ZEZE DJEDJE Sylvain, responsable de la licence
3 informatique de l'UFR SFA pour sa bienveillante sollicitude à notre égard, pour tous les
conseils donnés et la disponibilité qu'il nous a accordée.

Je remercie la direction de Plurielles Entreprises et toute l'équipe, pour l'accueil et l'importance

qu'elles m'ont accordée tout au long de mon stage :

M. KOFFI RAOUL. Directeur General

M. SASSON DINGUI, Responsable informatique

Et tous les autres agents qui m'ont aidé durant ce stage.

A tous mes parents et amis pour leur soutien.

IV
 RESUME

Proposer un outil qui faciliterait la gestion des incidents informatiques, est la mission qui nous
a été assignée lors de notre stage. Après une étude qui nous a permis de déceler les différents
besoins des utilisateurs, nous avons exploré les solutions existantes parmi lesquelles nous avons
choisi celle qui correspond aux besoins et aux ambitions : GLPI (Gestion Libre de Parc
informatique). Ce logiciel dont l'accès est très sécurisé, permet aux différents utilisateurs
d'effectuer les différentes tâches liées à leurs profils à partir des interfaces personnalisées. Nous
avons par la suite paramétré ce logiciel en fonction de nos besoins en y incluant de nouvelles
fonctionna I i tés.

Offering a tool that facilitates the management of data processings is the assignment that was
assigned us during our course. Having expressed the various needs for the compagny. we
explored the existing solutions among which we chose these that was answering the needs and
dreams : GLPl. This software whose access is reassured a lot, permits doing them for the
different users different related task of their profiles to depart in interfaces personnalized. We
have with the suite parameter this software in function of needs of there including under taking
of new fonctionalities.

V
 LISTE DES FIGURES

Figure 1:Processus de Gestion des Incidents 9

Figure 2: diagramme de cas d'utilisation 13
Figure 3: configuration du serveur de messagerie 26
Figure 4: configuration des notifications 28
Figure S: catégorie de ticket 29
Figure 6: exemple de catégorie de ticket.. 29
Figure 7: ajout d'un équipement 30
Figure 8: interface d'authentification 31
Figure 9 : Interface de déclaration de l'incident du collaborateur 32
Figure 10 : Interface pour l'affectation de l'incident 33
Figure 11 : Interface pour la résolution et le rapport sur l'incident 34
Figure 12: clôture de l'incident. 35
Figure 13: création gabarit de suivi 36
Figure 14: suivi de ticket 37
Figure 15: tâche d'un ticket 39
Figure 16: message reçu 40

VI
1

LISTE DES ABREVIATIONS

API : Application Programming Interface

GLPI : Gestion Libre de Parc Informatique

GPL : Licence Publique Générale

VII
 INTRODUCTION GENERALE

L'informatique, cœur de l'entreprise quel que soit son domaine d'activité, doit fonctionner
pleinement et en permanence. En effet, el le est devenue le système central des entreprises dans
la mesure où une panne, un manque de réactivité, une indisponibilité, une perte d'information
affectent considérablement leur mécanisme et les rend moins compétitives. Toute entreprise
vise à réaliser des bénéfices. Pour se faire elle doit avoir un système assurant les performances
optimales de ses outils de travail. Cela permettra d'amortir ses dépenses vu le coût exorbitant
du remplacement du matériel endommagé. De ce fait, la gestion des incidents doit être menée
de façon rigoureuse et fiable afin de garantir la compétitivité de l'entreprise. Daniel Kervarec
[ 1] dans son article intitulé« ITIL et la gestion des problèmes», paru sur le site newsitiweb.info
définit l'incident comme tout évènement n'appartenant pas aux opérations normales et pouvant
engendrer une interruption de service ou une diminution de sa qualité. La notion d'incident est
très large et couvre des domaines variés : incident technique, incident fonctionnel, incident
social, incident de sécurité, incident de communication, incident de paiement, incident
informatique etc.

Plurielles Entreprises, notre structure hôte, a pris conscience de cette réalité et a entrepris de se
doter des moyens pour prévenir et gérer les incidents informatiques de ses clients afin de
minimiser leur impact. C'est dans cet objectif que nous avons mené notre réflexion sur le thème
suivant: "Etude et mise en place d'une application de gestion des incidents informatiques".

Ce document présente en trois chapitres l'ensemble du projet. Dans le premier chapitre, nou
ferons une présentation générale de la structure d'accueil et présenterons le contexte dans lequel
nous réalisons ce projet. Dans le second, nous ferons un état de l'art en passant en revue le
connaissances sur la gestion des incidents et les outils existants et nous présenterons la solution
retenue. Dans le troisième chapitre, il s'agira de présenter le paramétrage de la solution. Nou
terminerons notre étude par une conclusion générale.
2
1
Contexte général du projet

1.1 Introduction
L'objectif de ce chapitre est de définir le contexte général du projet. D'abord, nous présenteron
la structure d'accueil suivie du cadre du sujet en décrivant l'existant. Ensuite nous présenterons
le contexte du projet et enfin nous poserons la problématique et les objectifs de l'application.

1.2 Présentation du cadre institutionnel

1.2.1 Présentation de Plurielles Entreprises

Crée le 05 Septembre 2016, Plurielles Entreprises est une Société à Responsabilité Limitée
(SARL) dynamique et spécialisée qui exerce dans plusieurs domaines d'activités à savoir les
télécommunications, les travaux de Bâtiments et Travaux Publics (BTP), l'Electricité et
l'informatique. Elle est située dans la commune de Marcory.

12.2 Organisation
Plurielles Entreprises est composée de deux directions: la direction technique qui renferme les
ervices informatiques, télécommunications, BTP, électricités et la direction administrative et
financière qui regroupe le service commercial et le service juridique.

Voir en annexe 1 l'organigramme de l'entreprise

L2.3 Présentation du département d'accueil

Le département qui nous a accueilli pour notre stage est celui de l'informatique dirigé par un
responsable Informatique.

e département a pour missions :

•!• la conception, le déploiement et l'exploitation de l'architecture système, réseau et

sécurité ;
•!• la conception, le déploiement et l'exploitation des logiciels métiers;
•!• l'assistance dans l'utilisation des outils informatiques Administration de bases de
données OL TP (Online Transaction Processing) et OLAP (Online Analytical
Processing);
•!• l'installation et la maintenance des équipements informatiques·
•!• la coordination de l'acquisition et le renouvellement du matériel informatique·

3
 Contexte général du projet

•!• L'hébergement de sites, le consulting.

La description du système informatique peut se faire en termes d'équipement, logiciel et réseau

informatiques.

12.4 Clients
Les clients sont pour la plupart des entreprises qui ont de nombreux besoins tels que
l'hébergement de sites internet ou d'applications ou qui ne possèdent pas de service
Informatique. Nous pouvons citer entre autre l'rNGS et la marie de BONO UA, la CNDJ (Centre
National De Documentation Juridique) et la société EICER-CI, Hammer ci, SIMES etc ...

1.3 Présentation du cadre général du sujet

13.1 Description de l'existant

A notre arrivée, le service informatique ne disposait pas d'un système informatisé de gestion
des incidents. Lorsqu'un incident survient, le client doit le signaler au service informatique via
le téléphone ou par mail. Après chaque intervention, l'agent qui est intervenu saisit ses
références personnel les et celles concernant l'incident dans un formulaire rangé dans les
archives du service informatique

13.2 Critique de l'existant

Les faiblesses du système que nous avons relevées sont les suivantes :

•!• Les enregistrements sont faits sur des feuilles, cela peut entrainer des pertes. D'où
ces données ne sont pas sûres et sécurisées ·
•!• l'absence de procédures pour la gestion des incidents : le processus de gestion des
incidents informatiques n'est pas standardisé;
•!• La longueur du temps de résolution des incidents ;
•!• Le manque de traçabilité et de suivi ;
•!• l'inexistence de base de données : les incidents ne sont pas enregistrés dans une base
de données afin d'établir des états, donc de faire des statistiques.

4
1
Contexte général du projet

13.3 Présentation générale du projet

Notre projet de fin d'études s'inscrit dans le cadre d'une solution optimisée et rationalisée de
l'activité d'assistance. Le département informatique a la charge de trouver des solutions
informatiques qui facilitent le travail de ses techniciens. Il veut mettre en place une application
accessible via internet qui permettra de déclarer les incidents afin de les traiter. 11 nous est
demandé de proposer cette application de gestion des incidents informatiques.
Cette application devra permettre:

•!• l'établissement de rapport sur les différents incident

•!• l'acquisition d'une banque de données des incidents
•!• la production d'une situation des incidents par agent, par département etc.

l3.4 Problématique
Les clients de Plurielles Entreprises rencontrent souvent des évènements appelés incidents qui
causent des interruptions de la quai ité de ses services. Ces incidents doivent être remontés au
département informatique afin d'avoir le support informatique nécessaire pour leur résolution.
ependant, ce processus constitue une perte de temps et d'argent compte tenu des
déplacements fréquents des équipes du département informatique vers les clients. Face à la
diversité des sites à gérer il est difficile pour ses techniciens de prendre en charges rapidement
les incidents déclarés et dassurer un suivi efficace de ces incidents. Aussi lorsque la solution à
un incident est connue d'un technicien, si un autre membre du département informatique est
ollicité pour le résoudre, il est possible qu'il lui soit nécessaire de reprendre tout le processus
de recherche avant d'arriver à la résolution au lieu de profiter de l'expérience de son collègue.
fi est également difficile pour le service informatique de garder une trace des incidents qui
surviennent. En plus. l'absence d'une base données numérique rend quasiment impossible
l'établissement de statiques fiables.

La problématique soulevée ici est donc de trouver comment mieux gérer les incidents
informatiques. La solution choisie est la mise en place d'un système informatique pour la
gestion des incidents.

I.3.5 Objectifs du projet

Cette application va à terme permettre d'atteindre les objectifs suivants :

5
 Contexte général du projet

•!• Une meilleure gestion du suivi des incidents

•!• Une rapidité et une facilité de traitements des incidents
•!• meilleure affectation des incidents entre les différents techniciens
•!• Une traçabilité des incidents.
•!• Une base de connaissance (sert à rassembler de manière centralisée l'expertise d'un
domaine généralement formalisée de manière déclarative)
•!• Une amélioration des relations avec les clients
•!• Bénéficier d'une visibilité totale sur les clients et les principales informations
associées
•!• Tenir ses engagements en termes de services

1.4 Conclusion
En somme nous avons présenté succinctement la structure d'accueil PLURlELLES
ENTREPRISES et le contexte dans lequel nous réalisons ce projet. Maintenant nous allons
passer à l'état de l'art.

6
7
1
Etat de l'art et choix de la solution

11.1 Introduction
Le présent chapitre permettra de présenter les connaissances en rapport avec le thème. D'abord
nous parlerons du projet afin de comprendre le problème étudié. Ensuite, nous définirons le
besoins et les contraintes de notre solution. Enfin, nous exposerons les solutions existantes et
nous présenterons la solution retenue pour atteindre notre objectif.

Il.2 Gestion des incidents

IJ.2.1 Définition des termes de l'étude
Pascal Delbrayel [2] dans son livre intitulé « ITIL vs la gestion des incidents » définit
un Incident comme étant :

« Tout événement qui ne fait pas partie du fonctionnement standard d'un service et qui cause,
ou peut causer, une interruption ou une diminution de la qualité de ce service.»

Les incidents peuvent être classés en deux catégories : Logiciel et Matériel.

Le terme Incident est généralement compris comme un dysfonctionnement signalé par un

Utilisateur. Cependant, deux extensions à cette définition sont généralement utilisées car elles
vont suivre le même processus de traitement que les dysfonctionnements proprement dits et
sont donc assimilés à des Incidents :

•:• Les demandes pour un nouveau service (ou l'extension d'un service existant) sont
considérées comme des Demandes de Changement (RFCs) mais assimilées à des
Incidents en pratique (traitement identique) et traitées dans le cadre de la Gestion des
Incidents
•:• Les Remontées d'alertes automatiques (espace-disque saturé par exemple): elles sont
souvent considérées comme faisant partie de l'exploitation courante ; ces événement
sont traités dans le cadre de la Gestion des Incidents même si le service délivré aux
Utilisateurs n'est pas affecté

La gestion des incidents est un processus de gestion du cycle de vie de tous les incidents. Elle
'assure que l'exploitation normale des services soit rétablie le plus rapidement possible et que
l'impact sur le business soit réduit au minimum.

8
1
Etat de l'art et choix de la solution

11.2.2 Processus de gestion des incidents

Le processus (3] de gestion des incidents est décrit par la succession des étapes suivante

DETECTION ET
ENREGISTREMENT

ou,
DEMANDE DE

RECHERCHE DES INCIDENTS

CONNUS
V ")
u..J
C)

>
=:,
._
OUI

V ")

u..J
u..J

._
___J
0
ex::
:z:
INVESTIGATION ET
DIAGNOSTIC

0
<..J

NON

RMETURE DE L'INCIDEN

Figure 1: Processus de Gestion des Lncident

9
1
~tat de l'art et choix de la solution

Détection et enregistrement : première étape du processus, l'activité de détection et

d'enregistrement se doit d'être particulièrement efficace. Il faut détecter vite, et si possible
avant le moindre impact sur les processus métiers. Puis, il s'agit d'enregistrer chaque
évènement sous une référence unique pour en assurer le suivi, la documentation et l'analyse.
Chaque action sera documentée.

Classification et première analyse : en préalable à toute action d'analyse, l'incident est associé
à une catégorie généralement à caractère technologique (système, stockage, réseau, etc.). Ce
paramètre facilitera la fonction d'analyse qui utilisera dans un premier temps les connaissances
capitalisées dans la base de gestion des incidents.

Recherche des incidents connus: Il s'agit plutôt de trouver une solution à l'incident dans les
bases d'informations et les documentations que de chercher une solution inédite sauf si elle est
évidente au vu du diagnostic.

Investigation et diagnostic : lorsque l'incident ne peut être résolu par le premier niveau de
support (généralement le centre de services), alors une action de diagnostic plus avancée est
engagée. Il est recommandé. chaque fois que cela est possible. de mettre en œuvre une solution
de contournement pour minimiser l'impact de l'incident.

Résolution et remise en état : l'incident peut être résolu par le biais d'une solution de
contournement ou par un changement (de composant ou de configuration). On veillera à ce
niveau du processus à porter un soin tout particulier à la documentation de l'action dans la base
de gestion des incidents. Cette information permettra probablement d'autres résolutions.

Fermeture de l'incident : la fermeture de l'incident ne peut être décidée par la ressource

technique seule. L'utilisateur, directement concerné, doit à ce niveau du cycle de l'incident
donner son approbation. C'est aussi l'opportunité de valider le niveau de satisfaction des
directions métiers sur le traitement des incidents.

II.3 Expression des besoins

Le département informatique dans sa mission de veille technologique, s'est donné pour projet
la mise en place d'une application de gestion des incidents informatiques. Cette application
permettra d'automatiser le processus de déclaration des incidents, d'automatiser le processus
de résolution des incidents, de produire des états de gestion et des statistiques des incidents.

10
 tat de l'art et choix de la solution

113.J Fonctionnalités requises

Au terme de notre projet, notre application devra comporter les fonctionnalités suivantes :

•:• Un Système d'administration des utilisateurs (paramétrage de base, gestion des

collaborateurs) ;

•:• Un module de déclaration d'incidents. d'annulation des incidents, de résolution des

incidents. de suivi des incidents et de clôture des incidents ·

•:• Une base de connaissance permettant aux techniciens de retrouver rapidement de

documents sur la résolution des incidents ·

•:• Des rapports (états) sur les incidents déclarés, les incidents résolus, les incidents en
cours de résolution ·

•:• Des statistiques sur les incidents selon plusieurs critères ·

•:• Des tableaux de bord permettant la visualisation du nombre d'incidents en cours d

résolution, d'incidents résolus, ouverts, des incidents clos.

•:• Un tableau de bord permettant la consultation de l'historique des incidents. des

interventions réalisées.

113.2 Contraintes et exigences

Pour que notre solution réponde aux exigences de I" entreprise, i I nous faudra respecter un
certain nombre de contraintes et critères qui conditionnent le fonctionnement du futur système.

•:• La convivialité des interfaces:

La solution doit présenter une interface ergonomique englobant toutes les fonctionnalités
offertes. La manipulation de l'interface ne doit pas nécessiter des connaissances poussées en
informatique ; el le doit être simple et claire afin de s'adapter aux connaissances informatiques
de notre utilisateur.

•!• Besoins de Sécurité :

Notre application doit garantir à l'utilisateur l'intégrité des données c'est-à-dire qu'elles gardent
leur forme et leur contenu original. En outre. elle doit protéger la confidentialité en assurant la

11
 Etat de l'art et choix de la solution

validité de l'identité de l'utilisateur. Ceci peut se faire entre autres par le moyen d'un mot de
passe assurant le contrôle d'accès.

•!• Disponibilité :

Il est important que notre système puisse fonctionner sur une plateforme hautement disponible
et pouvant gérer un grand nombre de requêtes.

•!• Extensibilité

Il doit avoir une possibilité d'ajouter de nouvelles fonctionnalités ou de modifier celles

existantes.

ll.3.3 Identification des acteurs

Les acteurs du système sont les suivants :

•!• Le client: la personne qui se connecte à l'application via l'interface web pour déclarer
les incidents.

•!• Le technicien: Membre du département informatique qui a pour charge de résoudre les
incidents déclarés par les collaborateurs.

•!• L'administrateur : C'est le super utilisateur ayant pour rôle toutes sortes d'opérations
telles que le paramétrage de base, le contrôles des connexions, la gestion des
collaborateurs et des ordinateurs et bien d'autre.

•!• Acteur externe : la personne qui résout les incidents remontés.

ll.3.4 Identification des cas d'utilisation

Il s'agit d'identifier les différentes intentions « métiers» associées aux acteurs du système. Les
principaux cas d'uti I isations sont :

•!• l'authentification ;

•!• la déclaration d'un incident;

•!• l'affectation d'un incident;

12
 Etat de l'art et choix de la solution

•:• la résolution d'un incident;

•:• la clôture de l'incident.

11.3.5 Diagramme de cas d'utilisation

Le diagramme de cas d'utilisation du langage UML [4] permet de recueillir, d'analyser,
d'organiser les besoins et de recenser les grandes fonctionnalités d'un système. Un diagramme
de cas d'utilisation capture le comportement d'un système, d'un sous-système, d'une classe ou
d'un composant tel qu'un utilisateur extérieur le voit.

Le diagramme des cas d'utilisation de notre système est représenté par la figure ci-dessous:

Figure 2: diagramme de cas d'utilisation

C0/19JLTER LISTE DES

UIODEHTS AFFECTES
\

~ ~NRE rnaDEm},',,
' A/W.YSE ET ROO.UTIOI
DE L111CIDBIT

am,
\

'
',,o
'

' '
1'1

l /

,,
' \ ~ I
'' ~r, '1i. REDACTION DE LA BASE
' {)'

,,
/ DE CONNAISSHIΠTEOiNICIEII
', ','~, Il I
... ,j} ,,,, // .. '
''' // ,
GERELEMODULE JI ~/
OEC- AATU> , , ~~~ ~, p,
I
COIISULTER LA LISTER !IICIDEIITS , Jf11
I
~
Rf~LUS ET HON RESOlUS I 1 11

;i I
______,,/,
I

1 1
PlANlflE LES 11/TERVEJITTOIIS /

ADMUIISTRAIBJ I I
I I
DEFl!HR LES PRIORITES ) t 1
I

·G""~-
ATI-STl-Q-UES
- DES_I_
IICI_D_
EJIT_~ AGEIIT EXTERNE

13
1
Etat de l'art et choix de la solution

ILJ.6 Solutions existantes sur le marché

11 existe plusieurs solutions possibles sur le marché pour notre problème, nous retrouvons :

11.3.6.1 ASTRES
ASTRES [5] est une solution de gestion de service d'assistance Française faite par IDV
ervice Support, développée en PHP et sous licence ONU.

Ses fonctionnalités sont:

•!• Gestion de workflow ;

•!• Gestion fine des permissions ·

•!• Fonctionnalités de Dialogue-Client permettant de tracer les communications, un peu

comme un forum ;

•!• Planification d'intervention;

•!• indexation des documents reçus par Tags ·

•!• Gestion de planning (congés, formations ... );

•!• Possibilité de génération de comptes rendus d'activité hebdomadaire

•!• générer des statistiques sous le forme de tableaux ou de graphiques sur les demande
des clients (demandes soumises/clôturées/résiduelles, demandes en retard. demandes
par sites, demandes par criticités, demandes par plates-formes, demandes par activités
charges en j/h des demandes, reste à faire par membre du support ... ). sur les document
ur les médias vierges, sur les livraisons/réceptions de matériel. .. Il y a beaucoup de
statistiques disponibles

•!• Base de connaissances ·

Cette application offre les fonctionnalités de base de la gestion des incidents. Néanmoins, nous
pouvons aussi noter les insuffisances suivantes :

Un point négatif concernant la sécurité, est qu'un utilisateur peut se connecter au système
eulement en inscrivant son nom et son prénom.

Au niveau de l'ergonomie des interfaces, lorsque l'on se connecte en tant qu'administrateur. il

est difficile de trouver l'option souhaitée en raison des nombreux menus et des termes parfois

14
1
Etat de l'art et choix de la solution

imprécis. Plusieurs abréviations sont utilisées par défaut, mais ne sont pas expliquées ; ce qui
augmente le temps d'apprentissage du logiciel. L'interface ne fournit aucun retour d'action;
lors de la création d'un utilisateur ou de tout autre élément. le logiciel ne donne aucun
renseignement sur l'état de l'action. L'utilisateur ne sait jamais si l'action s'est déroulée avec
succès ou non. Un autre désavantage de cette interface est que lors de la création d'un élément
(bien matériel, requête, etc.) une autre fenêtres' ouvre pour entrer les informations de l'élément.
Une fois le formulaire est complété et validé, l'utilisateur doit fermer cette fenêtre

Au niveau de la gestion des tickets: lors de la consultation d'un ticket par un administrateur ou
un technicien, plusieurs champs sont présents pour ajouter des informations mais quelques-uns
sont redondants. La trop grande quantité de champs nuit à la bonne gestion des tickets.

1/.3.6.2 OSTJCKET
OSTICKET (open source support ticket system) [6], logiciel libre de gestion de ticket orienté
relation - client et développé en PHP sous licence GPL. Il permet à un client de créer facilement
un ticket et de l'assigner à un service de l'entreprise. 11 permet aussi une gestion de suivi de
tickets, une gestion des utilisateurs ainsi qu'un grand nombre de paramètres de configuration.
OsTicket intègre également un système de template permettant de personnaliser à souhait
l'interfac

Voici une liste de ses fonctionnalité

•:• Création de tickets par mail, formulaire en ligne et téléphone.

•!• Réponse automatique lors de 1 'ouverture d'un ticket, ou à la réception avec gestion de
la personnalisation des mails via template
•!• Gestion de réponses pré-définies via un système de FAQ
•!• Ajout de commentaires aux tickets
•!• Notifications et alerte
•:• Gestion des permissions par groupe et service
•!• Possibilité d'assigner un intervenant sur un ticket et de le transférer
•!• Gestion de l'historique

ette application offre les fonctionnalités de base de la gestion des incidents. Néanmoins, nous
pouvons aussi noter les insuffisances suivantes :

15
 Etat de l'art et choix de la solution

•:• Pour vérifier l'état d'un ticket, l'utilisateur doit absolument avoir le numéro du ticket
(lien envoyé par courriel)
•:• Le technicien peut répondre au ticket et le clôturer si besoin. La logique aurait souhaité
que ce soit le client qui clôture de lui-même l'incident qu'il a déclaré. Cela permet
d'éviter que des techniciens clôturent le ticket sans avoir trouvé de solution
•:• Osticket ne permet pas de lier un équipement à un ticket
•:• Osticket ne contient pas de module qui permet de générer des rapports sur les statistique
des tickets
•:• Osticket n'est pas bien fourni au niveau des statistiques. li génère les statistiques
eulement par département, rubrique d'aide et par agent.

1/.3.6.3 REQUEST TRACKER

REQUEST TRACKER [7] est une solution de ticketing éditée par Best Practical, développée
en PHP et sous licence GPL.

Voici une liste de ses fonctionnalités :

•:• Création de tickets par mail, formulaire en ligne

•:• Nombre illimité de projet
•:• Gestion d'historique
•:• Gestion de la criticité
•:• Possibilité de laisser des commentaires privés
•:• Création de requêtes de recherches avec possibilité de sauvegarde de celles-ci.
•!• Réponse automatique lors de l'ouverture d'un ticket, ou à la réception avec gestion de
la personnalisation des mails via template
•:• Possibilité d'ajout de champs personnalisés, Gestion fines des permissions.
•:• Possibilité de lier des demandes entres elles (avec trois niveaux de liens plus ou moins
stricts dans la relation parents/enfants).
•:• Possibilité de lier des demandes à des équipements
•:• Historisation complète (sous forme de fils de discussion) de toutes les actions et de tous
les échanges autour d'un ticket.
•:• Module de suppression de tickets, disponibles pour les administrateurs (un utilisateur
ne peut rien supprimer, juste« marqué comme supprimé» s'il en a la permission).

16
 Etat de l'art et choix de la solution

•!• Possibilité de configurer des articles permettant de servir de base de connaissance

(FAQ) ou de modèles de réponse. Les articles peuvent être rédigés à partir d'extraits
d'un ticket

Cette application offre les fonctionnalités de base de la gestion des incidents. Néanmoins, nous
pouvons aussi noter les insuffisances suivantes :

Le logiciel est développé en perl outi I que nous ne maitrisons pa

Au niveau des interfaces, il est souvent compliqué de se retrouver dans les pages Web de
l'application et plus précisément celle des tickets. En naviguant dans l'application, il faut
parfois se demander quel est le but précis de cette page.

Au niveau de la gestion des tickets: la fenêtre de gestion des tickets contient trop de menus qui
ne sont pas directement liés à la gestion des tickets et il n'est pas très aisé d'ajouter des note
au ticket. Les propriétés du billet ne sont pas toutes au même endroit, ce qui fait que pour
modifier la priorité, il faut cliquer à un autre endroit.

Au niveau des statistiques, les options disponibles pour générer les rapports sont en quantité
limitée.

lf3.6.4 OTRS
OTRS (Open source Ticket Request System) [8] est une solution de gestion d'incidents
développée en PERL sous la licence ON
Voici une liste de ses fonctionnalités :
•!• Répondeur automatique pour les tickets ouverts par mai 1
•!• Notification par mail
•!• Déclaration autonome des tickets par les utilisateurs, mails, interfaces web ·
•!• Personnalisation de la vue des files d'attentes de tickets
•!• Gestion d'historique des tickets
•!• Gestion de priorités
•!• Gestion du temp
•!• Agent de création d'actions automatiques par actions planifiée
•!• Calendrier avec temps de travail
•!• Statistiques

17
 Etat de l'art et choix de la solution

Cette application offre les fonctionnalités de base de la gestion des incidents. Néanmoins, nous
pouvons aussi noter les insuffisances suivantes :

Au niveau de la convivialité des interfaces: Difficulté à se connecter en tant que client. La page
qui permet de déterminer tous les réglages est trop surchargée et il est parfois difficile de trouver
l'option souhaitée. Lorsqu'un technicien met à jour un billet, les boutons reliés à la gestion du
billet sont trop petits et passent inaperçus, un certain temps est nécessaire afin de trouver
l'option souhaitée
Au niveau de la gestion des statistiques : Le problème majeur est que l'administrateur doit
générer manuellement les diagrammes qu'il souhaite et ensuite ces diagrammes sont
auvegardés dans un fichier PDF externe à l'application. li aurait été souhaitable de visualiser
les statistiques directement dans l'interface Web et d'ensuite sauvegarder ceux que l'on
ouhaite garder.
Au niveau de la gestion des tickets: il ne fait pas de différence entre un incident et un problème.

11.3.6.5 GESTUP
GESTUP [9] est un logiciel de gestion de support sous licence GPL développé en PHP. Cette
solution offres aux usagers les possibilités suivantes:
•!• Support utilisateur
•!• Base de connaissance ;
•!• Possibilité lier un matériel au ticket;
•!• Gestion rnulti-techniciens ;
•!• Déclaration autonome des tickets par les utilisateurs, mails, interfaces web ·
•!• Liaison permanente avec vos collaborateurs, envoi de mail

1 •:• Reporting avec les statistiques ·

•!• Gestion du suivi
•!• intégration avec l'annuaire d'entreprise
•!• Planification d'intervention (planning)
•:• Insertion de pièces jointes au ticket
•!• Création de rappels sur un ticket
•!• Gestion du temps par ticket
•!• Gestion des priorités des demandes d'interventions
•!• Modèles de tickets (incidents récurrents)
•!• Gestion de profils avec des droits personnalisables

18
 Etat de l'art et choix de la solution

Ce logiciel offre toutes les fonctionnalités de base de la gestion des incidents. Ses interfaces
sont faciles à manipuler. Cet outil a la puissance de regrouper un support pour les utilisateurs
s'ils sont en équipe. Il permet de gérer divers profils et statuts (administrateur, techniciens,
utilisateurs ... ). Il offre des statistiques sur les incidents par technicien, service catégorie

criticités (critique, grave, moyenne, basse) .... li répond à nos besoins.

ll.3.6.6 GLPI
GLPI [1 O] est une solution de gestion de parc informatique qui contient également une
application de HelpDesk en rapport avec l'inventaire du parc développé en PHP. Elle est
développée sous la licence GPL
Voici une liste de ses fonctionnalités :

•:• Gestion des demandes d'interventions pour tous les types de matériel de 1' inventaire
•!• Collecte des demandes d'interventions par interface WEB ou par email
•!• Interface utilisateur finale pour demande d'intervention avec possibilité de joindre de
documents (self-service)
•!• Possibilité d'un suivi par mail de la demande d'intervention
•!• Consultation de l'historique des intervention
•!• Possibilité d'ajouter des commentaires à la demande d'intervention par interface WEB
ou par email
•!• Gestion des priorités des demandes d'interventions
•!• Suivi des demandes d'interventions
•!• Suivi par mail des interventions
•!• Affectation de catégories aux interventions
1 •!• Affectation des demandes d'interventions
•!• Modification de l'auteur de l'intervention
•!• Modification du matériel concerné par l'intervention
•:• Ouverture/fermeture/réouverture d'interventions
•!• Affectation d'un temps réel d'intervention
•!• Affectation d'un coût d'intervention
•!• Historique des interventions réalisées
•:• Affichage des interventions à réaliser par technicien
•!• Affichage de l'historique des interventions pour un matériel donné

19
 Etat de l'art et choix de la solution

•!• Gestion des plannings d'intervention

•!• Statistique

e logiciel permet la gestion de l'assistance aux utilisateurs avec des tickets d'incident et de
demande, la gestion d'un système de base de connaissances et permet de faire l'inventaire des
composants matériels sur un réseau. Il fournit des tableaux de bord permettant la visualisation
du nombre d'incidents en cours de résolution, résolus, ouverts et clos. Au niveau des
statistiques, il permet d'afficher les statistiques selon plusieurs critères : par ticket (nombre de
ticket ouverts, résolus, clos résolus en retard, délais moyens de prise en compte, durée moyenne
de résolution etc .... ) par intitulé (modèles, système d'exploitation etc .... ), par matériel ....
-t il génère des rapports dans divers formats ( PNG , SVG , CSV ); Ces statistiques peuvent
être affichées sous forme graphique. Pour conclure, nous pouvons dire que cet outil est trop
grand pour les besoins exprimés.

TI.4 Solution proposée

Après une étude comparative des différentes solutions existantes, il est donc primordial de
proposer une solution qui pourrait répondre à nos besoins. Notre choix de travail s'est porté sur
l'outil GESTSUP. Ce logiciel facile à utiliser, intègre toutes les étapes du processus de gestion
des incidents.

Le responsable du département informatique, ayant une vision plus claire des ambitions des
dirigeants de I" entreprise a opté pour le logiciel libre de gestion parc informatique GLPI. En
effet, comparativement au logiciel GESTUP qui permet seulement de faire la gestion des
incidents, GLPI permet de gérer l'ensemble du parc informatique de plusieurs sites à la fois, de

1 gérer les documents, les contrats ....

II.5 Objectifs
En plus des objectifs cités plus haut, cette application permettra de :

•!• Faire le point du parc informatique à tout moment des clients

•!• identifier de manière unique chaque équipement du parc des clients
•!• Localiser de façon précise chacun de ces équipements

20
 Etat de l'art et choix de la solution

11.6 Conclusion
L'état de l'art nous a permis de passer en revue les principales connaissances sur la gestion des
incidents, et de proposer une solution. Il s'agira de présenter les résultats de notre travail.

21
22
 Paramétrage

111.1 Introduction
e chapitre a pour objectif la mise en œuvre de chacun des modules décrits dans le chapitre
précédent. Nous consacrerons la première partie au paramétrage du logiciel et la deuxième
partie aux interfaces liées à la gestion des incidents ainsi que les nouvelles fonctionnalités.

ill.2 Paramétrage du logiciel

Le paramétrage d'un logiciel peut être défini comme le réglage du logiciel par l'introduction de
données permettant la modification de son fonctionnement.

agissant de notre logiciel, nous allons présenter quelques paramétrages à savoir celui du
serveur de messagerie, des notifications par mail, de la création de ticket par mail et des
catégories des tickets.

TIL2.1 Configuration d'un client

La notion de multi-entité de GLPI a pour but la segmentation de la gestion du parc tout en
permettant une consolidation facile des données des différents parcs. C'est une notion clé pour
les entreprises gérant le parc informatique de plusieurs entreprises. En effet, elle permet d'avoir
une nette vue des équipements et des interventions par entreprise. Ainsi on pourra affecter des
équipements à une entité, déclarer des tickets sur une entité, créer des profils et affecter
automatiquement des utilisateurs à des matériels à partir de certaines règles.

Tl s'agira pour nous ici de paramétrer notre logiciel pour une vue du parc informatique de l 'un
de nos clients.

CNDJ
1 1

'
, ,. •• ,

Bibliothèque Secrétariat Salle Service Bureau des Reprographie

informatique commerciale juristes

•• t Les
Les Les Les Les
Les
employés employés employés
employés employés employés
du service du service du service
du service du service du service

23
1
 Paramétrage

Pour la configuration nous al Ions :

1- dans le menu Administration> Entité et nous cliquons sur le "+" situé dans le menu
horizontal. Nous créons une nouvelle entité du nom de 'CNDJ .
•:• Nous rentrons ces coordonnées (téléphone, faxe pays, vil le, code postale et
courriel,
•:• Nous indiquons le mode d'authentification des employés (base GLPT, serveur
de messagerie ou annuaire LDAP)
•:• Nous définissons des règles d'habilitation
2- créer les groupes d'utilisateurs qui vont correspondre aux différents services de
l'entreprise. Il faut alors entrer dans le menu Administration> Groupe et cliquer sur le
"+" situé dans le menu horizontal. Ainsi le service commercial qui a pour parent la
CNDJ est créé après avoir rempli tous les champs.
3- dans le menu Administration> Utilisateur et nous cliquons sur le"+" situé dans le menu
horizontal. Nous remplissons les différents champs permettant d'ajouter un nouvel
utilisateur (son identifiant s'il n'est pas importé à partir du serveur de messagerie, le
nom, le numéro de téléphone, son entité 'parent' qui représente son entreprise). On
pourra par la suite lui attribuer des droits.
4- dans le menu 'Parc' et nous ajoutons les différents équipements de ce service. Par
exemple nous ajoutons un ordinateur; nous cliquons sur ·ordinateur' et nous remplissons
les différents champs en choisissant l'utilisateur de cet ordinateur. Nous pouvons aussi
attribuer un équipement tel qu'une imprimante qui sera utilisée par tous les utilisateurs
de ce groupe.

lll.2.2 Ajout d'un serveur messagerie

L'ajout d'un serveur de messagerie répond aux soucis de permettre une authentification des
utilisateurs via une source externe. Cela permet de ne pas avoir à entrer à la main chaque
utilisateur de notre logiciel. Plusieurs types d'authentification existent mais nous utilisons
l'authentification à partir d'un serveur de messagerie celui de Gmail.

Un utilisateur est authentifié par GLPI si le serveur de messagerie l'a authentifié au préalable.
La connexion au serveur de messagerie utilise les protocoles IMAP ou POP. Les options de
chiffrement SSL et TLS sont disponibles.

24
 Paramétrage

Pour ajouter un serveur de messagerie comme nouvelle source d'authentification

1. Aller dans le menu Configuration > Authentification > Serveurs de messagerie ;

2. Cliquer sur le "+" situé dans le menu horizontal ;

Nom : nom du serveur qui sera affiché dans glpi : Etic

Actif (active ou non le serveur de messagerie): oui

Nom domaine de messagerie (adresse de messagerie de type identifiant@domaine) :

informatiquenyse@gmail. corn

Serveur (le nom du serveur) : imap.gmail.com

Options de connexion(les paramètres optionnels de connexions au serveur) :

imap/ssl/val idate-cert/notls

Port (optionnel) : 993

Chaîne de connexion: {imap.gmail.com:993/imap/ssl/validate-cert/notls}

Après avoir rempli le formulaire, nous effectuons un test permettant de vérifier si la

connexion au serveur de messagerie a réussi

25
 Paramétrage

r' o. '"""' ? * o"'""'

.21 P•rt As1imnœ ou1ik Adnimtntion

,•• 1 c..liguntioo ~vthtoth,t... Serveurs de messa... + Cl

llJt, Serveur de messagerie· plurielles

StMurdt muu91nt

THttr
Cio;"t•I

Il
o ••
1 •••

r.t

'l'I~ ' SSl f j·".°'i.S ' ,-;1Ut)in-(?i t - 1 - t

,~,, ~,
(11NP,tmoltonttl/1Np/uVw11i111t1·ct~/ootls)

Figure 3: configuration du serveur de messagerie

Un utilisateur peut alors se connecter à partir de ses identifiants gmail.

111.2.3 les notifications par mail

Après avoir configuré le serveur de messagerie, nous allons maintenant configurer le
notifications. Les notifications permettent de recevoir des messages pour certaines action
prédéfinies. Les notifications de notre logiciel sont envoyées par mail. Il est donc nécessaire de
configurer la connexion à un serveur de messagerie. Par défaut, le suivi par mail n'est pa
configuré.

Dans l'onglet configuration/notification/configurer les suivis par courriels, nous remplisson

les différents champs du formulaire de configuration.

Utiliser le suivi par courriel : active ou non la gestion des notifications dans GLPl. Cette

configuration est globale à toute l'application : oui

26
 Paramétrage

Courriel de l'administrateur : l'adresse de messagerie de l'administrateur général de GLPI.

Cette adresse est utilisée lorsque !'Administrateur est sélectionné en tant que destinataire d'une
notification : informatiquenyse@gmail.com

Nom de l'administrateur: le nom de l'administrateur utilisé indique le nom associé au courriel

de l'administrateur : sasson

Courriel de réponse (si nécessaire): adresse de messagerie utilisée lorsque l'utilisateur répond
à une notification envoyée par l'administrateur. Nous avons utilisé la même adresse que celle
utilisée pour le courriel de l'administrateur: informatiquenyse@gmail.com

ignature des messages : texte ajouté à la fin de chaque notification. Celte valeur est globale
mais peut être adaptée pour chaque entité (optionnel) ·

Mode d'envoi des courriels :

1. PHP : l'envoi est géré par la fonction mail () de PHP. Celle-ci est très souvent
bloquée chez les hébergeurs ·
2. SMTP: envoi en utilisant le protocole SMTP;
3. SMTP + SSL : envoi en utilisant le protocole SMTP, encapsulé dans un tunnel
SSL;
4. SMTP + TLS : envoi de courriels plus sécurisé que SMTP + SSL ·

L'option utilisée est SMTP+SSL

Hôte(s) SMTP [: nom ou adresse [P du serveur de messagerie. Plusieurs serveurs peuvent être
précisés en les séparant par un point-virgule: smtp.gmail.com

Port: 465

Identifiant (login) SMTP (optionnel) : l'utilisateur autorisé à se connecter au SMTP :

info1111atiquenyse@gmail.com

Mot de passe SMTP (optionnel) : le mot de passe de l'utilisateur.

Après avoir rempli ces différents champs, un courriel test envoyé à l'adresse mail pour
vérification.
27
 Paramétrage

Acrnl ~ligiu1tio11 NotfullDns Configuration

Colll;IVllioll
NoolicJti1111s

:fü, ~ "·1 pll "'1"

dti12"",,.;m:1J llill"

SeM!Jr de m~erie

"tltl :~

ll!li:!'tlf'1' :~:-

Figure 4: configuration des notification

Dans notre cas, nous pouvons recevoir des notifications lorsqu'un ticket est créé ou fermé et
lorsqu'un jour est passé depuis la création du ticket et qu'il n'est toujours pas clo

/Tl2.4 la création d'une catégorie de ticket

Pour mieux cibler les tickets, il est nécessaire de créer des catégories. Ainsi lorsque le
utilisateurs vont créer des tickets ils peuvent directement choisir parmi une liste le logiciel
concerné.

Pour cela, il faut se connecter avec un compte administrateur puis aller sur le menu
configuration, intitulé, catégorie de ticket. Une page pop-up s'ouvre, c'est là que l'on saisit le
différentes catégories.

28
 Paramétrage

Lift< Catégorie de ticket - Logiciel Z,,1) )

Calegorit dt Udltl
Catégorie de lkket
t,tegones dt ttdltl
,., ~'
HdlOftllU<
c,,.,,,e ent1ntdt • G),
lous
F,soo,,ublt tuhn,ouo • pin thlodore

Groupe ttchn1Qwt .....• G),

&ue dt conna1su,icu LOGIC!El.S • (i)+

Ou
COf!lmentuu
,1b1f po1,1r un il'Cldtr\l Ov,

,s,ble GOUr..,,. dem1ndt

°'"'' '
v,1,bltpourunl)l®tme

v.1,bl, oo.r un c1>1n;,mec

°"' •
Gabont pou, une demirde • (i)

Gablr1t ~ un ln<tdtnt • G),

Figure 5: catégorie de ticket

Voici un exemple dans notre ca

(13)

O(IIC1el

Loo1clcl > autoca

001c,el > e,c

o•c•e.l > saari

001c1c1 > w1ndc-v

Log1c1el > word

1 1
Loo•c•el > wordpr---

M.atie.n

Mlltcnel > clav,cr

Mater'ICI > e.cran

Materu:I > hnprin·u,ntc

Matêrui!,I > souns

Figure 6: exemple de catégorie de ticket

29
 Paramétrage

IIJ.2.5 Interface ajout d'un équipement

e formulaire permet de faire l'inventaire du parc informatique de l'entreprise.

Il Ustc Ordinateur - ASS1STANTE !.• >

Ord1n11eu,
Ordlnottur
Coa1po.unb
Hom Staw<
Volumes
bu1uw • CD•
LOIIUdJ
-· .(j),
Co.n flQion,
•••••• (j)+
Parts l'H c.tu
hw'n.tfO dt ttfi

Gd"Uon
~~.tto â""'tnt:urc: lSSI

Ceint • (j) .•.• (j).

Oo<ummh -.(j),

M1duna; vutudl • (j).

Tlôru 0t.i,1C'ùf1 • G>•

Problttüff

(hMtfffll#T\t;
·- .(j).
LM1H Oltnl8 hoduct 10 du 1,1-t•..,, ct 1,piq+utf#"

N~tN

AtHtVaoen, WJO

Ht,lonQue
°'"' trt ""'" 1 fO\lt lt :?'0 16·U·Ol lS:2f
SC>ùlttOtf"\.11. t l)OIJf • (j),
Tou,

Figure 7: ajout d'un équipemen

III.3 Interface pour la gestion des incidents

Dans cette partie nous présenterons les quelques interfaces de cette application à partir d'un
cénario.
Un client a un problème avec son ordinateur, sa souris ne marche pas. Il envoie une demande
de tickets: le ticket passe à l'état nouveau. L'administrateur reçoit la demande: le ticket passe
de l'état nouveau à l'état attente d'affectation. Ensuite, l'administrateur attribue le ticket à un
technicien et planifie celui-ci en fonction de son emploi de temps. Le ticket passe de l'état en
attente à l'état en cours planifié. Le jour J le technicien va résoudre le problème de la souris. Le
problème étant résolu, le technicien fait passer le ticket de l'état en cours à l'état résolu et envoi
un suivi à l'administrateur. administrateur vérifie alors les comptes et envoie un survi au
déclarant. Celui-ci valide que la réponse apportée par le technicien correspond bien à ce qu'il
attendait et le ticket passe à l'état 'clos' sinon il est réouvert.

30
 Paramétrage

Œ.3.1 Connexion à l'application

La figure ci- dessous i ! lustre l'interface qui s'affiche à l'internaute désirant bénéficier des
fonctionnalités de notre système. Comme toute application, la sécurité d'accès est nécessaire.
L'internaute fournit alors ses paramètres, à savoir le mot de passe et le nom de l'utilisateur pour
vérification. Si les champs saisis ne sont pas corrects un message d'erreur est affiché. Dans le
cas contraire son menu s'affiche.

Figure 8: interface d'authentification

31
 Paramétrage

Il13.2 Interface de déclaration de l'incident du client

Après avoir renseigné les champs pour la connexion, le menu s'affiche. Le client peut alor
remplir les champs qui lui permettront de déclarer l'incident. Le ticket créé a le statut 'nouveau

Acmil

Oesuiptm de rlncident

-· , @ voir la base de connatsswr dt utte Clt19on1

Mi"I •

Si,1 p1r coiml

CotJrnl:i1s~c

m1 '

'! U

1<11~on

h11r (U Mio m11.mum)©

Glism et dtp0m Yol/1 fichi11 Id, ou

Coosissez IIIÎIU!f Aocoolklûrd~I
1

Figure 9 : Interface de déclaration de l'incident du collaborateur

32
 Paramétrage

I1L3.3 l'affectation de l'incident

L'administrateur se connecte à GLPI. Il accède à la console d'administration et visualise
directement les nouveaux tickets. li remplit les champs nécessaires à l'affectation de l'incident
et enregistre le formulaire. Le ticket pa au statut · en cours (attribué)
Accueil Assimnu

Ust, Ticket - SAARI :1: ) ~

Tldttl
Tkket ·ID: 17
l111ltment du brut 0
Date
d'ouverture
ll•ll-ll llSI ~ Date d'k!i~ance
tJtallques

Vllld1tlon1
Par • (u Dernière
1f..m,n r1iei1 m6-tl-ll ll:t9 çu d1119u1 umn
mod'rflatlon
fitments
Type Irodm • Catégorie Llg1ë! I > SIi~ • (i)t
Coûts

Tichts di pn>~t Statut Source de la

fn coùl'li~:tr~.el • ~~!\) • (u
demande
Probltmes
Validation K':11 ~-~~ 1 ,a ~!Ltt •

Clw19t111ents
Impact Mo,1n • Lieu :1-~N tT fl'WI d~~, AIJICII tT fl'l,lt, , (i)
Hlslonqut
Priorité Éléments
haw!t '
Tous associès O

Acteur Demandeur 1 Attribtléa t j

4' 11',I" n n1d111 (ù / , , lp1n 11114d0r1 (il/

rrtre

IIOfls.wlll!ESwir1~

Oesalptlon '(i)

Figure 10: Interface pour l'affectation de l'incident

33
 Paramétrage

fl/.3.4 la résolution de l'incident

Après avoir renseigné les champs nécessaires à sa connexion technicien accède à son
interface. Il peut alors saisie la résolution de l'incident.

La saisie d'une solution peut être facilitée par l'utilisation de 2 mécanismes :

•!• L'utilisation d'un gabarit de solution.

•!• L'extraction d'un élément de la base de connaissance. Pour cela, il faut cliquer sur
'Rechercher une solution', trouver l'élément de base de connaissances correspondant et
valider en choisissant Utiliser

ne fois la solution saisie, le ticket prend le statut 'Résolu', jusqu'à approbation de la solution.

List, Ticket · SAARI

Tkktt
Ajouter:
Tra1lemenl du hdtel o
• suivi
1
/ Tache V Solution
Stabsbquts

Validat,ons fKket

Elémtnls G1h1nt dt sotution

Couts oe :le solution ··- , (v

HlstonQut Enr1;,stm et IJouter I IJ tm 11 conn,,ssanc~ ~:i ,

Tous

-
A·~·I-
•
J

Omnpbon

Figure 11 : Interface pour la résolution et le rapport sur lincident

34
 Paramétrage

lll.3.5 Clôture de l'incident

Une fois lincident résolu, le déclarant se connecte pour approuver la solution ou la rejeter. Si
la solution est approuvée alors le ticket est clos. Dans le cas contraire, il est réouvert.

Ac.mil

Liste Ticket · SMRI t'U )

nckd
Historique des actions :
Traltement du Ucktt l
0 2016-12·12 13:4
StJtisllques ~
. s.ttioo~...
Eléments i~-
,\_)
tfütonque 1• ~himi11,~

Tous INMaàruP.rtlSCE1l~CI00ith00S CCHTACfER IWIRETOOR!U,\11. Sll 0 20l6-12-12 ll:4l

ESTToo»JRS OACTJ'/liE, LVIOOE'iî SEA.UEAClîlÊ AIJT(»Wl()JE 1ft'
v.Thi«lore
02016-11·2117:55 ---
ffe SAAR!
~(fJ IIOH SA,W 'IE S'W,1HJI
,__J
!liimillli~

Figure 12: clôture de l'incident

111.3.6 Gabarit de suivi et gabarit de tâches

e sont des modèles prédéfinis pour le suivi et les tâches comme c'est déjà le cas pour les
solutions et les tickets. Un gabarit définit un élément standard en pré-remplissant certains
champs qui seront réutilisés pour la création d'autres éléments. Cela permet de simplifier l'ajout
d'un grand nombre d'éléments quasi identiques. Ces gabarits permettront aux techniciens de ne
pas oublier certaines informations standards. lis permettront de communiquer plus souvent, plus
rapidement avec le client et de gagner du temps dans la gestion. Ces fonctionnalités n'existant
pas que nous uti I isons, i I nous a été alors demandé de les intégrer.

35
 Paramétrage

Pour chaque modèle concernant le gabarit de suivi, on peut définir:

•:• Une source du survi

•:• Un contenu
•:• Un commentaire

Après avoir renseigné la source du suivi, l'administrateur pourra créer les gabarits de survi en
donnant un nom, la source du suivi et un contenu. Ils seront alors utilisés lors du suivi des
tickets.

llste Gabarit ~e suivi · création ~'un compte .f\ )

Gabarit de suiri
Galiarit de suivi
H~torique
lil:n a11li:M111e,

Tous
~J!(I dl IUiil f·~ll ' @, com1rn1:am

on:tnu

A.;;. -1
••

Figure 13: création gabarit de suivi

Lors du suivi des tickets, lorsque le technicien choisit le gabarit de suivi, les champs 'source de
suivi' et 'description' sont remplis automatiquement.

36
 Paramétrage

Liste Ticket· HRE IS

Tidict
Ajouter:
Traltem,nt du lickd 1
J SUivl if Tâche ../ Solutlon
bltsbques

valldations Nouvel élément · Suivi

Eleme11ts G1bant dt IU<ii

Couts S0urc1 du su,.-.

TichtS de pro)et Prr.

Problt111tS B / u ~ îtltpoi~! • P111;11r,h1 1111 :: I= ',, ,. j ·:

Changemei1ls A·~· - '1, ~i J~
- - .J

Hlslonque 1~

,IC!lpbon
Tous

Gllsnz d déposez votre flchitt id, ou

CIIOUUl 111 th!! l«ui ltil!r ct,0111
!)Outtr un docum1 (64 M,o maumum,

Figure 14: suivi de ticket

Pour chaque modèle concernant le gabarit de tâches, on peut définir :

•!• Le Nom;
•!• La catégorie de la tâche ;
•!• Un contenu

L'administrateur crée les catégories de tâches à partir du menu configuration. Une fois les
catégories de tâches créées, il pourra à partir du même menu configuration créer les gabarits
de tâches en lui donnant un nom et un choix de catégorie. Le gabarit créé pourra alors servir à
remplir le formulaire des tâches des ticket....

37
 Paramétrage

K Listt Gaoarit ~e tâ(~e · installation ~e ~ilote li ) )

Ga~arit ~e tache
Gallarit lie tâc~e
ffiston~ue

Tous
rwrena;f~!fl , u

ntenu

B J ~ i î~!l1~1u , l~I • ~
•••••••• ,- i-
1-
~ ~ § ,•-__
____
~
~- }111
. ! I'
j

A,~. - J
••

Figure 9: création gabarit de taches

38
 Paramétrage
-------- -

Tlciet
Ajouter:
Traitement du Uciet

t1tisbqucs
0

• suivi 'f" Tache Doannt 1 ./ Solution

validations Nouvel élément· Tâche d'un ticket

Èleme11ts
Gabarit de tl:he nstillat.oo de ,1011 , (j) 1
Coùts
ate9or1 r!1mm11m1n1 • (j)
Tâches de pro)el
Statut A la,r! •
Probltmcs
?n., f{on '
ch1ngernen
D.iree
Histonque
8 / y 1i11 T1::!e ool1c1 • P11a;r1 ~.
Tous

--
A,~ •. - j ,J

Glissez et déposez vollt fichltt Id, ou

Cllolsm: 111 klœr Alrc111 t,;f~ eliool1
AJout!r un documt (6J H.o m111mJ111)

Par (j)

Figure 15: tâche d'un ticket

Ill.3. 7 L'envoi de message

Si l'envoi d'e-mail a longtemps été une solution intéressante pour envoyer des notifications aux

utilisateurs de nos applications/sites internet, la multiplication du SPAM et l'explosion du

nombre de ventes de smartphones ont placé les téléphones mobiles au cœur de l'information.
L'envoi SMS est donc devenu une solution simple et efficace pour rendre nos services plus
interactifs. A cet effet, Plusieurs solutions ont été développées pour intégrer l'envoi de sms.

39
1
Paramétrage

es solutions sont des A Pl et des services web. Pour notre part nous avons choisi l' API sms de
Nexorn (11].

Lorsqu'un utilisateur (collaborateur ou technicien) valide la déclaration d'incident aussitôt un

nouvel message est envoyé par le système sur le mobile de l'administrateur pour lui signaler la
création d'un nouvel incident.

ORANGE 13;30

creation d'un nouveau ticket

ORANGE 13.38

10 nov

creation d'un nouveau

ticket[Nexmo DEMO]
ORANGE 16:37

creation d'un nouveau

ticket[Nexmo DEMO]
ORANGE 16:45

t1,~r

creation d'un nouveau

ticket[Nexmo DEMO]
ORANGE 16.58

+ Entrez le message texte

Figure 16: message reçu

40
 Paramétrage

ID.4 Conclusion
Nous sommes parvenus au terme de ce chapitre dont l'objectif principal était de présenter le
produit final obtenu. A cet effet, nous avons tour à tour présenté le paramétrage de la solution,
les interfaces de notre solution puis nous avons présenté notre contribution à l'évolution de
l'application.

41
 CONCLUSION GENERALE
Ce document a été rédigé au terme du projet de fin d'études réalisé au sein de Plurielles
ntreprises, Ce projet a consisté à mettre en place une application pour la gestion du parc et des
incidents informatique de leurs clients. Cette application permettra d'améliorer le quotidien des
clients de Plurielles Entreprises.

Notre travail a fait appel à un grand sens de l'adaptation et de l'organisation. Il a permis une
étroite collaboration entre le département informatique et les autres départements. La réalisation
de ce projet a permis de mettre en pratique les connaissances acquises tout au long de notre
formation académique. Outre la mise en pratique de nos connaissances, le stage nous a permis
de nous imprégner des réalités de la vie professionnelle que sont: la ponctualité, l'assiduité, la
discipline, la rigueur dans le travail et l'esprit d'équipe.

Cependant, l'application soumis à notre étude peut être amélioré afin de la rendre
incontournable.

42
1

BIBLIOGRAPHIE
[l] Daniel Kervarec « ITIL et la gestion des problèmes», paru sur le site newsitiweb.info
[2] Pascal Delbrayelle (2004), ITIL V2 La gestion des incidents, Livre
[3] Christian Dumont, JTIL pour un service informatique optimal 2e édition EYROLLS
[4] Carina Roels (2016), « Débutez l'analyse avec Uml », article disponible sur le site
http://openclassroms.coure/courses/ débutez-l'analyse-avec-uml
[51 https://www.sourceforge.net/project astres
[6] https://www.osticket.com
[7] https://bestpractical.com/reguest tracker
[8] https://www.ostrs.com
[9] https://www.gestsup.com

110] Jean-Matthieu Doleans Et Frederic Ginioux, Project GLPI disponible sur https://glpi-
project
[llJ https://www.nexmo.com
[12J Nedge Ps (Professional Service), Système de notification par SMS (short message service)
des incidents informatique
[13) Gninatin Coulibaly (2016) « gestion des notes de l'ufr sfa » Université Nangui Abrogoua
Côte d'lvore
[14] Abdelkerim Douiri «Etude et développement d'une application de messagerie
électronique» Ecole Nationale des Sciences de L'informatique Tunisie

43
1

ANNEXES

1- ORGANIGRAMME DE PLURJELLE

ORGANIGIWBΠDE L'E~1REPRISE

Secrétaire et Assistarue
dedir(:(bOD

Dircct100 D1rcct1on
Administrattre et Techruque
f U1aDC1èrt

Coordonnateur de
PrOJei

~f.l
Admuustratû et
finanmr
Business
Dérelopper
1

C!]1~11 Responsable
Telécom
II Res~le
Informatique
Elcctric.itê

Comptable 1
l
Techruciens Tmciens J Tmciens
Gërue m11 Telecom J Informabque
~•.r-----{,

44
1- FICHE DE RAPPORT

RAPPORT D'INTERVENTION

DATE ET HEURE DE LA DEMANDE_

. ----------------------------

SERVICE···-·---------------··-·-·-----·----------------·---------
DEQ.AAATION ··-··----·---·--····--··--··--··-·--PrTELEPHONE. _

OESCRiPTION DE L'INCIDENT·--·-·--·--·····-·--·····--·--·····-··-·--···-····-··-··-·-···-··-··-··-···-··-·

IQENTJEIÇATIAN PV MATERIEL
TYPE··-·--·--·-····-··--·····--··--·····--··--··-··-·--··-···-··--····-·-·--·-····-·--····-··-·--·-··-·--··----

MARQUE · --··-·-··---· -·--····-··-·-----·--··-··-·------·-····--··-·-····---··-·--·····--·--·--· -··

N"SERIE ···--··--·······-····-··-·--········-·-·---·····--·····-FOURNISSEUR.--··-·--·-··--·····--··---········-··

N'O'INTERVENTION :---·---·--·--····--·--- TYPE D'INTERVENTION _

ETAT· -----··--·-------·--·· -··-·-------CADRE.---··---··--·-·-·--·----··--·····-·····-··

OEBUTD'INTERVENTION. _.C,AlJSE.. _

RN O'INTERVENllON REMEDE.-----·-··-·----·----·---···--······-··

SOCUTION · - - - ---···-·······-··

INTERVENANT
FONCTIONS NOM ET PRENOMS NUMERO DE MATRICULE

45