Gestion de La Qualité - ITIL

Introduc)on à ITIL
Gestion de la qualité
La démarche Qualité pour les services informatisés
ITIL
Objec&fs de ce module
• À la fin de cette partie, vous saurez
§ Ce qu’est la qualité des services à partir de cas issus de l’industrie, principalement illustrés
par la qualité des services informatisés.
§ Ce qu’est un processus, un service, un catalogue de services.
§ Quels sont les principaux processus et comment ils sont organisés.
§ Ce qu’est un incident, un problème, une demande.
§ Ce qu’est le processus d’amélioration continue.
• Les exemples sont issus d’ITIL, mais ils n’y sont pas limités et peuvent être
transférés à d’autres secteurs industriels que les services informatiques.
• Ce que nous n’allons pas faire
§ De la gestion de projets.
§ De l’analyse de processus (p.ex. BPMN, UML).
1
Introduction à ITIL
La qualité des systèmes d’information

• Problématique et enjeux
§ Comment assurer un haut niveau de qualité des systèmes d’information?
§ Quels sont les critères pour déterminer la qualité des systèmes d’information?
• Le nombre de pannes?
• La longévité du matériel?
• Les fonctionnalités offertes?
• …
§ Comment éviter les couts
exorbitants liés au
fonctionnement des
systèmes d’information?
§ Dans un contexte de forte
dépendance aux systèmes
d’information, il est
indispensable de définir le
niveau de qualité et les outils
à mettre en place.
Les normes et les standards en informa&que

• Les normes sont des documents qui définissent des exigences, des directives ou des
caractéristiques. Les normes s’adressent à des produits ou des services.
• Une norme a souvent un caractère obligatoire, et va a nécessité une certification.
§ L’ISO n’est pas un organisme de certification, mais de rédaction et de centralisation de
normes.
§ La certification est réalisée par des organismes indépendants.
§ La certification vérifie de manière exhaustive que les termes de la norme sont respectés
• Les standards
§ Attention à la traduction anglo-saxonne.
§ Un standard va s’imposer de facto sur le marché. Un standard répond souvent à des buts
commerciaux. Il est souvent imposé par des industriels.
§ Un standard concerne des produits ou des services, il garantit un certain niveau
d’utilisation de ses produits ou de ses services.
2
Les normes et les standards en informatique

• ISO 9001
§ C’est une norme relative aux systèmes de gestion de la qualité, quel que soit le secteur
d’activité.
• Comprendre les exigences des clients et les atteindre,
• Considérer que les processus doivent amener des résultats et des bénéfices,
• Mesurer l’atteinte de ses résultats et bénéfices à travers des indicateurs de performance, améliorer en
continu les processus.
• ISO 20000
§ C’est une norme internationale de gestion des services informatiques.
• La fourniture des services,
• la gestion des relations,
• la résolution d’incidents et de problèmes,
• le contrôle des changements et des configurations,
• la mise en production.

• Six sigma
§ Concerne la qualité et l’amélioration des processus.
§ La méthode six sigma se base sur les méthodes
• DMAIC: Define, Mesure, Analyse, Improve, Control
• SIPOC: Supplier, Input, Process, Output, Client
• COBIT – Control Objectives for Information and Related Technologies
§ Démarche qui permet l’audit et l’évaluation des services informatiques d’une entreprise,
afin d’en apprécier les performances et la robustesse en terme de sécurité et de
conformité.
3
Les normes et les standards en informatique

• CMMI – Capability Matirity Model Integration
§ Référence pour évaluer le niveau de maturité des activités informatiques.
§ Cinq niveaux de maturité
• Initial,
• reproductible,
• standardisé,
• maîtrisé,
• optimisé.
• Prince2
§ Méthode de conduite de projets.
§ Principes de base
• Un projet est un processus avec un début, mais surtout une fin clairement définie,
• Les projets doivent toujours être maîtrisés pour réussir,
• Il faut tenir compte des changements de l’environnement, car ils influencent le succès du projet,
• La conduite d’un projet est découpée en phases : démarrage, initialisation, exécution, clôture.

• eSCM – Enabled Sourcing Capability Management
§ Modèle pour gérer les étapes des activités de sourcing et de la relation client fournisseurs.
• Lean
§ Méthode pour rechercher la productivité, la performance, la qualité et supprimer les
gaspillages, et cela par l’amélioration continue.
• ITIL
§ Ensemble de bonnes pratiques pour la gestion des services informatiques.
§ Les bonnes pratiques sont des préconisations issues du monde professionnel et qui font
consensus dans un domaine donné.
4
Présentation d’ITIL
• L’augmentation continuelle des besoins de services informatiques, inhérente aux
demandes des clients, internes et externes.
• Les besoins en informatiques génèrent beaucoup de défis (augmentation des couts,
risque sur la productivité, défis d’organisation des outils et des méthodes... )
• Fin des années 1980 et début des années 1990, le gouvernement britannique (OGC)
lance une étude pour connaitre les meilleures pratiques et les pratiques ayant le
plus de réussites pour approcher la gestion des services informatiques.
• Cette étude a produit une série de livres documentant une approche de gestion des
services informatiques.
Présenta&on d’ITIL
• ITIL: Information Technology Infrastructure Library
• C’est une collection de livres qui traitent de l’infrastructure des systèmes
d’information.
• ITIL est basé sur des Best Practices qui vont permettre de travailler plus
efficacement dans les équipes informatiques.
§ Les best practices sont des recommandations pragmatiques qui peuvent être facilement
appliquées.
• C’est un référentiel décrivant un ensemble de processus de gestion en vue de
fournir des services de qualité.
• ITIL est complémentaire à la gestion de projets, à la démarche Lean, à Cobit
10
5
Présentation d’ITIL
• ITIL est une démarche pragma,que.
• ITIL est issu des expériences d’entreprises du secteur privé et du secteur public.
• IniEé en 1988 par l’agence anglaise chargée d’améliorer l’efficacité et la qualité des
services informaEques de l’administraEon de Grande-Bretagne.
• 2011: publicaEon d’ITIL v3
• 2019: PublicaEon d’ITIL 4 – version actuelle.
• ParEes prenantes
§ Propriétaire des livres officiels: Office of Government Office (OCG), c’est le ministère britannique
du Commerce.
§ ITSMF, InformaXon Technology Service Management Forum. Il sélecXonne les bonnes praXques
et les fait évoluer.
§ Les organismes de cerXficaXon EXIN et APMG.
§ Les organismes de formaXon.
§ Les experts et les consultants.
11
Présenta&on d’ITIL
• Principales publications – 5 livres officiels (v3)
§ La stratégie des services,
§ La conception des services,
§ La transition des services,
§ L’exploitation des services,
§ L’amélioration continue des services.
• Les publications complémentaires
§ Un grand nombre de livres et d’articles écrits par des experts.
• Les publications sur Internet
§ Souvent associées à des sites marchands et des bureaux de consultants.
§ www.itsmfi.org.
12
6
Qu’est-ce qu’une bonne pratique ?

