1

Diplôme préparé : Maser 2 en Systèmes Informatiques Communicants : réseaux, services et sécurité

Promotion 2019 – 2020

Thème : Mise en place d'une solution des gestions de service informatique (ITSM)

=== Réalisé par Marc AMOUZOUN ===

Site d’accueil : AIX-EN-PROVENCE

2

SUIVI DU DOCUMENT

Réalisé par : - Marc AMOUZOUN

Sous la supervision de : - Sébastien OLIER

- Abderrahim Benslimane

3

DEDICACES

Je dédie ce travail à mon feu père AMOUZOUN Kéhounde

Et à ma mère EGBI Cécile

REMERCIEMENT

Je ne saurais commencer ce mémoire sans remercier DIEU le PÈRE TOUT PUISSANT pour

son assistance continuelle dans ma vie.

Je tiens à témoigner toute ma reconnaissance aux personnes suivantes :

- Messieurs Georges HENROTEAUX et Laurent ESCALETTES pour leur aide dans

mon processus de recherche d’alternance ;

- Messieurs Lionel IMBERT, Sébastien OLLIER et Yassine DIAF pour leur confiance ;

- A Julien MURATOT, Jean-Denis HENRY, Maxence VALAY et Fabien LIEUTAUD

pour leur aide dans la réalisation de ce projet ;

- A toutes les personnes qui de près ou de loin, ont contribué à la réalisation de ce

document.

4

SOMMAIRE

DEDICACES ......................................................................................................................... 3

REMERCIEMENT................................................................................................................. 3

Introduction ............................................................................................................................ 5

CHAPITRE 1 : Présentation générale ................................................................................... 6

CHAPITRE 2 : ITSM .......................................................................................................... 11

2.1- Etude de l’existant ......................................................................................................... 12

2.2- Liste des besoins ........................................................................................................... 13

2.3- Choix technologiques .................................................................................................... 13

2.3.1- Etude comparative des différentes solutions ........................................................ 14

2.3.2- Etude comparative des coûts des solutions .......................................................... 15

2.3.3- Solution retenue .................................................................................................. 15

2.4- Méthodologie ................................................................................................................ 15

CHAPITRE 3 : Implémentation de la solution .................................................................... 18

3.1- Architecture de la solution ............................................................................................. 19

3.2- Contraintes de la solution .............................................................................................. 19

3.2.1- Informations d’un ticket ......................................................................................... 19

3.2.2- Règle SLA et escalade de tickets ............................................................................ 22

3.2.3- Gestion des contrats ................................................................................................ 23

3.2.4- Fiche d’intervention ............................................................................................... 23

3.2.5- Backup ................................................................................................................... 24

3.2.6- Profil ...................................................................................................................... 24

3.2.7- Reprise des données ............................................................................................... 24

3.2.8- Autres fonctionnalités ............................................................................................. 24

3.3- Sécurité ......................................................................................................................... 25

Conclusion ........................................................................................................................... 26

5

Introduction

La gestion des services informatiques (ITSM : Information Technology Service Management)

est une des bases de l’ITIL, qui le définit comme étant une approche de la gestion des

systèmes d’information (SI). Elle représente le SI comme un ensemble de capacités

organisationnelles permettant de fournir de la valeur à des clients sous forme de service ou

d’augmenter l'efficacité informatique pour une meilleure satisfaction. Cette valeur est

intangible et non monnayable pour l'entreprise. Les principaux intérêts des outils ITSM

portent sur l’amélioration de la qualité de service au client à travers une meilleure prise en

charge des incidents et de leur traitement. Il s’agit également d’un outil visant à fluidifier les

processus de gestion des services, optimiser l’efficacité opérationnelle, faciliter et fiabiliser la

circulation et l’accès à l’information.

Ce projet est d’une très grande utilité pour le département informatique qui est appelé à jouer

le rôle : de support aux utilisateurs, de gestion des projets d’infrastructure, d’exploitation, de

gestion des postes de travail, de téléphonie…etc. Cette application aidera aussi les chefs de

