Créer une IA de supervision pour vos machines
Une IA MQpanel n'est pas un chatbot : c'est un agent qui apprend, à partir d'une simple description en langage naturel, quelles variables surveiller sur un topic MQTT, puis analyse en continu la télémétrie reçue pour détecter des anomalies et produire un diagnostic exploitable.
Comment ça fonctionne
Vous décrivez votre machine et son fonctionnement en langage naturel dans une conversation guidée ; l'IA propose une liste de variables pertinentes à surveiller (avec leur type, leur unité et leurs bornes physiques plausibles), que vous validez ou ajustez. Une fois configurée, l'IA s'abonne au topic MQTT choisi et analyse chaque message reçu pour distinguer un fonctionnement normal d'une dérive suspecte.Comprendre l'interface de création
Le Chatbot IA (à droite)
C'est votre assistant. Discutez avec lui en langage naturel pour décrire la machine, son comportement et les variables à surveiller.
Le Formulaire (à gauche)
Il se remplit automatiquement en temps réel grâce aux informations extraites par le chatbot. Vous pouvez aussi le modifier manuellement.
L'évaluation RETEX
Un bouton pour simuler et évaluer la faisabilité de votre configuration avant de la déployer.
Le Déploiement
Une fois tous les champs au vert, sauvegardez pour lancer l'IA de supervision en continu sur votre topic.
- 1
Décrire la machine en langage naturel
Dans la conversation de configuration, indiquez le nom, le type, le numéro de série et surtout le fonctionnement de la machine (ex. « pompe centrifuge qui tourne en continu, la vibration augmente anormalement en cas d'usure du roulement »).
- 2
Laisser l'IA proposer les variables à suivre
À partir de votre description, l'IA génère une liste de variables (jusqu'à 20) avec leur type — numérique, booléen ou texte —, leur unité SI, une justification, et pour les variables numériques des bornes physiques plausibles (min/max) qui serviront à repérer une valeur aberrante.
- 3
Vérifier la faisabilité (RETEX)
Avant de déployer, un retour d'expérience (RETEX) évalue si la télémétrie proposée est suffisante pour détecter les anomalies décrites, avec un score de faisabilité sur 100 et des recommandations concrètes sur les données à ajouter.
- 4
Choisir le topic MQTT et le mode d'IA
Associez la configuration à un topic MQTT précis (jusqu'à 10 niveaux, sans wildcard #) et choisissez le mode d'analyse : 1.5 pour une supervision légère et rapide, 2.0 pour une analyse plus fine sur des comportements complexes.
- 5
Régler précision et mémoire
Deux curseurs de 1 à 100 % ajustent la sensibilité de détection (precisionPct) et la profondeur d'historique prise en compte pour juger d'une tendance (memoryPct).
- 6
Configurer les alertes
Définissez le seuil d'alarme, le nombre d'anomalies consécutives avant déclenchement, et une durée de bouclier (« shield ») de 1 minute à 7 jours pour éviter le spam d'alertes après un premier signalement.
- 7
Laisser l'IA superviser en continu
Une fois sauvegardée, l'IA tourne 24/7 : elle consomme la télémétrie du topic, met à jour son diagnostic, et déclenche une alerte dès que ses critères sont réunis.
Exemple : variables proposées pour une pompe centrifuge
| Variable | Type | Unité | Plage | Raison |
|---|---|---|---|---|
| temp_roulement_1 | numeric | °C | 0 – 120 | Une surchauffe du roulement précède presque toujours une casse mécanique. |
| vibration_axe | numeric | mm/s | 0 – 25 | Une vibration anormale signale un désalignement ou une usure de roulement. |
| etat_process | string (étapes) | — | arrêt / démarrage / régime / arrêt urgence | Contextualise les autres variables : une vibration élevée au démarrage est normale, en régime elle ne l'est pas. |
| defaut_actif | bool | — | vrai / faux | Reflète directement un code défaut déjà remonté par l'automate de la machine. |
Que contient un diagnostic d'anomalie ?
Quand l'IA détecte une dérive suspecte, elle ne se contente pas d'une alerte binaire : elle produit un diagnostic structuré que vous pouvez évaluer en retour (utile, inutile, faux) pour affiner ses futures analyses.
Verdict
Panne confirmée, données insuffisantes pour conclure, ou probable faux positif.
Confiance
Niveau de confiance de l'IA dans son verdict : faible, moyenne ou élevée.
Cause probable
L'hypothèse la plus vraisemblable expliquant l'anomalie observée.
Recommandation
L'action concrète suggérée (ex. inspection, arrêt préventif, resurveillance).
Preuves
Les éléments de télémétrie qui justifient le diagnostic, pour vérification humaine.
Ajuster la sensibilité des alertes
Seuil d'alarme
1 – 100 %
Le niveau de confiance à partir duquel une anomalie déclenche une alerte.
Nombre d'erreurs déclencheur
1 – 50
Le nombre d'anomalies consécutives requis avant de déclencher une alerte, pour filtrer le bruit ponctuel.
Durée du bouclier
1 min – 7 jours
La période de silence après une alerte pendant laquelle une nouvelle alerte similaire n'est pas renvoyée. Un e-mail d'alerte est envoyé à son activation. Lorsqu'il est actif, l'IA n'apprend plus pour éviter l'empoisonnement du modèle. Le bouclier se désactive dès qu'un humain intervient sur l'IA.
Bonnes pratiques pour une détection fiable
La qualité de la détection dépend bien plus de la télémétrie que vous envoyez et du réglage de vos alertes que du mode d'IA choisi. Voici ce qui fait la différence en production.
Décrivez le process, pas seulement la machine
À faire
Expliquez les phases de fonctionnement, ce qui est normal, ce qui ne l'est pas, et la panne que vous cherchez à anticiper. Plus la description est concrète, plus les variables proposées seront pertinentes.
À éviter
Se limiter à « pompe qui chauffe parfois » : sans contexte de fonctionnement, l'IA ne peut pas distinguer une montée en température normale d'une dérive.
Envoyez peu de variables, mais les bonnes
À faire
Gardez uniquement les variables réellement liées à la panne que vous cherchez à détecter — quelques mesures bien choisies valent mieux qu'une longue liste. La limite est de 20 variables par IA.
À éviter
Déverser tout le payload de l'automate « au cas où » : les variables sans lien avec la panne diluent le signal utile, ajoutent du bruit et rendent les diagnostics plus vagues.
Publiez une télémétrie régulière et stable
À faire
Envoyez toutes les variables validées dans un même message JSON, à intervalle constant, avec des noms de clés et des unités qui ne changent jamais.
À éviter
Renommer une clé, changer d'unité (°C vers K) ou n'envoyer certains champs que de temps en temps : l'IA perd sa référence et multiplie les faux positifs.
Ajoutez une variable de contexte
À faire
Publiez l'état courant du process (arrêt, démarrage, régime établi, arrêt d'urgence) à côté de vos mesures physiques.
À éviter
Envoyer une vibration ou un courant sans indiquer la phase : un pic normal au démarrage sera alors signalé comme une anomalie.
Laissez l'IA apprendre sur une période saine
À faire
Activez l'IA pendant que la machine fonctionne normalement, sur une durée couvrant un cycle de production représentatif.
À éviter
Démarrer l'apprentissage alors que l'équipement est déjà dégradé : le comportement anormal devient sa référence de « normal ».
Resserrez les alertes progressivement
À faire
Commencez avec un seuil d'alarme élevé et plusieurs anomalies consécutives requises, puis abaissez-les une fois le bruit de fond identifié.
À éviter
Régler un seuil bas dès le premier jour : le flot d'alertes non pertinentes fait perdre confiance dans l'outil avant même qu'il soit calibré.
Qualifiez chaque diagnostic reçu
À faire
Notez systématiquement les diagnostics comme utiles, inutiles ou faux : c'est ce retour qui affine la pertinence des analyses suivantes.
À éviter
Ignorer ou archiver les alertes sans les qualifier : l'IA continue alors de répéter les mêmes erreurs d'appréciation.
Maintenance préventive
Fonctionnalité en test
L'estimation de maintenance préventive est encore en phase de test. Traitez ses échéances comme une aide à la décision à confronter à votre expérience terrain, pas comme une date fiable sur laquelle engager un arrêt de production.Contrairement à la détection d'anomalie, qui juge l'instant présent, la maintenance préventive cherche à estimer quand une intervention deviendra nécessaire. Elle ne repose pas uniquement sur la télémétrie : elle se construit à partir de vos retours, selon le principe de l'humain dans la boucle. Chaque diagnostic que vous qualifiez et chaque panne que vous confirmez affine l'estimation.
Ciblez une pièce d'usure, pas la machine entière
Une machine complète tombe en panne pour trop de raisons différentes pour qu'une échéance globale ait un sens. Une pièce d'usure identifiée — roulement, courroie, filtre, garniture mécanique, plaquette — suit un cycle de dégradation répétable, donc bien plus estimable. Configurez votre suivi autour de cette pièce.
Décrivez le mode de dégradation attendu
Dans la description, précisez quelle pièce s'use, comment elle se dégrade et quels signes précèdent sa fin de vie (montée de vibration, dérive thermique, perte de débit). C'est ce qui permet de relier la télémétrie à un cycle d'usure plutôt qu'à un simple écart ponctuel.
Plusieurs pannes similaires sont nécessaires
Une estimation ne devient pertinente qu'après plusieurs occurrences du même mode de défaillance sur la même pièce : c'est la répétition qui donne une durée de vie moyenne. Une première panne ne constitue pas une référence suffisante, et l'estimation restera large tant que l'historique est court.
Confirmez chaque remplacement effectué
Signalez quand la pièce a réellement été changée et pourquoi : sans ce repère, impossible de mesurer la durée effective entre deux remplacements, et l'estimation continue de se baser sur un cycle incomplet.
Raisonnez en fenêtre, pas en date
Utilisez l'estimation pour planifier une inspection ou commander une pièce à l'avance, pas pour fixer une date d'arrêt au jour près. Elle se resserre au fil des cycles observés.
Éviter l'empoisonnement du modèle
L'IA continue d'apprendre à partir de la télémétrie qu'elle reçoit. Si un comportement anormal lui est présenté comme normal, elle finit par l'intégrer à sa référence et cesse de le signaler : c'est ce qu'on appelle l'empoisonnement du modèle. Le bouclier suspend automatiquement l'apprentissage pendant une alerte, mais les situations ci-dessous demandent votre vigilance.
Qualifier une vraie anomalie en « faux positif »
Le risque
Marquer un diagnostic correct comme faux pour faire taire les alertes apprend à l'IA que le comportement défaillant est acceptable.
La parade
Ne qualifiez de faux que ce qui l'est réellement. Si les alertes sont trop fréquentes mais justes, remontez le seuil d'alarme ou le nombre d'erreurs déclencheur plutôt que de fausser le retour.
Laisser l'IA apprendre pendant une intervention
Le risque
Maintenance, essais, marche forcée ou mode dégradé volontaire produisent une télémétrie atypique qui sera apprise comme un fonctionnement normal.
La parade
Le bouclier se désactive dès qu'un humain intervient sur l'IA : ne le levez qu'une fois la machine revenue en fonctionnement nominal.
Un capteur défaillant qui remonte des valeurs fausses
Le risque
Une sonde en dérive ou une valeur figée alimente l'IA en données erronées qu'elle intègre comme référence, sans jamais lever d'alerte.
La parade
Vérifiez la cohérence des mesures avant l'activation, et méfiez-vous d'une variable qui ne bouge plus du tout : les bornes physiques définies à la configuration aident à repérer ces valeurs aberrantes.
Publier des données de test sur le topic de production
Le risque
Rejouer un jeu de données simulé ou un banc d'essai sur le topic surveillé mélange du fictif à l'historique réel de la machine.
La parade
Réservez un topic distinct à vos tests, et n'associez jamais une IA de production à un topic sur lequel vous rejouez des données.
Ignorer un changement durable du process
Le risque
Après un changement de pièce, un réglage ou une modification de production, l'ancien « normal » ne correspond plus à la réalité et les alertes deviennent incohérentes.
La parade
Réévaluez la configuration après toute modification durable : ajustez la description et les variables, et relancez un RETEX pour repartir sur une référence à jour.
Checklist avant de déployer
L'appareil publie bien sur le topic MQTT choisi, et vous avez vérifié un message réel.
Toutes les variables validées sont présentes dans chaque message, avec les bonnes unités.
Une variable d'état ou de phase du process accompagne les mesures physiques.
Le score de faisabilité RETEX est satisfaisant, et ses recommandations ont été traitées.
Le seuil d'alarme, le nombre d'erreurs déclencheur et la durée de bouclier sont cohérents avec la criticité de la machine.
Une personne est identifiée pour recevoir les alertes et qualifier les diagnostics.
Et maintenant ?
Une IA a besoin d'une télémétrie fiable pour bien fonctionner : assurez-vous d'avoir connecté l'appareil correspondant et, si besoin, mis en place une règle de stockage pour garder l'historique qui a servi à un diagnostic.