Maintenance prédictive et machine learning : features, labels et modèles

La maintenance prédictive par machine learning exploite les données d'état des machines pour estimer si une panne se prépare, afin de planifier l'intervention avant la casse plutôt qu'après. Dans ce guide, vous verrez comment collecter les bons signaux via MQTT, les transformer en features et en labels, choisir un premier modèle et le valider d'une manière qui reflète son comportement réel en atelier.

Ce que le machine learning apporte à la maintenance

La plupart des usines pratiquent déjà une forme de surveillance d'état : une alarme vibratoire à un niveau fixe, une limite de température sur un roulement. Ces seuils statiques fonctionnent pour les défauts évidents, mais ils ratent les dégradations lentes et multi-signaux, et se déclenchent souvent tard. Le machine learning apporte deux choses. Il peut combiner plusieurs signaux faibles en un indicateur plus fort, et il peut apprendre à quoi ressemble la « normalité » de chaque machine sous différentes charges, au lieu d'appliquer une limite unique à toutes.

Il faut aussi être clair sur ses limites. Un modèle ne peut apprendre que les schémas de panne présents dans ses données. Si un type de machine n'est tombé en panne que deux fois en cinq ans, un classifieur de pannes supervisé n'apprendra pas grand-chose ; une approche par détection d'anomalies ou par tendance de dégradation convient mieux. Bien poser le problème compte davantage que le choix de l'algorithme.

Poser le problème

Beaucoup d'équipes commencent par la détection d'anomalies, car elle ne nécessite aucun label, puis passent à la classification une fois qu'elles ont collecté assez d'événements labellisés. L'article sur la détection d'anomalies IoT couvre cette première étape, et celui sur la prédiction de la durée de vie résiduelle couvre la formulation en régression.

Collecter les données d'état via MQTT

Les signaux doivent suivre les modes de défaillance qui vous intéressent. Pour les machines tournantes, l'ensemble habituel comprend des indicateurs vibratoires, la température des roulements ou des bobinages, le courant moteur et la vitesse. Pour les systèmes hydrauliques et pneumatiques : pression, débit et temps de cycle. Incluez toujours le contexte de fonctionnement comme la charge, la consigne de vitesse et le produit, car un modèle qui ignore la charge confondra un lot lourd avec un défaut naissant.

Une organisation MQTT pratique publie les indicateurs par actif sous une hiérarchie, avec des horodatages source :

connectmq/plant1/line2/pump3/condition   {"ts":..., "vib_rms":..., "vib_peak":..., "bearing_temp":..., "current":..., "load":...}
connectmq/plant1/line2/pump3/events      {"ts":..., "type":"maintenance", "action":"bearing replaced"}

Calculez les indicateurs vibratoires à l'edge plutôt que de diffuser des formes d'onde en kHz. Une fenêtre d'une seconde fournit le RMS, la crête, le facteur de crête et quelques énergies par bande spectrale, un volume assez faible pour être publié toutes les quelques secondes. Le topic des événements est aussi important que la télémétrie : sans actions de maintenance et pannes consignées, impossible de construire des labels. Le guide sur la labellisation des séries temporelles de capteurs montre comment recueillir ces événements auprès des opérateurs.

Le feature engineering pour la maintenance prédictive par machine learning

Les mesures brutes sont rarement les meilleures entrées de modèle. La dégradation se manifeste par des évolutions de niveau, de variabilité et de tendance dans le temps ; les features sont donc généralement calculées sur des fenêtres glissantes.

• Features de niveau : moyenne glissante du RMS vibratoire, de la température, du courant.
• Features de variabilité : écart-type glissant, crête à crête, facteur de crête.
• Features de tendance : pente d'un ajustement linéaire sur les dernières heures ou les derniers jours.
• Features relatives : échauffement par rapport à l'ambiante, courant par unité de charge, vibration comparée à la référence de la même machine.
• Features spectrales : énergie dans les bandes liées aux fréquences de défaut des roulements ou au balourd.
• Contexte de fonctionnement : charge, vitesse, heures de marche depuis la dernière maintenance.

Normalisez par actif lorsque les machines diffèrent. Une pompe qui a toujours vibré un peu plus que ses voisines ne se dégrade pas forcément ; c'est l'évolution par rapport à son propre historique qui compte.