projets car elle inclut une partie de gestion de projet. Autrement dit, le module de gestion de

projet nous permettra d’établir le planning des projets, la validation des étapes du projet, la

génération du diagramme de Gantt, l’évolution du projet …etc.

C’est dans cet ordre d’idée, qu’il nous a été confié dans le cadre de notre alternance à COM-

NETWORK de travailler sur le thème : « La mise en place d’une solution de gestion des

services informatiques». Pour mieux appréhender les contours de ce thème, nous avons

organisé notre travail en trois grandes parties : Le premier chapitre sera consacré à la structure

d’accueil, à la problématique et aux objectifs visés à travers cette étude. Le deuxième chapitre

portera sur la notion de gestion des services informatiques, puis sur une étude comparative des

différentes solutions en mettant en avant ses points forts et ses faibles afin de porter un choix

technologique. Enfin, le dernier chapitre fera objet de la présentation en détail de la solution

retenue et de son implémentation.

6

CHAPITRE 1 : Présentation générale

7

Dans ce chapitre nous présenterons la structure d’accueil à travers sa mission et son domaine

d’activité. Ensuite, nous présenterons le contexte et la problématique de notre sujet ainsi que

les objectifs visés.

1.1- Présentation de l’entreprise

COM-NETWORK est une entreprise dirigée par une équipe de professionnels qualifiés,

spécialisée dans l’administration systèmes, réseaux et sécurité. Acteurs majeurs de

l’intégration système et réseau, ils offrent un ensemble de solutions innovantes garantissant

l’accroissement de la productivité des entreprises (Cloud, téléphonie sur IP, infogérance, etc.).

1.1.1- Mission

La mission de COM-NETWORK vise à accroître la compétitivité de ses clients par la

valorisation des composantes informatiques, logicielles, réseaux etc. constituant le système

d'information de ces derniers. Leur principal objectif est d’accompagner les entreprises dans

leur projet de transformation digitale à travers les conseillers, des formations, des

implémentations de solutions informatiques etc. Ceci permet aux entreprises d’être à jour sur

le plan technologique et d’avoir une vision globale et parfaite de leur parc informatique.

1.1.2- Domaine d’activités

L’entreprise COM-NETWORK offre une palette de services dans le domaine des

technologies de l’information et de la communication (TIC) à savoir :

- L’administration systèmes

- L’administration réseaux

- La sécurité

- La voix sur IP

- Infogérance

- L’ingénierie des systèmes

- L’intégration distribuée

8

1.1.3- Organigramme

9

1.2- Présentation du sujet

1.2.1- Contexte du sujet

Dans le cadre de l’amélioration de la qualité de ses services et de la satisfaction de ses clients,

la Direction des Systèmes d’Information de Com-Network a initié le projet de migration de

son outil helpdesk. L’objectif de ce projet est d’optimiser et d’aligner la gestion des actifs et

des configurations, le processus de gestion des incidents, la gestion des problèmes, la gestion

des changements etc. sur les bonnes pratiques et référentiel.

1.2.2- Problématique et objectifs

L’outil de gestion de ticket utilisé par COM-NETWORK, installé depuis presque huit ans

répond aux besoins basiques des exigences ITSM actuelles mais ne se révèle pas assez

pertinent pour répondre à toutes les problématiques. Elle présente quelques insuffisances

comme la duplication de certains tickets, des difficultés de clôture des tickets, dispose d’une

interface très lourde et non conviviale, pas de possibilité de faire des escalades

automatiques des tickets, le traitement des tournées SAV (Service après-vente) et de la

génération des fiches d’intervention sont manuels etc.

En particulier, le problème de gestion des contrats SAV est majeur et critique parce que le

service CDS à sous sa maintenance plus de huit mille ordinateurs. Tous les matins, le

technicien exporte et traite dans un fichier Excel les demandes de la journée précédente. Ce

fichier est envoyé au responsable du CDS pour la vérification et la programmation des

tournées. C’est à la suite de ce long traitement, fastidieux et très lourd que les fiches

d’intervention sont générées. Il faut noter que les demandeurs n’ont pas la possibilité de se

