Sur le terrain, l'un des défis récurrents que je rencontre en maintenance prédictive, notamment sur la détection d'usure des roulements à billes par vibration, n'est pas tant de détecter une anomalie que d'éviter d'alerter pour rien. Les faux positifs grèvent la confiance des équipes, entraînent des interventions inutiles et, à terme, la désactivation des systèmes d'alerte. Dans cet article, je partage des règles concrètes de feature engineering et de seuils — issues de mes projets industriels — pour réduire ces faux positifs tout en conservant une sensibilité opérationnelle pertinente.

Comprendre la source des faux positifs

Avant de toucher aux features et aux seuils, il est essentiel d'identifier pourquoi un système déclenche des alertes erronées :

  • bruit de fond variable (machines voisines, activités de chantier),
  • variations de charge ou régime moteur qui modifient le spectre de vibration,
  • conditions environnementales (température, lubrification) qui influencent les mesures,
  • problèmes de capteur (dérive, mauvais montage, câble endommagé),
  • mauvaise granularité temporelle ou erreurs d'alignement entre données et labels.

    • Traiter ces sources est la première étape pour éviter que des features mal conçues ne traduisent ces variations en faux positifs.

    Qualité des données et prétraitement : la base

    Je suis intransigeante sur la qualité des données. Sans un prétraitement solide, aucun pipeline de features ne fera des miracles.

  • Vérifier le montage et la calibration des accéléromètres (ex: capteurs IEPE ou MEMS) ; un capteur mal fixé génère des harmoniques parasites.
  • Appliquer des filtres anti-aliasing et s’assurer que la fréquence d’échantillonnage respecte la règle de Nyquist pour la bande d’intérêt (souvent 1–20 kHz pour roulements selon les machines).
  • Recentrage et dé-trending : retirer la composante moyenne et les dérives lentes (filtre passe-haut à faible coupure) évite que RMS ou variance s’emballent inutilement.
  • Compensation température-charge : enregistrer température et courant/charge pour normaliser certaines features (RMS normalisé par charge, par exemple).

    • Règles de feature engineering pour des signaux de roulements

    Je privilégie des features interpretable et robustes plutôt que des vecteurs opaques. Voici celles qui, selon moi, réduisent le plus les faux positifs :

    Features temporelles robustes

  • RMS sur fenêtres adaptatives : calculer le RMS sur fenêtres mobiles mais normaliser par la charge ou le régime. Un simple seuil sur RMS provoque beaucoup de fausses alarmes si la charge varie.
  • Crest factor et kurtosis : utiles pour détecter impulsions (pitting). Pour éviter les faux positifs dus à impulsions isolées, j’utilise une stratégie en deux temps : un seuil supérieur sur kurtosis > X ET répétition dans N fenêtres consécutives.
  • Zero-crossing et skewness : informations complémentaires sur la symétrie et la nature du signal.

    • Features fréquentielles et en enveloppe

  • Analyse en enveloppe (demodulation) centrée sur fréquences caractéristiques du roulement (BSF, BPF, FTF) : plutôt que déclencher sur une seule ligne spectrale, je construis des packs de features (amplitude moyenne autour de l’ordre ± bande) — cela évite les alarmes dues à harmoniques d’autres organes.
  • Ratios harmoniques (ex : énergie à fréquence fondamentale / énergie totale) : si un pic augmente mais que le ratio reste constant, il s’agit souvent d’un changement de fond plutôt que d’un défaut réel.
  • Tracking d’ordre (order-tracking) : pour machines à vitesse variable, convertir en domaine ordre réduit fortement les fausses alertes liées aux changements de régime.

    • Features statistiques et dynamiques

  • Différences normalisées : au lieu d’un seuil absolu, je calcule la variation normalisée par rapport à un baseline (Delta/RMS_baseline). Un écart de 30% sur un signal stable est plus significatif qu’une valeur brute dépassant X.
  • EWMA / CUSUM (Exponentially Weighted Moving Average / Cumulative Sum) : ces détecteurs de changement filtrent les pics transitoires et détectent les dérives lentes typiques d'usure. Paramétrer le facteur d'atténuation (lambda) permet de doser la sensibilité.
  • Fenêtre d'acceptation temporelle : exiger N fenêtres consécutives hors seuil avant alarme (N dépend du coût d'une intervention et de la criticité).

    • Stratégies de seuils pratiques

    J'évite les seuils fixes universels. Voici des approches efficaces :

  • Seuils adaptatifs basés sur la statistique locale : seuil = μ_local + k * σ_local (k typiquement 3 pour alarmes fortes, 2 pour alertes préliminaires). La fenêtre locale doit couvrir suffisamment de cycles opératoires.
  • Seuils multi-feature (logique AND/OR pondérée) : déclencher uniquement si plusieurs features indépendantes (p.ex. RMS, kurtosis, amplitude d’enveloppe) dépassent leurs seuils — réduit fortement les faux positifs.
  • Seuils probabilistes : utiliser un classifieur léger (logistic regression, Random Forest) entraîné sur features interprétables pour produire une probabilité d'anomalie. Fixer le point de décision selon la courbe de coût (faux positif vs faux négatif).

    • Sélection et réduction de features

    Trop de features = surapprentissage et bruit. J'applique :

  • analyse de corrélation (éliminer features redondantes),
  • PCA pour visualiser clusters anormaux mais pas nécessairement pour la production si l'interprétabilité est requise,
  • sélection basée sur importance (permutation importance, SHAP pour modèles plus complexes) pour conserver seulement les features robustes aux variations de régime/environnement.

    • Validation pratique et retours terrain

    La validation est cruciale. Voici ma checklist :

  • Tests en conditions opérationnelles variées (charges, démarrages, arrêts) pour mesurer précision, rappel et taux de fausses alertes.
  • Utiliser des jeux de données annotés (même petits) et simuler des défauts si possible (essais sur banc). Les bibliothèques tsfresh, scikit-learn et pyculib m’ont souvent aidée pour prototyper.
  • Déployer en mode « shadow » : le modèle tourne en parallèle sans alerter les opérateurs durant une période pour comparer alertes réelles vs prédictions.
  • Mettre en place un retour humain (feedback loop) : chaque alerte validée ou rejetée alimente la réévaluation des seuils et du modèle.

    • Outillage et bonnes pratiques

    Sur mes projets j'utilise souvent une combinaison :

  • acquisition : National Instruments, HBM ou capteurs SKF pour fiabilité,
  • prétraitement & analyses : Python (numpy, scipy, pandas), MATLAB pour prototypage rapide,
  • modélisation : scikit-learn, lightGBM pour classifieurs légers; TensorFlow/PyTorch uniquement si volume de données suffisant,
  • déploiement edge : modules Advantech, Siemens IoT2000 ou solutions d'edge analytics supportant des modèles légers pour réactivité.

    • Réduire les faux positifs en détection d'usure par vibration est un équilibre : combiner features robustes, seuils adaptatifs et validation terrain. La clé, selon moi, est la simplicité interprétable — des règles claires et des features normalisées permettent d'engager les équipes opérationnelles, d'itérer rapidement et d'améliorer la confiance dans la maintenance prédictive.