L'IA générative dans l'industrie : cas d'usage concrets ancrés dans les données de l'usine

L'IA générative dans l'industrie apporte le plus de valeur lorsqu'elle s'appuie sur les données réelles de l'usine plutôt que sur des connaissances générales. Cet article passe en revue les cas d'usage qui tiennent la route dans un véritable atelier, l'infrastructure de données dont ils ont besoin et les garde-fous qui font d'un modèle de langage un outil utile plutôt qu'un risque. À la fin, vous saurez par quel projet commencer et comment l'alimenter en données machine en direct via MQTT.

Pourquoi les projets d'IA générative dans l'industrie s'enlisent

La plupart des premières expériences impressionnent en démonstration, puis s'essoufflent. Le scénario est connu : quelqu'un colle quelques codes d'alarme dans une fenêtre de chat, obtient une explication plausible, et l'équipe en conclut que le modèle « connaît » les machines. Une semaine plus tard, il explique avec aplomb une alarme qui n'existe pas sur cet automate.

Le problème de fond est l'ancrage. Un grand modèle de langage possède de vastes connaissances sur les machines CNC, les automates et les méthodes qualité, mais il ne sait rien de votre ligne 3, de votre recette pour la pièce 4711 ou du fait que le four tourne toujours dix degrés trop chaud en équipe de nuit. Sans ce contexte, il comble les lacunes par des suppositions.

La question utile n'est donc pas « que peut faire l'IA générative ? » mais « quelles tâches consistent surtout à transformer des données et des documents existants en texte, et où pouvons-nous fournir ces données au modèle de manière fiable ? » Ce recadrage mène à une courte liste de cas d'usage qui fonctionnent.

Les cas d'usage qui fonctionnent aujourd'hui

Rapports de poste et synthèses des arrêts

C'est le gain le plus facile. Dans chaque usine, quelqu'un passe la dernière demi-heure du poste à compiler ce qui s'est passé : quelles machines se sont arrêtées, pourquoi, combien de pièces ont été produites et ce que l'équipe suivante doit surveiller. Les données existent déjà sous forme d'états machine et de compteurs. Un petit service peut collecter les événements du poste, construire une synthèse structurée (chiffres calculés par le code, pas par le modèle) et demander au modèle de langage de la transformer en texte lisible.

Le choix de conception important est de laisser le modèle rédiger, pas calculer. Calculez le TRS, les minutes d'arrêt et le nombre de pièces en Python ou en SQL, transmettez-les comme des faits et demandez au modèle de n'utiliser que ces valeurs. Pour approfondir ce schéma, consultez les synthèses de données de capteurs par LLM.

Assistants de dépannage

Quand une machine passe en alarme à 3 h du matin, le technicien a besoin de la page du manuel, du dernier incident similaire et de l'état actuel des signaux associés. Un assistant de dépannage récupère ces éléments et les présente ensemble avec une liste de vérifications suggérée. La recherche dans les manuels et les tickets passés en est le cœur, c'est pourquoi ce cas d'usage s'appuie généralement sur la génération augmentée par récupération pour les données industrielles.

La partie en direct compte autant que les documents. Un assistant qui voit « température de broche en hausse depuis 20 minutes, débit de liquide de coupe en baisse à 02:41 » fait de bien meilleures suggestions qu'un assistant qui ne voit que le numéro d'alarme.

Aide au code et à l'intégration

Les ingénieurs passent un temps étonnant à écrire du code de liaison : une fonction Node-RED pour remodeler un payload, un abonné Python, une requête SQL pour un rapport. Les modèles de langage savent bien rédiger ce type de code lorsqu'ils voient de vrais exemples. Donnez au modèle un exemple de payload MQTT et votre convention de topics, et il pourra ébaucher un parseur en quelques secondes. Traitez le résultat comme le code d'un nouveau collègue : relisez-le, testez-le sur le serveur MQTT public gratuit, réservé aux tests, puis mettez-le en production.

Copilotes industriels

Combinez les trois cas précédents et vous obtenez ce que les éditeurs appellent un copilote IA industriel : une interface unique où l'opérateur pose des questions, obtient des synthèses et prépare des actions. Commencez par un accès en lecture seule. Écrire des consignes ou des commandes depuis un modèle est un problème distinct, bien plus difficile, qui exige ses propres protections.

Le socle de données : diffuser les données de l'usine via MQTT

Chacun des cas d'usage ci-dessus dépend de données fraîches et structurées. MQTT s'y prête naturellement, car les machines, les passerelles et les équipements edge y publient déjà, et autant de consommateurs que nécessaire peuvent s'abonner sans toucher aux machines.

Une arborescence de topics pratique suit les niveaux ISA-95 afin que les personnes comme les modèles puissent la lire :

connectmq/factory1/production/line1/cnc1/telemetry
connectmq/factory1/production/line1/cnc1/state
connectmq/factory1/production/line1/cnc1/alarms

Un payload de télémétrie typique :

{
  "ts": "2026-10-16T02:41:12Z",
  "spindleTempC": 61.4,
  "coolantFlowLpm": 8.2,
  "spindleLoadPct": 74,
  "partCount": 1532
}

Des noms de topics lisibles jouent un double rôle : ils aident les humains dans un explorateur de topics et donnent gratuitement du contexte au modèle. Un modèle qui voit line1/cnc1/alarms n'a pas besoin qu'on lui explique de quelles données il s'agit.

Un collecteur de poste minimal en Python

Le service ci-dessous s'abonne à tout un site, conserve le dernier état de chaque machine et compte les alarmes. En fin de poste, il transmettrait cette synthèse structurée au LLM de votre choix. Il utilise le serveur MQTT public gratuit broker.connectmq.com : n'utilisez donc que des données synthétiques.

