Des capteurs aux prédictions : comment fonctionne réellement une plateforme PdM

« Il suffira de mettre le ML sur les données de capteurs » est le raccourci qui lance des milliers de projets PdM qui échouent. La réalité est que le modèle ML représente peut-être 20 % du système. Les 80 % restants consistent à acheminer les données de façon fiable des capteurs aux modèles, et à acheminer les prédictions de façon fiable des modèles aux humains.

Voici comment fonctionne l'ensemble du pipeline dans une plateforme moderne, du capteur physique au téléphone de l'ingénieur.

Couche 1 : Collecte edge

Les capteurs industriels produisent des données à des débits très différents. Un accéléromètre de vibration sur un roulement échantillonne à 12 800 Hz. Une sonde de température se met à jour toutes les 30 secondes. Un débitmètre envoie des données toutes les 5 secondes.

Une passerelle edge gère :

Traduction de protocole — OPC-UA, MQTT, Modbus RTU et les signaux analogiques 4-20 mA ont tous besoin de pilotes différents
Mise en tampon locale — Les coupures réseau ne doivent pas faire perdre des données. La passerelle stocke les lectures localement et se synchronise quand la connectivité revient
Sous-échantillonnage — Les données de vibration à 12,8 kHz sont résumées (RMS, crête, kurtosis) pour la surveillance continue, avec des formes d'onde brutes capturées périodiquement pour l'analyse spectrale

Le défi des protocoles

La traduction de protocoles semble simple dans une présentation commerciale. En pratique, c'est là que la plupart des déploiements PdM se heurtent à leur premier obstacle.

OPC-UA est le standard moderne, mais « standard » est généreux — chaque équipementier l'implémente différemment. Vous passerez des jours à configurer les certificats de sécurité (OPC-UA impose un échange de certificats X.509), à mapper les IDs de nœuds vers des noms de tags significatifs et à faire face à des serveurs qui n'implémentent qu'un sous-ensemble de la spec. Les équipements récents sont généralement conformes ; tout ce qui a été fabriqué avant 2015 est aléatoire.

Modbus RTU/TCP est fiable mais rudimentaire. Le mapping des registres est entièrement manuel — la documentation du capteur vous indique « le registre 40001 est la vibration axe X, flottant 32 bits, big-endian », et vous le traduisez en configuration. Multipliez par 50 à 200 capteurs par installation, et vous comprendrez pourquoi la cartographie des protocoles seule peut consommer une semaine entière de mise en service.

Les signaux analogiques 4-20 mA nécessitent du matériel supplémentaire : conditionneurs de signal, convertisseurs analogique-numérique et une mise à la masse soigneuse pour éviter le bruit. Un décalage de 0,1 mA sur une boucle de courant 4-20 mA se traduit directement par une erreur de mesure que votre modèle ML interprétera comme un changement de procédé.

Les besoins en matériel edge sont souvent sous-estimés. Une passerelle gérant 200 capteurs a besoin de suffisamment de calcul pour la mise en tampon locale (minimum 32 Go de stockage pour une capacité hors ligne de 72 heures), la traduction de protocole (gourmand en CPU pour le chiffrement OPC-UA) et l'inférence edge optionnelle. Les passerelles de grade industriel des fournisseurs comme Advantech, Moxa ou Siemens IOT2050 varient généralement de 500 à 2 000 € par unité, avec des processeurs ARM ou x86 et des plages de température industrielles (-40 à 70 °C).

Couche 2 : Ingestion en streaming

Les données quittent l'edge en messages MQTT et entrent dans un courtier de messages (généralement Apache Kafka) qui fournit :

Durabilité — Les messages persistent jusqu'à consommation, survivant aux redémarrages de service
Multi-consommateurs — Les mêmes données alimentent simultanément le traitement en temps réel, le stockage froid et les pipelines ML
Application de schéma — Les schémas Avro valident la structure des données avant leur entrée dans le pipeline

