ENSEIGNEMENT DE PROMOTION SOCIALE

Cours de
MAINTENANCE INFORMATIQUE
- Analyse des pannes et problmes -








H. Schyns
Mars 2009

Analyse des pannes et problmes Sommaire
H. Schyns S.1
Sommaire
1. INTRODUCTION

2. LE DIAGRAMME D'ISHIKAWA
2.1. La version originale
2.2. Maintenance informatique
2.3. Dveloppement logiciel
2.4. Avantages et inconvnients
2.5. En pratique
2.5.1. Mise en place
2.5.2. Analyse
2.5.3. Remdier
2.6. Conclusion
3. L'ARBRE DES CAUSES
3.1. Introduction
3.2. Analyser et comprendre
3.3. Les 5 Pourquoi ?
3.4. Agir, rparer et prvenir
3.5. Conclusion
4. EXERCICES

5. ANNEXES : CANEVAS

6. SOURCES


Analyse des pannes et problmes 1 - Introduction
H. Schyns 1.1
1. Introduction
Le but de ce document est de donner aux tudiants des outils de recherche et
d'analyse de pannes et de problmes informatiques.
Il est en effet apparu que, alors que les tudiants possdent pourtant une bonne
connaissance du fonctionnement d'une machine en tat de marche, leur intervention
sur une machine en panne est trs souvent cahotique et irrflchie. De mme, des
tudiants qui comprennent bien la dmarche algorithmique semblent perdus lorsque
le programme qu'ils dveloppent ne fait pas exactement ce qu'ils attendent.
Les deux outils proposs pour remdier cette situation sont :
- le diagramme des causes d'Ishigawa ou diagramme en artes de poisson
- l'arbre des causes de l'Institut National de Recherche et de Scurit.
Ces deux mthodes d'analyse sont utilises respectivement dans les dmarches de
qualit et dans l'analyse des accidents professionnels. Toutefois, il suffit de
quelques modifications pour qu'elles deviennent des outils puissants d'analyse des
problmes informatiques que ce soit au niveau du hardware ou du software; au
niveau du rseau ou dans la rdaction d'un petit programme.
La premire partie traite du diagramme d'Ishikawa. Ce chapitre introduit la version
traditionnelle - dite des "5M" et en dduit un schma adapt la maintenance
informatique et un autre adapt au dveloppement logiciel. Nous expliquons ensuite
les modalits pratiques d'utilisation de la mthode depuis le brainstorming initial,
jusqu'aux techniques de classement des solutions potentielles en fonction de
plusieurs critres.
La deuxime partie traite de l'arbre des causes. La notion centrale d'accident de
travail est remplace par celle d'incident informatique. L'incident informatique
pouvant tre n'importe quoi allant de l'intrusion d'un hacker dans le rseau la
simple panne de courant. Nous expliquons comment, partant de l'incident, il est
possible de remonter des causes humaines, matrielles et organisationnelles pour
ensuite concevoir, choisir et implmenter des solutions durables.
En fin de document, nous proposons quelques exercices ainsi que des canevas de
diagrammes en artes de poisson vierges, conus l'un pour la maintenance, l'autre
pour le dbogage d'applications; le troisime tant la version originale.
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.1
2. Le diagramme d'Ishikawa
2.1. La version originale
Le diagramme d'Ishikawa (
1
) ou diagramme en artes de poisson est un outil de
diagnostic des pannes et disfonctionnements. Il a t mis au point en 1982 par
Kaoru Ishikawa pour les chantiers navals Kawasaki.
Ce diagramme aide faire l'inventaire des causes possibles d'un problme mais on
peut aussi l'employer pour dvelopper un projet.
Dans sa forme premire, le diagramme rpartit les causes en cinq catgories
connues sous le nom des 5 M (fig. 2.1):

fig. 2.1 Point de dpart du diagramme de Ishikawa
- Matires premires (ang.: Materials) :
Tout ce qui entre l'tat brut ou semi-fini dans un processus.
Ce point concerne videmment les matires premires mais on peut y inclure
l'nergie et les pices dtaches.
Exemple : Les botiers d'alimentation n'ont pas les bons connecteurs.
- Matriel (ang.: Machinery) :
Tout ce qui permet de transformer les matires premires, de monter les pices
dtaches.
Ce point concerne l'appareillage, les machines et l'quipement mais aussi le
matriel informatique, les logiciels, et les technologies.
Exemple : L'atelier n'a pas la cl Torx T6 ncessaire au dmontage.
- Mthodes (ang.: Methods) :
Tout ce qui explique comment on procde pour transformer les matires
premires et comment on utilise le matriel.
Ce point concerne les modes opratoires ainsi que la recherche et
dveloppement.
Exemple : On ne dispose pas de la doc technique de la carte mre.
- Main-d'uvre (ang.: Manpower) :
Tous ceux qui appliquent les mthodes et utilisent le matriel.
Ce point concerne non seulement tous les intervenants mais aussi toute
l'organisation de l'entreprise.
Exemple : Le travail dpasse les comptences du stagiaire auquel on l'a confi.