connecter à l’application pour créer leur incident. Cette charge de travail revient aux

techniciens qui saisissent toutes les demandes reçues par mail ou signalées par téléphone dans

l’outil helpdesk (CRM-Sage).

Puisqu’il s’agit d’une solution propriétaire, le fournisseur a été contacté pour résoudre les

différents problèmes rencontrés. En réponse à cette demande, le prestataire préconise

l’installation d’une nouvelle plateforme qui ne sera rien d’autre qu’une version évoluée de la

solution actuelle. Selon le prestataire, une migration ne serait pas possible à cause de

l’ancienneté de la version du CRM Sage utilisée.

En tenant principalement compte d’une part du coût de la migration et d’autre part du fait que

le domaine principal d’activité du prestataire est la comptabilité et non le développement des

10

outils de gestion des services informatiques, nous pensons qu’il serait nécessaire d’explorer

d’autres solutions spécialisées dans ce domaine et de faire une étude comparative en fonction

des fonctionnalités et du rapport qualité/coût pour aider la direction de COM-NETWORK à

porter un choix technologique qui répondrait mieux aux attentes, besoins et exigences du

centre de service informatique (CDS).

1.2.3- Autres missions

Au-delà du projet de gestion de ticket, je suis chargé d’apporter mon expertise technique

auprès des clients de Com-Network. J’ai aussi pour mission de participer aux déploiements

des nouvelles infrastructures pour répondre aux appels d’offres remportés.

En interne :

o Rédaction et validation de procédures et gestion de la base de documentation

technique

o Formation des techniciens de niveau 1 du centre de service

o Conception, installation et gestion de l’infrastructure de déploiement des

postes internes au Groupe Réel IT

En externe :

o Assistance téléphonique aux utilisateurs des infrastructures mises en place par

la société

o Assistance technique de niveau 2 aux techniciens sur site et à l’ensemble des

services de la société

o Interventions sur site client ou interne en escalade

o Intervention sur site en régie

o Déploiement d’infrastructures pour les clients de la société : Serveurs, firewall,

tunnels VPN, baies de stockage, bornes wifi, pc/tablette ...

Il faut noter que l’équipe du centre de service de Com-Network que j’ai intégré est

constitué de 4 personnes dont trois techniciens et un responsable de service.

11

CHAPITRE 2 : ITSM

12

L’ITSM (Information Technology Service Management) est une approche de gestion des

systèmes d’information orientée services et qui s’appuie sur les bonnes pratiques comme

ITIL, CobiT, ISO 9000,… Elle permet de représenter d’une part, le système d’information

comme un ensemble de capacités, techniques composées de spécialistes et d’autre part de

processus. (Wikipédia).

2.1- Etude de l’existant

L’étude de l’existant nous a permis d’analyser la solution existante afin de faire ressortir les

insuffisances qu’elle présente. Pour atteindre notre objectif, nous avons tenu plusieurs

réunions avec les techniciens qui l’utilisent le plus souvent. Les résultats de cet entretien ont

été confrontés à notre propre expérience sur l’utilisation de la solution helpdesk. Ci-dessous

les différents points que nous avons notés et qui correspond aussi à ceux relevés par les

techniciens :

- La création de ticket se fait uniquement par les techniciens. C’est-à-dire que, le

client ou le demandeur n’a pas le droit nécessaire pour créer un incident. Il est

toujours obligé d’appeler le centre de service. Cette charge de travail en

additionnelle au quotidien des techniciens, leur revient un peu difficile à gérer.

- La duplication des tickets ouverts

- la difficulté de changement de statut des tickets (Des tickets clôturés restent

parfois à l’état initial)

- L’interface n’est pas assez conviviale

- L’escalade des tickets n’est pas automatique

- Les techniciens ne sont pas relancés lorsque le délai de résolution (SLA) est

dépassé

- Pas d’affectation automatique des incidents récurrents aux techniciens

- Pas de possibilité de créer des tickets par mail (Lorsque les utilisateurs envoient

des mails d’incident, le technicien en local est obligé de créer le ticket

manuellement)

