IIoT : Capteurs Connectés et Monitoring Temps Réel
Module 3 / 5
3.4 Edge Computing vs Cloud : Traiter la Donnée au Bon Endroit
Un capteur vibratoire haute résolution génère jusqu'à 50 Mo de données brutes par heure. Multiplié par 500 capteurs sur une usine, c'est 25 Go/h à envoyer vers le cloud — soit 600 Go par jour. L'enjeu n'est plus seulement de collecter les données, mais de décider intelligemment où les traiter : à la source (edge), dans un datacenter local (fog) ou dans le cloud. Ce chapitre vous donne les clés de décision.
Définition de l'Edge Computing Industriel
L'edge computing désigne le traitement des données au plus près de leur source de génération, avant transmission vers des systèmes centraux. En industrie, l'edge peut être un gateway embarqué, un PC industriel dans l'armoire, ou un serveur rack dans la salle de contrôle locale — mais jamais le datacenter distant.
Principe de Proximité
- Vitesse de la lumière en fibre optique ≈ 200 000 km/s
- Paris → Frankfurt : latence réseau minimale ≈ 5 ms RTT
- Paris → US East Coast : ≈ 80 ms RTT minimum
- Edge local (même bâtiment) : < 1 ms possible
Pour une alarme vibratoire qui doit déclencher un arrêt machine en moins de 10 ms, un aller-retour vers un centre de données cloud situé à Paris serait déjà trop lent la moitié du temps. L'edge élimine cette dépendance réseau.
Exemples d'Applications Edge Industriel
- Alarme vibratoire temps réel : détection de dépassement de seuil ISO 10816 en < 5 ms — déclenchement arrêt d'urgence local
- Calcul FFT local : 25 600 points/s d'accélération → spectre calculé localement → seul le résumé spectral (peaks, RMS par bande) envoyé au cloud
- Agrégation temporelle : 1 000 mesures/minute → moyenne sur 5 min → 200 points/heure en cloud
- Mode dégradé : fonctionnement local garanti en cas de perte de connectivité WAN — la production continue
- Conformité RGPD locale : anonymisation des données avant envoi cloud, données sensibles restent sur site
Cloud Computing en Maintenance Industrielle
Le cloud apporte ce que l'edge ne peut pas offrir : une puissance de calcul élastique, un stockage quasi-illimité et des capacités d'analytics avancées. Il est irremplaçable pour les analyses de tendances à long terme, l'apprentissage automatique et la comparaison entre sites.
- Scalabilité : ajouter 1 000 capteurs sans investissement infrastructure
- Stockage massif : historique sur 10–20 ans pour analyses de tendances
- Machine Learning : entraînement de modèles prédictifs sur des années de données
- Corrélation multi-sites : comparer les signatures vibratoires de 50 usines
- Mises à jour automatiques : nouvelles fonctionnalités sans intervention sur site
- Accès mobile : dashboards maintenanciers accessibles depuis smartphone
- Intégration CMMS : création automatique de bons de travail via API
- Dépendance internet : panne opérateur = perte de visibilité sur la production
- Latence incompressible : 20–200 ms — inutilisable pour les réactions temps réel
- Coûts data : bande passante + stockage + compute — peut devenir élevé à grande échelle
- Souveraineté des données : localisation des serveurs (RGPD, données industrielles sensibles)
- Dépendance au fournisseur : migration difficile d'un fournisseur cloud à un autre dès que l'on s'appuie sur ses services managés propriétaires
- Sécurité périmètre : données industrielles exposées sur le réseau WAN
Architecture Hybride Edge + Cloud : Quelle Donnée Traiter Où ?
La réponse pragmatique est l'architecture hybride : l'edge traite ce qui est urgent et local, le cloud traite ce qui est massif et analytique. La clé est de définir précisément les critères de partage.
| Type de traitement | Edge ou Cloud ? | Raison technique | Exemple concret |
|---|---|---|---|
| Alarme seuil critique | Edge | Latence < 10 ms requise — cloud trop lent | Dépassement ISO 10816 zone D → arrêt machine local |
| Calcul FFT brut | Edge | Volume données brutes trop élevé (25 kHz × 24h) | Gateway calcule le spectre, envoie les peaks au cloud |
| Filtrage et pré-agrégation | Edge | Réduction du volume de données à transmettre (x10 à x1000) | Moyennes 5 min, min/max, détection de changement d'état |
| Inférence modèle ML simple | Edge / Fog | Latence < 100 ms, modèle léger (TF Lite, ONNX) | Classification défaut roulement en temps réel sur gateway |
| Stockage long terme | Cloud | Coût stockage cloud < disque industriel pour multi-années | Historique 10 ans de vibrations pour analyse de tendances |
| Entraînement modèle ML | Cloud | Puissance GPU requise — edge n'a pas les ressources | Entraînement modèle prédictif sur 2 ans de données historiques |
| Corrélation multi-sites | Cloud | Données de plusieurs usines — impossible localement | Comparaison signatures vibratoires entre 10 usines du groupe |
| Dashboards reporting direction | Cloud | Accès distant, multi-utilisateurs, mobile | KPIs MTBF, disponibilité machines, coûts maintenance sur Power BI |
| Intégration CMMS / ERP | Cloud | APIs REST vers systèmes tiers — réseau WAN requis | Création automatique OT dans SAP PM quand alarme détectée |
Edge AI : Exécuter des Modèles ML sur Gateways Industrielles
L'Edge AI combine les avantages de l'intelligence artificielle avec les contraintes temps réel de l'edge. Un modèle d'apprentissage automatique entraîné dans le cloud est déployé et exécuté localement sur une gateway industrielle, sans dépendance réseau pour l'inférence.
Technologies d'Edge AI
Framework Google optimisé pour les appareils embarqués. Quantification des modèles (INT8 vs FLOAT32) réduit la taille d'un facteur 4 et accélère l'inférence. Compatible ARM Cortex-M pour microcontrôleurs.
Open Neural Network Exchange — format d'échange de modèles entre frameworks (PyTorch, TensorFlow, Scikit-learn). ONNX Runtime optimise l'inférence pour CPU/GPU/ARM. Idéal pour les gateways x86 industriels.
Toolkits d'optimisation pour matériel spécialisé. NVIDIA Jetson AGX Orin offre 275 TOPS pour l'inférence temps réel. Intel OpenVINO optimise pour les processeurs Intel Atom/Core et les NPU intégrés.
Workflow Edge AI en Maintenance
Historique vibratoire + événements de maintenance labellisés (défaut roulement, balourd, désalignement) → dataset d'entraînement
Réseau de neurones convolutif (CNN) sur spectres FFT ou LSTM sur séries temporelles. Précision cible > 90 %
Quantification INT8, pruning, export TFLite ou ONNX. Validation des performances du modèle allégé.
Modèle déployé sur gateway industrielle. Inférence locale < 50 ms. Résultats (classe de défaut + confiance) envoyés au cloud pour dashboard.
Choisir une plateforme edge + cloud : les critères qui décident
L'offre se répartit en deux familles aux logiques très différentes : les plateformes IoT des grands fournisseurs cloud, très matures sur le traitement de données et l'apprentissage automatique, et les stacks des éditeurs industriels, nettement plus à l'aise pour parler aux automates et aux protocoles de terrain. Plutôt qu'un palmarès de produits — qui vieillit vite, certaines offres ayant été renommées ou arrêtées en cours de route — voici la grille de critères qui détermine réellement le choix.
| Critère | Plateforme d'un fournisseur cloud | Stack d'un éditeur industriel |
|---|---|---|
| Connectivité terrain | Souvent via une passerelle ou un serveur OPC UA tiers à ajouter | Drivers protocolaires nombreux et intégration directe aux automates de la marque |
| Traitement à l'edge | Runtime conteneurisé, fonctions déportées, inférence de modèles à l'edge | Boîtiers edge propriétaires, catalogue d'applications packagées |
| Analyse et apprentissage | Écosystème très large (entrepôt de données, outils de machine learning managés) | Modèles préembarqués par type d'équipement, moins ouverts |
| Parc multi-marques | Neutre par construction | Optimal sur la marque de l'éditeur, à vérifier au-delà |
| Modèle de coût | À l'usage : volume ingéré, stockage, appels. Prévisible seulement si le volume est maîtrisé à l'edge | Licences et boîtiers, coût d'entrée plus élevé mais plus stable |
| Réversibilité | Dépend de l'usage de services managés propriétaires : plus on les utilise, plus la sortie coûte | Dépend du format d'export des historiques et de la documentation des interfaces |
Résumé du Chapitre
- L'edge computing traite les données à la source avec une latence < 1 ms : alarmes temps réel, calcul FFT, agrégation. Il fonctionne indépendamment d'une connexion internet.
- Le cloud apporte la scalabilité, le stockage long terme et le ML avancé. Il est incontournable pour l'historisation multi-années, les corrélations multi-sites et l'intégration CMMS/ERP.
- 95 % du volume brut reste à l'edge après pré-traitement. Seuls les résumés à valeur ajoutée (peaks spectraux, statistiques, alertes) sont transmis au cloud.
- L'Edge AI déploie des modèles ML entraînés dans le cloud (TensorFlow Lite, ONNX Runtime) sur des gateways industrielles pour une inférence locale sans dépendance réseau.
- L'offre se partage entre plateformes des grands fournisseurs cloud et stacks d'éditeurs industriels. Le choix se joue sur trois points : les protocoles à supporter sur le parc réel, le volume de données qui part effectivement vers le cloud après filtrage, et la réversibilité des historiques.
Quiz Flash — 3 Questions
1. Quelle est la latence typiquement atteignable avec un traitement Edge local dans un même bâtiment industriel ?
2. Quel framework open source est recommandé pour exécuter des modèles ML sur des microcontrôleurs ARM à ressources très limitées ?
3. Quel type de traitement doit OBLIGATOIREMENT rester à l'edge et ne peut PAS être délégué au cloud en maintenance industrielle ?