# Comment détecter les anomalies dans les données de capteurs IoT grâce à l'IA

> Les quatre formes que prend une anomalie de capteur, pics, dérive, silence et pannes corrélées, pourquoi les seuils fixes en manquent trois, et comment construire la détection sur TagoIO avec des lignes de base statistiques, TagoAI, Analysis et Actions.

![Comment détecter les anomalies dans les données de capteurs IoT grâce à l'IA](https://tago.io/og/fr/blog/detect-iot-anomalies-with-ai.png)

Toute équipe qui surveille des capteurs commence de la même manière : fixer une limite et alerter quand une mesure la franchit. Température au-dessus de 8 degrés, vibration au-dessus de 4 mm/s, courant au-dessus de 20 ampères. Pour des limites physiques strictes, c'est exactement la bonne approche.

Mais les pannes qui coûtent vraiment cher ne s'annoncent presque jamais par une seule mesure hors plage. Elles se cachent dans des relevés qui, pris un par un, paraissent normaux. Un compresseur dérive de deux degrés en trois semaines. Un débitmètre se tait à 2 heures du matin et personne ne le remarque avant l'équipe du matin. Une anomalie n'est pas "un grand chiffre". C'est une mesure, ou une absence de mesures, que le schéma normal n'aurait pas prédite.

![Une anomalie est une mesure que le schéma attendu n'avait pas prédite.](https://tago.io/images/blog/detect-iot-anomalies-with-ai/anomaly-detection-band.svg)

## Les quatre formes d'anomalie dans les données de capteurs

En pratique, les anomalies de capteurs se présentent sous quatre formes, et seule la première est visible pour une limite fixe.

**Les pics** sont la forme évidente. Une valeur bondit loin de sa plage récente puis revient. Certains pics sont de vrais événements, beaucoup sont du bruit électrique ou un raté du capteur, et les distinguer demande généralement de regarder plus d'une mesure.

**La dérive** est plus lente et plus coûteuse. Un capteur, ou le procédé derrière lui, s'éloigne progressivement de sa ligne de base tout en restant dans les limites d'alerte du début à la fin. La perte de calibrage, les filtres qui s'encrassent et les fuites de fluide frigorigène se présentent comme une dérive. Quand un seuil fixe finit par déclencher, le problème a des semaines.

**Le silence** est l'anomalie que la plupart des dispositifs de surveillance oublient. Un appareil qui cesse de remonter ne produit aucune donnée à évaluer, donc les règles fondées sur les valeurs ne se déclenchent jamais pour lui. Une donnée manquante est une donnée.

**Les pannes corrélées** traversent les appareils. Une passerelle se bloque et trente capteurs se taisent ensemble, ou toutes les unités d'une même phase électrique décrochent à la même minute. Aucune règle par appareil ne voit cela, car le schéma n'existe qu'à l'échelle du parc.

![Les quatre formes d'anomalie : un pic qui sort de la plage et revient, la dérive qui s'écarte de la ligne de base, le silence sans aucune donnée, et la panne corrélée sur de nombreux appareils au même instant](https://tago.io/images/blog/detect-iot-anomalies-with-ai/anomaly-four-patterns.svg)

Détecter est par ailleurs un travail différent de prévoir. Si ce que vous voulez est une alerte avant qu'une valeur franchisse une limite, et non un signal après qu'elle s'est comportée bizarrement, il s'agit de prévision, et la [différence entre les deux](https://tago.io/blog/anomaly-detection-vs-forecasting-iot) décide de ce qu'il faut construire.

## Seuils et statistiques : quand les méthodes classiques suffisent

Ne sautez pas les outils classiques, car pour une grande part des anomalies ils sont la bonne réponse et non un compromis.

Un seuil statique est peu coûteux, transparent et parfaitement adapté quand la limite est physique ou contractuelle. Un réfrigérateur à vaccins doit rester sous 8 degrés, et personne n'a besoin de machine learning pour l'imposer. Les [Actions](https://docs.tago.io/docs/tagoio/actions/) de TagoIO s'en chargent directement : définissez la condition, définissez la réponse, terminé.

Une ligne de base statistique couvre le niveau suivant. Calculez moyenne et écart type glissants par capteur, signalez les mesures au-delà de trois écarts types, et vous attrapez les pics et les dérives que les limites fixes laissent passer, parce que la bande se déplace avec les données. Segmentez cette ligne de base par heure de la journée ou par mode de fonctionnement et la précision progresse encore : une température normale à 2 heures du matin peut être anormale à 14 heures. Le silence exige une autre règle, un délai : si un appareil n'a pas remonté dans le double de son intervalle habituel, c'est une anomalie indépendamment des valeurs.

Ce sont des statistiques sans éclat, et elles battent un modèle d'IA naïf sur la plupart des flux de capteurs parce qu'elles encodent ce que vous savez réellement du procédé.

Là où les méthodes classiques s'arrêtent, c'est précisément là où le travail devient fastidieux : choisir la bonne fenêtre par variable, traiter la saisonnalité, comparer les comportements sur des centaines d'appareils, corréler plusieurs variables à la fois. Rien de tout cela n'est difficile sur le plan conceptuel. Tout cela représente des heures de code et des arbitrages par parc, et c'est pourquoi la plupart des équipes s'arrêtent aux seuils et vivent avec les angles morts. C'est ce manque que l'IA comble réellement.

## Ce que l'IA apporte, honnêtement

La "détection d'anomalies par IA" se vend comme un modèle qui saurait par magie que quelque chose va mal. Le cadrage plus utile : l'IA supprime le travail ingrat entre savoir à quoi ressemble un bon pipeline de détection et en avoir un qui tourne sur votre propre parc.

Les modèles de machine learning entraînés méritent leur place dans le haut du spectre, pour les schémas multivariés, les fortes saisonnalités et les parcs trop grands pour un réglage capteur par capteur. Avant ce point, un assistant IA capable de voir vos vrais appareils et vos vraies données fait s'effondrer le coût de construction du pipeline classique lui-même, et c'est là que la plupart des équipes obtiennent le retour le plus rapide.

## Explorer votre parc avec TagoAI

TagoAI est l'assistant IA intégré à l'Admin TagoIO, derrière l'icône en étoile. Il est ancré dans la documentation officielle et dans votre propre compte : il peut inspecter vos Devices, Dashboards, Actions et scripts Analysis, et il tient compte du contexte, donc l'ouvrir depuis une page Analysis ou Dashboard signifie qu'il sait déjà ce qu'il regarde.

Ce qui compte pour le travail sur les anomalies, c'est qu'il exécute des opérations d'analyse de données sur l'ensemble de vos appareils. Vous pouvez demander, en langage courant, quels capteurs ont remonté des valeurs à plus de trois écarts types de leur propre moyenne sur deux semaines, quels appareils présentent des trous de plus d'une heure sur la dernière journée, ou si les unités derrière la passerelle 7 se sont tues au même moment. C'est de la détection exploratoire d'anomalies sans code, et c'est ainsi que vous apprenez à quoi ressemble le normal dans votre parc avant d'automatiser quoi que ce soit.

Il se comporte aussi comme doit se comporter un assistant ayant accès au compte. Il démarre en lecture seule, vous élevez ses permissions par session, il ne change jamais rien en silence, et tout ce qu'il fait est consigné dans l'Audit Log. Le [pas à pas détaillé](https://tago.io/blog/use-ai-assistant-query-live-iot-device-data) traite du changement de mode et des habitudes à installer, et les [choix de fournisseur et de confidentialité](https://tago.io/blog/query-iot-data-natural-language-ai) sont exposés séparément.

## Générer la logique de détection en code Analysis

L'exploration trouve des anomalies une fois. La détection en production doit tourner toutes les quelques minutes, sans surveillance. Sur TagoIO, c'est une [Analysis](https://docs.tago.io/docs/tagoio/analysis/) : un script qui s'exécute selon une planification, lit les données récentes, applique votre logique de détection et réécrit un indicateur d'anomalie sous forme de variable.

Plutôt que d'écrire ce script depuis une page blanche, demandez à TagoAI de le générer. Comme il peut inspecter vos appareils et vos formats de données réels, le code qu'il produit s'adresse à vos vrais noms de variables, unités et intervalles de remontée, et non à un exemple générique. Décrivez la logique arrêtée pendant l'exploration : ligne de base glissante par capteur, trois écarts types, segmentée par heure, plus un contrôle de silence au double de l'intervalle de remontée. Relisez le code, ajustez-le, et déployez. Si un script se comporte mal plus tard, TagoAI le débogue avec le même contexte de compte.

Le résultat est une logique de détection que vous pouvez lire, versionner et à laquelle vous pouvez faire confiance, produite en minutes plutôt qu'en jours. L'IA a fait le travail ingrat ; la logique reste la vôtre et reste auditable. Nous avons déroulé ce parcours en direct, de la description en langage courant à une Analysis en fonctionnement, dans le webinaire [AI Meets IoT: A Practical Experience with TagoAI](https://tago.io/videos/ai-meets-iot-a-practical-experience-with-tagoai).

## Alerter avec les Actions

Détection et alerte devraient rester séparées. L'Analysis écrit un indicateur d'anomalie ; une [Action](https://docs.tago.io/docs/tagoio/actions/) TagoIO surveille cette variable et prend en charge la réponse, courriel, SMS, notification push ou webhook vers votre outil de tickets.

Garder les deux séparés permet de durcir la logique de détection sans toucher au routage des alertes, et d'orienter la même variable d'anomalie vers différentes équipes selon la gravité.

## Enquêter sur ce qui est signalé

Une ligne de base vous dit que l'unité 4 a débordé à 3h20. Elle ne dit pas pourquoi, ni si cela fait partie d'un schéma, ni quoi faire. Cette enquête, corréler le débordement avec d'autres variables, vérifier si la même unité a déraillé la semaine passée et rédiger le correctif, est précisément ce qu'un assistant IA fait bien quand il atteint vos données réelles.

Si votre assistant vit en dehors de TagoIO, le [serveur MCP TagoIO](https://docs.tago.io/docs/tagoio/tago-ai/tagoio-mcp-ai-powered-iot-data-integration) lui donne la même portée : récupérer les mesures alentour, vérifier l'historique de l'appareil et proposer une Action plus stricte. La détection reste statistique et auditable tandis que l'IA prend en charge la corrélation fastidieuse et le premier jet de la réponse. La vue d'ensemble est dans [ce que MCP signifie pour l'IoT](https://tago.io/blog/what-is-model-context-protocol-mcp-for-iot).

## Un ordre de construction qui tient en production

Commencez par des Actions sur vos vraies limites strictes, aujourd'hui, sans IA. Utilisez ensuite TagoAI pour explorer le comportement réel de votre parc et repérer les variables qui dérivent, qui décrochent ou qui se taisent. Faites-lui ensuite générer l'Analysis qui encode ce que vous avez appris, et raccordez une Action à l'indicateur d'anomalie. Ajoutez des contrôles à l'échelle du parc pour les pannes corrélées quand la détection par appareil est stable. Ne sortez les modèles de machine learning entraînés que lorsque le pipeline statistique manque de façon démontrable des schémas qui vous importent.

Le piège à éviter est de commencer par la fin. Une IA qui enquête sur des anomalies que vous n'avez pas encore appris à détecter de façon fiable est une supposition assurée sur des fondations bancales. Détection d'abord, explication ensuite.

## À retenir

Les anomalies dans les données de capteurs arrivent sous forme de pics, de dérive, de silence et de pannes corrélées, et trois des quatre sont invisibles pour les seuils fixes. Les statistiques classiques les détectent bien mais coûtent du temps d'ingénierie réel par parc, et c'est ce temps que l'IA supprime : TagoAI pour explorer le comportement sur l'ensemble des appareils, du code Analysis généré pour la détection en production, les Actions pour l'alerte, et un assistant pour enquêter sur ce qui est signalé.

Construisez dans cet ordre et vous obtenez un système précis, débogable et véritablement utile, plutôt qu'une démonstration impressionnante à laquelle personne ne se fie en production. Voyez [Analysis](https://docs.tago.io/docs/tagoio/analysis/) et [Actions](https://docs.tago.io/docs/tagoio/actions/) dans la documentation, ou [commencez gratuitement sur TagoIO](https://admin.tago.io) et signalez votre première anomalie cette semaine.

[llms.txt](https://tago.io/llms.txt)