Mastère Spécialisé

Ingénierie des Systèmes d’Information

Thème :

Implémentation d’un système d’information

de support et de fourniture de services informatiques
selon le guide des bonnes pratiques I.T.I.L® v.3
adapté au contexte du F.N.I

Présenté par : Encadré par :

Mr. ADJIMI Kamel E ddine. Mr.YAHIATENE Youcef.

- Février 2023 -
 PLAN DE MEMOIRE
Page
Dédicaces ..................................................................................................................................... ii.
Remercîments ............................................................................................................................. iii.
Liste des figures .......................................................................................................................... iv.
Liste des tableaux ....................................................................................................................... vii.

INTRODUCTION GENERALE.................................................................................................. 1
Chapitre 01 : Présentation du projet.
1.1. Introduction ........................................................................................................................... 4
1.2. Présentation de l’organisme d’accueil................................................................................... 4
1.2.1. L’historique de l’institution ................................................................................................ 4
1.2.2. L’organigramme général .................................................................................................... 7
1.2.3. Orientations stratégiques du fonds ..................................................................................... 9
1.2.4. Les activités principales du fonds ...................................................................................... 9
1.3. Présentation de la structure informatique…………………………… .................................. 10
1.3.1. Organisation de l’activité informatique.............................................................................. 10
1.3.2. Les principales missions et attributions de la D.O. I........................................................... 11
1.3.3. Les attributions du département organisation D.O. I .......................................................... 11
1.3.4. Les attributions du département études et réalisations informatiques (D.E.R.I) ……....... 12
1.3.5. Les attributions du département exploitation et maintenance informatique (D.E.M.I) .... 12
1.3.6. Les principales missions et attributions du service informatique (D.R) ........................... 12
1.4. Présentation du projet………………………………………………………. ....................... 13
1.4.1. Contexte du projet………………………………………………………… ...................... 13
1.4.2. Les objectifs escomptés dans le cadre du mémoire…………………………………….... 14
1.4.3. La problématique à résoudre………………………………………………… .................. 15
1.4.4. La solution proposée…. ..................................................................................................... 15
1.5. Conclusion………………………………………………...…… .......................................... 15
Chapitre 02 : Etat de l’Art : La gestion classique du parc informatique.
2.1. Introduction ........................................................................................................................... 17
2.2. Les fondements de la gestion de parc informatique…………………………… .................. 17
2.2.1. La raison d’être de la gestion de parc ................................................................................. 17
2.2.2. Les processus de base de la gestion du parc....................................................................... 18
2.2.3. Le cycle de vie d’un bien informatique .............................................................................. 18
2.2.4. La structure des couts ......................................................................................................... 19
2.2.4.1. Les coûts d’acquisition .................................................................................................... 19
2.2.4.2. Les coûts d’administration……………………………………………… ...................... 19
2.2.4.3. Les coûts d’assistance………………………………………………… ......................... 20
2.2.4.4. Les coûts indirects…………………………………………………………… ............... 20
2.3. La gestion administrative du parc………………………………………… ......................... 21
2.3.1. Pré requis…………………………………………………………………… .................... 21
2.3.2. Réaliser l’inventaire initial……………………………………………… ......................... 21
2.3.3. La base administrative……………………………………………………. ....................... 22
2.3.4. Détail de la configuration…………………………………………………… ................... 23
2.3.5. L’immatriculation…………………………………………………………....................... 23
2.3.6. Les mouvements de matériels……………………………………………. ....................... 23
2.3.6.1. Les entrées…... ................................................................................................................ 23
2.3.6.2. Les déplacements de matériels ........................................................................................ 24
2.3.6.3. Les sorties…………………………… ............................................................................ 24
2.3.7. Les mouvements des utilisateurs…. ................................................................................... 25
2.3.7.1. L'arrivée des utilisateurs …. ............................................................................................ 25
2.3.7.2. Les changements de statut …. ......................................................................................... 25
2.3.7.3. Le départ des utilisateurs …. ........................................................................................... 25
2.3.8. Les bénéfices de la gestion administrative………………………………… ..................... 25
2.4. La gestion technique du parc……………………………………………....... ...................... 26
2.4.1. La base technique…... ........................................................................................................ 26
2.4.1.1. Fiche d’inventaire dynamique…………………………………………… ..................... 26
2.4.1.2. Les procédures de mise à jour…………………………………………… ..................... 27
2.4.1.3. Les configurations type…………………………………………………. ...................... 27
2.4.1.4. Le bouclage avec la gestion administrative……………………………......................... 27
2.5. Conclusion…... ...................................................................................................................... 27
Chapitre 03 : Introduction à la méthode I.T.I.L® v 3.0.
3.1. Introduction…………………………………………………………… ............................... 29
3.2. Présentation de la méthode I.T.I.L……………………………………………… ................ 29
3.2.1. Historique ........................................................................................................................... 29
3.2.2. La genèse… ........................................................................................................................ 29
3.2.3. L’évolution…………………………………………………… ......................................... 29
3.2.4. Les fondements de la méthode I.T.I.L…………………… ............................................... 30
3.2.5. Le positionnement de la méthode I.T.I.L dans la D.S.I……………… ............................. 30
3.2.6. La culture organisationnelle………………………………………… ............................... 31
3.2.7. Les principes de base d’I.T.I.L…………………………………… ................................... 31
3.2.8. Les concepts fondateurs d’I.T.I.L……………………………….…… ............................. 32
3.2.9. I.T.I.L et l’approche orientée service……………………………… ................................. 32
3.2.10. Le contenu d’I.T.I. L… .................................................................................................... 32
3.2.11. Les apports avantageux d’I.T.I.L………………………………………… ..................... 33
3.2.12. Les nouveautés par rapport à la v2.0……………………………………… .................... 34
3.2.13. Les bénéfices de la mise en œuvre de la v3.0……………………………… .................. 34
3.2.14. Problèmes potentiel d’I.T.I.L……………………………………………. ...................... 36
3.3. Le référentiel I.T.I.L……………………………………… .................................................. 36
3.3.1. Terminologie et définitions……………………………………………...… ..................... 36
3.3.2. L’évolution de la vision en matiere de gestion informatique…………… ......................... 38
3.3.2.1. La vision depassée……………………………………………… ................................... 38
3.3.2.2. La vision services informatiques………………………………… ................................. 39
3.3.3. Les fournisseurs externes………………………………………………...… .................... 39
3.3.4. L’approche de la gestion des services………………………………… ............................ 40
3.3.5. La fourniture de la valeur aux clients………………… ..................................................... 40
3.3.6. Les ressources et les aptitudes ............................................................................................ 41
3.3.7. Concevoir des processus .................................................................................................... 42
3.3.8. Utilité et Garantie…………………………………………… ........................................... 43
3.3.9. Le noyau de la méthode I.T.I.L…………………………… .............................................. 44
3.4. Conclusion……………………………………………………………… ............................. 44
Chapitre 04 : Cadre théorique d’un centre de service selon I.T.I.L® v 3.0.
4.1. Introduction ........................................................................................................................... 46
4.2. Le centre de service………………………………………………………… ....................... 46
4.2.1. Les technologies de centres de services…………………… ............................................. 47
4.2.1.1 Centre de service local………………………………………………… ......................... 48
4.2.1.2. Centre de service mutualisé……………………………………………......................... 49
4.2.1.3. Centre de service virtuel…………………………………………… .............................. 49
4.2.2. Interface avec les autres processus .................................................................................... 50
4.3. La gestion des incidents…………………………………………… .................................... 50
4.3.1. Définitions et terminologie…………………………………………………..................... 51
4.3.2. Les niveaux d’escalades…………………………………………...…… .......................... 52
4.3.3. Description du processus de la gestion des incidents……………… ................................. 52
4.3.4. Planification et mise en œuvre ........................................................................................... 54
4.3.5. Mesures et contrôle ............................................................................................................ 54
4.3.6. Rapport de gestion…………………………………………………………… .................. 54
4.3.7. Les conséquences de l’implémentation du processus de la gestion des incidents ............. 55
4.3.8. Les outils……………………………………………………………………… ................ 55
4.3.9. Rôles et responsabilités……………………………………………………… .................. 55
4.3.10. Interface processus……………………………………………… ................................... 56
4.4. La gestion des problèmes…………………………………………… .................................. 56
4.4.1. Description du processus de la gestion des problèmes…………… .................................. 57
4.4.2. Planification et mise en œuvre……………………………………… ............................... 60
4.4.3. Mesures et contrôle…………………………………………………… ............................ 60
4.4.4. Rapport de gestion……………………………………………………………… .............. 61
4.4.5. Les conséquences de l’implémentation du processus de la gestion des problèmes ........... 61
4.4.6. Rôles et responsabilités…………………………………………………………... ........... 61
4.5. La gestion des niveaux de services……………………………………………… ............... 62
4.5.1. Définitions et terminologie……………………………………………………................. 62
4.5.2. Description du processus de la gestion des niveaux de services……………….... ............ 63
4.5.3. Planification et mise en œuvre…………………………………………… ....................... 64
4.5.4. Mesures et contrôles…………………………………………………… ........................... 66
4.5.5. Couts……………………………………………………................................................... 66
4.5.6. Documents et rapports……………………………………………………………... ......... 66
4.5.7. Conséquences d’implémentation de la gestion des niveaux de services……....... ............. 66
4.5.8. Rôles et responsabilité ........................................................................................................ 67
4.6. Conclusion………………………………………………………………………… ............. 68

Chapitre 05 : Analyse de l’existant et étude des besoins.

5.1. Introduction ........................................................................................................................... 70
5.2. Analyse de l’existant ............................................................................................................. 70
5.2.1. Recensement des contraintes du site .................................................................................. 70
5.2.2. Délimitation du périmètre de l’étude ................................................................................. 72
5.2.3. Diagnostique approfondis du domaine de l’exploitation ................................................... 72
5.2.3.1. La gestion du parc informatique...................................................................................... 72
5.2.3.2. La supervision des ressources informatiques .................................................................. 73
5.2.3.3. La sécurité informatique.................................................................................................. 74
5.2.3.4. L’organisation et les procédures ..................................................................................... 77
5.3. Etude des besoins .................................................................................................................. 78
5.3.1. Besoin d’ordre technique ................................................................................................... 78
5.3.2. Besoin d’ordre organisationnel .......................................................................................... 78
5.3.3. Besoin d’ordre matériel ...................................................................................................... 79
5.3.4. Besoin d’ordre opérationnel ............................................................................................... 79
5.3.5. Besoin d’ordre managérial ................................................................................................. 79
5.4. Plateforme cible du projet ..................................................................................................... 79
5.5. Recommandations de mise en œuvre du projet ..................................................................... 80
5.6. Conclusion ............................................................................................................................. 82
Chapitre 06 : Implémentation de la solution.
6.1. Introduction ........................................................................................................................... 84
6.2. Introduction à la solution technique ...................................................................................... 84
6.3. Contexte actuel de l’exploitation........................................................................................... 84
6.4. Choix de la solution............................................................................................................... 85
6.5. Description technique de la solution ..................................................................................... 85
6.5.1. Architecture de la solution ................................................................................................. 85
6.5.2. Environnement de production cible ................................................................................... 86
6.5.3. Environnement matériel et virtuel ...................................................................................... 86
6.6. Implémentation technique de la solution .............................................................................. 87
6.7. Paramétrage et configurations avancées de la solution ......................................................... 94
6.7.1. Paramétrage technique ....................................................................................................... 94
6.7.2. Paramétrage fonctionnel ..................................................................................................... 97
6.7.2.1. La mise en place du service desk .................................................................................... 97
6.8. Implémentation du processus de la gestion des incidents ..................................................... 99
6.9. Implémentation du processus de la gestion des problèmes ................................................... 107
6.10. Implémentation du processus des niveaux de services ....................................................... 108
6.11. Rapports et statistiques ........................................................................................................ 111
6.12. La base de connaissances .................................................................................................... 112
6.13. Maintenance de la solution helpdesk .................................................................................. 113
6.13.1. La sauvegarde et l'archivage ............................................................................................ 113
6.13.2. La fréquence des sauvegardes .......................................................................................... 114
6.13.3. La restauration .................................................................................................................. 115
6.14. Pistes d’audit Glpi ............................................................................................................... 115
6.15. Recommandations techniques et perspectives .................................................................... 116
6.16. Conclusion ........................................................................................................................... 116

CONCLUSION GENERALE ...................................................................................................... 117

BIBLIOGRAPHIE ....................................................................................................................... 118
WEBOGRAPHIE ......................................................................................................................... 119
ANNEXE 1 : Scripte de sauvegarde et d’archivage des bases de données.................................. I
ANNEXE 2 : Gestionnaire de taches cron (ubuntu) : Le contenu du fichier crontab .................. II
GLOSSAIRE ................................................................................................................................ III
 ii.

Dédicaces

Ce travail est dédié en premier lieu à ma chère mère et chère épouse

qui m’ont soutenu et solidifiée ma volonté de vivre mon métier,

A Mon adorable enfant si bien gentil.

En second lieu à notre institution pour l’appui inconditionnel au renforcement

de mes connaissances et de mon expérience par le cursus du mastère spécialisé
au sein de l’I.S.G.P,

A nos amis et collègues des autres organismes, fière d’avoir l’occasion

de se connaitre et d’échanger activement.

A nos illustres enseignants et personnel pédagogique de l’I.S.G.P.

 iii.

Remercîments

Par ce présent mémoire, il y a lieu de témoigner de notre profonde

gratitude à toute personne ayant contribuée de près ou de loin chacune
par sa proportion dans l’accomplissement et à la réalisation de nos travaux.

Tous d’abord, remerciant notre institution pour l’accord et l’autorisation

de se former au sein du glorieux établissement de formation l’I.S.G.P,

A remercier vivement notre D.S.I : Mr. MAHFOUDI Kamel

pour son engagement indéfectible à l’objet de notre thèse.
A Madame SERBOUH notre honorable responsable au niveau de la D.R.H
pour le soutient, et l’accompagnement continu.
Saluer grandement notre encadreur Mr. YAHIATENE Yousef
de par sa réactivité et son professionnalisme avéré.

Aussi un grand remercîment adressé spécifiquement à Mme.MELIANI

et à Mme.OUARET du département économie numérique au sein de l’I.S.G.P
pour son accompagnement, l’écoute et les précieuses orientations.

A nos vénérables et formidables professeurs qui ont marqués finement leurs

empruntes dans nos esprits et ce durant tout le cursus.

A tous le corps enseignant de l’I.S.G.P,

A tous nos collègues du F.N.I et amis de l’I.S.G.P si respectueux et fraternels.
 iv.
Liste des figures
Page
Figure 1 : Organigramme général du F.N.I ................................................................................ 8
Figure 2 : Organisation interne de la D.O.I ..........................................................................................10
Figure 3 : Cycle de vie d’un bien informatique ....................................................................... 18
Figure 4 : Les trois grandes missions du S.I .........................................................................................31
Figure 5 : Cercle de qualité de Deming ................................................................................................33
Figure 6 : Niveaux de publication I.T.I.L .............................................................................................33
Figure 7 : Phases du cycle de vie I.T.I.L® v 3.0 ............................................................................ 33
Figure 8 : Processus et fonctions I.T.I.L® v3.0.................................................................................35
Figure 9 : La vision classique de la gestion informatique ........................................................ 38
Figure 10 : La vision service informatique ...........................................................................................39
Figure 11 : Fourniture de service ............................................................................................. 40
Figure 12 : Ressources et aptitudes .......................................................................................... 41
Figure 13 : Architecture d’un processus type........................................................................... 42
Figure 14 : Processus et organisation ....................................................................................... 43
Figure 15 : Centre de service local ........................................................................................... 48
Figure 16 : Centre de service mutualisé ................................................................................... 49
Figure 17 : Centre de service virtuel ........................................................................................ 50
Figure 18 : Interface du service desk avec les autres processus I.T.I.L® ................................ 50
Figure 19 : Flux simplifie du processus de gestion des incidents ............................................ 53
Figure 20 : Synoptique du processus de gestion incidents ....................................................... 54
Figure 21 : Interface de la gestion des incidents avec les autres processus I.T.I.L® ............... 56
Figure 22 : Schéma simplifié du contrôle des problèmes ........................................................ 57
Figure 23 : Schéma simplifié du contrôle des erreurs .............................................................. 58
Figure 24 : Flux simplifié de la gestion des niveaux de services ............................................. 64
Figure 25 : La gestion des niveaux de services ........................................................................ 68
Figure 26 : Architecture de déploiement des domaines active directory du F.N.I ......................75
Figure 27 : Architecture globale de l’interconnexion du F.N.I ......................................................75
Figure.28 : Installation du serveur d’administration ................................................................ 87
Figure.29 : Accès à distance au serveur Ubuntu ...................................................................... 87
Figure.30 : Interface d’accès à la solution glpi .....................................................................................91
 v.
Figure.31 : Interface d’administration PhpMyAdmin .............................................................. 92
Figure.32 : Importation des bases de données.......................................................................... 92
Figure. 33 : Interface du serveur OCS Inventory (Serveur) ..................................................... 93
Figure. 34 : Migration de la base de données Glpi................................................................... 93
Figure. 35 : Migration de la base de données ocsweb .............................................................. 93
Figure. 36 : Accès système au serveur F.T.P ........................................................................... 94
Figure. 37 : Configuration des notifications Glpi .................................................................... 95
Figure. 38 : Réception des messages sous Outlook (@fni.bis) ................................................ 95
Figure. 39 : Configuration de la liaison ldap concernant une structure du F.N.I ..................... 95
Figure. 40 : Répertoire des plugins Glpi .................................................................................. 96
Figure. 41 : Activation des plugins via interface Glpi ............................................................. 96
Figure. 42 : Configuration du serveur OCSNG sous Glpi ....................................................... 96
Figure. 43 : Imploration des machines dans Glpi..................................................................... 97
Figure. 44 : Matrice de dérivation des priorités ..................................................................... 100
Figure. 45 : Configuration de la matrice d’évaluations de la priorité Glpi ............................ 101
Figure. 46 : Règles métiers pour les tickets Glpi ................................................................... 101
Figure. 47 : Ouverture d’un ticket d’incident dans Glpi par un utilisateur ............................ 102
Figure. 48 : Validation du ticket par le responsable du helpdesk .......................................... 103
Figure. 49 : Prise en charge d’un ticket d’incident dans Glpi ................................................ 104
Figure. 50 : Suivi d’un ticket d’incident ................................................................................ 105
Figure. 51 : Ajout des taches à effectuer ou effectuées .......................................................... 105
Figure. 52 : Message d’information Glpi ............................................................................... 106
Figure. 53 : Adoption de la solution concernant l’incident .................................................... 106
Figure. 54 : Clôture de l’incident ........................................................................................... 107
Figure. 55 : Création de problème ......................................................................................... 107
Figure. 56 : Tickets liés au problème Glpi ............................................................................. 108
Figure. 57 : S.L.A définis dans Glpi ...................................................................................... 109
Figure. 58 : Configuration du S.L.A (Ex : S.L.A Développement) ....................................... 109
Figure. 59 : Configuration des niveaux d’escalades (Ex : S.L.A Messagerie) ...................... 110
Figure. 60 : Les tickets d’incidents liés (Ex : S.L.A : Maintenance) ..................................... 110
Figure. 61 : Statistiques sur les tickets Glpi ........................................................................... 111
Figure. 62 : Tableau de bord avancé (Plugin Dashboard) ...................................................... 112
Figure. 63 : Foire Aux Questions : F.A.Q .............................................................................. 112
 vi.

Figure. 64 : Sauvegarde manuelle des bases de données Glpi ............................................... 113

Figure. 65 : Accès en mode graphique (WinScp) .................................................................. 114
Figure. 66 : Journalisation des actions Glpi ........................................................................... 115
 vii.

Liste des tableaux

Page

Tableau 1 : Fiche d’inventaire administratif. ........................................................................... 22

Tableau 2 : Fiche d’inventaire dynamique ............................................................................... 26
Tableau 3 : Priorités de traitement et délais associés ............................................................. 105
 INTRODUCTION GENERALE
A l’issu de l’ouverture de l’entreprise sur l’environnement économique national,
la survie de cette dernière se trouve menacée par la concurrence acharnée du monde
des affaires ce qui conduit à imposer de nouvelles règles impactant directement le fond
du métier. L’entreprise est obligée de bien redéfinir ses objectifs et ces finalités modifiant
progressivement sa structure interne et ses méthodes de travail,
Plus concis encore l’entreprise devra constituer une vision complète et claire
de sa situation puis à concevoir une stratégie orientée et suffisamment murie
en la faisant déclinée sur un plan opérationnel en politiques ciblées et adéquates à chaque
domaine et fonction.
Ce travail en amont permet d’hisser les bases nécessaires d’un plan d’action précis
une fois établie et mis aussitôt en application les résultats ne seront que positifs manifestés
par l’augmentation du dynamisme interne et l’évolution qualitative du niveau de formalisme.
De ce qui précède l’entreprise va s’inscrire dans un processus de changement visant
à faire adapter continuellement les processus internes, à mieux orienter les activités
et en développer d’autres si le besoin constitue un impératif (besoin justifié).
Le développement massif de l’utilisation soutenue des technologies de l’information
et de la communication T.I.C représente l’une des conséquences de ce progrès professionnel
impliquant non seulement l’émergence de nouvelles organisations mais aussi de nouvelles
techniques et pratiques visant à impacter en profondeur la qualité de travail, ce qui contribue
directement ou indirectement à développer une forme de dépendance qualifiée de forte.
Faisant partie du package des T.I.C, l’informatique dans l’entreprise a évolué à travers
plusieurs stades partant de l’automation simple des processus, à la prise de conscience,
à l’optimisation puis vers l’extension du domaine applicatif jusqu’à la mise en place
d’un système d’information intégré en interne et par la suite externalisé aux différents
partenaires.
Supporter tous le système d’information de l’entreprise confère à la structure
informatique une place importante et un caractère névralgique.
L’expérience quotidienne dans le domaine de l’exploitation informatique engendre
systématiquement un accroissement rapide des exigences en matière de disponibilité,
de criticité, de sécurité, d’optimalité,… ce qui met la structure technique devant un vrai défi.
La satisfaction des besoins tous azimuts des différents clients et partenaires demeure
toujours la préoccupation centrale, par contre la performance, l’efficience, la maitrise
et l'optimisation des couts constituent des objectifs difficiles à atteindre, conjugués à l'étendu

