Introduction
FMAE : Failure Mode Analysis Effect
En français : AMDEC (Analyse Mode de défaillance, effets et criticité.
FMA : Failure Mode Analysis (Analyse des défaillances)
Le FMAE ou AMDEC est utilisé dans les DSI en tant que méthode systhématique dans la
gestion des risques (qualité) afin d’analyser les risques de défaillances potentiels ou réels au
sein des systèmes,
L'objectif du FMAE est de détecter les différentes failles possibles et de prévoir leurs
conséquences afin de mesurer les risques potentiels. L’objectif final est donc de
hiérarchiser ces modes de défaillance selon leur degré de criticité
Le FMAE définit le terme "mode de défaillance"(FMA) pour identifier les défauts ou les
erreurs, potentielles ou réelles, dans la conception d'un produit ou d'un processus, en
mettant l'accent sur celles qui touchent le client ou l'utilisateur final.
Un "effet de défaillance"(FMAE) est le résultat d'un mode de défaillance sur le produit ou la
fonction du système telle que perçue par l'utilisateur. Effets de défaillance peut être décrite
en termes de ce que l'utilisateur final peut voir ou d'expérience. L'étude des conséquences
des défaillances identifiées s'appelle l'analyse des effets.
Le FMAE priorise les défaillances en fonction de leur gravité, de leur fréquence et de leur
détectabilité :
La gravité est définie par le niveau de gravité des conséquences des défaillances ;
La fréquence est définie par la fréquence à laquelle les défaillances peuvent se
produire ;
La détectabilité fait référence au degré de difficulté de la détection des échecs.
Etapes du processus de la FMAE
Étape 1 : Identifier les défaillances et les effets potentiels
Étape 2 : Déterminer la gravité
Étape 3 : Jauger la probabilité d'occurrence
Etape 4 : Détection des pannes
Calcul du numéro de priorité du risque (NPR)
Étape 1 : Identifier les défaillances et les effets potentiels
La première étape du FMAE consiste à analyser les exigences fonctionnelles et leurs effets
pour identifier tous les modes de défaillance. Exemples : court-circuit électrique,
oxydation, rupture…
Énumérer tous les modes de défaillance par fonction en termes techniques, en considérant
le ou les effets ultimes de chaque mode de défaillance et en notant les effet(s) de la
défaillance.
Exemples d'effets de défaillance : surchauffe, bruit, arrêt anormal, blessure de l'utilisateur.
Étape 2 : Déterminer la gravité (S)
La gravité est le sérieux des conséquences des effets de défaillance. Le taux d’échec
détermine la gravité (S) sur une échelle de 1 à 10 où 1 est la gravité la plus faible et 10 est
la plus élevé.
Le tableau suivant montre la gravité typique de la FMAE :
Étape 3 : Jauger la probabilité d'occurrence (O)
Examiner la ou les causes de chaque mode de défaillance et la fréquence des défaillances
se produit.
Examinez des processus ou des produits et leurs modes de défaillance documentés. Toutes
les causes de défaillance potentielles devraient être identifiées et documentées en termes
techniques.
Les causes de défaillance sont souvent révélatrices de faiblesses dans la conception.
Voici quelques exemples de causes : algorithme incorrect, insuffisance ou de surtension,
environnement de fonctionnement trop chaud, froid,humide, etc.
Les modes de défaillance se voient attribuer un classement d'occurrence (O), toujours de 1
à 10, comme indiqué dans le tableau suivant.
Etape 4 : Détection des pannes (D)
Après avoir déterminé les mesures correctives, il faut les mettre à l'essai pour tester leur
efficacité. De plus, la conception devrait être vérifiée et les procédures d'inspection
spécifiées :
1. Les ingénieurs inspectent les contrôles actuels du système qui empêchent
l'apparition du mode de défaillance, ou détecter les défaillances avant qu'elles aient
un impact sur l'utilisateur/client.
2. Identifier les techniques utilisées avec des produits ou systèmes similaires pour
détecter les défaillances.
Ces étapes permettent aux ingénieurs de déterminer la probabilité de détection des
défaillances.
Ensuite, la combinaison des points 1 et 2 détermine la valeur de détection (D), qui indique
la probabilité que les défaillances soient détectées, et classe la capacité des actions
identifiées à remédier ou à supprimer des défauts ou de détecter des défaillances.
Plus la valeur de D est élevée, plus il est probable que la défaillance ne sera pas détectée.
Numéro de priorité du risque (RPN)
Après les étapes de base précédentes, les évaluateurs de risques calculent le risque RPN.
Ceux-ci influencent le choix de l'action contre les modes de défaillance. Le RPN est calculé
à partir des valeurs de S, O et D comme suit :
Les résultats devraient révéler les zones les plus problématiques, et les RPN les plus
élevées sont la priorité pour les mesures correctives. Ces mesures peuvent comprendre une
variété d'actions : nouvelles inspections, tests ou procédures, des changements de
conception, des composants différents, une redondance supplémentaire, limites modifiées,
etc.
Les objectifs des mesures correctives sont les suivants, par ordre de priorité :
Éliminer les modes de défaillance (certains sont plus faciles à prévenir que d’autres)
Minimiser la gravité des modes de défaillance
Réduire l'occurrence des modes de défaillance
Amélioration de la détection des modes de défaillance
Types AMDEC :
Document intéressant :
Exemple cas pratique :
https://fr.popularhowto.com/six-sigma-failure-mode-effects-analysis :
AMDEC / FMAE :
https://www.piloter.org/qualite/amdec.htm
Méthode des 5 pourquoi pour fixer définitivement un problème :
https://www.piloter.org/qualite/cinq-pourquoi.htm
Incident VS Problème :
Un incident est une dégradation ou une interruption imprévue du service. Il
s’agit d’un événement qui ne fait pas partie de l’exploitation normale d’un service et
qui entraîne ou peut entraîner une interruption ou une réduction de la qualité des
services et de la productivité des clients.
À l’inverse, un problème est la source d’un ou de plusieurs incidents dont la
cause fondamentale est inconnue.
Dans certains cas, des problèmes peuvent être identifiés parce que plusieurs
incidents présentent des caractéristiques communes. Les problèmes peuvent
également être identifiés sur la base d’un seul incident significatif, symptomatique
d’une erreur unique, dont la cause est inconnue. Dans d’autres cas, les problèmes
sont identifiés de façon proactive avant que des incidents connexes ne surviennent.
ITSM :
Information technology (IT) service management Gestion des services informatiques (IT)
Jargon du business analyst : https://bestofbusinessanalyst.fr/def-business-analysis/terminologie/
