Analyse des causes profondes en production : 5 Pourquoi et diagramme en arête de poisson dans la pratique

Par Mirko Peters · 2026-11-11

Analyse des causes profondes en production, étape par étape : quand utiliser la méthode des 5 Pourquoi ou un diagramme en arête de poisson, comment vérifier une cause et un exemple concret d’arrêt de production chiffré.

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

L’analyse des causes profondes (RCA) identifie la cause sous-jacente d’un problème, afin que la correction empêche sa réapparition. En production, les outils habituels sont les 5 Pourquoi et le diagramme en arête de poisson. Cet article s’adresse aux responsables de production qui doivent résoudre dès aujourd’hui les problèmes de ligne et veulent qu’ils restent résolus. Vous y trouverez une routine claire, un guide pour choisir entre les deux outils, un exemple chiffré d’arrêt de production et une liste d’erreurs courantes.

Points clés

• L’analyse des causes profondes identifie la cause sous-jacente d’un problème afin que la correction prévienne la récurrence, au lieu de traiter un symptôme.
• Utilisez les 5 Pourquoi pour une chaîne de cause à effet claire, et privilégiez d’abord un diagramme en arête de poisson lorsque plusieurs causes peuvent interagir.
• Chaque « pourquoi » doit trouver réponse dans un fait observé ou une donnée mesurée, et non dans une hypothèse, et la cause doit être vérifiée avant toute action.
• Commencez par les pertes les plus importantes, à l’aide d’une vue de Pareto, et donnez la priorité au goulot d’étranglement, où chaque minute perdue coûte à toute la ligne.
• Une correction n’est démontrée que lorsque le contrôle montre que le problème ne revient pas ; menez-la donc comme un petit essai PDCA.

Qu’est-ce que l’analyse des causes profondes en production ?

iSixSigma décrit l’analyse des causes profondes comme une manière d’identifier la source sous-jacente d’une défaillance de processus ou de produit. Elle recommande de commencer par un énoncé factuel du problème : le produit ou le processus défaillant, les observations, le nombre d’unités défectueuses et la description faite par le client. Voir son article sur les diagrammes d’Ishikawa et les 5 Pourquoi.

Trois notions sont faciles à confondre :

• Le confinement protège le client ou la ligne aujourd’hui, par exemple en triant les pièces suspectes. Il ne supprime pas la cause.
• L’action corrective est la modification qui supprime la cause.
• La cause racine est la cause qui, une fois supprimée, empêche la récurrence dans des conditions similaires.

Si vous vous limitez au confinement, le même défaut ou le même arrêt reviendra. Si vous passez directement à l’action corrective sans cause vérifiée, vous risquez de corriger le mauvais élément. L’analyse des causes profondes se situe entre les deux.

Quand utiliser les 5 Pourquoi ?

Le glossaire de l’ASQ décrit les Cinq Pourquoi comme une technique consistant à demander répétitivement « pourquoi ? ». On la applique généralement une cinquantaine de fois… non : environ cinq fois, mais un nombre inférieur ou supérieur est acceptable, et le glossaire en attribue la mise au point à Sakichi Toyoda. Ses règles sont pratiques :

1. Rédigez un énoncé précis du problème, appuyé par des données.
2. Demandez pourquoi le problème s’est produit et consignez la cause observable la plus proche.
3. Continuez à vous demander pourquoi pour chaque réponse, en restant ancré dans les faits.
4. Arrêtez-vous à une cause sur laquelle vous pouvez agir pour empêcher la récurrence.
5. Vérifiez la cause racine : mène-t-elle au problème, et sa suppression empêcherait-elle le problème de se reproduire ?
6. Appliquez une contre-mesure et confirmez par une mesure de suivi que le problème ne se reproduit pas.

La même page précise que chaque réponse doit être « un fait observé ou une donnée mesurée, et non une hypothèse ». Elle indique également que la méthode fonctionne au mieux pour des chaînes causales linéaires à une seule cause racine, et recommande un diagramme en arête de poisson pour les problèmes complexes.

