ETUDE ET MISE EN PLACE D'UNE APPLICATION DE GESTION DES

~========================================= 0 a 0 0 il 0 0 0 0 0 1 n r, [. r [ C n 0 u a a 0 0 a 0 l'Nl\'l.H'I 11 0 NANGUI AfiROGOt.:A a 0 1 r r, r C C r l a r- a ~ 0 u ~ 0 u r fi 0 a a a 0 0 0 u n 0 a a O Le jury n 0 0 a 0 a 0 0 D 0 0 0 0 0 a u l [J

REPUBLIQUE DE CÔTE-D'IVOIRE Union-Discipline-Travail

Université Nangui Abrogoua

2015-2016

Thème

Unité de formation et de recherche des Sciences

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

a J 3 a 0 a D n a a a 0 a 0 0 0 0 0 0 n 0 0 a 0 0 0 0 0 C D u

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

Fondamentale

~ il ~ u u 0 n 1 q ~ il 0 0 n a n a 0 n 0 a u n a a 0 u u

Directeur de mémoire: Prof. AKA Boko il J

Co-directeur: Dr. ZEZE DJEDJE Sylvain ~ 0 0 l a 0 0 D 0 1 0 r. r, a G n ~~~~~~~~~=~~~~~~~~~~=~~=~~=~=~=======~~~d

ETUDE ET MISE EN PLACE D'UNE APPLICATION DE GESTION DES INCIDENTS INFORMA TIQUES

MEMOIRE EN VUE DE L'OBTENTION DU DIPLÔME DE MASTER EN METHODES INFORMATIQUES APPLIQUEES A LA GESTION ET A L'ECONOMIE (MIAGE)

Présenté par : LASME AGNIME BENOITE NYSE EMMANUELLE

Président du jury : Prof. AKA Boko, Professeur Titulaire Membre : Dr. ZEZE DJEDJE Sylvain, Maître Assistant Membre: Dr. OUATTARA Mory, Assistant Membre : Ingénieur BOU Kuyo

Le 22 Décembre 2016

~=============~=<>======================================~ 0

0 0 0 0 0 0 r r n ü r r 1 L 1;

a n a 0 n ü Q 1 0 0 C 0 0 n u n 0 0 0 0 0 " a a 0 0 C 0 a a a 0 a a C a a a a a 1

a [) 0 n n n D n n 0 0 n ,J 0 0 0 0

. 0 a 0 a a a a 0 a 0 ] a 0 0 n G C n n 0 n 0 C 0 u 0 a u ] J 1 J 0 0 a a 0 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=~~~~~~~~~~~~~~~~~~===~

ANNEE UNIVERSITAIRE 2015-2016

Thème J ETUDE ET MISE EN PLACE D'UNE APPLICATION DE GESTION DES INCIDENTS INFORMATIQUES

MEMOIRE EN VUE DE L'OBTENTION DU DIPLÔME DE MASTER EN METHODES INFORMATIQUES APPLIQUEES A LA GESTION ET A L'ECONOMIE (MIAGE)

Présenté par : LASME AGNIME BENOITE NYSE EMMANUELLE

Le 22 Décembre 2016

~===~=~~~~~=~=~=~====================~==~~~=~=============••===~~~~======~=~~~~=~~ 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

introduction 3 I. I

1.2

1.2.1 l.2.2 1.2.3 1.2.4

1.3

1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

f..l

Présentation du cadre institutionnel , 3

Présentation de Plurielles Entreprises 3 Organisation 3 Présentation du département d'accueil 3 lients 4

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

Description del 'existant. 4 ritique de l'existant 4

Présentation générale du projet 5 Problématique 5 Objectifs du projet 5

onclusion 6

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

Il./

11.2

Introduction 8

Gestion des incidents 8

11.2.1 11.2.2

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

11.3 Expression des besoins 10

0.3.1 11.3.2 11.3.3 11.3.4 11.3 .5 II .3 .6

11.3.6.1 11.3.6.2 11.3.6.3 11.3.6.4 11.3.6.5 11.3.6.6

Fonctionnalités requises 11 Contraintes et exigences 11 Identification des acteurs 12 Identification des cas d'utilisation 12 Diagramme de cas d'utilisation 13 Solutions existantes sur le marché 14

ASTRES 14 OSTICKET 15 REQUEST TRAC KER 16 OTRS 17 GESTUP 18 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 111.2.2 1 II .2.3 (J] .2.4 111.2.5

Configuration d'un client 23 Ajout d'un serveur messagerie 24 Les notifications par mai 1 26 la création d'une catégorie de ticket 28 Interface ajout d'un équipement. 30

111.3 Interface pour la gestion des incidents 30 Til.3.1 111.3.2 II 1.3 .3 IJI.3.4 111.3.5 111.3.6 111.3.7

Connexion à l'application 31 Interface de déclaration de l'incident du client 32 l'affectation de l'incident 33 la résolution de ) 'incident 34 Clôture de l'incident.. 35 Gabarit de suivi et gabarit de tâches 35 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


11.2.2 Processus de gestion des incidents

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

V") u..J C)

> =:, V") ._ u..J u..J ___J

0 ex:: ._ :z: 0 <..J

DETECTION ET ENREGISTREMENT

ou, DEMANDE DE

RECHERCHE DES INCIDENTS CONNUS

INVESTIGATION ET DIAGNOSTIC

OUI

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


•:• 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

am,

ADMUIISTRAIBJ

\

'

C0/19JLTER LISTE DES UIODEHTS AFFECTES

