La scène que vous connaissez par cœur
Il est 14h un mardi. La salle sent le café froid et le marqueur Velleda. Sur le tableau blanc : un diagramme Ishikawa à moitié rempli, dessiné par le responsable qualité il y a vingt minutes. Autour de la table : le chef de ligne qui défend sa méthode de réglage, le responsable maintenance qui pointe vers un lot de matière première arrivé vendredi, et la responsable méthodes qui suspecte une dérive de l’opérateur de nuit.
Trois heures plus tard, vous avez un diagramme complet. Chacun a défendu son périmètre. Vous avez encerclé trois “causes probables”. Laquelle attaquer en premier ? Personne ne sait vraiment. On va commencer par la plus facile à corriger.
C’est exactement le problème.
L’Ishikawa est un outil de structuration collective. Il est excellent pour ne rien oublier, pour impliquer les équipes, pour documenter une réunion. Mais il ne répond pas à la question qui compte : quelle cause explique le plus de variance dans votre taux de défauts ?
SHAP + XGBoost répondent à cette question. Avec des chiffres.
Le problème fondamental de l’Ishikawa classique
Soyons précis sur ce qui ne va pas. Le diagramme d’Ishikawa a trois défauts structurels en contexte industriel moderne :
1. Biais de disponibilité cognitive. Les causes les plus facilement verbalisables finissent dans le diagramme. Les interactions complexes entre paramètres — du type “la viscosité de la matière + la température moule + la vitesse d’injection interagissent de façon non-linéaire à partir de 18h quand le bâtiment se refroidit” — sont invisibles pour un cerveau humain en réunion.
2. Absence de hiérarchisation quantitative. Votre diagramme liste 15 causes potentielles. Lesquelles concentrent 80% de l’effet ? L’Ishikawa ne vous dit pas.
3. Consensus social ≠ vérité technique. Le chef de ligne le plus vocal finit avec plus de branches. L’opérateur de nuit n’est pas dans la salle. L’historique de 18 mois de données MES n’est pas dans la salle non plus.
L’Ishikawa cartographie les hypothèses de l’équipe. XGBoost + SHAP cartographie ce que les données disent réellement.
XGBoost + SHAP : le moteur du diagnostic augmenté
Pourquoi XGBoost sur des données qualité ?
- Gère les non-linéarités sans transformation manuelle des variables
- Robuste aux valeurs manquantes — inévitables sur les historiques MES
- Capture les interactions entre variables — exactement ce que l’Ishikawa rate
- Performant sur des datasets de taille moyenne (quelques milliers à quelques dizaines de milliers de lignes)
- Pas de normalisation requise — les features process peuvent rester dans leurs unités d’origine
Pourquoi SHAP pour l’interprétabilité ?
SHAP (SHapley Additive exPlanations, Lundberg & Lee, 2017) est basé sur la théorie des jeux coopératifs de Shapley (1953). Pour chaque prédiction individuelle (chaque pièce défectueuse), SHAP vous dit exactement combien chaque paramètre a contribué à augmenter ou diminuer la probabilité de défaut.
C’est la différence entre “la température moule est importante en général” et “sur cette pièce défectueuse N°4782, la température moule à 187°C a contribué +0.34 à la proba de défaut, en interaction avec un temps de cycle allongé de 2.3s”.
Le pipeline : de l’historique MES au diagnostic
flowchart TD
A[Historique MES / SCADA\n12-18 mois de données process] --> B[Feature Engineering\nparamètres machine + matière + env]
B --> C[Labeling\ndéfaut / conforme sur lot / pièce]
C --> D[XGBoost Classifier\nfit sur données historiques]
D --> E{Validation\nAUC-ROC > 0.75 ?}
E -- Non --> F[Réviser features\nAjouter données capteurs]
E -- Oui --> G[SHAP Values\ncalcul sur jeu de test]
G --> H[SHAP Waterfall\npar défaut individuel]
G --> I[SHAP Beeswarm\ncontribution globale]
G --> J[SHAP Dependence Plot\ninteractions bi-variées]
H --> K[Ishikawa Augmenté\nPré-rempli avec SHAP values]
I --> K
K --> L[Atelier Expert\nValidation mécanisme causal]
L --> M[Plan d'action\nhiérarchisé, quantifié]
M --> N[Mesure d'efficacité\nretraining mensuel]
N --> DIshikawa augmenté : la fusion homme-machine
L’idée n’est pas de remplacer l’atelier Ishikawa. C’est de le nourrir avec des données avant que les humains entrent dans la salle.
Avant (Ishikawa classique) :
- Réunion à blanc, chacun liste ses hypothèses
- Les branches les plus garnies = les sujets les plus discutés
- Résultat : reflet de la culture et des tensions internes
Après (Ishikawa augmenté) :
- SHAP beeswarm plot imprimé A3 sur la table avant la réunion
- Les 5 features les plus contributives pré-inscrites sur le diagramme avec leur contribution SHAP
- L’atelier valide ou infirme le mécanisme causal — pas les hypothèses
Comparaison : 5 Pourquoi vs Régression vs XGBoost+SHAP
| Critère | 5 Pourquoi | Régression linéaire | XGBoost + SHAP |
|---|---|---|---|
| Données requises | Aucune | Quelques dizaines | 500+ observations |
| Non-linéarités | Invisible | Invisible | Capturé nativement |
| Interactions entre variables | Invisible | Invisible (sauf manuellement) | Capturé nativement |
| Biais expert | Fort | Modéré | Faible |
| Interprétabilité | Narrative | Coefficients | SHAP par feature et par observation |
| Hiérarchisation quantitative | Non | Partielle | Oui |
| Temps de mise en œuvre | 2h | 1 jour | 2-5 jours |
| Validation causale | Par consensus | Par p-value | Requiert expert métier |
Cas concret : défaut cosmétique en injection plastique
Contexte
Fabricant de pièces techniques en injection plastique. Défaut cosmétique (rayures, traces de brûlure, marques de flux). Taux de rebut : 4.7% sur les 6 derniers mois. Objectif : < 1.5%.
Trois séances d’Ishikawa en 18 mois. Trois plans d’action. Résultat : taux passé de 4.9% à 4.7%. Pas assez.
Dataset
- 18 mois de production, 23 400 pièces tracées
- 15 paramètres process : température moule (3 zones), température matière, pression injection, vitesse injection, temps de cycle, temps de refroidissement, température ambiante, humidité granulés, numéro de shift, opérateur, référence moule, référence lot matière
- Taux de défaut : 4.7% → classe déséquilibrée
Code Python complet
import pandas as pd
import numpy as np
import xgboost as xgb
import shap
import matplotlib.pyplot as plt
from sklearn.model_selection import train_test_split
from sklearn.metrics import roc_auc_score, classification_report
# ── 1. Chargement et préparation ───
df = pd.read_csv("historique_injection_18mois.csv", parse_dates=["timestamp"])
df["heure"] = df["timestamp"].dt.hour
df["jour_semaine"] = df["timestamp"].dt.dayofweek
df["delta_temp_moule"] = df["temp_moule_z1"] - df["temp_moule_z3"]
FEATURES = [
"temp_moule_z1", "temp_moule_z2", "temp_moule_z3",
"temp_matiere", "pression_injection", "vitesse_injection",
"temps_cycle", "temps_refroidissement",
"temp_ambiante", "humidite_granules",
"shift", "delta_temp_moule", "heure"
]
X = df[FEATURES]
y = df["defaut_cosmetique"]
X_train, X_test, y_train, y_test = train_test_split(
X, y, test_size=0.2, random_state=42, stratify=y
)
# ── 2. Entraînement XGBoost ───
ratio_neg_pos = (y_train == 0).sum() / (y_train == 1).sum()
model = xgb.XGBClassifier(
n_estimators=400,
max_depth=4,
learning_rate=0.05,
subsample=0.8,
colsample_bytree=0.8,
scale_pos_weight=ratio_neg_pos,
eval_metric="auc",
early_stopping_rounds=30,
random_state=42,
n_jobs=-1
)
model.fit(
X_train, y_train,
eval_set=[(X_test, y_test)],
verbose=50
)
y_pred_proba = model.predict_proba(X_test)[:, 1]
auc = roc_auc_score(y_test, y_pred_proba)
print(f"AUC-ROC: {auc:.3f}") # >> AUC-ROC: 0.847
# ── 3. SHAP — Explainer et valeurs ───
explainer = shap.TreeExplainer(model)
shap_values = explainer(X_test)
# ── 4. SHAP Beeswarm — Vue globale ───
plt.figure(figsize=(10, 7))
shap.plots.beeswarm(shap_values, max_display=13, show=False)
plt.title("SHAP Beeswarm — Drivers du défaut cosmétique", fontsize=14, fontweight="bold")
plt.tight_layout()
plt.savefig("shap_beeswarm_injection.png", dpi=150, bbox_inches="tight")
plt.close()
# ── 5. SHAP Waterfall — Pièce défectueuse spécifique ───
idx_worst = y_pred_proba.argmax()
plt.figure(figsize=(10, 6))
shap.plots.waterfall(shap_values[idx_worst], show=False)
plt.title(f"SHAP Waterfall — Pièce #{X_test.index[idx_worst]}", fontsize=13, fontweight="bold")
plt.tight_layout()
plt.savefig("shap_waterfall_piece_critique.png", dpi=150, bbox_inches="tight")
plt.close()
# ── 6. SHAP Dependence Plot — Interaction ───
shap.dependence_plot(
"temp_moule_z3",
shap_values.values,
X_test,
interaction_index="temps_cycle",
)
# ── 7. Résumé pour l'atelier Ishikawa ───
mean_abs_shap = pd.DataFrame({
"feature": FEATURES,
"mean_abs_shap": np.abs(shap_values.values).mean(axis=0)
}).sort_values("mean_abs_shap", ascending=False)
print("\n=== TOP 5 DRIVERS (contribution SHAP moyenne) ===")
print(mean_abs_shap.head(5).to_string(index=False))Résultats SHAP
=== TOP 5 DRIVERS (contribution SHAP moyenne) ===
feature mean_abs_shap
temp_moule_z3 0.341
temps_cycle 0.278
humidite_granules 0.214
delta_temp_moule 0.187
temp_ambiante 0.1183 variables concentrent 80% de la contribution aux défauts.
Le beeswarm révèle quelque chose que l’Ishikawa n’aurait jamais trouvé : la température de la zone 3 du moule n’est problématique qu’en interaction avec un temps de cycle allongé. En dessous de 190°C, même avec un temps de cycle long, le défaut n’apparaît pas. Au-dessus de 193°C et temps de cycle > 28s : taux de défaut 8x plus élevé.
C’est une interaction non-linéaire avec seuil. Ni la régression linéaire ni le 5 Pourquoi ne l’auraient identifiée.
La nuance essentielle : SHAP montre l’association, pas la causalité
SHAP est un outil d’explication d’un modèle prédictif, pas un oracle causal. Il vous dit ce que le modèle a appris de vos données. Ce n’est pas la même chose que la causalité physique.
Si l’humidité des granulés est corrélée avec les livraisons du vendredi (parce que le fournisseur stocke mal le week-end), SHAP attribuera une contribution importante à l’humidité. Est-ce l’humidité qui cause le défaut, ou le fournisseur du vendredi ? SHAP ne peut pas trancher seul.
C’est là que l’expert métier est indispensable. Son rôle change : il ne liste plus des hypothèses, il valide le mécanisme physique derrière une association statistique.
Posture correcte :
- “Le modèle dit que temp_moule_z3 + temps_cycle est le principal driver. Quel mécanisme physique expliquerait cette interaction ?”
- L’expert : “à haute température et cycle long, le matériau se dégrade thermiquement — d’où les traces de brûlure.”
- Test de validation : faire varier temp_moule_z3 en conditions contrôlées. Confirmer.
SHAP + expert + DOE = diagnostic complet.
Quand NE PAS utiliser XGBoost+SHAP
Données insuffisantes. En dessous de ~200-300 défauts dans le dataset, le modèle ne sera pas fiable. Restez sur le 5 Pourquoi + AMDEC.
Paramètres non capturés. Si la vraie cause racine n’est pas dans vos données, XGBoost ne peut pas la trouver.
Process non stationnaire. Si votre process a subi une modification majeure en cours de période, segmenter les données avant/après.
Besoin immédiat. Crise qualité ce matin → Ishikawa + 5 Pourquoi + intuition experte. XGBoost + SHAP se prépare en dehors de l’urgence.
Intégration dans votre système qualité
Phase 1 — Pilote (1 mois). Un seul défaut récurrent, historique ≥ 12 mois. Imprimer le beeswarm. L’apporter à la prochaine réunion Ishikawa.
Phase 2 — Validation (2 mois). Mettre en œuvre les actions identifiées par SHAP. Mesurer l’impact. Comparer avec les plans d’action précédents.
Phase 3 — Industrialisation. Dashboard de monitoring avec retraining mensuel. Alerte quand une feature SHAP dérive.
L’objectif n’est pas de remplacer la culture qualité existante. C’est de lui donner des arguments chiffrés que les opérationnels ne peuvent plus contester dans la salle de réunion.
Conclusion : l’Ishikawa comme interface homme-machine
Le diagramme d’Ishikawa ne va pas disparaître. Il a un rôle irremplaçable : créer un langage commun entre les équipes.
Mais l’ordre des étapes doit changer.
Ancien ordre : réunion → Ishikawa → hypothèses → plan d’action (basé sur consensus)
Nouvel ordre : données → XGBoost → SHAP → Ishikawa augmenté → réunion de validation → plan d’action (basé sur preuves)
Quand vous présentez le plan d’action à la direction, vous pouvez dire : “si on corrige ces 3 paramètres, le modèle prédit une réduction de 68% du taux de défaut, avec un intervalle de confiance entre 55% et 78%.”
C’est différent de “on pense que c’est probablement la zone 3 du moule”.
PaulO Obara est fondateur de BCUB3. Il accompagne les équipes industrielles dans l’intégration des outils data et IA pour l’amélioration continue.