Quand le diagramme en arête de poisson est-il préférable ?

Un diagramme en arête de poisson, ou diagramme d’Ishikawa, est une représentation d’hypothèses. L’effet, par exemple « injections incomplètes sur la presse 3 », se trouve en tête, et les branches présentent les causes possibles. Les équipes regroupent souvent les branches selon la machine, la méthode, la matière, les personnes, la mesure et l’environnement. Le diagramme permet à l’équipe de voir de nombreuses causes possibles à la fois et de décider ensemble lesquelles tester.

iSixSigma recommande une manière claire d’associer les outils : rédiger d’abord l’énoncé du problème et collecter les données, construire ensuite le diagramme à partir d’hypothèses décrivant des effets observables, appliquer les 5 pourquoi aux branches les plus probables, et suivre chaque hypothèse avec un responsable et une date d’échéance. Le guide met aussi en garde contre le fait que les diagrammes issus d’un remue-méninges contiennent souvent des causes sans contribution réelle, et que des catégories vagues, comme « éclairage », montrent rarement un chemin vers la défaillance.

Règle empirique : une chaîne unique et claire suffit pour les 5 pourquoi. Plusieurs facteurs contributifs possibles, ou une équipe en désaccord, impliquent de commencer par un diagramme en arête de poisson.

De nombreux problèmes de production ont plusieurs causes racines à l’œuvre. Un arrêt bref peut résulter à la fois d’une pièce usée, d’un contrôle manquant et d’une lacune de formation. Lorsque vous identifiez la cause racine, demandez-vous si vous en avez trouvé une seule ou l’ensemble. Bien définir le problème est déjà la moitié de la réponse : un énoncé précis, comme « arrêts au poste 3 pendant l’équipe de nuit », conduit à moins de causes potentielles qu’un énoncé large. Pour déterminer la cause racine d’un défaut récurrent, comparez les séries bonnes et mauvaises, et listez ce qui diffère. Mettez ensuite en œuvre des actions correctives pour chaque cause vérifiée, une à la fois, afin de voir laquelle fonctionne. Il s’agit d’une résolution de problème classique : les faits d’abord, les hypothèses ensuite, les actions en dernier.

Comment appliquer l’analyse des causes racines sur la ligne ?

1. Contenir. Protégez d’abord le client et la ligne. Mettez en quarantaine les produits suspects et rétablissez un état sûr.
2. Choisir le problème. N’analysez pas tout. Utilisez une vue de Pareto, c’est-à-dire un classement des pertes de la plus grande à la plus petite, et prenez la plus importante. Regardez d’abord le goulot d’étranglement, l’étape qui limite la production. Une minute perdue à cet endroit est perdue pour toute la ligne, alors qu’une minute perdue sur une étape disposant de capacité libre peut ne rien coûter.
3. Le définir avec des données. Quoi, où, quand, combien, par rapport à quoi ? Chiffrez-le.
4. Aller voir sur place. Observez le processus réel au gemba, mot japonais signifiant « le lieu réel », l’atelier. Parlez aux opérateurs qui étaient présents.
5. Identifier les causes candidates. Utilisez les 5 pourquoi ou un diagramme en arête de poisson avec une équipe transverse : opérateur, maintenance, qualité et superviseur.
6. Vérifier. Testez la cause probable. Si elle est réelle, sa suppression doit modifier le résultat, et son rétablissement doit faire revenir le problème.
7. Agir et contrôler. Mettez en place la contre-mesure sous forme d’essai limité et mesurez le résultat. Le cycle PDCA donne sa structure à cette étape, et un rapport A3 peut consigner toute l’histoire sur une seule page.

Exemple : temps d’arrêt sur une ligne

Cet exemple utilise des chiffres hypothétiques.

La ligne 4 fonctionne en deux équipes de 8 heures pendant 5 jours, soit 80 heures planifiées. La semaine dernière, elle a perdu 14 heures en arrêts, soit 14 ÷ 80 = 17,5 %.

