Attention au vocabulaire !

La traduction française de "Fault Tree Analysis" est l'Arbre des défaillances, pas l'arbre des causes.

L'arbre des causes est un outil d'application réglementaire, utilisé pour retrouver a posteriori les causes d'un dommage qui s'est produit : Raoul s'est cassé la jambe. Qu'a-t-il fallu pour cela ? Qu'il chute de l'échafaudage. Est-ce nécessaire ? Oui. Est-ce suffisant ? Oui. On n'a donc qu'une branche qui relie la fracture et la chute. A présent : qu'a-t-il fallu pour qu'il chute de l'échafaudage ? Qu'il glisse sur la planche. Est-ce nécessaire ? Oui. Est-ce suffisant ? Non. Il a fallu aussi que le garde-corps ne soit pas installé, et aussi que Raoul n'ait pas attaché sa longe. On a donc 3 liens qui mènent à la chute. Et on va rechercher les causes des causes (pour qu'il glisse, il a fait un mouvement brusque et les planches étaient mouillées et il n'avait pas ses chaussures de sécurité, etc.  Dans un arbre des causes, on n'a que des associations de type "et". Il ne sert qu'à expliquer un unique évènement. Mais avec uniquement des "et", il suffit d'éliminer une unique cause pour que l'accident ne se reproduise plus.

L'arbre des défaillances est un outil d'analyse a priori. L'évènement redouté est que le réservoir d'air comprimé du compresseur explose. Il peut exploser avant que la pression haute, celle à laquelle la soupape de sécurité est censée se déclencher, ne soit aitteinte, ou après. Si c'est avant, les causes sont : une erreur de fabrication (matériau utilisé moins résistant que prévu), ou alors une usure des matériaux, ou encore un choc extérieur. Si c'est après, il faut que la soupape ne se soit pas déclenchée et que la pression ait augmenté au-delà de la consigne. Etc. Dans un arbre des défaillances, on a des associations de type "et" et de type "ou". Il sert à imaginer tous les les combinaisons de facteurs amenant à l'évènement indésirable. Et là, il va falloir mettre en place une action par "ou". 

Merci Anthony pour ce rappel de l’utilisation de l’arbre des causes.

J'ai longtemps travaillé dans une entreprise de haute technologie qui utilise la version présentée par Anthony avec des « OU » et des « ET », sans bloquage sémantique.. C'était et c'est l'outil de recherche des causes profondes des cas complexes.
Partant du constat, on émet des hypothèses (des scénarios possibles) qui sont reliées avec un « OU » au problème constaté.
Le travail consiste ensuite à se demander quels éléments, au moins une action et au moins une condition (Cf Apollo root causes ou Relaty charting de Dan. L Gano) sont nécessaires à la réalisation de ce scénario ; ces éléments sont reliés par un ET à l'effet qu'ils engendrent. Comme pour le niveau du dessus, il peut y avoir plusieurs sous-scénarios possibles qui engendrent le scénario du dessus. À chaque niveau de pourquoi, pour chaque scénario, on essaye de vérifier si ce scénario peut être abandonné lorsque les faits constatés rendent impossible l'un des éléments générateur, ou, s'il doit être encore développé en cherchant ses antécédants.

