La version marketing de la maintenance prédictive est simple : on installe quelques capteurs, l’IA apprend la machine, puis elle prévient avant que celle-ci ne tombe en panne.
La réalité est moins magique, mais bien plus utile.
L’apprentissage automatique est effectivement capable de reconnaître des corrélations et des évolutions difficiles à traiter avec de simples seuils. Mais seulement si les fondamentaux d’ingénierie, d’acquisition de données et d’exploitation sont en place au préalable.
La maintenance prédictive ne commence donc pas comme un projet d’IA, mais par une question très concrète :
Quelle défaillance voulons-nous détecter plus tôt, et quel phénomène physique la précède ?
Il ne s’agit pas de surveiller « la machine » en général
Un moteur, une pompe ou un réducteur peut tomber en panne de bien des manières. Usure des roulements, balourd, problème de lubrification, surcharge, défaut d’isolement ou refroidissement insuffisant laissent chacun une signature différente.
La première étape consiste donc à définir les modes de défaillance et leurs conséquences. Il faut savoir :
- ce qui peut tomber en panne ;
- à quelle fréquence cela se produit ;
- quel arrêt ou quel dommage cela provoque ;
- si cela peut être détecté à l’avance ;
- de combien de temps on dispose pour intervenir ;
- quel signal mesuré porte une information exploitable.
Sans réponse à ces questions, on aboutit facilement à une collecte de données coûteuse, qui produit beaucoup de courbes mais éclaire peu de décisions de maintenance.
Le bon capteur compte plus qu’un modèle spectaculaire
Sources de données courantes de la surveillance d’état industrielle :
- vibrations et accélération ;
- température ;
- courant électrique, tension et puissance ;
- signal acoustique ;
- pression et débit ;
- vitesse de rotation ;
- humidité ou autre grandeur d’environnement.
Il n’est toutefois pas indifférent de savoir où le capteur est placé, dans quelle direction il mesure, comment il est fixé, ni quels sont sa fréquence d’échantillonnage, sa plage de mesure et son niveau de bruit.
Une mauvaise fixation mécanique d’un capteur de vibrations peut faire plus de dégâts qu’un algorithme moins performant : le modèle apprendra systématiquement à partir de mauvaises données. Il en va de même d’un transformateur de courant inadapté, d’une mesure de température trop lente ou d’un signal acoustique coupé de son contexte de procédé.
L’échantillonnage doit être adapté au phénomène
Une température de roulement qui évolue lentement peut être suffisamment surveillée à la seconde ou à la minute. L’analyse spectrale des vibrations exige en revanche un échantillonnage plus rapide de plusieurs ordres de grandeur.
Si l’on mesure trop rarement, le phénomène important disparaît. Si l’on mesure plus souvent que nécessaire, on augmente inutilement le trafic de données et les coûts de traitement.
C’est pourquoi le traitement en périphérie (edge) peut être particulièrement utile. L’équipement local peut calculer, à partir du signal brut haute fréquence, des indicateurs tels que la valeur RMS, la valeur crête, le kurtosis ou l’énergie par bande de fréquences, et n’envoyer au système central que leur évolution dans le temps.
Il faut d’abord apprendre le fonctionnement normal
Les données d’une machine ne sont pas, en elles-mêmes, normales ou anormales. Une même consommation de courant peut avoir un sens différent à vide, à pleine charge, au démarrage ou pendant un cycle de nettoyage.
Une évaluation fiable de l’état nécessite donc le contexte d’exploitation :
- charge actuelle ;
- mode de fonctionnement ;
- produit ou recette ;
- température ambiante ;
- équipe (poste) ;
- état de maintenance ;
- événements de démarrage et d’arrêt.
La baseline n’est pas une simple valeur moyenne. C’est le domaine multidimensionnel du fonctionnement normal, qui peut varier d’une situation d’exploitation à l’autre.
Sans qualité des données, l’IA se trompe avec assurance
Les données industrielles réelles sont lacunaires, bruitées et parfois contradictoires. Un remplacement de capteur, une coupure de communication, un horodatage erroné, une mise à jour du firmware ou un réglage de procédé modifié peuvent rompre une série de données.
Il faut traiter :
- les échantillons manquants ;
- les données dupliquées ;
- les codes d’erreur enregistrés comme valeurs mesurées ;
- les changements de mise à l’échelle ;
- les problèmes de synchronisation horaire ;
- la dérive des capteurs ;
- le nouvel état de référence après une intervention de maintenance.
L’IA ne corrige pas automatiquement ces erreurs. Si on ne les détecte pas, le modèle peut même apprendre qu’un défaut de communication annonce une défaillance imminente de roulement.
L’apprentissage supervisé n’est pas toujours nécessaire
Dans l’industrie, les événements de défaillance correctement étiquetés sont souvent rares. C’est logique : heureusement, toutes les machines ne tombent pas en panne cent fois avec des circonstances documentées avec précision.
Plusieurs approches peuvent donc être envisagées :
- seuils d’ingénierie et systèmes de règles ;
- détection statistique de tendances et de ruptures ;
- détection d’anomalies non supervisée ;
- estimation de l’état ;
- classification supervisée, si des données étiquetées adaptées sont disponibles ;
- estimation de la durée de vie utile restante, si les données disponibles le permettent réellement.
Une bonne solution n’est pas avancée parce qu’elle utilise le modèle le plus complexe possible. Elle l’est parce qu’elle soutient la décision de maintenance au bon moment, avec un taux de fausses alarmes acceptable.
La valeur métier commence après l’alarme
Un score d’anomalie ne répare rien à lui seul. Il faut définir ce qui se passe ensuite :
- qui reçoit l’alerte ;
- quelles données complémentaires il peut consulter ;
- quel niveau de gravité est attribué à l’événement ;
- si une vérification sur site est nécessaire ;
- si un ordre de travail est ouvert ;
- comment le diagnostic et le résultat de la réparation sont réinjectés dans le processus d’apprentissage.
La force d’OrigSmart est précisément la prise en charge de toute la chaîne. De la conception des capteurs et des passerelles au traitement des séries temporelles et à l’analyse automatique, jusqu’à la tâche de maintenance et au retour d’expérience, un seul et même système peut fédérer le processus.
Mieux vaut en faire la preuve par un pilote
Un bon pilote de maintenance prédictive ne cherche pas à « mettre de l’IA » dans toute l’usine d’un coup. Il sélectionne un équipement ou un mode de défaillance important pour l’activité, définit le critère de réussite, installe la mesure nécessaire et démontre d’abord que les données sont disponibles de manière stable et interprétable.
Viennent ensuite la baseline, l’évaluation des anomalies et le retour des équipes de maintenance. Le modèle ne peut passer à un niveau d’automatisation supérieur que si les résultats d’exploitation réels le justifient.
La maintenance prédictive ne devient donc pas intelligente parce qu’on y appose le mot IA.
Elle devient intelligente lorsqu’elle transforme le bon signal physique, dans le bon contexte et via un flux de données fiable, en une véritable décision de maintenance.
Parlons de votre projet