1 Kaoru Ishikawa (1915 - 1989), ingnieur chimiste japonais prcurseur et thoricien de la gestion de la
qualit.
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.2
- Milieu :
Tout ce qui concerne l'endroit et les conditions dans lesquelles les mthodes et
le matriel sont utiliss.
Ce point concerne l'environnement, le positionnement, le contexte.
Exemple : La table de montage est encombre par les pices d'un autre PC.
Tous les "M" s'expliquent logiquement quand on considre le fonctionnement d'une
chane de production (fig. 2.2) :

fig. 2.2 Position des 5M dans une chane de production
Certaines versions du schma ajoutent quelques "M" supplmentaires :
- Mesures (ang.: Measurements) :
Tout ce qui concerne la collecte d'informations et le contrle du processus de
fabrication.
Ce point concerne videmment les appareils de mesure et leur fiabilit mais
aussi les enqutes auprs de la clientle et les tudes de march.
Exemple : Le multimtre est drgl.
- Moyens financiers (ang.: Money) :
Quoique l'argent ne soit pas une cause primaire, il a une influence sur les autres
facteurs.
Exemple : Les crdits pour acheter les nouveaux PCs ont t supprims.
- Management (ang.: Management) :
Tout de qui concerne la chane de passage des ordres et des consignes.
Ce point est souvent regroup avec la main d'uvre
Exemple : Aucune rponse notre demande pour de nouveaux PCs.
Chaque branche reoit ensuite d'autres causes ou catgories hirarchises selon
leur niveau d'importance ou de dtail (fig. 2.3).

fig. 2.3 Ajout des causes une catgorie
L'analyse se fait selon le principe du "brainstorming". Un des buts de cette mthode
est de produire des ides nombreuses et originales. Deux principes sous-tendent sa
construction :
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.3
- la suspension du jugement
- la recherche la plus tendue possible
Ces deux principes se traduisent par quatre rgles :
- ne pas critiquer,
- faire participer tout le monde,
- se laisser aller (ang.: freewheeling),
- rebondir sur les ides exprimes (ang.: hitchhike),
- chercher obtenir le plus grand nombre d'ides possibles.
Comme il s'agit d'un outil de brainstorming, aucune cause - aussi peu
probable soit-elle - ne peut tre exclue a priori !
Le diagramme connat de nombreuses variantes, chacune adapte un cadre
d'utilisation donn.
- en marketing, on utilise les 8P : Product, Place, Price, Promotion, People,
Processes, Policies, Procedures;
- en consultance, on partira plutt des 4S : Surroundings, Suppliers, Systems,
Skills.
Il est permis de combiner toutes les versions, d'ajouter d'autres catgories ou de
supprimer celles qui ne sont pas pertinentes. L'objectif tant d'aider l'organisation
de ses ides.
A titre d'exemple, le diagramme ci-dessous (fig. 2.4) reprsente la recherche des
facteurs qui pourraient tre responsables d'incidents sur un rseau informatique.

fig. 2.4 Diagramme d'Ishikawa appliqu au rseau (Source: Baccou Bonneville Consultants)
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.4
Le diagramme ci-dessous (fig. 2.5) tente d'expliquer pourquoi une voiture refuse de
dmarrer

fig. 2.5 Diagramme d'Ishikawa appliqu au dpannage automobile (source: BPI Consulting)
Comme le diagramme peut tre adapt au problme traiter, nous dvelopperons
dans les paragraphes suivants deux variantes conues pour faciliter le travail de
l'informaticien.
2.2. Maintenance informatique
Localiser la cause d'un problme informatique est rarement vident.
Pourtant, le dpanneur novice invoque rapidement une premire cause, entreprend
d'y remdier sans mme la valider, s'aperoit que le problme n'est pas rsolu; il
invoque alors une seconde cause, se lance dans une action et recommence le
scnario pour finalement s'apercevoir qu'il ne sait plus ce qu'il a fait ou non et, en
bout de course, laisser la machine dans un tat plus dsespr qu'elle ne l'tait au
dpart.
Une procdure plus efficace consiste :
- suivre mentalement le chemin suivi par les signaux ou par l'information
- construire au fur et mesure un diagramme des causes avant d'intervenir
physiquement sur la machine ou le rseau.
Nous proposons un diagramme des causes dcoup en deux parties (fig. 2.6) :
- les artes suprieures concernent le matriel (ang.: hardware)
- les artes infrieures concernent le logiciel (ang.: software)
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.5