À ce stade, les données sont validées : les IDs de capteurs sont vérifiés, les horodatages sont contrôlés pour la dérive, et les lectures hors limites physiques sont signalées. Une lecture de vibration de -500 mm/s ou une température de 3 000 °C est mise en quarantaine, pas transmise aux modèles ML. Un score de qualité (0-100) tague chaque lecture, et tout ce qui est en dessous de 50 est filtré avant d'atteindre l'étape d'ingénierie des caractéristiques.

Couche 3 : Traitement en flux

Un processeur de flux (Apache Flink) transforme les lectures brutes en caractéristiques prêtes pour le ML en temps réel :

Statistiques glissantes — Moyenne, écart type, RMS, kurtosis sur des fenêtres de 60 s, 5 min et 30 min
Détection de tendance — La vibration augmente-t-elle, est-elle stable ou diminue-t-elle au cours de la dernière heure ?
Corrélation croisée des capteurs — Une température qui monte pendant que la vibration est stable suggère un changement ambiant, pas une dégradation
Caractéristiques fréquentielles — La FFT sur les données de vibration extrait les fréquences de roulement, les fréquences d'engrènement et les harmoniques

L'ingénierie des caractéristiques en détail

La qualité des prédictions ML est déterminée ici, pas dans l'architecture du modèle. Quelques exemples concrets :

RMS glissante vs. pic-à-pic : La vibration RMS capture l'énergie globale et est bonne pour détecter le balourd ou le désalignement. Le pic-à-pic capture les impacts transitoires et est meilleur pour la détection précoce de dommages de roulement (où le contact métal-métal crée des pics courts et aigus). Calculer les deux sur plusieurs tailles de fenêtres (60 s, 300 s, 1 800 s) donne au modèle différentes vues du même processus de dégradation.

FFT et fréquences de défaut de roulement : Pour la surveillance des roulements par vibration, la FFT brute ne suffit pas — vous devez savoir quoi chercher. Chaque roulement à éléments roulants a quatre fréquences de défaut caractéristiques, toutes dérivées de la géométrie du roulement et de la vitesse d'arbre :

BPFO (Ball Pass Frequency Outer) = (N/2) × RPM × (1 - d/D × cos(α)) — défaut de piste extérieure
BPFI (Ball Pass Frequency Inner) = (N/2) × RPM × (1 + d/D × cos(α)) — défaut de piste intérieure
BSF (Ball Spin Frequency) = (D/2d) × RPM × (1 - (d/D × cos(α))²) — défaut d'élément roulant
FTF (Fundamental Train Frequency) = RPM/2 × (1 - d/D × cos(α)) — défaut de cage

Où N = nombre d'éléments roulants, d = diamètre de bille, D = diamètre primitif, α = angle de contact. Le processeur de flux calcule la FFT sur les formes d'onde de vibration brutes et extrait l'amplitude à ces fréquences spécifiques (plus les harmoniques 2x et 3x). Une amplitude croissante à la BPFO avec harmoniques est un défaut de piste extérieure classique — le type de schéma invisible dans la RMS temporelle mais indubitable dans le domaine fréquentiel.

La sélection de la taille de fenêtre importe plus que la plupart des équipes ne le réalisent. Une fenêtre de 60 secondes capture les transitoires rapides (démarrage moteur, changements de charge). Une fenêtre de 30 minutes les lisse et révèle les tendances lentes. N'utiliser qu'une seule taille de fenêtre force le modèle à apprendre à la fois la dynamique rapide et lente d'une seule représentation — fournir les deux lui donne la résolution temporelle pour distinguer « le moteur vient de démarrer » de « ce roulement empire ».

Couche 4 : Stockage

Les données traitées atterrissent dans une base de données de séries temporelles (TimescaleDB) optimisée pour :