- Pas de notification par mail aux clients lorsque le ticket est clôturé. En plus, le

demandeur ne dispose pas d’un lien pour clôturer l’incident ou le réouvrir au cas

où il ne serait pas satisfait de la solution

- Pas de possibilité d’imprimer les fiches d’intervention

- Pas de notification par mail de nouveau ticket aux techniciens

13

2.2- Liste des besoins

Suite aux différents entretiens et réunions organisés avec les techniciens, en plus des

difficultés rencontrées sur la plateforme, nous avons aussi noté différents besoins à savoir :

- La création de ticket ou de déclaration d’incident par les demandeurs eux même

- La création automatique des tickets par mail

- L’escalade automatique des tickets

- Relance automatisée des techniciens lors du délai de résolution dépassée

- Affectation automatique des tickets récurrents aux techniciens

- Clôture des tickets résolus par le demandeur

- Importation et reprise de l’historique en cas de passage vers une autre solution

- Notification par mail de nouveau ticket

- Mise en place d’un Dashboard pour une vue globale ou personnalisée du

traitement des tickets

- Amélioration de l’ergonomie de l’application

- Accès mobile à l’application

- Intégration d’une base de connaissance

- Génération automatique des comptes rendu d’intervention

- Inventaire du parc informatique

- Gestion des changements

- Gestion de projet

- Gestion des règles SLA

- Gestion de règle OLA

- Personnalisation des notifications

2.3- Choix technologiques

Après une étude approfondie des solutions de gestion de solution informatique, nous avons

retenus les suivantes : ServiceNow, GLPI, Pythéas et Sales Force. Dans notre étude, nous ne

prendrons pas en compte les solutions ServiceNow et SalesForce. En effet « ServiceNow » est

une très bonne solution, classée leader du marché ITSM d’après Gartner Magic.

Malheureusement, nous avons tenté de les contacter pour une proposition commerciale en

vain. Jusqu’à présent, nous n’avons pas encore eu un retour de leur part. A propos de « Sales

Force », c’est aussi une bonne solution. Nous avons pu confirmer cela par les différents tests

14

que nous avons réalisés en ligne à la suite de l’obtention d’un compte test qui nous a été

fourni par leur service commercial. Mais le coût de la licence est très élevé à raison de

150€/utilisateur.

2.3.1- Etude comparative des différentes solutions

Dans le tableau ci-dessous, nous avons fait une étude comparative des différentes solutions

retenues afin de porter un choix technologique.

Pythéas GLPI CRM SAGE Commentaire

Gestion des tickets Oui Oui Oui

Création des tickets par mail

Oui Oui Non

Escalade des tickets Oui Oui Non

Validation de la clôture des tickets

Oui Oui Oui

Exportation des rapports Oui Oui Oui

Relance du technicien

après dépassement du délai

de résolution des tickets

- Oui Non

Gestion de stock Oui Oui Non

Gestion de l’historique et de la traçabilité des

mouvements

Oui Oui Non

Inventaire et remonté automatique des

équipements du réseau

Oui Oui Non

Licence + support Payant Libre Payant

Couplage Téléphonie

Informatique (CTI)

Oui Oui Non

Nombre d’invention

simultané

3 Illimité Limité

Affectation automatique des tickets récurrents

Oui Non

Ajout de module personnel Oui Oui Oui Pythéas et CRM-

Sage : En cas de besoin, il faut

contacter le

fournisseur pour le

15

développement de

nouveau module

Wiki intégré Oui Oui Non

Interface

Ergonomie

- Intuitive

- Léger - Conviviale

- Intuitive

- Léger - Conviviale

- Complexe

- Lourde - Non conviviale

2.3.2- Etude comparative des coûts des solutions

Pythéas CRM Sage GLPI

Coût de la licence

Mise en service : 19640€

Licence : 5760 €

4 300 € 0 €

Support 8 700 € 0 € (possible au besoin)

Total Année 1 25 400 € 13 000 € 0 €

Total Année n 5 760 € 13 000 € 0 €

