Revue des problèmes : trouver les incidents récurrents
Trouvez les incidents que vous résolvez sans cesse, expliquez le premier par une analyse structurée des causes racines, et convenez de qui est propriétaire de sa clôture. Trois outils, une seule séance, rien n’est envoyé.
- Repère les schémas récurrents
- Cinq passes de RCA structurées
- Rien ne quitte votre navigateur
Une revue des problèmes examine les incidents récents pour y repérer des schémas récurrents, retient ceux qui méritent une investigation et désigne un propriétaire pour chacun. Le tableau de bord signale un candidat quand au moins cinq incidents partagent une catégorie, un élément de configuration et une formulation similaire, et classe plus haut ceux qui augmentent sur les 14 derniers jours. Confrontez une tendance au Ramadan, à l’Aïd et à la clôture de fin de mois avant de vous y fier. Les candidats sont à examiner, ce ne sont pas des problèmes confirmés.
La plupart des centres de services résolvent le même incident de nombreuses fois. La gestion des problèmes est la pratique censée y mettre fin, et c’est celle qu’on saute le plus souvent — non parce que les équipes la contestent, mais parce qu’elle exige de prendre délibérément du temps hors de la file, et parce que le passage de l’incident au problème arrive généralement sous forme d’intuition plutôt que de preuves.
Ces trois outils comblent cet écart en une seule séance. Votre export d’incidents ne quitte jamais le navigateur.
1. Trouver les schémas
Déposez un export d’incidents. Les incidents qui partagent une catégorie, un élément de configuration et une formulation similaire sont regroupés, puis classés par volume, par la gravité des pires tickets du groupe, et selon que leur rythme a augmenté au cours des deux dernières semaines.
2. Expliquer le premier
Envoyez un candidat directement dans l’analyseur et soumettez-le à cinq passes structurées — est/n’est pas, Ishikawa, cinq pourquoi, Pareto et corrélation avec les changements. Le candidat est transmis : vous n’avez pas à le ressaisir.
3. Convenir de qui le clôt
Un schéma récurrent sans propriétaire reste un schéma récurrent. Déterminez s’il relève de l’incident ou du problème, qui est propriétaire de la clôture, et les mots qui le feront accepter par une partie prenante.
Mener une revue des problèmes qui change quelque chose
- Apportez des preuves, pas des impressions. Un candidat porte son nombre d’incidents, sa période, la répartition des priorités et des exemples de références de tickets. C’est ce qui transforme « ça n’arrête pas d’arriver » en un sujet sur lequel un comité consultatif des changements agira.
- Prenez un candidat, pas cinq. Une revue qui ouvre cinq enregistrements de problème et n’en clôt aucun est pire qu’une revue qui en ouvre un seul et le mène à terme.
- Privilégiez les schémas en hausse plutôt que les plus volumineux. Un groupe ancien de P4 est souvent une gêne connue, avec une solution de contournement. Un groupe qui a fortement augmenté au cours des deux dernières semaines correspond généralement à quelque chose qui a changé récemment, et donc à quelque chose qu’on peut annuler.
- Vérifiez le calendrier avant de vous fier à une tendance. Les volumes varient autour du Ramadan, de l’Aïd et de la clôture de fin de mois. Le calendrier des heures ouvrées du GCC définit les semaines de travail et les jours fériés sur lesquels se mesure chaque outil du Lab.
- Notez ce que vous avez décidé de ne pas poursuivre. Le mois prochain, vous regarderez la même liste. Savoir pourquoi un candidat a été écarté évite d’avoir deux fois le même débat.
Méthode et propriété
Les candidats proviennent du tableau de bord du centre de services, qui regroupe les incidents par catégorie, élément de configuration et descriptions courtes similaires, exige au moins cinq incidents par groupe, et compare les 14 derniers jours à un maximum de 90 jours précédents pour détecter une hausse. Le classement pondère les tickets les plus graves d’un groupe plutôt que la moyenne. Les candidats sont des points de départ pour l’investigation, pas des problèmes confirmés, et chaque étape s’exécute dans votre navigateur.
Les formules utilisées ici sont des méthodes standard et publiées. L’implémentation, l’interface, les textes, la logique des constats et les chiffres de référence sont une œuvre originale d’ITSM Compass. Les résultats sont des estimations, pas un avis professionnel. Voir les conditions d’utilisation.
© 2026 ITSM Compass. Tous droits réservés.
Questions
Qu’est-ce qu’une revue des problèmes ?
Une séance régulière qui examine les incidents récents pour y repérer des schémas récurrents, retient ceux qui méritent une investigation, et désigne un propriétaire pour chacun. C’est la pratique que la plupart des centres de services ont sur le papier et que peu mènent sérieusement, car elle exige du temps hors de la file réactive.
Comment un candidat problème est-il trouvé ?
Le tableau de bord regroupe les incidents qui partagent une catégorie, un élément de configuration et une formulation similaire, puis classe les groupes par volume, par la gravité de leurs pires tickets, et selon que leur rythme a augmenté sur les 14 derniers jours par rapport aux semaines précédentes. Les groupes de moins de cinq incidents sont ignorés. Ce sont des candidats à examiner, pas des problèmes confirmés.
De quelles données ai-je besoin ?
Un export d’incidents de ServiceNow, Jira, Freshservice ou de tout outil produisant un CSV avec les dates, la priorité, la catégorie et une description courte. Environ trois semaines d’historique sont le minimum pour que le test de tendance ait un sens ; davantage, c’est mieux.
Mes données de tickets quittent-elles ma machine ?
Non. L’export est lu dans votre navigateur et n’est jamais envoyé. Il n’y a ni compte ni serveur, et c’est précisément pour cela que tout fonctionne comme un ensemble d’outils dans le navigateur plutôt que comme une plateforme. Fermez l’onglet et l’export disparaît ; le tableau de bord conserve dans ce navigateur le nom du fichier et ses 12 premières catégories avec leurs volumes annuels, pour le calculateur shift-left.
Pourquoi l’analyse des causes racines a-t-elle besoin d’un outil distinct ?
Parce que trouver un schéma et l’expliquer sont deux tâches différentes. L’analyseur applique cinq passes structurées à vos éléments de preuve — est/n’est pas, Ishikawa, cinq pourquoi, Pareto et corrélation avec les changements — pour que la conclusion repose sur les preuves plutôt que sur la dernière personne qui a parlé.
À quelle fréquence faut-il le faire ?
Une fois par mois convient à la plupart des centres de services. Les données sur les schémas ont besoin de temps pour s’accumuler, et les actions qui en découlent ont besoin de temps pour aboutir avant la passe suivante.
Personne n’a le temps de mener la revue des problèmes ?
C’est la raison habituelle pour laquelle elle n’a jamais lieu. Un Service Delivery Manager à temps partagé peut la mener chaque mois et suivre les actions jusqu’à leur achèvement.