IA et IoT : le guide complet de l'AIoT, des modèles edge aux agents LLM

L'IA et l'IoT se complètent : les objets connectés produisent des flux continus de données sur le monde physique, et l'IA transforme ces flux en détections, en prévisions et en décisions. Ce guide explique où les modèles d'IA doivent s'exécuter, comment données et commandes circulent entre équipements et modèles, et comment construire avec MQTT un détecteur d'anomalies en temps réel et un chemin de commande sûr pour les agents d'IA.

Ce que signifie l'AIoT

L'AIoT, abréviation d'Artificial Intelligence of Things (intelligence artificielle des objets), désigne des systèmes où objets connectés et machine learning fonctionnent comme une seule boucle. Les capteurs mesurent, les modèles interprètent, et les résultats déclenchent des actions : une alerte, un ticket de maintenance, une consigne modifiée ou un convoyeur arrêté.

Aucune des deux moitiés n'est très utile seule à grande échelle. Des milliers de capteurs produisent plus de données que des humains ne peuvent en surveiller ; sans analytique, la plupart ne sont donc jamais regardées. Et un modèle sans données en temps réel n'est qu'un rapport sur le passé. Leur combinaison permet de :

• Détecter les comportements inhabituels au moment où ils se produisent, au lieu de les découvrir lors d'une revue mensuelle.
• Prédire les pannes, la demande ou la consommation d'énergie suffisamment tôt pour agir.
• Reconnaître des objets, des personnes et des défauts dans les flux vidéo et audio.
• Expliquer et interagir, en permettant aux personnes de poser des questions sur leurs équipements en langage naturel.

La difficulté est rarement le modèle. Elle consiste à acheminer de manière fiable des données propres et contextualisées jusqu'au modèle, puis à renvoyer ses résultats au bon endroit. C'est un problème d'architecture, et c'est l'objet de ce guide.

Où s'exécute l'IA : équipement, edge ou cloud

La première décision de conception de tout projet IA et IoT porte sur l'endroit où se fait l'inférence. Chaque emplacement a des atouts clairs.

En pratique, la plupart des systèmes utilisent les trois. Un équipement filtre et compresse, un nœud edge exécute le modèle critique en temps, et le cloud entraîne les modèles et analyse le parc. La comparaison IA edge vs IA cloud vous aide à trancher au cas par cas, et qu'est-ce que l'IA edge ainsi que qu'est-ce que le TinyML détaillent les options edge.

Une règle utile consiste à rapprocher le calcul du capteur autant que le modèle le permet, et à n'envoyer que ce dont les systèmes en amont ont besoin. Un accéléromètre échantillonnant à plusieurs kilohertz produit bien trop de données pour être diffusé en continu, mais un microcontrôleur peut calculer chaque seconde la valeur efficace, la crête et quelques bandes de fréquence, puis publier ces caractéristiques dans un petit message JSON. Si vous voulez essayer vous-même l'inférence embarquée, TinyML sur l'ESP32 présente un exemple complet, et la comparaison du matériel d'IA edge vous aide à choisir une passerelle lorsque le modèle dépasse les capacités d'un microcontrôleur.

MQTT comme canal de données et de commandes pour l'IA et l'IoT

Quelle que soit la répartition, équipements, nœuds edge et services cloud doivent échanger des données. MQTT est naturellement adapté à ce rôle :

• Découplage. Un modèle s'abonne aux topics dont il a besoin. Ajouter un second modèle, ou en remplacer un, ne touche pas aux équipements.
• Bidirectionnel. Le même broker transporte la télémétrie vers le haut et les commandes ou les résultats des modèles vers le bas.
• Efficace. Des en-têtes réduits et des connexions persistantes conviennent aux équipements contraints et aux liaisons cellulaires.
• Les résultats comme données. Un modèle publie ses sorties, comme un score d'anomalie ou un objet détecté, sur de nouveaux topics que les tableaux de bord, les alertes et d'autres modèles peuvent consommer.

Une organisation de topics typique sépare données brutes, sorties de modèles et commandes :