Hypertables — Partitionnement automatique par temps pour des requêtes rapides par plage
Agrégats continus — Rollups pré-calculés (1 min, 5 min, 1 heure) pour les performances des tableaux de bord
Politiques de rétention — Données chaudes (90 jours) dans PostgreSQL, données froides exportées vers un stockage en colonnes pour l'analytique long terme

La multi-location est appliquée au niveau de la base de données avec la sécurité au niveau des lignes (RLS). Chaque requête — qu'elle provienne de l'API, d'un tableau de bord ou d'un service interne — est automatiquement limitée au tenant authentifié. Ce n'est pas un filtrage applicatif qu'un bug pourrait contourner ; c'est une contrainte au niveau de la base de données qui rend l'accès aux données d'un autre tenant physiquement impossible sans credentials de superutilisateur.

Couche 5 : Inférence ML

Trois types de modèles par actif :

Détection d'anomalies

Un autoencoder LSTM apprend le schéma de fonctionnement normal pour chaque actif. Une erreur de reconstruction élevée = le comportement actuel ne correspond pas aux schémas appris. Le modèle traite une fenêtre glissante de données de capteurs multivariées (généralement 60 pas de temps) et produit un score d'erreur de reconstruction. Quand ce score dépasse un seuil appris (calibré par actif à partir des données de fonctionnement sain), une anomalie est signalée.

Durée de vie résiduelle (RUL)

Les modèles LSTM estiment le nombre de jours avant le prochain événement de maintenance. Un LSTM traitant des entrées brutes de 14 capteurs a atteint un RMSE de 11,48 jours sur le benchmark NASA C-MAPSS — ce qui signifie que les prédictions sont généralement précises à 11 jours près. Pour la planification pratique de la maintenance, c'est la différence entre « planifiez-le cette semaine » et « planifiez-le ce mois ».

Diagnostic de défauts

Un CNN 1D avec attention classifie les formes d'onde de vibration en catégories de défauts : piste intérieure, piste extérieure, défaut de bille, défaut de cage, désalignement, balourd. Pré-entraîné sur le jeu de données de roulements CWRU et affiné sur les données spécifiques à l'usine.

Exigences en données d'entraînement et précision attendue

Les performances des modèles dépendent fortement du volume de données :

| Volume de données | Meilleur modèle | Précision attendue | |---|---|---| | < 1 000 échantillons | Isolation Forest | Détecte les anomalies grossières, pas de RUL | | 1 000 - 50 000 | LSTM Autoencoder | Bonne détection d'anomalies, RUL de base | | 50 000 - 200 000 | LSTM + LightGBM | Anomalie forte + prédictions RUL | | > 200 000 + GPU | TranAD (Transformer) | Anomalie + RUL à l'état de l'art |

Pour un nouveau déploiement sans données historiques, les modèles pré-entraînés (entraînés sur le jeu de données de roulements CWRU et les données de turbofan NASA C-MAPSS) fournissent une capacité de référence immédiate. Ils ne sont pas parfaits pour votre équipement spécifique, mais ils encodent une physique de dégradation générale qui se transfère étonnamment bien entre classes d'équipements similaires.

Couche 6 : Moteur d'alerte

Le moteur d'alerte applique des règles métier :

Mapping de sévérité — Les seuils de score d'anomalie correspondent à des niveaux de sévérité. Un score 2x au-dessus du seuil est WARNING ; 4x est CRITICAL. Ces multiplicateurs sont configurables par classe d'actif, parce qu'une anomalie « critique » sur une pompe de secours a des implications opérationnelles différentes du même score sur un compresseur à point de défaillance unique.
Déduplication — Un roulement en dégradation génère des scores d'anomalie continus au-dessus du seuil. Sans déduplication, vous recevriez une alerte à chaque cycle d'inférence (généralement toutes les 30 à 60 secondes). Le moteur d'alerte regroupe les anomalies liées par actif et mode de défaillance, envoyant une seule alerte avec des mises à jour plutôt qu'un flux de notifications répétitives.
Escalade — Un WARNING non acquitté dans une fenêtre configurable (par défaut : 4 heures) ? Escaladez à CRITICAL et notifiez le niveau suivant. Un CRITICAL non acquitté en 1 heure ? Contactez le responsable de garde.
Attribution de caractéristiques — Chaque alerte montre quels capteurs ont contribué et dans quelle mesure. Ce n'est pas optionnel ou une fonctionnalité premium — c'est la différence entre une alerte qui est investiguée et une qui est ignorée.

