‫جامعة تونس االفتراضية‬

Université Virtuelle de Tunis

Mastère professionnel en Optimisation et

Modernisation des Entreprises MOME
Version finale
Présenté par

Ahmed Mellef
Pour l’obtention du

Diplôme de mastère professionnel

Mise en place d’un système de gestion des incidents

informatiques

Réalisé à
La Poste Tunisienne
Soutenu le 17/06/2017

Devant le Jury :
Président : M. Rached BOUSSEMA
Rapporteur : M. Zahran BESSAIDI
Encadreur Organisme d’accueil : M. Ridha BORGI
Encadreur UVT : M. Abderrahmen OUESLATI
Année Universitaire : 2016/2017
 Remerciements

Mes remerciements les plus sincères s’adressent à mon encadreur M. Abderrahmen

OUESLATI, pour l’aide considérable qu’il m’a apporté au cours de mon travail et je tiens à
exprimer mes vifs remerciements à M. Helmi BEN REJEB coordinateur du mastère MOME,
pour ses conseils, ses précieuses directives et sa disponibilité tout au long de notre formation.

Je tiens à exprimer tous mes sentiments de respect, de gratitude et de reconnaissance à tous

ceux qui ont participé à notre formation durant ces deux années d’études.

Je remercie également la direction de la Poste Tunisienne pour sa confiance en ma personne et

son assistance et bienveillance tout au long du projet ainsi que toute l’équipe du service
technique de la poste qui a contribué activement à la réussite de ce projet.

Mes remerciements s’adressent également aux membres de jury qui ont accepté de juger mon
travail.

1
 Dédicaces

A tous ceux qui m’ont aidé à établir ce travail

Pour tous les sacrifices consentis et les diverses compétences.

Je dédie ce travail :

A mes chers parents MOHAMED ARBI & NESSIMA, MONGI & RADHIA

Pour leur amour, leur confiance et leur encouragement qu’ils n’ont cessé de me fournir durant
toute ma vie et sans limite.

A ma très chère femme NESRINE qui n’a cessé d’être à mes côtés et a beaucoup sacrifié pour
moi.

A mes chers frères ANIS, MOHAMED, SAMI, WALID, SAHBI et mes chères sœurs
SAYDA, NEJLA et HANA qui n’ont pas arrêté de m’encourager tout au long de mes études.

A toute ma famille

A tous mes cher(e)s ami(e)s, à tous ceux qui m’ont soutenu et m’ont beaucoup aidé tout au
long de mon rapport et tous ceux que j’aime.

Que ce travail soit l’expression de ma profonde affection que je leur porte.

2
 Résumé

Un des soucis majeurs pour les directions des systèmes d’information des
entreprises est de fiabiliser au maximum les outils utilisés en fonction de leurs
charges et capacités pour pouvoir faire face aux besoins de ses utilisateurs et les
livrer à temps.

C’est dans ce cadre que s’inscrit notre projet de fin d’études qui a pour objectif
l’amélioration continue des pratiques et de satisfaction des utilisateurs de service
informatique de La Poste Tunisienne par la mise en place d’un système de
management des incidents en s’appuyant sur des référentiels et des standards.

Mots clés: GLPI, processus, résistance au changement, ITIL, La Poste Tunisienne.

Abstract

One of the main concerns of administration information systems in companies is to

provide maximum reliability of used tools according to their ability to meet users
needs and to deliver on time.

In this context, I’m writing my final year project which aims to continuously
improve practices and to satisfy the computer users of the Tunisian Post by the
establishment of an incident management system based on references and
standards.
Key words: GLPI, process, resistance to change, ITIL, Tunisian Post.

‫ملخص‬

‫يكمن الشكل الرئيسي في إدارة نظم المعلومات بالمؤسسات في إعطاء أقصى قدر من‬
‫الموثوقية لألدوات المستخدمة وفق قدرتها على تلبية إحتياجات مستخدميها و تسليمها في‬
.‫الوقت المحدد‬
‫ففي هذا اإلطار يندرج مشروع ختم الدروس الذي يهدف إلى التحسين المستمر للتطبيقات‬
‫و إرضاء مستخدمي منظومة اإلعالمية بالبريد التونسي من خالل إنشاء نظام إدارة الحوادث‬
.‫القائم على جملة من المعايير و المقاييس‬

‫ مكتبة البنية التحتية لتكنولوجيا‬,‫مقاومة التغيير‬, ‫عملية‬,‫جلبي‬:‫الكلمات المفاتيح‬

. ‫البريد التونسي‬,‫المعلومات‬

3
 Table des matières
INTRODUCTION GÉNÉRALE ............................................................................................................. 7
CHAPITRE 1 : PRÉSENTATION DE L’ENTREPRISE ET CONTEXTE DU PROJET......................................... 8
1.1. Présentation de l’entreprise ...................................................................................................... 9
1.1.1. Domaines d’Activités Stratégiques (DAS) ...................................................................... 10
1.1.2. Orientation stratégique .................................................................................................... 11
1.1.3. Organisme d’accueil ........................................................................................................ 11
1.2. Contexte du projet .................................................................................................................. 12
1.2.1. Problématique .................................................................................................................. 12
1.2.2. Contraintes du projet ....................................................................................................... 12
1.2.3. Estimation des charges du projet ..................................................................................... 13
1.2.4. Phases de projet ............................................................................................................... 13
1.2.5. Cadrage du projet ............................................................................................................ 14
1.2.5.1. Objectifs ................................................................................................................... 14
1.2.5.2. Macro-planning du projet ......................................................................................... 14
CHAPITRE 2 : ETUDE DES BESOINS ET ETAT DE L’ART ...................................................................... 18
2.1. Etude des besoins ................................................................................................................... 19
2.1.1. Analyse et critique de l’existant ...................................................................................... 19
2.1.2. Identification des problèmes............................................................................................ 23
2.1.3. Rechercher les causes racines : Brainstorming................................................................ 24
2.1.4. Analyser et visualiser les causes : Diagramme d’Ishikawa ............................................. 25
2.1.5. Valider les causes principales : Diagramme de Pareto ................................................... 25
2.2. Etat de l’art ............................................................................................................................. 26
2.2.1. Besoins fonctionnels........................................................................................................ 26
2.2.2. Etude comparative des logiciels de gestion des incidents ............................................... 27
CHAPITRE 3 : MODÉLISATION DU PROCESSUS DE GESTION DES INCIDENTS ...................................... 30
3.1. Processus de gestion des incidents ......................................................................................... 31
3.1.1. La gestion des incidents selon le référentiel ITIL ........................................................... 31
3.1.2. Avantages et difficultés de la gestion des incidents ........................................................ 37
3.1.2.1. Avantages ................................................................................................................. 37
3.1.2.2. Difficultés potentielles.............................................................................................. 38
3.1.3. Modélisation du processus de gestion des incidents de La Poste Tunisienne ................. 38
CHAPITRE 4 : MISE EN ŒUVRE DE LA SOLUTION RETENUE ............................................................... 44
4.1. Déploiement de la solution GLPI ........................................................................................... 45
4.2. Conduite de changement ........................................................................................................ 51
4.3. Amélioration continue du système mis en place .................................................................... 53
4.3.1. Analyse des indicateurs clés de performances ................................................................ 53
4.3.2. Plan d’actions correctives ................................................................................................ 57
CONCLUSION GÉNÉRALE ............................................................................................................... 60
RÉFÉRENCES BIBLIOGRAPHIQUES .............................................................................................. 61
ANNEXES ................................................................................... ERREUR ! SIGNET NON DÉFINI.

4
 Liste des figures
Figure 1.1 : Planning prévisionnel Diagramme de Gantt ......................................................... 17

Figure 2.1: Satisfaction par rapport à la disponibilité du service ............................................. 20

Figure 2.2: Qualité d’intervention des techniciens ................................................................... 20

Figure 2.3: Taux d’incidents par mois ..................................................................................... 21

Figure 2.4 : Appréciation globale des guichetiers .................................................................... 21

Figure 2.5 : Diagramme de Pareto ........................................................................................... 25

Figure 3.1 : ITIL version 3 -2011 ............................................................................................. 32

Figure 3.2 : Schéma de cycle de vie d’un incident ................................................................... 35

Figure 3.3 : Schéma de gestion des escalades .......................................................................... 36

Figure 4.1 : Matrice de calcul de priorité des tickets dans GLPI de La Poste ......................... 46

Figure 4.2 : Métriques Helpdesk GLPI de La Poste ................................................................ 47

Figure 4.3 : Suivi d’un ticket jusqu’à sa clôture ...................................................................... 47

Figure 4.4 : Statistiques des tickets par technicien ................................................................... 48

Figure 4.5 : Pourcentage de temps de résolution des tickets .................................................... 48

Figure 4.6 : Nombre d’incidents par niveau de support ........................................................... 49

Figure 4.7 : Nombre de tickets gérés par contrats de service SLA .......................................... 49

Figure 4.8 : Tickets par origine de réclamation ....................................................................... 50

Figure 4.9 : Nombre de tickets par état d’incident ................................................................... 50

Figure 4.10 : Les difficultés rencontrés lors du déploiement de la solution ............................ 51

Figure 4.11 : Formulaire de satisfaction client développé dans GLPI de La Poste ................. 56

5
 Liste des tableaux
Tableau 1.1 : La Poste Tunisienne en chiffres ............................................................................................ 9

Tableau 1.2 : Macro planning du projet ................................................................................................... 16

Tableau 1.3 : Planning réel et livrables du projet..................................................................................... 17

Tableau 2.1 : Identification des problèmes Méthode QQOCCP ............................................................... 24

Tableau 2.2 : Benchmarking des logiciels de gestion des incidents ......................................................... 28

Tableau 3.1: Les différents états d’un incident ........................................................................................ 37

Tableau 3.2 : Rôles et responsabilités du processus de gestion des incidents ........................................ 40

Tableau 3.3: Modélisation du processus de gestion des incidents de La Poste....................................... 41

Tableau 4.1 : Respect des délais max de résolution des incidents .......................................................... 54

Tableau 4.2 : Pourcentage des KPI par rapport à la valeur cible.............................................................. 54

Tableau 4.3 : Résultats des questionnaires de satisfaction par niveau ................................................... 56

Tableau 4.4 : Plan d’actions correctives ................................................................................................... 59

6
 Introduction générale
La Poste Tunisienne est une entreprise publique offrant des services postaux,
financiers et électroniques aux particuliers et aux entreprises.

Les prestations de services génératrices de revenus pour la poste Tunisienne s’appuient

dans une large mesure sur des systèmes informatisés d’où l’importance majeure pour
l’entreprise d’avoir un niveau de service optimal de ses systèmes productifs
informatisés.

Les guichetiers au niveau des bureaux de postes et des agences rapide poste trouvent
des difficultés à servir leurs clients à cause des incidents majeurs de diverses natures qui
surviennent au niveau de leurs postes de travail, engendrant ainsi des coûts
supplémentaires et un impact négatif sur les coûts , les délais et la qualité de service.

Le centre de services est peu structuré. Il en résulte une série de problèmes internes
visibles à plusieurs niveaux : exécutif, administratif et opérationnel.

