La plupart des projets IoT s’arrêtent au dashboard. Les capteurs déversent température, vibration, pression et courant dans des graphiques, et l’équipe regarde. Les dashboards font bien leur travail : ils montrent ce qui s’est passé. Le problème, c’est que rien sur un dashboard ne prévient qu’une pompe va lâcher jeudi prochain.
Les modèles d’analytics comblent cet écart. Ils apprennent le comportement normal de chaque équipement à partir de son propre historique, puis évaluent chaque nouvelle mesure par rapport à ce schéma. La sortie n’est pas un graphique de plus à interpréter. C’est une probabilité, une prévision ou un compte à rebours sur lequel on peut agir : commander la pièce, planifier l’équipe, déplacer la charge avant la pointe.
Cet article explique ce qu’est réellement un modèle d’analytics, pourquoi un modèle statistique ajusté surpasse un modèle d’IA généraliste pour évaluer de la télémétrie, quelle famille de modèles répond à quelle question, et ce que dit la recherche publiée sur le retour. Pour les bases de l’analytique descriptive, prédictive et prescriptive, commencez par ce que signifie l’analytique prédictive pour l’IoT.
Comment fonctionne l’analytique IoT, du capteur à la décision
Le pipeline se déroule en quatre étapes : collecter les données des capteurs, entraîner un modèle sur cet historique, exécuter des inférences sur les nouvelles mesures et agir sur le résultat.
La collecte, la plupart des équipes IoT l’ont déjà. Les appareils remontent selon un intervalle, la plateforme stocke les mesures en séries temporelles, et quelques semaines d’historique s’accumulent. Cet historique est la matière première de tout le reste. La quantité nécessaire dépend du modèle et de la saisonnalité que vous cherchez à capter, et cela vaut la peine d’être tranché avant d’entraîner quoi que ce soit.
L’entraînement se produit de temps en temps. Le modèle lit l’historique une fois et en extrait la structure : le cycle journalier, le cycle hebdomadaire, la tendance, la relation entre les variables. L’inférence, elle, tourne en continu et ne coûte presque rien. Chaque nouvelle mesure est évaluée en quelques millisecondes par rapport au schéma appris. Pour la mécanique de l’endroit où tourne l’entraînement et de l’endroit où se fait l’évaluation, voir exécuter du machine learning sur des données IoT.
C’est à la dernière étape que la valeur apparaît. Une prévision qui franchit une limite peut ouvrir un ordre de travail. Un score d’anomalie peut alerter un technicien. Une prévision de demande peut atterrir sur le dashboard que l’équipe d’exploitation utilise déjà, à côté des mesures en direct.
Qu’est-ce qu’un modèle d’analytics en IoT ?
Un modèle d’analytics est une description mathématique de la façon dont une variable évolue dans le temps, ajustée à vos propres données de capteurs. Une fois ajusté, il répond à des questions que les données brutes ne traitent pas : ce que ce capteur affichera la semaine prochaine, si le schéma de vibration du jour est inhabituel, combien de jours restent avant qu’une cuve atteigne sa limite.
Le modèle change aussi ce qu’un KPI peut être. La disponibilité du mois dernier et la température moyenne d’hier sont des chiffres tournés vers l’arrière ; ils décrivent un passé que personne ne peut modifier. Un modèle produit des KPI tournés vers l’avant : probabilité de panne ce mois-ci, jours avant le seuil, indice de santé par équipement, demande prévue avec intervalle de confiance. Ce sont les KPI sur lesquels quelqu’un peut agir, parce que l’événement qu’ils décrivent n’a pas encore eu lieu.
Les intervalles de confiance comptent davantage qu’il n’y paraît. Une prévision de “82 kWh demain, entre 76 et 88 avec 95% de confiance” permet de planifier avec un risque connu plutôt qu’à l’intuition. C’est toute la différence entre regarder un graphique et prendre une décision que vous pouvez défendre.
Les dashboards restent en scène. Il ne s’agit pas de les remplacer mais de changer ce qu’ils affichent : les sorties du modèle arrivent comme de nouvelles variables, de sorte que l’écran qui montre les dernières 24 heures peut aussi montrer les 7 prochains jours.
| Dashboards | Modèles d’analytics avec de bons KPI | |
|---|---|---|
| Question traitée | “Que s’est-il passé ?” | “Qu’est-ce qui va probablement arriver, et avec quelle certitude ?” |
| Horizon temporel | Du passé au présent | Du présent au futur |
| Sortie | Des graphiques que quelqu’un interprète | Prévisions, probabilités, scores d’anomalie |
| Comment l’action démarre | Quelqu’un remarque, puis réagit | Alertes et ordres de travail partent avant la panne |
| Aide à la décision | Contexte et piste d’audit | Délai d’anticipation et confiance quantifiée |
Pourquoi des modèles statistiques plutôt que de l’IA pour analyser des données de capteurs ?
Parce qu’évaluer des données de capteurs est un problème numérique, et qu’un modèle entraîné le résout pour une fraction infime du coût d’une IA généraliste. Les grands modèles de langage sont conçus pour le texte et le raisonnement. En pointer un sur de la télémétrie brute, c’est payer des prix de GPU, à chaque question, pour une arithmétique qu’un modèle ajusté exécute sur un CPU en quelques millisecondes.
La différence structurelle porte sur l’endroit où la lecture a lieu. Un modèle statistique lit votre historique une seule fois, pendant l’entraînement. Ensuite, chaque inférence ne touche que les points les plus récents. Un assistant IA à qui l’on demande “ce compresseur est-il en bonne santé ?” n’a aucun modèle ajusté sur lequel s’appuyer : il devrait retraiter les données concernées à chaque fois. Personne ne veut d’un LLM qui relit des milliards de points de données parce que quelqu’un a reposé la même question.
Le déterminisme est l’autre écart. Un modèle ajusté donne la même réponse pour la même entrée, avec un intervalle de confiance que vous pouvez auditer et expliquer à une responsable d’exploitation ou à un régulateur. La sortie d’une IA générative peut varier d’une exécution à l’autre, ce qui cadre mal avec une alerte qui réveille quelqu’un à 3 heures du matin.
| Modèles d’analytics entraînés | IA généraliste (LLM) | |
|---|---|---|
| Conçus pour | Séries temporelles numériques | Langage et raisonnement général |
| Matériel par inférence | CPU | Clusters de GPU |
| Coût par inférence | Fractions de centime | Ordres de grandeur au-dessus |
| Latence | Millisecondes | Secondes |
| Traitement des données | Entraîne une fois sur l’historique, n’évalue que les points nouveaux | Retraite les données à chaque question |
| Reproductibilité | Déterministe, même entrée, même sortie | La sortie peut varier d’une exécution à l’autre |
| Explicabilité | Tendance, saisonnalité et seuils auditables | Difficile à auditer |
| Passage à une flotte | Des milliers d’appareils évalués en continu à coût stable | Le coût croît avec chaque token traité |
L’IA garde sa place. Les assistants servent à construire des solutions, écrire des scripts et expliquer des résultats, et vous pouvez interroger vos données IoT en langage naturel avec l’un d’eux. L’évaluation continue et à gros volume de données de capteurs est un travail de modèles, comme vous n’engageriez pas une consultante pour additionner un tableur toutes les heures.
Quel modèle pour quel problème ?
Partez de la question à traiter, et choisissez la famille ensuite.
Prévision répond à “comment cette variable va-t-elle évoluer ?” Le lissage exponentiel (ETS) et Holt-Winters prolongent une série en pondérant l’historique récent et ses cycles saisonniers. Ce sont les chevaux de bataille du domaine, traités en profondeur dans Forecasting: Principles and Practice de Hyndman et Athanasopoulos, de la Monash University. La décomposition MSTL gère les séries à plusieurs schémas saisonniers simultanés, comme la consommation d’énergie avec un cycle journalier et un cycle hebdomadaire. Pour comparer ARIMA, Prophet et les options neuronales sur une même série, voir quel modèle de prévision convient à votre série temporelle IoT.
Détection d’anomalies répond à “est-ce normal ?” Le clustering K-Means, classique du cursus de machine learning de Stanford, regroupe les états de fonctionnement d’un équipement, de sorte que les mesures nouvelles qui ne tombent dans aucun groupe ressortent. DBSCAN trouve des groupes par densité, ce qui aide à repérer le seul appareil qui se comporte différemment de ses pairs. Isolation Forest isole vite les valeurs aberrantes, même sur de gros jeux de données. Détection et prévision règlent des problèmes différents, et se tromper de camp est une erreur courante au départ.
Détection de dérive répond à “est-ce que cela se dégrade lentement ?” Les cartes de contrôle EWMA, documentées dans le e-Handbook of Statistical Methods du NIST/SEMATECH, pondèrent les mesures récentes par rapport à une base de référence et signalent des déplacements faibles et persistants bien avant qu’ils ne crèvent un seuil fixe. Filtres qui s’encrassent, roulements qui s’usent et calibrage qui glisse ont exactement cette allure.
Estimation et délai avant seuil répondent à “qu’est-ce qui pilote ce résultat, et combien de temps me reste-t-il ?” La régression multivariée estime une cible à partir de ses facteurs, utile quand ce qui vous intéresse n’a pas de capteur dédié. Associer une prévision à un balayage de seuil transforme “la cuve est à 63%” en “la cuve atteint sa limite dans environ 9 jours”, ce qui est un planning de maintenance, pas un graphique.
La maintenance prédictive est-elle vraiment rentable ?
Les chiffres publiés disent oui. Le Operations & Maintenance Best Practices Guide du département de l’Énergie des États-Unis estime qu’un programme de maintenance prédictive qui fonctionne économise de 8% à 12% par rapport à un programme préventif, et de 30% à 40% pour les sites qui viennent d’une maintenance réactive, du type marche jusqu’à la panne. Le Pacific Northwest National Laboratory tient la même ligne : la planification par état bat à la fois le calendrier et la casse. Une revue relue par des pairs sur la maintenance prédictive dans l’industrie 4.0 arrive à la même conclusion sur des dizaines d’études. La technique marche quand le pipeline de données qui la porte marche.
Les chiffres de Deloitte sur la disponibilité et les coûts de maintenance sont détaillés dans simplifier la maintenance prédictive et ne sont pas répétés ici.
Une réserve honnête : les gains dépendent du passage à l’acte. Une prévision que personne ne transforme en ordre de travail n’est qu’un graphique de plus. L’étape d’action du pipeline n’est pas facultative.
Démarrer sans équipe de data science
Tout ce qui précède peut être construit à la main avec des bibliothèques open source, un endroit pour les exécuter et quelqu’un pour maintenir le pipeline. C’est un vrai projet : extraction des données, calendriers de réentraînement, stockage des modèles et raccordement des sorties aux alertes.
TagoIO Analytics intègre ce pipeline dans la plateforme vers laquelle vos appareils remontent déjà. Vous choisissez une variable, un assistant entraîne le modèle sur les données qui vous appartiennent déjà, et les prévisions reviennent sous forme de variables ordinaires. Elles atterrissent sur les dashboards, déclenchent des Actions et alimentent des alertes sans une ligne de code de ML.
Les étapes lourdes, entraînement et inférence, tournent sur le service sight.tago.io, tandis que vos données, dashboards et Actions restent dans votre compte TagoIO. Le pipeline du début de cet article s’y transpose directement.
La liste des modèles correspond aux familles ci-dessus : Seasonal Forecasting (décomposition MSTL avec lissage exponentiel ETS), Demand Prediction (Prophet avec prévision des facteurs), Estimation from Drivers (régression OLS multivariée), Quick Health Check (Isolation Forest), Continuous Monitoring (clustering K-Means), Peer Comparison (clustering par densité DBSCAN), Slow Drift Detection (carte de contrôle EWMA sur une base saisonnière) et Time to Threshold (prévision Holt-Winters ou AutoETS avec balayage de seuil).
Si vos capteurs envoient déjà des données, l’étape d’entraînement part d’un historique qui vous appartient déjà. Voyez les modèles sur tago.io/analytics, ou réservez une démo pour en parcourir un sur vos propres mesures.
Sources
- Hyndman, R.J. et Athanasopoulos, G. (Monash University), Forecasting: Principles and Practice, 3e éd.
- Taylor, S.J. et Letham, B., Forecasting at Scale (Prophet), PeerJ Preprints
- Liu, F.T., Ting, K.M. et Zhou, Z.-H., Isolation Forest, IEEE ICDM 2008
- Ng, A. (Stanford University), CS229 Lecture Notes: The k-means clustering algorithm
- NIST/SEMATECH, e-Handbook of Statistical Methods: EWMA Control Charts
- Département de l’Énergie des États-Unis, Operations & Maintenance Best Practices Guide, Release 3.0
- Pacific Northwest National Laboratory, O&M Best Practices: Maintenance Approaches
- Predictive maintenance in Industry 4.0: a survey of planning models and machine learning techniques, revue relue par des pairs
