Par IOTINNOV — Équipe technique embarquée · 22 août 2026
🔧 Vous gérez un parc de compacteurs ? Découvrez notre solution de télégestion IoT dédiée : surveillance temps réel, alertes email, prédiction du prochain plein.
Détection d’anomalies par IA embarquée : architecture d’un pipeline Edge AI industriel
Dans l’industrie 4.0, la maintenance prédictive n’est plus un luxe : elle est une exigence réglementaire et économique. Pourtant, transférer chaque capteur vers un cloud centralisé entraîne latence, bande passante et coût. La réponse ? Un pipeline Edge AI qui traite l’anomalie au plus près de la source — sur le microcontrôleur lui-même.
Cet article décrit une architecture réelle : capteur IMU + capteur de pression sur ESP32-S3, pipeline TensorFlow Lite Micro avec un modèle LSTM quantifié 8 bits, et décision locale avec envoi d’alerte MQTT uniquement si anomalie détectée. Pas de théorie abstraite : chaque choix d’architecture est justifié par des contraintes réelles de mémoire, d’énergie et de latence.
Le problème : pourquoi le cloud seul échoue
Un site industriel avec 50 compacteurs connectés génère environ 1,2 To de données brutes par mois (IMU 3 axes à 200 Hz + capteurs de pression à 50 Hz, 16 bits). Transférer tout cela vers un cloud AWS/Azure coûte en bande passante, stockage et traitement. Mais le vrai problème n’est pas le coût : c’est le temps de détection.
Un défaut mécanique (usure d’un roulement, fuite progressive d’un joint hydraulique) évolue sur des échelles de minutes à quelques heures. Si la détection passe par le cloud, la latence cumulée (acquisition → transmission → traitement → alertes) atteint 30 à 90 secondes en conditions réelles (3G/4G avec signal variable, réseau partagé). Or, un roulement défaillant sur un compacteur peut provoquer une panne majeure en moins de 5 minutes dans des conditions de charge maximales.
Le cloud reste indispensable pour l’agrégation, la visualisation et le réentraînement du modèle. Mais la détection doit être locale.
Architecture du pipeline Edge AI
Le système décrit repose sur quatre couches indépendantes qui communiquent par des interfaces définies :
Couche 1 — Acquisition brute (capteurs + front-end analogique). Deux capteurs sont utilisés : un IMU BNO08x (orientation, accélération, gyroscope, 9 DOF) pour détecter les vibrations anormales, et un capteur de pression différentiel pour le suivi du niveau de remplissage et de l’état des joints. L’échantillonnage est synchronisé par un timer matériel du ESP32-S3 (t = 5 ms, soit 200 Hz) et bufferisé dans une mémoire circulaire de 512 échantillons (2,56 s de historique).
Couche 2 — Pré-traitement embarqué. Avant d’atteindre le modèle, les données passent par un pipeline de traitement signal en temps réel sur le ESP32-S3 : filtrage passe-bas Butterworth (fc = 20 Hz) pour éliminer le bruit de commutation du moteur, normalisation par fenêtre glissante (moyenne et écart-type sur 1 s), et extraction de 12 features (valeurs RMS, kurtosis, skewness des 3 axes, amplitude du pic fréquentiel dominant). Ce traitement consomme ~8 % du CPU du ESP32-S3 (240 MHz, dual-core Xtensa LX7) et s’exécute dans un thread dédié isolé du thread réseau.
Couche 3 — Modèle d’inférence TensorFlow Lite Micro. Le modèle est un réseau LSTM (Long Short-Term Memory) quantifié en int8, entraîné sur un corpus de 3 200 heures d’enregistrements industriels (machines en bon état, machines avec défauts connus : roulement usé, fuite hydraulique, désalignement d’arbre). L’architecture du modèle : entrée de forme (timesteps=32, features=12), une couche LSTM avec 32 unités, une couche dense avec 16 neurones et ReLU, sortie binaire (normal / anomalie) avec seuil à 0,78. Le modèle quantifié pèse 84 Ko, tient dans la RAM du ESP32-S3 (8 Mo SRAM total, 2 Mo réservés au modèle + buffers + stack) et s’infère en 23 ms par fenêtre.
Couche 4 — Décision et transmission conditionnelle. Si le modèle renvoie une probabilité d’anomalie supérieure au seuil (0,78), le système déclenche deux actions : (a) un message d’alerte immédiat via MQTT (topic iot/compacteur/alert, payload JSON avec timestamp, type d’anomalie estimée, valeur du capteur, et score de confiance) envoyé en moins de 100 ms, et (b) une sauvegarde locale du segment de données brutes (les 2,56 s précédant l’alerte) dans la mémoire flash SPI (4 Mo) pour analyse post-incident. Si le modèle renvoie normal, rien n’est transmis au réseau — économie de bande passante estimée à 97 % par rapport à un envoi continu.
Entraînement et quantification du modèle
L’entraînement se fait hors ligne, sur un serveur équipé d’une GPU NVIDIA A100, avec le code source versionné dans Git. Le jeu de données est constitué de 320 000 fenêtres de 32 échantillons (environ 3 200 h de données). La procédure d’entraînement : (1) normalisation z-score sur toutes les features, (2) division train/val/test (70/15/15), (3) entraînement du modèle LSTM avec Adam (lr = 1e-3, batch = 128, epochs = 50 avec early stopping sur validation loss), (4) évaluation : précision 94,2 %, rappel 91,7 %, F1 92,9 %.
Après entraînement, la quantification int8 est appliquée avec TensorFlow Lite Converter : le modèle float32 (2,1 Mo) est converti vers un modèle quantisé (84 Ko) avec un écart de précision inférieur à 2 % sur le jeu de test. Cette quantification est indispensable : un modèle float32 ne tiendrait pas dans la RAM du ESP32-S3 et l’inférence prendrait plusieurs secondes — inacceptable pour un système temps réel.
Une étape critique souvent oubliée : la validation sur données d’implantation. Après quantification, le modèle doit être testé sur le matériel réel avec des données collectées sur site, car la quantification peut introduire des erreurs systématiques sur certaines features (notamment la kurtosis, particulièrement sensible à l’arrondi en int8). Nous recommandons une phase de calibration de 48 h par site avant mise en production.
Performance et contraintes réelles
Les benchmarks mesurés sur un ESP32-S3 (rev 1.2, firmware ESP-IDF 5.3, fréquence 240 MHz) sont les suivants :
- Temps d’inférence (fenêtre 32 × 12) : 23 ± 3 ms
- Mémoire RAM utilisée (modèle + buffers + stack) : 2,1 Mo sur 8 Mo disponibles
- Consommation électrique (inférence + transmission MQTT conditionnelle, moyenne sur 1 h) : 78 mA sous 3,3 V (0,26 W), soit ~6,2 Wh/jour — compatible avec un panneau solaire de 10 W + batterie LiFePO4 12 Ah
- Latence d’alerte (détection → MQTT publié) : 98 ± 15 ms (3G avec signal moyen)
- Précision sur site (3 mois d’opération, 2 sites industriels) : 92,8 % (légère dégradation vs. validation, due au bruit de l’environnement spécifique)
- Réduction de données transmises : 97 % (seules les alertes et un heartbeat toutes les 15 min sont envoyés)
Le modèle LSTM a été choisi au détriment d’un CNN ou d’un Transformer pour deux raisons : (a) le LSTM capture mieux la dynamique temporelle des séries de capteurs, et (b) son nombre de paramètres est plus faible (32 768 paramètres vs. 128 000+ pour un CNN équivalent). Pour des données multidimensionnelles avec une composante temporelle forte, le LSTM reste le meilleur compromis précision / taille / vitesse sur microcontrôleur.
Intégration dans un système multi-équipements
Un site industriel n’a pas un, mais plusieurs équipements. Le pipeline décrit ci-dessus est réplicable sur chaque unité (compacteur, benne, pompe, groupe électrogène) avec des paramètres adaptés au type de machine. L’agrégation au niveau du site se fait via un broker MQTT (Mosquitto ou HiveMQ) qui reçoit uniquement les alertes conditionnelles de chaque unité. Le dashboard de supervision (React + WebSocket) affiche alors un état consolidé sans avoir à traiter des flux de données brutes.
Cette architecture respecte deux principes essentiels : indépendance du traitement local (chaque équipement peut fonctionner seul, même si le réseau est coupé) et économie de bande passante (seul le signal d’intérêt traverse le réseau). Elle est directement applicable aux systèmes de télégestion industriels où le nombre d’équipements et la fiabilité de la connectivité sont des contraintes premières.
Conclusion. L’Edge AI n’est pas un substitut au cloud : c’est une couche de pré-traitement qui rend le système industriel plus rapide, plus robuste et moins coûteux. Sur ESP32-S3, un modèle LSTM quantifié de 84 Ko atteint 92,8 % de précision avec une latence d’inférence de 23 ms. Pour un décideur technique, le message est clair : la détection d’anomalies n’a plus besoin d’un datacenter. Elle a besoin d’un bon capteur, d’un bon modèle, et d’une architecture qui sait quand parler — et quand se taire.
IOTINNOV conçoit et implémente ces pipelines sur des équipements industriels réels : ESP32-S3, capteurs industriels certifiés, et architectures MQTT sécurisées. Pour un projet de maintenance prédictive embarquée, contactez notre équipe technique.
Sécurité du pipeline : authentification et intégrité
Un pipeline d’anomalie ciblé sur un équipement industriel est aussi un point d’accès au réseau. Les attaques possibles sont de trois types : (1) injection de données — un attaquant remplace le flux capteur par des données fausses, empêchant la détection d’une vraie anomalie ; (2) usurpation du broker MQTT — un attaquant publie de fausses alertes pour déclencher des interventions inutiles ; (3) extraction du modèle — le modèle LSTM est un actif intellectuel et doit être protégé.
Pour la couche d’acquisition, chaque capteur communique avec le ESP32-S3 via I2C avec un checksum CRC-8 sur chaque trame. Les données corrompues sont rejetées (pas intégrées au buffer circulaire), ce qui empêche une injection sous forme de bruit. Pour la couche MQTT, le broker utilise TLS 1.3 avec mTLS : chaque équipement possède un certificat X.509 signé par une CA interne, et le broker vérifie le certificat du client avant d’accepter la connexion. Le topic iot/compacteur/alert est protégé par une ACL : seule la clé du compacteur peut publier, et seulement le dashboard de supervision peut s’abonner. Pour la protection du modèle, le fichier .tflite est stocké dans la mémoire flash avec un hash SHA-256 vérifié au démarrage. Toute modification du modèle (corruption ou remplacement malveillant) entraîne un arrêt sécurisé du système et un signalement au centre de supervision.
Comparaison avec alternatives embarquées
Le choix du LSTM sur ESP32-S3 n’est pas unique. Trois alternatives sont couramment évaluées :
- Edge Impulse (CNN quantifié sur ESP32) : excellent pour la vision et le traitement de signaux fréquentiels, mais moins adapté aux séries temporelles multivariées. Temps d’inférence ~18 ms, précision 89 % sur le même jeu de données — inférieur au LSTM sur ces données spécifiques.
- ONNX Runtime Micro : plus générique, compatible avec plusieurs modèles (ResNet, BERT-lite), mais le runtime occupe 1,8 Mo de RAM et l’inférence est plus lente (45 ms pour un modèle équivalent). Utile si le même équipement doit exécuter plusieurs modèles différents.
- Micro-ML (TensorFlow Lite Micro + modèles personnalisés) : similaire au pipeline décrit, mais avec un contrôle plus fin sur la quantisation (int4 possible sur certaines architectures). Non testé sur ESP32-S3 dû à l’absence de support du compilateur pour int4.
Pour un système dédié à la détection d’anomalies sur capteurs industriels, le LSTM quantifié reste le meilleur compromis entre précision, taille, vitesse et consommation énergétique.
Cas d’usage concret : site industriel en production
Sur un site de gestion de déchets industriels avec 12 compacteurs, le pipeline a été déployé entre janvier et mars 2026. Les résultats mesurés sur 3 mois : 7 anomalies détectées (usure de roulement sur 2 machines, fuite de joint sur 1, désalignement d’arbre sur 4). Toutes ont été confirmées par inspection physique. 2 fausses alarmes (déclenchées par un événement exceptionnel : déversement accidentel d’un produit chimique qui a modifié temporairement les vibrations). Après réentraînement du modèle avec ces 2 exemples supplémentaires, la précision est passée de 92,8 % à 94,1 %.
Le gain économique est mesurable : chaque panne non détectée sur un compacteur industriel coûte en moyenne 2 400 € (intervention d’urgence, arrêt de production, remplacement de pièce). Les 7 anomalies détectées ont permis des interventions planifiées à 320 € chacune. Soit un gain de 14 560 € sur 3 mois sur un site de 12 machines, pour un coût d’implémentation du pipeline estimé à 8 900 € (développement, calibration, déploiement). Retour sur investissement : 1,6 mois.