~ ~NRE rnaDEm},',, \ ' 1 ',,o 1' ' ' ' l / ' \ ~ I '' ~r, '1i. ' {)' / ,, ', ','~, Il I ... ,j} ,,,, // .. '

''' ,,, // ,

~

GERELEMODULE JI ~/ OEC-AATU> , , ~~~~, p,

COIISULTER LA LISTER !IICIDEIITS , Jf II Rf~LUS ET HON RESOlUS 1

11

I 11

I ;i I PlANlflE LES 11/TERVEJITTOIIS 1 /

1 ______ ,,/, I I I I

DEFl!HR LES PRIORITES ) t 1 I

·G""~-ATI-STl-Q-UES-DES_I_IICI_D_EJIT_~

A/W. YSE ET ROO.UTIOI DE L111CIDBIT

REDACTION DE LA BASE DE CONNAISSHIŒ TEOiNICIEII

AGEIIT EXTERNE

13


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


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


15


•:• 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


•!• 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



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


•!• 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




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.

•!•

1 •:• •!•

•!•

•!•

•:•

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

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


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


1

•:• 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

•!• 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


•!• 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.

1

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

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


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.

1 CNDJ 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

1 23

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 : [email protected]

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: [email protected]

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 :

[email protected]

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

t,tegones dt ttdltl

HdlOftllU<

lous

,., c,,.,,,e ent1ntdt F,soo,,ublt tuhn,ouo

Groupe ttchn1Qwt

&ue dt conna1su,icu

Catégorie de lkket

~'

,1b1f po1,1r un il'Cldtr\l

,s,ble GOUr..,,. dem1ndt

v,1,bltpourunl)l®tme

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

Gabont pou, une demirde

Gablr1t ~ un ln<tdtnt

• G),

• pin thlodore

.....• G),

LOGIC!El.S • (i)+

Ou

Ov, COf!lmentuu

°'"'' '

°"' • • (i)

• 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

Ord1n11eu,

Coa1po.unb

Volumes

LOIIUdJ

Co.nflQion,

Parts l'Hc.tu

Gd"Uon

Ceint

Oo<ummh

M1duna; vutudl

Tlôru

Problttüff

(hMtfffll#T\t;

LM1H Oltnl8

N~tN

AtHtVaoen,

Ht,lonQue

Tou,

Ustc

Hom

Ordlnottur

Ordinateur - ASS1STANTE

•••••• (j)+

Staw<

!.• >

bu1uw • CD•

-· .(j),

hw'n.tfO dt ttfi

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

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

-.(j),

• (j).

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

·- .(j).

hoduct 10 du 1,1-t•..,, ct 1,piq+utf#"

WJO

SC>ùlttOtf"\.11. t l)OIJf

°'"' trt ""'" 1 fO\lt lt :?'016·U·Ol lS:2f • (j),

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 1Aocoolklûrd~I

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 ll•ll-ll llSI ~ Date d'k!i~ance

tJtallques d'ouverture

Vllld1tlon1 Par 1f..m,n r1iei1 • (u Dernière 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 fn coùl'li~:tr~.el • Source de la

~~!\) • (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 Tous haw!t ' 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 interface. Il peut alors saisie la résolution de l'incident.

technicien accède à son

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

Tra1lemenl du hdtel o

Ajouter:

• suivi Stabsbquts

Validat,ons

Elémtnls G1h1nt dt sotution

1/ Tache V Solution

fKket

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! ~(f J 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

Gabarit de suiri Galiarit de suivi

H~torique lil:n a11li:M111e,

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

on:tnu

.f\ )

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

Traltem,nt du lickd 1

bltsbques

valldations

Eleme11ts

Couts

TichtS de pro)et

Problt111tS

Changemei1ls

Hlslonque 1~

Tous

Ajouter:

J SUivl

G1bant dt IU<ii

S0urc1 du su,.-.

if Tâche ../ Solutlon

Nouvel élément · Suivi

Prr.

B / u ~ îtltpoi~! • P111;11r,h1 1111 :: I= ',, ,. j ·: A·~· - '1, ~i J~ - - .J

,IC!lpbon

!)Outtr un docum1

Gllsnz d déposez votre flchitt id, ou CIIOUUl 111 th!! l«ui ltil!r ct,0111

(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 ,

A,~. - ••

•••••••• ,- i- ~ . ! I' l~I • ~ ~ ~ § •- 1- ~ }111 ____ , __ - j

J

Figure 9: création gabarit de taches

38

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

Tlciet Ajouter: Traitement du Uciet 0 • suivi t1tisbqucs

validations

Èleme11ts Gabarit de tl:he

Coùts ate9or1

Tâches de pro)el Statut

Probltmcs ?n.,

ch1ngernen D.iree

Histonque

Tous

'f" Tache Doannt 1 ./ Solution

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

nstillat.oo de ,1011 , (j) 1

r!1mm11m1n1 • (j)

A la,r! •

f{on '

8 / y 1i11 T1::!e ool1c1 • P11a;r1 ~. A,~ •. - - - j ,J

AJout!r un documt

Glissez et déposez vollt fichltt Id, ou Cllolsm: 111 klœr Alrc111 t,;f~ eliool1

(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 Administrattre et f U1aDC1èrt

D1rcct1on Techruque

Coordonnateur de PrOJei ~f.l Business

II Res~le

Admuustratû et Dérelopper 1

C!]1~11 Responsable Informatique

finanmr

Elcctric.itê Telécom

l J Tmciens Tmciens

1 Comptable

Techruciens Telecom J Inf ormabque Gërue m11

~•.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

Documents

ETUDE ET MISE EN PLACE D'UNE APPLICATION DE GESTION DES