Maintenance prédictive industrielle avec n8n : centraliser les alertes capteurs IoT avant la panne

Dans la plupart des ateliers, les données existent déjà : un automate qui mesure une vibration, une sonde de température sur un moteur, un compteur d'heures sur un compresseur. Le problème n'est pas l'absence de capteurs, c'est leur dispersion — un tableau de bord SCADA que seul le technicien de quart consulte, un export CSV manuel une fois par semaine, une alarme sonore qu'on finit par ignorer. La panne arrive alors sans qu'aucune des données qui l'annonçaient n'ait été croisée à temps. n8n ne remplace pas un système de supervision industrielle, mais il excelle à faire exactement ce qui manque entre les capteurs et l'équipe de maintenance : centraliser les flux, filtrer le bruit, et router la bonne alerte vers la bonne personne avant que l'arrêt de production ne devienne la seule option.

Pourquoi centraliser avant de prédire

L'appellation « maintenance prédictive » évoque souvent un modèle de machine learning sophistiqué entraîné sur des années d'historique. Dans les faits, la première victoire — et la plus rentable — est presque toujours plus simple : faire converger des signaux déjà disponibles mais jamais croisés. Une revue systématique de la littérature sur la maintenance prédictive en Industrie 4.0 menée par Tiago Zonta et ses co-auteurs (Predictive maintenance in the Industry 4.0: A systematic literature review, Computers & Industrial Engineering, 2020, analysant 187 études) constate que l'intégration IoT et la centralisation des données de capteurs constituent le socle indispensable de toute démarche prédictive — avant même la sophistication des modèles utilisés en aval. Autrement dit : un pipeline d'ingestion et de filtrage fiable rapporte plus, plus vite, qu'un modèle prédictif isolé branché sur des données éparses.

C'est exactement le rôle qu'un outil d'automatisation comme n8n peut jouer dans une démarche de maintenance prédictive : pas remplacer les capteurs ni la GMAO (gestion de maintenance assistée par ordinateur), mais le tissu conjonctif qui relie l'un à l'autre.

Ingérer les données de capteurs dans n8n

Trois familles de sources couvrent la quasi-totalité des cas rencontrés en atelier :

• MQTT : le protocole de fait pour les capteurs et automates qui publient déjà vers un broker (Mosquitto, AWS IoT Core, HiveMQ). Le node MQTT de n8n s'abonne à un topic (par exemple usine/ligne3/moteur-A/vibration) et déclenche un workflow à chaque nouvelle mesure, sans configuration réseau supplémentaire côté capteur.
• Webhooks depuis une plateforme de supervision : la plupart des solutions SCADA ou GMAO modernes (Losant, ThingsBoard, Fiix, Hexagon) exposent des webhooks ou une API REST déclenchée sur seuil. Un trigger Webhook n8n reçoit alors l'événement déjà pré-filtré côté plateforme.
• Polling planifié : pour un automate ancien sans API ni MQTT, un Schedule Trigger interroge périodiquement une passerelle Modbus-vers-HTTP ou une base locale exposée par l'intégrateur — moins réactif, mais universel.

Dans les trois cas, la donnée brute arrivant dans n8n est la même : un identifiant d'équipement, une valeur mesurée, un horodatage. Le travail commence après.

Filtrer avant d'alerter : seuils, hystérésis et déduplication

Un capteur de vibration qui oscille autour d'un seuil génère, sans filtrage, des dizaines d'alertes identiques par heure — le meilleur moyen pour qu'une équipe de maintenance finisse par ignorer le canal entier. Trois garde-fous, combinables :

1. Seuil avec hystérésis : déclencher au-dessus d'un seuil haut, mais n'autoriser un nouveau déclenchement qu'après repassage sous un seuil bas distinct. Un node IF ou Switch suffit à l'implémenter si les deux bornes sont stockées avec l'équipement.
2. Fenêtre de non-répétition : enregistrer, pour chaque équipement, l'horodatage de la dernière alerte envoyée — dans une Data Table n8n pour un besoin léger, ou une table Postgres si le volume de capteurs est important — et bloquer toute nouvelle alerte tant que la fenêtre minimale (par exemple 30 minutes) n'est pas écoulée.
3. Déduplication par cause commune : quand un seul dysfonctionnement fait réagir plusieurs capteurs en même temps (vibration et température qui montent ensemble sur le même moteur), le node Remove Duplicates ou une agrégation par identifiant d'équipement regroupe ces signaux en un seul ticket au lieu d'un par capteur.