plant1/line2/pump3/telemetry          raw sensor readings (JSON)
plant1/line2/pump3/ai/anomaly         model output: score, label, model version
plant1/line2/pump3/ai/forecast        predicted values
plant1/line2/pump3/command/set        validated commands to the device

Publier les sorties des modèles sur leurs propres topics est un pattern sous-estimé. Il rend les résultats de l'IA observables comme n'importe quel autre signal, ce qui compte lorsque quelqu'un demande pourquoi une alerte s'est déclenchée. Il permet aussi d'exécuter deux versions de modèle côte à côte et de les comparer.

Gardez à l'esprit que le broker transporte les données ; il n'exécute pas de modèles. ConnectMQ est un broker MQTT managé sans fonctionnalité d'IA intégrée, et c'est le pattern honnête et modulaire : vos modèles s'exécutent dans des services Python, sur des équipements edge ou dans des plateformes de ML qui se connectent au broker comme de simples clients MQTT.

Préparer les données IoT pour l'IA

Un modèle ne vaut que par les données qu'il voit, et les données IoT brutes sont désordonnées. Avant tout entraînement ou toute inférence, assurez-vous que chaque flux respecte quelques standards de base. Bien les poser dès le départ évite des semaines de nettoyage plus tard.

Des horodatages à la source. Horodatez chaque mesure là où elle est prise, pas là où elle est reçue. Délais réseau, renvois et mise en tampon à l'edge réordonnent les messages, et un modèle qui utilise l'heure d'arrivée apprendra des schémas qui ne sont en réalité que des artefacts réseau. Synchronisez les horloges des équipements avec NTP et incluez l'horodatage dans le payload.

Des unités et un contexte d'actif explicites. Une valeur de 71.2 ne voudra rien dire pour un modèle dans six mois. Placez les unités dans le payload ou dans un schéma documenté, et faites en sorte que le chemin du topic identifie l'actif sans ambiguïté. Un namespace hiérarchique (site, zone, ligne, actif) vous permet de regrouper les données par type de machine ou par emplacement lors de la constitution des jeux d'entraînement.

Un échantillonnage cohérent. De nombreux modèles supposent des intervalles réguliers. Décidez si les équipements rapportent périodiquement, sur changement ou les deux, et documentez-le. Lorsque les équipements rapportent sur changement, un heartbeat périodique avec la valeur courante aide à distinguer « aucun changement » de « aucune donnée ».

Le contexte de fonctionnement. Une pompe qui consomme un courant élevé au démarrage, c'est normal ; le même courant en régime établi ne l'est pas. Publiez l'état de la machine, le type de produit ou l'identifiant de lot avec les mesures des capteurs afin que les modèles puissent en tenir compte.

Étiquettes et événements. Les modèles supervisés ont besoin d'exemples des résultats qui vous intéressent. Enregistrez les interventions de maintenance, les notes des opérateurs et les défauts confirmés comme des événements horodatés sur leurs propres topics, afin de pouvoir les croiser plus tard avec l'historique des capteurs. Le guide sur l'étiquetage des données de capteurs en séries temporelles présente des méthodes pratiques.

Vous pouvez répéter l'ensemble du pipeline de données sur le serveur MQTT public gratuit, réservé aux tests et non aux données de production, avec des valeurs simulées avant de connecter de vrais équipements, et c'est exactement ce que fait l'exemple pratique ci-dessous.

Les principaux cas d'usage de l'AIoT

Détection d'anomalies

La détection d'anomalies signale les mesures ou les schémas qui s'écartent du comportement normal : un roulement plus chaud que d'habitude, un spectre de vibration inhabituel, un profil énergétique qui change du jour au lendemain. C'est le premier projet d'IA le plus courant, car il ne nécessite pas de données de pannes étiquetées. Les méthodes vont des statistiques glissantes aux Isolation Forests et aux autoencodeurs. Commencez par le guide de détection d'anomalies IoT.

Maintenance prédictive

