Modèles et enregistrements · ISO 20000 · Chapitre 8.6.3
Registre des problèmes et des erreurs connues ISO 20000-1
Ce que l’on fait de la cause des incidents, et non de leur symptôme : la trouver, documenter comment la contourner en attendant et l’éliminer pour qu’elle ne revienne pas.
En une phrase
Le registre des problèmes naît de l’analyse des incidents, consigne le classement, la priorité, la cause racine, la solution de contournement et l’action définitive, et enregistre comme erreur connue ce dont la cause est identifiée mais qui n’est pas encore résolu, car le chapitre 8.6.3 de l’ISO/IEC 20000-1 exige d’analyser les données d’incidents pour détecter les problèmes, de les enregistrer, d’en identifier les causes et de suivre l’efficacité de leur résolution.
- Où la norme l’exige
- ISO 20000 · Chapitre 8.6.3 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 des problèmes et des erreurs connues (8.6.3)
- Qui le renseigne
- Gestionnaire des problèmes Avec les groupes techniques de chaque service
- Quand
- Après un incident majeur ou une tendance Également de manière proactive, à partir de l’analyse périodique des incidents
- 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
L’organisme analyse les données et les tendances des incidents pour identifier les problèmes. Les problèmes sont enregistrés, classés, hiérarchisés, escaladés si nécessaire et résolus lorsque c’est possible.
On recherche la cause racine et l’on détermine des actions pour réduire ou éviter les incidents. Si la solution exige un changement, elle passe par la gestion des changements. Les problèmes dont la cause est identifiée mais sans solution définitive sont enregistrés comme erreurs connues, avec les informations permettant d’en réduire l’impact.
L’efficacité de la résolution des problèmes est suivie, revue et rapportée. C’est le processus qui relie l’exploitation quotidienne à l’amélioration continue du chapitre 10.
Structure
Les champs que doit comporter le modèle
- Numéro, date et origine : incident majeur, tendance, proactif
- Incidents rattachés
- Service et éléments de configuration concernés
- Priorité
- Analyse de la cause racine et méthode
- Solution de contournement publiée pour le centre de services
- Erreur connue : oui ou non
- Action définitive et demande de changement associée
- Suivi de l’efficacité et clôture
Exemple
Exemple : expiration de certificats
Entreprise, personnes et chiffres fictifs : l’exemple montre seulement à quoi ressemble un enregistrement correctement renseigné.
| Champ | Contenu |
|---|---|
| Problème | PRB-26-021 · 16 avril 2026 · origine : incident majeur INC-26-0318 |
| Incidents rattachés | INC-26-0318 et 2 autres en 2025 dus à des certificats expirés sur d’autres services |
| Cause racine | Cinq pourquoi : les certificats sont renouvelés à la demande et il n’existe pas d’inventaire des dates d’expiration |
| Contournement | Vérification manuelle hebdomadaire des certificats critiques |
| Erreur connue | Oui, jusqu’à la mise en œuvre de l’action définitive |
| Action définitive | Inventaire des certificats comme éléments de configuration avec alerte à 30 jours · CHG-26-077 |
| Efficacité | Revue à 6 mois : 0 incident lié à l’expiration de certificats · clôturé |
À l’audit
Les erreurs que relèvent souvent les auditeurs
- Des problèmes clôturés dès l’application de la solution de contournement.
- Les tendances d’incidents ne sont pas analysées : on n’ouvre un problème qu’après une panne majeure.
- Des erreurs connues que le centre de services ne peut pas consulter.
- Des actions définitives appliquées sans passer par la gestion des changements.
- Aucun suivi de l’efficacité après la clôture.
Dans Kimobox
Comment tenir cet enregistrement dans Kimobox
- 1Les incidents récurrents sont rattachés à un enregistrement de problème avec son analyse de cause racine.
- 2Incidents et problèmes restent liés, et leur cause racine est documentée et traçable.
- 3L’action définitive est attribuée avec responsable, date et alerte de retard, et son efficacité est vérifiée plus tard.
Questions fréquentes
Ce que l’on nous demande avant de commencer
Qu’est-ce qu’une erreur connue ?
Un problème dont la cause racine est connue, ou pour lequel il existe un moyen d’en réduire ou d’en supprimer l’impact, mais qui n’a pas encore de solution définitive. On l’enregistre pour que le centre de services résolve plus vite les incidents qu’il provoque.
Problème et incident, est-ce la même chose ?
Non. L’incident est le symptôme : le service est défaillant. Le problème est la cause, connue ou non, d’un ou de plusieurs incidents. La gestion des incidents rétablit le service ; celle des problèmes évite qu’il ne retombe en panne.
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…