Les bénéfices de cette méthode
• On peut partir des scénarios imaginés lors des AMDEC (FMEA) réalisées précédemment, y rajouter une analyse type Ishikawa, une réflexion d'experts voire une déduction faite à partir des changements et particularités rencontrés par rapport à des cas similaires (Kepner Tregoe, ADEQUA ou Face-it2).
• l'analyse des scénarios possibles, permet d'orienter les investigations complementaires nécessaires pour déterminer si oui ou non, dans notre cas présent, un scénario est plausible c'est à dire si ses antécédents ont pu exister.
• Tant qu'un scénario et au moins un de ses sous-scénarios reste plausible, l'analyse continue. Il n'est en effet pas rare, surtout quand on n'a plus accès à tous les éléments physiques du problème mais uniquement à quelques enregistrements de télémesure, qu'un scénario soit déclaré non pertinent après avoir parcouru trois ou quatre niveaux de causes (niveau de pourquoi).
• On peut avoir à la fin plusieurs scénarios probables sans pouvoir les départager avec certitude, la recherche et le choix de solutions devra en tenir compte.
• L'études de tous les scénarios permet ensuite d'enrichir l'AMDEC réalisée préalablement sur le sujet (ou de la commencer), c'est l'une des meilleures façons de mémoriser les acquis de l'analyse pour la transformer en REX (Retour d'Expérience).


Un tel arbre des causes associant, les causes envisagées, celles qui ont été par la suite éliminées (et les raisons de leur élimination) et celle ou celles qui reste(nt) plausible(s), à défaut d'être certaines est un excellent support de présentation et de restitution à un CODIR.
J'ai même souvenir d'avoir présenté à un CODIR sur un produit avec plusieurs millions d'euros d'enjeux, un arbre des causes présentant explicitement un scénario nommé «scénario non identifié ». Le résultat à été très positif; le CODIR a apprécié d'avoir une vision sur d'autres scénarios et sur les raisons de leurs abandons, et aussi de constater que le groupe de travail s'était posé la question « avons-nous réellement tout envisagé? ». La culture du doute et un peu d'humilité sont souvent les bien venus.


Une limite:  pour les cas très simple ou évidents pour lesquels l'arbre doit être très très simplifié.

Enfin, personnellement j'utilise Xmind comme outil graphique pour dessiner les arbres des causes; les autres outils de dessin de cartes mentales sont bien sûr envisageables.

Bonjour

En conjuguant les 5M et les 5 pourquoi, on renforce la démarche et on démontre l'efficience de l'analyse et la robustesse du système de surveillance

Le "5 pourquoi" est le moteur de la construction de l'arbre des causes, il est donc indispensable.
Le "5M" n'est qu'une des méthodes de recherche de causes possibles ; il en existe d'autres, "particularités/changements" par exemple.

Ce qui est en plus nécessaire :
• identifier à chaque niveau les scénarios possibles
• identifier toutes les causes (facteurs de causes), par exemple : carburant, comburant et initiateur en cas d'explosion et de poursuivre le "5 pourquoi" de façon raisonnée sur chaque branche.
• de confronter au plus tôt chacun des éléments de l'arbre des causes avec les faits pour vérifier si l'élement a réellement pu se produire. D'où l'importance de la description du problème qui, pour être complète, doit utiliser le "est/n'est pas" (is/is not).

Enfin, ne pas oublier que :
• à un niveau donné, c'est la conjonction des éléments des causes antérieures qui conduit à l'effet ; l'action peut donc cibler un seul de ses éléments ce qui permet de chercher l'action la plus efficiente.
• lorsque que l'on ne sait pas départager plusieurs scénarios probables (scénarios compatibles des faits), faire voter un groupe est une mauvaise solution, les biais cognitifs ayant une top grande inffluence sur l'issue du vote. Le seul choix raisonnable repose sur une analyse de probabilité ou sur une décision argumentée par une analyse de risques de l'autorité concernée.

Quand arrêter un "5 pourquoi" ou "5 pourquoi raisonné"  : on l'arrête non pas à 5 niveaux, mais quand :
• l'élement de cause est incontournable (inutile de chercher, quand un réservoir a prit feu, pourquoi il y avait du carburant, c'est sa fonction ; inutile de chercher pourquoi il y avait en iceberg dans l'océan lors de la traversée du Titanic)
• l'élément de cause est hors de portée d'action du commanditaire de l'analyse du problème (certes, le problème vient du sous-traitant qui est piloté par le responsable des achats mais, moi, responsable de production, tant que je ne l'aurais pas convaincu qu'il doit traiter ce problème, il faut que je continue à avancer... et donc que je trouve une solution, que, certes, j'espère temporaire)