fig. 2.6 Diagramme d'Ishikawa appliqu au dpannage informatique
En ce qui concerne le matriel, nous pouvons diviser les causes en trois catgories
(au moins) :
- le matriel proprement dit :
quel est le matriel ncessaire ? est-il prsent ? est-ce un modle compatible ?
- les connexions de ce matriel :
est-il correctement connect ou aliment ? est-ce le bon slot ? le bon cble ? le
bon sens ?
- sa configuration :
y a-t-il des jumpers, des boutons de rglage ? est-il proprement configur ?
Nous observons le mme genre de dcoupage en ce qui concerne les logiciels :
- le logiciel proprement dit (y compris les pilote) :
quel est le logiciel ou pilote ncessaire ? est-il prsent ? est-ce une version
compatible ?
- l'installation de ce logiciel :
est-il correctement install ? est-ce le bon disque ? le bon dossier ? le bon
serveur ?
- sa configuration et son utilisation :
y a-t-il des options, des proprits dfinir ? les valeurs sont-elles dfinies
correctement ?
Un avantage essentiel du diagramme est de permette de suivre ce qui a t vrifi
et ce qui reste faire. La machine et son diagramme peuvent ventuellement tre
transmis une autre personne pour la suite de l'examen.
Un autre avantage non ngligeable est que l'ensemble des diagrammes peut tre
conserv pour constituer une bibliothque de solutions ou une base des
connaissances (ang.: knowledge base). Cette base des connaissances peut elle-
mme tre informatise sous la forme d'un programme d'aide au diagnostic.
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.6
2.3. Dveloppement logiciel
Le diagramme d'Ishikawa peut tre adapt au dveloppement de logiciels et devenir
un guide de dbogage. En effet, chacun des "M" (6M) a son correspondant dans le
processus de dveloppement car un logiciel n'est rien d'autre qu'une usine de
traitement de donnes :
Ishikawa Gnral Version Software
Matires premires Saisies, donnes
Machines Routines
Modes opratoires Algorithmes
Main d'uvre Dveloppeurs
Milieu Ordinateur, OS, compil.
Mesures Tests


fig. 2.7 Diagramme d'Ishikawa appliqu au dbogage de logiciel
- les saisies faites, les donnes lues :
- correspondent-elles ce que le programme attend en type et quantit ?
- que se passe-t-il si l'utilisateur n'introduit pas exactement ce qui est attendu
(caractres au lieu de nombres ou rciproquement) ?
- la structure de lignes des fichiers correspond-elle l'ordre de lecture ?
- les routines du programme :
- passe-t-on les bons types en paramtres, dans le bon ordre ?
- par pointeur, par valeur ou par rfrence ?
- y a-t-il des points de sortie dont on ne tient pas compte ?
- y a-t-il confusion de nom ?
- sont-elles bien intgres au projet ?
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.7
- les algorithmes :
- s'appliquent-t-ils ce type de donnes ?
- comment sont-ils initialiss ?
- quelle est la rgle de terminaison ?
- existe-il des cas particuliers ?
- les dveloppeurs :
- sont-ils bien documents ?
- valident-ils leurs hypothses ?
- l'ordinateur, le systme d'exploitation, le compilateur :
- sont-ils compatibles avec le modle du programme (processeur 32/64 bits,
version OS, ) ?
- le compilateur est-il correctement paramtr ?
- l'environnement d'exploitation est-il semblable celui de dveloppement ?
- ses tests et leur emplacement :
- a-t-on test les variables pendant le traitement (mouchards) ?
- sont-ils placs au bon endroit ?
- teste-t-on bien ce qu'on croit tester ?
2.4. Avantages et inconvnients
Le champ d'application du diagramme d'Ishikawa est extrmement vaste.
C'est un outil simple et rapide :
- il permet de visualiser rapidement les causes possibles d'un problme et, par
consquent, de dterminer les moyens d'y remdier.
- il simplifie le travail d'analyse et, par consquent, facilite et stimule la recherche
de solutions.
- il demande la participation de tous les membres d'un groupe l'analyse et, par
consquent, limite le risque d'oubli de causes et permet une meilleure
implication du groupe dans la mise en oeuvre des solutions.
Le diagramme dIshikawa peut aussi tre utilis en sens inverse, pour modliser un
objectif damlioration d'un produit ou d'un processus. On ne cherche plus alors
viter leffet mais au contraire en favoriser lapparition.
Son principal inconvnient est d'ignorer les relations logiques qui peuvent exister
entre les diffrentes causes d'un problme.
De mme, l'enchanement des causes tant inconnu, il n'est pas (directement)
possible de voir l'impact d'une cause possible du problme donn sur un autre
problme. Par exemple, le fait que la dfaillance des PC soit due des botiers
d'alimentation sous-dimensionns ne permet pas directement de dduire que
d'autres appareils utilisant les mmes botiers pourraient aussi avoir des problmes.
Ces inconvnients seront pris en compte par une autre mthode, nomme "arbre
des causes", expose au chapitre suivant.
2.5. En pratique
Ainsi qu'il a t dit le but du diagramme en arte de poisson de faire l'inventaire des
causes possibles d'une panne ou d'un incident. C'est un travail de groupe qui
permet chacun d'apporter sa comprhension du problme et son exprience. La
constitution d'un diagramme amne donc un change de connaissances entre tous
les participants.
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.8
2.5.1. Mise en place
1 - Dfinir le problme rsoudre ou l'objectif vis.
2 - Tracer une longue ligne horizontale sur un tableau ou une feuille de papier et
crire ce problme ou objectif l'extrmit droite.
3 - Slectionner les catgories de causes du problme ou les domaines d'action
faire pour atteindre l'objectif. Chacune de ces catgories ou domaines fait l'objet
d'une arte du poisson et son nom est crit en regard.
4 - Faire un brainstorming en respectant les rgles - pour noncer des causes
possibles dans chacune des catgories. Chaque cause dtaille fait l'objet
d'une sous-arte (gnralement parallle l'axe mais ce n'est pas essentiel.
5 - Ajouter d'autres branchements en demandant continuellement ce qui peut varier
dans telle ou telle branche et pourquoi telle ou telle chose est arrive.
6 - Chaque fois qu'une ide est exprime, prciser quelle branche ou sous-
branche elle s'attache. Certaines ides peuvent prendre place sur plusieurs
artes.
7 - Poursuivre jusqu' ce qu'il n'y ait plus d'ides nouvelles. Il faut cependant noter
que les blocages temporaires sont frquents; ils indiquent que le groupe passe
un autre registre de penses qui fournira de nouvelles ides.
Il est important ce stade de ne faire ni critique ngative ni analyse. Ceci comprend
des critiques non verbales telle que les hochements de tte ou le fait de se retirer du
groupe.
Vrifier que personne ne fait de suggestion qui implique une personne absente de la
runion de travail.
2.5.2. Analyse
Quand toutes les ides ont t ajoutes au diagramme, il faut vrifier que chacun
comprend clairement toutes les ides mises.
Aprs cette phase de clarification nous passons la discussion proprement dite.
Celle-ci se droule en trois tapes :
Eliminer les Non-Causes
Dans cette tape, nous liminons toutes les ides qui ne sont manifestement pas la
cause du problme ou qui n'ont aucun lien avec lui. Toutefois, pour liminer une
ide, il faut runir l'accord de tous les participants. Si un participant refuse
l'limination, l'ide doit rester dans le diagramme comme cause possible.
D'autre part, les ides limines ne sont pas effaces du diagramme mais
simplement barres. Garder un inventaire complet des ides permettra de revenir
ultrieurement sur le problme afin de vrifier si nous avons rellement trouv la
cause relle du problme.
Evaluer la probabilit
Nous reprenons ensuite chaque ide et nous examinons dans quelle mesure elle
peut tre une cause du problme.
S'il reste peu de causes possibles, nous pourrons atteindre un consensus en
discutant chaque ide sparment.
Si les ides sont nombreuses ou si les participants sont nombreux, nous pouvons
faire un premier tri en passant chaque ide en reue et en demandant chaque fois
aux participants s'ils estiment qu'il s'agit d'une cause relle du problme. Les
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.9
apprciations sont donnes par un vote main leve. Cette mthode a l'avantage
de montrer chaque participant quelle est la perception des autres.
Le vote peut tre raffin en demandant aux participants de voter s'ils estiment que
l'ide reprsente une cause :
- trs probable (T)
- assez probable ou peu probable (A)
- non-probable (N)