La maintenance prédictive estime quand un équipement tombera en panne afin de planifier la maintenance. Elle a besoin d'historique, idéalement avec des pannes, et d'un bon contexte sur les conditions de fonctionnement. L'article sur la maintenance prédictive avec le machine learning couvre les caractéristiques, les modèles et les données à collecter en premier.

Prévision

La prévision anticipe des valeurs futures comme la charge énergétique, les niveaux de cuve ou la demande de production. Les méthodes classiques de séries temporelles donnent souvent de bons résultats et sont plus faciles à expliquer que les modèles profonds.

Vision par ordinateur

Des caméras équipées de modèles de détection d'objets comptent les pièces, repèrent les défauts, détectent la présence de personnes dans des zones interdites ou lisent des manomètres. La vision s'exécute généralement à l'edge, car diffuser la vidéo vers le cloud coûte cher, et seules les détections transitent via MQTT, comme le montre la détection d'objets YOLO avec MQTT.

Agents LLM et interfaces en langage naturel

Les grands modèles de langage peuvent résumer des données de capteurs, répondre à des questions sur les équipements et, grâce au tool calling, interagir avec des équipements. C'est puissant, et c'est aussi le domaine où les erreurs ont des conséquences physiques. Le guide sur l'agent LLM pour équipements IoT couvre l'architecture, et la section ci-dessous présente la couche de sécurité qui doit s'interposer entre un agent et le matériel réel.

En pratique : détection d'anomalies en temps réel via MQTT

Cet exemple construit un détecteur d'anomalies en streaming en Python. Un simulateur publie des mesures de vibration avec des défauts occasionnels, et un détecteur s'abonne, évalue chaque mesure avec un z-score glissant et publie les événements d'anomalie sur un topic distinct. Les deux fonctionnent sur le serveur MQTT public gratuit broker.connectmq.com, qui accepte les clients anonymes avec un client ID unique et non vide. Les données y sont lisibles par tous : restez donc sur du simulé.

pip install "paho-mqtt>=2.0"

Le simulateur de capteur

# sensor_sim.py
import json
import random
import sys
import time

import paho.mqtt.client as mqtt

RUN_ID = sys.argv[1]  # n'importe quelle courte chaîne unique, ex. a7f3k2
TOPIC = f"connectmq/demo/{RUN_ID}/line2/pump3/telemetry"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"pump3-sim-{RUN_ID}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()

while True:
    vibration = random.gauss(2.0, 0.15)  # vitesse efficace normale en mm/s
    if random.random() < 0.03:
        vibration += random.uniform(1.0, 2.5)  # pic de défaut injecté
    payload = {"ts": int(time.time() * 1000), "vibrationMmS": round(vibration, 3)}
    client.publish(TOPIC, json.dumps(payload), qos=0)
    time.sleep(0.5)

Le détecteur en streaming

# detector.py
import json
import math
import sys
from collections import deque

import paho.mqtt.client as mqtt

RUN_ID = sys.argv[1]
BASE = f"connectmq/demo/{RUN_ID}/line2/pump3"
WINDOW, THRESHOLD, MODEL_VERSION = 120, 4.0, "zscore-v1"
history = deque(maxlen=WINDOW)


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{BASE}/telemetry", qos=0)
    print("detector listening:", reason_code)


def on_message(client, userdata, msg):
    reading = json.loads(msg.payload)
    value = reading["vibrationMmS"]

    if len(history) >= 30:  # attendre une référence minimale
        mean = sum(history) / len(history)
        std = math.sqrt(sum((x - mean) ** 2 for x in history) / len(history)) or 1e-6
        score = (value - mean) / std
        if abs(score) > THRESHOLD:
            event = {
                "ts": reading["ts"],
                "value": value,
                "score": round(score, 2),
                "baselineMean": round(mean, 3),
                "model": MODEL_VERSION,
            }
            client.publish(f"{BASE}/ai/anomaly", json.dumps(event), qos=1)
            print("ANOMALY", event)
            return  # exclure les anomalies de la référence

    history.append(value)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"detector-{RUN_ID}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Exécutez python sensor_sim.py a7f3k2 dans un terminal et python detector.py a7f3k2 dans un autre, en remplaçant a7f3k2 par votre propre chaîne aléatoire. Observez les résultats avec :

