Modèles et enregistrements · ISO 20000 · Chapitre 8.6.1
Registre des incidents IT selon l’ISO 20000-1
Chaque interruption non planifiée d’un service ou perte de sa qualité, de sa détection à sa clôture, avec un traitement particulier pour les incidents majeurs.
En une phrase
Le registre des incidents consigne chaque interruption ou dégradation d’un service avec son classement, sa priorité selon l’impact et l’urgence, l’escalade, les actions menées, la résolution et la clôture, et traite les incidents majeurs selon une procédure documentée, avec responsable désigné, information de la direction et rapport a posteriori, car le chapitre 8.6.1 de l’ISO/IEC 20000-1 exige d’enregistrer, classer, hiérarchiser, escalader, résoudre et clôturer chaque incident.
- Où la norme l’exige
- ISO 20000 · Chapitre 8.6.1 Les chapitres sont cités selon la numérotation de l’ISO/IEC 20000-1:2018, l’édition en vigueur et celle qu’utilise l’Académie.
- Type d’information
- Enregistrement obligatoire Enregistrement de chaque incident et des actions menées (8.6.1)
- Qui le renseigne
- Centre de services Les groupes de support résolvent ; le gestionnaire des incidents majeurs coordonne le cas échéant
- Quand
- Dès sa détection ou son signalement Y compris ceux détectés par la supervision avant que le client ne les remarque
- Durée de conservation
- Fixée par l’organisme La norme demande de maîtriser la conservation et l’élimination des informations documentées (7.5.3) sans fixer de durée. L’usage est de couvrir au moins le cycle de certification de trois ans, ou la durée du contrat avec le client si elle est plus longue.
Ce que demande la norme
Ce qu’exige ISO 20000 et ce qui est laissé à votre appréciation
Les incidents sont enregistrés et classés, hiérarchisés en fonction de leur impact et de leur urgence, escaladés si nécessaire, résolus et clôturés. L’enregistrement est mis à jour avec les actions menées.
L’organisme définit ce qu’est un incident majeur. Ces incidents sont gérés selon une procédure documentée : la direction est informée, une personne responsable est désignée et, une fois l’incident résolu, un rapport est établi et les opportunités d’amélioration sont examinées.
La norme distingue les incidents des demandes de service (8.6.2) : une demande de création de compte n’est pas un incident et ne doit pas compter dans son SLA.
Structure
Les champs que doit comporter le modèle
- Numéro, date et heure d’enregistrement
- Origine : utilisateur, supervision, fournisseur
- Service et élément de configuration concernés
- Description et symptômes
- Catégorie
- Impact, urgence et priorité qui en résulte
- Groupe affecté et escalades
- Actions menées et communications à l’utilisateur
- Résolution, cause apparente et lien vers un problème
- Heure de résolution, confirmation de l’utilisateur et clôture
- S’il est majeur : responsable, information de la direction et rapport a posteriori
Exemple
Exemple : incident majeur dû à une panne de la messagerie
Entreprise, personnes et chiffres fictifs : l’exemple montre seulement à quoi ressemble un enregistrement correctement renseigné.
| Champ | Contenu |
|---|---|
| Numéro | INC-26-0318 · 14 avril 2026, 09:02 · alerte de supervision |
| Service | SRV-04 messagerie et collaboration · élément CI-MAIL-01 |
| Symptômes | Les clients de messagerie ne se connectent pas : erreur de certificat |
| Priorité | Impact élevé (tous les utilisateurs) · urgence élevée · P1 · majeur |
| Responsable | Gestionnaire des incidents majeurs · direction informée à 09:10 |
| Résolution | Renouvellement du certificat à 10:20 · service rétabli |
| Durée | 78 minutes · dans l’objectif P1, mais avec un impact sur la disponibilité mensuelle |
| Rapport | Rapport d’incident majeur du 16 avril · problème PRB-26-021 ouvert |
À l’audit
Les erreurs que relèvent souvent les auditeurs
- Des demandes et des questions enregistrées comme incidents, qui faussent les indicateurs.
- Une priorité attribuée par l’appelant et non selon l’impact et l’urgence.
- Des incidents clôturés sans confirmation de l’utilisateur.
- Des incidents majeurs sans rapport a posteriori ni examen des améliorations.
- Les incidents répétés ne sont pas rattachés à un problème.
Dans Kimobox
Comment tenir cet enregistrement dans Kimobox
- 1Chaque incident est enregistré avec sa priorité et son délai de résolution.
- 2Les incidents récurrents sont rattachés à un enregistrement de problème avec son analyse de cause racine.
- 3Les demandes de service sont gérées depuis le portail clients ou le portail salarié.
- 4Le respect du SLA se lit dans le tableau de bord.
Questions fréquentes
Ce que l’on nous demande avant de commencer
Quelle différence entre incident et demande de service ?
L’incident est une interruption non planifiée ou une perte de qualité du service ; la demande est une sollicitation de quelque chose que le service prévoit déjà, comme une création de compte ou un changement de mot de passe. L’ISO/IEC 20000-1 les traite dans des chapitres distincts.
Qui décide de ce qu’est un incident majeur ?
L’organisme, selon des critères documentés — par exemple le nombre d’utilisateurs touchés ou l’arrêt de services critiques — et souvent convenus avec le client.
Tenez les enregistrements ISO 20000 sans modèles éparpillés
Nous vous montrons le module en fonctionnement avec des données proches des vôtres.
Poursuivez la visite
Pages associées
Fourniture et support du service
Ce bloc couvre l’exploitation quotidienne : résolution des incidents, gestion des problèmes et traitement…
Modèle de catalogue de services IT selon l’ISO 20000-1
Ce que doit comporter le catalogue de services exigé par l’ISO/IEC 20000-1 : description, résultats…
Modèle d’accord de niveau de service (SLA) ISO 20000-1
Ce que doit contenir un SLA selon l’ISO/IEC 20000-1 (8.3.3) : services, objectifs de niveau, limites de…
Modèle de rapport de niveau de service ISO 20000-1
Ce que doit contenir le rapport de service exigé par l’ISO/IEC 20000-1 : respect des SLA, charge, incidents…