L'option qui a reu le plus de voix est inscrite sur le diagramme, en regard de l'ide
correspondante.
Estimer la facilit
Nous examinons ensuite s'il est facile de vrifier chacune des causes possibles.
A nouveau, nous procdons un vote main leve par lequel les participants disent
s'ils estiment que la vrification est :
- trs facile (T)
- assez facile ou peu facile (A)
- pas facile (N)
Attention, il s'agit de savoir s'il est facile de vrifier s'il s'agit bien d'une cause et non
de savoir s'il est facile de remdier cette cause.
L'option qui a reu le plus de voix est nouveau inscrite sur le diagramme, en regard
de l'ide correspondante.
2.5.3. Remdier
A ce stade, chaque ide a reu deux estimations :
- une probabilit
- une facilit
Ceci permet de les placer dans un diagramme semblable celui de la fig. 2.8. Pour
des raisons d'efficacit, nous allons commencer par examiner toutes les causes qui
ont obtenu une cote TT, c'est--dire :
- trs probables
- trs faciles vrifier
Ces causes sont dans le coin suprieur droit du diagramme.
Analyse des pannes et problmes 2 - Le diagramme d'Ishikawa
H. Schyns 2.10
Probabilit
Facilit
Trs
Trs
Assez
Assez Pas
Pas
Progression
de l'examen
1
2
3

