Piloter un registre d'erreurs connues
Structurer et exploiter un registre d'erreurs connues pour accélérer la résolution des incidents récurrents.
À retenir
- Une erreur connue combine une cause racine confirmée et un contournement documenté et testé.
- Le registre n'apporte de la valeur que s'il est systématiquement consulté avant tout nouveau diagnostic.
- Une fiche doit être clôturée après correction définitive vérifiée, sous peine de polluer le registre.
- Le nombre d'occurrences rattachées objective la priorisation des corrections définitives.
Qu'est-ce qu'une erreur connue
Une erreur connue (known error) est un problème dont la cause racine a été identifiée et pour lequel un contournement, temporaire ou définitif, existe. Elle diffère d'un problème encore en investigation, dont la cause n'est pas confirmée.
Structure minimale d'une fiche d'erreur connue
| Champ | Exemple |
|---|---|
| Identifiant | ERR-2026-014 |
| Symptôme observé | Coupure réseau intermittente sur baies en rangée C |
| Cause racine confirmée | Connecteur RJ45 mal serti sur le panneau de brassage secondaire |
| Contournement | Basculer sur le port de secours identifié dans la CMDB |
| Correction définitive | Remplacement planifié du panneau lors de la prochaine fenêtre de maintenance |
| Statut | Contournement actif, correction planifiée le 14/11 |
Point clé
un registre d'erreurs connues n'a de valeur que si le service desk et les équipes d'astreinte le consultent systématiquement avant de commencer un diagnostic à partir de zéro.
Bénéfices mesurables
- Réduction du temps moyen de résolution (MTTR) sur les incidents récurrents déjà documentés.
- Cohérence des contournements appliqués, évitant que chaque astreinte réinvente sa propre solution temporaire.
- Historique exploitable pour prioriser les corrections définitives selon la fréquence des occurrences.
Processus de vie d'une fiche
- Un problème est confirmé avec cause racine identifiée → création de la fiche.
- Un contournement est documenté et testé avant publication.
- Chaque nouvelle occurrence liée est rattachée à la fiche existante plutôt que de créer un problème dupliqué.
- Une fois la correction définitive déployée et vérifiée sur plusieurs cycles, la fiche est clôturée et archivée.
Sur le terrain
l'erreur la plus fréquente est d'oublier de clôturer les fiches après correction définitive, ce qui pollue le registre et fait perdre confiance dans sa fiabilité au fil du temps.
Exemple de tableau de pilotage mensuel
| Indicateur | Cible | Résultat du mois |
|---|---|---|
| Nombre de nouvelles erreurs connues créées | — | 4 |
| Nombre de fiches clôturées après correction définitive | ≥ nombre créé | 3 |
| Part des incidents rattachés à une erreur connue existante | > 40 % | 52 % |
| MTTR moyen des incidents avec contournement documenté | < MTTR moyen global | 35 min vs 90 min |
Attention
un contournement documenté ne doit jamais devenir une solution permanente non assumée. Si aucune date de correction définitive n'est fixée après plusieurs mois, il faut le signaler explicitement en revue de gestion des problèmes.
Intégration avec la CMDB
Chaque fiche d'erreur connue doit référencer les éléments de configuration concernés (baie, panneau de brassage, onduleur) afin que la corrélation avec de futurs incidents soit automatique lors de la consultation de la base de gestion des configurations.
Astuce
ajoutez un champ « nombre d'occurrences » incrémenté automatiquement à chaque incident rattaché ; il devient un argument objectif pour prioriser les corrections définitives en comité technique.