Accueil / Niveau Intermédiaire

Niveau Intermédiaire — Pratiques opérationnelles

Incidents, problèmes, changements et requêtes : les 4 pratiques les plus testées à l'examen, avec les définitions exactes.

I1

Module 5 — Gestion des incidents : rétablir vite

+

1. Définition et objectif

Définition exacte — Incident : interruption non planifiée d'un service ou réduction de la qualité d'un service. Objectif de la pratique : minimiser l'impact négatif en rétablissant le fonctionnement normal du service aussi rapidement que possible.

Notez bien : l'objectif est la rapidité de rétablissement, pas la compréhension de la cause profonde (c'est le rôle de la gestion des problèmes).

Pourquoi c'est important : samedi à 20 heures, ton site e-commerce tombe pendant les soldes : 10 000 paniers bloqués, direction en panique, réseaux sociaux en feu. Sans pratique des incidents, chacun improvise, personne ne communique, le rétablissement prend 8 heures. Avec la pratique, le P1 est déclaré, le contournement appliqué, la communication rythmée. La différence se chiffre en chiffre d'affaires perdu.
L'analogie qui aide : pense aux urgences d'un hôpital : on ne cherche pas d'abord la cause du malaise, on stabilise le patient (rétablir vite), on trie par gravité (priorité selon impact et urgence), on appelle le spécialiste si besoin (escalade fonctionnelle) ou la direction pour des moyens (escalade hiérarchique). L'enquête approfondie viendra après, comme la gestion des problèmes.

2. Priorisation : impact × urgence

La priorité d'un incident se détermine en croisant l'impact (ampleur des dégâts : nombre d'utilisateurs, criticité métier) et l'urgence (vitesse à laquelle il faut agir, délai acceptable). Matrice usuelle : P1 (critique), P2 (haute), P3 (moyenne), P4 (basse). Exemple : panne du site e-commerce un samedi = impact élevé + urgence élevée = P1.

3. Escalade, communication et outils

  • Escalade hiérarchique : faire monter vers un niveau de management supérieur (décision, moyens). Escalade fonctionnelle : transférer vers une équipe plus experte (niveau 2, niveau 3).
  • Les incidents majeurs exigent une communication dédiée (cellule de crise, points réguliers aux métiers).
  • Bonnes pratiques : enregistrement de tous les incidents, catégorisation, scripts de diagnostic, droit accordé au centre de services de appliquer des workarounds connus.
Démonstration pas à pas : cas d'une assurance à 9h12 : 300 conseillers perdent l'accès au logiciel de contrats. Déroulé : enregistrement INC-2026-0841 avec catégorie et priorité P1 (impact : 300 personnes, urgence : contrats bloqués) ; contournement immédiat (bascule sur serveur secondaire) ; escalade fonctionnelle vers l'infrastructure ; point de situation toutes les 30 minutes aux métiers. Résultat : service rétabli à 9h47, 35 minutes d'interruption au lieu d'une journée. La cause sera traitée en problème séparé.
Exemple d'entreprise : à 9h12, 300 conseillers d'une assurance ne peuvent plus ouvrir le logiciel de contrats (P1). Le centre de services enregistre l'incident INC-2026-0841, applique le workaround documenté (basculer sur le serveur secondaire), escalade fonctionnellement vers l'équipe infrastructure, et envoie un point de situation toutes les 30 minutes. Service rétabli à 9h47. La cause profonde sera traitée séparément comme un problème.
Pièges d'examen : 1) Incident = interruption non planifiée (une maintenance planifiée n'est pas un incident). 2) L'objectif est le rétablissement rapide, pas l'analyse de cause. 3) Priorité = impact + urgence (question quasi systématique). 4) Escalade hiérarchique (management) vs fonctionnelle (expertise). 5) Tous les incidents doivent être enregistrés.
Pièges classiques : une maintenance planifiée n'est jamais un incident (il manque le caractère non planifié). L'objectif est le rétablissement rapide, pas l'analyse de la cause : si la question parle de cause profonde, c'est la gestion des problèmes. Priorité égale impact plus urgence, pas l'un ou l'autre. Escalade hiérarchique égale management, fonctionnelle égale expertise.
À vous de jouer : un utilisateur signale que son application est lente depuis trois semaines, sans interruption franche. Incident ou pas, et quelle priorité envisager ?
Voir la réponse