Commentaire Engagement : 3 ans Engagement : 1 an Sans engagement

2.3.3- Solution retenue

Au vu des différentes études comparatives réalisées, nous avons constaté que la solution GLPI

présente plus d’avantages aussi bien sur le plan financier comme fonctionnel.

Solution PYTHEAS CRM SAGE GLPI

☐ ☐ ☒

2.4- Méthodologie

La mise en place d’un système de gestion de parc informatique requiert un travail d’ensemble

avec le service informatique afin de définir de façon précise et clair les différentes

fonctionnalités à mettre en œuvre pour le déploiement de la solution.

Ainsi, avant la mise en place de la solution, une réunion de démarrage a été organisée pour

nous permettre de comprendre le fonctionnement actuellement du service helpdesk dans le but

d’adapter l’outil ITSM sans oublier la prise en compte des bonnes pratiques. Suite aux

16

différentes informations récoltées et après le choix technologique, nous sommes passés à

l’implémentation de la solution. Enfin, après notification de la fin de l’exécution des travaux,

une formation est prévue pour une meilleure prise en charge de la solution. Le travail

proprement dit est réalisé en dix étapes.

- Phase 1 : Etats de service

La réunion de démarrage nous a permis de définir en fonction de l’expérience des techniciens,

les différents états possibles des services pour la configuration des règles SLA.

- Phase 2 : Classification des tickets

A cette étape nous avons défini de commun accord la priorité des différents incidents.

Autrement dit, nous avons identifié en fonction du matériel, le service ou les personnes

concernées par l’incident, le niveau de priorité du ticket pour une meilleure prise en charge.

Toutes ces informations nous permettrons de codifier l’incident (impact, urgence et du délai

de rétablissement) pour pouvoir définir les niveaux de services (OLA).

Impact

Urgence

Bloquant > 10 personnes ou VIP

Bloquant 1

personne

Non bloquant

Critique A définir A définir A définir

Forte A définir A définir A définir

Faible A définir A définir A définir

NB : La priorité se traduit par le délai de résolution (en heure)

- Phase 3 : Escalade des tickets

En fonction de la criticité du ticket nous avons définit les règles d’escalade pour favoriser le

transfert de l’incident à un niveau d’assistance supérieur, principalement à cause d’un manque

de connaissance, 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.

- Phase 4 : État d’un ticket

Pour pouvoir automatiser les règles SLA, nous nous sommes basés sur les états des incidents.

Ces états doivent être connus de tous les acteurs (le demandeur, le technicien et l’escalade).

En fonction des différents états ci-dessous, des règles d’escalades ont été définies.

17

Etat Traitement associé (A définir)

Nouveau, ouvert

En-cours

Suspendu ou en attente

Résolu

Clos ou fermé

- Phase 5 : Classification des incidents

Cette étape nous a aidé à lister les différents types d’incidents possible.

Sécurité Pare-feu, proxy, … etc. (exemple)

Système Linux, Windows, …etc. (exemple)

A remplir A Remplir

A remplir A Remplir

- Phase 6 : Contenu des alertes par mail

Une analyse des différents états de tickets est réalisée pour personnaliser le contenu des

différentes alertes qui seront envoyées aux deux parties impliquées dans le traitement du

ticket.

- Phase 7 : Mise en place de la solution

À la suite de ces différentes informations recueillies, nous sommes passés à l’installation et à

la configuration de la solution.

- Phase 8 : Test de recette

Pour s’assurer du bon fonctionnement du système avant sa mise en production, un test de

validation du bon fonctionnement de chaque module a été réalisé.

- Phase 9 : Formation

Pour garantir une meilleure utilisation du système, nous avons organisés une formation

partielle pour les techniciens et d’autres acteurs susceptibles d’utiliser la solution. Une

deuxième formation plus technique est aussi prévue au courant du deuxième semestre.

- Phase 10 : Mise en production

A partir de cette étape, la solution a été mise en production.

18

CHAPITRE 3 : Implémentation de la solution

19