mosquitto_sub -h broker.connectmq.com -p 1883 -i viewer-a7f3k2 -t "connectmq/demo/a7f3k2/line2/pump3/ai/#" -v

Trois détails en font plus qu'un jouet. Les valeurs anormales sont exclues de la référence, si bien qu'un défaut n'apprend pas au détecteur que les défauts sont normaux. Chaque événement porte la version du modèle, ce qui permet de savoir quel détecteur l'a produit. Et la sortie est un topic MQTT ordinaire : un tableau de bord, un service d'alerte ou un système de maintenance peut s'y abonner sans modifier le détecteur. Pour une version utilisant Isolation Forest sur plusieurs caractéristiques, voir la détection d'anomalies en temps réel en Python.

Laisser les agents d'IA agir sur les équipements en toute sécurité

Lorsqu'un agent LLM ou n'importe quel modèle envoie des commandes à un équipement physique, le composant le plus important n'est pas le modèle. C'est la barrière entre le modèle et l'équipement. Ne laissez jamais un modèle publier directement sur des topics de commande. Faites plutôt passer ses propositions par un validateur qui applique une liste d'autorisation, des limites et un contrôle de fréquence :

# command_gate.py - valide les commandes proposées par l'IA avant qu'elles n'atteignent les équipements
import json
import time
import uuid

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/a7f3k2"
POLICY = {
    "line2/pump3": {"setpointRpm": (800, 1600)},
    "line2/fan1": {"speedPct": (0, 80)},
}
MIN_INTERVAL_S = 10
last_sent = {}


def validate(proposal):
    asset, param, value = proposal["asset"], proposal["param"], proposal["value"]
    if asset not in POLICY or param not in POLICY[asset]:
        return f"{asset}/{param} is not on the allowlist"
    lo, hi = POLICY[asset][param]
    if not isinstance(value, (int, float)) or not lo <= value <= hi:
        return f"value {value} outside [{lo}, {hi}]"
    if time.time() - last_sent.get(asset, 0) < MIN_INTERVAL_S:
        return "rate limit: too many commands for this asset"
    return None


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/ai/proposals", qos=1)


def on_message(client, userdata, msg):
    try:
        proposal = json.loads(msg.payload)
        error = validate(proposal)
    except (ValueError, KeyError) as exc:
        proposal, error = {"raw": msg.payload.decode(errors="replace")}, f"malformed: {exc}"
    audit = {"ts": int(time.time() * 1000), "proposal": proposal, "accepted": error is None, "reason": error}
    client.publish(f"{PREFIX}/ai/audit", json.dumps(audit), qos=1)
    if error is None:
        topic = f"{PREFIX}/{proposal['asset']}/command/set"
        client.publish(topic, json.dumps({proposal["param"]: proposal["value"]}), qos=1)
        last_sent[proposal["asset"]] = time.time()


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

L'agent, quel que soit le LLM ou le framework utilisé, publie des propositions comme {"asset": "line2/pump3", "param": "setpointRpm", "value": 1450} sur ai/proposals. Seule la barrière publie sur les topics de commande des équipements, et chaque décision est consignée sur un topic d'audit. En production, la barrière s'exécute avec ses propres identifiants de broker, et les équipements n'acceptent de commandes que d'elle. Les fonctions de sécurité restent dans l'automate ou le contrôleur, là où aucun logiciel de niveau supérieur ne peut les outrepasser. Le contrôle sûr des équipements IoT par l'IA complète cette approche avec des étapes d'approbation humaine, et construire un serveur MCP pour MQTT montre comment exposer de manière structurée des outils de lecture et de commande à un agent.

Une feuille de route pour un projet AIoT

