Maintenance prédictive : ce qui fait réussir un projet, et ce qui le fait échouer
Les promesses de retour sur investissement sont élevées, les abandons aussi. Les vraies difficultés sont rarement le modèle : ce sont les données, l'intégration et la décision qui suit l'alerte.
La maintenance prédictive — anticiper une panne plutôt que la subir ou la prévenir à intervalles fixes — fait partie des applications les plus citées de l'IoT industriel. Les retours d'expérience publiés sont contrastés : certains évoquent des retours rapides, d'autres des programmes abandonnés ou sans gain mesurable au bout de dix-huit mois. Les chiffres varient fortement selon les sources et leur objectivité (beaucoup viennent de fournisseurs) ; il vaut mieux retenir les causes d'échec, qui reviennent d'un article à l'autre.
Premier piège : la donnée
Les praticiens estiment qu'une très grande partie de l'effort — de l'ordre de 70 % dans plusieurs témoignages — porte sur l'ingénierie des données plutôt que sur le modèle. Les capteurs dérivent, les relevés comportent des trous et du bruit, les unités et les horodatages ne sont pas cohérents entre machines. Ces défauts se cumulent sur un grand parc. Un modèle sophistiqué alimenté par des mesures douteuses produit des alertes douteuses (SumatoSoft).
Deuxième piège : l'absence de pannes
Pour apprendre à reconnaître une défaillance, un modèle supervisé a besoin d'exemples de défaillances. Si une pompe fonctionne dix ans avant de tomber en panne, il y a très peu de données de panne. Dans ce cas, mieux vaut commencer par de la détection d'anomalie — repérer ce qui s'écarte du comportement normal — et par des règles physiques simples (seuils de vibration, température, courant) avant de viser une prédiction fine de la durée de vie restante.
Troisième piège : l'alerte sans décision
Une alerte n'a de valeur que si quelqu'un peut agir dessus à temps : pièce disponible, arrêt planifiable, technicien joignable. Les projets qui échouent produisent des alertes que personne n'a le pouvoir ou le temps de traiter, ou trop de fausses alertes qui épuisent la confiance des équipes. L'intégration avec la GMAO (la gestion de maintenance) et le planning de production compte autant que le modèle.
Quatrième piège : le périmètre
Instrumenter tout le parc pour « voir ce qui se passe » dilue l'effort. L'approche qui tient est de partir de quelques équipements critiques — ceux dont l'arrêt coûte le plus cher ou pose un risque de sécurité — d'y démontrer un gain, puis d'étendre. Les modèles ont besoin de plusieurs mois de fonctionnement avant de se stabiliser : le pilote doit durer assez longtemps pour être jugé.
Une démarche qui réduit le risque
- Chiffrer le coût d'un arrêt sur l'équipement visé : sans cette base, aucun retour sur investissement n'est démontrable.
- Auditer les données existantes avant d'acheter quoi que ce soit : ce que mesurent déjà les automates, avec quelle qualité.
- Commencer par l'anomalie et les règles simples, ajouter l'apprentissage quand les données le justifient.
- Définir qui fait quoi quand une alerte tombe, et mesurer le taux d'alertes utiles.
- Prévoir la sécurité des flux dès le départ : l'équipement connecté devient un point d'entrée possible (voir notre article sur la sécurité OT).
Notre lecture
La maintenance prédictive est un projet de métier avant d'être un projet d'IA : comprendre les modes de défaillance, la manière dont les équipes interviennent et ce qu'une heure d'arrêt coûte réellement. L'IA vient ensuite, sur une base de données propre, pour un cas d'usage borné.
Sources
Un projet IoT en tête ?
Décrivez votre contexte, on vous propose une solution sur mesure.