La solution retenue pour la gestion des tickets est GLPI (Gestionnaire Libre de Projets

Informatiques). GLPI est une application Web développée en 2003, qui permet de gérer le

parc informatique et les services d’assistances.

Dans ce chapitre, nous présenterons l’architecture fonctionnelle de la solution, ses contraintes

ainsi que les différentes configurations mise en place.

3.1- Architecture de la solution

3.2- Contraintes de la solution

3.2.1- Informations d’un ticket

À la suite des différentes réunions tenues avec l’équipe CDS, deux types de tickets sont

retenus. En fonction du profil du demandeur, de son entité d’appartenance et de la catégorie

du ticket, les champs du formulaire varient.

En effet, s’il s’agit d’un contrat de fourniture d’équipement et de maintenance, lors de la

création du ticket, l’utilisateur est appelé à fournir le numéro d’inventaire pour permettre à

l’équipe CDS de vérifier dans leur base interne si l’équipement est toujours sous garantie

(voir figure 1).

Contrairement à un contrat de supervision de parc informatique ou de maintenance de

logiciel, c’est juste la description de l’incident qui est nécessaire (voir figure 2).

20

a- Information des tickets de déclaration d’incident

Informations générales des tickets de type 1

Type, Demandeur, technicien en charge,

Statut du ticket, Source de la demande, Lieu

du demandeur, Tickets liés, pièce jointe,

Champs non obligatoire

Catégorie, Titre, Description Champs obligatoire

Figure 1 : Information des tickets de maintenance

b- Information des tickets de maintenance

En plus des informations du ticket de déclaration d’incident, les tickets de maintenance auront

les informations supplémentaires suivantes.

Informations générales des tickets de type 2

Modèle du produit, Numéro de série,

Numéro d'inventaire, Contact sur site,

Pièce Commandée, Version du produit,

Niveau de Priorité, Contact sur site, Pièce

disponible, Date d'intervention

Champs non obligatoire

Zone d'intervention Champs obligatoire

21

Figure 1 : Information des tickets de maintenance

22

c- Information des tickets d’enregistrement de garantie

3.2.2- Règle SLA et escalade de tickets

Le SLA (Service Level Agreement ou accord de niveau de service) est la formalisation d'un

contrat négocié entre l’entreprise et le client définissant le niveau de service attendu et du

délai maximum de résolution d’un incident ou d’une demande (Jour+1, Heure+4...). Plusieurs

niveaux d'escalades peuvent être définis au sein du SLA. Chaque niveau déclenche des

actions automatiques permettant la résolution du ticket dans les meilleurs délais. Ces actions

se déclenchent avant ou après la date d'échéance du SLA en fonction de la configuration.

23

Dans notre cas :

- Lorsqu’un ticket est à l’état « nouveau » ou lorsqu’il n’est pas pris en charge une

heure après sa date d’ouverture, il est escaladé à l’observateur ou en fonction du type

de ticket il sera attribué directement au technicien.

- Si le ticket est pris en charge et que le temps de résolution atteint la moitié du SLA, un

observateur est affecté au ticket ou le ticket est escaladé au support de niveau 2.

Pour pouvoir réaliser, c’est différente règle nous nous sommes basés sur le formulaire de

l’annexe 1.

3.2.3- Gestion des contrats

Les contrats concernent les accords établis entre des tiers. Avant de procéder à

l’enregistrement des contrats dans GLPI nous avons modifié le formulaire et la base de

données pour ajouter d’autres champs supplémentaires dans le but de l’adapter à nos besoins.

Une alerte est associée à chaque contrat. A un mois de son expiration un mail de notification

est généré pour informer le commercial en charge du client et le responsable du CDS. Cette

alerte leur permettra de mener à l’avance les démarches nécessaires pour son renouvellement.

3.2.4- Fiche d’intervention

La fiche d'intervention ou le rapport d'intervention permet de définir les actions à réaliser chez

un client lors d’une intervention. Elle comprend les détails sur la mission (planning des

travaux à réaliser), le nombre de jours d’interventions, le nom du technicien, l’adresse et le

lieu de l’intervention, la date de l’intervention …etc.