• Bonnes pra[ques (Best Prac[ce).
§ Les bonnes praXques désignent un recueil de préconisaXons issues du monde
professionnel et qui suscitent un consensus dans un domaine donné.
§ Les bonnes praXques proviennent du monde des entreprises et non pas d’une entreprise
dominante, comme c’est le cas des standards.
§ Une bonne praXque doit être écrite par un opéraXonnel pour les opéraXonnels.
• Les bonnes pra[ques d’ITIL
§ La démarche ITIL est une sélecXon de bonnes praXques très opéraXonnelles en maXère de
gesXon des services.
§ Elles sont produites par l’OGC, Office of Government Commerce.
§ La démarche ITIL est ouverte et publique.
13
Processus d’amélioration en 7 étapes Amélioration continue des services Mesure des services Rapport sur les services
Conception des services

Gestion de la Gestion du risque
capacité Plan de
Gestion des Rapports de
SLA capacité Gestion de la
niveaux de performance Surveillance et
SLA SLA
Gestion de la Plan de
continuité des
Description Durée
services ajustements
disponibilité services TI
Service
Soutien
Heures
Signature
disponibilité Politiques de Gestion de la
Planification Amélioration Analyse d’impact sécurité sécurité de
d’affaires l’information
Requis
Maintien du SKMS Définition des
Nouveaux requis Disponibilité Requis
catalogue CMIS politiques
projetée de Planification
Capture des requis Plan de
Planification service continuité Stratégies Implémentation
de niveaux de
Technique Affaire Implémentation
1
service
Gestion des Revue et mise à jour Maintien Planification Surveillance
fournisseurs Gestion du Surveillance
des OLA (et UC)
catalogue de
SKMS Implémentation Analyse
Production des SLA services
Stratégies Rapports AMIS
Test, revue et SKMS Contrôle
Définition maintien ISMS
Politiques SKMS Outils de
30%
10%
20% Portée Portefeuille Stratégie des services Déclenchement

découverte
Évaluation de services Gouvernance
10% SKMS Politiques Génération de la stratégie Gestion de la
30% Catalogues
Contrat
de services Création de valeur Actifs stratégiques demande
SKMS
SLA
Publication Définition du marché Approvisionnement
Activités et
Transition des services
Performance et mise à jour Développement de de service
Préparation pour comportements des CAB
l’offre Gestion des actifs
Maintien l’exécution affaires Gestion des
changements et des
configurations
Gestion du Gestion financière Consignation et Planification et
SKMS
Exploitation des services portefeuille de
services
des TI Plans
financiers Librairie
catégorisation identification
Évaluation et Contrôle
Évaluation des des médias CMS
Définition Lun Mar autorisation
services définitifs
Libre-service 27 28 Planification et
Organisation et grille de Rapport d’état CMDB’s
Financement contrôle
Centre de services Analyse responsabilité (RACI) Calendrier des
changements Calendrier des Vérification et Audit
Autorisation Facturation changements Pièces de
Retour sur rechange
Bon de Mesures et rapports Maintien
SKMS Mise en charte l’investissement
travail
Traitement des (ROI-VOI) Gestion des mises en Revue de post-
Modèle de Gestion des licences
Demandes requêtes requêtes
Gestion des production et implémentation
de service correctifs déploiements
Consignation de la Changements
Événements Gestion des urgents
requête Gestion des Planification
et alertes incidents
Gestion des accès problèmes
Modélisation Identification et Plan de
Gestion des Détection et validation et Préparation Planification et soutien de la transition
consignation
événements Automatisation du consignation de tests Stratégie de Préparation de Planification et coordination
Consignation de la Cycles de Soutien et actifs
flux de tâches requête Catégorisation construction et de transition la transition de la transition
Conception Catégorisation
modélisation des Vérification de la tests
Traitement Plans de
événements requête Priorisation Tests et pilotes Validation du Évaluation
Priorisation déploiement
Configuration des
Fermeture Fournir les droits Planification du
service et tests 2
systèmes Soutien initial Planification de
d’accès Analyse et déploiement
diagnostic Descriptifs l’évaluation
Surveillance des Retirer-restreindre Diagnostic
SKMS des mises en Exécution du
Assurance qualité et
systèmes service Effets attendus et
les droits d’accès productions déploiement,
Réponse et 1 Résolution et
Enregistrements
d’incidents
Résolution
transfert, retrait
inattendus du
Maintenir les Politiques de tests changement
fermeture Modèles de groupes et rôles rétablissement Gestion de la Soutien de début de
Enregistrements Fermeture Évaluation de la
requêtes connaissance des vie performance
Révision Fermeture d’erreurs Stratégies de tests
connues
Revue
services Revue de la mise en 2 attendue
SKMS production Niveaux de tests et
Enregistrements Évaluation de la
de problèmes Consignation et modèles de tests
Rôles et performance réelle
approbation
groupes Approche de tests et
Sondage de techniques
Proposition Surveillance Gestion du risque
satisfaction des
d’amélioration
utilisateurs de service Plan de tests et
résultats
Sondages de
satisfaction des clients
Revue de valeur et du
ROI
Rapports d’informations de gestion
et de tendances
Revue de services et
planification des améliorations
Revue de processus et
conformité
Implémentation du plan
de correction 14
Stratégie et plans de
communication
7
15
Quelques références - Livres
16
8
Quelques références
• ITIL by BMC Software
• https://www.bmc.com/blogs/itil-4/
• ITIL Glossaire (Qualiti7)

§ https://qualiti7.com/documents/ (ITIL v3)
• ITIL Poster (Qualiti7)

§ http://qualiti7.com/wp-content/uploads/2011/12/09-Q7-ITIL_2011_Overview-diagram-
français_11012015.pdf
17
ITIL – Une démarche orientée qualité des services
Services et processus
Cycle de vie des services
Maturité des services
18
9
Qu’est-ce qu’un service ?

• Notion de service
§ Un service est un moyen de fournir de la valeur aux clients en facilitant les résultats qu’ils
souhaitent obtenir sans porter toute la responsabilité des couts et des risques.
§ Un service est un engagement de résultats face aux clients.
§ Un service est là pour fournir de la valeur à l’entreprise.
§ Un service est une application qui fonctionne sur une infrastructure
• Avec la documentation,
• Avec la formation adaptée,
• Avec un support et de l'assistance aux utilisateurs mis en place,
• Avec un engagement de résultats.
19

• La culture Qualité de Services au cœur de la démarche ITIL
§ C’est la capacité à produire le service demandé avec le niveau de qualité demandé tout en
maitrisant les couts et les risques:
§ Aligner les services sur les besoins des clients.
§ Définir et améliorer la qualité des services.
§ Maitriser les couts de fourniture des services.
• Pour les systèmes d’information, la culture qualité de services, c'est mettre au cœur
de l'informatique le client et les branches métiers de l'entreprise.
§ Le client peut être interne à l’entreprise ou externe.
20
10

• La gestion de Services
§ Ensemble de fonctions et de processus pour gérer les services tout au long de leur cycle de
vie.
§ La gestion de services, c’est transformer des ressources en valeur.
§ Gérer, c’est planifier, mettre en œuvre, optimiser la fourniture et le support de services.
§ Maintenir l’orientation client dans l’évolution des services et les changements.
§ Se focaliser sur la qualité comme valeur ajoutée.
21
Le cycle de vie des services

Amélioration AmélioraPon
continue des services Conception conPnue des services
des services
Stratégie
de
services
Exploitation Transition
des services des services
AmélioraPon Amélioration
conPnue des services continue des services
22
11
Cycle de vie des services

• Stratégie des services
§ Réflexion sur un service répondant à un besoin des métiers.
• Conception des services
§ Étude des spécifications du service.
• Transition des services
§ Construction et réalisation du service.
• Exploitation des services
§ Production du service.
• Amélioration continue des services
§ Évolution et amélioration.
23
Qu’est-ce qu’un processus ?

Données,
informations,
connaissance
Fournisseurs Activité 1 Résultats

aPendus
Client
AcKvité 2
Activité 3
Contrôle du service et de la qualité
Déclencheur
24
12
Documenter un processus
• Quatre documents définissent le processus, son cycle de vie et son évolution.
§ La définition du processus,
• Le but, le périmètre, les entrées et les sorties, les relations avec les autres processus, la liste des actions,
les acteurs du processus, les indicateurs de performance, les risques, la terminologie.
§ Le logigramme,
• Représentation synthétique des actions et des activités. On peut par exemple utiliser BPMN.
§ la fiche synthèse de performance,
• Les indicateurs dans quatre catégories : progression, conformité, efficacité, efficience.
§ Le plan d’amélioration.
• Un processus à sa vie propre, mais aussi une vie par rapport aux autres processus. L’amélioration vise
aussi l’adaptation.
• Le plan d’action d’amélioration identifie les résultats attendus, les ressources nécessaires, les risques,
les dates de mise en œuvre.
25
Maturité d’un processus

• Objectifs Niveau de Description
maturité
§ Mesurer la capacité de l’organisation à
0 Il n’existe pas de processus.
intégrer l’amélioration continue dans
ses processus. 1 Le processus est ad-hoc, il est mis en
œuvre au cas par cas et sans méthode.
• Échelle d’évaluation – 5 niveaux.
2 Le processus est reproductible. Les
§ Initial
acteurs savent refaire ce qu’ils ont déjà
§ Reproductible fait.
§ Défini 3 Le processus est documenté, formalisé
§ Maitrisé et communiqué.
§ optimisé 4 Le processus est géré, mesuré et suivi.
5 Le processus est optimisé, géré et il

contient des actions d’amélioration
continue.
26
13
Maturité d’un processus

• Comment réaliser une évaluation de la maturité de processus?
• Utilisation de questionnaires – Attention au calibrage des échelles de mesure.

• Visite sur site ou dans l’entreprise.
§ Observations.
§ Analyse de documents.
§ Interviews individuelles ou par groupe.
• Agréger les résultats, faire une analyse, présenter un rapport.
• Faire une présentation aux personnes clés afin de valider les résultats ou de les
corriger.
§ C’est-à-dire faire une restitution.
• Faire un plan d’action (voir PCDA) pour atteindre les niveaux de maturité attendus.
27
Maturité d’un processus Maturity Level - Radar

Score Standard Max
Process 1
La représentaPon graphique permet de 5
montrer:
• Le score, c’est-à-dire le résultat d’un audit 4
ou d’une autoévaluaPon. Process 7 Process 2
3
• Le maximum.
2
• Le niveau à aWeindre, le Goal.
1
Le niveau 3 est généralement considéré 0
comme le niveau des standards externes. Il
est uPlisé lors d’une cerPficaPon. Process 6 Process 3
Process 5 Process 4
28
14
Exemple – Services et Processus

• Représentez le processus « Commander une pizza »
29
Exemple – Services et Processus

• Exemples appliqués à des entreprises de services informatisés
§ OVH, Heroku (cloud computing)
§ Worldline (paiements électroniques)
§ Sibelga, Ores (distribution gaz et électricité)
• Identifiez les services de ces entreprises.
• Identifiez les processus qui assurent des services de qualité dont le client peut être
satisfait.
30
15
Processus
• Un processus est transverse à une organisation, à une entreprise, et même à plusieurs
entreprises.
• L’approche processus n’est pas un modèle d’organisation, mais il fait intervenir
différentes fonctions de l’organisation.
• Idéalement, un processus doit être indépendant des changements d’organisation.
• Chaque processus doit avoir un but clairement identifié et compris de tous.
• Composants d’un processus
§ Contrôles du processus
• Propriétaire du processus, documentation, objectifs, boucle de rétroaction.
§ Les activités
• Description des activités, des rôles, des procédures, des instructions, des métriques et des améliorations.
§ Facilitateur du processus
• Ressources, aptitudes
32
Processus et procédures
• Ne pas confondre !
• Processus
§ Un processus est une suite d’activités interconnectées.
• Procédure
§ Une procédure détaille les tâches d’une activité d’un processus.
§ Elle précise les rôles, leurs responsabilités et les entrées/sorties.
• Mode opératoire
§ Un mode opératoire est lié à un outil.
§ Un mode opératoire est un ensemble de consignes qui s’appliquent à l’exécution d’une
procédure.
33
16
Notion de fonction
• Une fonction est une unité organisationnelle. Elle est responsable de la production
d’un résultat. Elle réalise une ou plusieurs activités dans les processus.
• Une fonction dispose de ses ressources et de ses moyens.
• Quatre fonctions dans ITIL:
§ Le centre de service,
§ La gestion des opérations,
§ La gestion technique,
§ La gestion des applications.
34
No&on de rôle
• Un rôle est un ensemble de responsabilités et de domaine d’autorité attribué à un
certain poste de travail.
• Le rôle est affecté à une personne physique ou à une équipe de personnes.
• Une personne ou une équipe peuvent endosser plusieurs rôles.
• Exemples de rôles différents:

§ Développeur et analyste.
§ Pizzaiolo et caissier.
§ …
35
17
Les acteurs de la démarche Qualité de services

• Les utilisateurs
§ L’utilisateur est la personne qui utilise le service, ce n’est pas celle qui paie pour ce service.
• Les clients
§ Le client est le commanditaire du service. Il donne les instructions relatives aux besoins et au métier.
• Le propriétaire du service
§ Il est responsable de la description du service, il est le représentant du service dans l’organisation.
• Le gestionnaire de service
§ Il est responsable de la définition de la stratégie de mise en œuvre du service.
• Le propriétaire du processus
§ Il est responsable de la description du processus et il est garant de la mise en œuvre.
§ Il est responsable de l’atteinte des résultats du processus.
• Le gestionnaire de processus – Process Manager
§ Il est responsable de faire vivre au quotidien le processus, de le gérer et de le faire évoluer.
36
Exploitation des services

Le Centre de services
Les processus de gestion des opérations
Gestion des événements
Gestion des incidents
Gestion des problèmes
Gestion des requêtes
Gestion des accès
37
18
38
Exploitation des services – Présentation

• Service Operation à Production informatique.
• La phase d’exploitation des services représente la phase de vie des services.
§ Activités de support,
§ Maintenance préventive,
§ Maintenance corrective,
§ Maintenance évolutive.
• Début
§ Dès la mise en production d’un service: à la fin de la période d’acceptation.
• Fin
§ Au retrait du service.
39
19
Exploitation des services

• Mission:
§ Coordonner et réaliser les activités nécessaires à la fourniture des services.
• Objectifs:
§ Assurer que la technologie sait répondre à la fourniture de service.
§ Produire des indicateurs pour la phase d’amélioration continue à optimisation du système
d’information.
§ Stabilisation du système d’information
• Trouver un équilibre entre les visions contradictoires:
Vision mé9er Vision technologique

Stabilité du SI Réactivité du IS
Cout Qualité
40
Exploitation des services – Processus et fonctions

• Gestion des événements.
• Gestion des incidents.
• Gestion des problèmes.
• Exécution des requêtes.
• Gestion des accès.
• Fonction importante de la phase d’exploitation des services

§ Le Centre de Services
• Gestion des incidents.
• Exécution des requêtes.
• Gestion des événements.
41
20
SKMS - Service Knowledge Management System

• Système de gestion des connaissances des services.
• Ensemble d’outils et de bases de données servant à gérer des connaissances, des
informations et des données. Le système de gestion des connaissances des services
inclut le système de gestion des configurations, ainsi que d’autres bases de données
et systèmes d’information. Il inclut des outils pour collecter, stocker, gérer, mettre à
jour, analyser et présenter toutes les connaissances, informations et données dont
un fournisseur de service informatique a besoin pour gérer le cycle de vie complet
des services informatiques.
• www.itilfrance.com
42
Le Centre de Services – Service Desk

• Point de contact unique ou Single Point of Contact (SPOC) entre les utilisateurs et le
département informatique.
• Les utilisateurs n’ont que le Centre de service comme point de contact pour
introduire des requêtes ou pour demander de l’aide.
• Servir les utilisateurs de manière satisfaisante.
§ Répondre aux questions et aux demandes des utilisateurs.
§ Remettre le service dans un état normal le plus rapidement possible (dans les engagements
contractuels).
• Relation bidirectionnelle:
§ Les utilisateurs appellent le Centre de service pour communiquer avec le département
informatique.
§ Le département informatique communique vers les utilisateurs.
43
21
Le Centre de Services
• Mise en place et gestion de 3 niveaux de support aux utilisateurs
§ Niveau 1: Investigation et diagnostic initial.
§ Niveau 2: Résolution d’incidents plus complexes non résolus au niveau 1.
§ Niveau 3: Résolution d’incidents nécessitant des modifications du système d’information.
• Centralisation des informations relatives aux appels des utilisateurs
§ Identifier des incidents et les résoudre,
§ Comprendre comment les utilisateurs utilisent le SI
§ Renseigner le Département informatique sur les expériences utilisateur, les possibilités
d’améliorations.
44
Le Centre de Services
• Le centre d’appel – Call Center.
§ Prendre les appels des utilisateurs
§ Prendre contact avec les utilisateurs.
§ Appels individuels ou en masse
• Le centre d’assistance – Help Desk.
§ Gérer les pannes et les dysfonctionnements remontés par les utilisateurs.
§ Coordination des activités liées aux dépannages.
§ Mode réactif.
• Le centre de service – Service Center ou Service Desk.
§ Ensemble du centre d’assistance et du centre d’appel
§ Activités proactives
45
22
Le Centre de Services – Les activités

• Prise en charge des appels des utilisateurs
§ Téléphone ou email
§ Traçabilité: Ouverture d’un ticket d’appel dans un outil de gestion.
• Enregistrement des informations liées à l’appel de l’utilisateur
§ Identification de l’utilisateur,
§ Objet de la demande, de l’appel.
• Catégorisation,
§ Classement des appels par type: incident ou requête,
§ Service concerné par l’appel.
• Prioritisation
§ Évaluer la priorité de la demande et délai contractuel de réponse.
46
Le Centre de Services – Les activités

• Investigation et diagnostic comme premier niveau de support.
• Répondre aux demandes de l’utilisateur
§ Incident à Restauration du service.
§ Requête à Exécution de cette requête.
• Escalade vers les groupes de support niveau 2 et 3.
• Suivre l’avancement de la demande de l’utilisateur.
• Clôturer les appels en fonction des objectifs atteints.
• Gérer les enquêtes de satisfaction des utilisateurs.
• Mettre à jour la base de connaissance.
47
23
Le Centre de Services – Configuration

• Dimensionnement et type de ressources en fonction
§ Du nombre d’appels, de demandes, de requêtes.
§ Des connaissances et compétences nécessaires.
§ Des périodes de charges, des horaires de service.
§ Des engagements contractuels.
• Types de Centre de services
§ Centre de services local.
§ Centre de services centralisé.
§ Centre de services virtuel.
§ Centre de service qui suit le soleil.
48
Le Centre de Services – Les indicateurs

• Mesure des performances du Centre de Service
• Qualité des indicateurs: Précision et exactitude.
• Exemples d’indicateurs de performance
§ Satisfaction des utilisateurs,
§ Taux de résolution des incidents,
§ Taux de traitement des requêtes,
§ Délais de prise en compte des appels,
§ Délais moyens de résolution d’incidents
§ …
• Exemples d’indicateurs analytiques
§ Répartition par types d’appels,
§ Répartition des appels dans la journée,
§ Répartition par types d’utilisateur, leur site, leur métier
§ …
49
24
Construire des indicateurs

• Indicateurs quantitatifs vs Indicateurs qualitatifs
• La validité d’un indicateur
§ « de quoi l’indicateur est-il l’indicateur? »
• Indicateur S.M.A.R.T.
§ Significatif. Avoir de l’importance, du sens.
§ Mesurable. Mesure fiable et facile.
§ Acceptable. Être compris et accepté par les personnes concernées
§ Responsable. Il doit y a voir une personne responsable de mesurer et de communiquer
l’indicateur.
§ Temporellement défini.
• Identifier des KPI – key performance indicators
§ Ce sont les indicateurs les plus représentatifs. Ils ont une signification globale.
50
Exercice – Indicateurs
• Dans une entreprise de livraison de pizzas à domicile ou à emporter, quels sont les
indicateurs de la qualité du service?
• Décrivez le service.
• Identifier les indicateurs.
• Décrivez comment les rendre SMART et les opérationnaliser.
• Identifier 1 ou 2 indicateurs clés.
51
25
Gestion des événements
52
Qu’est-ce qu’un événement ?

• Un événement est un fait détectable qui arrive sur le système d’exploitation et qui a
une signification pour la gestion des systèmes d’information ou sur la fourniture des
services.
• Un événement est aussi un changement d’état d’un ou plusieurs composants du
système d’information.
• Lors de la détection d’un événement, il n’y a pas obligatoirement de manifestation
visible du côté de l’utilisateur.
• Exemples d’événements:
§ Un utilisateur entre son identifiant et son mot de passe, l’authentification génère un
élément dans le sous-système de journalisation.
§ Un nouveau composant, par exemple un serveur, est installé dans l’infrastructure.
§ Un compte d’accès est effacé, car l’utilisateur a quitté l’entreprise.
53
26
Qu’est-ce qu’un événement ?

• Un événement est:
§ aléatoire,
§ observable et
§ mesurable.
• Des outils de détection et de gestion sont nécessaires pour détecter et gérer les
événements.
• Les outils de gestions doivent garantir l’intégrité des événements détectés et
enregistrés.
• Des interfaces de gestion permettent de piloter le niveau de granularité des
événements enregistrés
54
Types d’événements
• Événement normal
§ Les événements de ce type témoignent d’un fonctionnement normal du SI.
• Événement exception
§ Ce type d’événements indique un fonctionnement anormal du SI.
§ Exemple: le blocage d’un compte d’accès d’un utilisateur qui a entré un certain nombre de mots de
passe incorrects consécutifs.
§ Un événement d’exception peut signifier un incident s’il y a dégradation du niveau de qualité de service.
• Événement d’avertissement
§ Ce type d’événement est inhabituel, mais il ne signifie pas une situation anormale.
§ Exemple: l’approche d’un seuil critique de capacité de stockage
• Événement d’alerte
§ Ce type d’événement indique une situation exceptionnelle.
§ Exemple: un programme a rencontré une erreur qui a causé son arrêt.
§ Toutes les alarmes doivent être acquittées. C’est-à-dire qu’un opérateur doit valider la prise de
connaissance de l’alarme.
55
27
Objectifs de la gestion des événements

• Objectifs:
§ Minimiser le nombre d’incidents.
§ Garantir le niveau de qualité.
• Développer une gestion efficace:
§ Plus la gestion des événements est efficace, moins il y a d’incidents.
§ Analyser les événements.
§ Positionner les seuils d’avertissement et d’alerte.
§ Détecter les précurseurs d’incidents et permettre d’agir anticipativement.
§ Développer une connaissance du fonctionnement du SI.
§ Anticiper la détérioration de la qualité des services du SI.
56
57
28
Qu’est-ce qu’un incident ?

• Qu’est-ce qu’un incident ?
§ C’est une interruption non planifiée du service ou une réduction dans la qualité du service
redu à l’utilisateur.
• Service arrêté ou dégradé, qualité de service diminuée.
• Détection d’un incident
§ Par l’utilisateur qui contacte le Centre de service.
§ Par le processus de gestion des événements grâce à un outil de supervision.
• Un incident est terminé dès que la qualité de service rendu à l’utilisateur est
restaurée.
58
Impact, urgence et priorité

• Impact
§ L’impact est l’effet de l’incident sur le service.
§ Exemple d’indicateurs d’impact:
• Nombre d’utilisateurs bloqués,
• Perte d’exploitation.
• Urgence
§ L’urgence est le temps que le département informatique dispose pour rétablir le service.
§ Exemple d’indicateur d’urgence:
• Le délai d’intervention auprès d’un utilisateur du SI.
• Priorité
§ La priorité est la combinaison de l’impact et de l’urgence à matrice de priorité 3*3
§ Niveau de priorité:
• P1: intervenir immédiatement.
• P2: intervenir dans les x heures de bureau.
• P3: intervenir dans les x jours ouvrables.
59
29
Les incidents majeurs

• Forts impacts sur l’entreprise ou sur ses métiers.
• Priorité plus élevée que P1
• Les incidents majeurs peuvent signifier une situation de crise.
• Mise en place d’une organisation adaptée aux spécificités de l’incident majeur.
• Mise en place d’une communication spécifique à la situation.
• Exemples d’incidents majeurs
§ Piratage des données informatiques, ransonware.
§ Rupture dans une chaine de production.
60

• Deux objectifs principaux:
§ Rétablir le service dans un état normal le plus rapidement possible conformément à
l’accord de niveaux de services (SLA, Service Level Agreement).
• Rétablir le service ne signifie pas trouver une solution, mais remettre le service pour qu’il fonctionne de
nouveau.
• La remise en état d’un service peut se faire sans en comprendre la cause.
§ Minimiser l’impact de l’incident sur les utilisateurs.
• Minimiser les conséquences pour les utilisateurs.
• Maintenir la satisfaction des utilisateurs.
• La gestion des incidents n’a pas pour objectif de trouver les causes des incidents.
• Le Centre de service assure les communications avec les utilisateurs lors de la
gestion des incidents, cependant les techniciens peuvent prendre directement
contact avec les utilisateurs pour collecter des informations, vérifier des solutions …
61
30
http://wiki.octopus-itsm.com/fr/articles/gestion-des-incidents-processus-itilr 62

• Escalades fonctionnelles
§ Le diagnostic ou le rétablissement nécessite des compétences particulières qui doivent
faire intervenir d'autres équipes, d’autres compétences.
• Escalades hiérarchiques
§ Alerter la hiérarchie sur une situation particulière: incidents majeurs, impacts business
importants, manque de ressources et de moyens.
§ Des décisions sont attendues pour débloquer des situations.
63
31
64

• Un problème est une situation où on recherche la cause inconnue à un ou plusieurs
incidents.
• Incidents à traitement immédiat.
• Problème à traitement des causes des incidents.
§ La résolution de problème peut se faire après que l’incident soit clôturé.
• Le traitement du problème peut être différé. Par exemple si les ressources sont
mobilisées pour résoudre un incident.
• L’important est de rétablir le service, plus tard on cherchera les causes des incidents
et les solutions.
65
32

• Erreur connue (Known Error).
§ Une erreur connue est un problème dont on connaît la cause et dont on a identifié une
solution temporaire ou définitive.
§ Dès qu’on a trouvé la cause et une solution, un problème devient une erreur connue.
• Objectifs du processus de gestion des problèmes:
§ Diminuer le nombre d’incidents.
§ Anticiper l’apparition de nouveaux incidents.
§ Minimiser l’impact des incidents en mettant en place des moyens de containement.
§ Optimiser l’efficacité des équipes de supports en mobilisant les bonnes ressources au bon
moment.
66
http://wiki.octopus-itsm.com/fr/articles/gestion-des-problemes-processus-itilr
67
33
Méthode pour trouver les causes de problèmes

• Méthode Ishikawa
§ Méthode graphique des causes à Étude des paramètres qui influent sur les processus.
§ Les 5 M (domaine d’analyse)
• Matière: composants utilisés, …
• Milieu: environnement, lieu de travail, …
• Méthode: procédures, flux d’information, …
• Machine: équipements, systèmes d’information …
• Main d’œuvre: ressources humaines, les compétences, …
• Méthode des 5 Why
§ Trouver le pourquoi du pourquoi jusqu’à 5 niveaux de profondeur.
§ On estime qu’à ce niveau, on a trouvé la ou les causes des problèmes.
68
Ishikawa Diagram
69
34
Ishikawa Diagram
• Les catégories de causes
§ Main d’œuvre, personnel,
§ Matière, matériaux,
§ Méthodes,
§ Milieu, environnement,
§ Matériel, moyens, outils,
§ Mesures et contrôles.
70
Ishikawa Diagram
• Comment procéder?
§ Identifier clairement le problème, l’effet à analyser.
§ Pour chaque catégorie, il faut identifier les causes à faire un inventaire des causes
possibles.
§ Pour chaque cause, identifiez-le pourquoi et le comment.
• Exemple
§ L’accident de la navette Challenger le 28/01/1986
§ Quelques références:
• Vaughan - 1996 - The Challenger launch decision risky technology
• Morel - 2002 - Les décisions absurdes: Sociologie des erreurs radicales et persistantes
71
35
Vocabulaire: Incident/Problème
• Problem Models
§ Mesures prédéfinies pour le traitement de types de problèmes récurrents
• Workaround
§ Un moyen temporaire de contourner un incident, sa réduction ou son élimination, là où une
résolution n'est pas encore disponible
• Known Errors
§ Le diagnostic est complété et un contournement ou une résolution permanente sont connus
• Known Error Database
§ Conserve les erreurs connues dans une base de données; disponible pendant le diagnostic des
incidents et des problèmes
• Resolution
§ Mesures prises pour réparer un incident, un problème ou mettre en œuvre une solution de
contournement
72
Exercice: Incident ou problème ? Trouvez des exemples d’incidents et de

problèmes. Identifiez le lien entre
incident et problème.
Incident Problème
73
36
74

• Répondre à toutes les sollicitations des utilisateurs qui ne sont pas des incidents.
• Orienté vers la relation avec les utilisateurs.
• Une requête est une demande de service de la part d’un utilisateur.
§ Demande d’assistance, de conseil, d’information, de changement standard,
d’approvisionnements en composants standards …
• Une requête est limitée dans le temps, elle a un faible cout, elle est généralement
exécutée par une personne dans des délais courts.
75
37

• Objectifs de la gestion des requêtes:
§ Fournir un canal de communication pour émettre et traiter les demandes des utilisateurs
vers le département informatique.
§ Fournir de l’assistance aux utilisateurs sur l’utilisation des services.
§ Répondre aux demandes d’intervention, d’approvisionnement des utilisateurs.
§ Traiter les plaintes des utilisateurs.
• Exemples de requêtes
§ Vérification des copies de sauvegarde de données, Maintenance d’un équipement réseau,
…
§ Demande de remplacement d’un équipement, demande d’installation d’un programme, …
76

• Le catalogue des requêtes est une liste de requêtes que les utilisateurs peuvent
demander.
§ Requête planifiée,
§ Requête récurrente.
• Tous les jours, toutes les semaines, tous les mois, …
• Les requêtes qui ne sont pas dans le catalogue ne sont pas réalisées.
• Introduire une nouvelle requête consiste à faire une demande de changement.
§ Une demande de changement est un autre processus de ITIL.
77
38
Gestion des accès
78
Gestion des accès et Gestion des identités

• Ne pas confondre!
• Gestion des identités
§ Qui est qui?
§ à gestion des identifiants et des attributs des identités.
• Gestion des accès
§ Qui a accès à quoi?
§ à gestion des permissions et des accès aux ressources.
• Les deux sont très liés, mais ce sont des processus traités séparément.
79
39
Gestion des accès

• Objectifs
§ Assurer que les utilisateurs ont accès aux services dont ils ont besoin.
§ Gérer les accès aux différents services
§ Mesurer et suivre les accès
• Qui a accès à quels service?
• Quand l’utilisateur doit-il avoir accès?
• Principe
§ Gestion des accès en fonction des rôles des utilisateurs dans l’organisation
§ Gestion des accès en fonction d’un ou plusieurs attributs de l’utilisateur
80
Gestion des accès et Gestion des identités

• Critères de qualité de la Gestion des identités
§ L’identifiant est unique.
§ Les informations descriptives des identités sont précises et exactes (à jour).
• Critères de qualité de la Gestion des accès
§ Les utilisateurs ont les accès nécessaires et suffisants pour faire leur travail.
• En d’autres mots, les utilisateurs n’ont pas plus d’accès que ceux qui leur sont nécessaires pour faire
leur travail.
§ Les utilisateurs n’ont pas de droits d’accès mutuellement exclusifs.
• Segregation of duties.
• Exemple: un comptable qui a les accès pour encoder les factures ne devrait pas avoir les accès pour
payer ces factures à risque de détournement ou de fraude.
81
40
Gestion des accès

• La gestion des accès a pour objectif d’assurer que chaque personne dispose des
accès aux ressources dont il a besoin pour faire son travail.
§ Les ressources peuvent appartenir à l’entreprise et elle les gère.
§ Les ressources peuvent être externes à l’entreprise et gérées par des tiers (sous-traitance).
• Elle vise aussi a la sécurité d’accès aux systèmes d’information.
• Le modèle RBAC : Role-Based Access Control
• Le modèle ABAC : Attribute-Based Access Control
82
Gestion des accès – les défis

• « À qui je donne quels accès aujourd’hui? » (who, what, when)
• Le défi de la source autoritaire des identités.
§ Qui dans l’entreprise détient les informations sur les identités des personnes présentes
aujourd’hui?
§ Est-ce que cette personne ou ce service est disposé à partager ces informations?
• Contraintes techniques – la technologie n’est peut-être pas appropriée.
• Contraintes légales et/ou réglementaires – l’accès aux informations n’est pas permis, vie privée, …
• Le défi de la définition des rôles dans l’entreprise
§ Qui a quel rôle? Et quels accès ont besoin ces rôles?
§ Est-ce qu’il y a des rôles mutuellement exclusifs?
• Le défi du processus de contrôle des accès
§ Comment maintenir la cohérence du modèle?
§ Comment détecter des dérives et les corriger?
• Le défi du cout
§ Est-ce qu’il existe un business case positif?
83
41
RBAC: Gestion des accès par les rôles
U1 P1
U2 P2
U3 P3
U1
P1
U2 Profile or Role P2
U3 P3
84
ABAC: Gestion des accès par les attributs

• NIST 800-162 publication
• “ABAC is a logical access control methodology where authorization to perform a set
of operations is determined by evaluating attributes associated with the subject,
object, requested operations, and, in some cases, environmental conditions against
policy, rules, or relationships that describe the allowable operations for a given set
of attributes”.
• http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf
85
42
ABAC Principe
• ABAC is usually implemented to manage accesses in complex environments
§ Frequent and multiple changes.
§ Large number of roles, i.e. more roles than members of the organisation.
• Typical implementations
§ International and multilingual organisations.
§ Large websites
86
La stratégie de services
87
43
88
Les services et la stratégie

• Le déploiement de la stratégie de l’entreprise
§ Quels sont les services qui permettent le déploiement de la stratégie de l’entreprise?
• Les services doivent toujours être alignés sur la stratégie.
• La valeur perçue d’un service par le client, l’utilisateur
§ L’utilité (utility)
• La ou les fonctionnalités offertes par le service.
• Point de vue de l’utilité pour le client – à quoi ça lui sert.
§ La garantie (warranty)
• C’est la garantie, l’engagement, que le service va remplir les exigences de niveau de qualité de service.
• Garantie contractuelle.
89
44
Définir la stratégie informatique

• Définir la politique informatique de l’entreprise, développer une vision du rôle de
l’informatique dans le plan stratégique.
• Quelle est la politique de produits de l’entreprise?
• Quelles sont les ressources clés de l’informatique?
§ Les ressources humaines, les compétences, les savoir-faire.
• Quels sont les budgets de l’informatique?
§ Comment sont décidé les budgets?,
§ Comment sont fixées les priorités?
• Comment est révisée et évaluée la stratégie informatique de l’entreprise?
90
La gestion du portefeuille de service

• Le portefeuille de services est le catalogue, la liste, de l’ensemble des services
proposés par l’informatique à ses utilisateurs et clients.
• Le portefeuille de services se base sur la politique informatique de l’entreprise.
• La direction de l’informatique gère le portefeuille de services en accord avec les
clients internes et externes.
§ Contrats de service
§ SLA – Service Level Agreements
• Les services évoluent en fonction des changements internes, externes, techniques
et organisationnels.
91
45
Gestion de la relation métier

• Satisfaction des branches métiers et du business
§ Enquêtes de satisfaction.
§ Entretiens réguliers avec les représentants du business.
§ Plan d’action et évaluation de l’état d’avancement.
• Concevoir de nouveaux services en accord avec le business
• Produire des cadres fonctionnels et opérationnels sur le long terme.
92
Gestion financière
• Objectif:
§ Comprendre les couts et déduire la valorisation des services informatiques.
§ Gérer les investissements.
• Analyse des couts
§ Opérationnels et de fonctionnement.
§ Projets.
§ Matériel et équipements techniques.
• Gestion des budgets
§ En fonction de la politique informatique.
§ Les budgets sont souvent conséquents en informatique, ils peuvent être prévus sur
plusieurs années.
93
46
Gestion de la demande – Demand Management

• Analyser l’utilisation des services - service consumption
§ Faire des projections de l’évolution de l’utilisation des services
• Optimiser l’utilisation des services
§ Technologique
§ Économique
• Anticiper l’évolution des demandes et des attentes des utilisateurs
• Approche
§ Quels services doivent être offerts?
§ Où doivent-ils être accessibles?
§ Quand doivent-ils être accessibles?
§ Quelles sont les « performances » attendues?
94
Gestion de la demande – Demand Management

• Les clients et les usagers de l’informatique disposent d’un point d’entrée pour introduire
des demandes
• Les demandes sont classées selon leur coût, leurs impacts, leur valeur ajoutée
§ Importantes
§ Moyenne
§ Minime
• C’est un processus
§ Procédure d’introduction d’une nouvelle demande
§ Évaluation et catégorisation de la demande
§ Acceptation ou refus de la demande
§ Évaluation des étapes et des phases nécessaires au traitement de la demande.
§ Développement et implémentation des changements nécessaires
§ Évaluation et clôture de la demande.
95
47
Les outils de la Stratégie de service

• Définir les responsabilités
§ Matrice RACI
§ Mise en œuvre de la matrice RACI
• Établir les activités principales et identifier les personnes ou les groupes de personnes qui sont
impliqués dans la réalisation de ces activités.
• La matrice RACI et sa documentation doivent être validées par un Comité de Directeurs
– Le Comité de Directeurs donne la légitimité et « enforce » les décisions.
• Il faut un consensus large et fort des parties prenantes.
• Il faut s’assurer de la publication et de la bonne compréhension de la matrice RACI et de ses
implications
• La matrice RACI doit être révisée régulièrement:
– Chaque fois qu’il y a un changement important.
– Au moins un fois par an.
• Mettre en œuvre au quotidien
§ La matrice RACI doit servir de guide … sinon elle est inutile!
96
Matrice RACI
• Responsible, Accountable, Consulted, Informed
• Accountable - Approuve
§ C’est la personne qui est comptable, redevable sur l’avancement de l’action.
§ Il n’y a que 1 et 1 seul A par action.
• Responsible – Réalise
§ C’est la ou les personnes qui réalisent l’action.
§ Il y a au moins 1 R par action.
• Consulted
§ La ou les personnes que l’on consulte pour obtenir un avis.
§ La personne qui a demandé un avis doit en tenir compte au mieux.
• Informed
§ La ou les personnes doivent être tenues informées, elles doivent recevoir l’information sur la
réalisation de l’action.
97
48
Matrice RACI– Exemple à compléter

Activités Project Project Business Technical Developper Tester
Sponsor Manager Analyst Architect
Gérer le projet
A R I I I I
Formuler les Exigences du

client I A R C
Faire les spécifications

techniques
Faire l’analyse technique
Ecriture du code
Faire les tests fonctionnels

et d’intégration
98
Exemple
• Toujours documenter les activités.
• Objectifs:
§ Quels sont les objectifs de l’activité ou d’un groupe d’activités?
• Principes:
§ Sur quels principes repose cette activité ou groupe d’activités?
§ Faire référence aux principes fondamentaux et valeurs de l’entreprise.
• P.ex. respect du client, communication rapide et transparente, maximisation des profits, etc.
• Les livrables (output) des activités
§ P.ex. rapports mensuels des interventions auprès des clients, résultats d’enquêtes de
satisfactions, etc.
• Exemple d’une matrice RACI dans le cadre de la gouvernance de cybersécurité d’une
entreprise (slide suivant).
99
49
100
La conception de services
101
50
102
103
51
104
Conception des services

• Une fois la stratégie de service validée, il faut faire le design des services afin de les
intégrer dans l’entreprise:
§ Mettre en place le contexte contractuel
§ Tenir compte des ressources et de la culture de l’entreprise.
• Ressources humaines, connaissances, compétences savoirs et savoir-faire,
• Ressources financières,
• Ressources organisationnelles, collaboratives.
• Le design des services vise à harmoniser les services dans l’organisation, mettre des
priorités, les faire cohabiter
§ Les services ne sont pas isolés, ils fonctionnent ensemble, ils ont de nombreux échanges et
ils dépendent les uns des autres (vue systémique).
105
52
Gestion de fournisseurs
• Identifier les fournisseurs qui participent directement et indirectement aux services
§ P.ex. fournisseurs de connexions Internet, d’électricité
§ P.ex. les équipes de support et fournisseurs de pièces de rechange pour le système
d’information
• Établir des contrats avec les fournisseurs
• Convenir des niveaux de services de ces fournisseurs
§ Temps minimum d’intervention, horaires, …
§ Nombre de personnes disponibles
§ Qualification des personnes disponibles
§ …
106
Gestion des niveaux de service

• Planification des services
§ Quels services sont disponibles quand?
§ Il y a-t-il des astreintes ou des pénalités en cas de non-respect des engagements?
• Service Level Management – SLM
• Service Level Requirement – SLR
§ Déterminer ou convenir des niveaux d’exigence des services (point de vue du client)
• Service Level Agreement – SLA
§ Engagement sur les niveaux de services
§ Il faut établir des critères objectivables et les suivre régulièrement.
• Operating Level Agreement – OLA
§ Engagement sur les niveaux opérationnels
§ Engagement de l’informatique pour atteindre les exigences des SLA
107
53
Gestion du catalogue de service

• Créer un catalogue de services
§ Lister et documenter les services
• Organiser les services
§ Qui fait quoi?
§ Quels services doivent être regroupés?
§ Comment accéder aux services?
• Communiquer le catalogue de services
• Revoir régulièrement le catalogue de services
§ Chaque fois que la situation le requiert (p.ex. gestion du changement dans les projets)
§ Au moins une fois par an.
108
Gestion de la capacité – Capacity Management

• Plusieurs grandeurs techniques doivent être surveillées et leurs évolutions doivent
être anticipées.
• Impact sur les budgets
§ Prévoir les achats futurs
• Achat de nouveaux matériels
• Revente de matériels sous-utilisés ou obsolètes (ou presque)
• Outils du Capacity Manager
§ Statistiques descriptives
§ Modèles prévisionnels linéaires
• Réallocation des ressources
§ En fonction de prévisions
§ En fonction des événements
109
54

• Capacité de stockage
§ Fichiers,
§ Bases de données,
§ Application workspaces
• Capacité de communication
§ Interne
• Réseaux internes
• Réseaux d’entreprise et propriétaires
§ Externes
• Internet
• Avec les systèmes d’information des partenaires
110

• Capacités humaines et organisationnelles
• Capacité de traitement
§ Déterminer le nombre de CPU, la quantité de mémoire RAM
§ Déterminer le nombre de serveurs physiques et virtuels
§ Suivre les besoins en puissance de calcul
• Divers
§ Contrats de licences
§ Contrats de maintenance et de support
111
55
Gestion de la disponibilité – Availability Management

• Faire la distinction entre:
§ Arrêt planifié des services (maintenance)
§ Arrêt non planifié des services (panne, bug, …)
• Facteurs influençant la disponibilité des services
§ La disponibilité des systèmes techniques,
§ La redondance des systèmes techniques,
§ La fiabilité des technologies,
§ La possibilité d’un site de repli,
§ La possibilité d’avoir un mode dégradé,
§ Facteurs humains et organisationnels
• Formation adaptée
• Gestion des ressources humaines
112
Indisponibilité planifiée et indisponibilité non planifiée

• Indisponibilité planifiée
§ Tous les systèmes informatiques doivent être arrêtés pour faire des activités de maintenance,
d’installations de nouveaux programmes ou de nouveaux modules.
§ Certains systèmes sont très stables et les longues périodes sans arrêt ne posent pas de problème.
• Indisponibilité non planifiée
§ Il s’agit d’arrêts qui arrivent de manière imprévue.
• Arrêt total
• Arrêt partiel (p.ex. uniquement le réseau est indisponible)
§ Causes:
• Erreurs humaines,
• Pannes techniques du matériel,
• Plantages de programme (bug),
• Attaques informatiques (p.ex. DoS)
• Désastres physiques (incendie, inondation …)
113
56
Disponibilité exprimée en nombre de 9
114
Paramètre de la disponibilité
115
57
Paramètres de la disponibilité
• MTBF
§ Mean time between failures
§ Le temps moyen entre 2 pannes
• MTTR
§ Mean time to repair
§ Le temps moyen pour effectuer une réparation
• MTTD
§ Mean time to detect
§ Le temps moyen pour détecter une panne
• MTTF
§ Mean time to failure
§ Le temps moyen de bon fonctionnement
116
Gestion de la continuité de service

• La continuité des services, c’est plus que la disponibilité.
• Il y a un lien étroit entre la disponibilité et la continuité.
• Il peut y avoir un mode dégradé qui assure la continuité.
• Objectifs
§ Déterminer les moyens techniques et organisationnels
§ Déterminer les engagements.
117
58
Gestion de la continuité de service

• Disaster Recovery Plan – DRP
§ Plan de reprise en cas de désastre
§ Centré sur le fonctionnement des systèmes informatiques
• Business Continuity Plan
§ Plan de continuité des activités métiers
§ Centré sur les activités de l’entreprise et le lien avec l’informatique
§ Faire un Business Impact Analysis (BIA)
• Prévoir des systèmes de secours en cas de pannes, de détériorations partielles ou
totales
• Prévoir des modes de fonctionnement dégradés pour garder un minimum d’activité
118
DRP – Disaster Recovery Plan

• Se préparer à gérer la disponibilité en cas de désastre majeur.
• Les désastres et les pannes majeures
§ Sur le site
• Explosions, inondations du site,
• Destructions partielles ou totales des infrastructures,
• Blocage des accès.
§ Dans la salle ordinateur (data center)
• Incendies, Inondations
• Vol de matériel
• Dégradations à l’intérieur ou à l’extérieur du local
§ Les pannes d’alimentation
§ Les pannes de la climatisation
§ Coupures de réseau et de télécom
119
59
BCP – Business Continuity Plan

• Analyse des impacts de l’indisponibilité sur les activités de l’entreprise.
§ Business Impact Analysis – BIA
§ C’est une analyse qui doit être actualisée régulièrement
• Préparer le business à réagir en cas de pannes ou d’incidents importants
• Prévoir des répétitions ou entrainements, par exemple tous les 6 mois.
• Lien entre l’informatique opérationnelle et les activités de l’entreprise.
120
Quels moyens techniques pour la continuité?

• Disponibilité basse
§ Temps de restauration: de 2 à 7 jours
§ Matériel disponible pour le remplacement.
• Disponibilité moyenne
§ Temps de restauration: de 1 à 2 jours
§ Systèmes redondants: actifs-passifs (« froid »)
• Disponibilité élevée
§ Temps de restauration: de 4 à 12 heures
§ Systèmes redondants actifs-passifs (« chaud »)
• Disponibilité très élevée
§ Temps de restauration: de 2 à 4 heures
§ Systèmes redondants actifs-actifs
121
60
Réplication sur plusieurs Data Centers

• Plusieurs Data Centers
§ Distance minimale de 5 km. La distance peut atteindre 150 à 300 km, voire plus.
§ Attention: plus a distance est élevée, plus le temps de latence est important
• Réplication en continu des données et des programmes
• Technologie de cluster
§ 2 serveurs ayant chacun leur propre IP Address + 1 adresse commune.
• Ne pas oublier les espaces de bureaux pour les employés qui doivent assurer les
activités essentielles de l’entreprise.
122
Architecture à Haute disponibilité

• Informatique de gestion
§ Systèmes bancaires, e-commerce, e-business, gouvernements …
• Informatique industrielle
§ Système de contrôle et de commande (SCADA)
§ Systèmes aéronautiques, énergie …
• La haute disponibilité concerne uniquement les systèmes d’information critiques,
car les solutions sont très couteuses.
123
61

• Active
§ Il y a 1 seul système d’information. En cas de panne on doit réinstaller un nouveau
système.
• Active-Passive
§ Il y a 2 systèmes d’information, mais seulement 1 est actif, l’autre attend d’être activé.
• Active-Active
§ Les 2 systèmes d’information sont actifs en même temps, le second reprend
automatiquement (cluster)
• Data Center
§ Data Center principal (HQ) et Data Center de secours (DR)
§ On double uniquement les systèmes critiques et tous les autres systèmes nécessaires à leur
fonctionnement
§ On installe quelques bureaux pour pouvoir fonctionner presque normalement.
124

• Système à Haute disponibilité – By design
§ Mainframe
§ HP NonStop
• https://www.hpe.com/be/fr/servers/nonstop.html
§ IBM HACMP (High-Availability Cluster MultiProcessing)
https://www.ibm.com/developerworks/aix/library/au-powerha/index.html125
62
Gestion de la sécurité des services

• Respect des engagements de sécurisation des informations
• Conformité aux normes et aux règlements
§ ISO27002, PCI-DSS
§ GDPR
• Certification de sécurité
§ Processus d’audit et de certification
§ Dans certaines situations, l’entreprise doit fournir un certificat de conformité
• Aux clients, aux fournisseurs, aux parties prenantes.
• Principes de sécurité de l’information
§ Confidentialité
§ Intégrité
§ Disponibilité
126
La transition de services
127
63
128
La transition de services
• La transition de services vise à la mise en place des services selon leur design à la phase
de Conception de service.
• La transition des services vise la gestion du changement qui permet la mise en
exploitation des services.
§ Changements techniques
• Nouvelles technologies à mettre en place
§ Assurance qualité
§ Changements organisationnels
• Réorganisation des équipes
– Implication directe dans la mise en œuvre des services
– Implication indirecte dans la mise en œuvre des services
§ Communication
§ Formation
• Des utilisateurs de services
• Des prestataires de services
129
64
Transition de services
• Identifier les changements
• Identifier les impacts des changements sur le système d’information et les services
• Garantir la qualité des services
• Accepter ou refuser les changements
• Planification des changements
• Mettre à jour la base de connaissance
• Mettre à jour les documentations
130
Change Advisory Board – CAB

• Comité de pilotage des changements
• Groupe interdisciplinaire
§ Composé d’experts et de managers
• Les décisions du CAB doivent être indépendantes et sont souveraines
• Réunions régulières et formelles – CAB Meeting
• Le CAB décide des changements
§ Évalue
§ Accepte
§ Refuse
§ Suit les incidents
§ Maintient le calendrier des changements
131
65
Processus de gestion des

changements
La gestion des changements est un processus

supervisé par le Change Manager. Il est
formalisé et doit être suivi pour toutes
demandes
• Pas d’exceptions.
• Mais on peut gérer les urgences et les cas
particuliers. Par exemple, pour gérer les
incidents et les situations de crise.
132
Gestion des changements
Application de support à la gestion des

changements
133
66
Request For Change – RFC

• RFC: Demande de changement
• Tout changement sur le système d’information de production doit faire l’objet de
RFC.
• Une procédure formelle doit être suivie par les demandeurs pour introduire un RFC.
• Le CAB (Change Advisory Board) évalue les RFC
• RFC Approved
• RFC Denied
134
Les types de demandes de changement

• Changement normal
§ Les demandes de changement normal suivent le processus défini.
• Changement standard
§ Un changement standard est un changement pré-autorisé à risque faible, relativement commun
et qui suit une procédure ou une instruction de travail spécifique.
§ P.ex. création d’un nouvel utilisateur dans le système d’information de production.
• Changement urgent
§ Ce type de changement doit être implémenté dès que possible pour résoudre un incident majeur
ou implémenter un correctif de sécurité.
§ Ce changement est d’une priorité telle qu’il va directement à l’approbation du CAB.
• Le catalogue des demandes de changement
§ Les demandes normales et les demandes standards doivent être décrites dans un catalogue.
§ Il faut maintenir ce catalogue à jour.
135
67
Gestion des changements – Change management

• Introduire les demandes
§ Projets,
§ Corrections de problèmes
§ Maintenance évolutive et maintenance corrective
• Évaluer les demandes de changements
§ Est-ce que la demande respecte la forme (respect des procédures)
§ est-ce que la demande est justifiée (critères nécessaires)
§ Quels sont les impacts estimés? Sont-ils trop « importants »
• Statut des demandes
§ Acceptée sans réserve
§ Acceptée sous conditions
§ Refusés
§ En attente d’informations complémentaires pour mieux évaluer
136
Gestion des changements – Change management

• Tous les changements doivent être planifiés
• Le déploiement doit être documenté
§ Procédure de déploiement
• Mettre à jour la documentation.
• Suivre les incidents qui pourraient être causés par le changement
• Motifs de refus d’implémentation d’un changement, exemples:
§ Tests non conformes
§ Tests insuffisants
§ Procédures de déploiement ou d’implémentation insuffisantes
§ Documentation insuffisante
§ Changement de niveau de risque (p.ex. événement)
§ …
137
68
Planification des changements

• Déterminer la meilleure date pour l’implémentation des changements
• Minimise les risques d’incidents en production
• Évaluer les charges de travail
• Évaluer les effets indésirables (effets de bord des changements et de leur
implémentation)
• Après l’implémentation
§ Mettre à jour le calendrier
§ Suivre les post-implémentations
138
Calendrier des changements

• Calendrier sur 12 à 24 mois
• Produire une vue sur les événements qui peuvent avoir un impact sur la disponibilité des
services
§ Impacts sur le système d’information
§ Impacts sur l’organisation du département informatique
• Reporter les événements externes à l’entreprise
§ Maintenance de la fourniture d’électricité
§ Maintenance des systèmes d’information des partenaires (fournisseurs, clients, …)
• Reporter les événements internes au département informatique
• Reporter les dates clés pour l’entreprise et faire le lien avec les calendriers des autres
départements
§ Périodes de congés, jours fériés
§ Périodes de lancement de nouveaux produits (marketing)
139
69
Calendrier des changements

Exemple de l’application ServiceNow
140
Planification et support de la transition

• Déterminer la stratégie de transition de services
• Déterminer les politiques de transition de services
§ Condition et processus de transition
§ Best Practices
• Déterminer les politiques de déploiement des changements
§ Cycle de vie des changements
§ Cycle de vie des développements et des tests
§ Politique de test et de validation
§ Politique de suivi des implémentations
§ Politique de déploiement en production
…
141
70
Gestion des déploiements

• Qui est responsable de l’implémentation d’un changement?
• Assurer un support adapté
§ Équipes mobilisées pour réagir en cas de problèmes lors du déploiement
• Déterminer le ou les points de non-retour
§ Quand on est arrivé à ce point, il n’est plus possible de faire marche arrière. En cas de
problème, il faut un plan B.
• Vérifier les conditions au démarrage du déploiement
§ Est-ce que toutes les conditions préalables au déploiement sont vérifiées?
§ Backups récents?
§ Communication OK?
§ …
142
Validation et tests
• Assurance qualité des services
• Pas de test, pas de déploiement !
• On ne met jamais en production un changement qui n’a pas été testé complètement
§ Voir la politique de test et de validation des changements
• Des plans de tests doivent être prévus avant d’introduire une demande de
changement.
• Maintenir le Test Catalog
§ Critères d’évaluation des tests
§ Catégories de tests selon les finalités du changement
143
71
Evaluation des changements

• Anticipation des impacts
§ Problèmes prévisibles
• Suivi du pilotage du changement
§ Après le déploiement, il faut vérifier que le changement n’a pas introduit de bug,
§ Si c’est le cas, on analyse les causes des incidents, des changements.
144
Gestion de connaissances
• Mettre à jour les documentations
• Mettre à jour les procédures opérationnelles si elles ont changé
• Publier les release notes
§ Exemple: https://documentation.sips.worldline.com/fr/release-notes/21.1.html
• Faire un rapport de post-implémentation
• Informer le management
• Éventuellement
§ Former les utilisateurs, les ingénieurs, les opérateurs, …
§ Informer les clients, les partenaires, la presse, …
145
72
Configuration Management Database – CMDB

• Inventaire des composants du système d’information
• Inventaire des configurations des composants du système d’information
• Documentation des configurations et des versions
• Cycle de vie des composants
§ Dates de fin de support par les fournisseurs
• Version des composants
§ Firmware version
• Contraintes entre les composants
§ Est-ce que les composants dépendent d’autres composants
• Prévoir un processus de mise à jour régulière de la CMDB
• Assurer autant que possible l’exhaustivité des inventaires
§ Attention aux quantités importantes d’informations!
146
Gestion des actifs – Asset Management

• Objectifs
§ Maintenir et contrôler l'inventaire des composants achetés et utilisés
§ Réduisez le coût d'achat et de gestion des actifs.
§ Gérer le cycle de vie des actifs, de la planification à l'élimination.
§ Respect des normes et réglementations en vigueur.
§ Amélioration des services aux utilisateurs.
§ Gérer les processus de gestion des composants.
147
73
Gestion des configurations – Config Management

• Asset et Configuration Items (CI)
§ Un CI est un élément de configuration
• Physique (p.ex. un élément de hardware)
• Logique (p.ex. une instance de base de donnée)
• Logiciel (p.ex. un web service)
§ Un asset est composé de un ou plusieurs CI
§ P.ex. un serveur bien identifié (asset) est composé d’une unité centrale, de disques de
stockage, de composants de télécommunication, etc.
• Les configurations sont stockées dans la CMDB
148
CMDB
Pour alimenter la CMDB, on fait appel à des

outils de discovery qui identifient
automatiquement les composants sur le
réseau.
149
74
Amélioration continue
Principe
Méthodologie
150
Amélioration continue – Principe et objectifs

• Améliorer et maintenir la qualité
§ du niveau des services,
§ du niveau de support aux utilisateurs.
• Amélioration continue
§ Amélioration planifiée, mais pas forcément en continu.
§ Cela implique que du temps et des ressources doivent être planifiés pour les activités de
revue et de consolidation.
151
75
Amélioration continue – Principe et objectifs

• Objectif
§ Alignement du système d’information sur les besoins des métiers de l’entreprise.
• Mettre en valeur la qualité comme facteur clé pour atteindre et maintenir le niveau
de qualité des services.
• Mesurer le niveau actuel de la qualité des services et la comparer avec les niveaux
attendus et contractualisés.
152
La roue de Deming – PDCA

§Planifier §Identifier les solutions
§Analyser §Les mettre en œuvre et
§Comprendre les causes les implémenter
Plan Do
Act Check
§Implémenter §Vérifier les résultats
la solution, la généraliser §Mesurer les
§Recommencer améliorations
§Évaluer
153
76
La roue de Deming – PDCA

• Approche progressive et cyclique de l’amélioration ou du changement.
§ Les approches de type « big bang » ne donnent pas souvent de bons résultats dans les
programmes d’amélioration.
• Cette méthode permet le réajustement des actions pour atteindre des objectifs
mobiles et changeants.
§ L’environnement des organisations n’étant pas stable.
• Plan, Do Check, Act è Planifier, Faire, Vérifier, Ajuster
154
PDCA – Plan
• Phase de planification
• Définir les buts à atteindre, les objectifs et le périmètre.

• Définir les rôles, les responsabilités, les ressources nécessaires
• Définir le développement de processus, les composants techniques et les outils.
• Définir les interfaces dans le cycle de vie des services.
155
77
PDCA – Do
• Phase de réalisation et de mise en œuvre du plan d’actions
• Établir un plan d’action en tenant compte des ressources:
§ Exigences financières et budgets.
§ Ressources humaines: les personnes, leurs compétences.
§ Les produits et le matériel nécessaires.
§ Les besoins en communication et en formation.
156
PDCA – Check
• Phase de suivi et de vérification des effets des actions
• Surveiller mesurer et revoir
• Comparer les résultats obtenus avec les résultats attendus
• Vérifier que la documentation correspond bien à la réalité.
§ Notes de version,
§ Procédures opérationnelles, …
• Réaliser des audits
§ des services,
§ des processus et
§ des composants technologiques.
157
78
PDCA – Act
• Phase d’ajustement du plan d’actions.
• Dans quelle mesure avons-nous atteint les objectifs fixés lors de la phase de
planification?
• Identifier les ajustements nécessaires
§ Services,
§ Processus,
§ Composants technologiques.
• Mettre en œuvre ces améliorations.
158
Processus d’amélioration en 7 étapes

• ITIL recommande 7 étapes pour mettre en œuvre l’amélioration continue selon les
principes de PDCA.
• Approche structurée pour gérer l’amélioration continue des services.
159
79

1. Définir la place des services dans la vision d’entreprise, missions, buts est objectifs.
2. Évaluation des baselines.
3. Établir des cibles mesurables.
4. Définir les améliorations des services et des processus.
5. Mise en œuvre et actions.
6. Evaluation des résultats obtenus.
7. Adapter et ajuster les actions. Boucler et recommencer.
160
Étape 1
• Chaque amélioration doit contribuer à atteindre un objectif de l’entreprise.
• Définir une vision, des objectifs qui permettent d’aligner l’informatique sur les
besoins des métiers, les clients, les parties prenantes.
• Points importants
§ Vérifier la bonne compréhension de cette vision par toutes les parties prenantes.
§ Vérifier toutes les propositions d’amélioration s’intègrent bien dans cette vision.
§ Vérifier que toutes les parties prenantes ont bien compris leur rôle.
161
80
Étape 2
162

Définir ce qu'il
faudrait
mesurer
Mettre en place Défnir ce qu’il
les actions est possible de
d’amélioration mesurer
Restituer et
Collecter les
communiquer
les informations données
Analyser les Ajuster les

données données (KPI)
163
81
La mesure des services

• Les mesures des indicateurs ne doivent jamais être un but en soi.
• Il faut effectuer une mesure uniquement quand on a identifié ce qu’on va en faire, à
quoi elle sert, de quelle information elle est la mesure.
• Les mesures sont souvent quantitatives, c’est-à-dire numériques. Elles essaient
d’être objectives, quantifiables.
• Pourquoi faire des mesures?
§ Pour suivre un plan d’action.
§ Pour valider un choix.
§ Pour donner une direction.
§ Pour justifier, pour se justifier.
164
Les indicateurs
• La validité interne
§ Elle permet d’assurer que le résultat obtenu reflète bien la réalité et qu’il n’est pas dû à un
biais ou au hasard.
• La validité externe
§ Elle permet de s’assurer que le résultat n’est pas isolé, mais qu’il s’intègre dans un cadre
logique.
• Quatre types d’informations véhiculées par les indicateurs
§ La progression. L’indicateur de progression donne une idée de l’évolution sur une période
de temps.
§ La conformité. Cet indicateur montre si ce que l’on fait correspond à ce que l’on dit.
§ L’efficacité. Il indique si on a atteint un but, il n’indique cependant pas la manière dont on
a atteint le but.
§ L’efficience. Il mesure le rapport Qualité/Coût du résultat obtenu.
165
82

Gestion de La Qualité - ITIL

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Gestion de La Qualité - ITIL

Transféré par

Droits d'auteur :

Formats disponibles

Introduc)on à ITIL

La qualité des systèmes d’information

Les normes et les standards en informa&que

Les normes et les standards en informatique

Les normes et les standards en informa&que

Les normes et les standards en informatique

Les normes et les standards en informa&que

Qu’est-ce qu’une bonne pratique ?

Conception des services

20% Portée Portefeuille Stratégie des services Déclenchement

Quelques références - Livres

• ITIL Glossaire (Qualiti7)

• ITIL Poster (Qualiti7)

ITIL – Une démarche orientée qualité des services

Qu’est-ce qu’un service ?

Qu’est-ce qu’un service ?

Qu’est-ce qu’un service ?

Le cycle de vie des services

Cycle de vie des services

Qu’est-ce qu’un processus ?

Fournisseurs Activité 1 Résultats

Contrôle du service et de la qualité

Maturité d’un processus

5 Le processus est optimisé, géré et il

Maturité d’un processus

• Utilisation de questionnaires – Attention au calibrage des échelles de mesure.

Maturité d’un processus Maturity Level - Radar

Exemple – Services et Processus

Exemple – Services et Processus

• Exemples de rôles différents:

Les acteurs de la démarche Qualité de services

Exploitation des services

Exploitation des services – Présentation

Exploitation des services

Vision mé9er Vision technologique

Exploitation des services – Processus et fonctions

• Fonction importante de la phase d’exploitation des services

SKMS - Service Knowledge Management System

Le Centre de Services – Service Desk

Le Centre de Services – Les activités

Le Centre de Services – Les activités

Le Centre de Services – Configuration

Le Centre de Services – Les indicateurs

Construire des indicateurs

Gestion des événements

Qu’est-ce qu’un événement ?

Qu’est-ce qu’un événement ?

Objectifs de la gestion des événements

Gestion des incidents

Qu’est-ce qu’un incident ?

Impact, urgence et priorité

Les incidents majeurs

Gestion des incidents

Gestion des incidents

Gestion des problèmes

Gestion des problèmes

Gestion des problèmes

Méthode pour trouver les causes de problèmes

Exercice: Incident ou problème ? Trouvez des exemples d’incidents et de

Gestion des requêtes

Gestion des requêtes

Gestion des requêtes

Gestion des requêtes