Pareto des arrêts :

• Erreurs de lecture du capteur : 6,3 h (45 %)
• Dépassement du changement de série : 4,2 h (30 %)
• Attente de matière : 2,1 h (15 %)
• Autres : 1,4 h (10 %)

Les deux causes les plus importantes représentent 75 % de la perte. L’équipe commence par les erreurs de lecture du capteur.

Les 5 pourquoi.

1. Pourquoi la ligne s’est-elle arrêtée ? Le capteur a mal lu la position de la pièce.
2. Pourquoi ? De la poussière se trouvait sur la lentille du capteur.
3. Pourquoi y avait-il de la poussière ? Personne ne nettoie la lentille pendant l’équipe.
4. Pourquoi cela ? Le nettoyage ne fait pas partie du travail standard de l’opérateur.
5. Pourquoi cela ? Le travail standard a été rédigé avant l’installation du capteur.

La cause racine est une lacune du travail standard, et non un capteur défectueux. La contre-mesure consiste à ajouter un contrôle de la lentille à la routine de début d’équipe et à installer un petit capot de protection.

Effet attendu. Si cela supprime 80 % des arrêts liés au capteur : 6,3 × 0,8 = 5,04 heures. Le nouveau temps d’arrêt est de 14 − 5,04 = 8,96 heures, soit 8,96 ÷ 80 = 11,2 %. Le contrôle après deux semaines montrera si le résultat réel correspond à cette estimation. Dans le cas contraire, l’équipe reprend le diagramme.

Comment s’assurer que la cause est la bonne ?

Testez la conclusion avant d’investir dans une correction. Deux questions simples aident à le faire :

• Si la cause que vous avez identifiée était différente, le résultat aurait-il été différent ?
• Si vous la supprimez, la même défaillance est-elle peu probable dans des conditions similaires ?

Collectez des données avant et après. Une bonne RCA se termine par un résultat mesuré et une norme modifiée, et c'est ainsi qu'elle alimente l'amélioration continue au lieu de la gestion des urgences. Notez également les facteurs contributifs que vous n'avez pas corrigés, comme la formation ou les outils, afin qu'ils ne soient pas oubliés.

Méfiez-vous de l'« erreur humaine ». Elle est rarement une cause racine. Si un opérateur a commis une erreur, demandez-vous pourquoi le processus l'a permise : l'instruction était-elle claire, l'outil était-il adapté, disposait-on du temps nécessaire ? La réponse se trouve presque toujours dans le système.

Erreurs courantes

• S'arrêter au premier pourquoi. La première réponse n'est généralement qu'un symptôme.
• Répondre par des opinions. Chaque pourquoi doit s'appuyer sur un fait observé ou une mesure.
• Blâmer les personnes. Le blâme met fin à la discussion et masque la cause réelle.
• Analyser d'abord les petits problèmes. Utilisez une vue de Pareto et commencez par la perte la plus importante.
• Omettre la vérification. Une cause non vérifiée conduit à une correction qui ne fonctionne pas.
• Ne pas modifier la norme. Si le travail standard reste inchangé, le problème reviendra.

Comment les logiciels peuvent aider

Une bonne analyse repose sur de bonnes données. Un logiciel peut enregistrer la raison de chaque arrêt au moment où il se produit, générer automatiquement des diagrammes de Pareto et montrer si un problème réapparaît après la correction. Cela fait gagner du temps dès les premières étapes de la RCA et donne à l'équipe des faits plutôt que des souvenirs. Un outil ne remplace pas la réflexion : ce sont toujours les personnes qui doivent aller au gemba et se demander pourquoi.

Prochaine étape

Identifiez la plus grande perte de la semaine dernière sur votre ligne, rédigez un énoncé du problème chiffré, puis menez les 5 pourquoi avec les opérateurs présents. Vérifiez ensuite la cause au moyen d'un essai de petite envergure. C'est la façon concrète d'appliquer l'analyse des causes racines dans votre production.