Lorsque le statut d’un ticket est « en cour (attribué) » et nécessite une intervention sur site, le

technicien en charge de la demande est appelé à ajouter les tâches à mener. L’intérêt de ce

module est de pouvoir générer à partir d’un seul clic, la fiche d’intervention qui recense toutes

les informations dont il aura besoin lors de son intervention (Nom du contact sur site, les

tâches à réaliser, le lieu ou adresse d’intervention …).

Notre solution simplifie tout le processus de génération de la fiche d’intervention et permet

aussi aux différents acteurs impliqués de gagner du temps pour le consacrer à d’autres projets.

Nous nous sommes basés sur le plugin « Entités Management » pour réaliser notre fiche

d’intervention (Voir annexe 4).

24

Dans la nouvelle version du plugin que nous avons développé, nous l’avons adapté à nos

besoins sans oublier d’ajouter d’autres informations utiles comme le nom du demandeur, le

numéro du contact, …etc.

3.2.5- Backup

Pour éviter toutes pertes données suite à un incident et de pourvoir restaurer le système dans

son état de fonctionnement, nous avons mis en place un script de backup. Nous avons utilisé

du PowerShell pour le développement du script de sauvegarde. Nous avons aussi mis aussi en

place une tâche pour automatiser la sauvegarde de la base de données de l’application. Cette

tâche se réalise tous les mardis et vendredis à des heures bien définis.

3.2.6- Profil

Nous avons créé plusieurs profils pour assurer la séparation des tâches :

- Le profil demandeur permet au demandeur de créer des tickets

- Le profil comptable permet l’enregistrement des contrats

- Le profil administrateur permet l’administration de l’application ou de faire des

configurations avancées

- Le profil technicien permet de gérer les tickets

- Le profil observateur permet de faire la supervision du traitement des tickets.

3.2.7- Reprise des données

Il s’avère important et primordiale de faire la reprise de données pour garder l’historique des

tickets traité sous l’ancien outil. Nous nous sommes basés sur le plugin « Data Injection »

couplé avec un gabarit personnalisé que nous avons créé sous GLPI pour faire l’importation.

Nous avons importé les données suivantes comme les contacts, les utilisateurs, les entreprises

etc. Mais nous n’avons pas importé les tickets. Nous les avons juste exportés en PDF pour

garder une trace des tickets clôturés.

3.2.8- Autres fonctionnalités

Au-delà de l’implémentation des listes des besoins citées ci-dessus, nous avons :

- Connecté l’application à la base d’authentification interne. Donc les utilisateurs

internes utiliseront le contrôleur de domaine et les utilisateurs externes utiliseront la

base d’authentification de la plateforme.

25

- Configuré un relay SMTP pour assurer l’envoie des notifications

- Intégré fusionInventory pour assurer l’inventaire du parc informatique

- Déployé un script d’installation de l’agent fusionInventory sur tout le parc à travers un

GPO

- Configurer OPcache pour améliorer de la performance de l’application.

3.3- Sécurité

Au regard de l’importance de la technologie dans le monde actuelle, de la guerre de

l’information et des différentes attaques informatiques contribuant parfois à la faillite de

beaucoup d’entreprises, la sécurité se positionne donc au cœur de l’informatique. Autrement

dit, elle devient une branche transversale à tous les domaines technologiques. C’est dans cette

logique qu’après le déploiement de notre plateforme, nous avons configuré des mesures de

sécurité pour éviter autant que possible tout intrusion ou attaque.

- Désactivation du listing des répertoires

- Affichage de fausse bannière

- Personnalisation des messages d’erreur ou d’information contre le scanning (Analyse

de bannière)

- Chiffrement des informations entre l’utilisateur et le serveur

- Arrêt des services non utilisés

- Masque des extensions des pages pour éviter la détection des technologies utilisées

- Redirection des trafics http vers du https

- Désactivation de tous les ports non utilisés

- Changement de l’option ServerSignature en OFF

26

Conclusion

La communication est un axe très important en entreprise par sa contribution à son évolution,

