Outil d’analyse des causes racines pour les incidents IT
Cinq passes structurées sur vos propres éléments de preuve d’incident — est/n’est pas, Ishikawa, cinq pourquoi, Pareto, corrélation avec les changements — puis une liste classée des causes et des lacunes à combler en priorité.
- Classé selon les preuves
- Cinq méthodes en une passe
- Fonctionne dans votre navigateur
Une cause racine doit expliquer ce qui a été épargné autant que ce qui a échoué : si seules les agences de Riyad ont perdu les paiements par carte, la cause doit expliquer pourquoi Djeddah ne les a pas perdus. Cet outil note chaque candidat sur 100 à partir de vos preuves : est/n’est pas 35 points, corrélation avec les changements 20, Pareto 20, cinq pourquoi 15 et inversion 10. Un changement daté après le symptôme est écarté.
Le symptôme
Quand il a été observé pour la première fois. Chaque changement que vous saisirez ensuite sera comparé à ce moment.
Causes candidates
Nommez ce que cela pourrait être, dans n’importe quelle catégorie d’Ishikawa, puis indiquez ce que vous savez réellement de chacune. Les réponses vides sont signalées comme des lacunes, pas comme des « non ».
Le test d’inversion
Si vous vouliez provoquer cela délibérément demain, comment vous y prendriez-vous ? Nommez les leviers que vous actionneriez, puis cochez ceux qui étaient réellement en place.
Ce que les preuves étayent
Mise à jour pendant la saisie. Les scores sont sur 100 et ne reflètent que ce que vous avez saisi.
La fréquence et l’impact sont vos propres chiffres. Une cause candidate sans nombre d’occurrences ni impact n’a aucun poids dans le Pareto — elle n’est pas écartée, elle n’est simplement pas mesurée.
Comment obtenir une réponse exploitable
Le classement ne vaut que par les éléments qui le fondent : l’outil note donc séparément la part des questions renseignées et la solidité du dossier. Une cause candidate à 30 points avec toutes les questions renseignées est une cause faible ; une cause candidate à 30 points avec la moitié des questions vides est une cause non examinée. Elles n’appellent pas le même travail.
Avancez sur toutes les causes candidates à la fois plutôt que sur une seule. Nommez-en d’abord quatre ou cinq dans des catégories d’Ishikawa différentes, puis répondez à la paire est / n’est pas pour chacune, puis aux nombres d’occurrences. Épuiser une cause candidate avant les autres, c’est ainsi que les équipes finissent par démontrer leur théorie favorite au lieu de la tester.
Ce qu’apporte chaque passe
- Est / n’est pas (35 points). Kepner-Tregoe. Votre critère le plus discriminant : une vraie cause explique la frontière autant que la défaillance.
- Corrélation avec les changements (20). La plupart des incidents suivent un changement. Un changement daté après le symptôme est éliminé d’office.
- Pareto (20). Fréquence × impact, rapportés à la cause candidate la plus lourde, pour que l’effort porte sur les quelques causes essentielles.
- Cinq pourquoi (15). La profondeur atteinte sans vous répéter.
- Test d’inversion (10). Le levier de sabotage qui s’est révélé réel.
Méthode et propriété
Cinq passes sur les éléments que vous fournissez : est / n’est pas de Kepner-Tregoe (35 points), corrélation avec les changements (20, avec élimination stricte de tout changement daté après le symptôme), Pareto par fréquence × impact (20), profondeur des cinq pourquoi sans les réponses répétées (15) et un test d’inversion (10). Aucune donnée externe n’est utilisée et rien n’est conservé.
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
L’outil devine-t-il la cause à ma place ?
Non. Il n’a aucune base de causes courantes et rien n’est envoyé nulle part. Il prend les causes candidates que vous nommez et les éléments que vous donnez pour chacune, applique cinq techniques éprouvées et vous montre quelle cause candidate les éléments étayent réellement — et à quelles questions vous n’avez pas encore répondu.
Pourquoi demande-t-il sans cesse ce qui n’est PAS touché ?
Parce que c’est la question qui départage les causes. Beaucoup d’explications collent à la défaillance ; très peu expliquent aussi pourquoi les sites, utilisateurs ou transactions épargnés l’ont été. Une cause candidate qui explique la défaillance mais pas la frontière cache généralement une distinction que personne n’a examinée.
Qu’est-ce que le test d’inversion ?
Vous vous demandez comment vous provoqueriez le problème délibérément si vous le vouliez. L’angle du sabotage contourne les réflexes défensifs — on décrit volontiers une étape d’approbation fragile ou un compte partagé qu’on ne présenterait jamais spontanément comme une faute de sa propre équipe. Tout levier qui s’avère avoir été en place devient une cause candidate à part entière.
Pourquoi une cause candidate est-elle entièrement écartée ?
Si vous indiquez une date de changement postérieure à la première observation du symptôme, ce changement ne peut pas en être la cause, quoi qu’il explique par ailleurs. C’est la seule élimination stricte de l’outil ; tout le reste est pondéré, pas absolu.
Combien de pourquoi dois-je atteindre ?
Trois à cinq. L’outil compte la profondeur mais ignore tout pourquoi qui reformule la réponse précédente, car c’est là que les chaînes s’enlisent d’ordinaire : les mots changent, la réflexion non.
Mes données d’incident sont-elles conservées quelque part ?
Non. Tout s’exécute dans votre navigateur, il n’y a pas de compte, et rien n’est écrit sur un serveur ni dans le stockage local. Fermez l’onglet et tout disparaît.
Les causes reviennent sans cesse ?
Une revue de la gestion des problèmes met au jour les schémas derrière les incidents répétés et attribue un responsable aux correctifs qui les arrêtent.