Introduction

La ligne s'arrête. La production attend, le chef d'atelier passe toutes les dix minutes. Le technicien change la pièce la plus suspecte, l'équipement redémarre, tout le monde repart soulagé. Trois semaines plus tard, la même panne revient, sur la même machine, à la même heure de poste.

Cet article détaille les méthodes qui structurent le diagnostic d'une panne industrielle, du symptôme observé jusqu'à la cause racine : les 5 pourquoi, le diagramme d'Ishikawa, l'arbre de défaillance, l'AMDEC et le diagramme de Pareto. Il explique quand chacune s'applique, et ce que change un diagnostic guidé par IA une fois la méthode installée.

Il s'adresse aux techniciens de maintenance, aux responsables maintenance et aux services méthodes qui veulent faire baisser durablement leurs pannes récurrentes. Il sera moins utile aux équipes qui cherchent un paramétrage précis sur un équipement donné.

Pourquoi un diagnostic non structuré coûte cher

Quand un équipement s'arrête, la pression est immédiate. Un technicien sous tension cherche d'abord ce qu'il connaît déjà, change la pièce la plus suspecte, et redémarre. Si le symptôme disparaît, l'intervention est jugée réussie. Sauf que le symptôme n'est pas la cause.

L'étude After the Fall, menée par Vanson Bourne pour ServiceMax, mesure que 23 % des arrêts non planifiés dans l'industrie manufacturière viennent d'une erreur humaine, contre 9 % dans les autres secteurs.

Un diagnostic posé trop vite alimente les pannes récurrentes : on traite la conséquence, le mécanisme de défaillance reste actif, et l'équipement retombe en panne quelques semaines plus tard. Le MTTR ne baisse jamais durablement, parce que la même panne revient encombrer le planning.

L'autre coût est invisible. Le raisonnement reste dans la tête du technicien qui a dépanné. Le collègue d'astreinte la semaine suivante repart de zéro sur le même équipement.

Les cinq méthodes qui structurent le raisonnement

Ces méthodes ne s'excluent pas, elles se combinent selon le contexte.

Les 5 pourquoi

Née du système de production Toyota, la méthode consiste à demander « pourquoi » de façon successive jusqu'à atteindre la cause racine. Un roulement chauffe : pourquoi ? Mauvaise lubrification. Pourquoi ? Le graisseur automatique est vide. Pourquoi ? Personne n'a vu l'alarme. Pourquoi ? L'alarme n'est pas remontée au superviseur.

En cinq questions, on passe d'un symptôme mécanique à un défaut d'organisation. Simple, rapide, redoutable sur les causes uniques.

Le diagramme d'Ishikawa

Aussi appelé diagramme en arêtes de poisson, il classe les causes possibles d'un défaut selon les 5M : Matière, Matériel, Main-d'œuvre, Méthode, Milieu. Il force l'équipe à explorer toutes les familles de causes avant de conclure, plutôt que de s'enfermer sur la première hypothèse. Utile quand une panne peut avoir plusieurs origines croisées.

L'arbre de défaillance

Cette méthode descendante (Fault Tree Analysis) part de l'événement redouté, par exemple l'arrêt d'une ligne, et le décompose en combinaisons logiques de défaillances élémentaires reliées par des portes ET et OU. On visualise quelles conjonctions de pannes mènent à l'incident. Plus exigeante à construire, elle est précieuse sur les équipements critiques et les analyses de sécurité.

L'AMDEC

L'Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité hiérarchise les modes de défaillance d'un équipement par criticité :

Criticité = Gravité x Fréquence x Non-détection

Elle se construit avant la panne, pour orienter le plan de maintenance préventive, mais elle nourrit aussi le diagnostic : face à un arrêt, la grille AMDEC indique quels modes surveiller en priorité.

Le diagramme de Pareto

Au niveau d'un parc, il trie les pannes par fréquence ou par coût et met en évidence la minorité de causes qui provoque la majorité des arrêts. Il ne diagnostique pas une panne précise, il dit où concentrer l'effort de diagnostic structuré.

Ce que l'IA ajoute à la méthode

L'IA ne remplace ni la méthode ni le technicien. Elle met la démarche structurée à portée de main au moment où elle est la plus difficile à tenir : sur le terrain, sous pression, devant l'équipement en panne.

Un diagnostic guidé par IA propose des hypothèses hiérarchisées à partir des symptômes décrits, en s'appuyant sur la documentation machine et sur l'historique des interventions passées. Le technicien garde la main, valide ou écarte chaque piste, mais il ne part plus de zéro et il ne suit plus uniquement son intuition du jour.

L'apport décisif est la capitalisation. Quand le diagnostic suit une démarche structurée et que sa conclusion est documentée automatiquement, la cause racine devient une donnée réutilisable. La prochaine fois que le même symptôme apparaît, la mémoire de l'usine répond. C'est le passage d'un savoir individuel à un savoir collectif requêtable.

Mise en pratique

1. Choisir le chantier. Sortir l'historique des douze derniers mois et construire le diagramme de Pareto des pannes par fréquence, puis par heures d'arrêt. Les deux classements diffèrent presque toujours.

2. Cadrer le symptôme. Décrire ce qui est observé, pas ce qui est supposé : quel signal, à quel moment du cycle, sur quel repère.

3. Dérouler les 5 pourquoi sur les pannes à cause unique. Arrêter la chaîne quand la réponse sort du périmètre de la machine et entre dans celui de l'organisation.

4. Passer à Ishikawa dès que deux familles de causes restent plausibles après la troisième question.

5. Réserver l'arbre de défaillance aux équipements critiques et aux analyses de sécurité, où la combinaison de défaillances compte autant que chaque défaillance isolée.

6. Documenter la conclusion dans la GMAO, avec la cause racine nommée et le mode de défaillance associé, pas seulement l'action réalisée.

Conclusion

1. Le symptôme n'est pas la cause. Une intervention qui fait redémarrer la ligne sans nommer le mécanisme de défaillance prépare la prochaine panne.

2. La méthode se choisit selon le type de panne. Cause unique, les 5 pourquoi. Causes croisées, Ishikawa. Équipement critique, arbre de défaillance.

3. Un diagnostic non documenté ne sert qu'une fois. La cause racine écrite est la seule qui profite au collègue d'astreinte.

Prochaine étape pour un responsable maintenance : prendre les trois équipements qui reviennent le plus souvent dans le planning et dérouler les 5 pourquoi sur la dernière intervention de chacun.

Sources

• Vanson Bourne/ServiceMax, 2017 : After the Fall, human error is more common cause of unplanned downtime

• NF EN 13306 : Vocabulaire de la maintenance (AFNOR)

• Kaoru Ishikawa, Guide to Quality Control (diagramme de causes et effets)

• ISO 17359:2018 : Condition monitoring and diagnostics of machines

Article publié initialement sur mimorian.co.