1
et à la taille de l'organisation informatique en place, la répartition géographique,
et la multiplicité des acteurs et des intervenants.
De ce qui précède, vu que les ressources informatiques sont considérées comme
stratégiques, la D.S.I est face à une problématique complexe i.e. à la fois économique
et technique en termes de gestion.
Fort de cette thèse, l’évidence de réviser la manière de gérer et de penser l’activité
informatique s’impose.
Résoudre cette problématique de manière quasiment systématique, revient à adopter
en interne un référentiel technique reconnu dans le monde de l'informatique comme modèle
de gestion normatif.
Il existe de nouvelles approches et méthodologies novatrices éprouvées
par les expériences en matière de la gestion optimale des services informatiques portent
sur une structuration plus compacte et plus rationnelle et mieux organisée dont les résultats
attestent d’une qualité irréprochable et d’un professionnalisme avéré.
L'objectif et le sens de notre travail s'articule sur la mise en application au sein
de la D.S.I d'une méthode de travail formelle, rationnelle, unifiée et complètement structurée
inspirée d'un référentiel unique déjà expérimenté par les grandes entreprises (boites)
informatiques mondiales.
Pour ce faire, notre thèse traitant ce sujet sera constituée de plusieurs chapitres orientés
chacun selon un objectif :
Le chapitre 1 : Consacre l'introduction générale du projet dans l'institution.
Le chapitre 2 : Décrit la gestion classique des ressources informatiques.
Le chapitre 3 : Introduit de manière générale la méthode I.T.I.L.
Le chapitre 4 : Décrit en détail la fonction centre de services ainsi que les processus
de base (objet d'étude) du model I.T.I.L v3.0 coté support et fourniture de service.
Le chapitre 5 : Consacré à l’étude de l'existant informatique et analyse des besoins.
Le chapitre 6 : Implémenter la solution technique retenue conformément au modèle
I.T.I.L v3.0 proposé dans le cadre de l'étude (Chapitre 4).

2
 Chapitre 01 :
Présentation du projet

3
1.1. Introduction :
Le chapitre est consacré entièrement à la présentation de l’entreprise, suivi d’un descriptif
de l’organisation interne jusqu’à la structure informatique puis introduire le projet
en question de façon progressive.
1.2. Présentation de l’organisme d’accueil :
1.2.1. Historique de l’institution :
L’organisme d’accueil représente une institution financière étatique sous tutelle du ministère
des finances. L’institution a évolué depuis l’indépendance du pays en adoptant plusieurs rôles
et contributions au développement de l’économie nationale. Les phases de son évolution sont
déclinées comme ce qui suit :

Phase n° 01 : de 1963 à 1970 : La C.A.D1.

La caisse algérienne de développement créée par loi N° 63.165 du 7 mai 1963. [1]
Les missions qui lui sont attribuées sont :
 Chargée de l’exécution du budget d’investissement en octroyant directement
des crédits à long terme, ou des prêtes par signature.
 Chargée de la gestion d’un certain nombre de crédits gouvernementaux, mis
à la disposition de l’Algérie, principalement par les pays dits « socialistes » et destinés
au financement du développement.
 Prendre un certain nombre de participations dans le capital de P.M.E créées sous forme
de sociétés d’économie mixte (public/privé). [27]
Phase n° 02 : de 1970 à 1988 : La B.A.D.
Ces deux décennies voient la C.A.D devenue Banque Algérienne de Développement
(B.A.D) aux termes de l’ordonnance n° 71-47 du 30 juin 1971 et l’ordonnance
N° 72.26 du 07 juin 1972 évoluant comme un intervenant majeur dans le financement
des investissements planifiés. [1]
L’action de la banque va ainsi couvrir trois domaines principaux :
 L’équipement public :
Financé par concours définitifs sur budget de l’état, il recouvre essentiellement
les infrastructures socio-économiques, ferroviaires, hydrauliques, socio-éducatives,
de santé, …etc.

1. C.A.D : Caisse Algérienne de Développement.

4
  Le financement du secteur productif :
Vise la mise en place essentiellement par le secteur public des grands investissements
productifs de base, La B.A.D prend en charge la mise en place sur ressources
budgétaires des (C.I.L.T1).
Le suivi financier de tous les projets individualisés (Procédure de visa B.A.D).
 Le Financement extérieur :
L’appel aux concours externes, a amené la B.A.D à s’investir fortement dans
la recherche, la mise en place et la gestion de financements extérieurs diversifiés auprès
d’institutions bancaires privées ou d’institutions gouvernementales, régionales
ou multilatérales. [27]
Cette fonction, sera rapidement étendue à la gestion pour le compte de l’état,
par application d’accords intergouvernementaux :
- Crédits gouvernementaux émanant des pays dits « socialistes »
- Accords multilatéraux, tels les protocoles financiers de l’Accord de Coopération
avec la C.E.E 2 (à partir de 1981),
-Crédits de Coopération consentis par la R.A.D.P à des pays d'Afrique.
Phase n° 03 : de 1988 à 1994.
Dès 1986, dans le cadre du lancement de réformes économiques, l’état à engager une série
d’actions :

 Un désengagement progressif de l’état du financement direct concernant le secteur

productif,
 Coopération avec les institutions monétaires internationales F.M.I 3, B.I.R.D 4.
Le désengagement de l’état s’étendant à la sphère de l’administration et de gestion,
la B.A.D s’est trouvée naturellement chargée, par l’administration financière de :
 Souscrire en tant qu’emprunteur auprès des bailleurs de fonds désignés par les accords
intergouvernementaux, des conventions de mise en œuvre des financements,
 Mener à bien l’exécution du P.E.C, assortie d’une nouvelle priorité, celle
de recouvrer auprès des bénéficiaires la totalité des C.I.L.T alloués.
1. C.I.L.T : Crédits Internes à Long Terme.
2. C.E.E : Communauté Economique Européenne : Ancienne composante de l'Union Européenne.
3. F.M.I : Fonds Monétaire International: Institution internationale regroupant 188 pays,
dont le but est de promouvoir la coopération monétaire internationale.
4. B.I.R.D : Banque Internationale pour la Reconstruction et le Développement : Fondée en 1944 afin
d’accompagner la reconstruction de l’Europe au lendemain de la seconde guerre mondiale.

5
  La gestion et l’administration des prêts consentis à l’Etat, par les institutions
financières régionales et multilatérales (B.I.R.D, F.I.D.A5, F.A.D.E.S 6,...etc). [27]

Phase n° 04 : de 1995 à 1999.

L’année 1995 constitue une année charnière dans l’évolution de la B.A.D, sa marque la fin
de l’intervention de la banque dans le financement du secteur productif sur ressources
budgétaires. Le 31 décembre 1994 a été en effet fixé, comme terme ultime à la distribution
des C.I.L.T qui continuaient à être alloués au secteur productif sous le vocable de Programme
en Cours. Cet événement a mis en évidence, la nécessité impérieuse de restructurer la banque,
qui s’était fait sentir au demeurant, avec le désengagement du Trésor public. [27]
Phase n° 05 : de 1999 à 2009.
Depuis 1999, la banque a inscrit ses actions dans une perspective de restructuration
et de son intégration dans le système financier et bancaire national. Cette période
a vu la baisse de son activité globale. La banque s’est attachée à préparer les conditions
de sa restructuration notamment par la poursuite de l’assainissement de son portefeuille
et de ses comptes sociaux. Une reprise du volume d’activité est notable depuis l'exercice 2006
à la faveur des programmes gouvernementaux de financement des grands projets
d’équipement public et du financement des investissements sur ressources du Trésor.
Parallèlement, en 1999 puis en 2001 et en 2005, la B.A.D a formulé de nouvelles propositions
de relance de ses activités, s’inscrivant dans la nouvelle configuration du secteur bancaire
et financier qui se profile.
Phase n° 06 : de 2009 à 2011.
La L.F.C de 2009 portant sur la restructuration de la B.A.D en F.N.I – B.A.D en le dotant
d’un capital de 150 Milliard de Dinars suivi de l’installation d’un nouveau Conseil
de Direction et un Comité Stratégique d'Orientation pour la Transition. La loi de finances
complémentaires de 2011 article 37 modifiant définitivement la dénomination F.N.I-B.A.D
par F.N.I. Ce fonds a été créé par les pouvoirs publics à l'effet de promouvoir
de nouveaux instruments indispensables à l'intervention de l'état dans le financement
du développement économique. Cette action entre dans le cadre du parachèvement
du processus de réforme du secteur financier et bancaire engagé par l’état. [27]

5. F.I.D.A : Fonds International de Développement : Institution spécialisée du système des Nations Unies.
6. F.A.D.E.S : Le Fonds Arabe de Développement Economique et Social.

6
Phase n° 07 : de 2011 à ce jour.
Conformément aux changements attendus par les pouvoirs publics suite à la mutation
en fonds d’investissement, L’institution a pris la décision d’adopter un plan de modernisation
globale (P.S.M1) dans l’objectif d’améliorer et de développer ses capacités et de s’adapter
sur le marché national en manière de compétitivité afin de faire face à la conjecture
économique du pays.
Pour se faire l’institution s’est appuyée sur une étude menée par K.D.S 2
dans le cadre
d’un partage des connaissances avec la K.D.B 3, sous l’égide du Ministère des Finances.
Fort de l’étude consacrée au développement, Le F.N.I se mobilise autour de quatre (04) axes
stratégiques :
1. Le renforcement de l’évaluation des prêts,
2. L’introduction du système de gestion du risque à divers niveaux,
3. La diversification des ressources de financement,
4. Le renforcement du personnel et de la formation.
La refonte du système d’information est l’une des priorités de ce développement visant
l’intégration de tous les systèmes de gestions en cohérence avec la stratégie entreprise conçue
au préalable.
La refonte a permis au F.N.I de réviser le système de procédures internes, la définition
d’une organisation interne cible et de sa mise en place progressive
(Accompagnement : Conduite de changements). [7]
1.2.2. Organigramme général :
La structure du F.N.I repose sur une organisation de type hiérarchique et fonctionnelle
(staff & line).
Ce type d’organisation permet de joindre à la fois les avantages du model hiérarchique
et du model fonctionnel confèrent ainsi à l’institution une grande stabilité dans la structure,
et garantir une certaine unité du pouvoir décisionnel.
L’organigramme du F.N.I est conçu en structures organiques adoptant une architecture
pyramidale,
Voire : Fig.1. Organigramme général du F.N.I. [11]

1. P.S.M : Plan Stratégique de Modernisation.

2. K.D.S : (Korea Institute for Développement Strategy) Institut Coréen de Développement Stratégique.
3. K.D.B: Korea Development Bank.

7
 Conseil de Direction

Comité de Direction

Direction Générale

Secrétariat Général

Département de l’Audit Département des Affaires

Interne Juridiques et du
Contentieux

D.S.I : Direction D.R.H.L : Direction D.F.C : Direction D.E.O.I : Direction D.E.D : Direction D.E.P : Direction
des Systèmes des Ressources des Finances et de la des Engagements des Etudes d’Equipement
d’Information Humaines et de la comptabilité et des Operations et Développement Public
Logistique Internationales

D.R.O : Direction Régionale D.R.Alger : Direction D.R.C : Direction Régionale D.R.A : Direction Régionale
d’Oran Régionale d’Alger de Constantine d’Annaba

Fig.1 : Organigramme général du F.N.I. [11]

8
1.2.3. Orientations stratégiques du fonds :
Le F.N.I a pour objectifs :
 Financement du développement de l'économie nationale,
 Promotion du financement bancaire local des grands projets,
Le F.N.I accompagne :
 Les projets de toute nature décidés par l’état,
 Les projets économiques du secteur public et/ou du secteur privé,
 Au financement d’équipements publics par le marché, en substitution au budget
de l'état.
Le F.N.I intervient par :
 Des prises de participations,
 Des financements directs,
 L'octroi de garanties. [27]

1.2.4. Les Activités principales du fonds :

Financement sur ressources propres notamment par :
 Des prés directs à long terme,
 Des prises de participation dans le capital des entreprises économiques,
 L’octroi de garantie,
 Financement sur ressources du trésor,
 Gestion financière des programmes d’équipements publics. [27]
Les partenaires du F.N.I sont : Algerian Quatari Steel, Omnium Telecom Algérie
(O.T.A-Djezzy), AXA Assurance Algérie-Dommage, Saidal North Manufacturing,
Tala Assurance, SIAHA, Groupe COSIDER, Renault Algérie Production, Banque Algérienne
de Commerce Extérieur. [11]

9
1.3. Présentation de la structure informatique :
La structure informatique actuelle est issue de la révision de l’organigramme de l’ancienne
B.A.D présentée de la manière suivante :
1.3.1. Organisation de l’activité informatique :
L’informatique de notre institution obéie à un modèle complètement centralisé
et partiellement externalisé doté d’une architecture organique pyramidale
type Hiérarchique et Fonctionnel (en adéquation avec l’architecture globale
de l’institution).
L’organisation informatique se déploie à travers deux (02) deux niveaux :
 Le niveau central :
Par une direction centrale de l’informatique :
D.S.I : Direction des systèmes d’information : Auparavant D.O.I (Direction
de l’Organisation et de l’Informatique) structurée en trois (03) départements
informatiques centraux et de quarte (04) services informatiques régionaux.
La Figure ci-dessous illustre clairement l’architecture organisationnelle de la centrale.

D.O.I
Directeur Central

D.E.M.I D.E.R.I
Chef de Département Chef de Département

D.ORG
Chef de Département

Fig.2 : Organisation interne de la D.O.I.

D.ORG : Département de l’Organisation,
D.E.R.I : Département des Etudes et des Réalisations Informatiques,
D.E.M.I : Département d’Exploitation et de Maintenance Informatique.
Le département D.E.M.I comprend à son tour deux autres services :
Service d’exploitation du siège Alger,
Service d’exploitation du siège implémenté à Birkhadem.

10
  Le niveau réseau régional :
La fonction informatique est représentée par :
Un service informatique pour chaque direction régionale rattaché directement
au directeur gestionnaire de structure sur le plan administratif soutenu et supporté
fonctionnellement par une relation métier (sur le plan technique) avec la centrale D.S.I.
Il est à noter que le service est dépourvue de sous structures internes
(organisation plate).
Le service assure de manière complète toutes les activités et les spécialités
informatiques déclinées au niveau régional.
1.3.2. Les principales missions de la D.O.I :
Dans le respect de la législation et la réglementation en vigueur et des statuts de la banque
et dans le cadre de :
 La politique générale arrêté par le conseil de la direction de la banque,
 Des orientations de la direction générale,
Mettre en œuvre la politique d'organisation de la Banque et notamment :
 Participer à l'élaboration des plans d'organisation de la Banque,
 Participer à la définition et la mise en place du système d'information de la Banque,
 Assister les structures dans la prise en charge des problèmes d'organisation
et des procédures.
Gérer les moyens informatiques de la banque et notamment :
 Elaborer et mettre en œuvre des plans directeurs informatiques,
 Exploiter et maintenir les équipements informatiques et annexes,
 Exploiter et maintenir les applications et données informatiques,
 Réaliser les études et développements informatiques,
 Assister en permanence les structures à l'utilisation des outils informatiques. [3]
1.3.3. Les attributions du département organisation (D.O) :
Se déclinant par :
 L’élaboration des schémas d’organisation en collaboration avec les structures,
 Participation à l’élaboration des procédures de la banque,
 La conception et à la mise en œuvre du système d’information de la banque. [3]

11
1.3.4. Les attributions du département études et réalisations informatiques (D.E.R.I) :
Se déclinant par :
Piloter, suivre et participer aux études de développements informatiques notamment :
 La réalisation d’études informatiques,
 La conception et la réalisation des applications,
 La mise en exploitation des applications développées,
 La formation des utilisateurs aux nouvelles applications,
 La réalisation des dossiers techniques d’exploitation,
 La maintenance des applications.
Piloter et suivre les prestations informatiques externes :
 Elaborer et proposer les procédures internes de son département,
 Participer à élaborer les procédures de la banque,
 Participer à l’évolution des produits informatiques de la banque,
 Participer à l’élaboration des plans informatiques de la banque. [3]
1.3.5. Les attributions du département exploitation et maintenance informatique (D.E.M.I) :
Se déclinant par :
 La gestion du parc informatique et le suivi des inventaires,
 L’étude des besoins et l’élaboration des prescriptions techniques pour l’acquisition
des équipements informatiques,
 Assurer l’exploitation et la maintenance des moyens informatiques
de la banque. [3]
1.3.6. Les principales missions et attributions des services informatiques (D.R) :
Selon l’organisation en vigueur, le service informatique est chargé de :
 La mise en place, l’exploitation, la maintenance des équipements informatiques
et la gestion du parc informatique de la direction régionale et des agences rattachées,
 La mise en exploitation et le suivi des logiciels informatiques,
 La gestion de la sécurité des données informatiques,
 L’assistance et la formation des utilisateurs,
 Participer aux études et développements informatiques sous la conduite de la D.O.I,
 La transmission des dossiers et supports informatiques aux structures du siège. [4]
A noter que l’organisation de travail actuelle se base sur le manuel de procédures interne
de l’institution élaboré dans le contexte de la B.A.D.

12
L’ensemble de l’activité informatique est en plein restructuration par rapport aux nouvelles
missions qui lui sont dévolus. Un nouvel organigramme a été conçu est mise en place suite
à la mutation de l’ancienne direction vers une structure type D.S.I (Direction des Systèmes
d’Information) organisée et centrée uniquement sur deux départements de base à savoir :
 D.S.I/D.I.S : Département Infrastructure et Support.
 D.S.I/D.E.D : Département Etudes et Développements.
Le département D.I.S comprend (05) services :
 Le service Datacenter,
 Le service infrastructures techniques,
 Le service réseau,
 Le service Helpdesk,
 Le service maintenance I.T.
L’organisation interne concernant le D.E.D, fera l’objet d’aménagement en services
(en cours de conception). [5]
Note : La nouvelle organisation (D.S.I), conserve la même structure que l’ancienne D.O.I.
Les missions et les objectifs assignés à chaque structure sont en cours d’élaboration par la D.S.I.
1.4. Présentation du projet :
1.4.1. Contexte du projet :
S’inscrit dans le cadre du plan de modernisation de notre institution baptisé (P.S.M)
lancé en 2011 à l’issu de la restructuration de notre institution en fonds d’investissement
(F.N.I) soutenue par le cadre d’étude (K.D.S) élaborée dans le cadre de la mission inter
ministérielle de partage de connaissances avec la K.D.B.
Sous l’égide du ministère des finances ce plan de modernisation vise essentiellement
à accroitre les capacités du fonds en général et particulièrement améliorer qualitativement
le rendement de l’activité informatique ainsi qu’à son efficience du fait qu’elle soit au cœur
du développement. Ce plan conduit vers l’instauration d’un long processus de réforme mené
selon une démarche progressive (Step by Step) et qui s’opère aussi bien selon les conditions
actuelles et les moyens dont dispose notre institution. [8]
Actuellement l’activité informatique de manière générale est en pleine réorganisation
à la lumière des nouvelles impératives de gestions et des évolutions technologiques.
De par la technique le projet d’études met l’accent sur plusieurs volets jugés pertinents
et en parfaite synergie notamment :
 L’organisation de l’activité informatique et ces structures.
 La gestion de l’infrastructure informatique.

13
1.4.2. Les objectifs escomptés dans le cadre du mémoire :
Comme cela est le cas dans plusieurs entreprises de par le monde et en Algérie, ce projet
est né de plusieurs réflexions liées aux différents contextes de travail de notre métier. Citant
celui largement partagé, traduit par l'augmentation et l'intensification des tâches d'exploitation
des systèmes informatiques et des réseaux ainsi qu’aux responsabilités attenantes et ce,
la plupart du temps à moyens humains constants.
Son objectif est donc de proposer aux D.S.I nouveaux entrants, ou déjà en poste, de mieux
identifier les processus essentiels nécessaires pour le soutient et la fourniture de services
informatiques, sécuriser les serveurs et les réseaux, documenter les actions informatiques,
communiquer, gérer le temps, respecter certaines contraintes juridiques, former et se former.
Il permettra sans nul doute d'aider à la structuration du travail dans nos activités, voire
à améliorer l'organisation des services informatiques de l’entreprise et en définitif la qualité
de service.
Ce mémoire n’est nullement un livre de recettes à appliquer à la lettre non plus un guide
administratif ou technique qui va dicter aux D.S.I et à des organisations apprendre à travailler.
Il ne s’agit pas d’atteindre une conformité méthodologique afin de garantir la décision. [12]
Il s’agirait plutôt de s’initier à des approches plus pragmatiques dans l’élaboration
de méthodologies organisationnelles éprouvées et inspirées du monde industriel, des normes
et du retour d’expérience sur le terrain en matière de soutient de service et de fourniture
de service, de la sécurité informatique et ce conformément aux réglementations en vigueur
dans l’entreprise en particulier sans pour autant constituer un frein rigide d’adaptation.
L’objectif final étant d’impacter l’entreprise et sa performance dans son ensemble,
Plus concis encore et de manière plus formelle, une batterie d’objectifs précis a été élaboré
au départ du projet principalement représentés par les points suivants :
 Formaliser et structurer l’activité informatique en implémentant les processus I.T.I.L®,
 Rationnaliser l’utilisation des ressources disponibles : intégrer la maitrise des couts,
 Augmenter l’efficacité opérationnelle de la structure informatique,
 Catalyser les demandes de services et anticiper la prise de décision,
 Centraliser les décisions stratégiques, et décentraliser localement la gestion,
 Faire évoluer le niveau de l’expertise technique et managérial de l’équipe,
 Conquérir de la crédibilité vis-à-vis de la direction qu’en a l’action informatique,
 Renforcer l’agilité de la structure informatique en tant qu’entité stratégique.

14
1.4.3. La problématique à résoudre :
La problématique à résoudre s’articule autour des préoccupations majeures suivantes :
 Une problématique d’ordre économique : les ressources I.T sont stratégiques pour
notre institution dont il est jugé obligatoire d’optimiser leurs couts d’exploitation,
 Une problématique d’ordre de gestion : le grand nombre de machines, la répartition
géographique, l’étendu de l’infrastructure, les différents acteurs du domaine
informatique, la formalisation de l’activité informatique, la rationalisation
de la gestion technique,
 Une problématique de gouvernance et de pilotage : l’alignement stratégique
du S.I avec le métier et les fonctions de support.
1.4.4. La solution proposée :
Implémentation d’un système d’information centralisé destiné au soutient et à la fourniture
de services informatiques en se réfèrent au guide des bonnes pratiques I.T.I.L v3 ®.
Ce qui revient à identifier, adapter et implémenter les processus prioritaires du noyau I.T.I.L®
à savoir au niveau du :
 Support de service informatique.
 Fourniture de service informatique.
Sur le plan pratique la solution se matérialise par :
 L’implémentation d’un système informatique comme outils de travail unique
et indispensable : solution intégrée open source,
 L’impact sur l’organisation de travail actuelle : réorganisation de l’activité
informatique (structures, procédures).

1.5. Conclusion :
L’efficacité, la rentabilité, l’agilité de la structure informatique constitue un élément
stratégique du processus de développement global de notre institution (Orientations
particulières de l’étude menée sous l’égide de la K.D.B).Tous les efforts
et les accomplissements doivent être capitalisés, formalisés, et valorisée dans une démarche
de qualité visant à réformer et à reconstruire progressivement l’activité informatique
du sommet à la base d’où l’essence même de ce projet qui trouve tout son compte.

15
 Chapitre 02 :
Etat de l’Art : La gestion classique du parc informatique

16
2.1. Introduction :
L’évolution rapide de la technologie notamment des outils et des équipements confère
aux ressources informatiques divers applications conjugué au fait de l’étendu organisationnel
d’une entreprise et de sa répartition géographique conduit à la nécessité de disposer
d’une gestion.
2.2. Les fondements de la gestion de parc informatique :
2.2.1. La raison d’être de la gestion de parc :
Dans le passé la gestion du parc informatique relève du directeur des finances
de l’entreprise perçu comme une opération simple à réaliser dans une configuration ou régné
en maitre absolu les gros serveurs d’application et de communication.
Auparavant la gestion de parc s’est affinée dans un environnement complètement centralisé.
Mais avec l’avènement de la micro-informatique et de l’utilisation des réseaux favorisant
la répartition géographique et la décentralisation des activités, la gestion parviennent
par devenir complexe ce qui provoque son transfert au gestionnaire du service informatique.
De cela a été conclu que plus l’organisation et grande plus les instances décisionnelles
sont décentralisées. [18]
Entre le management et l’informatique pure, voire l’émergence d’une nouvelle fonction
dans les services informatiques qui est le gestionnaire de parc.
La gestion du parc permet d’avoir une planification optimale des ressources ce qui induit
à une réduction sensible des couts (générer des économies indirectes).
Fort de cette thèse toute organisation informatique est perçue comme un centre de couts
produisant divers services.
La gestion du parc informatique se divise en deux sous gestions :
 Une gestion administrative.
 Une gestion technique.
Une gestion de parc maîtrisée permet :
 Le suivie du cycle de vie des équipements (localisation, valorisation, évolution),
 La gestion efficiente de l'utilisation des ressources par service ou par site,
 La facilitation des opérations de migration de parc en anticipant les évolutions
matérielles et logicielles,
 Optimisation du suivi des acquisitions (de la demande d'achat à la facture, en passant
par la commande, le bon de livraison...),

17
  Budgétisation des investissements à réaliser, calcule du coût total de possession
(T.C.O), et estimation des dépenses à venir,
 Gestion au plus juste des immobilisations du parc.
2.2.2. Les processus de base de la gestion du parc :
Constitué aux tours de :
 La gestion des dépenses et des investissements,
 La planification de l’évolution,
 Le suivi de l’exploitation des composants.
Ces gestions sont basées sur l’action de la connaissance détaillée des actifs et des composants
d’un parc représentée et matérialisée par un inventaire complet.
Les trois questions auxquelles doit répondre une réalisation et un suivi de l’inventaire sont :
 Quoi : Quels sont les biens qui sont susceptibles d’être repris en inventaire.
 Quand : Le meilleur moment pour effectuer l’inventaire.
 Comment : La façon dont l’inventaire sera réalisé.
2.2.3. Le cycle de vie d’un bien informatique :
Le cycle commence par la demande du bien (besoin) et se termine par une session (Fig.3).

Acquisition
Soumission
Choix de la soumision
Contrat
Reception
Localisation

Planification
Besoin Utilisation
Analyse Preparation,Attribution,Support,
Solution Migtation,Mise àjour,Deplacement
Budgetisation

Session
Vente
Donation
Recyclage
Destruction

Fig.3. Cycle de vie d’un bien informatique.

18
2.2.4. La structure des couts :
Le cout que peut générer un équipement informatique dès l’acquisition jusqu’à sa réforme
définitive obéie à la structure suivante :
 Les couts d’acquisition.
 Les coûts d’administration.
 Les coûts d’assistance.
 Les coûts indirects.
Ces coûts peuvent se détailler de la manière suivante :
2.2.4.1. Les coûts d’acquisition :
 Prix d’acquisition du matériel (Serveurs, U.C, Ecran, Onduleur, Imprimante, etc.).
 Prix d’acquisition du consommables et accessoires (cartes wifi, switches,…etc.).
 Prix d’acquisition des licences logiciels.
 Dépenses de mise à disposition (livraison, installation, montage,..etc.).
 Coûts de câblage (infrastructures et réseaux).
 Frais divers associés.
2.2.4.2. Les coûts d’administration :
Les coûts liés à l’acte d’achat ce qui correspond à des :
 Procédures d’appel d’offre ou contrats : rédaction, publication.
 Négociations avec les partenaires.
Les coûts liés à la relation fournisseur :
 Expression du besoin : bon de commande,
 Rédaction et émission du bon de commande interne,
 Suivi de la livraison,
 Contrôle de conformité : livraison / bon de commande,
 Enregistrement de la facture,
 Paiement de la facture,
 Enregistrement en immobilisations.
Les coûts liés à l'action administrative :
 Calcul et édition des dotations et amortissements,
 Calcul et édition des plus ou moins-values de cession,
 Fabrication de la déclaration aux assurances,
 Enregistrement des mouvements de parc dans les applications,
 Réalisation des inventaires,

19
  Suivi des contrats répétitifs :
Contrat de licences logicielles, de location, de maintenance, d’assistance,
de sous-traitance.
Les coûts de sortie :
 Frais de stockage des matériels à reformer,
 Inventaire des matériels à reformer,
 Organisations physique de la réforme,
 Procédure de sessions des actifs.
2.2.4.3. Les coûts d’assistance :
Correspond aux :
 Contrats de maintenance,
 Helpdesk,
 Dépannage et support,
 Formation.
2.2.4.4. Les coûts indirects :
 Auto-formation,
 Auto-dépannage ou tentative d’auto-dépannage,
 Formation informelle (aide du voisin de bureau ou d’un technicien de passage),
 Tentatives plus ou moins réussis de développement d’applications personnelles,
 Tâches d’exploitation du poste de travail.

20
2.3. La gestion administrative du parc :
L’acte fondateur de la gestion administrative du parc est l’inventaire initial. Il suppose
la définition et la mise en œuvre d’une base administrative. Il convient ensuite de maîtriser
les différents mouvements (ajout, modification, mouvement, sortie) de façon à disposer
d’un inventaire permanent à jour.
2.3.1. Pré requis :
Un inventaire de parc s’il n’est pas accompagné en parallèle d’un outil de gestion est inutile.
Il convient donc de se poser la question de l’application informatique qui va recueillir
les résultats de l’inventaire ainsi que les mises à jour ultérieure résultants des mouvements
de matériels (ajouts, modifications, retraits…etc.). Avant tout inventaire, il faut donc
assurer que soit opérationnel le fichier ou le S.G.B.D de gestion administrative du parc.
Un autre pré requis consiste à définir une nomenclature raisonnée des matériels et logiciels :
 Le nombre d’ordinateurs de bureau,
 Le nombre d’ordinateurs portables,
 Le nombre de serveurs,
 Le nombre d’imprimantes matricielles,
 Le nombre d’imprimantes Laser,
 Le nombre de licences serveurs ou poste station.
Ce pré requis requiert les exigences suivantes :
 L’existence d’une codification (pour tous types de matériel à inventorier),
 Un classement par grande nature de tous ces types (voir nomenclature).
2.3.2. Réaliser l’inventaire initial :
Si les prés requis ont été respectés, la situation devienne la suivante :
 Une nomenclature aussi exhaustive que possible des matériels en parc a été réalisée,
 Des procédures verrouillées de mise à jour,
 Les fiches d’inventaires sont clairement définies,
 L’application de gestion administrative de parc est opérationnelle,
Le but de l’inventaire initial consiste à visiter tous les locaux de l’entreprise (bureaux, salles,
ateliers,…) afin de recenser tous le matériel. Chaque matériel devra d’abord être identifié dans
la nomenclature, une étiquette d’immatriculation apposée et un relevé de toutes
les données requises sur la fiche d’inventaire.
Un inventaire doit être réalisé sur une période courte. Si un inventaire dure plusieurs mois,
il y a de fortes chances que les données recueillies en premier soient partiellement inexactes

21
en fin de parcours. L’inventaire doit ensuite être suivi de la mise à jour de la base
administrative réalisée par saisie directe des données collectées ou par injection de fichiers.
Dans ce dernier cas il faudra que les fichiers aient étés préparés à partir des données
recueillies par les équipes chargées de l’inventaire.
Note :

L’inventaire des locaux sera facilité si vous parvenez à obtenir les plans particulièrement dans des locaux
anciens. L’opération d’inventaire doit être organisée et planifiée, comme informer à l’avance la direction.
2.3.3. La base administrative :
De la qualité du travail d’analyse et de préparation de l’inventaire (outils, procédure, logiciel
de gestion de parc) résultera une bonne gestion administrative de l’entreprise
dans la perspective.
Exemple d’une fiche d’inventaire basique voire tableau suivant :
Marque : Modèle :
Type : Caractéristiques : H.D, R.A.M,
N° de série : Logiciels : noms, version, n° de licence
Immatriculation : Utilisateur :
Service : Date de mise en service :
Localisation : Prix d’achat :
Tableau 1 : Fiche d’inventaire administratif.
Concernant le nombre de données, il n’y a pas de limite supérieure.
Pour ce qui est du matériel, notamment le poste de travail, gérer souvent quelques
caractéristiques du micro-ordinateur : taille du disque dur, processeur, mémoire vive…etc.
Concernant l’affectation, souvent gérer : l’utilisateur, le n° de série, date de dernière
affectation.
Concernant les données financières, à apprécier souvent de connaître : la valeur immobilisée,
la valeur nette comptable (V.N.C), la date d’immobilisation,
Enfin, certains veulent connaître les principaux logiciels utilisés : type, version, n° de licence.
Néanmoins il faut faire preuve de beaucoup de discernement dans le choix des données
à gérer. En effet toute gestion de données à un coût d’acquisition et de mise à jour.
Savoir la difficulté que représente la simple tenue des données de base (une petite dizaine),
contrains à être dubitatif sur les fiches d’inventaires qui prétendent gérer des dizaines
de données.

22
2.3.4. Détail de la configuration :
Deux écoles s’opposent. Les tenants du détail souhaitent absolument gérer de façon
individuelle l’écran, l’unité centrale voire le clavier. Les partisans de la vision synthétique
préfèrent gérer des configurations type. En cas de parc particulièrement hétérogène,
la première position peut se défendre mais dès que le parc est homogène la seconde
alternative est préférable.
2.3.5. L’immatriculation :
Pour identifier physiquement les matériels de manière déterministe le recours aux
numéros de séries pose deux problèmes à gérer :
 Souvent très longs, difficile à contrôler et à vérifier,
 Parfois difficilement accessibles pour certain type de matériels.
En général en cas de contrat de maintenance pour une machine donnée, ou pour une mise
en jeux de garantie fournisseur, l’information numéro de série trouve tous l’intérêt.
L’immatriculation doit être dument contrôlée avec le fournisseur ou le fabricant
de l’équipement en question.
L’immatriculation est une excellente formule. Elle consiste à apposer une étiquette portant
un numéro séquentiel sur la face avant du matériel. Ce numéro doit être unique dans
l’entreprise. Il est également utile sur l’étiquette d’accompagner le numéro
de sa transcription inventaire en code barre (relecture par douchette et exploité par un logiciel
approprié).
2.3.6. Les mouvements de matériels :
2.3.6.1. Les entrées :
Représentent les trois étapes à savoir :
 La livraison.
 L’installation.
 Entrée comptable avec la réception de la facture et du bon de livraison.
Chaque étape alimente la fiche d’inventaire en information,
En principe, il est préférable qu’un matériel soit identifié dans la base administrative
dès son entrée physique dans l’entreprise, c’est à dire dès sa livraison. Cela est possible
si les livraisons sont effectuées en un point central ou sera initialisée l’entrée dans la base
administrative. Si les livraisons sont décentralisées, il faut attendre la remontée en un point
central des bons de livraison. C’est en général le service comptabilité qui les récupère.

23
Il appartient au responsable informatique de nouer de solides relations avec ce service pour
recueillir les informations nécessaires à la saisie.
2.3.6.2. Les déplacements de matériels :
Chaque déplacement temporaire ou définitif de matériel doit être signifié au gestionnaire
de parc spécialement s’il est connecté au réseau d’entreprise,
Plus en détail en cas de :
1- Poste de travail autonome : Le gestionnaire de parc n’est pas informé d’un déménagement
décidé localement par l’utilisateur de l’équipement ce qui rend l’actualisation de la base
administrative impossible. D’une autre part le suivi de l’opération de déménagement
est effectué par les services des moyens généraux. Ils supposent que soient consignées
sur des plans ou des documents de déménagements ou d’inventaire la position initiale
et la position finale du poste de travail. Pour maintenir la base administrative à jour,
le responsable de la gestion du parc devra être informé et disposé des documents nécessaires
pour réactualise la localisation des matériels déménagés.
2- Poste de travail configuré en réseau :
Si le poste contient des configurations spécifiques au fonctionnement
des applications réseau, ou de services réseau, il est impératif d’interdire toute initiative
personnelle de la part de l’utilisateur pour le déplacement car il s’agit
d’une opération sensible qui incombe au service technique spécialisé d’intervenir
et accompagner le déménagement afin que le poste soit de nouveau opérationnel dans
sa nouvelle localisation.
2.3.6.3. Les sorties :
La conception d’un système qui permet de décharger l’utilisateur du matériel affecté et dont
il n’a plus l’usage, cela suppose :
 L’organisation d’un lieu de stockage,
 La mise en place de procédures de réaffectation de matériel encore utilisable
ou de sortie (réforme) si le matériel n’a plus d’utilité pour l’entreprise.
De ce fait, il est impératif de :
 Faire sortir les matériels de la base administrative ;
 Recueillir les pièces nécessaires (P.V de sortie ou de réforme ou de destruction)
qui permettront aux services comptables d’expurger les matériels du fichier
des immobilisations.

24
2.3.7. Les mouvements des utilisateurs :
L'utilisateur final est la préoccupation majeure du service informatique
de par son caractère imprévisible et son comportement d’où le suivi de ses mouvements
et les procédures à concevoir et à mettre en place constituent un vrai défi pour la gestion.
2.3.7.1. L'arrivée des utilisateurs :
La première difficulté qui se pose est d'anticiper l'arrivée d'un nouvel utilisateur.
Au niveau du service informatique et afin d'être en mesure de préparer en temps utiles
tous les constituants de son futur poste de travail (éviter la rupture : planification)
dans de bonnes conditions, des informations nécessaires doivent être demandées aux services
de l'administration, car une action conjuguée devienne une opération plus qu’obligatoire.
2.3.7.2. Les changements de statut :
Autant il est courant de gérer les changements de statut des matériels gérés, autant
il est plutôt rare que les entreprises gèrent un statut pour leurs utilisateurs.
C'est pourtant souhaitable, dans la mesure où le statut permet d'optimiser la gestion
de la base dans les cas de longue maladie, congé maternité, départ, délégation ...
En effet, il est préférable de maintenir l'utilisateur dans la base de gestion du parc,
en modifiant simplement un champ statut paramétré au préalable.
2.3.7.3. Le départ des utilisateurs :
Au départ d'un utilisateur, sa suppression de la base est à éviter impérativement,
cela peut poser des problèmes d'analyse des événements passés
(garantir de la traçabilité).Pour ce faire , le changeant s’opère simplement au niveau du statut
de l’utilisateur en question.

2.3.8. Les bénéfices de la gestion administrative :

De manière simple et synthétique la gestion administrative du parc permet :
 Le contrôle efficient des budgets d’investissements,
 La diffusion de l’inventaire par direction et par service.

25
 2.4. La gestion technique du parc :
Le principal intérêt de la gestion technique d’un parc c’est de connaitre à tous instant le détail
des configurations matérielles et logicielles que dispose une machine y compris la relation
avec le réseau de l’entreprise, donc logiquement sa constitue un atout majeur
pour un tous technicien qui veut gérer efficacement l’ensemble des éléments de son parc.
Un autre point important qui explique l’indispensabilité de la gestion technique
c’est la relation avec la gestion des incidents, car chaque incident concerne de manière directe
un élément bien précis ce qui met en évidence de connaitre d’abord ces caractéristiques
techniques.
2.4.1. La base technique :
La base technique trouve tous son intérêt dans le cadre d’un parc informatique mise en réseau.
La conception d’une base technique comprend trois étapes :
 La définition du contenu technique,
 La définition des procédures de mise à jour,
 L’inventaire technique de départ.
2.4.1.1. Fiche d’inventaire dynamique :
Correspond à une fiche descriptive structurée comportant :
 Les données techniques du matériel,
 Les données techniques des logiciels standards et spécifiques,
 Les données relatives aux connexions.
Fiche d’inventaire dynamique simplifiée (voir tableau ci-après) :
Données hard Données soft
Marque Logiciels standard
N° de série N° d’immatriculation
………… ………
Données utilisateur Gestion
Nom bureau
Prénom Adresse
Données réseau ………
Carte communication ………
Logiciel réseau ………
Code serveur ………
Tableau 2 : Fiche d’inventaire dynamique.

26
2.4.1.2. Les procédures de mise à jour :
Les mises à jour sont les résultats des mouvements opérés sur le parc informatique :
Réaffectation d’équipements, déménagement, connexion, déconnexion,…etc.
Logiquement les informations comportant ces mises à jour sont détenues exclusivement
par les techniciens responsables de l’opération et du cout sont chargés de mettre à jours
la base dynamique.
Le cas d’utilisation d’une technique d’inventaire automatique ne dispense pas les techniciens
de prendre manuellement certaines informations : n° série, n° immatriculation,
n° platine,…etc.
2.4.1.3. Les configurations type :
Afin d’avoir une base dynamique maitrisée (non complexe à gérer).
Il existe une approche qui consiste à limiter la variété des informations émanâtes du matériel
hétérogène.
Cette approche consiste à définir des configurations techniques type tant au plan matériel,
que logiciel.
2.4.1.4. Le bouclage avec la gestion administrative :
Le bouclage est assuré par la communication entre la base technique et la base administrative,
Dans le cas d’un parc de faible taille, il est envisageable de créer une seule base.
Cependant si le parc devient important , la séparation des bases constitue
une recommandation perçue comme un impératif afin de préserver la cohérence
des informations fournis,
Il est à noter que d’après l’expérience une base technique peut être plus à jours qu’une base
administrative.

2.5. Conclusion :
Disposer de la gestion de parc constitue un élément fondamental structurant
de l’activité informatique au sein d’une organisation.
Un gestionnaire informatique compètent est celui qui applique de manière correcte
et méthodique les principes de la gestion de parc après avoir suivi une formation
de qualification dispensée par un expert en la matière.

27
 Chapitre 03 :
Introduction à la méthode I.T.I.L® v3.0

28
3.1. Introduction :
Le chapitre sera entièrement consacré à la méthode I.T.I.L, vue sa consistance,
sont importance et son succès irréprochable dans le milieu professionnel traduit
par la rationalité de ses démarches.
A nos jours la majorité des D.S.I au niveau des plans directeurs informatiques, des stratégies
informatiques, des études de cahiers des charges et des audites informatiques adoptent
clairement et recommande le recours à la méthode I.T.I.L dans les projets
de restructuration, de réforme, de développement de la fonction informatique.
Cela n’est guère le fruit du hasard, mais il s’agit de l’adoption d’une vision rationnelle
complètement structurée en matière de gestion informatique afin d’atteindre les objectifs
d’affaires.
3.2. Présentation de la méthode I.T.I.L :
3.2.1. Historique :
Le gouvernement britannique a lancé une étude à la fin des années (80) afin de connaitre
les meilleurs pratiques dans le but de mettre en place la gestion des services I.T qui désormais
inconnue à cette époque. La gestion avait pour finalité d’améliorer l’efficacité des services
informatiques du secteur public.
3.2.2. La genèse :
Suite à la guerre des Malouines (Falklands) en 1983, l’U.K Navy avait des difficultés
à coordonner l’ensemble de ses services informatiques.
De là semble impératif de disposer d’une méthode qui permet d’atteindre la cohérence
de l’ensemble des structures et des fonctions informatiques à l’échelle national.
Le projet a été lancé pour devenir par la suite la méthode I.T.I.L. [19]
3.2.3. L’évolution :
La compagnie I.B.M avait proposé au gouvernement britannique l’externalisation de tous
les services informatiques publics. Après évaluation et estimation du cout de ce projet et suite
à la complexité rencontrée et pour des raisons rationnelles, I.B.M décide d’abandonner
le projet, la mission a été confiée au C.C.T.A (Central Computer & Télécommunication
Agency) par le gouvernement en 1986, puis, a été reprise par l’O.G.C (Office
of Gouvernement Commerce : L’organisme britannique propriétaire d’I.T.I.L qui en assume
la promotion au niveau mondial) . Après plusieurs années de travail, et avec l’aide
de nombreux professionnels de l’informatique (consultants spécialisés, experts indépendants,
formateurs), le résultat de l’étude débouche sur une panoplie de documents inspirant
à une vraie approche orientée vers le support des utilisateurs (organisations d’affaire).

29
Ce cumule d’expérience inestimable a constitué une bibliothèque originale allant jusqu’à
(40) livres connu comme la première version d’I.T.I.L.
Au fil du temps plusieurs versions ont vu le jour à la lumière des avancés et des expériences
nouvelles dans le domaine I.T. La deuxième version a permis de réduire considérablement
l’ancien volume vers (10) livres seulement. La dernière version (v.3) comporte seulement
(05) livres avec les améliorations. [19]
3.2.4. Les fondements de la méthode I.T.I.L :
L’acronyme d’I.T.I.L veut dire : « Information Technology Infrastructure Library » bibliothèque
d’infrastructures des technologies d’information.
Ensemble de livres ou sont structurés les pratiques, procédures, méthodes qui permettent
de gérer un système d’information, le référentiel I.T.I.L® est perçue comme un recueil
de bonnes pratiques, à noter que I.T.I.L® n’est pas :
 Une méthode : mais utilise plusieurs.
 Un langage : mais définit un.
 Une norme.
Une fois le référentiel est mis en place dans une administration, ou dans une entreprise
les informaticiens devront utiliser le même vocabulaire et les mêmes processus
et ce indépendamment de la nature du service informatique.
Le référentiel I.T.I.L® a été adopté par plusieurs sociétés I.T de renom dans le cadre de leurs
référentiel métier : I.B.M, British Télécom, Hewlett-Packard, Cap Gemini,…etc.
L'objectif est d’optimiser l’utilisation des ressources informatiques, ce qui implique :
 Adapter les services informatiques aux besoins actuels et futurs de l'entreprise
et de ses clients,
 Améliorer la qualité des services informatiques fournis en créant des cercles vertueux,
 Réduire les coûts de fourniture des services informatiques à court, moyen, long terme.
En complet I.T.I.L® constitue une approche méthodique, modulaire pour le support
et la fourniture d’un service informatique de qualité. [31]
3.2.5. Le positionnement de la méthode I.T.I.L dans la D.S.I :
En matière de référentiels informatiques permettant de structurer la fonction système
d’information au sein d’une entreprise, la méthodologie I.T.I.L® occupe une position centrale
à la définition des missions d’une D.S.I (au cœur du S.I). voir Fig.4
Les méthodologies plus utilisés (06 référentiels) sont groupés en (03) trois grandes catégories:
 Le développement du S.I (conception et développement des systèmes informatiques),

30
  La gestion du S.I (la gestion et l’administration des solutions informatiques),
 Le pilotage du S.I (le pilotage stratégique et opérationnel de l’infrastructure
informatique).

CMMI I.T.I.L COBIT

UML Réf. CIGREF ISO

Développement du S.I Gestion du S.I Pilotage du S.I

Fig. 4 : Les trois grandes missions du S.I. [24]
C.O.B.I.T: Control Objectives for Information and related Technology.
I.S.O: International Organization for Standardization.
U.M.L: Unified Modeling Language.
C.M.M.I: Capability Maturity Model Integration.
C.I.G.R.E.F : Club Informatique des Grandes Entreprises Françaises.
3.2.6. La culture organisationnelle :
Se définie principalement par les relations qui existent entre les différents collègues, la façon
dont les décisions sont prises, l’attitude des employés vis-à-vis de leurs travail, des supérieurs,
des clients,…etc. ce qui caractérise la culture sont les normes et les valeurs des membres
de l’organisation la rendant incontrôlable, et la seul possibilité de l’atteindre se limite
par le pouvoir de l’influencée en installant une autorité par le déploiement d’une politique
homogène, et une politique de soutien à l’égard du personnel.
La prestation du service informatique dépend de la culture organisationnelle de l’entreprise
et ce selon le type d’organisation. [23]
3.2.7. Les principes de base d’I.T.I.L :
 Considérer l’utilisateur comme un client,
 Positionner la D.S.I comme un prestataire de services,
 Optimiser la qualité et les coûts des services informatiques,
 Capitaliser sur les meilleures pratiques,
 Penser organisation et processus,
 Adopter une démarche structurée,
 Rationaliser les services de front office,
 Informatiser la gestion des services informatiques,
 Fournir un cadre standard pour gérer la sous-traitance. [30]

31
3.2.8. Les concepts fondateurs d’I.T.I.L :
La philosophie d’I.T.I.L® repose sur quatre (04) concepts fondamentaux :
1- La prise en compte de l’attente du client dans la mise en œuvre des services
informatiques que les anglophones appellent le Customer Focus.
2- Cycles de vie des projets informatiques doivent intégrer dès leur naissance
les différents aspects de la gestion des services informatiques.
3- La mise en place des processus interdépendants (assurer la qualité des services).
4- La mise en place d’une démarche qualité pour les services installés et d’une mesure
de cette qualité effectuée du point de vue des utilisateurs selon le modèle de Deming1.
I.T.I.L® offre un référentiel complet de bonnes pratiques (gestion I.T efficace et optimale).
3.2.9. I.T.I.L et l’approche orientée service :
Suivant le modèle économique mondial, c’est la valeur ajoutée qui fait vendre tous produit.
L’informatique ne fait pas l’exception à cette règle, tous ses produits sont conçus à base
de services fournis aux clients que ça soit une garantie sur le produit même (différence
de concept : produit et service), I.T.I.L® propose une approche complètement centrée
sur le service (voir la partie : La vision service informatique).
3.2.10. Le contenu d’I.T.I.L :
Le référentiel I.T.I.L® propose (03) niveaux de publication à savoir :
1- Le noyau de la gestion I.T.I.L des services : la structure des processus et des fonctions
représentés en (05) familles ou publications de base constituant le cycle de vie des services :
 Stratégie des services,
 Conception des services,
 Transition des services,
 Exploitation des services,
 Amélioration continue des services.
2- Conseils complémentaires sur la gestion I.T.I.L des services : proprement dit sur la mise
en œuvre flexible pour les secteurs industriels, type d’organisation, modèles opérationnels,
architectures technologiques,
3- Les services web de support I.T.I.L® : produits en ligne disponibles sur internet refermant
un glossaire, une étude de cas,…etc. [29]
1. La roue de Deming (de l'anglais Deming Wheel) est une illustration de la méthode de gestion
de la qualité dite P.D.C.A (plan-do-check-act), ou encore P.D.S.A (plan-do-study-act). Son nom vient
du statisticien William Edwards Deming.

32
 Fig. 5 : Cercle de qualité de Deming. [28]

Fig. 6 : Niveaux de publication I.T.I.L. [20]

L’organisation de la v 3.0 d’I.T.I.L® repose complètement sur le concept de cycle de vie
des services (découpage en phases).

Fig. 7 : Phases du cycle de vie I.T.I.L® v 3.0. [31]

3.2.11. Les apports avantageux d’I.T.I.L :
Au niveau de l’organisation informatique :
 Le développement de structures plus claires, efficaces orientées selon les objectifs
de l’entreprise.
 Dégager de la facilité dans la gestion des échanges et conférer un meilleur contrôle
de gestion.
 Définir un langage commun à tous les niveaux de l’organisation.

33
  Intégration des processus et des fonctions dans l’organisation informatique.
 Une justification business (création de valeur) de chaque processus et activité
informatique.
 Une structure de processus efficiente fournit un cadre pour l’externalisation efficace
d’éléments des services informatiques.
 Conseils sur les meilleures pratiques pour réaliser une gestion efficace et efficiente
des services informatiques dans le respect des engagements de niveaux de service.
 L’application des meilleures pratiques de l’I.T.I.L® encourage un changement culturel
vers la fourniture d’un service et l’introduction d’un système de gestion de la qualité
basée sur les normes de la série I.S.O 9000.
I.T.I.L® permet la mise en place d'un cadre de référence uniforme pour la communication
interne et la communication avec les fournisseurs ainsi que pour la normalisation
et l’identification des procédures au niveau de l’utilisateur ou le client :
 La fourniture de services informatiques est plus orientée vers le client et les accords
relatifs à la qualité des services améliorent les relations.
 Les services sont mieux décrits, dans le langage du client, avec plus de détails.
 La qualité et le coût des services sont mieux gérés.
 La communication avec l’organisation informatique améliorée (points de contacts).
3.2.12. Les nouveautés par rapport à la v.2.0 :
Les principales nouveautés sont les suivantes :
 Tous les processus de la v.2 sont dans la version 3.0,
 Nouveaux concepts (stratégie) et nouveaux processus,
 Meilleure cohérence de l’ensemble,
 Notion de modèle de processus pour certains processus.
3.2.13. Les bénéfices de la mise en œuvre de la v3.0 :
La version (03) d’I.T.I.L® se distingue par :
 Infrastructure informatique et services plus stables,
 Perception utilisateurs et clients améliorée,
 Meilleur temps de mise sur le marché,
 Organisations business plus compétitives.
Plus concis encore l’implémentation du noyau procure au niveau de chaque publication :
Stratégie des services (Service Strategy) :
 Aligner les stratégies d’affaires et informatique,

34
  Définir les objectifs et les politiques,
 Allouer les ressources et préciser les contraintes,
 Etablir un plan global et le piloter.
Conception des services (Service Design) :
 Concevoir les architectures et les normes, les processus informatiques, les outils
internes de gestion pour répondre efficacement à la demande et fournir les niveaux
de services convenus,
 Gérer les relations clients et fournisseurs.
Transition des services (Service Transition) :
 Elaborer et gérer les plans de transition, les risques et les critères d’acceptation, tester
et valider les solutions, déployer, capitaliser les connaissances.
Exploitation des services (Service Opération) :
 Appliquer les plans opérationnels, les procédures et modes opératoires au quotidien
pour fournir la qualité de service convenue, surveiller et générer des rapports.
Amélioration continue des services (Continual Service Improvement) :
 Produire des rapports, analyse du fonctionnement (solutions, processus, organisation).
 Définir, lancer et piloter les plans d’amélioration.
De façon synthétique l’amélioration continue se base sur les outils de gestion de la qualité.
La figure illustre aisément le fonctionnement continue des composants d’I.T.I.L®.
La structure des fonctions et des processus : voir Fig.8.

Fig.8 : Processus et fonctions I.T.I.L® v3.0. [31]

35
3.2.14. Problèmes potentiel d’I.T.I.L :
 Introduire la méthode I.T.I.L exige beaucoup de temps et d’efforts et nécessite
un changement de culture dans l’organisation. Une démarche trop ambitieuse peut
conduire à une certaine frustration étant donné que les objectifs ne sont jamais atteints.
 Si les structures de processus deviennent elles-mêmes des objectifs, cela peut nuire
à la qualité du service. Dans ce cas, les procédures deviennent des obstacles
bureaucratiques qu’il faut éviter quand cela est possible.
 Le manque de compréhension de ce que doivent offrir les processus,
de ce que sont les indicateurs de performance et de la façon de contrôler
les processus échoue toute amélioration projetée.
 L’amélioration de la fourniture et la réduction des couts n’est pas instantanée.
 Une mise en place réussie nécessite l’implication et l’engagement du personnel à tous
les niveaux de l’organisation. Le fait de réserver le développement des structures
de processus à un département spécialisé peut isoler ce dernier et donner
une orientation qui ne soit pas acceptée par les autres départements.
 Le manque d’investissement en outils de soutien, influe négativement
sur l’amélioration des services. Des ressources et du personnel supplémentaire
peuvent être nécessaires si l’organisation est déjà surchargée par les activités
quotidiennes de gestion des services informatiques.
Ces problèmes potentiels sont bien sûr surmontables. I.T.I.L® a été développée en raison
de ses avantages. De nombreuses suggestions de meilleures pratiques visent à éviter de tels
problèmes ou à les résoudre s’ils se présentent. [20]
3.3. Le référentiel I.T.I.L :
3.3.1. Terminologie et définitions :
Service :
« Un moyen d’apporter de la valeur aux clients en facilitant les résultats que les clients
doivent obtenir sans avoir à gérer directement les couts et les risques spécifiques
aux composants et aux prestations sous-jacentes ». [21]
« Un service est un moyen de délivrer de la valeur aux clients en facilitant la production
des résultats dans leurs activités sans qu’ils aient à se préoccuper des coûts et des risques
spécifiques au service qu’il leur est fourni. ». [21]
« Le service informatique est entendu comme une unité organisationnelle de l’entreprise
au même titre que le service comptabilité. ». [21]

36
« La seconde vision que l’on peut avoir d’un service informatique est davantage
liée au système d’information et au service rendu par ce système ». [21]
« Il s’agit dans ce cas d’une ressource dont on peut profiter en devenant client : messagerie,
bureautique et autres E.R.P. Ces services sont comparables aux autres prestations
de l’entreprise comme la climatisation, l’eau courante, l’électricité ou même le courrier». [21]
« Le mot service correspond à la prestation, l’aide ou l’assistance que l’utilisateur peut
attendre dans le sens (rendre service) ». [21]
A noter que le mot service possédé (03) sens à savoir :
 Service informatique au sens organisationnel (D.S.I),
 Service informatique au sens système d’information,
 Service informatique au sens prestations délivrées.
Gestion de service informatique :
« Ensemble d’aptitudes utilisés pour fournir de la valeur aux clients sous la forme
de service ». [20]
Fournisseur de services informatiques (I.T Service Provider) :
« Un fournisseur de services informatiques est une entité responsable de la mise à disposition
d’un ensemble de services informatiques ». [20]
Fournisseur externe (3rd party supplier) :
« Un fournisseur externe est une entité tierce (externe) responsable de la fourniture
ou de la sous-traitance de certains éléments des services fournis ». [20]
Utilisateur (User) :
« Un client est une personne ou un rôle bénéficiaire final du service, comptable des résultats
de ses collaborateurs, utilisateurs des services informatiques ». [20]
Propriétaire de service (Service Owner) :
Un propriétaire de service est un rôle qui effectue le suivi de bout en bout le service :
 Tout au long de son cycle de vie et dans tous les processus informatiques utilisés,
 De bout en bout sur l’ensemble des technologies utilisées. [20]
Propriétaire de processus (Process Owner) :
Un propriétaire de processus est un rôle ayant une double responsabilité (Chargé de):
 La conception, la mise en œuvre du processus et garant des résultats du processus,
 La fourniture des ressources suffisantes pour le bon fonctionnement du processus. [20]
Gestionnaire de processus (Process Manager) : « Un gestionnaire de processus est un rôle
qui coordonne et supervise les activités du processus et les résultats au quotidien ». [20]

37
3.3.2. L’évolution de la vision en matiere de gestion informatique :
3.3.2.1. La vision depassée :
L’organisation informatique n’a pas évoluée dans sa conception de base
dès les années (70) jusqu’aux années (90) où l’informatique garde toujours le focus
sur les technologies fournis par le baie d’applications.
Les interventions effectuées sur ces applications suite aux différents dysfonctionnements
s’opèrent par l’instauration de ce qu’ont appel des services Hot line afin de répondre
aux appels tous asymutes des utilisateurs actifs.
La disponibilité des applications en service est tributaire des pannes affectant
le fonctionnement des technologies mise en place.
Le premier constat le plus pertinent à faire c’est que cette vision n’offre aucune considération
à la formulation de la qualité de service générée or plus l’informaticien consentis des efforts
importants pour seul le maintien du fonctionnement de l’infrastructure technique à condition
que ce dernier fait l’objet d’une motivation.
La notion du best effort existe dans plusieurs organisations selon cette vision.
Le second constat à faire c’est que d’après cette conception les utilisateurs dans leurs
démarches deviennent fortement dépendants des informaticiens i.e. : atteindre les objectifs
escomptés est conditionné par le rendement de l’informaticien en charge ce qui renforce chez
ce dernier un certain cynodrome d’indispensabilité.
Le dernier constat à faire c’est que cette organisation ne permet pas de répondre aux objectifs
multiples ni même de les atteindre dans un environnement purement concurrentiel
ce qui se répercute indirectement sur l’informatique de l’entreprise (impact négatif).
Donc cette vision est complètement révolue ce qui mène à l’évidence la nécessité d’arpenter
une approche complètement structurée dans le cadre d’une organisation d’affaire. [20]

Fig.9 : La vision classique de la gestion informatique. [20]

38
3.3.2.2. La vision services informatiques :
Cette vision s’incarne par l’accompagnement des technologies et des applications fournis
par un service complet. Donc une orientation de l’organisation informatique vers
l’accompagnement des services d’affaires par des services technique complets.
L’approche consiste à octroyer des garanties concrètes pour les utilisateurs stipulant selon
le besoin échu, l’assurance de la disponibilité des solutions techniques, des infrastructures
et autres applications et ce, à courts terme, à moyen terme, et à long terme.
Plus précisément cette approche se concentre principalement sur les besoins et les contraintes
de l’organisation d’affaire.
L’organisation informatique se doit accompagner de bout en bout les processus d’affaires afin
d’accroitre, d’accélérer et de renforcer les résultats (ex : accroissement des parts de marchés).
L’accompagnement se fait à travers les technologies utilisées dans le cadre d’une gestion
informatique complète I.T.S.M (Information Technology Service Management).
Notant que l’approche I.T.I.L ne règlemente pas le type d’organisation, mais de décrire
les relations entre les activités dans les processus fournissant ainsi un cadre d’échange
et d’apprentissage basés sur des organisations dynamiques ce qui le qualifié comme
le meilleur model conçu à ce jour destiné à la gestion des services informatiques. [20]

Fig.10 : La vision service informatique. [20]

3.3.3. Les fournisseurs externes :
L’organisation informatique est incapable économiquement de disposer des ressources
internes, et des compétences nécessaires pour faire marcher les différentes technologies
devenant plus complexes et plus interconnectés entre elles. Donc le recours à l’expertise
externe par le baie de la sous-traitance des fournisseurs externes les plus qualifiés demeure
une obligation de choix.
Les fournisseurs externes se doivent partager avec l’organisation informatique de l’entreprise
certaines valeurs :

39
Une direction stratégique, des objectifs, des pratiques, des processus, un langage,
des métriques.
L’approche que propose I.T.I.L permet de faciliter le partage efficace de ces valeurs.
3.3.4. L’approche de la gestion des services :
Par définition La gestion des services (I.T.S.M) est un ensemble d’aptitudes utilisées
pour fournir de la valeur aux clients sous la forme de services.
Le fournisseur de service informatique en est le propriétaire incontesté de ces services
dont il a l’obligation de gérer l’équilibre, l’optimisation et la cohérence lors de la fourniture
aux différentes organisations d’affaires considérées comme ses clients potentiels.
La fourniture de service informatique met l’accent sur :
 La gestion des risques opérationnels : rupture de service, capacité insuffisante face
à une demande, reprise d’activité après désastre,…etc.
 La facturation des services fournis : se traduit par l’élaboration des budgets
de fonctionnement et les budgets de développement.
L’organisation d’affaire doit disposer des services clairement formalisés dans un catalogue
de service afin que cette dernière puise le service concerné pour ces processus métiers.
La valeur ajoutée pour un client donné (organisation d’affaire) se traduit par une prestation
informatique d’intérêt ou d’avantages liés à l’activité d’affaire.
3.3.5. La fourniture de la valeur aux clients :
La fourniture du service informatique adéquat nécessite :
 Des ressources : de nature technique, humaines, financières.
 Des aptitudes : la capacité de l’organisation à gérer ces ressources en s’appuient
sur l’expérience capitalisée, des méthodes, …etc.


Fig. 11 : Fourniture de service. [20]

40
3.3.6. Les ressources et les aptitudes :
Les ressources représentent les éléments de base alimentant la production de service citant :
 Le capital financier : les budgets accordés à l’activité informatique,
 L’infrastructure : le socle technique de support aux applications informatique,
 Le système d’information : visible par l’utilisateur final,
 L’information : produite et gérée par les applications d’affaires,
 La ressource humaine.
Les aptitudes représentent la capacité de l’organisation informatique à :
 Aligner les services fournis aux besoins des clients,
 Coordonner et optimiser l’utilisation des ressources pour être efficace et efficient.
Aussi peuvent être considérés comme de l’ingénierie à l’entretien de l’ensemble du service :
 Le management : la culture services et I.T.S.M,
 L’organisation : hiérarchie et responsabilité,
 Les processus : la structuration des activités de la direction informatique afin d’obtenir
des résultats constants,
 La connaissance : l’expérience des personnes sur tous les domaines permettant
d’optimiser l’ensemble (marché de l’entreprise, processus métiers, technologies
informatiques, connaissances des applications en production, etc.),
 Les personnes.
Cas particulier est à considérer : les personnes qui sont à la fois :
Des ressources (humaines) : une équipe dimensionnée en nombre de personnes pour assurer
un certain volume de travail.
Des aptitudes : La personne connaissant le fonctionnement de l’entreprise, de l’organisation
informatique, des technologies et des applications sera plus efficace
en cas de dysfonctionnement et dans la mise en œuvre d’un changement
qu’une autre personne n’ayant pas ces connaissances. (voir Fig.20)
Les ressources et les aptitudes constituent les actifs du service informatique. [20]

Fig. 12 : Ressources et aptitudes. [20]

41
3.3.7. Concevoir des processus :
Par définition un processus est une suite d’activités liées de façon logique et poursuivant
un objectif défini.
Un processus est un ensemble structuré d’activités :
 Déclenchés par un événement spécifique.
 Générant des résultats spécifiques, à des clients ou à des parties prenantes.
 Produisant des résultats mesurables.
 Octroyer de l’action aux individus (attribution des rôles aux acteurs).
L’efficacité est une mesure permettant de savoir si les objectifs d’un processus, d’un service
ou d’une activité ont été atteints.
Un processus ou une activité efficace est celui ou celle qui atteint les objectifs convenus.
L’efficience est une mesure permettant de savoir si la bonne quantité de ressources
a été utilisée pour un processus, un service ou une activité.
Un processus efficient atteint ses objectifs avec un minimum de temps, d’argent, de personnel
ou autres ressources. (voir Fig.13)

Fig. 13 : Architecture d’un processus type. [20]

Afin de mieux étayé ce qui précède, l’enchaînement des activités peut empreinter plusieurs
formes : cyclique, permanente, linéaire, etc., quant au processus doit être déclenché
par un événement spécifique qu’il faut décrire.
Les résultats produits par un processus donné doivent être obligatoirement mesurés
et comparés aux objectifs du processus. Ces résultats doivent toujours apporter de la valeur
au client (demandeur).
Un processus peut être visible pour des clients comme la gestion des incidents
où le bénéficiaire des résultats est simplement le client.
Certains processus peuvent être internes à l’organisation informatique. Dans ce cas,
le bénéficiaire n’est pas un client mais une partie prenante (stakeholder), terme générique

42
incluant les clients et tout personne interne ou chez un fournisseur externe déclenchant
le processus comme la gestion des configurations en guise d’exemple.
Les activités du processus sont réalisées, coordonnées et pilotées par des rôles
et non directement par des personnes ou des équipes.
Cette notion de rôle permet de décrire un processus indépendamment de l’organisation
et de le rendre plus générique.
Un rôle est rempli par une équipe, une personne ou un comité dans l’organisation.
Une personne ou une équipe se voie attribuer plusieurs rôles issus de plusieurs processus
différents et permettre de définir des fiches de poste.
Un rôle représente :
 Un concept abstrait permettant de séparer la définition des processus de la définition
de l’organisation,
 Une personne ou un comité dans l’organisation se verra attribué un ou plusieurs rôles.

Fig. 14 : Processus et organisation. [20]

3.3.8. Utilité et Garantie :
La production de la valeur au client est la résultante de la combinaison de deux parties
indissociables :
L’utilité :
Tous simplement l’utilité est atteinte lors ce que le service fournis répond de manière
complète au besoin du client demandeur, donc l’utilité est le fait résultant de :
 L’amélioration des processus d’affaires et des actifs de clients,
 La levée des contraintes. [20]
La garantie :
Le service répond correctement aux exigences d’utilisation du client.
La garantie s’articule aux tours de (04) thèmes obligatoires :

43
  La disponibilité : s’opère et se vérifie par rapport aux conditions d’utilisation définie
par le client,
 La capacité et la performance : le service devra être performent en respectant
lors de l’exploitation les conditions convenues avec le client (nombre maximal
autorisé des connexions simultanées par utilisateurs par exemple),
 La continuité de service : le service doit assurer l’opérationnalité en mode dégradé
de l’activité en cas de sinistre ou de catastrophe,
 La sécurité : le service doit veiller à la protection de l’information gérée
par les utilisateurs en assurant un certain niveau de sécurité convenue avec le client.
Dans d’autres termes la garantie doit vérifier les critères ou les thèmes précédents.
A noter que les deux premiers thèmes sont directement perceptibles par le client.
Les deux autres concernent les risques liés à la technologie informatique.
Sur le plan opérationnel la garantie est matérialisée par un accord établie entre le fournisseur
de service et le client communément désigné sous le terme S.L.A (Accord de niveau de service).
La garantie peut se manifester à travers plusieurs services à niveaux différents interprétant
ainsi la qualité de service fournis. [20]
3.3.9. Le noyau de la méthode I.T.I.L :
Le noyau est complètement centré sur la gestion des services structurée en deux parties
distinctes (selon la v 2.0) traitant :
 Le soutient des services.
 La fourniture de services.
Une batterie de processus constitue chaque partie en phase
(cycle de vie des services v3.0). [25]
3.4. Conclusion :
L’adoption du projet I.T.I.L® à l’échelle de l’entreprise permet le développement
des capacités à surmonter la concurrence et les défis de l’environnent économique.
Pour ce qui est de l’organisation informatique la mise en place du noyau de processus
y afférents à la partie soutient des services et à a la partie fourniture de service permet
l’émergence de centre de compétences à valeur ajouté.
L’alignement du métier aux objectifs de l’entreprise demeure l’atout majeur accompagné
par un changement culturel.
Les deux chapitres qui vont suivre seront consacrés essentiellement au noyau de la méthode
à savoir la structure et les processus cibles qui en découlent.

44
 Chapitre 04 :
Cadre théorique d'un centre de service selon I.T.I.L® v3.0

45
4.1. Introduction :
La gestion des services informatiques au sens I.T.I.L® diffère de la gestion classique
(Chapitre 02) de par le raffinement des raisonnements et le formalisme des activités
et des logiques d’action.
La fondation de cette gestion est conçu à travers une couche de base traduisant tous
le soutient de l’exploitation et la fourniture de service informatique dans le cadre d’un cycle
de vie complètement structuré.
Selon l’architecture proposée par I.T.I.L® v.3.0, la partie théorique sera uniquement accentuée
sur quelques processus et fonctions est ce en harmonie avec le cadre d’étude du projet
et l’implémentation projetée ultérieurement :
 Le centre de service.
 La gestion des incidents. Phase Exploitation des services.
 La gestion des problèmes.
 La gestion des niveaux de services. Phase Conception de services.
4.2. Le centre de service :
Permet d’effectuer les opérations journalières de maintien du service fournis aux clients
(qualité de service).
La communication avec les utilisateurs finaux (production informatique) s’opère à travers
un point d’entrée unique ou point de contact unique (S.P.O.C 1).
Le Service Desk représente le centre névralgique des opérations de production informatique
appelé ainsi le centre de service (le centre de service opérationnel).
Par conception le centre de service travail sur deux plans :
 L’assistance aux utilisateurs : la fonction classique,
 L’interface : entre les utilisateurs et le service informatique.
Dans la situation d’absence totale de ce centre de service, les techniciens chargés
de l’exploitation et de la gestion du système d’exploitation sont directement confrontées
aux utilisateurs finaux, ce qui induit à un mode pompier permanant.
La conséquence est fâcheuse traduite par un manque flagrant de confiance des utilisateurs
et la genèse d’un support parallèle issus des mêmes utilisateurs.
Logiquement le temps consacré à la résolution de l’incident augmente substantiellement,
et la qualité de service devienne médiocre.
1. S.P.O.C : (Single Point of Contact) : Fournit un moyen unique et cohérent de communiquer avec une organisation
ou une unité métiers.

46
Ce constat existe dans plusieurs sociétés historiques réfractaires aux projets de restructuration
et de développement et ce indépendamment de la compétence technique de l’équipe
informatique du fait que ces derniers s’occupent quotidiennement à réorganiser le travail
et à la gestion. Le comportement de l’utilisateur face à une demande de service est quasiment
important ce dernier veut que sa requête soit traitée rapidement mieux obtenir un résultat.
Tous désagrément causé par le changement aléatoire d’interlocuteurs techniques et la durés
de la prise en charge effective par le technicien compètent en la matière joue un rôle
important dans la perception globale de l’informatique par la direction générale,
il en va de même de la réputation à mettre en examen.
L’instauration du centre de service corrige définitivement la situation par :
 Le rétablissement de service dès le premier contact : le technicien doit se focaliser
sur le besoin métier de l’utilisateur et non sur la technologie i.e. : rétablir le service au
lieu de résoudre l’incident,
 Reconquérir la confiance des utilisateurs en les fédérant tous aux tours de leurs
intérêts métiers par la qualité des prestations,
 Concourir à l’appui de la direction générale : efficacité de la structure technique
à répondre aux exigences métiers de l’institution.
La mutation du centre d’assistance vers le centre de service a été bien motivée par l’évolution
du besoin métier. Plus loin encore c’est la relation avec l’utilisateur qui a impacté
ce changement organisationnel.
Bien que le centre de service soit l’interlocuteur privilégié, il se doit d’anticiper et corriger
les dysfonctionnements du système d’information avant qu’il ne se produisent car le mode
réactif seul devient insuffisant à produire un support de haute qualité (pourcentage des appels
résolus dès le premier contacte).
Le centre de service constitue un vrai projet dans l’entreprise qui demande une volonté de fer
et un investissement propre.
Le mode de centralisation qu’offre cette organisation permet non seulement de connaitre avec
précision la consommation réelle du service concernant un incident particulier mais
d’implanter rationnellement la maitrise des couts. [21]
4.2.1. Les technologies de centres de services :
Au début il faut se mettre d’accord que le but recherché ce n’est pas la technologie au sens
pure mais la finalité emploie la technologie comme un moyen.
A noter que la technologie reste le fer de lance dans l’accomplissement des missions
et des taches conférées aux membres des équipes d’interventions et au centre de service.

47
L’informatique en réalité constitue un amplificateur de l’organisation et des processus
associés, donc si au départ l’entreprise dispose d’une organisation quasiment défaillante,
la mise en place des outils et des solutions informatiques ne va qu’accélérer et amplifier
le phénomène (la défaillance).
Mette en place une organisation structurelle d’un centre de service n’obéie pas à un modèle
universel précis du fait qu’il n’existe même pas. Aussi l’inexistence de modalités pratiques
d’implémentation. Cependant l’adoption de la structure du centre de service doit se plier aux
considérations (critères) suivants :
 Le volume de l’activité informatique.
 La localisation géographique.
 L’importance de l’organisation.
D’après I.T.I.L il existe (03) types de structures à envisager :
4.2.1.1. Centre de service local :
Perçu comme l’organisation classique à mettre en œuvre le centre de service.
L’organisation proposée procure un service local complet i.e. : sur le site même
avec la possibilité d’adaptation dans la situation multi-sites.
L’inconvénient c’est qu’il faut au préalable disposer dans tous les sites de :
 Procédures de travail communes,
 Matériel uniformisé,
 Partage des compétences entres les centres de supports : duplication des ressources,
 Indicateurs uniformisés de contrôle de l’activité,
 Compte rendu commun.
La figure illustre de manier simple l’architecture de l’organisation.

Utilisateur Utilisateur Utilisateur

local local local

Centre de service

Support système Support Support Micro

Support externe
& réseau applications & bureautique

Fig.15 : Centre de service local. [21]

48
4.2.1.2. Centre de service mutualisé :
Conçu pour les organisations étendus (ex : plusieurs établissements).
Le centre de service est complètement centralisé, et les sites disposent de la même assistance.
Ce type d’organisation provoque une relative perte de proximité chez les utilisateurs mais
aussitôt compensée par le gain en couts opérationnel directe (infrastructure téléphonique,
salles informatiques, matériel, personnel).
La centralisation de l’information dans une seule base de données, permet de disposer à tous
moment d’une vision claire de la situation.
Des rapports de synthèses peuvent se faire systématiquement.

Centre de service
mutualisé

Support
Support Support Support Micro
système
externe applications & bureautique
& réseau
Fig. 16 : Centre de service mutualisé. [21]
4.2.1.3. Centre de service virtuel :
Conçu à la base des deux technologies comme un modèle hybride puisant de la puissance
de chaque organisation, dont les points forts sont déclinés comme suite :
 La faculté de répondre à n’importe quel site et de manière continue,
 La proximité des techniciens : intervention sur le même site.
L’atout majeur de cette organisation c’est qu’elles s’appuient sur l’emploie des technologies
réseau et télécommunication palliant au contraintes liées à la géographie, et au temps
de réponse.

49
 Centre de service
Los Angeles

Centre de service
Virtuel Centre de service
Sydney

Centre de service
Paris

Fig. 17 : Centre de service virtuel. [21]

4.2.2. Interface avec les autres processus :

Rapport
CI info Niveaux de Service level
Configuration
Management services Management
Mise à jour

Solutions
Incident
SERVICE DESK Incidents Management
Demande de
Services

FSC Problem
Change Erreurs Connues
Management Management
RFC

Fig.18 : Interface du service desk avec les autres processus I.T.I.L®. [15].
4.3. La gestion des incidents :
Dans la situation d’un service informatique non géré, le constat est immédiat :
 La fréquence des ruptures de service suite aux interruptions causées
par la disponibilité du technicien en charge,
 Les incidents mineurs se multiplies dont certains évoluent pour devenir critiques,
 Le partage de l’expérience ne s’opère pas entres les différents intervenants au cours
du processus de résolution de l’incident,
 Perte éventuelle des incidents manifestés,
 Responsabilités diluées au cours des étapes de résolution.

50
L’approche proposée par I.T.I.L à travers le processus de la gestion des incidents permet
de provoquer un grand changement qualitatif par :
 La mise en place d’un système d’escalade (conception et mise en place de plusieurs
niveaux de support) afin de contrôler la propagation et de contenir l’évolution
des incidents affectant la qualité de service,
 La mise en place d’une gestion d’incidents : la priorité d’un incident est organisée
au tour d’un mécanisme d’ordonnancement calculé en fonction des critères
de l’urgence et du critère de l’impact,
 L’optimisation des ressources humaines et matérielles impliquées dans le processus
de support,
 Capitaliser et partager l’expérience accumulée par les techniciens : mise en place
d’une base de connaissances,
 Mise en place d’une gestion formelle : palier aux problèmes de perte d’incidents
(approche systématique de résolution d’incidents),
 Contrôle proactif de la qualité : niveaux de services négociés avec
les utilisateurs (S.L.A).
Durant le traitement de l’incident et selon le processus proposé l’incident change en modifiant
son statut (nouveau, planifié, assigné, résolu, clôturé, etc.). Ainsi il permet de connaitre à tous
instant sa position (étape de traitement).
De plus en cas de rupture de S.L.A et le déclanchement d’un audit à l’égard du support
informatique tous les évènements et toutes les modifications apportées durant le traitement
de l’incident sont déjà consignés : Fiche de l’incident. [21]
4.3.1. Définitions et terminologie :
 Incident : Un incident est tout événement qui ne fait pas partie du fonctionnement
normal d’un service et qui provoque ou peut provoquer une interruption
ou une diminution de la qualité de ce service. [23]
 Urgence d’un incident : délai acceptable pour l’utilisateur ou pour les processus
business. [23]
 Impact d’un incident : importance de l’écart par rapport au niveau normal de service,
en termes de nombre d’utilisateurs ou de processus business touchés. [23]
 Un problème : La cause inconnue d’un ou de plusieurs incidents. [21]
Lorsque l’incident présente un impact global : il s’agit d’un incident majeur et à ce stade
une équipe spécifique de gestion des incidents regroupant des éléments interne plus ceux

51
provenant d’autres processus (gestion des problèmes) et même externe (support externe)
doit être organisée et réunie afin de rétablir la situation.
4.3.2. Les niveaux d’escalades :
Principalement structurés en deux types :
 L’escalade fonctionnelle :
Le premier niveau c’est le centre de service si ce dernier ne parvient pas à régler rapidement
l’incident une procédure d’escalade vers un autre niveau supérieur de support comportant
des spécialistes disposant d’un niveau de compétence raffiné et du temps.
La procédure est immédiatement engagée résultat : l’incident est automatiquement transféré
vers le support approprié.
La conception de plusieurs niveaux de support est fort envisageable de même recommandée
pour les organisations complexes.
Ce type d’escalade permet de concentrer plus de ressources au traitement de l’incident.
 L’escalade hiérarchique :
Ce type d’escalade intervient lors d’une décision concernant le recours à un support externe.
4.3.3. Description du processus de la gestion des incidents :
Suite à la détection et la déclaration de l’incident le centre de service entreprend
l’enregistrement de l’évènement (information sur l’utilisateur, symptômes, configuration,
premier diagnostic),
Par la suite les informations collectées permettent de classifier l’incident soit :
 Incident déjà produit,
 Erreur connue avec solution palliative,
 Incident déjà résolue : recours directe à la C.M.D.B (résolution au 1ier niveau).
L’étape qui suit permet l’évaluation de la priorité à octroyer pour cet incident en fonction
de l’urgence dégagée et de l’impact enregistré sur le système d’information,
Cette étape est primordiale à l’allocation des ressources nécessaires et adéquates à l’étape
de résolution ainsi de déterminer avec précision les détails de la restitution des garantis
en disposant des contrats de services.
L’étape suivant consiste à identifier la solution de l’incident, une fois appliquée le service
se voie restauré et disponible à nouveau.
Dans le cas où l’incident ne trouve pas de solution, un transfert vers une équipe de support
spécialisé s’opère.

52
Si tous de même l’incident reste sans solution définitive il devient un problème, le centre
de service communique aussi tôt l’information à l’équipe de la gestion des problèmes
(quel que soit le stade du support). Il se peut que le centre de service est en mesure
de se prononcer du problème lorsque d’éventuelles dysfonctionnement de même nature
puissent surgir ce qui lui met alaise dans cette décision. Une fois l’incident résolu consentant
à l’accord de l’utilisateur, le centre de service clôture l’intervention tous en disposant
d’un rapport complet sur l’incident produit.
Le rapport d’incident compte : le parcours et les actions prises lors de la résolution
(traitement), le détail de la solution, les couts engendrés, le temps du traitement.
Dans cette gestion le centre de service assume complètement la responsabilité de la gestion
de l’incident, en suivant de pas à pas le déroulement des actions de résolution
tous en informant l’utilisateur de l’état d’avancement de sa requête.
En effet le contrôle devient plus sensible pour chaque incident ouvert et qui transite entres
plusieurs équipes de support spécialisés tous en changeant progressivement son statut initial,
cela peut engendrer.
L’effet « Ping - Pong », et c’est l’un des rôles du centre de service pour gérer et contenir
la situation sous entière control.
Le traitement de l’incident comporte deux modes de gestion correspondants aux principes de :
 L’escalade,
 S.L.A.
A noter que ce type de traitement ne doit en aucun cas être confondu avec la gestion
des problèmes qui met en évidence le côté récalcitrant (récurant) de l’incident à traiter.
Dans le cas où la résolution définitive de l’incident impose de grands changements,
une solution de contournement doit être aussi tôt déployée en la faisant examiner et avaliser
d’abord par le processus de gestion des problèmes, systématiquement la mise à jour
de la C.M.D.B va permettre aux techniciens de connaitre cette solution palliative.
La figure illustre de manière simple le processus de la gestion des incidents.

Enregistrement Classification Recherche &

Début
de l’incident de l’incident diagnostique

Résolution
& restauration Fermeture de l’incident Fin
du service

Fig.19 : Flux simplifie du processus de gestion des incidents. [21]

53
4.3.4. Planification et mise en œuvre :
La mise en place de la gestion des incidents est conditionnée par l’existence d’un centre
de service. Il est fortement recommandé la création préalable du centre de service au début
du projet informatique globale.
La gestion des incidents est un processus de base du fait qu’il génère le meilleur retours
sur investissement sans pour autant négliger le reste des processus (gestion des problèmes,
gestion des changements, gestion des configurations) qui demeurent toujours indispensables
à mettre en place.
4.3.5. Mesures et contrôle :
La validation de l’efficacité du processus de la gestion des incidents concerne directement
le centre de service, ce dernier met en place plusieurs métriques pour ces fins de contrôle :
 Le nombre des incidents,
 La durée des incidents,
 L’impact constaté sur le système d’information,
 Ratios incidents résolus : entre le 1ier niveau de support et les autres niveaux (02, 03).

Fig.20 : Synoptique du processus de gestion incidents. [34]

4.3.6. Rapport de gestion :
Les rapports de gestion doivent être élaborés par le centre de service puis destinés à plusieurs
publics notamment :
 La direction générale,
 Les directions opérationnelles,
 La direction informatique.

54
4.3.7. Les conséquences de l’implémentation du processus de la gestion des incidents :
Dès la mise en place de ce processus, les résultats devient aussi tôt tangibles et positifs citant :
 Le rétrécissement du périmètre de l’impact sur le système d’information,
 La validation de l’efficacité du processus et de son adéquation avec le métier,
 La capitalisation des effets d’expériences,
 La rationalisation de l’utilisation des ressources,
 L’éradication progressive du phénomène liée à la perte des demandes,
 Satisfaction des utilisateurs.
Arriver à cette situation forte édifiante n’est accomplis sans obstacles, le plus classiquement
connue c’est la résistance systématique aux changements qui se manifeste bien avant
l’implémentation du processus mais c’est lors de la mise en place du centre de service.
L’absence de la culture service à contracter (S.L.A) conduit à une mauvaise expression
des besoins conjugués au manque d’engagement de la direction générale et traduit
par le manque de moyens à disposer.
4.3.8. Les outils :
Sur le plan opérationnel le processus de gestion des incidents est fortement lié au centre
de service qui constitue le départ de la résolution de l’incident.
La mise en place d’un outil simple d’escalade automatique paramétrable :
 Délais de réponse de l’équipe d’intervention,
 Détection automatique d’incident : alertes envoyés (ordinateurs, réseaux, applications,
services systèmes d’information),
 L’exploitation active de la C.M.D.B : relation fiche incident,
 Accès banalisé (web : intranet) à l’application de la gestion des incidents.
4.3.9. Rôles et responsabilités :
1- Responsable de la gestion des incidents :
A défaut le responsable du centre de service, couvre plusieurs rôles importants à savoir :
 La gestion des équipes d’intervention : répartition des tâches,…etc.
 Mesurer l’efficacité de l’organisation et proposer des améliorations possibles,
 Concevoir et élaborer le reporting de l’activité,
 Gérer les conflits et le stress au sein de l’équipe,
 Adopter les techniques de communications interpersonnelles,
 Travail dans la pression,
 Méthodologies des approches empreintées,...etc.

55
Il s’agit bien d’une personne doté d’un fort caractère disposant de facultés morales
(résolu, mesuré) et d’une compétence technique irréprochable, bref toute aptitude inhérente
à un manager,
2- Equipe d’intervention :
Les membres de cette équipe par essence présentent certaines aptitudes professionnels
ce qui rend efficace la structure informatique face aux incidents, par conséquent
le recrutement des techniciens de support devient plus raffiné et plus sensible
car sa constitue un facteur déterminant dans la qualité des prestations et du cout
de la perception global du centre de service par la direction de l’entreprise.
4.3.10. Interface processus :
Rapport
CI info Service level
Configuration
Management Niveaux de Management
Mise à jour services

Change ??
Change information GESTION DES Availability
Management INCIDENTS Infos sur les Management
FsC incidents

Solutions ??
WA Capacity
Problem
Infos sur les Management
Management
Maj incidents

Incidents de
Classification
Sécurité

Security
Management

Fig. 21 : Interface de la gestion des incidents avec les autres processus I.T.I.L®. [15].
4.4. La gestion des problèmes :
Cette gestion traite les problèmes produits par les incidents récurrents (ou récalcitrants)
et dans les causes ne sont pas encore élucidées. Par conception la gestion des problèmes
ne consiste pas en priorité de rétablir la disponibilité du service mais d’identifier les vraies
causes du problème à traiter, donc raisonnablement le processus de la gestion des problèmes
doit consommer le temps qu’il faut afin de résulter de la solution adéquate, cela peut entrainer
la rupture du contrat S.L.A établi ce qui constitue une conséquence mesurée dans la gestion
globale (centre de service).
L’équilibre est maintenu par le fait que la gestion des problèmes permet efficacement
de réduire l’impact des problèmes en éliminant simplement à l’origine les causes de leurs
apparitions.

56
Le travail de fond consiste à une phase d’investigation très raffinée au tour du problème
concluent à une identification formelle des causes, et à une résolution par une solution
définitive. L’approche d’anticipation caractéristique de la gestion des problèmes est un atout
majeur empêchant tous incident de se reproduire.
Une autre valeur ajoutée c’est que cette gestion produit une documentation précieuse lors
de la recherche et l’identification.
Toujours utile la documentation générée est automatiquement exploitée par le centre
de service (résolution des incidents au premier cout) et les techniciens non spécialisés.
4.4.1. Description du processus de la gestion des problèmes :
L’analyse des incidents récurrents s’opèrent en deux modes :
 Le mode réactif : L’analyse se joue lors de l’apparition d’incident reçurent,
 Le mode proactif : l’analyse s’effectue sur un ensemble d’incidents afin de déduire
des modèles ou des tendances.
Pour ce qui est du côté démarche de résolution de problème envers une solution définitive,
à noter qu’il s’agit de faire évoluer le problème en erreur connue et ce en identifiant l’origine
du dysfonctionnement sans pour autant trouver la solution recherché (définitive),
Le second palier consiste à trouver une solution qui sollicite une demande de changement
(R.F.C) qui soit acceptable au plan budgétaire sinon toute solution de contournement
(solution palliative) devienne définitive.
La figure illustre de manière simple la démarche.

Enregistrement Classification
Début
du problème du problème

R.F.C et fermeture Recherche

Control des erreurs
possible et diagnostique

Fig.22 : Schéma simplifié du contrôle des problèmes. [21].

L’absence de cette gestion induit des conséquences négatives à l’égard de l’image
de l’informatique en générale du fait que le mode réactif ne confère pas aux équipes
d’intervention le temps nécessaire pour isoler les causes réelles d’un incident récalcitrant,
d’autant plus la persistance de cette situation provoquant une démotivation systématique chez
les informaticiens en charge. Le processus de la gestion des problèmes dispose d’une étroite
relation avec le processus de la gestion des incidents car ce dernier recouvre d’autres
informations sur l’incident si par exemple il existe un lien entre l’incident et une erreur

57
connue. Une autre forme de coopération entre ces deux processus réside lors
de l’identification de la solution au problème, l’information est communiquée au centre
de service et du cout à la gestion des incidents.
Pour mieux comprendre encore l’ensemble des activités de la gestion des problèmes sont :
 Le control des problèmes,
 Le control des erreurs,
 La prévention des problèmes,
 L’identification des tendances,
 La production de l’information de gestion : à destination du centre de service,
 La tenue des réunions concernant les problèmes majeurs,
Le même principe pour le control des erreurs,
La figure illustre de manière simple la démarche.

Control des problèmes

Enregistrement
Evaluation de l’erreur
de l’erreur

Fermeture erreur
Résolution de l’erreur
et problème associé

Fin

R.F.C

Fig.23 : Schéma simplifié du contrôle des erreurs. [21].

Plus concis encore l’implémentation du processus de la gestion des problèmes est structurée
aux tours de trois (03) activités de base à savoir :
 Le contrôle des problèmes : par son mode réactif ce type de contrôle permet
d’identifier les causes révélées par un ou par plusieurs incidents afin de fournir le plus
rapidement possible une solution empêchant la reproduction du dit incident,
ce contrôle se fait en phases identification et enregistrement des problèmes,
la classification, la recherche de la solution adéquate,
 Le contrôle des erreurs : par son mode réactif agissant de la même façon
que le contrôle des problèmes,

58
  La prévention des problèmes : le mode proactif se traduit par l’analyse des données
des incidents, identifier la récurrence, rapprochement avec les problèmes traités
et les erreurs connues impliquant une analyse complète de l’infrastructure I.T.
A noter que ce mode proactif concerne également d’autre processus à identifier
ces dysfonctionnements notamment :
 La gestion de la capacité,
 La gestion de la disponibilité.
Lors de l’enregistrement du problème, les informations sont automatiquement consignées
dans la C.M.D.B de la même façon pour les incidents ce qui favorise la mise en place des liens
problèmes – incidents par exemple : les données sur les C.I (Configuration Item).
La classification des problèmes repose sur plusieurs paramètres :
 Le type du problème : logiciel, matériel, service,
 L’urgence du problème,
 L’impact du problème sur le S.I,
 L’effort fournis dans l’identification d’éléments C.I impliqués dans le problème,
 L’effort dépensé pour la remise en fonction.
La C.M.D.B joue un rôle important dans l’évaluation de l’impact du problème sur le S.I.
Le caractère de l’urgence n’a pas la même perception que dans la gestion des incidents mais
il s’opère de manière un peu relative générée lors de la recherche d’une solution
de contournement au problème. Donc ce caractère obéi à d’autres critères citant :
 La possibilité d’intervention planifiée sur le système d’information,
 La précarité de la solution de contournement,
 L’impact sur l’environnement économique.
Le pré requis recommandés lors de la phase recherche et diagnostique :
 Disposer de la documentation du système,
 Disposer de l’architecture des applications, services, réseaux,
 Récapitulatifs de dernières modifications effectuées sur le système.
Par fois l’intervention des spécialistes chevauches entres les deux gestions
(incidents, problèmes), il faut bien que les responsables de ces gestions respectives se mettent
d’accord sur un ratio de participation pour chaque processus faut de quoi la gestion
des incidents utilise cette ressource en mode pompier. La divergence d’intérêts enregistrée
entre la gestion des problèmes et la gestion des incidents se manifeste aux tours
des classements de priorités.

59
Plus claire encore dans le cas d’un arrêt de production la gestion des incidents demande
à rétablir en état opérationnel le service défaillant le plus rapidement possible alors que pour
la gestion des problèmes cette dernière réclame la conservation de l’incident dans son dernier
état afin d’y travaillé dessus.
La méthode I.T.I.L s’appuie sur des approches classiques permettant de structurer l’analyse
des problèmes comme :
 L’approche de Kepner et Tregoe1.
 Le diagramme d’Ichikawa 2 établie lors de réunions de brainstorming,
4.4.2. Planification et mise en œuvre :
La relation qui existe entre la gestion des problèmes et celle des incidents n’a pas
de conséquences sur de la mise en œuvre. Cependant il est toujours utile d’implémenter
le processus de la gestion des problèmes aussi tôt que possible. Cette implémentation peut
se faire en parallèle avec celle de la gestion des incidents en étant conscient qu’un manque
de ressource peut influer la manière de s’y prendre, le plus souvent se concentrer
que sur l’implémentation de l’aspect réactif du processus et de différé l’aspect proactif. Dans
la situation des ressources quasiment limités, il est recommandé de se concentrer
sur les problèmes les plus fréquent « Top 10 ». D’après l’expérience 20 % des problèmes sont
à l’origine de 80 % de détérioration de services.
4.4.3. Mesures et contrôle :
L’efficacité du processus et la qualité de service s’obtient à travers de fines statistiques
élaborées à la base de l’historique des interventions effectuées (problèmes et incidents
résolues). Les indices utilisés pour la mesure et le contrôle sont :
 Le nombre de problèmes et erreurs identifiés,
 Le nombre de demande de changement exprimés,
 Le nombre de corrections réalisés,
 Estimation du gain de disponibilité du S.I,
 Estimations des couts liés.
1. L’analyse des Docteurs Kepner et Tregoe (KT) : créé en 1958, est une approche structurée
et rationnelle de résolution de problème et de prise de décision critique.
La méthode rationnelle a été construite par l'observation de managers dans des contextes de prises
de décision difficiles. L'objectif est d'aider le manager à mettre en œuvre de manière systématique
des méthodes logiques et cohérentes de management.
2. Le Diagramme de causes et effets, ou diagramme d'Ishikawa, ou diagramme en arêtes de poisson ou encore
5M, est un outil développé par Kaoru Ishikawa en 1962 et servant dans la gestion de la qualité.

60
4.4.4. Rapport de gestion :
Le rapport de gestion constitue un moyen puissant permettant d’évaluer rationnellement
le progrès réalisé dans le traitement des dysfonctionnements,
Le rapport doit comporter :
 Les problèmes identifiés,
 Les erreurs connues,
 Les demandes de changements.
Ainsi qu’a des informations sur les ressources utilisées lors de la phase d’identification,
de recherche ou sur le niveau de progression des recherches en cours d’investigation.
Le processus de la gestion des problèmes doit être en mesure de fournir l’information
adéquate accompagnée de moyens d’interprétation au centre de service.
La communication des détails y afférents aux :
 Palliatifs : solutions de contournements,
 Les corrections effectuées,
 Les demandes de changements à destination du centre de service,
Le centre de service à son tour assure la diffusion de l’information aux différentes parties
prenantes notamment au management et aux directions métiers, voir même aux utilisateurs.
4.4.5. Les conséquences de l’implémentation du processus de la gestion des problèmes :
L’implémentation du processus dégage une panoplie de conséquences positives citant :
 L’amélioration de la qualité de service : réduction du volume d’incidents,
 Provoquer un meilleur taux de résolution des incidents dès le premier essai :
centre de service,
 La prise en compte des besoins de l’entreprise en se focalisant sur les évènements
importants (système de priorité),
 Palier au risque de générer un service support bis.
Par contre l’entretien et la maintenance de la C.M.D.B demeure une activité de priorité.
4.4.6. Rôles et responsabilités :
Le responsable de la gestion des problèmes dispose de plusieurs rôles :
 La maintenance du processus,
 L’optimisation de l’efficacité du processus,
 Amélioration du fonctionnement du processus,
 La production des rapports à destination du centre de service,
 La gestion d’équipe : planning, allocation de ressources,…etc.

61
Les informations transmises au centre de service et à la direction générale permettant
de valider l’efficacité du processus en question. Il est jugé utile de noter qu’à défaut
le responsable de la gestion des incidents et le même responsable du centre de service, cela
n’est pas autorisé pour la gestion des problèmes qui doit disposer de son propre responsable
en raison des conflits d’intérêts qui peuvent susciter.
4.5. La gestion des niveaux de services :
Face à la concurrence soutenue des sociétés de services informatiques les D.S.I ont adoptés
une approche qui vise à gérer leurs informatiques internes comme étant un service fournisseur
externe cela n’explique pas l’écartement des sociétés informatiques de la vie de l’entreprise
mais seulement une manière de s’organiser plus structurée avec ces derniers traduite
par des relations contractuelles à base d’accords et d’objectifs. S’engager dans la fourniture
d’un service informatique précis revient à le définir d’abord en fond et en forme.
Le fond du service représente le contenu à livrer, la forme du service représente la façon
de présenter le service.
La base de la conception d’un service repose strictement sur la formulation des besoins
et des exigences reportées par les clients de ce service.
La gestion des niveaux de services (S.L.M : Service Level Management) concrétise
parfaitement ce travail en s’appuyant sur des accords bien négociés ce qui permet
une diligence et un contrôle continu aboutissant aux objectifs déjà définis.
4.5.1. Définitions et terminologie :
 S.I.P : (Service Improvment Program)
À l’image de la roue de Deming, le S.I.P correspond au programme d’amélioration
permanent de la qualité des services informatiques. Il se déroule dans un cycle
ininterrompu de mise en action, de contrôle, de validation et de modification. [21]
 S.L.R : (Service Level Requirement)
Globalement correspond à l’expression des besoins des clients et des utilisateurs.
Il s’agit du cahier des charges de ce qui est attendu dans le but de soutenir l’activité
de l’entreprise. [21]
 C.S : Le catalogue de services définit les services informatiques disponibles au sein
du système d’information (messagerie, bureautique, outils de gestion divers, E.R.P,
sauvegarde, anti-virus,…etc.). Il documente les principales caractéristiques
de ces services (disponibilité horaire, performance, capacité, coûts,…etc.). [21]
 S.L.A : L’accord de niveaux de service est un document écrit qui définit des objectifs
précis et spécifiques à ce service. Il engage les deux parties (clients et fournisseurs)

62
 sur les niveaux à atteindre en termes de disponibilité, de capacité et de coûts, et permet
l’évaluation des performances de l’organisation informatique lors de la fourniture
et le support de ce service. [21]
 O.L.A : La déclinaison en termes technique de la convention de niveaux de service
signée par les utilisateurs. Ce document permet de placer les ressources techniques
(humaines, matérielles, logicielles,…etc.) en regard des demandes exprimées
dans le S.L.R et validées dans le S.LA. [21]
 U.C : Les contrats de sous-traitance (Underpinning Contract) associés aux services
doivent également être documentés dans le cadre de la gestion des niveaux de service.
Ils doivent être régulièrement réévalués afin de valider qu’ils remplissent bien le rôle
qui leur est attribué dans l’atteinte des objectifs du S.L.A. [21]
4.5.2. Description du processus de la gestion des niveaux de services :
Le processus obéi au concept de la route de Deming, ce qui explique une démarche qualité
traduisant des mesures objectives du fonctionnement.
En entrée les principaux interlocuteurs du processus sont : les clients et les utilisateurs.
Plusieurs autres processus participent :
 La gestion de la capacité, la gestion financière, la gestion de la disponibilité, la gestion
de la continuité de service.
 La gestion des configurations et la gestion des changements intervient à leurs tours
afin d’en assurer que les niveaux de services ne sont pas influencés ni même perturbés
par leurs interventions.
La gestion des niveaux de services comprend (04) quatre familles d’activités :
1- La planification : traduite par la production du catalogue de service par la direction
informatique à l’égard des utilisateurs précédé par une évaluation de satisfaction.
2- La réalisation : la rédaction du projet S.L.A doit être effectuée après avoir analyser
les demandes des utilisateurs (S.L.R) suite à la publication du catalogue, suivi
par la négociation du projet avec les utilisateurs concernés afin de se mettre d’accord sur
les engagements. A ce stade la validation de l’adéquation entre le S.L.A et les O.L.A
et les U.C s’opère. Afin de prévenir tous litige entre le contractant lié à l’interprétation
des engagements il est d’une grande importance de définir sans ambiguïté chaque service
en utilisant un langage compréhensible.
3- La validation : traduite par des contrôles cycliques et réguliers dont le but d’obtention
de pistes d’amélioration de la qualité du service rendu.

63
4- L’amélioration : dans cette phase le S.L.A est mis en revu et en fonction de son niveau
d’efficacité des améliorations peuvent susciter.
La figure ci-après illustre de manière plus claire le processus.

Début Planifier Négocier Signer Fin

Contrôler

Fig.24 : Flux simplifié de la gestion des niveaux de services. [21].

4.5.3. Planification et mise en œuvre :
L’évaluation de la satisfaction actuelle des clients envers les services proposés constitue
la base de départ.
Des documents formels sont conçue au cours des étapes engagent la direction informatique
et les clients en guise de précision :
 Le catalogue de service :
Permet l’obtention d’une vue précise et synthétique des services proposés par le système
d’information de l’entreprise.
D’un angle purement fonctionnel les clients satisfaits du service rendu conformément
aux engagements disposent pleinement la capacité de le justifier financièrement.
 Expression des besoins des clients (S.L.R) :
Le but est la validation des besoins des clients par rapport au catalogue de service
ce qui explique la sensibilité de la démarche.
De manière professionnelle il est conseillé de procéder à la préparation d’un modèle
de document standardisé à l’égard des clients structuré en questions précises reprenant
les informations du catalogue.
Ce procédé permet de faire gagner du temps au lieu de débuter avec les clients par une simple
page blanche.
Comme première étape La mise en place de la structure de base des accords (S.L.A) doit être
calquée soit sur l’organisation soit sur la plateforme de service.
La seconde étape consiste à interroger les clients sur les éléments qui peuvent leurs intéressés
et figurant dans le cadre du besoin.

64
Il est important de définir les conditions de disponibilité, les horaires, les capacités
nécessaires en cas d’activité normal ou dans le cas de défaillance (service dégradé).
Suite à cette logique les utilisateurs ne se sentent pas imposé un produit mais un service
qui répond à leurs attentes.
 Conception du S.L.A :
Par conception l’accord est basé soit sur le client, soit sur le service,
Dans le premier cas : le S.L.A couvre tous les services,
Le deuxième cas le S.L.A couvre tous les utilisateurs d’un service unique, donc chaque
groupe d’utilisateurs est concerné par un besoin particulier ce qui met en évidence
la complexité de la gestion en vue des contraintes d’infrastructure, d’implantation
géographique.
L’avantage tiré de ce cas c’est que le S.L.A est directement calqué sur le catalogue de service.
Selon la conception, il est possible d’avoir des accords par niveau :
1- Le niveau entreprise : couvre les services et les niveaux de services communs
à l’ensemble des clients.
2- Le niveau client : couvre les services et les niveaux de services concernant
un groupe de clients.
3- Le niveau service : couvre un service consommé par un client spécifique.
 Négociation et signature du S.L.A :
Concrétise l’officialisation des engagements après la prise en compte des besoins
et des moyens disponibles.
Le choix du bon interlocuteur pour la partie client est décisif conjugué à l’implication
du niveau hiérarchique afin de donner sens à l’engagement.
Pour la partie fournisseur, la validation de la direction informatique traduit clairement
que l’engagement est réaliste, financièrement abordable.
L’accord doit être renégocié jusqu’à l’acceptation de tous les parties.
Un autre objectif rentre en jeux c’est la communication des différents accords établies
à l’ensemble des clients et les membres de la direction informatique et dans ce contexte
le centre de service peut jouer un rôle important par la diffusion.
 Control du S.L.A :
Au départ il est primordial de s’engager sur un service mesurable afin d’éviter tout conflit
avec les parties contractantes d’où l’importance d’aligner les dimensions de l’accord avec
les moyens techniques disponibles.

65
La méthode et la métrologie doit être définie au moment de la rédaction du document portant
sur l’accord. Il est difficile de mesurer la disponibilité du service en surveillant toute
la chaine de composants (les différents éléments entre le serveur et le poste client), mais
il est plutôt avantageux d’aligner l’accord avec la perception du service par les différents
clients. Dans ce contexte le centre de service contribue massivement au control
vue les informations qu’il fournit : temps de réponse de l’équipe informatique, du sous-
traitant lors de la résolution d’un incident donné.
Le control peut s’élargir au niveau des O.L.A et au niveau des U.C.
4.5.4. Mesures et contrôles :
La tenue des rapports de gestion et des réunions de suivi doivent être mentionné dans l’accord
signé par le client.
Juger de l’efficacité du processus à travers les indicateurs de performance :
 La proportion des services couverts par les accords,
 Le pourcentage d’objectifs atteints,
 Le nombre de rupture de services (graves),
Le reporting confère la possibilité d’analyser des tendances comme :
 La diminution des couts de production,
 L’augmentation du nombre d’objectifs atteint,
 L’amélioration de la perception globale des clients.
4.5.5. Couts :
Les couts d’implémentation de ce processus sont centrés sur :
 Les dépenses en personnel (salaire, consultant, formation),
 Outils logiciels et support de processus (création de rapport, surveillance),
 Solution logicielle intégrant la gestion des S.L.A (le cout est partagé par plusieurs
processus I.T.I.L),
Toutes ces dépenses doivent être perçues comme un investissement a valeur ajouté
pour l’entreprise et non seulement des frais dans un tableau financier.
4.5.6. Documents et rapports :
Les seuls documents contractuels sont les S.L.A, les O.L.A, les U.C soutenue
par les documents de contrôle de l’efficacité du processus.
4.5.7. Conséquences d’implémentation de la gestion des niveaux de services :
L’implémentation de ce processus engendre les avantages suivants :
 L’amélioration de la communication entre la direction informatique et les clients,

66
  L’élaboration de services alignés sur les besoins définis dans les accords passés avec
les clients,
 Dégager une vision claire des rôles et des responsabilités de chaque partie
contractante,
 L’identification des objectifs spécifiques pour chaque service,
 Suivi permanant grâce aux mesures et aux métriques,
 Identification des points faible du système d’information,
 La concentration des efforts de l’équipe informatique sur les domaines jugés
importants par le métier,
 Améliorer la qualité des services fournis,
 La diminution des situations de rupture de service,
 Permettre l’équilibre du budget informatique (dégager des économies substantielles).
Par contre cette implémentation peut générer les risques suivants :
 Les contrats sont perçus comme un système d’arbitrage des situations conflictuelles,
 La formulation et la rédaction des documents contractuels peuvent être source
d’interprétation et du cout de conflits entre les parties.
4.5.8. Rôles et responsabilités :
Le rôle que doit assumer le responsable du processus est conditionné par le soutient sans
contrainte de la direction informatique ainsi que la jouissance d’une certaine autorité, en guise
de précision :
 La création et le maintien d’un catalogue de service au sein du système d’information,
 Négociation des S.L.A avec les utilisateurs, les O.L.A avec les services informatiques
internes, les U.C avec les fournisseurs externes,
 Une revue annuelle des documents en vue de la validation de l’adéquation
avec le besoin de l’entreprise.
Les compétences nécessaires que doit disposer un tel responsable :
 Une bonne compréhension des services informatiques et les facteurs affectant
la fourniture aux clients,
 Une bonne compréhension du métier de l’entreprise,
 Capacité d’écoute et de synthèse,
 Capacité de communication (orale, écrite),
 Résistance au stress, patience,
 Maitrise des procédés d’analyse et de statistique en vue du reporting.

67
 1 - Etablir la FONCTION (SLM)

Planification Mise en place

2 - Mise en place des SLA

Révision
Catalogue Avant-
de Services
Négociation des SLA, Accord
projet UC et OLA

Revoir et
Revoir le
Auditer le Surveillance Rapport Révision
Processus
SLA

4 - Révision périodique 3 - Gestion du processus

Fig.25 : La gestion des niveaux de services. [16].

4.6. Conclusion :

Sortir d’une gestion archaïque en se dotant d’un centre de service au sens I.T.I.L® à l’échelle
de l’organisation informatique d’une entreprise constitue un changement qualitatif notable
et une mutation importante.
Le chapitre en question a permis de mettre en valeur la synergie qui existe entre
les (04) quatre processus de base étudiés d’une parte et de l’autre part se focaliser aux détails
de leurs conceptions.

68
 Chapitre 05 :
Analyse de l'existant et étude des besoins

69
5.1. Introduction :
L’étude va permettre de mieux connaitre notre existant de maniéré à déterminer
les caractéristiques de l’environnement qui conditionnes le fonctionnement de l’activité
informatique au sein de notre institution et de démystifier au fur et à mesures d’éventuelles
zones d’ombres afin de préparer une base solide à l’étape consacrée pour la spécification
des besoins (cahier des charges technique et fonctionnel) voir point 5.3. Etude des besoins.
Notre démarche va s’accomplir selon la structure proposée :
1- Analyse de l’existant :
 Recensement des contraintes du site,
 Délimitation du périmètre de l’étude,
 Diagnostique approfondis du domaine de l’exploitation.
2- Etude des besoins.
3- Plateforme cible du projet.
4- Recommandations de mise en œuvre du projet.
5.2. Analyse de l’existant :
5.2.1. Recensement des contraintes du site :
En partant du terrain comme base de recensement, plusieurs contraintes ont été identifiées
et qualifiées de persistantes structurées en quatre (04) types les suivants :
Type n° 01 : Les contraintes d’ordres techniques :
Se manifestent par :
 L’absence totale ou partielle des réseaux informatiques câblés : type L.A.N-V.D.I
(Infrastructure physique et logique),
 Le manque en matériel professionnel adéquat : Serveurs dédiés, bais de stockages,
stations de travails, switches managables,…etc.,
 Locaux techniques : aménagement et conditionnement,
 Absence d’une installation électrique de support dédiée à l’infrastructure informatique,
 Manque en plans, schéma techniques, synoptiques (réseau informatique, électrique),
manuels, procédures techniques.
Type n° 02 : Les contraintes d’ordres organisationnels :
Se manifestent par :
 Une organisation pyramidale et fortement hiérarchisée,
 Un fonctionnement statique centré sur la décision,
 Missions et prérogatives limités et dépassés par le temps,

70
  Responsabilités quasiment diluées,
 Une direction (D.G) passive et partiellement impliquée,
 Le manque de perspectives d’évolution concernant le personnel technique,
 Normalisation et certification des activités métiers : projet non adéquat
(métier spécifique),
 Manque dans la délégation des pouvoirs de décision au niveau des structures
régionales (décisions centralisés).
 Un personnel démotivé et mal formé,
Type n° 03 : Les contraintes d’ordres géographiques :
Se manifestent par :
 L’organisation informatique se déploie géographiquement à travers le territoire
national selon les différentes régions : (01) structure centrale à Alger (D.S.I) et (04)
structures régionales : Alger centre, Ouest : Oran, Est : Constantine et à Annaba.
 Pour ce qui est des structures régionales, il est primordial de noter que le tissu
des sociétés de services informatiques spécialisés (support technique) n’est pas très
développé par fois absent et cela en dépit des compétences techniques
(service support fortement établie à Alger).
Type n° 04 : Les contraintes d’ordres juridiques et administratifs et financières
Se manifestent par :
 Adoption du projet de charte informatique par la direction en géstation.
 Approbation des notes d’instruction techniques ou de service au niveau des structures
opérationnelles devient problématique.
 Le caractère administratif prédominant sur la gestion : les communications inter
structures sont assurées exclusivement via le support papier comme le seul moyen
officiel reconnu (document),
Les documents les plus fréquents concernant l’I.T sont structurés comme suit :
Documents techniques :
Demande d’intervention, dossier d’étude conceptuelle, manuel d’utilisation, cahier
des charges techniques,...etc.
Documents de coordination :
Rapport d’activité mensuel, rapport d’intervention (à la demande de la hiérarchie), rapport
de situation sur l’état de l’exploitation du réseau et applicatifs, rapport de panne, spécification
des besoins informatiques, demande de réparation, demande de prestation, demande

71
de formation, demande d’assistance à une expertise externe, P.V de réunion , P.V de suivi
technique, décharge d’équipements, …etc.
Vide législatif marquant en matière de droit informatique : Adaptation en interne des lois
en procédures opérationnelles de gestion (Notes internes, Projet de charte informatique).
Budget d’investissement informatique demeure faible comparé aux budgets des autres
directions, aussi des difficultés de justifier les différentes dépenses (investissement ou autres)
et faire approuver par la (D.G) les budgets informatiques en complet.
5.2.2. Délimitation du périmètre de l’étude :
Le périmètre de l’étude se limite au traitement des aspects liés à :
 La gestion du parc informatique,
 La supervision des ressources informatiques,
 La sécurité informatique,
 L’organisation et les procédures.
5.2.3. Diagnostique approfondis du domaine de l’exploitation :
Notre approche consiste à identifier et poser les vrais problèmes pour chaque aspect
à traiter selon le périmètre de l’étude préétabli.
Ce travail est le fruit de constats effectués sur le terrain (sur le tas) et basé sur l’expérience
capitalisée dans le domaine de l’exploitation représenté comme ce qui suit :
5.2.3.1 La gestion du parc informatique :
Sur le plan matériel la structure globale du parc informatique est constituée d’enivrent :
 280 P.C de bureau,
 200 Imprimantes (laser, matricielle),
 12 Serveurs (tours, rack),
 40 P.C portable : Lap Top,
 Autre matériel d’exploitation : onduleurs, scanners, …etc.

Les points qui caractérisent le niveau de la gestion actuelle du parc informatique

et les défaillances qui existent se manifestent par ce qui suit :
 Une bonne partie de l’administration du parc se fait poste par poste ce qui induit
une charge de travail supplémentaire et un cout de maintenance élevé (en interne),
 L’opération d’inventaire est semi-automatique (faible maitrise) : omissions, erreurs
de désignation,…etc.
 Le manque d’assistance technique externe (contrat de support fournisseur :
maintenance) au niveau des directions régionales,

72
  L’absence d’une gestion complète des licences d’exploitation installées (en service),
 Matériel disponible faiblement exploité (problème d'utilisation / sa juste valeur),
 Certains utilisateurs sont affectés à plusieurs postes de travail ce qui complique
et brouille le suivi,
 Manquement enregistrés dans les opérations liées à la maintenance (pièces
de rechanges d'origine, contrôles programmés, consommable de faible qualité,…etc.),
 Absence d'une maintenance planifiée (programmée),
 Les interventions se font en mode pompier (aucune traçabilité et suivi des incidents),
 Le problème des incidents récurrents (récalcitrants),
 Un retour d’expérience faiblement capitalisé (fracturé),
 Un support informatique repartis (en interne),
 Naissance de support parallèle dans les structures (aucun moyen de control),
 Décalage entre le besoin réel d’exploitation et les spécificités du matériel affecté
(besoin de configuration matérielle type),
 Absence d’un fichier central des fournisseurs agréés et homologués par les pouvoirs
appropriés,
 La maitrise des couts d’exploitation : concept nouveau (gestionnaires informatiques),
 Le suivi de l’amortissement des équipements contrôlé comptablement,
 Cartographie non actualisée du parc informatique global,
 Le manque de structure et d’homogénéité au sein du parc informatique à l’échelle
de l’institution (configurations disparates, plusieurs marques et modèles, plusieurs
fournisseurs, ...etc.).
5.2.3.2. La supervision des ressources informatiques :
Sur le plan de la supervision des ressources, les défaillances sont comme suit:
 La couche de supervision et de contrôle de la disponibilité des ressources
est quasiment absente dans les structures informatiques de l’institution : le manque
de moyens techniques de supervision de base ou de contrôle de l’infrastructure
homologués par les pouvoirs informatiques de l’institution,
 Manque d’études sur l’utilisation des outils et des moyens techniques professionnels
de pointe dédiés spécifiquement à la surveillance des services réseaux
(solution de supervision),….etc.
 Responsabilités des gestionnaires informatiques complètement diluées,
 Structures informatiques repartis géographiquement.

73
5.2.3.3. La sécurité informatique:
En tenant compte de la nature de l’activité que dispose notre institution, l’aspect
sécurité par essence et l’un des piliers de notre exploitation (composante importante
du Système d'information), la situation révélant de la question sécurité est présentée
de la manière suivante :
Les points communs :
 Validation partielle par la direction générale concernant la mise en place
d’une politique de sécurité,
 Absence de structure dédiée uniquement à la sécurité informatique au sein de la D.S.I,
 Recours à la veille technologique en matière de sécurité informatique constitue
une option secondaire,
 Simplicité de la conception de l’architecture sécurité (infrastructure) : constituée
à travers une seule couche défensive (voire Fig.27. Architecture globale
d’interconnexion).
Plus précis encore par domaine de sécurité :
1- La sécurité de l’infrastructure réseau :
La structure globale de l’infrastructure réseau est composé de :
 05 Firewall (Appliance de sécurité, V.P.N type site à site),
 12 Servers matériel (Equipés de licences Windows 2008 server S.T.D Edition 64 bits),
 05 L.A.N (04 L.A.N : Installation domestique : Wifi mode infrastructure, 01 LAN :
totalement câblé).
L’architecture d’interconnexion du réseau F.N.I est conçue selon le model Microsoft à base
de domaines.
Le type d’architecture est parfaitement adapté au contexte de l’exploitation et en adéquation
avec l’organisation et les moyens disponibles.
(Voir Fig.26 : Architecture de déploiement Active Directory).
Le déploiement de la technologie Active directory repose sur une structure pyramidale
de type : Domaine parent-Domaine enfant.
Cette architecture permet notamment de :
 Conférer un certain niveau de disponibilité à l’architecture domaine
(perte d’approbation en cas de coupure de connexion A.D.S.L ou de liaison V.P.N),
 Déléguer les pouvoirs d’administration selon le niveau de gestion informatique,
 Possibilité d'adopter un control d’infrastructure réseau à plusieurs niveaux.

74
La concrétisation de cette infrastructure est opérée par :
 Un plan I.P (S/R) pour chaque site distant,
 Le déploiement de serveurs (principal, secondaire) pour chaque site distant,
 Création de lien V.P.N (architecture en étoile) utilisant une appliance de sécurité
(Firewall – V.P.N) et d'une connexion internet standard (asymétrique),
Voir (Fig.27 : Architecture globale de l’interconnexion du F.N.I).

V.P.N

Serv-DC2 Serv-DC1
D.S.I :Alger
Domaine Racine : fni.loc Intranet F.N.I V.P.N
(S/R: 192.168.16.x)
ServDRC-DC1 ServDRC-DC2
Direction Régionale Centre
Domaine enfant: DRC.fni.loc
V.P.N (S/R: 192.168.16.x)
V.P.N

ServDRO-DC1 ServDRO-DC1 V.P.N

Direction Régionale Oran
Domaine enfant: DRO.fni.loc
(S/R: 192.168.31.x) ServDRA-DC1 ServDRA-DC1
Direction Régionale Annaba
Domaine enfant: DRA.fni.loc
(S/R: 192.168.23.x)

ServDRE-DC1 ServDRE-DC1
Direction Régional Constantine
Domaine enfant: DRE.fni.loc
(S/R: 192.168.25.x)
Fig.26 : Architecture de déploiement des domaines active directory du F.N.I.

WAN: Intranet F.N.I

V.P.N V.P.N

S/R-D.R: Alger,Oran, Constantine, Annaba

S/R-D.S.I-Alger

Fig. 27 : Architecture globale de l’interconnexion du F.N.I.

Les points qui caractérisent le niveau de sécurité et les défaillances sont comme suit :
 Déploiement partiel des mécanismes de contrôle d’accès et d’authentification
pour l’ensemble des postes de travail (Solution Microsoft : Active Directory),

75
  Absence de stratégie globale de gestion des comptes sous domaine (Active Directory),
 Les serveurs utilisés servent qu’à la fonction d’authentification et du service D.H.C.P,
 Autorité de certificat racine (C.A) absente (serveur parent de l’infrastructure A.D),
 Le nommage des machines s’opère par le nom, prénom de l’utilisateur actif,
 Absence d’un serveur de temps en interne (N.T.P),
 Techniques d’isolement des systèmes sensibles non prévus: D.M.Z, Routage,…etc. [9]
 Plan I.P global découpé en sous réseaux plats: S/R structure (16.x, 31.x, 23.x, 25.x),
 L’exploitation réseau se fait partiellement via des infrastructures hybrides à base
de wifi (installations de secours : besoin opérationnel immédiat),
 Liaison V.P.N (type Site à Site) avec la structure centrale s’opère à travers
une connexion internet asymétrique de base (problème de performances),
 Configurations disparates des équipements actifs du réseau notamment les Firewalls,
 Rapport disproportionné entre le degré d’utilisation et le taux de déploiement
des moyens de communications : Mail (@fni.dz, @fni.bis), S.F.T.P,
 Centralisation partielle de la solution antivirale (Kaspersky) à travers les structures,
 Externalisation partielle du système de messagerie (@fni.dz) : dépendance externe,
 Faible redondance au niveau des équipements nodaux de chaque installation réseau,
 Firewall : aucun renforcement par une solution de technologie différente. [9]
 La transmission et synchronisation des données hébergées sur notre Cloud
Privé demande le renforcement obligatoire de la partie W.A.N du réseau intranet.
2- La sécurité de l’exploitation :
Caractérisée par les points (manquements) suivants :
 Absence de plan de reprise d’activité après panne paralysante : P.R.A
(Plan de Reprise d’Activité.),
 Plan de sauvegardes : les sauvegardes de secours (versions de rétention) s’opèrent
manuellement par les équipes informatiques autrement dit : Les jeux de sauvegardes
sont conservés au niveau des structures par les utilisateurs actifs avec des copies
asynchrones au niveau de l’informatique,
 Centralisation des mises à jour et des correctifs de sécurité (manque d’infrastructure
adéquates : serveur de mise à jours Solution Microsoft : WSUS),
3- La sécurité logique et applicative :
Caractérisée par les points (manquements) suivants :
 Applications métiers (applicatif, base de données) installées en mode mono poste,

76
  Manque de sécurité au niveau des applications mono poste (niveau de granularité :
conception de l’architecture applicative),
 Gestion simple des mots de passes et des procédures d’authentifications,
 L’emploi massif des solutions de stockages intermédiaires (disques amovibles, clefs
U.S.B, D.V.D, C.D,…, etc.),
 Détention du support original (livrable) des logiciels de gestion par certains
utilisateurs.
 Données des utilisateurs (documents, supports,….etc.) repartis sur plusieurs postes
de travail (aspect problématique à traiter),
 La confidentialité des données sensibles : le recours à la cryptographie,
la classification des documents utilisés, demeure un objectif lointain,
 Les outils de sécurité mises en service doivent être révisés dans le cadre du projet
de migration vers le Cloud privé (mise en place d’outils natifs de sécurité).
4- La sécurité physique et environnementale :
Caractérisée par les points (manquements) suivants :
 Absence de mécanismes de contrôle d’accès physique aux salles informatiques
et locaux techniques,
 La protection de l’environnement (respect des normes : température, humidité,…etc.),
 Renfoncement de la redondance des équipements critiques (prévoir en priorité cette
mesure au sein du Datacenter),
 Sites de secours (à froid) non encore envisagé,
 Energie : gestion intelligente dédiée (dispensée) aux L.T et autres (Ondulation SMART),
 Absence d’un plan de maintenance préventif (tests périodiques) et curatif
(pièces de rechanges).
5.2.3.4. L’organisation et les procédures :
Au niveau de la fonction informatique le volet organisationnel et procédural se caractérise
par les constats suivants :
 Une fonction informatique centrée essentiellement sur le maintien de l’exploitation
de l’infrastructure en service (occupation au quotidien),
 Absence d’une perception rationnelle du volume de l’activité informatique
à l’échelle globale,
 Absence de procédures de gestion : parc informatique (acquisition, maintenance,
support, …etc.), gestion des sauvegardes,

77
  Absence de procédures de sécurité physique et logique de l’ensemble des ressources
(salles informatiques, locaux techniques, … etc.),
 Problème de répartition des tâches et des objectifs en fonction des effectifs
disponibles,
 L’absence de cartographies : des macros processus par activité et des processus
par fonction,
 Définition d’un profile complet du personnel orienté vers le support informatique,
 Définition des nouvelles missions et prérogatives pour chaque fonction et domaine,
 Faible traçabilité des actions réalisées par chaque intervenant,
 Absence du travail collaboratif : par exemple utilisation des outils type Groupware1,
 Diffusion systématique de l’information de gestion informatique à travers
les structures opérationnelles (recours aux écrits administratifs),
 Aucun processus d’audit informatique n’est mis en place (déroulement régulier basé
sur un calendrier précis).
1. Groupware : Un type de logiciel qui permet à un groupe de personnes de partager des documents
à distance pour favoriser le travail collaboratif.
5.3. Etude des besoins :
Une bonne étude de besoin constitue un paramètre devant conditionner l’orientation
du cahier des charges technique et fonctionnel et ce en fonction des objectifs déjà prédéfinis.
L’architecture des besoins ainsi conçue est structurée selon le schéma suivant :
5.3.1. Besoin d’ordre technique :
Disposer d’un système informatique complet (type solution) comportant les fonctions
et les gestions suivantes :
 La gestion de parc informatique et d’inventaire,
 La gestion des incidents,
 La gestion des problèmes informatiques,
 La supervision du parc informatique,
 La plateforme de messagerie professionnelle (démarche d’intégration),
 Le système d’authentification centralisé (démarche d’intégration).
5.3.2. Besoin d’ordre organisationnel :
 Redéfinir les spécialités, les missions de l’organisation informatique,
 Disposer d’une organisation orientée par domaine de compétence
(Infrastructure, Réseau, Base de données, Sécurité,...etc.),

78
  Disposer d’un référentiel technique de gestion (standard),
 Instaurer plusieurs niveaux de support,
 Fédérer les différents acteurs de l’organisation informatique aux tours des objectifs
(Administrateurs, Chef de projet, Ingénieurs, Techniciens, …, etc.).
5.3.3. Besoin d’ordre matériel :
 Disposer d’un (01) serveur matériel dédiés et hautement configurés hébergés dans
le Datacenter et correctement dimensionné (ou dans un local technique hautement
aménagé spécifique au centre de service informatique),
 Disposer d'un (01) serveur matériel réplique installé dans un site distant
(site de secours),
 Disposer d’une solution technique de stockage en réseau type N.A.S (centralisation).
5.3.4. Besoin d’ordre opérationnel :
1- L’environnement technique de production :
 Disposer de locaux techniques totalement aménagés (climatisation, énergie ondulé
et secourue, isolation thermique, isolation acoustique, mise à la terre, …etc),
 Disposer de liens internet ou de liaisons spécialisés redondantes sur tous les sites
éloignés (de préférence 02 technologies différentes),
2- Elaboration de politiques :
 De sécurité physique et logique,
 De gestion de parc informatique.
5.3.5. Besoin d’ordre managérial :
 Disposer d’une stratégie informatique déclinée en politiques opérationnelles,
 Disposer d’un système de supervision et de control centralisé de l’ensemble
des ressources critiques : interface unifié, authentification type S.S.O,
 Pilotage et mesure des performances : priorité donnée aux activités critiques,
 Disposer d’un outil de pointe pour la gestion des projets informatiques,
 Maitriser et adopter la conduite de changement.
5.4. Plateforme cible du projet :
Afin de lever au pas à pas les contraintes récalcitrantes et les différentes réserves
techniques, notre institution devra se munir progressivement des moyens adéquats constituant
la nouvelle plateforme d’intégration du projet se déclinant comme ce qui suit :
 Disposer d’un budget informatique complètement structuré (Budget d’exploitation /
Budget de fonctionnement / Budget de développement) : permettant de prendre

79
 en charge les besoins opérationnels, les projets informatiques est ce après
une étude complète (orientation et alignements avec les objectifs bisness)
et une validation collégiale (intégrer le métier),
 Disposer de la documentation technique complète des projets précédents (en relation
avec le projet imminent),
 Former les cadres informaticiens à la gestion de projet : méthodologie et outillage,
 Disposer des ressources humaines techniquement les plus qualifiée : Formations
qualifiantes, certifications, recrutements ciblés,…etc.,
 Prévoir des doublures concernant chaque responsable de projet ou dossier,
 Disposer d’un bureau d’étude informatique spécialisé : Accompagnement technique,
 Prévoir au niveau des structures centrales et régionales des installations réseaux
en mode passif complet et actif complet de type L.A.N (Réseau informatique V.D.I)
correctement dimensionnés et reliés à un backbone central prenant en compte
une marge acceptable d’évolutivité future,
 Disposer d’un Datacenter correctement dimensionné au niveau de la centrale
informatique (D.S.I),
 Disposer de liens internet stables ou autre solution d’interconnexion pour chaque
structure distante ou de liaisons spécialisés : selon la criticité de l’exploitation
(s’appuyer sur une étude technique),
 Disposer au préalable d’un site de secours à froid et d’un site de secours à chaud :
espaces réservés en vue d’un aménagement technique complet
(s’appuyer sur une étude technique),
 Motivation professionnelle des cadres concernés par les projets (volet R.H).
5.5. Recommandations de mise en œuvre du projet :
En adéquation avec le périmètre de notre projet et d’après l’étude effectuée les points
(besoins) les plus pertinents et les plus urgents à soulever (en guise de leur prise en charge) :
1- Sur le plan organisationnel et procédural :
 Formations des équipes informatiques au référentiel I.T.I.L® v 3.0 : Fondation,
Practitioner, Manager,
 Concevoir un manuel de procédures informatiques,
 Mise en place d’un dispositif de planification périodique des différents types
de maintenance (préventives/curatives),
 S’appuyer de préférence sur l’assistance et l’expertise externe spécialisé,

80
 Formaliser une politique de gestion de parc informatique à l’échelle entreprise,
 Mettre en place une structure d’audit informatique,
 Faire adopter un projet de charte informatique par la direction générale du F.N.I,
 Séparation entre la décision et l’audit informatique (au niveau de la D.S.I). [22]
2- Sur le plan technique :
 Consolidation de l’architecture réseau en service et amélioration du niveau
de la sécurité,
 La mise en place d’une D.M.Z à travers le déploiement de (02) Firewalls (technologies
différentes) au niveau du backbone central (étudier le cas Datacenter) : Firewall Frontal
(type U.T.M 1), Firewall dorsal (type Applicatif) i.e. protection de la zone interne
par (02) Firewalls. [10]
 Mise en conformité des L.A.N sur chaque site distant,
 Disposer d’une segmentation réseau opérée pour chaque L.A.N et en harmonie avec
l’organisation actuelle de notre institution (niveau 02 : Vlan ou niveau : 03 Routage) :
sécuriser, garantir une performance de qualité (équipement actif). [10]
 Revoir l’architecture et la conception de l’organisation adoptée au sein de l’A.D :
séparation nette de l’aspect physique de l’aspect logique (Convention ou model
de nommage adapté à la norme I.S.O 27001). [26]
 Déploiement complet de l’A.D sur l’ensemble du parc informatique
(accompagnement technique si nécessaire).
 Couche messagerie : Déploiement à travers tous les niveaux de l’organisation.
 Homologation de l’utilisation d’un outil professionnel complet (à travers la charte
informatique) de contrôle à distance pour les taches d’administration courantes
et de support technique du1ierniveau (Exemple : DameWar).
 Utilisation d’une solution logicielle de sécurité et d’optimisation de la gestion
des mots de passes (Homologuée à travers la charte informatique exemple : keePass).

1. U.T.M : Unified threat management, ou U.T.M (en français : gestion unifiée des menaces)
est un terme inventé par Charles Kolodgy du cabinet de conseil I.D.C (International Data Corporation)
en 2004 et utilisé pour décrire des pare-feu réseau qui possèdent de nombreuses fonctionnalités
supplémentaires qui ne sont pas disponibles dans les pare-feu traditionnels.

81
5.6. Conclusion :
L’étude de l’existant à révéler la vétusté des procédures en vigueur et les méthodes
de travail jugées archaïques ce qui explique simplement la difficulté d’opérer des solutions
sur le terrain et d’agir efficacement sur notre organisation.
La remise en cause des pratiques traditionnelles est une étape fondamentale vers une réflexion
approfondis engageant à la fois les aspects liés à l’humain, à l’organisation et à la technique.

Définir avec précision les insuffisances, les contraintes, conduites systématiquement

à un cahier des charges structuré et bien dimensionné.
Préparer les conditions de projet est aussi une phase importante qu’il faut mener
au préalable voire impérativement à la base.
Se focaliser sur les aspects les plus importants concernant le périmètre du projet en question,
est une démarche parfaitement rationnelle permettant la réduction des risques liés à la mise
en œuvre et d’augmenter le niveau d’intégration de la solution envisagée.

82
 Chapitre 06 :
Implémentation de la solution

83
6.1. Introduction :
Le chapitre se consacre entièrement à l’implémentation de la solution et de son adaptation
selon notre contexte. Dans ce chapitre deux parties sont clairement traités à savoir :
 Une partie technique : concerne la préparation de l’environnement de production
et l’installation de la solution cible I.T.S.M. [39]
 Une partie fonctionnelle : concerne le paramétrage avancé de ladite solution.
6.2. Introduction à la solution technique :
G.L.P.I : Acronyme de Gestionnaire Libre de Parc Informatique, une solution de nature
open-source (distribuée sous licence G.P.L) permettant la gestion des services informatiques
(I.T.S.M) et la gestion des services d'assistance (Helpdesk). [33]
G.L.P.I est conçu de maniéré intégrée fonctionnant en mode Full Web renfermant la gestion
de l’ensemble des problématiques liées à la gestion de parc informatique notamment :
 L’inventaire des composantes matérielles ou logicielles,
 L’assistance aux utilisateurs (La fonction helpdesk).
Plus concis encore Glpi permet de proposer des fonctionnalités à forte valeur ajouté à savoir :
 Le service desk (helpdesk, S.L.A.)
 L’inventaire automatisé du parc.
 Le mode multi-entités (Sites/Parcs).
 Télé déploiement. [35]
Gestions suivantes : ressources informatiques, licences, consommables, réservations,
base de connaissances.
6.3. Contexte actuel de l’exploitation :
Caractérisé par les points et les constats suivants :
 L’accès à la solution est en mode complètement centralisé (Serveur applicatif).
 Une seule liaison V.P.N de type site à site partagée par plusieurs applications
(Accès multiples).
 La solution G.L.P.I est installée dans le même serveur d’application destiné
aux solutions métiers et autres applications.
 L’infrastructure réseau câblée est partiellement absente (infrastructure wifi).
 Le backup s’effectue sur le même serveur d’application en mode manuel
(via interface de l’application).
 L’administration à distance du serveur d’application s’opère à travers le client
Windows R.D.P (Remote Desktop Client) via V.P.N.

84
6.4. Choix de la solution :
Le choix repose sur les critères suivants:
 Support communautaire important (développé),
 Solution connue chez les grandes entreprises (constitue un standard de gestion I.T),
 Impact financier nul (solution libre),
 Démarche pleine qualité,
 Solution modulable et rapide à déployer,
 Faible consommation de la bande passante (déploiement optimal en réseau),
 Haute performance,
 Fonctionnalités étendus (conception raffinée, système de plugins),
 Utilisation intuitive (facilité d’interaction avec les interfaces),
 Communication avec divers annuaires existants (ldap, A.D, …etc.),
 Accès en mode full web,
 Sécurité accrue (inspiré du monde Linux, mieux gérée).
6.5. Description technique de la solution :
La réalisation de la solution G.L.P.I utilise et intègre plusieurs technologies web notamment :
 P.H.P : Support de base (Langage),
 MYSQL/ Maria DB : Serveur de base de données,
 Apache : Serveur web,
 H.T.M.L : Pages web,
 CSS : Feuilles de style,
 SLK et PDF : Génération de rapport,
 AJAX : Parties liées à l’interface,
 Un navigateur internet respectueux des standards. [37]
6.5.1. Architecture de la solution :
L’architecture de la solution repose sur les éléments d’infrastructures suivants :
 Un (01) Serveur de production : déployé sous une distribution (dédiée) Linux version
serveur destiné à faire tourner l’application G.L.P.I et le serveur d’inventaire OCSNG,
 Un (01) Serveur Active Directory : utilisé pour l’authentification L.D.A.P,
 Un (01) Serveur de messagerie : mécanisme de notification des utilisateurs (glpi),
 Un (01) Serveur F.T.P : déployé sous une distribution Linux (dédiée) version serveur
utilisé comme solution de backup : Archivage des bases de données MySQL
(glpidb, ocsweb).

85
6.5.2. Environnement de production cible :
Coté solution :
 Un serveur web : Technologie Apache2.4.18.
 Un serveur de bases de donnes : Technologie MySQL version 15.1 Distrib 10.0.29-
MariaDB, for Debian-linux-gnu (x86_64).
 L’application G.L.P.I version 0.90.5.
 Solution serveur OCSNG : OCSNG_UNIX_SERVER-2.2.1.
Coté administration :
Outils installés en ligne de commandes sur le serveur de production et accessible via interface
web notant :
 Open S.S.H : Administration à distance du serveur de production.
 PhpMyAdmin : Administration à distance du serveur de bases de données.
Coté infrastructure :
 Plateforme système (O.S) : Technologie Linux distribution serveur :
Ubuntu Server 16.04.03 L.T.S 64 bits (A.M.D-64).
 Serveur F.T.P (Infra-d‘ appuis) : Technologie Linux distribution serveur :
Ubuntu Server 14.04.05 L.T.S 64 bits (A.M.D-64).
 Serveur d’Annuaire : Technologie Microsoft : A.D Windows Server 2016 STD 64 bits.
6.5.3. Environnement matériel et virtuel:
Afin de pouvoir effectuer notre travail correctement, l’environnement de production cible
est constitué de :
 Un poste physique de travail : type station de travail.
Processeur : Intel Core (I 5.0).
Mémoire vive :08 G.O
Disque : 500 G.B
Système d’exploitation : Windows 7 pro 64 bits.
 Machine virtuelle : VMware Workstation12 Pro.
Note :
Pour le serveur de messagerie nous allons utiliser notre messagerie interne Microsoft (Outlook : @fni.bis).
Les versions des technologies utilisée pour la production sont testées (expérience pratique).
Le recours aux versions les plus stables type (L.T.S : Ubuntu Lent terme supporté), et les plus complètes
en fonctionnalités (éventail de plugins plus étendu et plus riche).
Une démarche de migration (monté en versions : migration mineur) constitue l’une des étapes nécessaires
à une mise en place correcte et progressive de la solution.

86
6.6. Implémentation technique de la solution :
Etape n° 01 : Installation, configuration et préparation de la plate-forme système-serveur :
 Téléchargé l’I.S.O du system serveur disponible sur le site officiel d’Ubuntu,
 Fixer les paramètres de configuration (machine virtuelle : optimisation
des performances),
 Démarrer l’installation manuelle du système (minimale),
 Installation du serveur d’administration à distance (voir Fig.28),
 Configuration de la couche réseau.

Fig. 28 : Installation du serveur d’administration.

Fig. 29 : Accès à distance au serveur Ubuntu.

Note :
La majorité du reste de travail va s’opérer en ligne de commande (à distance) utilisant la console S.S.H
(Utilisation de l’'outil : PuTTy version sous Windows). voir Fig. 29.

87
Adresse I.P : 192.168.31.2
Non de la machine : ubuntu-csit (i.e. centre de service I.T).
Le compte root : Login : servsup
Mots de passe : xxxxxx
 Application des mises à jour et actualisation de la version (après connexion au serveur
en introduisant les informations du compte root correspondant) dont voici les
commandes à faire passer :
# apt-get update
# apt-get upgrade
 Modification du fichier de configuration réseau: /etc/network/interfaces
# auto ens33
# allow-hotplug ens33
# iface ens33 inet static
# address 192.168.31.2
# netmask 255.255.255.0
# gateway 192.168.31.1
# dns-nameservers 8.8.8.8
Tester la prise en charge de la configuration par le système :
# sudo /etc/init.d/networking restart
 Vérification supplémentaire de la configuration concernant la carte réseau
(modification effectuées) :
# ifconfig -a
Note :
Le but de la configuration mode statique c’est de pouvoir disposer d’une administration à distance en utilisant
le client S.S.H en mode sécurisé.
Autre point : connecter le serveur à internet sur le même plan ip pour pouvoir effectuer les opérations
d’installation des paquets nécessaires à l’implémentation de la solution.
Etape n° 02 : Installation de la plate-forme web :
 Installation du serveur web Apache :
# sudo apt-get install apache2apache2-doc
 Installation des packages P.H.P :
# apt-get install php libapache2-mod-php php-mysqlphp-gd
Etape n° 03 : Installation et configuration du serveur de bases de données(Mariadb) :
# apt-get -y install mariadb-server mariadb-client

88
  Sécurisation du serveur :
# mysql_secure_installation
 Paramétrage de la base de données : Se connecter avec l'utilisateur root et lui octroyer tous
les privilèges :
# mysql –u root –p
# grant all on *.* to root@localhost identified by ‘mots de passe_root_Mariadb’;
# flush privileges;
# create database glpidb;
#exit ;
 Installation des modules PERL:
# apt-get install libxml-simple-perl
# apt-get install libio-compress-perl
# apt-get install libc-dev
# apt-get install libdbi-perl
# apt-get install libdbd-mysql-perl
# apt-get install libapache-dbi-perl
# apt-get install libnet-ip-perl
# apt-get install libsoap-lite-perl
Etape n° 04 : Installation du serveur OCS Inventory :
 Téléchargement du paquet d’installation de puis le lien réservé :
#wget https://github.com/OCSInventory-NG/OCSInventory
ocsreports/releases/download/2.2.1/OCSNG_UNIX_SERVER-2.2.1.tar.gz
 Suivi des instructions :
# tar - xzvf OCSNG_UNIX_SERVER-2.2.1.tar.gz
# cd OCSNG_UNIX_SERVER-2.2.1
 Lancement du scripte d’installation :
# ./setup.sh
 Suivre les instructions de l'installation :
# sudocp/etc/apache2/conf-available/z-ocsinventory-server.conf/etc/apache2/sites-
enabled
# sudocp /etc/apache2/conf-available/ocsinventory-reports.conf /etc/apache2/sites-
enabled
 Création des liens symboliques :

89
 # sudo ln -s /etc/apache2/sites-enabled/z-ocsinventory-server.conf
/etc/apache2/sites-enabled/ocsinventory.conf
# sudoln -s /etc/apache2/sites-enabled/ocsinventory-reports.conf
/etc/apache2/sites-enabled/ocsreports.conf
 Redémarrage du serveur Apache (prise en compte des modifications):
# sudo /etc/init.d/apache2 restart
 Modification des lignes (variables) dans les fichiers suivant (Télédeploiment) :
Les fichiers sont : /etc/php/7.0/cli/php.ini et /etc/php/7.0/apache2/php.ini
Les variables à modifier :
memory_limit = 1000M
upload_max_size = 1000M
post_max_size = 1000M
upload_max_filesize = 1000M
max_execution_time = 1200
 Installation du package P.H.P soap :
# apt-get install php-soap
 Redémarrage du serveur Apache:
# sudo /etc/init.d/apache2 restart
Etape n° 05 : Installation de l’application G.L.P.I :
# wget https://github.com/glpi-project/glpi/releases/download/0.90.5/glpi-0.90.5.tar.gz
 Extraction de l’archive :
# tar -xzvfglpi-0.90.5.tar.gz
 Déplacement du fichier dans le dossier /opt :
# sudo cp –r glpi /var/www/html/glpi
 Accord des permissions sur le fichier et le dossier :
# chmod 777 -R /var/www/html/glpi
 Modification du fichier de configuration :
# nano /etc/apache2/apache2.conf
<Directory /var/www/html/glpi>
Options Indexes FollowSymLinks
AllowOverride limit
Requireall granted
</Directory>

90
  Redémarrage du serveur Apache:
# sudo /etc/init.d/apache2 restart
 Accès à glpi depuis le navigateur et suivre le processus d’installation :
http://192.168.31.2/glpi

Fig. 30 : Interface d’accès à la solution glpi.

Suppression du fichier Install : (pour des raisons de sécurité)
# sudo rm -f install.php
Etape n° 06 : Ajout des plugins (ocsinventory,...) dans glpi :
# cd /var/www/html/glpi/plugins
#wget https://github.com/pluginsGLPI/ocsinventoryng/releases/download/1.2.1/glpi-
ocsinventoryng-1.2.1.tar.gz
# tar -xzvf glpi-ocsinventoryng-1.2.1.tar.gz
Etape n° 07 : Installation des interfaces : annuaire, messagerie (paquets: ldap, imap) :
# apt-get install php-ldap
# apt-get install php-imap
Etape n° 08 : Installation de l’outil d’administration des bases de données (PhpMyAdmin) :
# sudo apt-get install phpmyadmin
 La modification des variables dans le fichier php.ini (serveur apache) :
post_max_size = 1000M au lieu de 8M.
upload_max_filesize = 1000M au lieu de 2M.
Note :
Ces modifications sont nécessaires au bon déroulement de l’opération d’importation des bases de données
existantes destinées à l’opération de migration.
Aussi précisant qu’il s’agit d’une procédure de migration en version mineur.

91
Etape n° 09 : Migration des bases de données (glpidb, ocsweb).
1- Importation des bases de données :
Après avoir récupéré manuellement les bases (glpi, ocsweb) à partir de l’ancienne installation.
L’opération d’importation sera assurée en utilisant l’outil d’administration des bases
de données (mode graphique) déjà installé au niveau du serveur.
Il s’agit de l’outil : PhpMyAdmin (Voir Fig.31).

Fig. 31 : Interface d’administration PhpMyAdmin.

 Accéder à PhpMyAdmin depuis l’interface web en tapant l’url suivante :
http://192.168.31.2/phpmyadmin
 Introduisez les informations du compte d’administration du serveur MySQL (root).
 Accéder à l’option d’importation des bases.
 Mettre le chemin d'accès aux bases de données (Option parcourir).
 Exécuter l'importation des bases.
 Attendre la fin de l'opération. (voir Fig.32).

Fig. 32: Importation des bases de données.

92
2- Validation de l'opération de migration (accès via l'interface web) :
 Accéder à Glpi en tapant l’url suivante : http://192.168.31.2/glpi
L'opération de migration se d'éclanche automatiquement,
 Accéder à OcsReports en tapant l’url suivante http://192.168.31.2/ocsreports

Fig. 33 : Interface du serveur OCS Inventory (Serveur).

 Exécuter l'opération de migration (option: exécuter la mise à jour).
 Attendre la de la fin de l’opération. (Voir Fig.34, 35).

Fig. 34 : Migration de la base de données Glpi.

Fig. 35 : Migration de la base de données ocsweb.

93
Etape n° 10 : Mise en place du serveur F.T.P distant (Infrastructure d’appuis) :
O.S : Ubuntu Serveur.
Adresse I.P : 192.168.31.245 (même S/R que le serveur de production).
Nom de la machine : ubuntu-ftp
Serveur ftp doté d’authentification utilisateur.
Compte root Login : mandataire
Mot de passe : xxxxxxx
Installation : voir la procédure technique de mise en place en détail. [40]

Fig. 36 : Accès système au serveur F.T.P.

Note :
Ce serveur va servir de système de backup, très utile dans une situation de défaillance majeur au niveau
du serveur de production, il suffit de remettre le système en service selon le procédé standard et d’effectuer
la restauration des bases de données de production soigneusement sauvegardées.
Le serveur F.T.P remplace temporairement l’inexistence d’une solution de stockage type N.A.S.
6.7. Paramétrage et configurations avancées de la solution :
Notre démarche est déclinée comme suit :
6.7.1. Paramétrage technique :
Les principales configurations à mettre en place sont :
 Notifications : Configuration du suivi par courriel en utilisant notre messagerie interne
(voir Fig. 37,38).
 Authentification via l’annuaire L.D.A.P : Notre solution pointe sur plusieurs annuaires
ldap en adéquation avec le périmètre de gestion (plusieurs entités) et selon la méthode
de déploiement Active Directory utilisée (voir Fig.39).

94
 Fig. 37 : Configuration des notifications Glpi.

Fig. 38 : Réception des messages sous Outlook (@fni.bis).

Fig. 39 : Configuration de la liaison ldap concernant une structure du F.N.I.

95
 Intégration et activation des plugins les plus importants : L’intégration s’opère via
le système (répertoire de plugins voir Fig.40), et l’activation à partir de l’interface
glpi (voir Fig.41) à savoir :
OcsInventory NG : Synchroniser Glpi avec le serveur d'inventaire (OcsNG), composé
d’un script (P.H.P ou Shell) permettant d’automatiser l’import et la mise à jour
des machines. [36]
Plus de rapport : Contient un ensemble de rapports statistiques plus élaborés
et structurés. [36]

Fig. 40 : Répertoire des plugins Glpi.

Fig. 41 : Activation des plugins via interface Glpi.

 Configuration et connexion de glpi à la base ocsweb (voir Fig. 42) :
(Glpi->Outils->OcsInventoryNg->Configuration du serveur OCSNG). [39]

Fig. 42 : Configuration du serveur OCSNG sous Glpi.

96
  Importation des machines et équipements depuis Glpi (voir Fig. 43) :
(Outils->OcsInventoryNg->Importation de nouveaux ordinateurs). [39]

Fig. 43 : Imploration des machines dans Glpi.

Note :
Plusieurs plugins peuvent être rajoutés et activés selon le besoin (Dashboard, P.D.F,….etc.).
(Menu Glpi : Configuration-> Plugins). [39]
6.7.2. Paramétrage fonctionnel :
Les principales configurations à mettre en place concernent les items suivants (Intitulés) :
 Statut des éléments :  Catégorie d’utilisateurs :
Matériel H.G (Hors Garantie). Administrateur-Bases données.
Matériel S.G (Sous Garantie). Administrateur-Réseau.
Matériel proposé à la réforme. Administrateur-Fonctionnel.
Matériel en attente du P.V.R. Technicien-Expérimenté/ Standard.
Matériel réformé. Utilisateur-Avertis/Standard.
Matériel volé.
6.7.2.1. La mise en place du Service desk :
Le système G.L.P.I dans sa configuration de base comporte :
 Les comptes utilisateur : Glpi, Poste only, Normal (simple utilisateur), Tech.
 Profiles associés aux comptes : Super-admin, Admin, Superviseur, Observateur,
Technicien,Hotliner,Post-Only.

97
  Les Entités :
Au niveau de Glpi, le recours à l’utilisation du mode multi-entité permet également
de crée des parois étanches, donc chaque structure ou entité possède sa propre gestion.
 Les groupes utilisateurs : Management, Métier, Soutient, Helpdesk, Messagerie,
Réseau et Systèmes, Sécurité, Maintenance, Data Center, Bases de données , Helpdesk,
ERP, Consultants, Observateurs. ...etc.
 Les catégories des tickets :
Structuré par domaine de compétence (Service : Catalogue proposé) :
Développement, Maintenance, Messagerie, Réseau et Systèmes, Bureautique,
Sécurité, Visioconférence.
 Les catégories des taches :
Décrivant plus en détails les principales actions techniques mémés dans la démarche
de résolution d’un incident donné.
 Types de solutions :
Solution définitive.
Solution de contournement.
Demande de changement.
Transfert de compétence / Formation.
Hors compétences.
Notes :
1- Selon un retour d’expérience la segmentation coté catégories s’opère par domaine de compétence comme
priorité et non par type d’incidents.
2- Les utilisateurs potentiels du système :
Equipe informatique : Selon l’organisation I.T envisagée (I.T.S.M).
Utilisateur standard : Post-Only (Self-service).
3- Les profils des utilisateurs sont repartis en deux catégories :
Orientée vers les clients du service desk.
Destinée aux informaticiens chargés de la gestion de parc et de l’assistance.
4- Chaque groupe d'utilisateurs puise son organisation interne des spécialités techniques nécessaires à couvrir
les différents services proposés (Catalogue de service D.S.I).

98
6.8. Implantation du processus de gestion des incidents :
L’adaptation et la mise en place du processus au niveau de Glpi passe à postériori
par maitriser et cerner les points suivants :
 Classification de la priorisation du traitement des incidents :
1- Incident Majeur :
Service critique : Perte de disponibilité (application métier, paie, comptabilité, accès
au serveur d’application, accès intranet,….etc.) boqués sans solution
de contournement) , perte total du système de messagerie de l’institution , perte total
du lien V.P.N ou du réseau intranet concernant un site ou plusieurs sites , perte total
de la connexion internet (un site ou plusieurs sites), panne matérielle paralysante
(hors service) touchant un des serveurs critique (cas Datacenter), Attaque externe
(sécurité), compromission de log, vole d’information compromettante , corruption
des bases de données,…etc.
2- Incident Très Haute :
Service secondaire : traduit par une perte de performances (Serveur de fichier, solution
antivirus, solution G.E.D, …etc.
Perte partielle de connexion internet (inférieur à 10/05 utilisateurs).
Perte partielle de la messagerie de l’institution : un site (Pb. d’envoi ou de réception).
3- Incident Haute :
Blocage concernant plusieurs utilisateurs (inférieur à 10/05 utilisateurs) dans leurs
taches d’exploitation sans disposer de solution de contournement.
4- Incident Moyen :
Plusieurs utilisateurs standards impactés par la dégradation du service sans blocage
dont (01) utilisateur bloqué.
5- Incident Bas :
Un utilisateur impacté par la dégradation du service exploité sans blocage.
 Délais cibles de traitement des incidents : le tableau suivant peut servir de référence:
Priorité Délais associé
P1 A.S.A.P
P2 A.S.A.P
Haute 4h
Moyenne 12 h (01 J)
Basse 24 h (02 J)
Tableau 3 : Priorités de traitement et délais associés.

99
  Statuts des tickets d’incidents : représentés selon la chronologie du traitement :
Nouveau ticket.
Ticket assigné ou attribué.
Ticket planifié
Ticket en attente de résolution (en cours). Statuts glpi : non modifiables.
Ticket fermé non résolu.
Ticket fermé.
 Evaluation de l’impact d’un incident :
Faible : un seul utilisateur est impacté.
Fort : un service est impacté,
Elevé : plusieurs services ou un V.I.P sont impactés.
 Evaluation de l’urgence d’un incident :
Faible : ralentit son travail,
Fort : perturbe le travail mais l’utilisateur peut faire autre chose,
Elevé : bloque le travail.
 Evaluation de la priorité d’un incident :
En fonction de l’urgence et de l’impact que la priorité attribuée à un incident peut être
déterminée, pour ce faire la conception d’une matrice d’évaluation semble obligatoire
(adaptée à notre contexte) dont voici un exemple vivant (voir Fig. 44).
Les critères d’impact : nombre d’utilisateurs, 03 niveaux.
L’urgence :03 niveaux.

Fig.44 : Matrice de dérivation des priorités. [42]

Pour ce faire,
Etape 0 :
 La configuration matrice des priorités (adaptation à notre contexte) :
Glpi (Configuration ->Générale->Assistance) : Voir Fig. 45.

100
 Fig.45 : Configuration de la matrice d’évaluations de la priorité Glpi.
 Les règles de gestion métiers pour les tickets (voir Fig. 46) :
La configuration de ces règles impacte le fonctionnement du service d’assistance
car sa permet :
1- L’affectation automatique des tickets vers leur support correspondant,
2- L’assignation automatique des S.L.A selon le service sollicité.

Fig.46 : Règles métiers pour les tickets Glpi.

101
Le déroulement complet du processus est matérialisé par les étapes suivantes :
Etape n° 01 : Ouverture d’un ticket d’incident.
La demande de support s’opère en créant un ticket au niveau du système par (02) techniques
1- Accès utilisateur : Système helpdesk glpi (déployé au niveau user).
2- Accès Hotline : Appel téléphonique directe (ex: 11-11) vers le centre de support.
Le ticket est considéré comme nouveau (information statut).
Les informations importantes à renseigner par l’utilisateur (demandeur) sont :
 Le type.
 La catégorie.
 L’urgence.
L’utilisateur peut faire une capture d’écran du message d’erreur et l’attacher au ticket en pièce
jointe puis l’envoyer (pour un meilleur diagnostique).
Note :
La création du ticket est effectuée soit par l’utilisateur (profile : poste only) ou par le hoteliner du centre
de support. Au départ il faut bien faire la différence entre une demande de service et un incident (information
type). L’urgence doit obligatoirement être définie par le demandeur du service (Accès utilisateur).

Fig. 47 : Ouverture d’un ticket d’incident dans Glpi par un utilisateur.

102
Cas n° 01 : Une fois le ticket transmis par le demandeur (Accès utilisateur), au moins
une des règles de gestion métiers s’applique en attribuant automatiquement l’entité helpdesk
de support (proximité utilisateur) au ticket correspondant et actionnant la demande
de validation du ticket par le responsable du helpdesk en question.
Le ticket bascule automatiquement de statut : nouveau->en attente (validation).
Cas n° 02 : Une fois le ticket ajouté par le hotliner, ce dernier peut faire un suivi en vue d’être
pris en charge par un technicien ou un groupe de techniciens.
Etape n° 02 : Statuer sur la validation.
Cas n° 01 : Validation du ticket par le responsable du helpdesk (Accès utilisateur).
En cas de refus, un commentaire sera obligatoirement formulé (case : Commentaire
de validation). A l’issu de cette opération le responsable peut assigner le traitement
de ce ticket à un de ces techniciens.
Cas n° 02 : le ticket n’est pas soumis à validation.

Fig. 48 : Validation du ticket par le responsable du helpdesk.

Etape n° 03 : Consultation et prise en charge du ticket.
Le technicien réserve le droit de consulter et de modifier les informations disponibles selon
la situation notamment :
 Le type.
 La catégorie.
 L’urgence.
Définition de l’impact constaté : bas, moyen, haut, très haut.

103
La priorité est alors recalculée automatiquement en fonction de l’urgence modifiée
et de l’impact constaté.
Cas-01 : S.L.A ne sont pas défini ou assignés automatiquement, ni des règles métiers
actionnées : Le technicien helpdesk a pour mission :
 Attribution d’un observateur, un intervenant ou un groupe d’intervention spécifique.
Cas-02 : S.L.A : Assigné automatiquement.
La prise en charge du ticket ainsi que son évolution suit une procédure d’escalade jusqu’à
résolution probable. Au niveau du S.L.A le groupe observateur est ajouté automatiquement
(dès l’assignation).

Fig. 49 : Prise en charge d’un ticket d’incident dans Glpi.

Notes :
1- L’utilisateur ordinaire (demandeur) peut traduire une perception subjective de l’urgence à consacrer à son
ticket (la plus haute possible). afin de permettre une évaluation objective des différents critères de traitement
ces dernières doivent être discutés et validés avec l’utilisateur en question (dans le cas ou des S.L.A ne sont pas
définis au départ).
2- Dans la situation ou des liens existent entre tickets : (voir : Option Tickets liées).
Le technicien peut rattacher plusieurs tickets à ce nouveau ticket.
Les relations entre les tickets Glpi : liaison ou duplication.
Une liaison (simple) : possède but informatif.
Une duplication : la résolution d'un des tickets, la même solution est définie sur les tickets dupliqués
(qui sont donc automatiquement résolus).

104
Etape n° 04 : Le suivi du ticket :
Correspond aux échanges entre le demandeur et la personne en charge.
Un mail est automatiquement transmis au demandeur le rassurant de l’aboutissement
de sa demande au niveau du centre de support (voir Fig.50).

Fig. 50 : Suivi d’un ticket d’incident.

Etape n° 05 : Ajout des taches au ticket.
Cette action permet de rappeler les taches a effectués et le timing réservé
pour accomplissement.
L’utilisateur ne pourra savoir le détail des taches qui se fond en back office (privé : oui).
Le champ catégorie des taches est déjà configuré (intitulé). (voir Fig.51).

Fig. 51 : Ajout des taches à effectuer ou effectuées.

105
Etape n° 06 : Planification de tâches liées au ticket.
Le système glpi control la disponibilité des intervenants par rapport aux taches planifiées,
un message d’information est généré automatiquement dans ce cas de figure (voir Fig.52).

Fig. 52 : Message d’information Glpi.

Etape n° 07 : Adopter la solution liée au ticket.

Formulation de la solution à adopter de manière claire et précise en indiquant dans quel type
à inscrire afin de pouvoir servir de base pour la résolution des incidents de même nature.
Le statut du ticket est automatiquement basculé vers l’état résolu.

Fig. 53 : Adoption de la solution concernant l’incident.

Etape n° 08 : Clôturer le ticket.
Dans le cas où le ticket est soumis à l’approbation :
 L’état du ticket bascule automatiquement vers le statut clos si la solution
est approuvée.
 L’état du ticket reprend le statut en cours dans la situation contraire.
Note :
Il existe une clôture automatique des tickets à configurer au niveau de glpi : Actions automatiques (close ticket)
tous les 48 h ou les 72 h.

106
 Fig. 54 : Clôture de l’incident.
 Les tickets récurrents :
Sa concerne les tickets émis pour les taches périodiques par exemple : les sauvegardes
des bases de données, le changement des bandes magnétiques, changement de tonner
d’imprimantes,…etc.
6.9. Implémentation du processus de la gestion des problèmes :
Dans le cas ou plusieurs tickets d’incident requière la même solution (incidents répétitifs)
que le problème prend forme (cause) et sera créé sur le système par la personne dument
qualifiée (après sa détection). Dans certains cas il suffit d’un seul incident pour permettre
la détection du problème. La détection, la création et la résolution du problème
se doit conférer à un administrateur (Helpdesk, D.S.I) et non à un utilisateur standard.
A l’issu de la résolution du problème (solution au problème) tous les tickets qui lui sont
rattachés seront automatiquement résolus (partage de la même solution).
A préciser que pas tous les problèmes détectés trouvent une issu (solution).

Fig. 55 : Création de problème Glpi.

107
 Fig. 56 : Tickets liés au problème Glpi.

Note :
La création du problème dans le système se passe de la même manière que la déclaration d’un incident, le plus
important c’est de renseigner et traiter le problème.
6.10. Implémentation du processus de la gestion des niveaux de services :
Glpi permet la création des S.L.A (définir le niveau de service attendu). Le plus courant
concerne les délais (maximum) autorisés pour la résolution des incidents et des demandes,
ou de définir des niveaux d’escalades concernant les incidents non résolus à temps.
Le déclanchement des S.L.A s’actionne lorsque le ticket est pris en charge.
Un S.L.A peut traduire plusieurs niveaux d’escalade (Support I.T : escalade fonctionnelle).
 Le 1ier niveau : concerne les structures opérationnelles sur place (support
de proximité : groupe Helpdesk).
 Le 2iem niveau voir plus : concerne les structures d’assistance centrales (spécialisées).
Si l’incident n’est pas résolu à temps (à travers la procédure d’escalade), l’administrateur peut
également définir le ticket à un niveau d’escalade supérieur (escalade hiérarchique).
Ce sera en général envoyé au C.S.C (Centre de Support Central).
Selon les services sollicités (conçu au niveau du catalogue) certains requièrent des S.L.A
(voir : Fig. 57, 58).
La configuration des S.LA repose sur la maitrise et la configuration des éléments suivants :
 Calendrier : la répartition des horaires de travail au niveau du F.N.I,
 Temps maximum de résolution : l’échéance attribuée au technicien pour résoudre
l’incident,

108
 Critères : défini pour chaque niveau, dans notre cas se baser essentiellement
sur le type, la priorité,
 Actions : les modifications à apporter pour chaque niveau ainsi que les éventuels
rajouts, Plus synthétique voir : Fig. 58, 59,60.

Fig. 57 : S.L.A définis dans Glpi.

Fig. 58 : Configuration du S.L.A (Ex : S.L.A Développement).

109
Fig. 59 : Configuration des niveaux d’escalades (Ex : S.L.A Messagerie).

Fig. 60 : Les tickets d’incidents liés (Ex : S.L.A : Maintenance).

110
6.11. Rapports et statistiques :
Le centre de service dispose d’une vision synthétique sur l’ensemble des interventions
effectuées, des états statistiques et de gestion (exportables : csv, PDF) sont produits
par le système afin de mieux cerner le support, par exemple :
Global: le nombre de tickets, leur durée de prise en charge, de résolution, de clôture
et de traitement total.
Par ticket: les tickets sont agglomérés par demandeur. Le nombre de tickets est affiché
par statut, ainsi que les délais moyens associés aux tickets.
Par caractéristique du matériel: ces données sont des statistiques par matériels
avec un regroupement possible par type, modèle, système d’exploitation, lieu…
Par équipement: les statistiques sont données par matériel ayant un ticket associé.
Glpi renferme plusieurs d’autres états intéressant (plugins de reporting) :
 Ancienneté de traitement des tickets.
 Evolution du nombre de ticket sur la période par statut.
 Nombre de tickets par catégorie et par entité.
 Nombre de tickets ouverts et clôturés.
 Nombre de tickets clôturés par catégorie et par type.
 Répartition des tickets par catégories et sous-catégories…etc. (voir Fig.61,62).

Fig. 61 : Statistiques sur les tickets Glpi.

111
 Fig. 62 : Tableau de bord avancé (Plugin Dashboard).
6.12. La base de connaissances :
La mise en service de cette base sert à atteindre les buts suivants :
Centraliser les connaissances internes à destination des techniciens.
Mettre à la disposition des utilisateurs des informations leurs permettrons de résoudre
les problèmes simples (F.A.Q).
Mettre à la disposition des utilisateurs et des techniciens des documents d’aides
(tutorial, procédure,…etc.). voir Fig. 63.

Fig. 63 : Foire Aux Questions : F.A.Q.

112
6.13. Maintenance de la solution helpdesk :
6.13.1. La Sauvegarde et l’archivage :
Le but essentiel de cette action est de se prémunir contre la perte des données de production
qui peut s’avérer d’une grande criticité pour l’exploitation informatique.
Le backup (sauvegarde) : s’opère selon une politique définie en guise d’exemple :
Sauvegardes régulières des bases de donnes glpi et ocs : définition des intervalles de temps.
But escompté : disposer du passif (modifications effectués, retours arriéré du système,…etc.).
Méthodes de sauvegardes : il existe pour notre cas (02) méthodes.
1-Manuelle : opérés selon la nécessité (volume d’activité) depuis l’interface de l’application.
La fonctionnalité de maintenance est disponible dans Glpi (Administration -> Maintenance),
Les bases seront sauvegardées au format S.Q.L (scripte) ou en format X.M.L.(voir Fig.64)
Une autre manière de faire des sauvegardes manuelles est de procéder en utilisant le système
pour la copie intégrale du répertoire glpi depuis l’emplacement web (serveur apache).
Note :
Au lieu de tout le répertoire glpi, le fichier de configuration et le répertoire des plugins sont important
à sauvegarder (une fois après l’installation ou régulièrement).

Fig. 64 : Sauvegarde manuelle des bases de données Glpi.

113
2- Automatique : Consiste à concevoir et à mettre en place un scripte Shell sous Linux
(Bach : Ubuntu) en s’appuyant sur la fonctionnalité du système d’exploitation permettant
la planification de la tâche (Taches Cron).
Pour des raisons de bonnes pratiques, la création d’un utilisateur spécifique pour
les opérations de sauvegarde (MySQL) est indispensable, afin d’éviter de mentionner
en claire sur notre scripte les mots de passe du compte root de notre serveur MySQL. [41]
Le scripte ainsi conçu est disponible : voire Annexe 01.
Le lancement planifié de l’exécution du scripte s’opère en taches cron : voir Annexe 02.
6.13.2. La fréquence des sauvegardes:
La sauvegarde de production s’opère une seule fois tous les jours (sauvegarde complète).
Le stockage des jeux de sauvegarde se fait en première étape sur le serveur de production
(dossier spécifique) et en second étapes l’archive des bases sera effectuer puis transmis
via le scripte en réseau vers notre serveur F.T.P distant (serveur de sauvegardes, plan
de secours,…etc.). [38]
La consultation des archives sauvegardées en mode graphique (plus commode) se fait
en utilisant un client ftp (WinScp : outils gratuit). Voir Fig.65.
Notes :
1- La planification des sauvegardes s’effectue en dehors des heures de travail : créneaux horaires les moins
chargés pour notre cas la sauvegarde s’effectue à 18h :00.
2- Les sauvegardes peuvent être transférés depuis le serveur F.T.P et les conditionnées sur un autre support
ou les déplacés vers une autre machine sur le réseau selon le besoin.

Fig. 65 : Accès en mode graphique (WinScp).

114
6.13.3. La restauration :
La technique préconisée consiste simplement à restaurer la base de données (glpidb),
Plusieurs méthodes peuvent être utilisées, les plus recommandés sont :
 Méthode 01 : depuis l’interface web de l’application (Administration ->Maintenance :
Restaurer).
 Méthode 02 : en utilisant l’accès directe à l’S.G.B.D via l’outil d’administration
PhpMyAdmin : option d’importation.
6.14. Pistes d’audit Glpi :
Concrètement Glpi inscrit toutes les actions qui se déroulent sur le système (accès, ajout,
modification, suppression,…etc.) via un procédé de journalisation accessible depuis
l’interface d’administration de glpi. (voir Fig.66)

Fig. 66 : Journalisation des actions Glpi.

115
6.15. Recommandations techniques et perspectives :
 Intégrer la solution dans une plate-forme centrale de virtualisation professionnelle telle
que VSphere ou autre solution de Cloud privé (notre cas au niveau du data center :
ne pas investir en serveurs matériels).
 Etudier l’aspect sécurité en complet coté Datacenter.
 Normaliser le parc informatique par des procédures techniques claires tel que la charte
de nommage du matériel, des comptes et des sessions systèmes inspiré de la norme
I.S.O 27001. [26]
 Accompagner la mise en place et le déploiement du helpdesk par des procédures.
 Former les utilisateurs finaux à l’utilisation de l’outil helpdesk déployé.
 Renforcer l’approche ressources humaine dans la gestion des équipes (D.S.I).
6.16. Conclusion :
L’aspect technique de la solution constitue une démarche professionnelle menée
au pas à pas inspirée des pratiques utilisées par les grandes firmes, cela permet inévitablement
un impact positif sur nos techniques et nos méthodes de travail.
Concrètement la révision de notre solution actuelle (installation, configuration,…etc.) dont
la conséquence d’opérer une migration en version permettant la correction des bugs,
l’amélioration des performances, et finalement le renforcement en pratique dans l’utilisation
intensive de l’outil helpdesk glpi-ocsinventory.
L’administrateur en question pourra disposer désormais d’une vue globale et complète de tous
le système informatique de l’institution.
L’un des objectifs de notre projet est simplement créer la possibilité d’exposer une tout autre
approche, une autre manière de faire légèrement différente à ce qui se fait dans notre contexte
d’exploitation d’une part et de l’autre mettre le point sur la nécessité d’installer
une organisation stable et flexible au sein de l’équipe informatique. Concernant les processus
à mettre en place en priorité constituant la base de notre travail accentuée principalement
sur la gestion des incidents et la gestion des problèmes mal maitrisée jusqu’à maintenant
donnant lieu à une adaptation peut productive du model I.T.I.L proposé.
L’implémentation de la couche S.L.A, apporte une gestion prompte des incidents déclarés
et une maitrise solide des délais de traitement ainsi qu’aux démarches
de résolution. Finalement ce mémoire va permettre de mieux cerner les concepts I.T.I.L,
de mieux les appréhendés et de mettre en place une véritable solution de support informatique
mieux gérée.

116
 CONCLUSION GENERALE

Afin d’arriver à offrir le service support selon I.T.I.L® v 3.0, l’outil est considéré comme
le dernier paramètre à mettre en œuvre, autrement dit le produit technique ne dispense
pas de la réflexion qu’il faut entreprendre en amont. La conception et la mise en place
d’un I.T.S.M au sein de notre institution est axée principalement autour des processus,
des personnes et des partenaires. L’adaptation d’I.T.I.L® au contexte du F.N.I demeure
la phase clé vers une implémentation durable et intégrée. Se confronter à un existant statique
révolu et archaïque de par sa gestion et ses méthodes de travail et dont le défi résultant
exprime une volenté de pouvoir reformer de l’intérieur ce qui n’est guère une mission facile.
Se focaliser que sur les processus de base les plus vitales à l’émergence du centre de service
ouvre la voie vers une urbanisation progressive et continue du reste que propose I.T.I.L
le tous est tributaire de la capacité d’absorption de l’organisation, des moyens,
et des possibilités que dispose notre institution. Greffer des processus ciblés au sein
de l’organisation informatique actuelle à constituer un travail non négligeable profitant
de la structure et la conception raffinée qu’offre la solution technique employée.
La phase d’implémentation technique s’est consacrée à intégrer plusieurs technologies
différentes formant ainsi une seule solution ce qui est fort avantageux dans la capitalisation
des connaissances techniques et le renforcement de l’expérience. L’avantage de disposer
du projet data center et du projet E.R.P au sein de l’institution constitue des éléments
importants et un plus qui se rajoute à la démarche d’intégration de la solution.
La conduite du changement constitue un aspect fondamental à traiter lors de cette mutation
essentiellement du coté utilisateur dont l’objectif est de résorber toute résistance, et intégrer
les utilisateurs finaux au projet en inculquant progressivement une culture informatique
de qualité appréciable.
I.T.I.L en termes de la gestion des ressources humaines permet aussi de conserver
un turnover extrêmement faible du personnel technique sans pour autant constituer une excuse
et faire adapter les techniciens du service opération suite à chaque départ. L’idée de base
d’I.T.I.L c’est de conserver en internes la ressource humaine informatique le plus longtemps
possible en leurs offrants des perspectives d’évolution techniques à travers les différents
niveaux d’expertises. Concernant le cas du F.N.I, sa constitue une véritable solution à mettre
en œuvre afin de freiner que possible le phénomène. Finalement la réussite du projet demande
du temps, des efforts personnels continuent renforcés par un engagement indéfectible
de la part de la direction générale de notre institution.

117
 BIBLIOGRAPHIE
Documents et Rapports
1. Statut de la Banque Algérienne de Développement: loi n° 63.165 du 07 mai 1963.
2. Manuel de procédures internes : Réf : M.O.G/D.N/015/95 : Organigramme de la Direction
de l’Organisation et de l’Informatique.
3. Manuel de procédures internes : Réf : M.O.G/N.I/007/96 : Missions de la Direction
de l’Organisation et de l’Informatique et attributions.
4. Manuel de procédures internes : Réf : M.O.G/N.I/012/96 : Missions de la direction
régionale, des services régionaux.
5. Manuel organisation général : Réf : M.O.G/N.I/011/17 : Organigramme de la direction
des systèmes d’information.
6. Rapport : Missions de diagnostic et de recommandations (Système d’information
de la B.A.D).
7. Projet de Plan Stratégique de Modernisation 2011-2015 : Orientations Générales
et Particulières : Réf : F.N.I/D.G/02/15 (version finale : 09-02-2012).
8. Rapport K.D.S : Développement des capacités du Fonds National d’Investissement –
Banque Algérienne de développement : L’amélioration de la compétitivité national.
(Etude de transformation B.A.D en F.N.I. Juin 2010).
9. Rapport d’audit système et dimensionnement de serveurs (DELTALOG)
« Recommandations de sécurité ».
10. Rapport d’audit système et dimensionnement de serveurs (DELTALOG)
« Conseil déploiement réseau ».
11. Rapport annuel 2016 du F.N.I.
12. Gouvernance du système d’information. Problématiques et démarches, Rapports publiés
par le Cigref 2001-2002.
13. Communication sur la refonte du système d’information F.N.I : Conseil de direction
du 01-10-2012.
14. Rapports publiés par le Cigref en 2000-2001 Comment le contrôleur de gestion peut-il
assister le D.S.I.
15. Synthèse Service Manager I.T.I.L (version 1.0) : Service SUPPORT, (http://www.itil.fr).
16. Synthèse Service Manager I.T.I.L (version 1.0) : Service DELIVERY, (http://www.itil.fr).
17. Support de cours : Implémentation de la solution Glpi Gestion du parc informatique
(DELTALOG).

118
 Livres
18. Lebel, P. (2003).Gérer un parc informatique. Éditions Pratiko. 260 pages.
19. Delbrayelle, P.(2004). I.T.I.L v 2 : Historique et présentation générale. 11 pages.
20. Delbrayelle, P. (2011) . Introduction à ITIL v.3.0 et au cycle de vie des services. 16 pages.
21. DUMONT, C. (2007). I.T.I.L pour un service informatique optimal 2 édition. 377 pages.
22. CIGREF. (2002). Gouvernance du système d’information : Problématiques et démarches.
46 pages.
23. Van Bon, J. (2005). Gestion des services informatiques, une introduction basée
sur l’ITIL. 119 pages.
24. Autissier, D. (2008). Mesurer la performance du système d’information : Les baromètres
de la performance. 214 pages.
25. Van Bon, J. (2011). ITIL v 3 Guide de poche. 23 pages.
26. Honan, B. (2010). ISO 27001 in Windows Environment. 312 pages

WEBOGRAPHIE

[27]. Site web officiel de l’institution. Consulté le 02 décembre 2015.

http://www.fni.dz
[28] . Cercle de qualité de Deming. Consulté le 02 décembre 2015.
https://fr.wikipedia.org/wiki/Roue_de_Deming
[29]. Site web I.T.I.L® France gratuit sur I.T.S.M. Consulté le 13 décembre 2015.
http://www.itilfrance.com
[30]. Les principes de base d’I.T.I.L.Consulté le 20 décembre 2015.
https://www.bestpractices-si.fr/publications/etat-de-l-art/les-principes-de-base-d-itil.
[31]. I.T.I.L v3.0 : La gestion du cycle de vie des services. Consulté le 31 janvier 2016.
http://blog.octo.com/itilv3/.
[32]. Etat de l’art I.T.I.L.Consulté le 18 février 2016.
http://www.pytheas.com/fr/content/27-etat-art-qu-est-ce-que-itil.
[33]. Gestion libre du parc informatique. Consulté le 23 avril 2017
https://fr.wikipedia.org/wiki/Gestion_libre_de_parc_informatique.
[34]. La gestion des incidents. Consulté le 27 mai 2017.
http://www.itilfrance.com/index.php?pc=pages/docs/itilv3-04/120-
01.inc&pe=haut_entete_itil2007.inc&pt=La%20gestion%20des%20incidents.
[35]. Site web officiel du projet G.L.P.I. Consulté le 11 juin 2017.
http://glpi-project.org/.

119
[36]. Catalogue des plugins G.L.P.I. Consulté le 18 juin 2017
http://plugins.glpi-project.org/
[37]. Manuel d’utilisation de gestionnaire libre du parc. Consulté le 25 juin 2017.
https://www.google.dz/?gws_rd=cr&ei=GnCcWLr4EY_NaP3Lv8AL#q=manuel+d%2
7utilisation+ glpi.
[38]. La sauvegarde : pourquoi, comment, quand et à quelle fréquence.
Consulté le 23 juillet 2017.
http://www.tomshardware.fr/articles/logiciel-backup-sauvegarde,2-648-2.html
[39]. Inventaire du parc informatique avec OCS/G.L.P.I. Consulté le 30 juillet 2017.
http://www.supinfo.com/articles/single/3578-inventaire-parc-informatique-avec-ocs-
glpi.
[40]. Serveur F.T.P. Consulté le 02 Aout 2017.
https://guide.ubuntu-fr.org/server/ftp-server.html
[41]. Tutoriel de sauvegarde automatisée de bases de données MySQL, compression
en tar.gz et envoi par F.T.P sous Linux Debian). Consulté le 06 Aout 2017.
http://www.xenetis.org/a_28_script_sauvegarde_bases_de_donnees_mysql_compressi
on_tar_gz_envoi_ftp_debian_linux.html
[42]. Priorité des incidents et des niveaux de services de base. Consulté le 19 juillet 2018.
http://docs.octopus-itsm.com/fr/articles/priorites-des-incidents-et-niveaux-de-service-
de-base

120
 I

ANNEXE 01
Scripte de sauvegarde et d’archivage des bases de données (bash : Ubuntu) :
#! /bin/sh
# Emplacement du dossier ou nous allons stocker les bases de données de production en deux étapes
(sauvegarde, archivage) :
dossierlocalsql=/home/backup_mydatabases
dossierlocalarchive=/home/archive_mydatabases
# Configuration SQL LOCAL
backupwd=xxxxxxxxx
# Backup de la base de données :
DATE=`date +%y_%m_%d`
mysqldump -u backup --password=$backupwdglpidb>"$dossierlocalsql/GLPI"_"$DATE.sql";
mysqldump -u backup --password=$backupwdocsweb>"$dossierlocalsql/OCSWEB"_"$DATE.sql";
# Compression des fichiers de la base en tar.gz :
tar -cvzf $dossierlocalarchive/GLPI"_"$DATE.tar.gz -P "$dossierlocalsql/GLPI"_"$DATE.sql";
tar -cvzf $dossierlocalarchive/OCSWEB"_"$DATE.tar.gz -P
"$dossierlocalsql/OCSWEB"_"$DATE.sql";
# Configuration du FTP distant
loginftp=mandataire
passftp=xxxxxxxxxx
hostftp=192.168.31.245
portftp=21
dossierdistantftp=/home/mandataire/archives-databases
dossierlocalsql=/home/backup_mydatabases
# Transfert des bases archivées vers le serveur FTP distant :
ncftpput -u $loginftp -p $passftp -P $portftp -F $hostftp $dossierdistantftp
"$dossierlocalarchive/GLPI"_"$DATE.tar.gz»" ;
ncftpput -u $loginftp -p $passftp -P $portftp -F $hostftp
$dossierdistantftp"$dossierlocalarchive/OCSWEB"_"$DATE.tar.gz" ;
 II
ANNEXE 02

Gestionnaire de taches cron (ubuntu) : Le contenu du fichier crontab.

# Edit this file to introduce tasks to be run by cron.

# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
00 18 * * * /bin/sh /home/backup_myscripts/backup_ftp_mysql.sh
# 00 10 * * * /sbin/shutdown -r now
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dommondow command
 III

GLOSSAIRE
Terme Définition
Active Directory : Solution Microsoft, services centralisés d'identification
A.D et d'authentification à un réseau d'ordinateurs utilisant le système Windows. permet
également l'attribution et l'application de stratégies, l'installation de mises à jour
critiques par les administrateurs.
Le libre Apache H.T.T.P Server (Apache) est un serveur H.T.T.P créé et maintenu au sein
Apache de la fondation Apache. C'est le serveur H.T.T.P le plus populaire du World Wide Web.
distribué selon les termes de la licence Apache.
L’A.D.S.L (de l'anglais Asymmetric Digital Subscriber Line) est une technique
A.D.S.L de communication numérique (couche physique) de la famille xDSL. Elle permet
d'utiliser une ligne téléphonique pour transmettre et recevoir des données numériques
de manière indépendante du service téléphonique conventionnel.
Backbone Le cœur de réseau, littéralement épine dorsale est le cœur de réseau, qui est également
appelé réseau général.
Association loi 1901 créée en 1970, est un réseau de grandes entreprises
et administrations publiques françaises qui se donnent pour mission de réussir
le numérique. Il n’exerce aucune activité lucrative. Le Cigref regroupe à ce jour près
Cigref de 150 grandes entreprises et organismes français de tous les secteurs d'activité (banque,
assurance, énergie, distribution, industrie, services…). représente près
de 85 % du C.A.C 40, et 1/4 de ses membres sont des administrations publiques
(Ministère de l'Intérieur, Ministère des Armées, Caisse des Dépôts, etc.)
« Capability Maturity Model Integration », est un modèle de référence, un ensemble
structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités
des entreprises d'ingénierie.
C.M.M.I a été développé par le Software Engineering Institute de l'université Carnegie-
Mellon, initialement pour appréhender et mesurer la qualité des services rendus
C.M.M.I par les fournisseurs de logiciels informatiques du département de la Défense des États-
Unis (D.o.D). Il est maintenant largement employé par les entreprises d'ingénierie
informatique, les directeurs des systèmes informatiques et les industriels pour évaluer
et améliorer leurs propres développements de produits.
 IV
La configuration management data base (abrégé C.M.D.B), ou base de données
C.M.D.B de gestion de configuration, est une base de données unifiant les composants
d'un système informatique.
« Control Objectives for Information and related Technology », ou « objectifs
de contrôle de l'information et des technologies associées » en français est référentiel
C.O.B.I.T de bonnes pratiques d'audit informatique et de gouvernance des systèmes d'information
d'origine américaine. Au fil des versions successives, il tend à devenir un outil
fédérateur de gouvernance des systèmes d'information en intégrant progressivement
les apports d'autres référentiels tels que I.S.O 9000, I.T.I.L,…etc.
Un Cloud privé est un type d'informatique de Cloud qui offre des avantages similaires
Cloud privé à un Cloud public, notamment en termes d'évolutivité et de libre-service, mais via
une architecture propriétaire. Contrairement aux Cloud publics, qui fournissent
des services à plusieurs entreprises, une seule entreprise exploite un Cloud privé.
Un centre de données ou data center est un site physique sur lequel se trouvent regroupés
des équipements constituants du système d’information de l’entreprise (ordinateurs
Datacenter centraux, serveurs, baies de stockage, équipements réseaux et de télécommunications,
etc.). peut-être interne et/ou externe à l’entreprise, exploité ou non avec le soutien
de prestataires.
D.S.I Direction des Systèmes d’Informations.
D.M.Z Une zone démilitarisée (ou D.M.Z, de l'anglais demilitarized zone) est un sous-réseau
séparé du réseau local et isolé de celui-ci et d'Internet.
« Dynamic Host Configuration Protocol » (D.H.C.P, protocole de configuration
D.H.C.P dynamique des hôtes) est un protocole réseau dont le rôle est d’assurer la configuration
automatique des paramètres IP d’une station, notamment en lui affectant
automatiquement une adresse IP et un masque de sous-réseau.

Le Domain Name System (ou D.N.S, système de noms de domaine) est un service
D.N.S permettant de traduire un nom de domaine en informations de plusieurs types qui y sont
associées, notamment en adresses I.P de la machine portant ce nom.
D.C Contrôleur de domaine (Microsoft Active Directory).
Un logiciel puissant utilisé dans la télémaintenance, permet de gérer les serveurs
DameWar les ordinateurs portables et les ordinateurs de bureau à distance afin de prendre
en charge les utilisateurs finaux.
 V

E.R.P Enterprise Resource Planning, est apparu au début des années 90. Il désignait un système
d’information gérant l’ensemble des fonctions d’une entreprise : Achats, Ventes, Stocks,
Production, Personnel.
Un pare-feu (de l'anglais firewall) est un logiciel et/ou un matériel permettant de faire
Firewall respecter la politique de sécurité du réseau, celle-ci définissant quels sont les types
de communications autorisés sur ce réseau informatique. mesure la prévention
des applications et des paquets.
General Public License :Licence selon laquelle un logiciel doit être diffusé avec ses
G.P.L sources et peut être librement adapté et modifié. La licence est dite contaminante,
puisque tout logiciel désireux d'utiliser tout ou partie d'un logiciel G.P.L existant tombe
lui-même automatiquement sous le coup de la G.P.L.
Un exploitation libre créé en 1983 par Richard Stallman, maintenu par le projet GNU.
G.N.U Son nom est un acronyme récursif qui signifie en anglais « GNU’s Not UNIX »
(littéralement, « GNU n’est pas UNIX »). Il reprend les concepts et le fonctionnement
d’UNIX.
(G.E.D ou en anglais D.M.S pour Document Management System ou E.D.M
pour Electronic Document Management) désigne un procédé informatisé visant
G.E.D à organiser et gérer des informations et des documents électroniques au sein
d'une organisation. Le terme G.E.D désigne également les logiciels permettant
la gestion de ces contenus documentaires.
Organisation internationale de normalisation : est une organisation internationale
non gouvernementale, indépendante, dont les 162 membres sont les organismes
I.S.O nationaux de normalisation. Par ses membres, l’Organisation réunit des experts
qui mettent en commun leurs connaissances pour élaborer des Normes internationales
d’application volontaire, fondées sur le consensus, pertinentes pour le marché, soutenant
l’innovation et apportant des solutions aux enjeux mondiaux.
Une adresse IP (avec IP pour Internet Protocol) est un numéro d'identification
I.P qui est attribué de façon permanente ou provisoire à chaque appareil connecté
à un réseau informatique utilisant l'Internet Protocol. L'adresse IP est à la base
du système d'acheminement (le routage) des messages sur Internet.
I.T.S.M « Information Technology Service Management » est une des bases de l'I.T.I.L.
 VI

IPsec (Internet Protocol Security), défini par l'I.E.T.F comme un cadre de standards
ouverts pour assurer des communications privées et protégées sur des réseaux I.P,
par l'utilisation des services de sécurité cryptographiques, est un ensemble
de protocoles utilisant des algorithmes permettant le transport de données sécurisées sur
un réseau I.P. IPsec se différencie des standards de sécurité antérieurs en n'étant
IPsec pas limité à une seule méthode d'authentification ou d'algorithme et c'est la raison
pour laquelle il est considéré comme un cadre de standards ouverts. De plus, IPsec opère
à la couche réseau (couche 3 du modèle O.S.I) contrairement aux standards antérieurs
qui opéraient à la couche application (couche 7 du modèle O.S.I), ce qui le rend
indépendant des applications, et veut dire que les utilisateurs n'ont pas besoin
de configurer chaque application aux standards IPsec.

KeePass Password Safe est un gestionnaire de mots de passe publié sous G.P.L v2
ou ultérieure (v3, v4, etc.), sauvegarde les mots de passe dans un fichier chiffré appelé
keePass « base de données ». Cette base est accessible avec le mot de passe principal. peut être
accompagné d'une clé sous la forme d'un fichier (dont le suffixe est .key) pour renforcer
la sécurité d'accès au fichier chiffré.
L.A.N est un acronyme anglais qui peut signifier :
Local Area Network, en français réseau local, ce terme désigne un réseau informatique
L.A.N local, qui relie des ordinateurs dans une zone limitée, comme une maison, école,
laboratoire informatique, ou immeuble de bureaux. Par opposition au W.A.N(réseau
étendu).
Light weight Directory Access Protocol (L.D.A.P) est à l'origine un protocole permettant
l'interrogation et la modification des services d'annuaire (une évolution du protocole
D.A.P). Ce protocole repose sur TCP/IP. Cependant évolué pour représenter une norme.
L.D.A.P pour les systèmes d'annuaires, incluant un modèle de données, un modèle de nommage,
un modèle fonctionnel basé sur le protocole L.D.A.P, un modèle de sécurité
et un modèle de réplication. C'est une structure arborescente dont chacun des nœuds
est constitué d'attributs associés à leurs valeurs. L.D.A.P est moins complexe
que le modèle X.500 édicté par l'U.I.T-T.
 VII
Un système de gestion de bases de données relationnelles (S.G.B.D.R). distribué sous
une double licence G.P.L et propriétaire. Faisant partie des logiciels de gestion de base
MySQL de données les plus utilisés au monde, autant par le grand public (applications web
principalement) que par des professionnels, en concurrence avec Oracle, PostgreSQL
et Microsoft SQL Server.
Network Time Protocol (protocole d'heure réseau) ou N.T.P est un protocole
N.T.P qui permet de synchroniser, via un réseau informatique, l'horloge locale d’ordinateurs
sur une référence d'heure.
Un serveur de stockage en réseau, également appelé stockage en réseau NAS, boîtier
de stockage en réseau ou plus simplement N.A.S (de l'anglais Network Attached
N.A.S Storage), est un serveur de fichiers autonome, relié à un réseau dont la principale
fonction est le stockage de données en un volume centralisé pour des clients réseau
hétérogènes.
Modèle O.S.I (de l'anglais Open Systems Interconnection) est un standard
O.S.I de communication, en réseau, de tous les systèmes informatiques. C'est un modèle
de communications entre ordinateurs proposé par l'I.S.O (Organisation Internationale
de Normalisation) qui décrit les fonctionnalités nécessaires à la communication
et l'organisation de ces fonctions.
Un émulateur de terminal doublé d'un client pour les protocoles S.S.H, Telnet, rlogin,
PuTTY et T.C.P brut. Il permet également des connexions directes par liaison série RS-232.
À l'origine disponible uniquement pour Windows, à présent porté sur diverses plates-
formes Unix (et non-officiellement sur d'autres plates-formes).
Request for Change (Transition de service) : Une demande formelle de changement
R.F.C à effectuer. Une R.F.C comporte des détails sur le changement proposé et peut être
enregistrée sur papier ou électroniquement. Le terme RFC est souvent utilisé
à contresens pour signifier enregistrement de changement ou le changement lui-même.
Remote Desktop Protocol (R.D.P) est un protocole qui permet à un utilisateur
de se connecter sur un serveur exécutant Microsoft Terminal. Des clients existent pour
R.D.P la quasi-totalité des versions de Windows, et pour d'autres systèmes d'exploitation,
comme les systèmes GNU/Linux. Le serveur écoute par défaut
sur le port TCP 3389.
 VIII
Le service-level agreement (S.L.A) ou « entente de niveau de service »
est un document qui définit la qualité de service, prestation prescrite entre
S.L.A un fournisseur de service et un client. Autrement dit, s'agit de clauses basées
sur un contrat définissant les objectifs précis attendus et le niveau de service
que souhaite obtenir un client de la part du prestataire et fixe les responsabilités.
S.M.T.P Simple Mail Transfer Protocol.
batch Programme Script Windows executant des commands systems.
Secure Shell (S.S.H) est à la fois un programme informatique et un protocole
de communication sécurisé. Le protocole de connexion impose un échange de clés
S.S.H de chiffrement en début de connexion. Par la suite, tous les segments T.C.P sont
authentifiés et chiffrés. Donc impossible d'utiliser un sniffer pour voir ce que fait
l'utilisateur. Le protocole S.S.H a été conçu avec l'objectif de remplacer les différents
protocoles non chiffrés comme rlogin, telnet, rcp et rsh.
L'authentification unique (en anglais Single Sign-On : S.S.O) est une méthode
S.S.O permettant à un utilisateur d'accéder à plusieurs applications informatiques (ou sites web
sécurisés) en ne procédant qu'à une seule authentification.
Le coût total de possession, ou T.C.O (Total Cost of Ownership) est une estimation
T.C.O des dépenses associées à l'achat, au déploiement, à l'utilisation et au retrait d'un produit
ou d'un équipement.
U.M.L Le Langage de Modélisation Unifié, de l'anglais Unified Modeling Language (UML),
est un langage de modélisation graphique à base de pictogrammes conçu pour fournir
une méthode normalisée pour visualiser la conception d'un système. Il est couramment
utilisé en développement logiciel et en conception orientée objet.
Un système d’exploitation (tel Windows ou MacOs) basé sur Debian G.N.U/Linux
Ubuntu et sponsorisé par la société Canonical.
Ubuntu est une distribution G.N.U/Linux, c’est-à-dire un regroupement de logiciels
libres qui forment un tout cohérent, modulable et adapté à l’utilisateur.
Réseau V.D.I (Voix, Données, Images) est un réseau universel qui permet
V.D.I de transporter la voix (téléphonie), les données (informatiques) et des images
(télévision) à l’intérieur d’une structure (entreprise ou habitation).
 IX

V.L.A.N Un réseau local virtuel, communément appelé V.L.A.N (pour Virtual LAN),
est un réseau informatique logique indépendant. De nombreux VLAN peuvent coexister
sur un même commutateur réseau.
Un réseau privé virtuel, abrégé V.P.N – Virtual Private Network, est un système
permettant de créer un lien direct entre des ordinateurs distants, en isolant ce trafic.
V.P.N On utilise notamment ce terme dans le travail à distance, ainsi que pour l'accès
à des structures de type cloud computing, mais également en matière de services
M.P.L.S.
Une société informatique américaine fondée en 1998, filiale d'E.M.C Corporation depuis
VMware 2004 (racheté par Dell le 7 septembre 2016), qui propose plusieurs produits propriétaires
liés à la virtualisation d'architectures x86. C'est aussi par extension le nom d'une gamme
de logiciels de virtualisation.
vSphere Un logiciel d'infrastructure de Cloud computing de l'éditeur VMware,
c'est un hyperviseur de type 1 (Bare Metal), basé sur l’architecture VMware ESXi.
Le Wi-Fi, aussi orthographié wifi est un ensemble de protocoles de communication sans
fil régis par les normes du groupe IEEE 802.11 (ISO/CEI 8802-11). Un réseau Wi-Fi
Wi-Fi permet de relier par ondes radio plusieurs appareils informatiques (ordinateur, routeur,
smartphone, modem Internet, etc.) au sein d'un réseau informatique a fin de permettre
la transmission de données entre eux.
Wide area network (réseau étendu) ; Par opposition au L.A.N (réseau local).
W.A.N Un réseau informatique ou un réseau de télécommunications couvrant une grande zone
géographique, typiquement à l'échelle d'un pays, d'un continent, ou de la planète entière.
Le plus grand WAN est le réseau Internet.
Windows Server Update Services (WSUS) est un service permettant de distribuer
les mises à jour pour Windows et d'autres applications Microsoft sur les différents
ordinateurs fonctionnant sous Windows au sein d'un parc informatique. WSUS
WSUS est un rôle pour serveur Windows lui permettant ainsi de devenir un serveur de mises
à jour local (ou proxy de mises à jour). Ce serveur télécharge et stocke ponctuellement
l'ensemble des mises à jour disponibles auprès des serveurs Windows Update
de Microsoft et rend possible le contrôle de la diffusion de celles-ci dans le parc.
 X
Un client S.F.T.P graphique pour Windows. utilise S.S.H et est open source.
WinSCP Le protocole S.C.P est également supporté. Le but de ce programme est de permettre
la copie sécurisée de fichiers entre un ordinateur local et un ordinateur distant.