fig. 2.8 Progression de l'examen des causes possibles
Nous poursuivons avec les causes trs probables mais un peu moins faciles
vrifier (TA) ainsi que les causes moins probables mais faciles vrifier (AT)
(premire ligne oblique pointille). Nous continuons avec celles qui sont sur la
deuxime ligne oblique et ainsi de suite, pour terminer si nous n'avons vraiment
pas de chance avec la cause la moins probable et la plus difficile vrifier.
Ds qu'une ide est identifie comme tant la cause relle du problme, nous
pouvons laborer une solution, la mettre en uvre et surtout la valider !
En effet, bien que la solution ait t mise en uvre, il faut s'assurer que le problme
est bien rsolu. Il se pourrait que le problme ait de multiples causes et que nous ne
l'ayons corrig que partiellement. Il se peut aussi que nous ayons mal identifi la
cause ou que nous ayons appliqu une solution inadapte.
Si c'est le cas, nous reprendrons notre diagramme en arte de poisson d'origine et
nous le complterons en recherchent d'autres causes.
Il est intressant de conserver les diagrammes relatifs tous les problmes
rencontrs de manire constituer une bibliothque de connaissances (ang.:
knowledge base) qui pourra ventuellement faire l'objet d'une application
informatique.
2.6. Conclusion
Crer un diagramme en artes de poisson est amusant et intressant.
Comme ce type de diagramme est gnralement construit en groupe, tous ceux qui
y travaillent en tirent de nouvelles connaissances. Il nous permet aussi de raliser
combien nous en savons sur un processus : un diagramme peu fourni indique que
nous ne savons pas grand'chose alors qu'un diagramme trs riche signifie que nous
avons une bonne comprhension des phnomnes susceptibles d'avoir une
influence sur le processus analys.
Analyse des pannes et problmes 3 - L'arbre des causes
H. Schyns 3.1
3. L'arbre des causes
3.1. Introduction
L'arbre des causes est un outil d'analyse cre en 1970 par l'Institut National de
Recherche et de Scurit sur base des travaux de la CECA. Il a t conu
l'origine pour l'analyse des accidents de travail dans les mines de fer de Lorraine
mais nous pouvons en faire une excellente mthode d'analyse des incidents ou
problmes informatiques.
L'arbre des causes est la reprsentation graphique de l'enchanement
logique des faits qui ont provoqu l'incident ou le problme (
1
).
L'objectif est double :
- Comprhension
- rechercher les causes qui ont conduit l'incident, ce qui permet de dceler
des risques nouveaux ou de connatre des risques indits ou inavous.
- comprendre ce qui s'est pass.
- Prvention
- viter le retour d'un incident identique, en prenant des mesures immdiates,
- traiter les causes profondes,
- prvenir d'autres incidents, en supprimant les risques similaires dans
d'autres secteurs de l'entreprise ou du systme.
L'ide est que, en principe, il suffit d'liminer l'un des faits de l'arbre des causes pour
supprimer l'occurrence de l'incident.
3.2. Analyser et comprendre
Le but premier de l'arbre des causes est de comprendre l'incident. Il ne s'agit pas
de juger, ni de trouver un coupable mais d'identifier les causes de l'vnement. Une
fois les causes mises en vidence, nous pourrons identifier les facteurs ayant
gnr l'vnement qu'ils soient d'ordre technique, organisationnel ou humain.
En aucun cas les attaques personnelles n'ont place dans une enqute.
La premire tape consiste recueillir les donnes :
- collecter des faits prcis et objectifs
- examiner l'ensemble des lments de la situation de travail
- remonter le plus loin possible en partant de l'incident
- rechercher en priorit les faits inhabituels
Par fait, on entend :
- une action (p.ex.: le serveur distribue des pages web)
- un tat (p.ex.: Le serveur est l'arrt)

1 Pour ne pas alourdir la suite de l'expos, nous utiliserons exclusivement le terme "incident".
Analyse des pannes et problmes 3 - L'arbre des causes
H. Schyns 3.2
Un fait doit tre:
- Concret
- Prcis
- Avr
Un fait ne doit pas tre :
- une opinion (p.ex.: mon avis),
- un jugement (p.ex.: l'ingnieur systme est nul (
1
) ),
- une interprtation ou une hypothse (p.ex.: Je pense qu'il y a eu un orage (
2
) )
L'enqute est faite :
- le plus tt possible aprs l'incident, car
- chacun a encore les faits en mmoire,
- les faits sont encore facilement vrifiables,
- sur les lieux de l'incident;
- avec l'ensemble des personnes concernes.
Nous recherchons des faits et, pour chaque fait, nous demandons :
- Qu'a-t-il fallu pour que cela arrive ?
- Est-ce ncessaire ?
- Est-ce suffisant ?
Demander si le fait est ncessaire permet de supprimer les informations inutiles
tandis que demander si un fait est suffisant permet de dcouvrir d'autres faits qui
pourraient aussi expliquer la cause ou l'incident.
Pour organiser les faits, nous utilisons deux symboles qui reprsentent les faits
habituels ou permanents d'une part et les faits inhabituels d'autre part (fig. 3.1).
Fait permanent Fait inhabituel

fig. 3.1 Symboles utiliss dans l'arbre des causes
La mthode part du concept que, dans le cadre d'un tat permanent et d'une suite
de faits normaux, il ne doit pas y avoir d'incident. Par consquent, l'incident rsulte
d'un fait ou d'un tat inhabituel. L'analyse de l'accident consiste donc reconstituer
le processus en identifiant surtout les facteurs inhabituels qui ont concouru sa
survenance.
Chaque fait est reli un fait antcdent par un lien logique (fig. 3.2). En pratique,
nous construirons l'arbre de droite gauche afin que le sens de lecture (de gauche
droite) corresponde la chronologie des faits :

1 Par contre, dire que "l'ingnieur systme ne connaissait pas la procdure appliquer" est un fait.
2 Cette hypothse peut facilement tre vrifie et devenir un fait.
Analyse des pannes et problmes 3 - L'arbre des causes
H. Schyns 3.3
Panne de
courant
Serveur
l'arrt
Fait Antcdent
Liaison