Le présent stage de fin d’études consiste à piloter le projet initié par la Poste
Tunisienne pour mettre en place un système centralisé de gestion des incidents
informatiques et ce dans le cadre d’une équipe pluridisciplinaire mise sur pied à cette
fin.

Notre mission consiste à travailler sur la définition des spécifications fonctionnelles de

l’outil informatique à mettre en place, la définition et l’implémentation du processus de
gestion des incidents dans la solution retenue et la conduite du changement nécessaire
pour son acceptation par les utilisateurs cibles.

7
1. Chapitre 1 : Présentation de
l’entreprise et contexte du projet

8
 1.1. Présentation de l’entreprise
La Poste Tunisienne, dénomination commerciale de l’office national des postes (ONP)
est une entreprise publique tunisienne de service postal à la base.

Depuis le 1er janvier 1999, à la suite du retrait des activités de téléphonie, elle est
devenue un établissement à caractère industriel et commercial et un nouvel
organigramme a été élaboré (voir Annexe 1).

Le tableau 1.1 ci-dessous résume les statistiques de l’année 2015 concernant La Poste
Tunisienne :

L
Indicateurs 2015
Effectif 9 706
Taux d'encadrement 36,30%
Nombre de courrier ordinaire 77 800
Nombre de courrier hybride 24 700
Nombre de courrier publicitaire 4 310
Nombre d'envois Rapide-Poste (express mail) 1 395
Nombre de colis postaux 204
Nombre d'épargnants à la Poste 3 764
Nombre de mandats électroniques à l'échelle nationale 16 718
Nombre d'opérations de transfert électronique d'argent provenant de
1 091
l'étranger
Montant de virements d'argent via CCPN et
3 982
(en million de dinars)
679
Montant des transferts reçus de l'étranger en Devises (en million de dinars)

Nombre d'opérations de paiement sur Internet 687 145

Réseau commercial de la poste

Nombre de bureaux de Poste 1 051
Nombre d'agences Rapide-Poste 35
Nombre d'agences Poste-Colis 28
Nombre de Centres de distribution 64
Nombre de distributeurs automatiques de billets (DAB) 178

Tableau 1.1 : La Poste Tunisienne en chiffres

9
 La principale mission de La Poste Tunisienne est d’être le premier fournisseur aux
citoyens tunisiens et étrangers en Tunisie :

o Des services postaux : la collecte, le transport et la distribution de courrier, la

fabrication et la vente des timbres postaux et philatélie ;

o Des services financiers : dépôt et retrait d’argent (ccp, épargne), transfert

d’argent (mandats nationaux et internationaux), service de change de devises,
intermédiation en matière de service d’assurance vie et SICAV) ;

o Des services électroniques (mobile payment, e-parcel, ccpnet, mailpost, e-dinar,

e-billing…).

La vision de La Poste Tunisienne à long terme consiste à :

Etre un partenaire privilégié et solidaire des postes étrangères et notamment arabes et

africaines, en garantissant des produits et des services modernes de qualité en vue de
satisfaire la clientèle et favoriser la croissance des services électroniques postaux dans
les pays africains.

1.1.1. Domaines d’Activités Stratégiques (DAS)1

-Nouveaux supports financiers : CCP avec 1,8 million comptes.

-Inclusion financière : 3,5 millions particuliers non bancarisés avec 425000 TPE
d’après une étude menée par la banque mondiale.

-Mandats : 12 millions mandats organismes par an.

-Inter bancarité : 2 637 123 comptes de dépôt à vue (chiffre APBT 2015).

1
DAS : Domaine d’Activités Stratégiques, un ensemble de produits qui partage les mêmes ressources, affronte les
mêmes concurrents et peuvent faire l'objet d'une stratégie spécifique d’une entreprise.

10
1.1.2. Orientation stratégique

La Poste Tunisienne oriente ses investissements et ses efforts sur quatre axes
stratégiques comme suit:

Axe numérique

Renforcer le rôle primordial de la Poste tunisienne pour le développement de

l’économie numérique en Tunisie par les moyens modernes de communication tel que la
téléphonie mobile et l’internet.

Axe des services postaux

Moderniser les services postaux par l’amélioration de la qualité des services, la

fiabilité et la rapidité.

Axe des services financiers

Moderniser les services financiers par des réformes structurelles, la diversification des
produits financiers et des cartes électroniques.

Axe logistique

Renforcer le rôle de la Poste numérique dans un système logistique smart qui

comprend les enjeux et les technologies modernes pouvant assurer le développement du
commerce électronique et du projet « Tunisie Numérique ».

1.1.3. Organisme d’accueil

Notre projet de fin d’études s’est déroulé au sein du centre de développement et des
technologies postales (CDTP) qui travaille en étroite collaboration avec le centre
informatique et l’unité numérique dans tous les projets informatiques de la Poste (voir
Annexe 1).

La direction CDTP a pour mission de :

 faire des études et des recherches pour le développement des produits postaux,
financiers et électroniques de la Poste.

11
  Gérer un ensemble de plateformes (messagerie, SMS, Web Hosting, applications
métiers…) hébergées dans un Datacenter dédié.

1.2. Contexte du projet

Actuellement, la DSI2 de La Poste Tunisienne ne dispose d’aucun moyen pour
enregistrer et garder une traçabilité des incidents réclamés par les clients internes
(utilisateurs) de la Poste.

Le but de ce projet est d’identifier et mettre en œuvre une solution appropriée

permettant aux informaticiens de la Poste de gérer les incidents selon les meilleures
pratiques du management de système d’information.

1.2.1. Problématique

Dans quelle mesure la mise en place d’un système de gestion des incidents dans un
centre de service au sein de la Poste Tunisienne permet-elle l’amélioration de la
performance technique des informaticiens et le renforcement de la qualité de service
offert par les guichetiers à la clientèle dans les bureaux de poste?

1.2.2. Contraintes du projet

Dans le cadre de notre projet, on doit faire face à plusieurs contraintes :

Le coût qui est un paramètre très important à prendre en compte avant tout acquisition
et mise en place d’un outil de gestion des incidents. On peut procéder autrement, à
travers une solution de type open source qui engendre une réduction de coût en prenant
en compte le budget réservé par la DSI de La Poste.

Une contrainte de temps pour la mise en place : installation, configuration, tests et

validation de l’outil de gestion des incidents qui devra répondre aux besoins de La
Poste, facile à manipuler et évolutif.

2
DSI : Direction de système d’information, est la direction responsable du système d’information d’une entreprise.
Elle est en charge de définir l’architecture du système d’information, concevoir, installer et déployer et exploiter le
SI.

12
 La résistance au changement peut constituer la principale contrainte avec un personnel
qui veut toujours garder ses habitudes de travail et qui peut ne pas accepter facilement
l’intégration d’un nouvel outil de travail.

1.2.3. Estimation des charges du projet

Il faut estimer la taille du projet et fixer un périmètre bien déterminé en se basant sur
une description des besoins qui sont définis en fonction de l’outil de gestion des
incidents à installer.

On va tester l’outil sur 3 sites pilotes pour le déployer à long terme sur tous les centres
et les bureaux de poste.

L’estimation du délai consiste à déterminer les délais à partir de la charge estimée. Le

délai pour réaliser ce projet est de 4 mois, au bout desquels il faudra être en mesure de
pouvoir déployer, implémenter et tester cet outil de gestion des incidents sur les sites
pilotes choisis.

On va estimer le coût total du projet selon le type de l’outil de gestion des incidents à
choisir, si c’est un outil propriétaire, le coût sera important en incluant la maintenance,
le support et la formation pour pouvoir maîtriser et manipuler le logiciel.

Par contre, dans le cas d’un outil open source3, le coût sera bien réduit et La Poste
dépensera beaucoup moins surtout si la formation sera prise en charge par l’équipe du
projet en pleine autonomie (auto formation).

1.2.4. Phases de projet

La chronologie du projet devait suivre la démarche qualité générique PDCA4 en

s’articulant autour de quatre axes :

Plan : expressions correcte des besoins en définissant le cahier des charges, les
activités, les tâches et l’établissement d’un planning prévisionnel.
3
Outil open source : un programme informatique dont le code source est distribué sous une licence permettant à
quiconque de lire, modifier ou redistribuer ce logiciel.
4
PDCA : La Roue de Deming qui a été popularisée par William Edwards Deming, promoteur de la qualité made
in Japan. Cette méthode présente les 4 phases (Plan, Do, Check, Act) à enchainer successivement afin de s'inscrire
assurément dans une logique d'amélioration continue.

13
 Do : Développer, réaliser et mettre en œuvre GLPI :

Analyse de l’existant, une étude comparative des solutions de gestion des incidents
informatiques existantes sur le marché et la modélisation du processus de gestion des
incidents.

Déploiement de la solution logicielle retenue sur un environnement virtuel puis sur un

site pilote afin de la généraliser à long terme sur l’ensemble des centres et bureaux de
poste et rédaction des documents techniques à destinations des utilisateurs.

Check : contrôler les ressources mises en œuvre dans l’étape (Do) et vérifier que les
résultats obtenus correspondent bien à ce qui a été prévu (plan).

Tests et validation de la solution.

Act, adjust : Ajuster les écarts, rechercher des points d’amélioration et déduire les
actions à mener.

Mettre en place un plan d’actions d’amélioration continue du processus de gestion des

incidents.

1.2.5. Cadrage du projet

1.2.5.1. Objectifs

Dans un objectif d’amélioration de ses pratiques et de satisfaction de ses utilisateurs, la

DSI de La Poste Tunisienne a initié un projet cadre de mise en place d’un système de
management des incidents.

Son objectif est d’optimiser continuellement la qualité de service informatique en

s’appuyant sur des référentiels. Ces référentiels permettent à la fois de bénéficier d’un
label, de disposer d’un support méthodologique, de travailler en processus transversal et
d’utiliser une terminologie commune.

1.2.5.2. Macro-planning du projet

Durant le projet, Il y aura un ensemble d’activités qui vont contribuer à des résultats
tangibles et mesurables pour atteindre des objectifs.

14
Phases du Date Résultats Indicateurs
Activités Date fin
projet début tangibles mesurables(KPI)

Réunion du démarrage
avec les parties 01/02/2017 01/02/2017
Lancement du Charte de
prenantes
projet projet
Définition de la charte
02/02/2017 03/02/2017
de projet

Collecte
Tableau
d’informations et
QQOQCCP
analyse des besoins

Etude et extraction des

06/02/2017 24/02/2017
défaillances au niveau
Diagramme
Etude de du processus de
d’Ishikawa
l’existant et gestion des
état de l’art incidents existant.

Tableau
Benchmarking des comparatif des Des indicateurs de
solutions de gestion 27/02/2017 03/03/2017 solutions les performance des
des incidents. plus solutions proposées
pertinentes

Etude des démarches

de management de
système d’information 06/03/2017 09/03/2017
(ITIL, ISO 20000,
Modélisation
9000…).
du processus
Logigramme
de gestion
du nouveau
d’incidents Cartographie du
processus de
processus selon le 10/03/2017 15/03/2017
gestion des
référentiel ITIL.
incidents selon
ITIL