Construire des labels sans fuite de données

Pour une formulation en classification, un label courant est « tombera en panne dans les H prochaines heures ». Vous prenez chaque horodatage de panne et marquez comme positives les fenêtres situées dans l'horizon qui la précède, tout le reste étant négatif. Trois règles gardent les labels honnêtes :

1. Excluez la période qui suit immédiatement une maintenance pendant un court laps de temps, car les mesures en phase de rodage ne sont pas représentatives.
2. Écartez les fenêtres qui contiennent la panne elle-même, sinon le modèle apprend à reconnaître une machine à l'arrêt.
3. Ne calculez jamais de features avec des données postérieures à l'horodatage de la fenêtre. Les fenêtres glissantes centrées sont une source classique de fuite.

Un exemple fonctionnel en Python

Le script ci-dessous génère des données d'état simulées pour plusieurs pompes, dont certaines se dégradent, les publie sur le serveur MQTT public gratuit (réservé aux tests et aux prototypes, jamais aux données de production), les récupère avec un abonné et entraîne un classifieur à gradient boosting évalué sur des pompes qu'il n'a jamais vues pendant l'entraînement. En pratique, le collecteur lirait plutôt depuis votre historian.

import json
import random
import time
import uuid

import numpy as np
import pandas as pd
import paho.mqtt.client as mqtt
from sklearn.ensemble import HistGradientBoostingClassifier
from sklearn.metrics import classification_report

BROKER = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1"
rows = []


def on_message(client, userdata, msg):
    p = json.loads(msg.payload)
    p["asset"] = msg.topic.split("/")[-2]
    rows.append(p)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pdm-" + uuid.uuid4().hex[:8])
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.subscribe(f"{PREFIX}/+/condition", qos=1)
client.loop_start()
time.sleep(1)

# Simuler 6 pompes x 600 pas ; certaines se dégradent jusqu'à la panne à la fin
for asset in range(6):
    fails = asset % 2 == 0
    for step in range(600):
        wear = max(0, step - 400) / 200 if fails else 0
        body = {
            "step": step,
            "vib_rms": round(1.0 + 1.5 * wear ** 2 + random.gauss(0, 0.08), 3),
            "bearing_temp": round(55 + 12 * wear + random.gauss(0, 0.5), 2),
            "current": round(14 + 1.5 * wear + random.gauss(0, 0.2), 2),
            "load": round(random.uniform(0.6, 1.0), 2),
            "failed_at": 600 if fails else None,
        }
        client.publish(f"{PREFIX}/pump{asset}/condition", json.dumps(body), qos=0)
        time.sleep(0.11)  # rester sous la limite de 10 msg/s par client du broker public

time.sleep(3)
client.loop_stop()

df = pd.DataFrame(rows).sort_values(["asset", "step"])
HORIZON = 100
df["label"] = ((df["failed_at"].notna()) & (df["failed_at"] - df["step"] <= HORIZON)).astype(int)

feats = []
for col in ["vib_rms", "bearing_temp", "current"]:
    g = df.groupby("asset")[col]
    df[f"{col}_mean20"] = g.transform(lambda s: s.rolling(20, min_periods=5).mean())
    df[f"{col}_std20"] = g.transform(lambda s: s.rolling(20, min_periods=5).std())
    df[f"{col}_slope50"] = g.transform(lambda s: s.diff(50) / 50)
    feats += [f"{col}_mean20", f"{col}_std20", f"{col}_slope50"]
feats.append("load")
df = df.dropna(subset=feats)

# Découpage par actif : entraînement sur les pompes 0 à 3, test sur les pompes 4 et 5 jamais vues
train, test = df[~df["asset"].isin(["pump4", "pump5"])], df[df["asset"].isin(["pump4", "pump5"])]
model = HistGradientBoostingClassifier(max_iter=200, learning_rate=0.05)
model.fit(train[feats], train["label"])
print(classification_report(test["label"], model.predict(test[feats]), digits=3))

Installez les dépendances avec pip install paho-mqtt pandas numpy scikit-learn. L'exécution prend plusieurs minutes, car le simulateur respecte la limite de débit du serveur MQTT public gratuit. Avec votre propre broker ConnectMQ, en utilisant YOUR_USERNAME, YOUR_PASSWORD et YOUR_CLIENT_ID sur le port 8883, vous pouvez publier depuis de nombreux appareils en parallèle.