fig. 3.2 Lien entre un fait et un antcdent
Chaque liaison est examine sous deux aspects (fig. 3.3) :
- son caractre ncessaire,
formalis par la question "Qu'a-t-il fallu pour que le fait survienne ?".
- son caractre suffisant,
formalis par la question "Cela a-t-il suffit pour que le fait survienne ?".
Suffisant ?
Ncessaire ?
Serveur
l'arrt
Panne
de
courant

fig. 3.3 Analyse du caractre ncessaire et suffisant du lien de causalit
Quand un antcdent n'est pas suffisant c'est qu'un autre antcdent tait aussi
ncessaire. Il peut donc y avoir plusieurs antcdents un fait. Nous parlerons
alors de conjonction de causes (fig. 3.4) :
Batterie
de BU
dcharge
Serveur
l'arrt
Fait
Antcdents
Panne de
courant
Conjonction

fig. 3.4 Causes conjointes : chacune ncessaire mais pas suffisante si seule
Inversement, un mme antcdent peut avoir plusieurs consquences.
L'antcdent est une cause commune plusieurs faits. Nous parlerons alors de
disjonction (fig. 3.5) :
Analyse des pannes et problmes 3 - L'arbre des causes
H. Schyns 3.4
Routeur
l'arrt
Site web
inaccessible
Tlphone
VOIP
en panne
Antcdent
Dpendants
Disjonction

fig. 3.5 Cause commune
Une conjonction de causes peut entraner une disjonction de faits dpendants (fig.
3.6)
Batterie
de BU
dcharge
Serveur
l'arrt
Faits Antcdents
Panne de
courant
Routeur
l'arrt

fig. 3.6 Conjonction de causes et consquences communes
Dans ce cas, nous essaierons de rorganiser les faits de manire mettre en
vidence un fait ou un tat intermdiaire (fig. 3.7) :
Batterie
de BU
dcharge
Serveur
l'arrt
Antcdents
Disjoncteur
dclenche
Routeur
l'arrt
Panne de
courant
Etat ou fait
intermdiare
Faits

fig. 3.7 Rorganisation des faits et apparition d'un tat intermdiaire
Analyse des pannes et problmes 3 - L'arbre des causes
H. Schyns 3.5
3.3. Les 5 Pourquoi ?
Pour rechercher les faits, nous pouvons reprendre les catgories d'Ishikawa. Que
s'est-il pass d'inhabituel en ce qui concerne :
- les matires premires / nergie,
p.ex.: il y a eu une panne de courant
- les machines,
p.ex.: le serveur s'est arrt
- la main d'uvre,
p.ex.: le technicien de garde ne savait pas o sont les disjoncteurs
- les modes opratoires et procdures,
p.ex.: aucun message d'alerte n'a t transmis
- le milieu ?
p.ex.: le local des serveurs tait verrouill et inaccessible
La question essentielle de la dmarche est "Pourquoi ?"
Toutefois, il est peu probable que nous arrivions la cause primaire de l'incident
avec une seule question. De plus, en nous contentant d'une rponse, risquons de
passer ct d'autres causes tout aussi pertinentes.
Une technique largement utilise est appele "les 5 pourquoi ?". Elle consiste
poser remonter de cause en cause en posant cinq fois successivement la question
du pourquoi :
- Pourquoi le serveur est-il l'arrt ?
Parce qu'il y a eu une panne de courant pendant la nuit.
- Pourquoi y a-t-il eu une panne de courant ?
Parce qu'il y a eu un orage sur la rgion.
- Est-ce qu'il suffit d'un orage pour mettre le systme en panne ?
Non car il y a un systme d'alimentation de secours
- Pourquoi le systme de secours n'a-t-il pas pris le relais ?
Parce que les batteries n'taient pas charges.
- Pourquoi les batteries taient-elles dcharges ?
Parce que le chargeur tait rest dconnect.
- Pourquoi le chargeur tait-il dconnect ?
Parce qu'on avait eu besoin de la prise pour alimenter un autre appareil.
- etc
Nous arrtons les questions dans les cas suivants :
- nous aboutissons sur une action ou un tat normal.
p.ex.: il y a eu un orage sur la rgion
Le fait qu'il y ait un orage est un tat normal sous nos latitudes, surtout en t. Il
est inutile d'en rechercher les causes.
p.ex.: le webmaster a effectu une mise jour du site web
Mettre un site web jour est une action normale qui fait partie du travail d'un
webmaster. Il est inutile d'en rechercher les causes.
- l'action ou l'tat concerne la vie prive d'un intervenant.
p.ex.: il a fait la fte chez lui, il s'est endormi, il n'a pas entendu le tlphone.
Analyse des pannes et problmes 3 - L'arbre des causes
H. Schyns 3.6
Aucun plan d'action ne pourra tre mis en place sur des sujets qui sortent du
champ de comptence de l'entreprise. Ds lors, cet enchanement de causes
ne doit pas apparatre dans le diagramme.
- la cause est inconnue.
p.ex.: L'lectricien a fait des travaux sur le rseau lectrique.
Dans ce cas, nous utiliserons un symbole avec un point d'interrogation.
3.4. Agir, rparer et prvenir
Plus nous posons des questions, plus nous progressons dans la comprhension de
l'incident. En gnral, l'arbre des causes prsente une certaine structure. Partant
de l'incident, nous rencontrons successivement :
- des causes qui mettent en vidence le facteur humain,
- des causes qui sont essentiellement d'origine matrielle ou technique,
- des causes lies des questions d'organisation gnrale.