à l’amélioration de la qualité de service, de son image et de son chiffre d’affaire. Ceci

explique donc l’intérêt de notre projet qui s’inscrit dans l’amélioration du service support

qu’offre COM-NETWORK et de sa relation avec ses clients à travers la mise en place d’un

canal de communication avec le Service de support, autant pour notifier les demandes ou

incidents et aussi pour suivre l’évolution de leur prise en charge.

Nous tenons à souligner que la plateforme est déjà en production et que le projet a été réalisé

dans un délai de quatre mois pour une présente de deux mois en entreprise et deux mois à

l’université.

A la fin du projet, nous avons réalisé une enquête dont les résultats ci-dessous nous

confirment la satisfaction des techniciens et des responsables :

- Bon fonctionnement de la plateforme

- Respect du cahier de charge

- Respect du délai de déploiement selon le planning

- Réalisation d’un bénéfice de 13.000 € à 25.400 € pour le frais de déploiement et de

5.760 € à 13.000 € pour les frais de maintenance (par an).

Enfin, durant notre alternance, nous n’avons pas rencontré de difficulté majeure. L’intégration

à l’entreprise et surtout au sein de mon équipe s’est très bien passée. Nous avons aussi eu

accès à toutes les ressources et conditions nécessaires pour pourvoir réaliser le projet.

Mais la seule difficulté à laquelle nous nous sommes confronté est la résistance au

changement. Ce que je juge normale, parce que la majorité des gens ont peur de l’inconnu, de

la rupture du routing, … Dans le but d’atteindre nos objectifs, j’ai essayé de les associées au

projet et dans la prise des décisions. Je leur ai aussi garantie ma disponibilité et mon aide au

cas où ils seront confrontés à des difficultés d’exploitation et techniques de la solution.

Du côté de la direction, il avait une petite crainte par rapport au délai de réalisation du projet

vu la charge du travail que cela nécessitait alors qu’on était à quatre mois de la fin du contrat.

N’ayant pas une connaissance large de ma qualité du travail bien fait et d’atteinte des

objectifs, j’ai pu les rassurer de mes compétences techniques, de ma possibilité à réaliser le

projet dans ce court délai de quatre mois (deux mois de présence en entreprise), des valeurs

ajoutées que j’apporterai à travers plusieurs documents élaborés (étude comparative des

solutions ITSM, les valeurs ajoutées, l’intérêt financier, le planning etc.). De ce fait, une

27

rupture du contrat a été envoyée au prestataire, ce qui marqua ainsi le début de mon projet. Je

tiens à rappeler que tout au long du projet j’ai rassuré la direction à travers des rapports

réguliers sur l’évolution du déploiement.

Enfin, pour faciliter la prise en charge de la solution par les utilisateurs et les techniciens j’ai

rédigé une documentation technique et d’utilisation.

28

Webographie

[W1] https://wiki.octopus-itsm.com/fr/articles/Glossary (Consulter le 07 Octobre 2020)

[W2] https://glpi-project.org/fr/ (Consulter le 07 Octobre 2020)

[W3] https://dumas.ccsd.cnrs.fr/dumas-01240429/document (Consulter le 18 Octobre 2020)

Annexes

- Annexe 1 : Dashboard de supervision

- Annexe 2 : Interface d’accueil de l’application

29

- Annexe 3 : gestion des SLA

Ticket affecté au SLAs

Catégorie de

ticket Technicien

Groupe de

technicien

Temps de

prise en

charge

Temps de

résolution

Temps

d'escalade

Escalade

N+1

Escalade

N+2

VMware

Réseaux

Hardware

TOIP

Firewall

Sécurité

Microsoft

Backup-

Windows

Backup

Backup-Veam

Backup

Office 365

NetApp

Datacore

Messagerie-

Messagerie-

Client Outlook

Messagerie-

serveur

exchange

Active

Directory

Alimentation

électrique

Antivirus

Application

Comptable

Application

Sage saari

Application

Spécifique

Bureautique

Client léger

Impression

Ordinateur

Autre

30

Annexe 4 : Fiche de d’intervention