Schémas d'intégration

Les alertes doivent atteindre les personnes là où elles travaillent. Le moteur d'alerte prend en charge plusieurs canaux de livraison simultanément :

PagerDuty / OpsGenie — pour la rotation de garde et l'escalade
ServiceNow / SAP PM / Maximo — ordres de travail créés automatiquement avec contexte de diagnostic
Webhooks — pour les intégrations personnalisées avec les systèmes internes
E-mail / SMS — pour les équipes n'utilisant pas de plateformes de gestion d'incidents
Push mobile — pour les opérateurs sur le terrain

Le problème du démarrage à froid

La question la plus courante des nouveaux déploiements PdM : « Que se passe-t-il le premier jour avec zéro donnée ? »

C'est là où la plupart des projets PdM internes calent. L'entraînement d'un autoencoder LSTM de zéro nécessite des semaines de données de fonctionnement propres. L'entraînement d'un modèle RUL nécessite des données historiques de défaillances — que vous n'aurez peut-être pas sous forme structurée.

Une plateforme moderne aborde le démarrage à froid en trois phases :

Jours 1-7 : Modèles pré-entraînés. Des modèles entraînés sur des jeux de données de référence publics (roulements CWRU, moteurs de turbofan NASA C-MAPSS) et des données inter-clients anonymisées fournissent une détection d'anomalies immédiate. Ils ne détecteront pas les modes de défaillance spécifiques à votre équipement, mais ils détecteront les schémas de dégradation courants (usure des roulements, balourd, emballement thermique) qui représentent 60 à 70 % des défaillances d'équipements rotatifs.

Semaines 2-4 : Apprentissage de la référence. Avec 2 à 4 semaines de données continues, la plateforme entraîne des modèles spécifiques à chaque actif. L'autoencoder LSTM apprend à quoi ressemble le « normal » pour chaque machine dans ses conditions de fonctionnement spécifiques. La précision de détection des anomalies s'améliore significativement parce que le modèle sait maintenant que la pompe 7A à 1 800 tr/min vibre normalement à 1,8 mm/s — pas seulement que « les pompes vibrent entre 0 et 10 mm/s ».

Mois 2+ : ML progressif. À mesure que les données s'accumulent, la plateforme améliore automatiquement les modèles : Isolation Forest → LSTM Autoencoder → TranAD (basé sur Transformer). Chaque amélioration améliore à la fois la sensibilité de détection et le délai d'anticipation. La transition est automatique — la plateforme suit les métriques de performance de chaque modèle et promeut le meilleur modèle quand il s'est prouvé sur des données de validation retenues.

Couche 7 : Action

Les alertes déclenchent : notifications PagerDuty/ServiceNow, ordres de travail créés automatiquement, webhooks pour les intégrations personnalisées et visualisation en temps réel sur les tableaux de bord. La couche finale boucle la boucle : défaillance prédite → alerte → investigation → ordre de travail → réparation → confirmation. Chaque étape est enregistrée, créant la piste d'audit qui alimente en retour le ré-entraînement des modèles et la mesure du ROI.

Prevly gère les sept couches en tant que plateforme managée. Voir comment ça fonctionne avec une démonstration interactive utilisant de vrais modèles ML.

Lectures complémentaires : La prédiction RUL expliquée · Surveillance OPC-UA en lecture seule · Débuter avec l'analyse vibratoire