fig. 3.8 Les causes s'organisent en couches de diffrents types
Plus nous nous loignons de l'incident proprement dit (arrt du serveur) et plus la
tentation est grande de ne retenir que les causes qui sortent de notre sphre de
responsabilit (
1
).
A l'inverse, les causes plus loignes de l'incident sont communes un plus grand
nombre de situations. De ce fait, elles sont susceptibles d'tre l'origine d'un plus
grand nombre incidents potentiels si une conjonction malheureuse apparat.

1 Nous pourrions faire un parallle intressant avec le mythe d'Adam et Eve.
Analyse des pannes et problmes 3 - L'arbre des causes
H. Schyns 3.7

fig. 3.9 Une cause loigne peut avoir de nombreuses consquences si
Pour tablir un plan d'action efficace, nous allons, pour chacune des causes (
1
) :
- imaginer une ou plusieurs solutions adaptes,
- valuer la faisabilit des solutions proposes.
- rechercher si la cause peut avoir un impact dans un autre domaine,
Par exemple, en reprenant le schma de la fig. 3.7 :
Pour liminer Que faire ?
Serveur l'arrt a1 Prvoir un serveur de backup dans un autre
endroit ou pays
a2 Prvoir un site miroir sur un autre serveur
a3 Emettre une alarme vers le service de garde
Routeur l'arrt b1 Prvoir un routeur de backup dans un autre
endroit
b2 Mettre le routeur sur un autre circuit
d'alimentation que le serveur
b3 Emettre une alarme vers le service de garde
Panne de courant c1 Emettre une alarme vers le service de garde
c2 Installer un groupe lectrogne
Batterie dcharge d1 Doubler la capacit des batteries
d2 Mettre des batteries recharge rapide
d3 Emettre une alarme si la batterie est
dcharge
d4 Prvoir une routine de surveillance de l'tat
des batteries
Disjoncteur dclenche e1 Installer une protection surtensions
e2 Renforcer le circuit de mise la terre
Chacune des solutions est ensuite value sur base de plusieurs critres.