1. Définissez la décision. Qu'est-ce qui changera quand le modèle produira un résultat ? Si rien, arrêtez-vous là.
2. Collectez et contextualisez les données. Topics, unités, horodatages et métadonnées d'actifs cohérents. La plupart des projets d'IA échouent sur la qualité des données, pas sur les algorithmes.
3. Établissez une référence avec des règles simples ou des statistiques. Elle vous dit si un modèle complexe apporte quelque chose.
4. Choisissez l'emplacement de l'inférence selon la latence, la bande passante et la connectivité.
5. Publiez les sorties des modèles sous forme de topics avec la version du modèle et le niveau de confiance.
6. Bouclez la boucle avec prudence : d'abord les alertes, ensuite les recommandations, enfin les commandes automatisées, et uniquement via une barrière de validation.
7. Supervisez et réentraînez. Les capteurs dérivent, les procédés changent et les modèles se dégradent. Le guide MLOps pour l'IoT couvre le versionnage, la supervision et le redéploiement.

Les pièges courants

• Entraîner sur des données non représentatives. Un modèle entraîné en été risque de signaler chaque matin d'hiver comme une anomalie.
• Ignorer les données manquantes. Un capteur qui se tait est en soi un signal. Utilisez des topics de statut avec Last Will pour que les modèles ne confondent pas les trous avec des mesures stables.
• Des alertes boîte noire. Les opérateurs ignorent les alertes qu'ils ne comprennent pas. Incluez la valeur, la référence et la raison dans chaque événement.
• Faire trop confiance aux LLM. Les modèles de langage peuvent produire des commandes plausibles mais erronées. Validez tout ce qu'ils proposent par rapport à des limites strictes.
• Tout envoyer dans le cloud. Les vibrations haute fréquence ou la vidéo doivent être traitées à l'edge, seules les caractéristiques ou les détections étant envoyées en amont.

Alimentez votre pipeline AIoT avec ConnectMQ

Vos modèles ont besoin d'un flux de données entrant fiable et d'un canal contrôlé pour les résultats et les commandes sortants. Créez un compte gratuit sur app.connectmq.com avec le plan Serverless, sans carte bancaire, puis connectez équipements, détecteurs et agents avec les identifiants générés via TLS sur le port 8883. ConnectMQ prend en charge MQTT 3.1.1 et 5.0, et les plans payants ajoutent les abonnements partagés pour que plusieurs instances de détecteur se répartissent la charge d'un même flux de télémétrie. Pour davantage de connexions ou un environnement isolé, comparez les plans de broker MQTT cloud.

Questions fréquentes

Quelle est la différence entre l'IA et l'IoT ?

L'IoT est le réseau d'objets connectés qui mesurent et agissent dans le monde physique, tandis que l'IA est l'ensemble des techniques qui apprennent des schémas à partir de données et font des prédictions. L'AIoT les combine pour que les données des équipements alimentent les modèles et que les sorties des modèles déclenchent des actions.

L'IA doit-elle s'exécuter à l'edge ou dans le cloud ?

Exécutez à l'edge l'inférence critique en temps et gourmande en bande passante, comme la vision ou l'analyse de vibrations haute fréquence. Utilisez le cloud pour l'entraînement, l'analytique à l'échelle du parc, les prévisions et les grands modèles de langage. La plupart des systèmes combinent les deux.

ConnectMQ inclut-il des fonctionnalités d'IA ou de machine learning ?

Non. ConnectMQ est la couche de messagerie MQTT. Vos modèles s'exécutent dans vos propres services, sur des équipements edge ou dans des plateformes de ML, qui se connectent à ConnectMQ en tant que clients MQTT pour recevoir les données et publier les résultats.

Un LLM peut-il commander directement des équipements IoT ?

Il ne le devrait pas. Faites passer les commandes proposées par un agent par une barrière de validation qui applique des listes d'autorisation, des limites de valeurs et des limites de fréquence, tient une piste d'audit et constitue le seul client autorisé à publier sur les topics de commande des équipements.

Quel est le premier projet IA et IoT le plus simple ?

La détection d'anomalies en temps réel sur un flux de capteur existant, car elle ne nécessite aucune donnée de panne étiquetée. Une référence statistique glissante comme celle de l'exemple de ce guide suffit souvent à produire des alertes utiles.