Choisir un premier modèle

• Les arbres à gradient boosting (scikit-learn, XGBoost, LightGBM) sont le choix par défaut pour les features tabulaires. Ils gèrent des échelles hétérogènes, demandent peu de réglages et fournissent des importances de features dont les ingénieurs maintenance peuvent discuter.
• La régression logistique est une référence utile et facile à expliquer.
• Isolation Forest ou les autoencodeurs pour une formulation en anomalies lorsque les labels sont rares.
• Les modèles séquentiels (LSTM, CNN 1D, transformers) seulement lorsque vous disposez d'un long historique et que les modèles simples plafonnent.

Valider comme en production

Les découpages aléatoires entraînement-test surestiment les performances sur les séries temporelles, car des fenêtres voisines sont presque identiques. Utilisez un découpage temporel et, idéalement, mettez de côté des actifs entiers pour vérifier que le modèle se généralise à des machines qu'il n'a pas vues. Indiquez la précision et le rappel au seuil d'alerte que vous comptez utiliser, et traduisez-les en termes opérationnels : combien de fausses alarmes par semaine, et combien de pannes détectées avec quelle avance. Ce sont les chiffres qui intéressent un planificateur de maintenance.

Déployer et boucler la boucle

Un modèle déployé n'est qu'un client MQTT de plus. Il s'abonne aux topics d'état, évalue chaque nouvelle fenêtre et publie un score de risque :

connectmq/plant1/line2/pump3/health   {"ts":..., "risk":0.82, "model":"pdm-gbt-1.4"}

Les tableaux de bord, les connecteurs de GMAO et les outils d'alerte s'abonnent à ce topic. Dans le portail ConnectMQ, vous pouvez aussi définir des règles d'alerte à seuil sur la valeur de risque publiée, de sorte qu'un score supérieur à la limite choisie apparaisse dans le journal des alertes sans code supplémentaire. Consignez l'issue de chaque alerte sous forme d'événement, réinjectez-la dans les labels et réentraînez périodiquement ; l'article sur le MLOps IoT couvre ce cycle de vie.

Pour une vue d'ensemble des modèles et des appareils qui travaillent ensemble, consultez le guide IA et IoT. Pour aborder le même problème sous l'angle du jumeau numérique, la maintenance prédictive par jumeau numérique ajoute un contexte physique à l'approche fondée sur les données.

Démarrez avec ConnectMQ

Commencez dès aujourd'hui à collecter des données d'état : créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et connectez vos appareils edge avec les identifiants générés. ConnectMQ vous offre un broker MQTT managé avec TLS, un explorateur de topics en direct et des alertes à seuil, pour que vous puissiez vous concentrer sur les features et les modèles plutôt que sur l'exploitation du broker. Si vous avez besoin plus tard de davantage de connexions ou d'isolation, les mêmes topics migrent vers une offre de broker MQTT cloud plus capacitaire.

Questions fréquentes

Combien de données faut-il pour la maintenance prédictive par machine learning ?

Pour la prédiction supervisée des pannes, il vous faut plusieurs pannes consignées par mode de défaillance, ainsi que les données d'état qui précèdent chacune d'elles. Si vous avez peu de pannes, commencez par la détection d'anomalies sur des données normales et collectez des événements labellisés au fil de l'eau.

Quel est le meilleur algorithme pour la maintenance prédictive ?

Les arbres à gradient boosting appliqués à des features glissantes bien construites constituent un excellent point de départ pour la plupart des données d'état. Les modèles séquentiels profonds peuvent aider avec de longs historiques, mais ils battent rarement de bonnes features sur de petits jeux de données.

Pourquoi mon modèle semble-t-il précis en test mais échoue-t-il en production ?

Les causes les plus fréquentes sont les découpages aléatoires qui font fuiter des fenêtres quasi identiques dans le jeu de test, les features calculées avec des données futures et l'absence de contexte de fonctionnement. Utilisez des découpages temporels ou par actif et vérifiez soigneusement les fenêtres de features.

Le broker MQTT peut-il exécuter le modèle ?

Non, le broker route les messages. Exécutez le modèle comme un client MQTT séparé, à l'edge ou dans le cloud, qui s'abonne aux topics d'état et republie les scores vers le broker.