Edge computing vs cloud computing dans l'IIoT : il ne s'agit pas de choisir l'un ou l'autre, la vraie question est de savoir quelle logique s'exécute à côté de la machine et laquelle s'exécute de manière centralisée. Cet article compare les deux approches en matière de latence, de bande passante, de résilience, de sécurité et de coût, puis détaille une architecture hybride dans laquelle un nœud edge prend les décisions rapides en local et publie des résultats synthétisés vers un broker MQTT dans le cloud.
Définitions dans un contexte industriel
L'edge computing consiste à traiter les données dans l'atelier ou à proximité : dans un automate, un PC industriel, une passerelle ou un petit serveur sur site. Les données sont exploitées avant de quitter le site.
Le cloud computing consiste à traiter les données de manière centralisée dans un cloud public ou privé : stockage, analyse, tableaux de bord, entraînement de modèles de machine learning, jumeaux numériques des installations et reporting multi-sites.
Entre les deux se trouve la couche de messagerie. Dans la plupart des systèmes IIoT modernes, c'est MQTT : les équipements edge publient, les services cloud s'abonnent, et le broker les découple afin que chaque côté puisse évoluer sans casser l'autre.
Edge computing vs cloud computing dans l'IIoT : comparaison
| Critère | Edge computing | Cloud computing |
|---|---|---|
| Latence | Quelques millisecondes, sans aller-retour WAN | Dépend du chemin internet ; de dizaines à centaines de millisecondes, parfois plus |
| Bande passante | Les données brutes restent en local ; seuls les résultats sont envoyés | Chaque valeur doit traverser le WAN |
| Résilience | Continue de fonctionner pendant les coupures internet | Indisponible quand la liaison est coupée, sauf si l'edge met en tampon |
| Capacité de calcul | Limitée par le matériel local | Élastique, pratiquement illimitée |
| Vision multi-sites | Un site à la fois | Tous les sites, tout l'historique, au même endroit |
| Maintenance | Matériel réparti sur plusieurs sites, mis à jour un par un | Mises à jour et exploitation centralisées |
| Exposition sécurité | Les données restent dans l'usine | Les données quittent l'usine : le transport et le contrôle d'accès deviennent essentiels |
| Profil de coût | Matériel initial et support sur site | Coûts récurrents à l'usage, qui augmentent avec le volume de données |
Aucune colonne ne l'emporte nettement. Chaque ligne désigne une catégorie de traitements qui a sa place d'un côté ou de l'autre.
Ce qui a sa place en périphérie
- Boucles de sécurité et de régulation. Tout ce qui doit réagir en quelques millisecondes ou ne doit jamais dépendre d'internet reste dans les automates et les systèmes de sécurité. Le cloud ne doit jamais faire partie d'une boucle de régulation.
- Traitement du signal haute fréquence. Les vibrations échantillonnées à plusieurs kilohertz, les formes d'onde de qualité réseau et les compteurs rapides produisent bien plus de données que vous ne voulez en expédier. Calculez des indicateurs (RMS, crête, bandes de fréquence) en local et publiez-les.
- Alarmes locales. Une alarme de débordement de cuve doit retentir même quand le WAN est coupé.
- Réduction des données. Les bandes mortes et le report by exception réduisent le trafic à la source.
- Mise en tampon. Les nœuds edge mettent les données en file d'attente pendant les coupures et les rejouent ensuite, comme décrit dans store-and-forward pour MQTT.
- Traduction de protocoles. Convertir Modbus, OPC UA ou EtherNet/IP en MQTT est par nature une opération locale ; voir passerelle edge IIoT.
Ce qui a sa place dans le cloud
- Comparaison multi-sites et reporting TRS. Comparer des lignes situées dans différentes usines exige d'avoir les données au même endroit.
- Historique long terme. Des années de séries temporelles sont moins chères et plus faciles à gérer de manière centralisée.
- Entraînement de modèles. Les modèles de machine learning sont entraînés sur de grands jeux de données historiques avec une puissance de calcul élastique, puis le modèle entraîné peut être redéployé en périphérie.
- Intégration métier. L'ERP, la GMAO et les systèmes qualité vivent dans l'IT, pas dans l'atelier.
- Tableaux de bord à distance et accès mobile. Les ingénieurs et les responsables hors de l'usine ont besoin d'un point d'accès central.
Le modèle hybride
La réponse pragmatique pour la plupart des usines est hybride : calculer en périphérie, coordonner et analyser dans le cloud, et relier les deux avec MQTT.
Machine --> Edge node --> Cloud MQTT broker --> Cloud services
(100 Hz) - samples raw signal (TLS 8883) - dashboards
- local alarm (no WAN needed) - historian
- 1-minute aggregates - analytics
- publishes events + summaries
L'edge publie deux types de messages : des événements (alarme déclenchée, alarme levée) au moment où ils se produisent, et des synthèses (min, max, moyenne par minute) selon un calendrier fixe. Le cloud ne voit jamais le flux brut à 100 Hz, sauf si un ingénieur le demande explicitement.
Un nœud edge hybride fonctionnel en Python
Ce script simule un capteur échantillonné à 20 Hz. Il évalue une alarme en local à chaque échantillon, publie immédiatement les changements d'état de l'alarme et publie un agrégat par minute. Il utilise paho-mqtt 2.x et le serveur MQTT public gratuit broker.connectmq.com, réservé aux tests ; modifiez l'hôte, le port et les identifiants pour la production.
import json
import math
import random
import statistics
import time
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PORT = 1883
CLIENT_ID = "edge-node-3c9d"
BASE = "connectmq/demo/edge-3c9d/plant1/line1/pump1"
SAMPLE_HZ = 20
WINDOW_S = 60
ALARM_ON = 78.0 # degrés C
ALARM_OFF = 74.0 # hystérésis
def read_sensor(t):
"""Température de roulement simulée avec dérive lente et bruit."""
return 70 + 6 * math.sin(t / 90) + random.gauss(0, 0.4)
def now_iso():
return datetime.now(timezone.utc).isoformat(timespec="milliseconds")
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.publish(f"{BASE}/status", "online", qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
protocol=mqtt.MQTTv5)
client.on_connect = on_connect
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
# Production : client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"); client.tls_set(); PORT = 8883
client.connect(BROKER, PORT, keepalive=60)
client.loop_start()
window = []
alarm = False
window_start = time.monotonic()
t0 = time.monotonic()
while True:
value = read_sensor(time.monotonic() - t0)
window.append(value)
# Logique edge : évaluée à chaque échantillon, sans besoin de réseau
if not alarm and value > ALARM_ON:
alarm = True
# ici, vous piloteriez aussi une sortie locale, par ex. une colonne lumineuse
client.publish(f"{BASE}/event", json.dumps(
{"ts": now_iso(), "type": "HIGH_TEMP", "state": "RAISED", "value": round(value, 2)}),
qos=1)
elif alarm and value < ALARM_OFF:
alarm = False
client.publish(f"{BASE}/event", json.dumps(
{"ts": now_iso(), "type": "HIGH_TEMP", "state": "CLEARED", "value": round(value, 2)}),
qos=1)
# Synthèse cloud : un message par fenêtre au lieu de SAMPLE_HZ * WINDOW_S
if time.monotonic() - window_start >= WINDOW_S:
summary = {
"ts": now_iso(),
"window_s": WINDOW_S,
"samples": len(window),
"min": round(min(window), 2),
"max": round(max(window), 2),
"mean": round(statistics.fmean(window), 2),
"alarm": alarm,
}
client.publish(f"{BASE}/summary", json.dumps(summary), qos=1, retain=True)
print("summary", summary)
window.clear()
window_start = time.monotonic()
time.sleep(1 / SAMPLE_HZ)
Abonnez-vous depuis un autre terminal pour constater l'écart de volume entre ce que voit l'edge et ce que reçoit le cloud :
mosquitto_sub -h broker.connectmq.com -p 1883 -i edge-3c9d-viewer -t "connectmq/demo/edge-3c9d/#" -v
Le nœud traite 1 200 échantillons par minute mais n'envoie qu'une synthèse plus un événement occasionnel. La décision d'alarme est prise en local et immédiatement ; si le broker est injoignable, l'alarme locale fonctionne toujours. Pour un déploiement réel, ajoutez une file d'attente sur disque afin que les événements déclenchés pendant une coupure ne soient pas perdus.
Les coûts, sans effet de mode
Le matériel edge coûte de l'argent au départ et nécessite quelqu'un pour l'entretenir sur site. Les services cloud coûtent de l'argent en continu, et la facture augmente généralement avec le volume de données. La réduction des données en périphérie est donc le principal levier sur le coût du cloud : si vous n'envoyez que le nécessaire, vous pouvez utiliser des offres plus modestes, des bases de données plus petites et moins de bande passante, en particulier sur des liaisons facturées au volume comme MQTT sur réseau cellulaire. La contrepartie est qu'une donnée jamais envoyée ne pourra pas être analysée plus tard : conservez donc les données brutes en local pendant un certain temps si les ingénieurs risquent d'en avoir besoin.
La sécurité dans une architecture hybride
La connexion entre l'edge et le cloud doit toujours être sortante, chiffrée et authentifiée. Le nœud edge ouvre une session TLS vers le broker sur le port 8883 avec des identifiants émis spécifiquement pour ce nœud. Aucun port entrant vers le réseau de l'usine n'est nécessaire, ce qui garde le réseau OT fermé. Les consommateurs cloud s'abonnent avec leurs propres identifiants. Le guide de l'IoT industriel avec MQTT replace ce modèle dans l'architecture globale de l'usine.
Choisir le côté cloud
Dans le modèle hybride, le broker cloud est le hub dont dépendent tous les sites et tous les consommateurs. L'exploiter vous-même implique de gérer TLS, l'authentification et le dimensionnement d'un système critique. Un broker MQTT managé vous décharge de ce travail, et ConnectMQ propose une gamme allant des offres Serverless partagées pour les projets pilotes aux offres Dedicated et BYOC (bring-your-own-cloud) pour les déploiements plus importants. Les intégrations comme les historiens ou les bases de données se connectent comme de simples abonnés MQTT (Telegraf, Node-RED ou vos propres services), ce qui garde l'architecture simple et portable. Si les brokers sont nouveaux pour vous, commencez par le rôle d'un broker MQTT.
Connectez votre edge à ConnectMQ
Donnez à vos nœuds edge un hub cloud sécurisé en quelques minutes. ConnectMQ fournit MQTT 3.1.1 et 5.0 sur TLS, des identifiants émis, un explorateur de topics en direct et des règles d'alerte à seuil pour surveiller les synthèses. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et pointez-y le script ci-dessus.
Questions fréquentes
L'edge computing remplace-t-il le cloud computing dans l'IIoT ?
Non. Ils résolvent des problèmes différents. L'edge gère les traitements rapides, locaux et gourmands en bande passante ; le cloud gère l'analyse multi-sites, l'historique et l'intégration. La plupart des systèmes utilisent les deux.
Quelle latence attendre d'un traitement dans le cloud ?
Elle dépend du chemin réseau et de la région du fournisseur, généralement de quelques dizaines à quelques centaines de millisecondes avec des pics occasionnels. C'est suffisant pour les tableaux de bord et l'analyse, mais pas pour des boucles de régulation.
L'edge computing améliore-t-il la sécurité ?
Il peut l'améliorer, car les données brutes restent dans l'usine et seules les synthèses en sortent. Les nœuds edge eux-mêmes doivent néanmoins être mis à jour, durcis et dotés d'identifiants sécurisés.
En quoi MQTT aide-t-il une architecture hybride ?
MQTT découple producteurs et consommateurs. Les nœuds edge publient sur des topics sans savoir qui les consomme : on peut donc ajouter ou modifier des services cloud sans toucher à l'usine.
