Edge AI vs IA cloud pour l'IoT : latence, confidentialité, coût et architecture hybride

Edge AI vs IA cloud : c'est l'une des premières décisions d'architecture de tout projet de machine learning IoT, et une erreur à ce stade se traduit plus tard par des alertes lentes, des factures de bande passante énormes ou des revues de confidentialité qui bloquent le déploiement. Cette comparaison explique où chaque approche l'emporte en matière de latence, de confidentialité, de coût et de taille de modèle, vous donne une checklist pour décider et présente une architecture hybride dans laquelle les résultats edge transitent via MQTT vers des modèles cloud.

Les deux approches en bref

L'edge AI exécute l'inférence sur l'appareil ou sur une passerelle à côté. Les données des capteurs restent locales, et l'appareil publie des conclusions : un label de classe, un score d'anomalie, un comptage. Pour une introduction, commencez par ce qu'est l'edge AI.

L'IA cloud envoie les données vers des serveurs où les modèles tournent avec une puissance de calcul pratiquement illimitée. L'appareil est une source de données ; l'intelligence est centralisée.

En pratique, très peu de systèmes en production relèvent purement de l'une ou de l'autre. La question utile est de savoir quelles décisions doivent être prises où.

Edge AI vs IA cloud : comparaison côte à côte

Aucune de ces lignes n'est décisive à elle seule. Un arrêt de sécurité qui doit réagir en quelques dizaines de millisecondes relève de la périphérie quel qu'en soit le coût. Une prévision à l'échelle du parc qui nécessite l'historique de chaque site relève du cloud quelle que soit la latence.

Latence et fiabilité

L'inférence en périphérie est limitée par la puissance de calcul de l'appareil, et cette limite est prévisible. L'inférence cloud dépend du réseau, qui ne l'est pas. Les liaisons cellulaires, le Wi-Fi d'usine saturé et les fenêtres de maintenance ajoutent tous du délai ou des coupures. Si l'action qui suit une prédiction est physique, comme éjecter une pièce, arrêter un convoyeur ou ouvrir une vanne, gardez la décision en périphérie et considérez le cloud comme un destinataire du résultat.

Confidentialité et gouvernance des données

Les caméras et les microphones sont les cas les plus évidents. Envoyer la vidéo de personnes vers un cloud tiers soulève des questions de consentement, de conservation et de localisation des données. Exécuter la détection localement et publier « 2 personnes dans la zone B » évite la plupart de ces questions. La même logique s'applique aux données de production qu'un industriel juge confidentielles : un taux de défauts est moins sensible que des images d'un nouveau produit.

Coût : où va l'argent

L'edge AI concentre le coût en amont, sur le matériel et l'ingénierie : accélérateurs, boîtiers durcis et travail de réduction des modèles. L'IA cloud transforme le coût en dépense courante qui croît avec le volume de données. Pour des signaux continus à haute fréquence comme la vidéo, tout diffuser vers le cloud est généralement l'option la plus chère. Pour des données clairsemées, comme une mesure toutes les quelques minutes, l'inférence cloud peut être moins coûteuse car vous évitez un matériel plus intelligent sur chaque site. Estimez les deux avec vos propres débits de données plutôt que de vous fier à des règles empiriques.

Taille et capacités des modèles

Les microcontrôleurs exécutent des modèles qui se mesurent en kilo-octets ; les modules GPU edge exécutent des modèles de détection à plusieurs millions de paramètres ; le cloud exécute tout ce que vous pouvez vous offrir, y compris des grands modèles de langage. Si la tâche exige une large connaissance du monde, un long contexte ou un raisonnement sur de nombreuses sources, elle relève du cloud. S'il s'agit d'une tâche de perception ciblée, comme « ce son est-il anormal ? », un petit modèle edge est souvent tout aussi précis. Ce qu'est le TinyML montre jusqu'où l'on peut descendre.

Checklist de décision

Répondez à ces questions pour chaque prédiction de votre système :

1. Une action dépend-elle de la prédiction en moins d'une seconde ? Si oui, edge.
2. Le système doit-il continuer à fonctionner sans Internet ? Si oui, edge.
3. Les données brutes sont-elles sensibles ou réglementées ? Si oui, privilégiez l'edge et publiez des résultats dérivés.
4. Le débit de données brutes est-il élevé (vidéo, audio, capteurs en kHz) ? Si oui, privilégiez l'edge.
5. La prédiction nécessite-t-elle des données de nombreux appareils ou un long historique ? Si oui, cloud.
6. Le modèle a-t-il besoin de plus de mémoire que n'en offre votre classe d'appareils ? Si oui, cloud, ou un appareil edge de niveau passerelle.
7. Le modèle changera-t-il chaque semaine ? Le cloud facilite l'itération ; l'edge exige un pipeline de mise à jour solide.

La plupart des projets aboutissent à un partage : la perception en périphérie, le contexte et la planification dans le cloud.

L'architecture hybride : les résultats edge transitent via MQTT vers des modèles cloud

L'architecture hybride comporte trois couches :

1. Les appareils edge exécutent des modèles de perception et publient des résultats compacts sur des topics comme site/area/line/device/inference.
2. Un broker diffuse ces résultats. Les appareils n'ont jamais besoin de savoir qui les consomme.
3. Les consommateurs cloud s'abonnent aux résultats de nombreux appareils et exécutent des modèles de second niveau : détection d'anomalies à l'échelle du parc, prévision, corrélation des causes racines ou un LLM qui résume les événements pour les opérateurs.

Le cloud peut aussi renvoyer des décisions : un nouveau seuil, une demande d'échantillon brut ou un avis de mise à jour du modèle publié sur un topic de commande auquel l'appareil est abonné.