Définition des Réduction du coût des

Mise en œuvre Améliorer le
spécifications incidents (taux
de la solution 16/03/2017 20/03/2017 business et
fonctionnelles et non d’impact des incidents
retenue l’efficience
fonctionnelles de la sur les utilisateurs).

15
 solution logicielle à
Contrôle et
implémenter. Nombre d’incidents
résolution des
résolus
incidents

Installation,
Augmenter le taux de
configuration et
satisfaction des
implémentation du
Garantir la utilisateurs, diminuer
système open source
21/03/2017 11/04/2017 satisfaction des le temps d’attente pour
de gestion des
utilisateurs déclarer un incident et
incidents (GLPI) sur
le temps moyen de
un environnement
diagnostic.
virtuel.

Tests et validation de Maintenir des

Augmenter le taux de
la solution GLPI sur 12/04/2017 28/04/2017 services de
disponibilité de service
un site pilote. qualité

Mettre en place un
plan d’actions
Amélioration
d’amélioration Plan d’actions
du système 01/05/2017 15/05/2017
continue du processus correctives
mis en place
de gestion des
incidents.

Tableau 1.2 : Macro planning du projet

Afin de visualiser l’état d’avancement du projet avec ses différentes étapes, activités et
tâches. On a eu recours à une représentation graphique à savoir le diagramme de Gantt 5
pour présenter le planning prévisionnel du projet.