Oui, c'est un incident : réduction de la qualité de service, même sans coupure totale. La priorité se fixe en croisant impact (un seul utilisateur ou tout un service) et urgence (travail bloqué ou ralenti). Enregistrement obligatoire, diagnostic, contournement si possible, puis escalade si nécessaire.

I2

Module 6 — Gestion des problèmes : traiter la cause

+

1. Définitions en cascade (à connaître par coeur)

Problème : cause, ou cause potentielle, d'un ou plusieurs incidents. Known error (erreur connue) : problème qui a été analysé mais non résolu, avec un workaround documenté. Workaround (solution de contournement) : solution qui réduit ou élimine l'impact d'un incident ou d'un problème pour lequel une résolution complète n'est pas encore disponible.

La chaîne logique : incident(s) → problème (cause) → analyse → known error + workaround → résolution définitive → clôture.

Pourquoi c'est important : en deux mois, ton support traite 14 fois les mêmes lenteurs ERP en redémarrant le serveur la nuit. Les utilisateurs s'énervent, les techniciens s'épuisent, la direction parle d'externaliser le support. Sans gestion des problèmes, tu éteins le même feu en boucle. Avec elle, tu identifies la requête SQL fautive et tu règles la cause une fois pour toutes.
L'analogie qui aide : pense au plombier face à une fuite répétée : l'incident, c'est éponger l'eau (vite, pour limiter les dégâts). Le problème, c'est trouver le tuyau percé. La known error, c'est savoir que le joint est fissuré et poser une bassine calibrée en attendant (contournement). La résolution définitive, c'est changer le tuyau. Éponger sans réparer garantit la prochaine inondation.

2. Objectif et activités

Objectif : réduire la probabilité et l'impact des incidents en identifiant leurs causes réelles et potentielles, et en gérant les workarounds et les known errors.

  • Distinguer le contrôle des problèmes (réactif : analyser après incidents ; proactif : détecter avant qu'ils surviennent, via tendances et supervision) et le contrôle des erreurs.
  • Analyser les tendances (récurrence des incidents), prioriser les problèmes selon le risque, documenter les known errors dans la base de données des erreurs connues (KEDB).
Démonstration pas à pas : cas de 14 incidents lenteurs ERP en deux mois. Déroulé : ouverture de PRB-117, analyse des journaux et corrélation avec la montée de version ; identification de la cause (index manquant) ; déclaration en known error avec contournement documenté (purge nocturne du cache dans la KEDB) ; demande de changement pour réindexation définitive. Résultat : zéro récidive en trois mois, temps de réponse divisé par quatre, centre de services soulagé grâce à la KEDB pendant l'attente.
Exemple d'entreprise : en 2 mois, 14 incidents « lenteurs de l'ERP » sont enregistrés. La gestion des problèmes ouvre PRB-117, identifie la cause (requête SQL mal indexée après la montée de version), déclare une known error avec workaround (purger le cache chaque nuit), puis planifie la correction définitive (réindexation) via un changement. Sans cette pratique, le support aurait « éteint » 14 fois le même feu.
Pièges d'examen : 1) Incident (symptôme, interruption) vs problème (cause) : la distinction tombe à chaque session. 2) La known error est un problème analysé mais non résolu. 3) Le workaround ne résout pas la cause, il réduit l'impact. 4) La KEDB permet au centre de services de résoudre plus vite les incidents récurrents. 5) L'analyse proactive utilise les tendances.
Pièges classiques : incident égale symptôme et interruption, problème égale cause réelle ou potentielle : ne les inverse jamais. Known error égale problème analysé mais non résolu, avec contournement. Le contournement réduit l'impact sans supprimer la cause. La KEDB sert au centre de services pour aller plus vite sur les récidives. L'analyse proactive s'appuie sur les tendances, pas sur un seul ticket.
À vous de jouer : après analyse, tu connais la cause d'une erreur d'impression mais le correctif attend le budget du trimestre prochain. Quel statut ITIL et quelle action immédiate ?
Voir la réponse

