IoT industriel : maintenance prédictive par apprentissage machine

L'équipementier industriel français qui nous a confié ce projet exploite une usine de 14 machines critiques — presses, fraiseuses CN, lignes d'extrusion — dont les pannes non programmées coûtaient en moyenne 4 200 € par heure d'arrêt, sans compter les pénalités contractuelles sur les retards de livraison. Deux pannes catastrophiques en 18 mois (broche de fraiseuse haute vitesse et palier de presse, 28 k€ de réparation chacune) avaient déclenché la décision de passer en maintenance prédictive. La direction industrielle nous a posé une contrainte simple : un ROI démontrable en moins de 18 mois ou le projet serait coupé. La première étape — souvent sous-estimée — était l'instrumentation physique. Sur chaque machine, nous avons posé trois capteurs : un accéléromètre triaxial 8 kHz sur le palier le plus chargé (la vibration est le meilleur indicateur précoce de dégradation mécanique), une PT100 sur le roulement de l'arbre moteur, et un tore de Rogowski sur la phase d'alimentation pour suivre le courant en charge. Le choix du 8 kHz n'est pas anodin : il permet de capter le contenu harmonique jusqu'au sixième multiple de la fréquence de rotation, là où apparaissent les défauts de roulement (BPFI, BPFO) avant qu'ils ne soient perceptibles à l'oreille. La connectivité radio passe par LoRaWAN sur un gateway Kerlink installé en toiture d'atelier. LoRaWAN ne convient pas pour les flots brut de vibration (trop peu de bande passante) ; nous transportons donc des features extraites localement : RMS, kurtosis, fréquence dominante, spectre réduit à 32 bins. L'extraction tourne sur un edge gateway Raspberry Pi CM4 placé en pied de machine, qui agrège aussi les lectures température / courant, les horodate avec un GPS local pour la précision sous-seconde, et bufferise jusqu'à 24 h en cas de perte radio. Cette dernière clause a sauvé le projet pendant un orage qui a coupé la connectivité usine pendant 7 heures. Le backend tourne sur FastAPI avec TimescaleDB en stockage. TimescaleDB n'est pas un détail : sur des séries hautement chronologiques, les hypertables et la compression native diminuent l'empreinte disque d'un facteur 7 à 12 par rapport à un PostgreSQL nu, et les agrégations continues permettent de servir les dashboards en sub-100 ms sans précalcul applicatif. Les ingestions arrivent par MQTT (Mosquitto en HA), passent par une couche de normalisation et de déduplication, puis sont publiées sur un bus Redis Streams consommé par les workers de scoring ML. Le modèle ML est le sujet où la plupart des projets échouent. Nous avons explicitement refusé un modèle générique « anomalie sur toutes les machines » : chaque machine a sa propre signature vibratoire, son propre régime de fonctionnement, sa propre historique d'usure. Nous entraînons donc un couple Isolation Forest + autoencodeur dense par machine, sur les 6 à 12 premiers mois de données après calibration. L'Isolation Forest gère les anomalies ponctuelles ; l'autoencodeur capte les dérives lentes, celles qui annoncent une dégradation 2 à 3 semaines avant la panne. Le score combiné est seuil par machine, ajusté tous les trimestres. La boucle de retour humaine est la pièce que la plupart des projets oublient. Chaque alerte arrive dans le CMMS (GMAO) de l'équipementier avec un lien vers le dashboard et un champ obligatoire d'annotation à la clôture : « vraie dégradation », « faux positif », « maintenance préventive avancée ». Ces annotations alimentent un job nocturne qui réajuste les seuils par machine et réentraîne mensuellement les modèles. C'est ce qui a fait passer le taux de faux positifs de 31% au démarrage à 7% au bout de quatre mois — sans intervention manuelle des data scientists. La mise en production a été progressive : trois machines en pilote pendant trois mois, puis cinq, puis le reste. Cette approche est volontaire : elle laisse le temps à l'équipe maintenance d'apprendre à faire confiance au système, et elle nous donne la base statistique pour calibrer correctement les seuils avant d'élargir. Deux pannes catastrophiques évitées pendant le pilote (la même broche fraiseuse qui avait coûté 28 k€ l'année précédente, et un palier détecté avec 11 jours d'avance) ont définitivement convaincu la direction. Sur les douze mois suivants, le taux d'arrêts imprévus a baissé de 38%, les coûts de maintenance corrective de 22%, et l'OEE (Overall Equipment Effectiveness) a gagné 9 points (de 64% à 73%). Le ROI a été atteint au mois 11, principalement par les deux pannes lourdes évitées, l'extension de durée de vie des roulements (remplacement programmé plutôt qu'en urgence) et la suppression du sur-stockage de pièces de rechange. La direction industrielle a depuis lancé l'extension à un deuxième site, avec un seuil ROI fixé à 14 mois sur la base de l'expérience acquise.