1 C'est prcisment l'intrt du systme : en ayant mis en vidence un grand nombre de petites causes, on
peut mettre en uvre un grand nombre de solutions.
Analyse des pannes et problmes 3 - L'arbre des causes
H. Schyns 3.8
Les premiers critres employs sont gnralement :
- le cot
- la facilit de mise en uvre.
Il faut galement - et surtout voir si la solution est prventive ou curative et quelle
est sa porte :
- limine-t-elle (quasi-) totalement le risque d'incident ?
p.ex. serveur de backup ailleurs ou un site miroir sur un serveur remote
- diminue-t-elle le risque et les consquences de l'incident sans le supprimer ?
p.ex. augmenter la capacit des batteries est favorable mais sans effet si la
panne de courant est plus longue
- a-t-elle un impact nul sur le risque d'incident mais peut-elle ventuellement
limiter les consquences ?
p.ex. installer une alarme n'a aucun impact si personne ne ragit.
Nous pouvons aussi examiner si la solution
- est durable dans le temps ?
p.ex. une routine de surveillance des batteries risque de tomber dans l'oubli
aprs quelques temps.
- est valable pour plusieurs postes ?
p.ex. installer un groupe lectrogne assez puissant peut intresser d'autres
utilisateurs.
Chacune des solutions est value face chacun des critres et reoit par exemple
une cote allant de 0 (trs mauvais) 5 (excellent). Cette cotation est videmment
subjective mais elle permet de classer les diffrentes solutions les unes par rapport
aux autres. Eventuellement, nous pouvons appliquer un facteur de pondration
chaque critre.
Solution a1 a2 a3 b1 b2 b3 c1 c2 d1 d2
cot 2 4 5 3 4 5 5 1 4 3
facilit 2 4 5 2 3 5 5 1 4 4
limine totalement le risque 5 5 0 5 3 0 0 5 4 3
durable dans le temps 5 4 1 5 4 1 1 5 4 4
valable pour plusieurs postes 4 3 1 4 1 0 2 4 3 3
Somme 18 20 12 19 15 11 13 16 19 17
Somme des carrs 74 82 52 79 51 51 55 68 73 59
Nous effectuons la somme des cotes et nous appliquons en priorit les solutions qui
ont obtenu le score le plus lev.
Une variante plus correcte d'un point de vue gomtrique consiste effectuer la
somme des carrs des cotes. En effet, chaque critre peut tre vu comme un axe
d'un systme [ n ] dimensions. Dans ce systme les meilleures solutions sont
celles qui sont simultanment "au bout" de plusieurs axes donc, les plus loignes
de l'origine (fig. 2.8). Ds lors, par Pythagore, ce sont celles pour lesquelles la
somme des carrs est maximale.
Analyse des pannes et problmes 3 - L'arbre des causes
H. Schyns 3.9
3.5. Conclusion
La mthode de l'arbre des causes est une mthode efficace, condition qu'elle
repose sur un travail de groupe. Elle doit impliquer chacun des acteurs et viter que
cela ne devienne le travail d'un spcialiste.
Les causes matrielles sont relativement faciles traiter, car les solutions ne
dpendent que d'une implication des dcideurs "locaux" et des moyens accords
leur ralisation.
Par contre, les causes qui touchent l'organisation de l'entreprise, aux mthodes de
travail et au facteur humain sont beaucoup plus difficiles traiter. Elles demandent
souvent des dlais plus longs et ncessitent une volont affirme de la Direction.
La mthode a aussi l'avantage d'amener un changement d'attitude l'gard du
fonctionnement du systme grce :
- la sensibilisation aux problmes potentiels,
- le dialogue entre les intervenants,
- la solidarit entre les personnes concernes.
Analyse des pannes et problmes 4 - Exercices
H. Schyns 4.1
4. Exercices
Exercice 1
Construire les diagrammes d'Ishikawa relatifs aux problmes suivants :
- Un utilisateur vient de s'abonner auprs d'un fournisseur d'accs Internet. Il a
install tous les appareils et tous les cbles mais n'arrive pas accder
Internet.
- J'ai tlcharg une vido depuis Internet mais je n'arrive pas la visualiser sur
mon ordinateur.
- Un utilisateur a fait un upgrade de son systme d'exploitation et maintenant, son
ordinateur refuse de dmarrer.
Exercice 2
Etablissez l'arbre des causes relatif l'incident suivant :
Lundi matin, notre service de clientle reoit une plainte d'un client disant que notre
site web est rest inaccessible pendant tout le week-end.
L'enqute a rvl que notre serveur web s'est arrt dans la nuit de vendredi
samedi suite une panne de courant gnrale due un violent orage sur la rgion.
Le serveur de back-up s'est arrt galement car il est branch sur le mme circuit
lectrique. En principe, l'onduleur (UPS) aurait d prendre le relais et alimenter le
systme pendant 24h au moins mais ses batteries taient compltement
dcharges. Il est apparu que vendredi matin, dans le cadre des travaux
d'extension de l'installation lectrique dans le btiment, des lectriciens ont
dconnect le circuit sur lequel ils devaient intervenir sans s'apercevoir que ce circuit
alimentait aussi nos serveurs web et l'onduleur. Personne ne s'est aperu de la
panne car l'onduleur a pris le relais pendant la journe, vidant ses batteries. En fin
de journe, les lectriciens ont rtabli le courant mais les batteries n'ont pas eu le
temps de se recharger avant le dbut de l'orage.
Imaginez un maximum de solutions en vous servant de chacun des faits. Pour
chaque fait, repensez aux catgories d'Ishikawa : peut-on intervenir sur
- les matires premires / nergie,
- les machines,
- la main d'uvre,
- les modes opratoires et procdures,
- le milieu ?
Dfinissez une liste de critres d'valuation des solutions et hirarchisez-les selon
ces critres.


H. Schyns 5.1
5. Annexes : canevas


H. Schyns 5.2


H. Schyns 5.3

Analyse des pannes et problmes 6 - Sources

H. Schyns 6.1

6. Sources
- Diagramme de Ishikawa
Anonyme
Wikipedia
fr.wikipedia.org/wiki/Diagramme_de_causes_et_effets
- Diagramme de Ishikawa
Erwan NEAU
Innovation et information stratgique
erwan.neau.free.fr/Toolbox/Diagramme_d_ISHIKAWA.htm
- Analyzing Cause and Effect Diagrams
William McNeese
BPI Consulting, LLC
www.spcforexcel.com/analyzing-cause-and-effect-diagrams
- Le Diagramme de "Causes Effet" de Kaoru Ishikawa
Pierre CLIER
ENSET de Mohammedia
www.enset-media.ac.ma/cpa/diagramme_ishikawa.htm
- Les outils des mthodes de rsolution de problmes
Diagramme de "Causes Effet"
Rmi BACHELET
Ecole centrale de Lille
rb.ec-lille.fr/Cours_de_Qualite.htm
- Le diagramme de causes et effet d'Ishikawa
Baccou Bonneville Consultants
makeitstrategic.com/index.php/2008/02/02/diagramme-causes-effet-
ishikawa?blog=5
- Savoir construire l'arbre des causes
Acadmie de Caen
Enseignement de la Prvention des Risques Professionnels
www.discip.ac-caen.fr/
risques.professionnels/telechargement/jour2/Methode_ADC.ppt
- Analyser les accidents
Mthode de l'arbre des causes
M. Eudes, M. Lesbats
Universit de Bordeaux Dpartement HSE
hse.iut.u-bordeaux1.fr/lesbats/H-arbre des causes/ADC.HTM
- Mthodes en prvention
Arbre des causes
CRAM Bourgogne et Franche-Comt
www.cram-bfc.fr/prevention/PDF_prevention/arbre_des_causes.pdf