Analyse des modes de défaillance, de leurs effets et de leur criticité (AMDEC)
L'analyse des modes de défaillance, de leurs effets et de leur criticité (AMDEC, en anglais FMEA ou FMECA) est une méthode d'analyse de risque qui recense les façons dont un produit, un processus ou un logiciel peut manquer à sa fonction. Pour chaque défaillance, elle établit l'effet, la cause et le contrôle qui la détecterait. Trois cotes de 1 à 10 la qualifient: la gravité de l'effet, l'occurrence de la cause et la capacité du contrôle à la détecter. Leur produit, ou une table de priorité, ordonne les actions. Selon la norme IEC 60812, l'analyse devient une AMDEC, le C de criticité, quand ce classement porte au moins sur la gravité; la norme traite l'AMDE et sa variante AMDEC dans un même texte. L'AMDEC travaille avant l'incident, sur une conception ou un processus.
Objectif
L'AMDEC répond à une question posée avant la mise en service: comment ce processus ou ce système peut-il échouer, et quelles défaillances faut-il traiter d'abord? Elle remplace l'inventaire des craintes exprimées en séance par un balayage fonction après fonction, puis par un classement.
La méthode soutient deux décisions. La première porte sur la mise en service: le risque qui reste après les actions est-il acceptable? La seconde porte sur les moyens: quelles actions financer, dans quel ordre, avec quel responsable. Le classement tranche cette seconde question, là où la défaillance dont on parle le plus fort l'emporterait.
Le livrable est le registre AMDEC, un tableau à une ligne par mode de défaillance ou par cause. Chaque ligne porte le mode, son effet, sa cause, les contrôles en place, les trois cotes, la priorité, l'action décidée, son responsable, son échéance et les cotes recalculées après l'action. Le registre vit aussi longtemps que le produit ou le processus: chaque modification le rouvre.
La méthode vient de l'armée américaine, qui la décrit dès 1949 dans la procédure MIL-P-1629. La NASA l'a reprise pour le programme Apollo, puis l'industrie automobile en a fait un standard de fournisseur. Deux textes la fixent aujourd'hui: la norme internationale IEC 60812, générique, et le manuel commun de l'AIAG et du VDA, publié en 2019 pour l'automobile et lu bien au-delà.
Usage
Quand l'utiliser
- Avant une mise en production: corriger une défaillance sur le papier coûte moins qu'après son premier incident.
- Processus, système ou interface modifié: recenser ce que le changement peut casser dans les fonctions existantes.
- Défaillance coûteuse: sécurité des personnes, conformité légale, perte financière définitive ou atteinte à la réputation.
- Liste de risques trop longue pour être traitée en entier: le classement dit où placer le budget d'amélioration.
- Savoir dispersé entre métier, informatique et exploitation: la séance réunit ces personnes sur un seul registre, ligne par ligne.
- Fournisseur de l'industrie automobile: le client attend un registre établi selon le manuel AIAG-VDA.
- Données d'incidents disponibles: tickets, réclamations et retours terrain fondent les cotes d'occurrence sur des faits.
Quand ne pas l'utiliser
- Défaillance déjà survenue, à expliquer: chercher sa cause avec l'analyse des causes racines.
- Risques stratégiques ou de portefeuille, sans objet à décomposer: les tenir dans un registre selon l'analyse et gestion des risques.
Description
La méthode classique, celle que décrit IEC 60812, enchaîne décomposition, recherche des défaillances, cotation, classement et actions. Le manuel AIAG-VDA de 2019 découpe le même travail en sept étapes et rend explicite ce que la forme classique laissait implicite: aucune défaillance ne s'inscrit au registre avant la quatrième étape. Les sept étapes s'appliquent aussi à un processus administratif, comme le montre l'exemple.
L'AMDEC de conception porte sur un produit, un système ou un logiciel. L'AMDEC de processus porte sur une suite d'étapes: fabrication, traitement administratif, exploitation informatique. Le manuel AIAG-VDA ajoute une troisième famille, pour les fonctions de surveillance d'un véhicule en service. L'analyste d'affaires rencontre surtout l'AMDEC de processus et l'AMDEC d'une application ou d'une interface.
1. Planifier et préparer
La préparation fixe le périmètre: où commence et où finit l'objet analysé, quelles interfaces entrent dans l'analyse. Elle fixe aussi l'équipe. Quatre à six personnes suffisent, à condition de réunir ceux qui connaissent le processus au quotidien, ceux qui connaissent le système et une personne de la qualité ou du risque. L'analyste d'affaires anime les séances et tient le registre.
Les trois échelles de cotation s'arrêtent avant la première séance. Le manuel AIAG-VDA en publie pour l'automobile; hors de l'automobile, l'organisation écrit les siennes. Chaque niveau porte un critère que deux personnes appliquent sans se concerter: «9, perte de fonds non récupérable ou manquement légal» plutôt que «9, très grave». Une échelle négociée pendant la séance se déplace au fil des lignes, et le classement final compare des cotes incomparables.
2. Décomposer l'objet
L'analyse de structure découpe l'objet en niveaux. Pour une AMDEC de conception, le système se découpe en sous-systèmes, puis en composants. Pour une AMDEC de processus, le processus se découpe en étapes, et chaque étape en éléments de travail. Les éléments de travail sont les catégories de causes de l'étape: les personnes, les machines ou logiciels, les matières consommées et le milieu de travail. Un diagramme de contexte, un modèle de processus ou une décomposition fonctionnelle sert de support. Si ce support manque, l'équipe le construit avant la première séance.
Sauter cette étape est la faute la plus coûteuse de la méthode. Une équipe qui liste d'emblée «ce qui peut mal tourner» produit des défaillances à des niveaux mélangés, des doublons et des trous, et personne ne sait ce qui n'a pas été examiné. La décomposition liste les éléments à balayer et dit donc quand l'analyse est complète.
3. Établir les fonctions
Chaque élément reçoit sa fonction, formulée par un verbe et un complément, avec un critère de performance: «transmettre à la banque l'ordre de paiement validé, une seule fois, au plus tard le 23 du mois». Les fonctions se relient d'un niveau à l'autre: la fonction d'une étape contribue à celle du processus. Sans critère, la défaillance ne se définit pas, car une défaillance est un écart à ce critère.
4. Analyser les défaillances
Un mode de défaillance est la manière dont un élément manque à sa fonction. L'équipe cherche, pour chaque fonction, l'absence, l'exécution partielle, l'excès, le retard et l'exécution intempestive. L'ordre n'est pas transmis, il est transmis incomplet, deux fois, trop tard ou modifié. Chacun de ces modes forme une ligne.
L'effet est la conséquence du mode, vue au niveau supérieur jusqu'au client, à l'utilisateur ou à l'autorité. La cause est ce qui, au niveau inférieur, produit le mode. Le manuel AIAG-VDA relie ces trois termes en une chaîne de défaillance: le mode d'un élément est la cause d'une défaillance au niveau supérieur et l'effet d'une défaillance au niveau inférieur. La chaîne relie les lignes du registre entre les niveaux de la décomposition, là où une liste plate les juxtapose.
Un mode a souvent plusieurs causes. Chaque cause prend sa propre ligne, parce qu'elle a sa propre occurrence et ses propres contrôles. Une ligne qui regroupe trois causes reçoit une seule cote d'occurrence, et cette cote ne décrit aucune des trois.
5. Analyser le risque
Coter
Chaque ligne reçoit trois cotes de 1 à 10. Elles portent sur trois objets, et confondre ces objets fausse le registre.
La gravité (G) cote l'effet le plus grave du mode. Elle ne dépend ni de la cause ni du contrôle: un versement de salaire à un tiers reste grave, qu'il soit rare ou fréquent. L'occurrence (O) cote la probabilité que la cause se produise et entraîne le mode, compte tenu des mesures de prévention en place, celles qui empêchent la cause. La détection (D) cote la capacité des contrôles de détection à repérer le mode ou sa cause avant que l'effet n'atteigne le client. L'échelle de détection est inversée: 1 signifie que le contrôle détecte à coup sûr, 10 qu'aucun contrôle n'existe ou qu'il ne voit pas ce mode.
Coter D d'après la rareté du mode revient à compter l'occurrence deux fois. Un contrôle qui intervient après que l'effet s'est produit, comme un rapprochement bancaire le lendemain du versement, reçoit une cote de détection haute: il limite les dégâts sans arrêter l'effet.
| Cote | Ce qu'elle cote | 1 signifie | 10 signifie | L'action qui la baisse |
|---|---|---|---|---|
| Gravité (G) | L'effet le plus grave du mode | Effet imperceptible | Atteinte à la sécurité ou manquement légal | Modifier la conception ou le processus pour supprimer ou atténuer l'effet |
| Occurrence (O) | La cause, compte tenu des mesures de prévention | Cause écartée par la conception | Cause presque certaine à chaque exécution | Supprimer la cause ou ajouter une mesure de prévention |
| Détection (D) | Le contrôle de détection, avant que l'effet n'atteigne le client | Le contrôle détecte à coup sûr | Aucun contrôle ou un contrôle qui ne voit pas ce mode | Ajouter un contrôle de détection ou le rendre plus sûr |
Classer par le nombre de priorité de risque
La méthode classique multiplie les trois cotes: le nombre de priorité de risque (NPR, en anglais RPN) vaut G × O × D et va de 1 à 1000. Sur ces mille valeurs, le produit n'en atteint que 120. Le registre se trie par NPR décroissant, et les lignes du haut reçoivent une action.
Donald Wheeler en a montré les défauts. Les trois cotes sont ordinales: elles rangent sans mesurer. Un 8 n'est pas deux fois un 4, et le produit de trois rangs n'a pas de sens arithmétique. Des risques différents obtiennent le même NPR.
| G | O | D | NPR | Ce que la ligne décrit |
|---|---|---|---|---|
| 10 | 1 | 10 | 100 | Effet catastrophique, cause rare, aucun contrôle ne la voit |
| 5 | 5 | 4 | 100 | Effet moyen, cause occasionnelle, contrôle assez sûr |
| 2 | 10 | 5 | 100 | Gêne mineure, cause presque systématique, contrôle incertain |
Le défaut le plus lourd touche la gravité. Une défaillance catastrophique mais rare, ou bien contrôlée, obtient un NPR modeste et se retrouve sous des gênes fréquentes. Un seuil fixe aggrave le problème: une règle «action au-delà de 100» pousse l'équipe à coter juste en dessous, et elle laisse passer la première ligne du tableau. Une équipe qui garde le NPR fixe aussi une règle de gravité: toute ligne de gravité 9 ou 10 reçoit une action, quel que soit son rang.
Classer par la priorité d'action
Le manuel AIAG-VDA remplace le NPR par une priorité d'action (AP, action priority). Une table du manuel associe chaque combinaison de G, O et D à une priorité haute, moyenne ou basse. La table fait primer la gravité, puis l'occurrence, puis la détection. Le manuel admet qu'une entreprise remplace les valeurs de la table par les siennes. La table ne multiplie rien: deux combinaisons de cotes ne se confondent plus parce que leurs produits coïncident.
6. Décider les actions
Le registre note, pour chaque action, le facteur qu'elle vise. L'équipe cherche d'abord à supprimer ou atténuer l'effet, puis à empêcher la cause, puis à repérer la défaillance: une action de prévention empêche la défaillance, une action de détection la rattrape.
Chaque action reçoit un responsable, une échéance et un statut. Une fois l'action réalisée, l'équipe vérifie son effet et recote la ligne. Les nouvelles cotes donnent le risque résiduel. Une action qui annonce «formation du personnel» sans changer aucune cote n'a pas traité le mode. Elle l'a documenté.
Certaines équipes de projet appliquent une variante à deux facteurs, G × O, quand aucun contrôle n'existe à coter. Cette variante n'est pas la méthode normalisée. Elle retire à l'équipe le levier de la détection, alors qu'un contrôle ajouté, une revue ou un rapprochement, est parfois l'action la moins chère.
7. Documenter et communiquer
L'équipe présente le registre, trié et annoté, à ceux qui décident de la mise en service ou du budget. La présentation montre les lignes de priorité haute, les actions engagées et le risque résiduel accepté, avec le nom de qui l'accepte. Une modification du processus, un nouveau fournisseur, une interface ajoutée ou un incident réel rouvrent le registre. Un incident fournit aussi une donnée d'occurrence et, s'il n'était pas dans le registre, un mode oublié. L'analyse des causes racines de cet incident alimente la ligne manquante.
Une AMDEC rédigée après la mise en service, pour satisfaire un audit, ne décide plus rien. Elle recopie les contrôles existants et les cote favorablement. Une AMDEC vaut tant qu'une ligne du registre peut encore changer la conception.
Considérations IA
Un modèle de langage accélère le balayage. À partir de la liste des fonctions, il propose pour chacune les modes d'absence, d'exécution partielle, de retard ou de doublon. Il propose aussi une première liste de causes par élément de travail. L'équipe part d'une liste à trier au lieu d'une page blanche. Le modèle relit aussi le registre: il repère deux lignes qui décrivent le même mode avec des mots différents, une même cause cotée 3 ici et 7 là, une action sans responsable ou une ligne sans facteur visé.
Sur les données d'incidents, un outil d'analyse de texte regroupe les tickets et les réclamations par mode de défaillance. Il donne une base factuelle aux cotes d'occurrence, là où l'équipe n'aurait que ses souvenirs.
Les cotes restent humaines. La gravité engage l'organisation sur ce qu'elle juge acceptable pour ses clients et devant l'autorité, et ce jugement a un responsable nommé. Un modèle ne connaît ni les contrôles pratiqués dans l'organisation ni leur taux d'échec: une détection cotée par lui mesure la plausibilité. Les registres d'AMDEC décrivent enfin les points faibles d'un système. Un service d'IA grand public qui les reçoit en détient la liste. L'outil retenu reste sous le contrôle de l'organisation.
Exemples
L'étape analysée appartient au processus de paie d'une PME de soixante collaborateurs.
Étape: transmettre l'ordre de paiement des salaires. Fonction: transmettre à la banque l'ordre validé, complet et inchangé, une seule fois, au plus tard le 23 du mois.
| Mode de défaillance | Effet | G | Cause | O | Contrôle actuel | D | NPR | Action (facteur visé) |
|---|---|---|---|---|---|---|---|---|
| Ordre transmis deux fois | Salaires versés à double, environ CHF 380'000 à récupérer auprès de 60 personnes | 7 | Nouvel envoi après une coupure de l'e-banking, sans consulter le statut du premier | 5 | Rapprochement bancaire le lendemain du versement | 8 | 280 | Aucun nouvel envoi sans statut consulté et second visa (O) |
| Ordre incomplet | Une personne entrée dans le mois n'est pas payée à l'échéance, virement d'urgence | 5 | Entrée saisie dans le logiciel RH après la clôture de la paie | 4 | Aucun, la personne signale le manque | 10 | 200 | Comparer l'effectif payé à l'effectif actif avant signature (D) |
| Ordre modifié entre l'export et l'envoi | Salaires versés sur le compte d'un tiers, fonds non récupérables | 9 | Fichier de paiement déposé dans un dossier ouvert en écriture à tout le service | 2 | Total de l'ordre comparé au journal de paie, qui ne voit pas un IBAN remplacé | 10 | 180 | Envoi direct du logiciel de paie à la banque, sans fichier intermédiaire (O) |
Trié par NPR, le registre traite la fuite de fonds en dernier, parce que sa cause est rare. La règle de gravité de l'équipe la fait passer en tête. Le registre complet porte aussi les responsables et les échéances.
Visualisations
Le registre se montre rempli, dans un tableau. Les trois cotes se comparent critère par critère, dans un tableau aussi. Deux idées de la méthode relèvent en revanche de l'espace. La décomposition est un arbre: le processus, ses étapes, puis les éléments de travail de chaque étape. La chaîne de défaillance relie trois niveaux de cet arbre par deux flèches, et la position de chaque maillon dit s'il est cause, mode ou effet. Les sept étapes forment une séquence où la première défaillance n'entre qu'à la quatrième.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Moyen | Fixer le périmètre, réunir l'équipe et arrêter trois échelles de cotation avant la séance. La décomposition demande un modèle du processus ou du système, à construire s'il manque. |
| Exécution | Élevé | Plusieurs séances de deux à trois heures avec quatre à six personnes. Chaque élément produit plusieurs modes et chaque mode plusieurs causes: le registre compte vite des dizaines de lignes. |
| Documentation | Élevé | Le registre se tient à jour à chaque modification et chaque incident. Les actions se suivent jusqu'à la recotation, sans laquelle le risque résiduel reste inconnu. |
Outils
Le tableur suffit pour une première AMDEC et pour la plupart des AMDEC de processus administratif. Les colonnes du registre y tiennent, le tri par NPR est immédiat et le fichier se partage. Il montre ses limites quand les lignes se comptent par centaines ou quand plusieurs registres partagent des éléments: la chaîne de défaillance n'y figure pas, et une modification doit se reporter à la main dans chaque copie.
Les logiciels spécialisés tiennent la décomposition, les fonctions et la chaîne de défaillance dans une base unique et en génèrent le registre. APIS IQ-RM, répandu dans l'industrie germanophone, PLATO e1ns et Relyence en sont des exemples. Ils se justifient chez un fournisseur de l'automobile ou des dispositifs médicaux, où les registres se comptent par dizaines et où le client audite leur forme.
Pour la décomposition, un tableau blanc, physique ou numérique comme Miro, porte l'arbre de structure pendant la séance. Le registre se remplit ensuite dans l'outil retenu.
Sources
- International Electrotechnical Commission, IEC 60812:2018, Failure modes and effects analysis (FMEA and FMECA), 3e édition: la définition de la méthode, l'extension à la criticité et son champ, qui couvre produits, processus, logiciels et interfaces.
- AIAG et VDA, FMEA Handbook, 1re édition, 2019: les sept étapes, l'analyse de structure, la chaîne de défaillance et la priorité d'action qui remplace le NPR.
- Wheeler, Donald J., «Problems With Risk Priority Numbers», Quality Digest, 2011: la nature ordinale des trois cotes et les défauts du produit qui en découlent.
- Kluse, Christopher, «A critical analysis of the AIAG-VDA FMEA; does the newly released AIAG-VDA method offer improvements over the former AIAG method?», Journal of Management & Engineering Integration, 13(1), 2020: l'ordre gravité, occurrence puis détection que suivent la priorité d'action et le choix des actions.
- NASA, Procedure for Failure Mode, Effects, and Criticality Analysis (FMECA), RA-006-013-1A, 1966: la procédure écrite pour le programme Apollo.