Cette étape de filtrage, invisible mais décisive, est ce qui distingue un pipeline d'alertes exploitable d'un flux de notifications que plus personne ne lit.

Laisser un agent IA prioriser avant l'humain

Une fois le bruit éliminé, toutes les alertes restantes ne se valent pas : une dérive lente de température sur un équipement redondant n'a pas la même urgence qu'une vibration anormale sur la seule presse de la ligne. Susto et ses co-auteurs, dans Machine Learning for Predictive Maintenance: A Multiple Classifiers Approach (IEEE Transactions on Industrial Informatics, 2015), montrent qu'une classification multi-critères (type de signal, criticité de l'équipement, historique de pannes) améliore nettement la priorisation par rapport à un seuil unique appliqué uniformément.

Dans n8n, un node AI Agent peut jouer ce rôle de triage sans entraîner de modèle dédié : à partir du contexte transmis (équipement concerné, type de mesure, valeur, historique récent des alertes sur cet équipement récupéré via une requête Postgres ou Data Table), l'agent classe la sévérité (information / à surveiller / urgent), rédige une description exploitable pour le technicien, et peut consulter la documentation de maintenance de l'équipement si elle est indexée dans une base vectorielle — un usage direct du RAG avec Supabase appliqué à la documentation technique plutôt qu'au support client.

Router vers le bon canal selon la criticité

Une alerte « information » peut atterrir dans un canal Slack consulté au prochain point d'équipe. Une alerte « urgent » sur un équipement critique mérite un canal différent — SMS d'astreinte, appel automatisé — et, pour les décisions qui impliquent d'arrêter une ligne de production, une validation humaine explicite plutôt qu'une action automatique. Le node Wait combiné à des boutons Slack permet de mettre le workflow en pause jusqu'à ce qu'un responsable confirme l'arrêt, tandis qu'un node Stop and Error documente explicitement les cas où le workflow doit s'interrompre plutôt que de deviner une suite.

Exemple de workflow complet

1. Trigger MQTT sur les topics de capteurs d'une ligne, ou Webhook depuis la plateforme de supervision.
2. Enrichissement : jointure avec les métadonnées de l'équipement (criticité, historique) stockées en Postgres ou Data Table.
3. Filtrage : seuil avec hystérésis, fenêtre de non-répétition, agrégation par équipement.
4. AI Agent : classification de sévérité et rédaction d'une description de l'anomalie, avec accès à la documentation technique indexée.
5. Routage conditionnel : Slack pour une alerte informative, SMS/appel pour une alerte urgente, Wait + approbation humaine avant tout arrêt de ligne.
6. Journalisation : insertion de l'alerte, de sa sévérité et de la décision prise dans une table d'historique, réutilisable pour l'audit de maintenance.

Garder une piste d'audit pour les contrôles réglementaires

Dans l'industrie, la traçabilité des interventions de maintenance n'est pas un confort : elle conditionne souvent les audits qualité (ISO 9001, ISO 27001) ou les obligations sectorielles de sécurité. Le principe décrit dans notre guide sur la piste d'audit RGPD avec n8n et Supabase s'applique directement ici : chaque alerte traitée, chaque décision d'arrêt validée par un humain, chaque intervention déclenchée gagne à être journalisée avec horodatage et identifiant de l'exécution — une base solide si votre organisation doit un jour prouver qu'un signal d'alerte a bien été traité dans les délais. Le Pack Conformité & Audit (149 €) fournit une base de départ pour ce type de journalisation, pensée pour être adaptée à un contexte industriel plutôt que purement logiciel.

Pour aller plus loin

La maintenance prédictive n'exige pas de partir d'un data lake et d'un modèle de deep learning : elle commence par un pipeline fiable qui centralise ce que vos capteurs remontent déjà, filtre le bruit, et priorise ce qui mérite vraiment l'attention d'un technicien. n8n couvre cette couche d'orchestration sans nécessiter d'équipe data dédiée — un point de départ réaliste avant, éventuellement, d'investir dans un modèle de détection d'anomalie plus fin une fois l'historique de données suffisamment propre pour l'entraîner.