import json
import time
import uuid
from collections import defaultdict

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/genai-7f3a"
latest = {}
alarm_counts = defaultdict(int)


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"{PREFIX}/factory1/production/+/+/#", qos=1)


def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    machine = "/".join(parts[-3:-1])  # p. ex. line1/cnc1
    kind = parts[-1]
    try:
        payload = json.loads(msg.payload)
    except json.JSONDecodeError:
        return
    if kind == "alarms":
        alarm_counts[machine] += 1
    else:
        latest.setdefault(machine, {}).update(payload)


def build_summary():
    return {
        "machines": latest,
        "alarmCounts": dict(alarm_counts),
        "generatedAt": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
    }


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

try:
    while True:
        time.sleep(60)
        summary = build_summary()
        print(json.dumps(summary, indent=2))
        # Passez `summary` à votre LLM avec un prompt tel que :
        # "Write a shift report using ONLY these facts. Do not invent numbers."
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Notez que le broker n'effectue ici aucun traitement d'IA. ConnectMQ achemine les données de manière fiable ; le collecteur et le modèle sont vos propres services, qui se connectent comme des clients MQTT ordinaires. Cette séparation est saine : vous pouvez changer de modèle sans toucher aux machines.

Les garde-fous qui gardent l'IA générative utile

Une liste de contrôle numérotée à appliquer à chaque pilote d'IA générative dans l'industrie :

1. Des faits en entrée, du texte en sortie. Calculez tous les chiffres en dehors du modèle et demandez-lui de n'utiliser que les valeurs fournies.
2. Citer la source. Demandez au modèle d'indiquer le topic, le document ou le ticket d'où provient chaque affirmation, et montrez-le à l'utilisateur.
3. Lecture seule d'abord. Aucun topic de commande à la portée du modèle tant que la version en lecture seule n'a pas gagné la confiance des équipes.
4. Validation humaine des actions. Si le modèle prépare un ordre de travail ou une modification de consigne, une personne l'approuve. Consultez le pilotage sûr des objets IoT par l'IA pour les schémas côté commande.
5. Journaliser prompts et réponses. Vous en aurez besoin pour diagnostiquer les mauvaises réponses et améliorer les prompts.
6. Protéger les données sensibles. Utilisez un broker privé avec identifiants pour les vraies données de l'usine, jamais le serveur MQTT public gratuit.
7. Mesurer l'utilité. Demandez aux opérateurs si la synthèse leur a fait gagner du temps ; abandonnez les cas d'usage qui n'y parviennent pas.

Choisir où s'exécute le modèle

Les API de LLM hébergées sont le moyen le plus rapide de démarrer et conviennent aux synthèses de données non sensibles. Les usines soumises à des politiques de données strictes exécutent souvent des modèles ouverts en local ; un serveur sur site exécutant un runtime de modèle local et abonné au broker de l'usine peut le faire sans qu'aucune donnée ne quitte le site. Dans les deux cas, le chemin des données est le même : les machines publient vers le broker, un abonné construit le contexte, le modèle rédige le texte, et le résultat repart vers un topic, un système de tickets ou un e-mail.

Si vous cartographiez l'architecture globale des modèles, des équipements edge et des brokers, le guide IA et IoT indique où se place chaque type de modèle.

Bien dimensionner l'infrastructure

Le broker devient une dépendance partagée dès que plusieurs services lisent les mêmes données d'usine ; il ne doit donc pas être une machine virtuelle oubliée sous le bureau de quelqu'un. Un broker MQTT managé vous apporte TLS, identifiants et supervision sans avoir à exploiter vous-même le serveur. ConnectMQ détecte aussi les topics ISA-95 et Unified Namespace et peut republier les données Sparkplug B dans des topics ISA-95 lisibles, exactement le type de structure qui rend les données de l'usine plus faciles à exploiter, pour les personnes comme pour les modèles.

Pour le prototypage, le serveur MQTT public gratuit broker.connectmq.com vous permet de construire le collecteur et les prompts avec des données simulées avant que quoi que ce soit ne touche la production.

Lancez votre pipeline de données d'usine sur ConnectMQ

L'IA générative ne vaut que ce que valent les données que vous lui fournissez. Créez un broker privé avec l'offre gratuite Serverless sur app.connectmq.com, sans carte bancaire, connectez une passerelle ou un simulateur et regardez les topics arriver dans l'explorateur de topics en direct. Une fois les données en circulation, votre premier générateur de rapports de poste ne demande qu'un après-midi de travail.

Questions fréquentes

Quel est le meilleur premier projet d'IA générative dans une usine ?

Les synthèses automatiques de poste ou d'arrêts. Les données existent déjà, le résultat est facile à vérifier, et une phrase erronée coûte peu, car une personne la lit avant d'agir.

Un modèle de langage peut-il piloter directement des machines ?

Il ne devrait pas, du moins pas sans limites strictes et validation humaine. Commencez par des assistants en lecture seule et n'ajoutez des chemins de commande qu'avec validation, listes d'autorisation et étapes de confirmation.

ConnectMQ inclut-il des fonctionnalités d'IA ?

Non. ConnectMQ est le broker MQTT qui transporte les données de l'usine ; votre application LLM s'y connecte comme un client MQTT normal, ce qui vous laisse libre de choisir n'importe quel modèle.

Comment empêcher le modèle d'inventer des chiffres ?

Calculez chaque indicateur dans le code, transmettez les résultats sous forme de faits structurés et demandez au modèle de n'utiliser que ces valeurs. Comparer les résultats aux données sources pendant le pilote permet de détecter les problèmes restants.