5
Diagramme de Gantt : un outil utilisé (souvent en complément d'un réseau PERT) en ordonnancement et en
gestion de projet et permettant de visualiser dans le temps les diverses tâches composant un projet.

16
 Figure 1.1 : Planning prévisionnel Diagramme de Gantt

Le tableau ci-dessous récapitule les différentes phases du planning réel ainsi que les
livrables du projet :

Phase Livrables Responsable Date Date Validation

livraison livraison
prévue réelle

Lancement du PV de définition et de validation de AHMED 03/02/217 03/02/217 validée

projet périmètre et du planning MELLEF
prévisionnel du projet

Etude de Tableau comparatif des outils de AHMED 03/03/2017 03/03/2017 validée

l’existant et état gestion des incidents MELLEF
de l’art

Modélisation du Document détaillé : logigrammes, AHMED 15/03/2017 24/03/2017 validée

processus tableau des rôles et des MELLEF
responsabilités et fiche procédures
de processus de gestion des
incidents de LA Poste.

Mise en œuvre -Document technique de la solution. AHMED 25/04/2017 21/04/2017 validée

de la solution MELLEF
-Manuel utilisateur.

Amélioration Plan d’actions correctives en se AHMED 22/05/2017 22/05/2017 validée

continue du basant sur l’analyse des KPI de MELLEF
système l’outil.

Tableau 1.3 : Planning réel et livrables du projet

17
2. Chapitre 2 : Etude des besoins et
Etat de l’art

18
 2.1. Etude des besoins
Cette phase d’étude comprend les tâches qui permettent notamment de déterminer, au
niveau fonctionnel, les exigences du système à mettre en place en prenant en compte les
divergences possibles entre les exigences des différentes parties prenantes telles que les
utilisateurs, la direction générale, la DSI, etc.

2.1.1. Analyse et critique de l’existant

Pour enregistrer un incident informatique, un bureau de poste réclame par téléphone,

par fax ou par mail à la direction régionale concernée qui contactera le pôle
informatique en cas de besoin et va coordonner avec le centre informatique pour
remédier à l’incident. Cette démarche pouvait se faire à distance ou parfois nécessite la
mobilisation d’un technicien sur les lieux de l’incident (voir Annexe 2).

Le client (utilisateur) servit par le centre informatique est le guichetier6.

Le guichetier a besoin de l’aide au niveau de :

 l’infrastructure, du poste de travail et des logiciels bureautiques.

 une ou plusieurs applications Web (applications métiers : Mandats minute, IFS,

eurogiro, CCP, RAPID, Epargne, Post Assurances, Monétique…).

Un questionnaire de satisfaction client (voir Annexe 3) a été diffusé par mail et par fax
à l’attention d’un échantillon de 100 bureaux de postes couvrant les 24 gouvernorats du
pays.

Les résultats issus du traitement de ce questionnaire sont synthétisés ci-après :

6
Guichetier : un agent dans un bureau de poste qui rend des services postaux financiers et électroniques dans un
bureau de post à des clients particuliers et entreprises.

19
 En analysant la figure ci dessous, on remarque une insatisfaction globale des
guichetiers qui atteint 80% par rapport au délai de prise en compte de l’intervention par
le technicien.

Figure 2.1: Satisfaction par rapport à la disponibilité du service

La figure 2.2 nous indique que 80% des bureaux de poste confirment que les
explications fournies par les techniciens ne sont pas claires et qu’ils ne comprennent pas
très bien leurs réclamations.

Figure 2.2: Qualité d’intervention des techniciens

20
 Un taux d’incidents clôturés très faible qui ne dépasse pas 6% :

Figure 2.3: Taux d’incidents par mois

La figure 2.4 résume le mécontentement des guichetiers du service offert par la

direction informatique de la Poste avec une satisfaction globale très faible de 10% .

Figure 2.4 : Appréciation globale des guichetiers

En se basant sur ces résultats et les observations mentionnées par les guichetiers dans
les 100 questionnaires envoyés aux bureaux de poste , nous avons déduit :

-Un taux d’incidents non résolus très élevé qui atteint 67% du nombre total
d’incidents.

-Une absence de catégorisation et de priorisation des demandes d’intervention.

21
 - Une plainte des guichetiers suite au manque de suivi des interventions de la part du
service informatique : une insatisfaction qui atteint les 90%.

-Plusieurs intervenants sur un même incident, personne n’a une responsabilité claire
d’une tâche durant une période spécifiée (Qui fait Quoi ?).

-Des incidents qui se reproduisent bien qu’ils aient été réglés.

- Absence de traçabilité des problèmes résolus auparavant.

-Des délais de réponse aux incidents trop longs dépassant 7 heures, parfois pas de
réponse.

-Taux d’insatisfaction par rapport au délai moyen de résolution d’un incident qui
dépasse 90%.

- L’absence de statistiques et de métriques7 des incidents et des demandes

d’intervention.

-Un processus de gestion des incidents qui n’est pas claire, obsolète et quasi absent.

-L’absence d’un système informatique de gestion d’incidents.

-Un problème de communication dû à l’absence d’un vocabulaire standardisé entre les

équipes du centre de service et les différents centres et bureaux de postes.

-Les processus, les procédures, la terminologie, les règles de gestion et les niveaux de
services ne sont pas documentés. De plus, ils diffèrent selon le type de soutien
technique.

7
Métriques : une compilation de mesures issues des propriétés techniques ou fonctionnelles d'un logiciel.

22
 2.1.2. Identification des problèmes

Afin d’identifier clairement et formaliser le problème, on a eu recours à la méthode

QQOQCCP8 :

QQOQCCP Description Questions à se poser

Un processus de gestion des incidents obsolète:

-pas de procédure claire de résolution des De quoi s’agit-il?

incidents.
Que s’est-il passé?
Quoi ?
-Délai de réponse aux incidents trop longs,
Qu’observe-t-on?
parfois pas de réponse.

-Absence de catégorisation et de priorisation des

demandes d’intervention

-Direction générale (DG)

-D.Centrale des produits postaux et financiers. Qui est concerné?

Qui ?
-Les équipes techniques (DSI). Qui a détecté le problème?

-Les guichetiers et les gestionnaires.

-Bureaux de postes, centres des applications

Où ? Où cela s’est il produit?
métiers, agences rapide poste.

-quotidiennement.
A quel moment?

-dans les horaires de travail (8h à 17h).

Quand ? Depuis quand?

-plusieurs fois par jour sur des laps de temps

Combien de fois par cycle?
variables.

Comment ? -Nombre élevé de réclamations. -De quelle manière?

8
QQOQCCP : Qui Quoi Où Quand Comment Combien Pourquoi, est un outil d'identification aux multiples
applications. Dans un contexte qualité, il sera utilisé autant pour définir un nouveau processus que pour contribuer
à la résolution d'un problème existant.

23
 -Optimisation du processus de gestion des -Dans quelles circonstances?
incidents.
-Comment mettre en œuvre
-Mise en place d’un système informatique de les moyennes nécessaires?
gestion des incidents.
Avec quelles procédures?
-Changement des procédures organisationnelles
de travail au sein du centre de service.

Quels coûts?
-Ressources humaines, matérielles et logicielles.
Combien ? Quels moyens?
-développement interne de la solution.
Quelles ressources?

-Amélioration de la performance technique des

informaticiens de la Poste.
Dans quel but ?
Pourquoi ? -Renforcement de la qualité de service.
Quelle finalité?
-un système de gestion des incidents informatisé
basé sur des indicateurs d’aide à la décision.

Tableau 2.1 : Identification des problèmes Méthode QQOCCP

2.1.3. Rechercher les causes racines : Brainstorming9

Pour recenser le maximum d’idées et d’informations, on a organisé une série de

réunions en présence de groupe de travail hétérogène, pluridisciplinaire et
représentatif composé des représentants des services suivants :

-Direction générale(DG), directions centrales des produits postaux et financiers.

- Direction système d’information(DSI).

-Direction du réseau postal (directions régionales et bureaux de poste).

9
Brainstorming : une technique d'étude qualitative et de créativité utilisée pour générer des concepts, des idées ou
des marques dans une réunion en groupe ou chacun est invité à émettre des idées ou suggestions en relation avec le
sujet de l'étude.

24
 2.1.4. Analyser et visualiser les causes : Diagramme d’Ishikawa10

On a travaillé en groupe pour construire le diagramme d’Ishikawa (voir Annexe 4) qui

nous a permis d’analyser les grandes catégories de causes (manque de procédures,
panne réseau, absence de système de gestion des incidents..) pour parvenir à un effet
particulier qui est dans notre cas le taux des incidents informatiques résolus qui est très
bas par rapport au nombre total d’incidents.

2.1.5. Valider les causes principales : Diagramme de Pareto 11

On peut déduire que 20 % des causes expliquent souvent 80 % des effets :

Le processus de gestion des incidents qui est obsolète ainsi que l’absence d’un système
informatique de gestion des incidents expliquent le taux de résolution qui est très bas
soit 27% de nombre total d’incidents.

Absence de système de
40
management
35 Processus de gestion
30 obsolète
25 Faible sensibilisation
20
Manque d'organisation
15
10 Gaspillage
5
Absence de motivation
0

Figure 2.5 : Diagramme de Pareto

10 Diagramme d’Ishikawa : Le diagramme causes-effets d'Ishikawa en référence à son concepteur promoteur,

aussi appelé diagramme arête de poisson en raison de sa graphie, est un outil qualité utilisé pour identifier les
causes d'un problème.

11 Diagramme de Pareto : un histogramme dont les plus grandes colonnes sont conventionnellement à gauche et
vont décroissant vers la droite. Le diagramme de Pareto est un outil efficace de prise de décision.

25
 2.2. Etat de l’art
En réponse à la problématique de gestion des incidents, des modules nommés "Service
Desk" ou "Help Desk"12 ont été ajoutés dans les logiciels et les outils de gestion des
parcs informatiques. Ils permettent aux utilisateurs de procéder via une interface dédiée,
la déclaration d'un dysfonctionnement de leur poste de travail, des périphériques
associés à ce dernier ou des logiciels utilisés.

2.2.1. Besoins fonctionnels

La solution à déployer doit permettre la mise en place progressive de l’ensemble des
fonctionnalités suivantes :

Pour les utilisateurs :

-Mise à disposition d’un portail utilisateurs pour créer et suivre leurs incidents et les
demandes de service et pour les informer sur les changements prévus dans leur
environnement informatique ;

-Mise à disposition de solutions d’auto-dépannage.

Pour la DSI :

-Gestion des incidents détectés par les utilisateurs ;

-Mise en place d’une base de connaissance13 pour partager les résolutions d’incidents
et pannes au sein de la DSI, réduire leurs temps de résolution, et pérenniser les
connaissances ;

-Gestion des composants pour inventorier d’une façon permanente les moyens
informatiques installés (matériel et logiciel), leurs interactions (base de gestion de la
configuration) et le lien avec les engagements de service pris par la DSI ;

12
Help Desk : un centre d'assistance, permet aux entreprises d'installer un point de contact privilégié avec ses
utilisateurs. Sa mission : aider les clients à résoudre leurs problèmes informatiques.
13
Base de connaissance : regroupe des connaissances spécifiques à un domaine spécialisé donné, sous une forme
exploitable par un ordinateur.

26
 -Gestion des événements pour tracer les dysfonctionnements et pannes relevés par la
DSI elle-même sur l’environnement informatique ;

-Gestion des changements pour tracer les modifications et évolutions planifiées de

l’environnement informatique ;

-Mise en place d’un catalogue de services informatiques14 et gestion des demandes de

services associées ;

2.2.2. Etude comparative des logiciels de gestion des incidents

Il existe plusieurs solutions de gestion des incidents sur les marchés présentant de
fortes similitudes en termes de fonctionnalités et pouvant répondre largement aux
besoins identifiés. Nous avons procédé à une étude comparative entre 4 solutions parmi
celles ayant de fortes notoriétés afin de choisir celle qui nous conviendrait le plus.

On propose ci après un tableau des logiciels les plus connus dans ce domaine :

Modules
Logiciel Licence Ergonomie Remarques
disponibles

Inventaire, Possibilité de développer

des modules et de les
Gestion des incidents, intégrer au logiciel.
Développé en mode « full
GLPI Base de connaissance,
Licence GPL Web ». Reconnaissance
Planning des +++ des machines: Windows,
open source interventions, Gestion Linux, BSD, Solaris, IBM
des licences, Gestion AIX, MacOS
Commerciale et X.Reconnaissance des
financière,- Rapports et serveurs Windows, Linux,
statistiques. BSD.

Découverte et Certification à l’utilisation

LANDesk Landesk
inventaire, Gestion des des produits.
software
Management incidents, Contrôle à +++++ Reconnaissance des postes
Suite 70$/poste distance, Distribution de clients Windows, Mac OS
logiciel, Déploiement X et Linux.Prise en

14 Catalogue de services informatiques : Base de données ou document structuré comportant des informations sur
tous les services informatiques opérationnels, incluant ceux qui sont disponibles pour déploiement.

27
 de système compte des périphériques
d'exploitation, Gestion mobiles.
des licences, Gestion de
l'énergie, Tableaux de
bord.

Nécessite l’installation
Inventaire, Gestion des d’un client sur les postes
incidents, Supervision Intégration de Symantec
de PC, Mise à jour Ghost pour la création
logicielles et d'images disques et leurs
Altiris Client distribution des « patch déploiements. Symantec
Management Symantec » de sécurité, Gestion Endpoint Protection : un

Suite des licences, Sécurité ++++ antivirus et un anti-

70$/poste des postes et des malware Altiris Software
serveurs antivirus, virtualization Solution :
Déploiement de virtualisation
système d’exploitation d'applications
et de logiciels, Tableaux Reconnaissance des
de bord machines : Windows, Mac
OS et Linux.

Inventaire, Gestion des

incidents Gestion des
PCI Edition licences, Systèmes d'exploitation
Télédistribution de supportés : Windows: 95
GIMI +
1000 $ pour fichiers, Gestion des 98 NT Me 2000 XP, Vista,
900 postes interventions et des 7, 2003, 2008
contrats de services,
Tableaux de bord.

Tableau 2.2 : Benchmarking15 des logiciels de gestion des incidents

15
Benchmarking : un ensemble de procédures de recherches et d'analyses comparatives de la concurrence. Il
permet d'améliorer les performances d'une entreprise grâce à l'élaboration d'un plan d'action, rédigé grâce aux
conclusions tirées de cette analyse.

28
 Justification du choix de GLPI16 ?

L’étude comparative des différents outils de gestion des incidents déjà mentionnés ci-
dessus et en se référant aux avis de quelques experts du domaine, nous avons opté pour
l’outil Open source GLPI comme système de gestion des incidents à mettre en place au
sein de la DSI de la Poste Tunisienne.

L’outil GLPI est :

 Le moins coûteux (gratuit).

 Le plus modulaire.

 Le mieux adapté aux normes et pratiques de management des systèmes

d’informations (ISO 20000, ITIL V3, etc.).

 Facile à intégrer et le mieux interfacé avec d’autres outils (de supervision,

d’authentification, de projet, d’inventaire, etc.).

 Evolutif et riche en documentation.

16
GLPI : Gestionnaire Libre du Parc Informatique : un logiciel libre de gestion des services informatiques (ITSM)
et de gestion des services d'assistance (issue tracking system et Service Desk). Cette solution open source est
éditée en PHP et distribuée sous licence GPL.

29
3. Chapitre 3 : Modélisation du
processus de gestion des incidents

30
 3.1. Processus de gestion des incidents
La gestion des incidents concerne la prise en charge de tous les incidents informatiques
tout au long de leurs cycles de vie.

Sa mission est d’assurer un fonctionnement normal des services conformément avec

l’engagement pris contractuellement sur les niveaux de services garantis.

La mise en œuvre d’un processus de gestion des incidents est une étape
incontournable pour :

-La réactivité : l’utilisateur peut joindre rapidement un technicien pour l’assister. Cela
occasionnera moins de perte de temps pour l’utilisateur, mais aussi pour ses collègues
qu’il ne dérange plus.

-L’efficacité du technicien : il ne sera plus dérangé au cours d’une activité planifiée.

-La capitalisation du savoir : si un incident a été enregistré, en cas de renouvellement

de ce type d’incident, les techniciens du service savent ce qu’il convient de faire et
gagneront du temps dans le traitement de l’incident.

-La prévention : il sera possible d’identifier correctement un incident mineur avant

qu’il ne devienne critique et que cela aboutisse à une situation de crise.

3.1.1. La gestion des incidents selon le référentiel ITIL

La gestion des incidents est un processus faisant partie du management des systèmes
d’information parmi lesquels l’ensemble de bonnes pratiques ITIL17.

ITIL est un ensemble de bonnes pratiques, procédures et méthodes qui servent de

lignes directrices pour l’amélioration de la gestion des services dans l’environnement
informatique.

17
ITIL : Information Technology Infrastructure Library

31
 C’est en fonction de son organisation, de son activité, de sa taille et de ses objectifs
stratégiques que l’entreprise mettra en œuvre, en partie ou en totalité, les processus
décrits dans ITIL.

Les Bonnes pratiques ITIL

De manière générale, les technologies de l’information peuvent être très complexes.

Afin de gérer cette complexité, il est important de définir des processus clairs,
consistants et bien définis.

ITIL permet d’identifier, d’améliorer et de documenter les processus mis en œuvre, ce

qui peut résulter en une amélioration de l’organisation de l’entreprise.

ITIL regroupe un ensemble de bonnes pratiques largement répandues qui découlent de

l’expertise et de l’expérience de ses contributeurs et membres de la communauté
ITSM18. Cela en fait un référentiel évolutif basé sur l’expérience pratique. Plus
spécifiquement, ITIL est un recueil structuré de conseils et de recommandations orientés
vers le service à la clientèle. Enfin, il est ouvert et s’intègre bien aux autres référentiels
de l’industrie (CMMI, PMBOK, COBIT, etc.). Il est en quelque sorte le noyau de la
gestion des services.

Figure 3.1 : ITIL version 3 -2011

18
ITSM : Information Technology Service Management est une des bases de l’ITIL et une approche de la
gestion des SI. Elle se propose de représenter le SI comme un ensemble de capacités (« capabilities »)
organisationnelles permettant de fournir de la valeur à des clients sous forme de services.

32
 Objectif du processus de gestion des incidents

Le but principal du processus de gestion des incidents est de « rétablir un service

opérationnel aussi rapidement que possible en minimisant l’impact sur l’entreprise et
en s’assurant que les niveaux de service et de disponibilité convenus soient maintenus ».

D’autres objectifs sont également à prendre en compte :

-S’assurer que des méthodes standardisées et des procédures sont utilisées afin de
garantir une réponse.

-Augmenter la visibilité des incidents et la communication vers le métier.

-Maintenir la satisfaction du client en assurant une qualité des services des

technologies de l’information.

La gestion des incidents traite tous les incidents rapportés par les utilisateurs via le
centre de service, le personnel technique et la surveillance technique.

Les incidents peuvent apparaître au niveau :

Matériel :

-Poste de travail en panne,

-Imprimante non opérationnelle,

-Ressource indisponible ou inaccessible,

-Alerte ou exception générée automatiquement par un composant du système.

Applicatif :

-Service non disponible,

-Dysfonctionnement d’une application,

- Demande d’assistance de la part des utilisateurs par rapports à un défaut de maitrise

de certaines fonctionnalités applicatives.

33
 Dans le référentiel ITIL, les rôles des intervenants sont spécifiés comme suit :

-Les groupes de premier et éventuellement de deuxième et troisième niveaux ainsi que

les groupes d’experts.

-Le gestionnaire des incidents.

-Le propriétaire du processus.

En termes de fonction, on retrouve le gestionnaire du centre de services.

Pour mesurer le fonctionnement du processus, plusieurs indicateurs19 peuvent être mis

en place :

-Nombre d’incidents crées.

-Nombre d’incidents résolus au premier contact.

-Durée moyenne de traitement d’un incident.

-Nombre d’incidents traités en dehors des délais des SLA20.

-Nombres d’incidents escaladés.

Cycle de vie d’un incident

Le traitement d’un incident se fait en plusieurs étapes (voir Annexe 5). On parle
régulièrement du cycle de vie d’un incident comme il est illustré dans la figure 3.2 ci
dessous.

Les demandes de services, les requêtes et les événements sont traités via le centre de
services et enregistrés dans le cadre du processus de gestion des incidents.

19
Indicateur : une grandeur spécifique observable et mesurable qui peut servir à montrer les changements obtenus
ou les progrès accomplis par un programme en vue de la réalisation d'un effet spécifique.
20
SLA : Service Level Agreement, ou « accord de niveau de service » est un document qui définit la qualité de
service, prestation prescrite entre un fournisseur de service et un client.

34
Figure 3.2 : Schéma de cycle de vie d’un incident

35
 La procédure d’escalade présentée dans la figure 3.3 ci-dessous devrait garantir la
bonne gestion des incidents.

Figure 3.3 : Schéma de gestion des escalades

Dans la pratique, il est nécessaire de prévoir des traitements d’exception car il n’est pas
possible de conserver des incidents ouverts au-delà d’un certain délai.

Dans cette phase, le centre de services doit s’assurer que l’enregistrement des
différentes actions réalisées pendant le traitement de l’incident a été correctement
réalisé dans l’outil de gestion des incidents.

36
 Etat d’un incident

Depuis sa détection, l’incident va passer par des états successifs tout au long de son
traitement.

L’outil à mettre en place doit indiquer à tous les acteurs du processus de gestion des
incidents (clients, technicien..) l’état d’avancement du traitement de l’incident.

Etat Description

Nouveau, ouvert Détection d’un incident et procédure

d’enregistrement (ticket) avec un identifiant
unique.

Accepté S’assurer que ce type d’incident fait partie de la

compétence de l’équipe en charge de la
résolution pour l’accepter.

Planifié L’incident occupera une place dans la file

d’attente selon sa priorité et aura une date
prévisionnelle de résolution.

Affecté A un instant t l’incident sera affecté à une seule

organisation pour le traiter.

En cours L’incident est en cours de traitement

En attente Le traitement de l’incident nécessite une

ressource supplémentaire pour le résoudre.

Résolu Une solution a été trouvée et la correction a été

déployée.

Clôturé Incident résolu, le ticket sera fermé par la

personne qui a déclaré l’incident.

Tableau 3.1: Les différents états d’un incident

3.1.2. Avantages et difficultés de la gestion des incidents
3.1.2.1. Avantages

La gestion des incidents ne devrait pas être un centre de coûts. Mais plutôt un centre de
profit pour l’entreprise.

Les coûts qui seront induits par le centre de services et de la gestion des incidents
devraient contrebalancés par les gains de productivité que cela apporte à l’entreprise :

37
 diminution du temps d’indisponibilité du personnel, diminution du nombre d’incidents,
gestion proactive des incidents, etc.

3.1.2.2. Difficultés potentielles

La principale difficulté rencontrée était de convaincre l’ensemble des opérateurs de

recourir au centre de services et donc l’outil de gestion des incidents.

L’autre difficulté consiste à convaincre les techniciens d’enregistrer tous les incidents,
même si le temps de saisie de l’incident dans l’outil est parfois plus important que le
temps de réponse à l’utilisateur.

Si l’ensemble des incidents n’est pas enregistré, il sera difficile de démontrer que le
centre de services est un centre de profit.

3.1.3. Modélisation du processus de gestion des incidents de La Poste

Tunisienne

Pour gérer efficacement le processus de gestion d’incidents, on a procédé au sein de la

DSI de la Poste Tunisienne à une définition claire des responsabilités et des rôles de
chacun des acteurs (20 personnes) par l’élaboration des fiches postes (voir Annexe 6).

Rôle Responsabilités

Le propriétaire du -S’assurer que le processus de gestion des incidents est adapté aux besoins
processus de l’organisation.

-Être responsable de la conception du processus.

-S’assurer de l’implémentation du processus.

-Réviser les rapports de gestion et les indicateurs de performance du

processus.

-S’assurer que le gestionnaire du processus a les ressources nécessaires

pour maintenir et gérer le processus en conformité avec les meilleures
pratiques afin d’atteindre les objectifs.

-Être responsable de la gestion des changements au processus.

-Être responsable de l’amélioration continue du processus et de ses

mesures.

Le gestionnaire du -Réaliser la gestion opérationnelle du processus de gestion des incidents.

processus
-Identifier les opportunités d’amélioration et les communiquer au

38
 propriétaire du processus.

-Être responsable de l’implémentation du processus.

-S’assurer que le processus est respecté et le corriger si nécessaire.

-Exécuter les audits du processus et produire les rapports de gestion et les

indicateurs de performance.

L’analyste de l’incident -Être responsable de la prise en charge des incidents.

-Effectuer un diagnostic et déployer, si possible, la solution identifiée.

-Spécifier la classification de l’incident

-Être responsable de la mise à jour des incidents qui lui sont assignés et
s’assurer qu’ils sont documentés de façon pertinente.

-Contacter et travailler en collaboration avec les autres niveaux interne ou

externe si aucune solution n’est identifiée, afin de résoudre l’incident.

-Participer aux revues d’incidents majeurs si nécessaire.

-Identifier les incidents récurrents et les soumettre au niveau adéquat.

Le technicien du centre de -Être le point de contact unique pour tous les utilisateurs lorsqu’il ya une
service interruption de service.

-Enregistrer les informations reçues, catégoriser et prioriser l’incident, et

entreprendre les actions nécessaires pour résoudre l’incident le plus
rapidement possible dans les délais définis par les niveaux de service.

-Escalader au niveau hiérarchique ou fonctionnel adéquat selon les

procédures préétablies.

-Confier les incidents non résolus au groupe d’affectation approprié.

-Être responsable du suivi des tickets, depuis leur ouverture à leur

fermeture.

-Identifier les incidents récurrents et les soumettre au niveau adéquat.

L’analyste événement -Surveiller le fonctionnement des composants manuellement ou via des

mécanismes automatiques de surveillance.

-Identifier et enregistrer les incidents à partir des alertes significatives.

Le gestionnaire de la file -Être responsable de l’assignation des incidents selon les ententes de
d’incidents services.

-Être responsable du respect de niveaux de service.

-Représenter le groupe d’affectation dans les réunions de suivi des

39
 incidents.

-Communiquer avec le gestionnaire des incidents lorsqu’il y a des relances

ou escalades hiérarchiques.

Le gestionnaire des -Être responsable de la veille sur tous les incidents mineurs.
incidents
-Assurer l’efficacité du processus de gestion des incidents.

-S’assurer quotidiennement que les niveaux de services sont respectés.

-Initier les processus de relance et d’escalade hiérarchique ou fonctionnel

si les délais ne sont pas respectés.

-S’interfacer avec les groupes de support de niveau N et le centre de

services.

Le gestionnaire des -Être responsable de tous les incidents majeurs.

incidents majeurs
-Coordonner la résolution des incidents majeurs.

-S’assurer quotidiennement que les niveaux de service sont respectés.

-Garder le processus de communication d’incidents majeurs à jour.

-Être responsable et organiser la revue d’incidents majeurs, du suivi du

plan d’action.

-Analyser les rapports et les métriques liés aux incidents majeurs.

Le coordonnateur des -S’assurer d’avoir à sa disposition les ressources et expertises requises.

incidents majeurs
-Convoquer et animer les rencontres requises.

-Informer le gestionnaire des incidents majeurs sur le progrès des travaux.

-Assurer la collaboration des experts de domaine (les analystes des

incidents).

-Mettre à jour les enregistrements d’incidents majeurs.

Tableau 3.2 : Rôles et responsabilités du processus de gestion des incidents

40
 Le tableau ci-dessous présente une modélisation du processus de gestion des incidents
de la poste Tunisienne qu’on a réalisé une fois les rôles et les fonctions ont été définis :

Phase du Données Activité Eléments de Document de Qui ?

processus d’entrée sortie référence

Enregistrement Incident identifié Enregistrer Incident Outil de gestion Technicien du

de l’incident l’incident avec enregistré et des incidents centre de
Déclaration par un identifiant initiation (GLPI), service
mail, téléphone, unique pour d’une formulaire ajout
événement de garantir sa procédure de incident Analyste de
supervision, outil traçabilité. résolution. l’incident
de gestion

Classification Incident Analyser, Ticket à jour -Base de Technicien du

de l’incident enregistré. catégoriser et problèmes et des centre de
prioriser erreurs connues. service
Vérifier s’il existe l’incident.
déjà -Grille des Analyste de
priorités. l’incident

Investigation et Ticket à jour Analyser plus -Solution Technicien du

diagnosic en détails directe ou de centre de
l’incident et contournement service
prévoir des
solutions pour -Ticket à jour Analyste
le résoudre. d’incident

Gestionnaire
incident

Coordonnateur
incident majeur

Résolution -Solution directe Prendre les -Ticket à jour. Formulaire de Analyste des
ou de mesures de résolution incidents
contournement. rétablissement -Incident incident (GLPI)
pour résoudre résolu. Coordonnateur
-Ticket à jour. l’incident. des incidents
majeurs

Clôture -Ticket à jour. Confirmation Incident Formulaire de Technicien du

de la clôturé et résolution centre de
-Incident résolu. résolution de ticket fermé incident (GLPI) service
l’incident par par la
l’utilisateur personne ayant
ayant réclamé déclaré
l’incident l’incident.

Tableau 3.3: Modélisation du processus de gestion des incidents de La Poste

41
 Les Objectifs du processus et leurs indicateurs de résultat et de fonctionnement sont :

Objectif 1 : Réduction du coût élevé des incidents par rapport au nombre de total des
utilisateurs, actuellement à 50%.

Indicateur 1 associé à l’objectif 1 : Taux d’impact niveau élevé des incidents sur les
utilisateurs.

Valeur cible de l’indicateur 1 : <= 10%

Objectif 2 : Réduire le nombre d’incidents non résolus actuellement à 67% du nombre

total d’incidents.

Indicateur 1 associé à l’objectif 2 : Nombre d’incidents non résolus.

Valeur cible de l’indicateur 1 : Nombre d’incidents non résolus <= 5% du nombre total
d’incidents.

Objectif 3 : Augmenter le taux de la satisfaction globale du client actuellement à 10%.

Indicateur 1 associé à l’objectif 3 : Le taux de l’appréciation globale niveau 1

« meilleur ».

Valeur cible de l’indicateur 1 : Le taux de l’appréciation globale niveau 1 « meilleur »

devrait être > = 80% du total des résultats des enquêtes de satisfaction.

Objectif 4 : Augmenter le taux de disponibilité du service support actuellement à 70%

d’incidents majeurs résolus dans un délai maximum de 4 heures, de 60% d’incidents
moyens résolus dans un délai maximum de 16 heures et de 50 % d’incidents mineurs
résolus dans un délai maximum de 36 heures.

Indicateur 1 associé à l’objectif 4 : Taux d’incidents majeurs résolus dans le délai de

moins de 4 heures.

Valeur cible de l’indicateur 1 : Taux d’incidents majeurs résolus dans le délai de

moins de 4 heures > = 95 %.

42
 Indicateur 2 associé à l’objectif 4 : Taux d’incidents moyens résolus dans le délai de
moins de 16 heures.

Valeur cible de l’indicateur 2 : Taux d’incidents moyens résolus dans le délai de moins
de 16 heures > = 85 %.

Indicateur 3 associé à l’objectif 4 : Taux d’incidents mineurs résolus dans le délai de

moins de 36 heures.

Valeur cible de l’indicateur 3 : Taux d’incidents mineurs résolus dans le délai de

moins de 36 heures > = 80%.

On a procédé à la fragmentation du processus de gestion des incidents en des sous-

processus, dont chacun est composé de plusieurs activités (voir Annexe 7).

Nous avons opté pour la représentation avec des logigrammes des séquences des
actions et des décisions à prendre en fonction des situations qui seront rencontrées.

Un logigramme permet de décrire complètement une activité. Il est ainsi possible de

mettre en évidence les éventuels gaspillages ou non valeur ajoutée, dans une démarche
d'amélioration continue.

43
4. Chapitre 4 : Mise en œuvre de la
solution retenue

44
 4.1. Déploiement de la solution GLPI
Avant de procéder à la mise en production de notre solution GLPI, nous avons installé
une maquette de test sur un environnement Vmware Workstation21 afin de tester la
faisabilité et la compatibilité des différentes technologies (systèmes d’exploitation,
outils de programmation, les packages GLPI, les prés requis..).

Ensuite, on a entamé la phase de déploiement du GLPI sur un environnement de

production en se basant sur une architecture bien déterminée et conformément au
processus qu’on a déjà modélisé (voir Annexe 8).

Pour gérer le traitement et la hiérarchisation des incidents, on a choisi une politique

simple :

-Tous les incidents de priorité « très haute » doivent être en priorité.

-Si deux incidents ont des priorités et des urgences égales, celui avec l’impact le plus
élevé sera traité en premier.

-Si deux incidents ont des priorités et des impacts égaux, celui avec l’urgence la plus
élevée sera traité en premier.

Pour calculer les délais d’intervention, on va se baser sur les différents statuts de
l’incident (nouveau, en cours, en attente, résolu, clos).

-Le délai de prise en charge d’un incident est la différence de l’heure d’attribution
moins l’heure d’ouverture de ticket.

-Le délai de résolution : la différence de l’heure de résolution moins l’heure

d’ouverture de ticket.

-Les délais de relance et d’escalade hiérarchique seront calculés en fonction du statut

de l’incident.

21
Vmware Workstation : une référence du secteur pour l'exécution de plusieurs systèmes d'exploitation en tant que
machines virtuelles sur un seul PC.

45
 Figure 4.1 : Matrice de calcul de priorité des tickets dans GLPI de La Poste

Une fois la plateforme GLPI mise en place, toutes les parties prenantes du projet se
sont mis d’accord pour commencer les tests réels pendant un mois sur 3 sites pilotes qui
appartiennent à la direction régionale de Tunis : Bureau de poste Tunis Hached, bureau
de poste Mohamed 5 et bureau de poste Habib Thameur.

Il est indispensable de générer régulièrement des rapports d’activités qui vont nous
servir pour améliorer nos procédures de travail 22 et la productivité des différents acteurs
du centre de service.

Pour cela, on a développé des plugins afin de générer des rapports et des graphiques
sous forme de métriques d’indicateurs de performance KPI23 qui sont produites selon
des fréquences spécifiques :

22
Procédure de travail : désigne une manière spécifiée d'effectuer un ensemble de tâches. Elle décrit ainsi étape
par étape l'enchainement des tâches à réaliser, et les rôles et responsabilités associées.
23
KPI : un acronyme pour Key Performance Indicator. Les KPI ou ICP (indicateurs clés de performance) peuvent
être utilisés, dans le domaine du management au sens large, dans le domaine du marketing et de la publicité ou
dans le domaine de l'analyse d'audience d'un site web

46
 Figure 4.2 : Métriques Helpdesk GLPI de La Poste

-Les Dashboard24 et les rapports d’activités nous ont permis d’avoir une vision plus
détaillée et en temps réel sur le déroulement du processus de gestion des incidents à
travers la génération des rapports :

-de suivi en détails des tickets jusqu’à leur clôture :

Figure 4.3 : Suivi d’un ticket jusqu’à sa clôture

24
Dashboard : un terme anglais pour tableau de bord.

47
 - en nombre et pourcentage d’incidents traités par agent du centre de service :

Figure 4.4 : Statistiques des tickets par technicien

-calculant la Moyenne /Maximum/Minimum de temps écoulé pour résoudre les

incidents :

Figure 4.5 : Pourcentage de temps de résolution des tickets

48
-en nombre d’incidents fermés par les différents niveaux de support :

Figure 4.6 : Nombre d’incidents par niveau de support

-en pourcentage d’incidents résolus dans les termes des SLA :

Figure 4.7 : Nombre de tickets gérés par contrats de service SLA

49
 -En nombre de tickets par origine de réclamation : 83% des tickets sont déclarés à
travers l’outil GLPI.

Figure 4.8 : Tickets par origine de réclamation

-en nombre de tickets par état :

Figure 4.9 : Nombre de tickets par état d’incident

Interprétation

En comparant les résultats des différents indicateurs mentionnés ci-dessus avec ceux
obtenus avant la mise en place de l’outil GLPI, on peut déduire que :

-Le nombre total d’incidents a diminué de 15 pannes par bureau à une moyenne de 3
par jour.

-L’utilisation d’un système informatique de réclamation d’incident est passé de 0% à

83%.

-Le nombre d’incidents non résolus a diminué de 67% à 15%.

50
 -Les délais moyens de prise en charge et de résolution des incidents ont diminué de 8 h
à moins de 4 h pour les incidents majeurs et de 48heures à moins de 24 heures pour les
incidents moyens et mineurs grâce à la mise en place de la base de connaissances propre
à la Poste qui a simplifié les tâches de traitement et de résolution des incidents.

-Un processus de gestion des incidents bien structuré à été mis en place.

4.2. Conduite de changement

Malgré les améliorations observées dans le paragraphe précédent, nous avons
rencontrés quelques difficultés au cours et après le déploiement de GLPI :

Figure 4.10 : Les difficultés rencontrés lors du déploiement de la solution

En observant la figure 4.10 , on peut déduire que la résistance au changement25 était la

principale difficulté qu’on a rencontré lors de déploiement du GLPI avec 60% de
l’ensemble des difficultés , des utilisateurs qui ne sont pas habitués à utiliser un tel outil
pour réclamer vu qu’ils se servent de l’email , du télephone et du fax.

Certains techniciens n’ont pas accépté au début de traiter un grand nombre de

tickets(quelques tickets sont enregistrés et les autres traités sans traçabilité).

25
Résistance au changement : Attitude consciente ou inconsciente d’un individu ou d’une personne morale qui
l’incite à refuser toute modification ou évolution de son état actuel.

51
 Au début du projet , on avait un soucis de disponibilité de ressources humaines et
logicielles (8 %) et un manque de soutien des dirigeants (12 %) qui n’ont pas accordé
les fonds nécessaires pour ce service jusqu’à l’intervention de la direction génerale .

Au cours de l’implémentation de l’outil , on a subi des problèmes d’intégration (10 %)

suite auquelles ont n’a pas respecté entièrement le planning du déploiement mais qui n’a
pas influencé sur les autres phases du projet et on a pu corrigé le problème après avoir
éffectué des mise à jour de systèmes nécessaires.

Toutes ces barrières qu’on a citées ci-dessus, ont réussi partiellement à empêcher notre
outil GLPI à s’implanter convenablement et agir d’une manière très efficace au sein de
la Poste Tunisienne.

En se basant sur quatre actions clés : communiquer, impliquer, former et accompagner,

on a pu surmonter cette résistance au changement :

-Expliquer, convaincre et valoriser notre outil GLPI à travers des emails et la

sensibilisation en profitant d’une journée ouverte organisée à Mahdia pour la plus part
des chefs de bureaux de poste du pays.

-Par l’implication de toutes les parties prenantes et en partageant avec eux les objectifs
ainsi que le cadre général du projet ;

-En faisant participer quelques utilisateurs au cours des différentes phases du projet à
chaque étape de validation avec une communication régulière sur l’état d’avancement
du projet permettant également d’obtenir une forme de motivation et d’engagement;

- En choisissant des guichetiers de quelques bureaux de postes pour participer à la

phase des tests de GLPI ;

-Par la planification d’une journée de formation pour les techniciens informatiques des
24 régions, une fois l’outil GLPI mis en place, leur expliquant la raison d’installer un tel
système et les différentes étapes de la gestion des tickets depuis la création jusqu’à la
clôture. Chaque technicien à son tour, a réexpliqué aux guichetiers des bureaux de poste
de sa région ce qu’il a appris au cours de cette journée de formation.

52
 -Mettre un plan d’actions d’amélioration continue en accompagnant les acteurs du
projet au quotidien et rester à l’écoute pour renforcer leur appropriation mais aussi
détecter d’éventuels écueils.

Les raisons pour lesquelles la conduite de changement pour la gestion des incidents au
sein de la Poste n’a pas entièrement aboutie sont :

-La révolution tunisienne, qui malgré ses bénéfices a engendré l’anarchie dans
l’administration tunisienne y compris La Poste : le non respect des procédures de travail
et des chefs hiérarchiques.

- La non implication de quelques chefs de services surtout ceux des directions

régionales qui voulaient assister à toutes les réunions et se sentent écartés.

- Pas de motivation en absence des fonctions promotionnelles (chef de service et chef

de section) depuis 2011.

-Le refus catégorique de travailler avec les outils informatiques pour les guichetiers
prêts à la retraite.

4.3. Amélioration continue26 du système mis en place

4.3.1. Analyse des indicateurs clés de performances
En se basant sur les contrats de service (SLA) qu’on a définit dans notre outil GLPI, on
a choisit 6 indicateurs parmi ceux qu’on a définit au début du projet pour quantifier et
qualifier la qualité, le coût et le délai :

 5 indicateurs relatifs à la gestion des incidents exprimant le taux d’impact des

incidents sur les utilisateurs , le nombre d’incidents non résolus et le respect
des délais maximum de résolution d’un incident selon son niveau de priorité à
partir du moment de la prise en compte de l’incident.

26
Amélioration continue : démarche structurée en groupe de travail, visant l'amélioration, par le personnel, de la
qualité du produit, de la satisfaction du client et de la performance globale de l'entreprise, assurant ainsi le
développement et le succès à long terme de celle-ci.

53
 Niveau de priorité Délai max de résolution Plage horaire Du Lundi à
Vendredi

Très Haute (TH) 1 heure 8h-17h

Haute (H) 4 heures 8h-17h

Moyenne (M) 16 heures 8h-17h

Basse(B) 24 heures 8h-17h

Très Basse (TB) 36 heures 8h-17h

Tableau 4.1 : Respect des délais max de résolution des incidents

Sur un total de 100 tickets générés dans un mois, on a récolté les résultats suivants :

Objectif Indicateur Valeur Valeur Valeur Ecart

avant après cible % à la
mise en mise en valeur
place place cible

Réduction des coûts Taux d’impact niveau élevé 50% 30% 5% -25%
des incidents des incidents sur les utilisateurs

Réduction du Nombre d’incidents non 67% 15% 5% -10%

nombre d’incidents résolus par rapport au nombre
non résolus total d’incidents

Respecter les Taux d’incidents majeurs 70% 90% 95% -5%

contrats de service résolus dans le délai de moins
SLA de 4 h

Taux d’incidents moyens 60% 90% 85% +5%

résolus dans le délai de moins
de 16 heures

Taux d’incidents mineurs 50% 99% 75% +24%

résolus dans le délai de moins
de 36 heures

Tableau 4.2 : Pourcentage des KPI par rapport à la valeur cible

54
 Analyse et interprétation

En analysant le tableau 4.2 ci-dessus, on remarque qu’on a des indicateurs qui

dépassent la valeur cible (en vert) et d’autres qui sont en dessous de la valeur cible (en
rouge).

On a choisi de déterminer l’impact d’un incident qui est calculé en fonction de critères
définis dans le contrat de service(SLA) (voir Annexe 8) selon un minimum de trois
niveaux :

-Elevé : un grand nombre d’utilisateurs est impacté ou c’est une application majeure
qui est concernée.

-Moyen : un nombre limité d’utilisateurs est impacté ou c’est une application standard
qui est concernée.

-Faible : un seul ou très peu d’utilisateurs sont impactés ou c’est une application
bureautique qui est concernée.

On doit agir sur les indicateurs en rouge pour remédier aux lacunes observées :

-Réviser la matrice des priorités et mieux l’adapter au processus de gestion des

incidents pour mieux gérer l’impact des incidents sur les utilisateurs.

-Mieux maîtriser le temps max de résolution des incidents majeurs et mieux respecter
les SLA.

 Un indicateur mesurant le taux de satisfaction client qui va être évalué par le

biais d’un questionnaire électronique greffé dans l’outil GLPI une fois le ticket
clôturé par l’utilisateur qui a déclaré l’incident.

55
Figure 4.11 : Formulaire de satisfaction client développé dans GLPI de La Poste

Cet indicateur dépendra d’un critère qu’on va prendre en compte : le taux de

satisfaction niveau 1(meilleur) doit être au moins de 80 % comme valeur cible.

On a mené cette enquête sur les 3 utilisateurs des 3 sites pilotes (Bureau Med 5, Tunis
Hached et Thameur) pendant un mois sur un nombre de tickets clos égale à 100:

Niveau de satisfaction Résultats Taux par rapport aux Ecart par rapport à la
nombre de tickets clos valeur cible

1 60 60% -20%

2 25 25%

3 10 10%

4 3 3%

5 1 1%

6 1 1%

Tableau 4.3 : Résultats des questionnaires de satisfaction par niveau

56
 Analyse et interprétation

En se référant au tableau ci-dessus, on peut déduire qu’on n’a pas pu atteindre la valeur
cible de 80%.

On aura du travail à faire afin d’améliorer la qualité de service qui est en cause de la
non satisfaction des clients (utilisateurs)27.

4.3.2. Plan d’actions correctives

Les résultats d’analyse des KPI dans le paragraphe précédent nous ont poussés à
penser à réviser et réévaluer le processus de gestion des incidents de la Poste afin de
respecter les objectifs déjà fixés au début du projet.

Nous sommes tenus de relancer la roue de Deming PDCA.

Pour cela, nous allons surveiller et comparer les métriques de façon continue à travers
le tableau de bord développé sur notre outil GLPI et mis à jour instantanément.

En collaboration avec toutes les parties prenantes du projet, on a recherché, analysé et

visualisé à nouveau les causes du non performance des indicateurs qui n’ont pas atteint
la valeur cible après la mise en place de GLPI.

Nous avons élaboré ensemble un plan d’actions correctives28 et préventives qui nous
servira pour réévaluer le processus de gestion des incidents qu’on a modélisé et
remédier aux problèmes rencontrés :

27
Satisfaction client : considérée comme le pilier de la fidélisation. Cependant, la relation satisfaction / fidélisation
est complexe et loin d'être linéaire selon les domaines d'activités.
28
Plan d’actions correctives : une stratégie basé sur des actions visant à éliminer une faiblesse détectée dans le
système ou la cause d'une non-conformité afin d'en empêcher la réapparition.

57
Objectif Indicateur Action Responsable Priorité Coût Echéance
corrective

Réduire les Taux -Mettre à Mr AHMED 1 Ressources Juillet 2017

coûts des d’impact niveau les MELLEF humaines et
incidents des systèmes des matérielles
incidents applications internes à la
sur les métiers. Poste.
utilisateurs
-Mettre en
place des outils
de préventions.

Réduire le Nombre -Dédier une Mr AHMED 3 Ressources Du mois de

nombre d’incidents équipe pour MELLEF humaines et juillet à la
d’incidents non résolus mettre des matérielles fin d’année
non résolus par rapport règles internes à la
au nombre d’intervention Poste.
total proactive pour
d’incidents ce type
d’incidents.

-Mettre en
place à moyen
terme un
processus de
gestion des
problèmes.

Respecter Taux -Affiner et Mr AHMED 2 Formation D’Août à

les contrats d’incidents enrichir le MELLEF externe Septembre
de service majeurs contenu de la payée dans 2017
SLA résolus base de le cadre de
dans le connaissances. la

58
 délai de subvention
-Formation
moins de 4 annuelle de
externe des
heures formation.
équipes sur
ITIL fondation
V3-2011.

Maximiser Taux du -Formation Mr AHMED 1 -Formation Juillet 2017

la premier externe des MELLEF externe
satisfaction niveau de équipes sur payée dans
client satisfaction ITIL fondation le cadre de
(meilleur) V3-2011, la
module subvention
Satisfaction annuelle de
client service formation.
informatique.
-Formation
-Mieux interne
impliquer les assurée par
utilisateurs en des
les membres de
sensibilisant à l’équipe de
utiliser l’outil projet.
GLPI dans les
règles de l’art
(formation
interne).

Tableau 4.4 : Plan d’actions correctives

59
 Conclusion générale
Ce rapport a été rédigé dans le cadre du projet de fin d’études réalisé au sein de La
Poste Tunisienne.

Notre projet consistait à mettre en place un outil de gestion des incidents informatiques
open sources GLPI dans un centre de service de la Poste qui garantira une amélioration
des pratiques des informaticiens et la satisfaction des utilisateurs (les guichetiers des
bureaux de poste).

Malgré qu’on ait beaucoup gagné de la mise en place de l’outil GLPI, ce projet n’a pas
atteint tous ces objectifs fixés au départ vu des contraintes de temps, de coordination et
de résistance au changement.

Pour remédier à des tels soucis, on a élaboré un plan d’actions correctives à cours
terme.

Ce stage nous a permis de bénéficier de nouvelles connaissances dans le domaine de

management des systèmes d’information complétant celles que nous avons acquises
durant notre formation MOME.

Enfin, nous espérons que la mise en place d’un tel système de gestion des incidents
informatiques nous servira pour intégrer de nouveaux modules tels que le module de
gestion des problèmes à moyen terme.

60
 Références bibliographiques

BOYA, Jean Louis. Processus de conduite de changement : application au guichet unique

électronique. Mémoire. Commerce et marketing.2006.ESSEC Douala Cameroun.
CORNIC, Claire. Comment appliquer le diagramme d’ishikawa à la gestion du projet. Blog
gestion de projet.com, Décembre 2013. [17 Mars 2017]. < http://www.blog-gestion-de-
projet.com/comment-appliquer-le-diagramme-ishikawa-a-la-gestion-de-projet/>
DELBRAYELLE, Pascal.ITIL version 3. [Consulté durant la période du stage].Disponible sur
Web : < http://www.itilfrance.com>.
DISSON, Eric ; HUIN, Leslie ; TALENS, Guilaine. Réussir un projet BPM. In DISSON, Eric.
Introduction à la cartographie des processus métiers. Lyon. Université Jean Moulin, 2017,
page 1-3.
GLPI, Community.Forum GLPI. [Consulté durant la période du stage].Disponible sur Web : <
http://forum.glpi-project.org/>.

LABED, Jamel. Comment organiser son service help desk. JDN. [Consulté le 23 Mars
2017].disponible sur le web : < http://www.journaldunet.com/solutions/systemes-
reseaux/enquete/08/0211-faire-monter-en-puissance-son-helpdesk/2.shtml>.

MALTOT, Cyrille et COTE, Jean-Marcel.Kit de déploiement de processus pour GLPI, ENI

éditions, 2017, ISBN : 978-2-409-00533-6.
QUESNE, Jacques. Comprendre ITIL 2011, ENI éditions, 2015, ISBN : 978-2-7460-7355.
SUEUR, Christian. Mise en place d’un système de Helpdesk (GLPI).9Février 2017. Disponible
sur Web : < https://christiansueur.com/mise-en-place-dun-systeme-de-helpdesk-glpi/>.

61
Annexes

62
 Annexe 1 : Organigrammes de La Poste

Direction générale PDG

D DC DC Unité DC DC DC D
Affaires Patrim Comm relation Produits Finance Produits Juridique
DCRH étrangèr oine erciale avec le postaux DSI et financiers
es client compta
bilité

Centre D
D Bâtiments D D
informa Monétique
Marketi courrier
ng tique

D Mondats
D Moyens D D CDTP
Commu Réseau
nication postal

D
Unité
Postfinance
numéri
que

CEF

Direction système d’information DSI

Centre informatique Centre de développement des Unité numérique

technologies postales CDTP

Service Service Service Service recherche Service des

messagerie commerce développement et développement affaires générales
électronique électronique télématique

63
Annexe 2 : Processus de gestion des incidents
existant

64
 Annexe 3 : Questionnaire de satisfaction client
Votre avis nous intéresse…
Madame, Monsieur,

Dans le but d’améliorer nos prestations et notre qualité de service, nous vous remercions de bien
vouloir consacrer quelques instants à compléter et à nous retourner ce formulaire par mail au :
support@tnpost.tn ou par fax au 71831508.

Votre Nom : Adresse e-mail :

Fonction : Direction :

Indiquez votre niveau de satisfaction relatif aux points suivants :

Disponibilité du service informatique

Très Satisfait Satisfait Insatisfait Très Insatisfait
Le temps d’attente pour joindre    
un interlocuteur
Délai de prise en compte de    
l’intervention
Délai moyen de résolution    

La qualité des interventions

Très Satisfait Satisfait Insatisfait Très Insatisfait
Qualité de l’accueil téléphonique    
Compréhension de la demande    
Clarté des explications fournies    
Votre relation avec les techniciens    

Taux d’incidents
De 0 à 10 De 10 à 30 De 30 à 50 >50
Nombre total d’incidents/mois    
Nombre d’incidents résolus/mois    

Appréciation globale
Très Satisfait Satisfait Insatisfait Très Insatisfait
Votre appréciation globale    

Observations / Suggestions d’amélioration

……………………………………………………………………………………………………………………………………………………………………………………………………
……………………………………………………………………………………………………………………………………………………………………………………………………

65
Annexe 4 : Diagramme d’Ishikawa

66
Annexe 5 : Processus de gestion des incidents
selon ITIL
Enregistrement d’un incident

Enregistrer dans l’outil de gestion mis en œuvre au sein du centre de services en

identifiant le demandeur par le technicien.

Classification

C’est l’étape la plus importante du processus de gestion des incidents.

La catégorisation

Elle permet de déterminer quels sont le matériel, le service ou les personnes concernés
par l’incident et le niveau de priorité qui lui sera affecté.

Cette catégorisation va également permettre d’identifier le groupe de support vers

lequel la réclamation sera dirigée, dans la mesure où le technicien n’est pas dans la
capacité de la traiter lui-même.

La priorisation

C’est la combinaison de deux paramètres (impact et urgence) qui permet de définir la

priorité d’un incident.

L’impact

L’impact d’un incident est déterminé en fonction de critères définis dans le contrat de
service(SLA) selon un minimum de trois niveaux :

-Elevé : un grand nombre d’utilisateurs est impacté ou c’est une application majeure
qui est concernée.

-Moyen : un nombre limité d’utilisateurs est impacté ou c’est une application standard
qui est concernée.

67
 -Faible : un seul ou très peu d’utilisateurs sont impactés ou c’est une application
bureautique qui est concernée.

L’urgence

Elle est définie dans le SLA selon un minimum de trois niveaux :

-Elevé : c’est une application ou un équipement critique.

-Moyenne : c’est une application ou un équipement non critique.

-Faible : l’utilisateur peut continuer à travailler en mode dégradé.

La priorité

Il faut définir dans quels délais le service doit être rétabli.

Urgence

Code de priorité Elevée Moyenne Faible

Elevé 1 2 3

Impact Moyen 2 3 4

Faible 3 4 5

Code de priorité Description Durée résolution prévue

1 Critique 1 heure

2 Elevé 8 heures

3 Moyen 24 heures

4 Faible 48 heures

5 Planification Conforme à la planification des

tâches

68
 Incident majeur

Au-delà de la priorisation d’un incident, il existe des circonstances où il est nécessaire

de prendre des mesures particulières.

Dans ce type de situation, cet incident est qualifié d’incident majeur.

Cela signifie qu’une procédure particulière est déclenchée pour traiter le plus
rapidement possible cet incident, en mettant en œuvre des ressources adaptées à une
telle situation.

On peut l’assimiler à une situation de crise.

Escalade

Il existe deux cas d’escalade. L’un entre dans le traitement normal d’un incident et
l’autre est et demeurer exceptionnel.

Escalade fonctionnelle :

Qui consiste à l’acheminement d’un incident à un niveau d’assistance supérieur,

principalement à cause d’un manque de connaissance ou d’expertise du technicien, ou
lorsque l’intervalle de temps convenu dans le SLA pour traiter l’incident est écoulé ou
risque de l’être à court terme.

Escalade hiérarchique :

Cette démarche est mise en œuvre au cours d’une activité quand il est probable que la
résolution d’un incident ne sera pas faite à temps ou ne sera pas satisfaisante. Les
gestionnaires doivent prendre rapidement la décision appropriée.

Un client peut demander une modification de la priorité qui a été affecté à son incident.

Investigation et diagnostic

Durant cette phase, le technicien va mener des investigations afin de déterminer les
causes réelles de l’incident.

69
 Pour cela, il va interroger l’utilisateur mais il va également interroger les bases de
connaissances dont il dispose.

Il est important de tenir le client informé durant cette phase, et lorsque cela est
possible, lui offrir une solution de contournement.

Toutes les investigations et opérations menées durant cette phase doivent être
consignées dans l’outil de gestion des incidents afin d’assurer la traçabilité de l’incident,
et également pour permettre une analyse globale des incidents qui sera réalisée dans le
processus gestion des problèmes.

Résolution

La résolution de l’incident peut être réalisée sur la base d’une solution fournie par le
centre de services dont les informations concernant les opérations mises en œuvre
doivent être enregistrées dans l’outil de gestion des incidents.

Clôture

Par principe, aucun incident ne peut être clos sans l’accord de la personne qui est à
l’origine de l’incident.

70
 Annexe 6 : Fiche poste
IDENTIFICATION DU POSTE

Intitulé du poste

Nature du poste

IDENTITE DE L’AGENT /CADRE

Nom-prénom

Statut, corps, catégorie, grade

PRESENTATION DU SERVICE (à remplir par le N+1)

Mission principale du service

Composition du service (effectif)

Positionnement de l’agent dans

l’organigramme du service

MISSIONS ET ACTIVITES DU POSTE

Mission principale, raison d’être

ou finalité du poste

Missions et activités du poste

Intérêts, contraintes, difficultés du

poste

COMPETENCES REQUISES SUR LE POSTE

Profil du poste

Les « savoirs » :

Les « savoir-faire » :

Les « savoir-faire » comportementaux :

Signature du chef hiérarchique Signature de l’agent

71
 Annexe 7 : Manuel de procédure PGDIP

Logigramme général du PGDIP

72
Fiche et logigramme du sous processus 1 :

Description : Activités requises pour identifier un incident

Rôles : Analyste d’événements, analyste d’incidents

In put : Out put :

-Evénements. -Incident identifié.

-Alerte.

-email.

73
Fiche et logigramme sous processus 2 :

Description : Activités requises pour enregistrer un incident

Rôles : Technicien, Analyste d’événements, analyste d’incidents

In put : Out put :

-Incident identifié. -Incident enregistré.

-système automatique de supervision

(SCOM, PRTG, Nagios) détectant les
événements.

-Enregistrement depuis l’interface web de

l’outil HDPost.

-Appel téléphonique d’un utilisateur.

-Contact utilisateur via le courrier

électronique.

74
Fiche et logigramme du sous processus 3 :

Description : Catégorisation requise de l’incident

Rôles : Technicien, Analyste d’événements, analyste d’incidents

In put : Out put :

-Incident enregistré. -Incident catégorisé.

75
Fiche et logigramme du sous processus 4 :

Description : Activités requises pour prioriser un incident

Rôles : Technicien, analyste d’incidents, gestionnaire incidents majeurs, coordonnateur incidents

majeurs

In put : Out put :

-Incident catégorisé. -Incident à diagnostiquer.

-Incident à escalader.

-Incident majeur à coordonner.

-Incident priorisé et mis à jour.

-Incident majeur confirmé.

76
Fiche et logigramme du sous processus 5 :

Description : Activités requises pour déterminer si l’incident peut être résolu directement ou il
faut une escalade fonctionnelle.

Rôles : Technicien, analyste d’incidents

In put : Out put :

-Incident à diagnostiquer. -Incident nécessitant une escalade

fonctionnelle ou hiérarchique.

-Incident à investiguer et diagnostiquer.

-Incident à résoudre.

-Incident mis à jour.

77
Fiche et logigramme du sous processus 6 :

Description : Activités requises pour procéder à une escalade fonctionnelle ou hiérarchique.

Rôles : Technicien, gestionnaire des incidents, gestionnaire des incidents majeurs, analyste
d’incidents

In put : Out put :

-Incident majeur prêt pour escalade. -Incident affecté à un groupe de résolution

identifié.
-Incident dont le diagnostic initial nécessite
une escalade. -Escalade hiérarchique complétée.

-Incident non résolu qui demande une

escalade.

-Incident qui nécessite une escalade

hiérarchique.

-Affectation d’incident refusé et retourné à

la coordination de gestion des incidents.

78
Fiche et logigramme du sous processus 7 :

Description : Activités requises pour investiguer et diagnostiquer l’incident.

Rôles : Technicien, analyste d’incidents, gestionnaire de file, coordonnateur incidents majeurs.

In put : Out put :

-Incident dont le diagnostic initial est établi. -Incident diagnostiqué et mis à jour.

-Incident escaladé. -Incident à réaffecter.

-Incident non résolu. -Procédure de relève déclenchée.

-Communication et suivi avec le

coordinateur des incidents majeurs.

79
Fiche et logigramme du sous processus 8 :

Description : Activités requises pour résoudre l’incident.

Rôles : Technicien, analyste d’incidents, coordonnateur incident majeur

In put : Out put :

-Incident avec une solution à appliquer. -Incident confirmé résolu.

-Incident investigué et diagnostiqué. -Incident à escalader.

-Changement ou requête complétés. -Incident non résolu à investiguer et

diagnostiquer.

80
Fiche et logigramme du sous processus 9 :

Description : Activités requises pour clôturer l’incident

Rôles : Technicien, Analyste d’événements, analyste d’incidents

In put : Out put :

-Incident résolu. -Incident fermé.

-Incident majeur à fermer.

81
Fiche et logigramme du sous processus 10 :

Description : Activités requises pour coordonner et assurer les suivis des incidents.

Rôles : Gestionnaire des incidents, gestionnaire des incidents majeurs

In put : Out put :

-Tous les incidents. -Rapport de performance des incidents.

-Indicateurs KPI relatifs aux délais de -Incident en bris de service.

résolution et de relance.
-Incident ne nécessite pas de coordination ou
escalade.

-Incident nécessitant une escalade

hiérarchique.

-Communication aux parties prenantes.

82
Fiche et logigramme du sous processus 11 :

Description : Activités requises pour coordonner les incidents majeurs.

Rôles : Gestionnaire des incidents majeurs

In put : Out put :

-Incident déclaré majeur. -Communication avec le coordinateur des

incidents majeurs.
-Communication du coordinateur incident
majeur au cours de l’investigation et le -Déclenchement d’une escalade.
diagnostic.
-Incident majeur fermé.
-Incident résolu.

83
Annexe 8 : Etapes de déploiement de l’outil
GLPI
Pour mettre en place l’outil GLPI, on a utilisé plusieurs technologies et outils :

-Vmware Esxi version 5.5 : technologie utilisée pour l’hébergement virtuel de la

plateforme.

-Debian 6.5 server 64 bits : une distribution de système d’exploitation linux sur la
quelle on a installé et configuré l’outil GLPI.

-GLPI 0.85.5 : package de noyau de base de l’outil GLPI.

-OCS inventory : package open source pour inventorier les équipements du réseau de
la Poste.

-PHP 5.5 : langage de programmation web open source utilisé pour le développement
des modules GLPI.

-Apache 2.2.16 : serveur web open source pour l’interprétation des pages web générées
par plusieurs langages de programmation (php, perl,…).

-Mysql 5.0 : système de gestion de bases de données relationnelles open source.

-Microsoft visio 2016 : pour la modélisation du processus de gestion des incidents.

-Winscp 5.9.5 : utilitaire qui permet la copie sécurisée de fichiers entre un ordinateur
local et un serveur distant en utilisant des protocoles SFTP, SSH.

84
 Architecture technique de la plateforme

Après avoir installé la plateforme GLPI , on s’est intéressé à la création des profils des
groupes utilisateurs de GLPI et à l’affectation des rôles et des niveaux d’escalades
(SLA) .

85
Création des profils , groupes et utilisateurs GLPI :

Création et paramétrage des contrats de service SLA :

86
Formulaire d’ajout d’un nouveau ticket suite à un incident :

La base de connaissances GLPI :

87