Sur le terrain, l'un des problèmes les plus frustrants en maintenance vibration est sans doute les faux positifs : alarmes fréquentes, interventions inutiles, perte de confiance dans le système et finalement des coûts opérationnels accrus. J'ai travaillé sur plusieurs projets où l'on disposait d'excellents capteurs et d'algorithmes prometteurs, mais la friction venait du fait que le système n'était pas contextualisé — il ne savait pas différencier un pic d'énergie dû à une opération normale (démarrage, freinage, passage de charge) d'un vrai défaut mécanique.
Dans cet article, je partage une approche pragmatique que j'utilise : combiner une inférence edge performante (par exemple sur une plateforme Nvidia Jetson), des règles métier contextualisées et des techniques d'apprentissage par transfert. L'idée est de tirer parti de la puissance du deep learning pour détecter les signatures fines de défaillance tout en gardant un filet de sécurité logique composé de règles et d'expertise terrain pour réduire les alarmes inutiles.
Pourquoi allier Jetson, règles métier et transfert d'apprentissage ?
Trois bénéfices clés m'ont convaincue d'adopter cette combinaison :
Réactivité et confidentialité : l'inférence sur Jetson (Nano, Xavier NX, Orin Nano selon la contrainte) permet de traiter les signaux localement, réduire la latence et préserver les données sensibles.Robustesse opérationnelle : les règles métier intégrées (fenêtres temporelles, niveaux de vitesse, scheduler machine) encapsulent le contexte machine et éliminent les alarmes attendues.Adaptabilité : l'apprentissage par transfert limite le besoin de gros jeux de données spécifiques et accélère la mise en œuvre sur nouveaux équipements ou configurations.Architecture générale que j'implémente
Voici l'architecture que j'ai déployée sur plusieurs sites :
Capteurs vibration (accéléromètres tri-axe) → prétraitement (filtrage, normalisation, segmentation en trames) sur un microcontrôleur ou directement sur le Jetson.Calcul de features classiques (RMS, kurtosis, crest factor) + génération de spectrogrammes ou de scalogrammes (STFT / CWT).Inférence locale sur Jetson avec un modèle CNN optimisé (par ex. PyTorch converti en ONNX puis optimisé en TensorRT).Un module de règles métier côté edge pour appliquer contextes (maintenance planifiée, vitesse machine, signaux d'entrée/événements).Un service de remontée et d'apprentissage centralisé pour collecte d'étiquettes, ré-entraînement et déploiement de modèles mis à jour.Optimiser le modèle pour Jetson
Sur Jetson, l'optimisation est cruciale. J'utilise souvent ce workflow :
Entraîner un modèle léger sur GPU (ResNet small, MobileNetV3, ou un CNN personnalisé sur spectrogrammes).Effectuer quantification et pruning si nécessaire pour réduire latence et consommation.Exporter en ONNX puis convertir en TensorRT (qui tire parti du GPU embarqué). TensorRT apporte souvent un speed-up significatif.Profiling temps réel : je m'assure que l'ensemble prétraitement + inference reste sous le cycle requis (ex. inference < 200 ms pour détection quasi-temps réel).J'ai expérimenté des modèles basés sur des spectrogrammes (image-like) : ils se prêtent bien aux CNN et bénéficient de modèles pré-entraînés sur ImageNet pour le transfert d'apprentissage.
Apprentissage par transfert : stratégies pratiques
Le transfert d'apprentissage m'a permis de déployer rapidement des détecteurs sur des machines qui n'avaient pas d'historique d'incident. Voici les approches que je privilégie :
Feature extraction : utiliser un backbone pré-entraîné (MobileNet, EfficientNet-lite) comme extracteur de features sur spectrogrammes, puis entraîner un classifieur léger sur les données locales.Fine-tuning progressif : geler les couches basses puis réentraîner progressivement les couches supérieures avec un petit taux d'apprentissage et un dataset augmenté.Domain adaptation simple : utiliser des techniques d'augmentation (bruit, shift de fréquence, scaling d'amplitude) pour simuler conditions locales si peu d'exemples existent.Concrètement, j'ai obtenu de bons résultats en commençant avec un modèle pré-entraîné sur un gros jeu de spectrogrammes industriels et en le ré-entraînant avec quelques dizaines à centaines d'exemples étiquetés localement (selon la complexité de la défaillance).
Règles métier : la clé pour filtrer les fausses alertes
Les règles métier sont simples mais puissantes. Elles traduisent l'expérience opérationnelle en logique que le système applique avant d'émettre une alarme :
Suppression d'alarmes pendant les plages connues de démarrage/arrêt.Seuils adaptatifs selon la vitesse / charge : exiger un dépassement de seuil proportionnel à la vitesse.Validation multi-frames : n'alerter que si la détection persiste sur N trames consécutives ou si un pattern temporel est confirmé.Cross-check capteurs : confirmer l'anomalie sur plusieurs canaux (paliers avant/arrière) avant alarme.Exclusion temporaire si maintenance planifiée ou si un opérateur a validé une action en cours.J'implémente ces règles dans un moteur léger sur Jetson (ou dans un microservice edge) pour qu'elles s'exécutent après l'inférence ML. Le but est d'augmenter la précision opérationnelle sans diminuer la sensibilité aux vrais défauts.
Boucle humaine et apprentissage actif
Une bonne réduction des faux positifs passe par l'humain dans la boucle. J'encourage systématiquement :
Un mécanisme de feedback : l'opérateur peut marquer une alarme comme "faux positif" ou "vrai défaut" via une interface (tablette, HMI).Collecte d'étiquettes pour ré-entraînement périodique : ces retours sont stockés et utilisés pour la prochaine phase de transfert/fine-tuning.Active learning : le système propose des échantillons ambigus pour validation humaine prioritaire, maximisant l'impact des étiquettes limitées.Sur un site pilote, l'introduction du feedback opérateur a réduit le taux de faux positifs de l'ordre de 40% en deux mois simplement parce que le modèle a été réajusté sur des cas réels.
Métriques et validation
Pour évaluer l'efficacité, je ne me contente pas d'un seul indicateur. Voici ceux que je suis :
Taux de faux positifs (FP) et faux négatifs (FN) séparément.Precision / Recall et F1 sur un jeu d'essai validé terrain.Nombre d'interventions préventives déclenchées par mois et le taux d'interventions effectivement utiles.Temps moyen entre alarmes réellement utiles (MTBA) — métrique opérationnelle importante pour la confiance.Je mets en place des tableaux de bord montrant ces KPIs et les évolutions après chaque livraison de modèle ou modification des règles.
Exemples concrets et outils
Dans mes déploiements, j'ai souvent utilisé :
Nvidia Jetson Xavier NX pour les sites avec charge de calcul significative, et Nano pour les cas low-cost.PyTorch pour l'entraînement, ONNX + TensorRT pour le déploiement.Des bibliothèques open-source pour le prétraitement : librosa pour spectrogrammes, scipy pour filtrage.MQTT/OPC-UA pour l'orchestration des alertes et la remontée vers SCADA/CMMS.Un cas client : en convertissant des signaux vibration en spectrogrammes et en appliquant un MobileNetV3 fine-tuné + règles métier (validation multi-frames, filtre vitesse), nous avons réduit les alarmes non pertinentes de 60% tout en conservant plus de 95% des vrais défauts détectés.
Risques et points d'attention
Quelques gardes-fous que j'observe systématiquement :
Sur-adaptation : attention à ne pas sur-ajuster les règles au point de masquer de véritables anomalies.Qualité des labels : un modèle formé sur labels erronés perpétuera les erreurs. La gouvernance des étiquettes est essentielle.Sécurité : maintenir la sécurité du Jetson (patches, segmentation réseau) car l'edge devient un point critique de l'infrastructure.Maintenance des modèles : planifier des itérations régulières de ré-entraînement et une stratégie de rollback si une version dégrade les performances.En résumé, la combinaison d'un edge performant (Nvidia Jetson), d'un modèle initial robuste via transfert d'apprentissage et d'un ensemble de règles métier validées par les opérateurs donne une solution pragmatique et évolutive pour limiter les faux positifs en surveillance vibration. Cette approche permet de garder la sensibilité nécessaire pour détecter les vrais problèmes, tout en évitant les alarmes qui érodent la confiance des équipes terrain.