MQTT convient à ce schéma car les résultats edge sont de petits événements fréquents avec de nombreux consommateurs. Un broker MQTT cloud s'insère naturellement entre les couches : les appareils edge se connectent en sortie via TLS et aucun port entrant n'est nécessaire sur les réseaux des sites.

Exemple : un agrégateur côté cloud

Ce worker Python s'abonne aux résultats d'inférence de tous les appareils sous un préfixe et applique une règle simple de second niveau sur l'ensemble du parc : si plusieurs appareils d'une même ligne signalent des anomalies dans une courte fenêtre, il publie une alerte au niveau de la ligne. Ce type de corrélation est hors de portée d'un appareil edge isolé.

import json
import time
import uuid
from collections import defaultdict, deque

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/3f9c1a7e"          # use your own unique prefix
SUB = f"{PREFIX}/+/+/+/inference"           # site/area/device/inference
WINDOW_S, MIN_DEVICES = 120, 2

recent = defaultdict(deque)                 # line key -> deque of (ts, device)


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(SUB, qos=1)


def on_message(client, userdata, msg):
    _, _, _, site, area, device, _ = msg.topic.split("/")
    result = json.loads(msg.payload)
    if result.get("label") == "normal":
        return
    key = f"{site}/{area}"
    now = time.time()
    q = recent[key]
    q.append((now, device))
    while q and now - q[0][0] > WINDOW_S:
        q.popleft()
    devices = {d for _, d in q}
    if len(devices) >= MIN_DEVICES:
        alert = {"scope": key, "devices": sorted(devices), "window_s": WINDOW_S,
                 "reason": "correlated anomalies"}
        client.publish(f"{PREFIX}/{site}/{area}/alerts", json.dumps(alert), qos=1)
        print("ALERT", alert)
        q.clear()


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"cloud-agg-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Simulez deux appareils edge signalant des anomalies sur le serveur MQTT public gratuit, réservé aux tests :

P=connectmq/demo/3f9c1a7e
mosquitto_pub -h broker.connectmq.com -p 1883 -i dev-a-81 -q 1 \
  -t "$P/site1/pumps/pump-01/inference" -m '{"label":"bearing_wear","score":0.81}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i dev-b-82 -q 1 \
  -t "$P/site1/pumps/pump-02/inference" -m '{"label":"cavitation","score":0.77}'

L'agrégateur affiche et publie une alerte de ligne. Lorsqu'un seul worker ne suffit plus, exécutez-en plusieurs copies avec un abonnement partagé MQTT 5 comme $share/agg/connectmq/... afin que le broker répartisse les messages entre elles ; chez ConnectMQ, les abonnements partagés sont disponibles à partir de l'offre Serverless (Paid). Notez qu'un corrélateur avec état comme celui-ci a besoin que les messages d'une même ligne atteignent le même worker : partitionnez donc par topic plutôt que de partager aveuglément.

Erreurs courantes en architecture hybride

1. Diffuser les données brutes « au cas où ». N'envoyez des échantillons bruts que sur demande ou en cas d'anomalie, via un topic séparé.
2. Laisser le cloud prendre des décisions critiques dans le temps. Gardez le réflexe en périphérie et utilisez le cloud pour la stratégie.
3. Aucun champ de version. Chaque résultat doit indiquer la version du modèle qui l'a produit, afin que les modèles cloud puissent tenir compte des changements.
4. Ignorer les limites de taille des messages. Les résultats doivent rester bien en dessous de la limite de votre broker ; sur le serveur MQTT public gratuit, cette limite est de 64 Ko.
5. Des topics de commande non authentifiés. Tout ce qui peut modifier le comportement d'un appareil doit passer par un broker privé avec identifiants et TLS.

Pour en savoir plus sur l'intégration de ces couches dans un système AIoT complet, lisez le guide IA et IoT, et au moment de choisir le matériel, comparez les cartes dans la comparaison du matériel edge AI.

Reliez l'edge et le cloud avec ConnectMQ

L'architecture hybride ne fonctionne que si le lien entre la périphérie et le cloud est fiable et sécurisé. ConnectMQ fournit un broker MQTT managé avec MQTT 5, TLS sur le port 8883 et des abonnements partagés sur les offres payantes, pour que vous puissiez vous concentrer sur les modèles plutôt que sur l'exploitation du broker. Créez un broker avec l'offre gratuite Serverless sur app.connectmq.com, sans carte bancaire.

Questions fréquentes

L'edge AI est-elle meilleure que l'IA cloud ?

Aucune n'est meilleure de manière générale. L'edge AI l'emporte sur la latence, le fonctionnement hors ligne et la confidentialité ; l'IA cloud sur la taille des modèles, le contexte multi-appareils et la facilité d'itération. La plupart des systèmes IoT utilisent les deux.

Puis-je commencer dans le cloud et passer à l'edge plus tard ?

Oui, et c'est un parcours courant. Concevez d'abord le format des messages de résultat, de sorte que lorsque l'inférence passe sur l'appareil, les consommateurs cloud continuent de recevoir les mêmes messages sur les mêmes topics.

Que doit envoyer un appareil edge vers le cloud ?

Des résultats d'inférence avec horodatage, confiance et version du modèle, un heartbeat périodique, et des échantillons bruts uniquement sur demande ou lorsqu'une anomalie est détectée.

L'IA hybride edge-cloud a-t-elle besoin d'un broker de messages ?

Pas strictement, mais un broker découple les appareils des consommateurs, gère la connectivité intermittente grâce à la QoS et aux sessions, et vous permet d'ajouter de nouveaux consommateurs cloud sans toucher aux appareils.