Déclare une known error avec contournement documenté dans la KEDB (par exemple file d'attente redirigée vers une autre imprimante). Le support applique le contournement en attendant la résolution définitive pilotée par un changement.

I3

Module 7 — Gestion des changements (change enablement)

+

1. Définition et objectif

Définition exacte — Changement : ajout, modification ou suppression de tout élément susceptible d'avoir un effet direct ou indirect sur les services. Objectif : maximiser le nombre de changements réussis en s'assurant que les risques sont correctement évalués, en autorisant les changements et en gérant le calendrier.
Pourquoi c'est important : un technicien applique un correctif réseau un vendredi à 17 heures sans autorisation : tout le VPN tombe, la comptabilité ne peut pas clôturer, le directeur exige des coupables. L'audit révèle aucun RFC, aucune évaluation de risque, aucun plan de retour. La pratique change enablement existe pour maximiser les changements réussis : évaluer et autoriser au bon niveau, pas pour bloquer.
L'analogie qui aide : pense au contrôle aérien : un petit avion de tourisme suit une procédure standard pré-autorisée (changement standard), un vol commercial suit un plan de vol évalué au cas par cas (changement normal avec CAB), et un mayday obtient une priorité immédiate avec cellule dédiée (changement urgent avec ECAB). Personne ne décolle sans autorisation adaptée au risque.

2. Les 3 types de changements

TypeCaractéristiquesAutorité
Changement standardPré-autorisé, à faible risque, procédure documentée, fréquentPré-autorisation (politique)
Changement normalPlanifié, évalué, autorisé au cas par cas selon le risqueAutorité de changement (manager, CAB)
Changement urgentNécessite une action immédiate (exemple : faille critique)ECAB (conseil consultatif d'urgence)

3. Autorité, planification et évaluation

  • L'autorité de changement varie selon le type et le risque : un responsable, un groupe de pairs, le CAB (Change Advisory Board) pour les changements normaux à risque, l'ECAB pour les urgents.
  • Le calendrier des changements (change schedule) centralise les changements planifiés pour éviter les conflits et informer les parties prenantes.
  • Chaque changement normal suit : demande (RFC) → évaluation du risque et de l'impact → autorisation → planification → mise en oeuvre → revue post-implémentation (PIR).
Démonstration pas à pas : cas d'une faille critique sur le dossier patient d'un hôpital. Déroulé : RFC urgent déposé à 14 heures, ECAB réuni en visioconférence à 15 heures, évaluation express (impact, risque, retour arrière), déploiement à 3 heures du matin en fenêtre réduite, tests ciblés, revue post-implémentation le lendemain. Résultat : vulnérabilité fermée en 24 heures sans interruption des soins. À l'inverse, une réinitialisation de mot de passe reste un changement standard exécuté sans CAB.
Exemple d'entreprise : un hôpital doit corriger une faille critique du dossier patient. Changement urgent : ECAB réuni en 1 heure, test minimal mais tracé, déploiement à 3h du matin, revue le lendemain. À l'inverse, la réinitialisation d'un mot de passe suit un changement standard pré-autorisé exécuté par le centre de services sans CAB.
Pièges d'examen : 1) Les 3 types : standard (pré-autorisé, faible risque), normal (évalué au cas par cas), urgent (ECAB). 2) Le CAB conseille et autorise les changements normaux ; l'ECAB traite les urgents. 3) L'objectif mentionne « maximiser les changements réussis », pas « minimiser leur nombre ». 4) Le nouveau nom officiel de la pratique est change enablement (et non « change management »). 5) Un changement standard n'a pas besoin d'autorisation à chaque occurrence.
Pièges classiques : standard égale pré-autorisé, faible risque, fréquent. Normal égale évalué et autorisé au cas par cas par l'autorité de changement ou le CAB. Urgent égale ECAB, pas CAB. L'objectif officiel dit maximiser les changements réussis, jamais réduire leur nombre. Le nom d'examen est change enablement, pas change management.
À vous de jouer : ton équipe veut ajouter un champ au formulaire de congés, procédure déjà documentée et appliquée 50 fois sans incident. Quel type de changement et quelle autorisation ?
Voir la réponse

Changement standard : faible risque, procédure connue, pré-autorisé par la politique. Pas de CAB à chaque occurrence, exécution directe par l'équipe habilitée avec traçabilité.

I4

Module 8 — Centre de services et gestion des requêtes

+

1. Le centre de services (service desk)

Définition exacte — Centre de services : point de communication unique entre le fournisseur de services et les utilisateurs. C'est une pratique, pas seulement une équipe ou un outil.

Qualités attendues : compréhension métier, excellentes compétences de communication, empathie, capacité de diagnostic initial et d'escalade pertinente. L'examen insiste : le centre de services a un impact majeur sur l'expérience utilisateur.

Pourquoi c'est important : sans point d'entrée unique, les utilisateurs appellent directement les administrateurs sur leur portable : interruptions permanentes, demandes perdues, favoritisme, aucun pilotage. Le centre de services et la gestion des requêtes remettent de l'ordre : un canal unique, des workflows publiés au catalogue, des délais mesurés. L'expérience utilisateur et la charge des experts s'améliorent en même temps.
L'analogie qui aide : pense à la réception d'un grand hôtel : un seul comptoir accueille tout le monde avec empathie (centre de services), les demandes courantes suivent des fiches précises (requêtes avec workflows prédéfinis). Quand une canalisation éclate, ce n'est plus une requête mais un incident : on déclenche la maintenance d'urgence avec une autre procédure.

2. Gestion des requêtes de service

Définition exacte — Requête de service : demande d'un utilisateur (ou de son représentant) qui initie une action convenue dans le cadre de la fourniture normale d'un service. Objectif : soutenir la qualité convenue en traitant efficacement ces demandes prédéfinies et initiées par les utilisateurs.

Exemples : réinitialisation de mot de passe, fourniture d'un PC, accès à un dossier partagé, demande d'information. Les requêtes suivent des workflows prédéfinis avec étapes d'approbation et délais publiés dans le catalogue de services.

3. Requête vs incident : le distinguo capital

CritèreIncidentRequête de service
NatureInterruption non planifiée, anomalieDemande normale, prévue au catalogue
Exemple« Ma messagerie ne fonctionne plus »« Je demande un second écran »
PriorisationImpact × urgenceProcédure et délai standard du catalogue
Démonstration pas à pas : cas d'une université qui reçoit 200 demandes de compte Wi-Fi invité à la rentrée. Déroulé : requête publiée au catalogue (délai 4 heures, approbation du responsable) ; dépôt via le portail self-service ; workflow automatique (vérification, création, notification) ; clôture avec enquête de satisfaction. Résultat : 98 pour cent dans les délais, zéro appel aux administrateurs réseau. Quand le Wi-Fi tombe dans l'amphithéâtre, le même portail bascule vers un incident P2 avec une autre équipe.
Exemple d'entreprise : une université publie au catalogue « demande de compte invité Wi-Fi » (délai 4 h, approbation du responsable). L'étudiant dépose sa requête via le portail, le workflow s'exécute automatiquement, le compte est créé et clôturé avec enquête de satisfaction. Quand le Wi-Fi tombe en panne dans l'amphithéâtre, c'est en revanche un incident géré par la pratique des incidents.
Pièges d'examen : 1) « Mot de passe oublié / demande d'accès / demande d'information » = requête, pas incident. 2) Les requêtes sont prédéfinies, initiées par l'utilisateur, avec workflows standard. 3) Le centre de services est le point de communication unique. 4) L'automatisation et le self-service (portail) sont encouragés pour les requêtes simples. 5) Ne confondez pas « demande de changement » (RFC) et « requête de service ».
Pièges classiques : mot de passe oublié, demande d'accès, demande d'information ou de PC : c'est une requête, pas un incident. La requête est prédéfinie, initiée par l'utilisateur, avec workflow standard et délai catalogue. Le centre de services est le point de communication unique et pèse sur l'expérience utilisateur. Ne confonds pas requête de service et demande de changement (RFC).
À vous de jouer : un nouvel arrivant demande un PC portable et l'accès au CRM. Incident, requête, ou changement ? Justifie.
Voir la réponse

Deux requêtes de service : demandes normales, prévues au catalogue, initiées par l'utilisateur, avec workflows d'approbation et de fourniture. Ni interruption (incident) ni modification risquée d'un service existant (changement).

Continuer vers le niveau Expert