L'inspection visuelle par IA utilise des caméras et des modèles entraînés pour décider si une pièce est bonne ou défectueuse, à la cadence de la ligne et sans fatigue de l'opérateur. Cet article explique comment se construit un poste d'inspection, quels défauts l'IA traite mieux que la vision industrielle à base de règles, et comment publier chaque verdict conforme/non conforme via MQTT pour que le pilotage de ligne, les tableaux de bord et les enregistrements de traçabilité restent synchronisés.
Ce que fait l'inspection visuelle par IA
La vision industrielle traditionnelle repose sur des règles réglées à la main : mesurer un bord, compter les pixels au-dessus d'un seuil, comparer à un modèle de référence. Cela fonctionne bien pour les contrôles dimensionnels sur des pièces homogènes. Cela devient difficile quand les défauts varient en forme et en aspect, comme les rayures, les bosses, la porosité, la contamination, les étiquettes froissées ou les soudures irrégulières, ou quand l'éclairage et la finition des pièces changent au cours d'un poste.
L'inspection visuelle par IA remplace ou complète ces règles par un modèle appris. Selon le problème, le modèle relève de l'une de ces trois catégories :
- Classification : l'image entière est étiquetée
okoung(non conforme), ou se voit attribuer une classe de défaut. - Détection d'objets ou segmentation : le modèle trace des boîtes ou des masques autour des défauts, ce qui indique leur emplacement et leur taille.
- Détection d'anomalies : le modèle est entraîné principalement sur des pièces conformes et signale tout ce qui paraît inhabituel. C'est précieux lorsque les échantillons défectueux sont rares, ce qui est courant sur une ligne mature.
Le résultat qui compte pour l'usine est simple : un verdict, une confiance, le type de défaut et un identifiant qui rattache le résultat à une pièce précise.
Anatomie d'un poste d'inspection
Un poste opérationnel est bien plus qu'un modèle. Les éléments qui déterminent sa réussite sont généralement physiques.
| Composant | Ce qu'il faut décider | Piège courant |
|---|---|---|
| Caméra | Matricielle ou linéaire, résolution, monochrome ou couleur | Choisir la résolution avant de connaître la taille du plus petit défaut |
| Optique | Focale de l'objectif, distance de travail, profondeur de champ | Pièces à différentes hauteurs qui sortent de la zone de netteté |
| Éclairage | Annulaire, dôme, rétroéclairage, champ sombre rasant | Lumière ambiante des fenêtres qui modifie les résultats au fil de la journée |
| Déclenchement | Cellule photoélectrique ou signal codeur de l'automate | Capture temporisée par logiciel qui dérive avec la vitesse du convoyeur |
| Calcul | PC industriel avec GPU, Jetson ou caméra intelligente | Exécuter l'inférence sur un PC de bureau partagé |
| Éjection | Soufflage, aiguillage, prélèvement par robot | Aucune confirmation que l'éjection a réellement eu lieu |
| Chemin des données | MQTT vers le pilotage de ligne, le MES et les tableaux de bord | Résultats stockés uniquement sur le PC d'inspection |
L'éclairage mérite le plus d'attention. Un bon éclairage rend les défauts évidents pour un humain qui regarde l'image brute ; si vous ne voyez pas la rayure, il est peu probable que le modèle apprenne à la reconnaître de façon fiable.
Construire le modèle de défauts
Le flux de travail du modèle suit un chemin prévisible :
- Collectez des images sur le poste réel, avec la caméra, l'objectif et l'éclairage définitifs. Les images prises au téléphone sur l'établi ne sont pas transposables.
- Étiquetez de manière cohérente. Rédigez un court catalogue de défauts avec des exemples de chaque classe et la limite entre acceptable et rebut. Les désaccords entre annotateurs deviennent du bruit pour le modèle.
- Entraînez et validez sur des images que le modèle n'a jamais vues, y compris des pièces de lots et de postes différents.
- Choisissez le seuil avec les ingénieurs qualité. Laisser passer un défaut (fuite) et rejeter une pièce conforme (faux rebut) ont des coûts très différents : le seuil de confiance est donc une décision métier.
- Commencez en mode fantôme : le modèle publie ses verdicts sans déclencher d'éjection, et vous les comparez à l'inspection manuelle.
- Déployez en périphérie, généralement sous forme de modèle optimisé sur un GPU ou un accélérateur à côté de la caméra. Consultez le déploiement de modèles ML sur des appareils edge pour les stratégies de packaging et de mise à jour.
L'inférence a sa place en périphérie, car la décision d'éjection doit intervenir avant que la pièce ne quitte la fenêtre d'éjection. Envoyer des images complètes vers le cloud ajoute de la latence et de la bande passante sans aucun bénéfice. Ce qui transite sur le réseau, c'est le résultat. La comparaison edge AI vs IA cloud détaille ce compromis.
Pourquoi MQTT pour les résultats de l'inspection visuelle par IA
Un verdict d'inspection a plusieurs consommateurs : l'automate ou le contrôleur de ligne qui déclenche l'éjection, le MES ou la base de traçabilité qui enregistre le résultat avec un numéro de série, un tableau andon, un tableau de bord qualité et éventuellement l'ordinateur portable d'un ingénieur pendant la mise en service. Relier chacun d'eux en point à point est fragile. Avec le publish/subscribe, le poste publie une seule fois et chaque consommateur s'abonne à ce dont il a besoin.
MQTT convient bien car il est léger, prend en charge la QoS 1 pour une livraison au moins une fois, et permet de publier un statut de poste en retained message, de sorte qu'un tableau de bord démarré plus tard sait immédiatement si le poste est en ligne. Des hiérarchies de topics suivant les niveaux ISA-95 donnent à chaque résultat une adresse claire, par exemple :
connectmq/plant1/assembly/line2/inspect1/result
connectmq/plant1/assembly/line2/inspect1/status
connectmq/plant1/assembly/line2/inspect1/stats
connectmq/plant1/assembly/line2/inspect1/cmd/threshold
ConnectMQ détecte les topics de style ISA-95 et Unified Namespace et présente les appareils par entreprise, site, zone, ligne et cellule dans sa vue des appareils, ce qui facilite la navigation dans un parc croissant de postes d'inspection. Si vous utilisez déjà Sparkplug B sur la ligne, le guide Sparkplug B et Unified Namespace explique comment les deux styles de topics coexistent.
Conception du payload de résultat
Conservez un message par pièce inspectée, compact et autodescriptif :
{
"partId": "SN-24-104877",
"ts": "2026-10-16T09:41:07.312Z",
"verdict": "ng",
"defect": "scratch",
"confidence": 0.93,
"bbox": [412, 188, 470, 214],
"model": "housing-defects-v7",
"threshold": 0.80,
"inferenceMs": 18,
"imageRef": "inspect1/2026-10-16/SN-24-104877.jpg"
}
Les champs model et threshold rendent les résultats traçables des mois plus tard : lorsqu'une réclamation client arrive, vous pouvez montrer quelle version du modèle a jugé la pièce et avec quel réglage. L'image elle-même reste sur un stockage local ou part vers un stockage d'images ; le message MQTT transporte une référence, pas les pixels.
Exemple : publier les résultats d'inspection en Python
Cet exemple simule la boucle du poste avec paho-mqtt 2.x. Remplacez run_model() par votre véritable appel d'inférence. Il publie les résultats en QoS 1, un statut online/offline en retained avec un Last Will, ainsi que des statistiques de rendement périodiques.
import json
import random
import time
import uuid
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
HOST, PORT = "broker.connectmq.com", 1883
RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/plant1/assembly/line2/inspect1"
MODEL = "housing-defects-v7"
threshold = 0.80
def run_model(image=None):
"""Stand-in for real inference: returns (label, confidence, bbox)."""
if random.random() < 0.08:
return random.choice(["scratch", "dent", "missing_screw"]), random.uniform(0.6, 0.99), [412, 188, 470, 214]
return "ok", random.uniform(0.85, 0.99), None
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code)
client.publish(f"{BASE}/status", "online", qos=1, retain=True)
client.subscribe(f"{BASE}/cmd/threshold", qos=1)
def on_message(client, userdata, msg):
global threshold
try:
value = float(msg.payload)
if 0.5 <= value <= 0.99:
threshold = value
print("threshold set to", threshold)
except ValueError:
print("ignored invalid threshold", msg.payload)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"inspect1-{RUN_ID}")
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, PORT, keepalive=30)
client.loop_start()
ok = ng = 0
try:
for n in range(1, 10_000):
start = time.perf_counter()
label, conf, bbox = run_model()
inference_ms = round((time.perf_counter() - start) * 1000, 1)
verdict = "ng" if label != "ok" and conf >= threshold else "ok"
ok, ng = (ok + 1, ng) if verdict == "ok" else (ok, ng + 1)
part_id = f"SN-{RUN_ID}-{n:06d}"
result = {
"partId": part_id,
"ts": datetime.now(timezone.utc).isoformat(timespec="milliseconds"),
"verdict": verdict,
"defect": None if label == "ok" else label,
"confidence": round(conf, 3),
"bbox": bbox,
"model": MODEL,
"threshold": threshold,
"inferenceMs": inference_ms,
}
client.publish(f"{BASE}/result", json.dumps(result), qos=1)
if n % 20 == 0:
stats = {"ok": ok, "ng": ng, "yield": round(ok / (ok + ng), 4)}
client.publish(f"{BASE}/stats", json.dumps(stats), qos=1, retain=True)
time.sleep(0.5) # stays well under the public broker's 10 msg/s per client
finally:
client.publish(f"{BASE}/status", "offline", qos=1, retain=True)
client.loop_stop()
client.disconnect()
Suivez les résultats depuis un autre terminal, en remplaçant l'ID par celui du topic :
mosquitto_sub -h broker.connectmq.com -p 1883 -i qa-viewer-91c2 \
-t 'connectmq/demo/<run-id>/plant1/assembly/line2/inspect1/#' -v
Le serveur MQTT public gratuit convient pour essayer la conception du payload et des topics, mais il est ouvert à tous et réservé aux tests. Les données d'inspection de production ont leur place sur un broker privé en TLS sur le port 8883, avec les identifiants et le client ID attribués au poste.
Boucler avec le pilotage de ligne
L'actionneur d'éjection ne doit pas dépendre d'un aller-retour vers le cloud. Dans la plupart des usines, le poste signale l'éjection directement à l'automate via des E/S ou un bus de terrain, et MQTT transporte le même verdict pour tout le reste : comptage, traçabilité, tableaux de bord et alarmes. Lorsqu'un automate ou un contrôleur edge s'abonne bien au topic de résultat, gardez le broker près de la ligne ou assurez-vous que la logique d'éjection se met en sécurité si la connexion tombe.
Quelques règles garantissent la fiabilité du système :
- Publiez une confirmation d'éjection depuis le capteur de l'aiguillage, afin de rapprocher les verdicts
ngdes éjections réelles. - Indiquez la version du modèle dans chaque message et conservez en retained un topic
statusdécrivant le modèle actif. - Limitez qui peut publier sur les topics
cmd/, et validez chaque valeur de commande sur le poste, comme le fait l'exemple pour le seuil. - Alertez sur la dérive du rendement. Une chute soudaine du rendement est souvent due à l'éclairage ou à la caméra plutôt qu'à un vrai problème de qualité.
Les règles d'alerte à seuil de ConnectMQ peuvent surveiller des valeurs numériques comme le rendement dans un message de statistiques et enregistrer les alertes dans le journal des alertes, ce qui permet de repérer rapidement une dérive sans construire un service de supervision séparé.
Problèmes courants en production
| Symptôme | Cause probable | Ce qu'il faut vérifier |
|---|---|---|
| Précision en baisse après un arrêt de maintenance | Caméra ou éclairage déplacé | Comparer une image de référence avec la capture du jour |
| Plus de faux rebuts l'après-midi | Lumière ambiante | Capot ou carénage autour de la zone d'inspection |
| Résultats manquants dans la base de traçabilité | Abonné hors ligne, QoS 0 | QoS 1 et session persistante pour le processus d'écriture en base |
| Enregistrements en double | Relivraison QoS 1 | Utiliser partId comme clé idempotente à l'insertion |
| Nouveau type de défaut non détecté | Le modèle ne l'a jamais vu | Réinjecter les fuites dans l'étiquetage et réentraîner |
Pour des projets de vision connexes, consultez la détection d'objets YOLO via MQTT, le guide Jetson Nano MQTT et le guide de référence IA et IoT.
Connectez vos postes d'inspection à ConnectMQ
Chaque poste, tableau de bord et processus d'écriture de traçabilité a besoin d'un point de rencontre fiable. ConnectMQ vous fournit un broker MQTT managé avec TLS, MQTT 5, une vue des appareils ISA-95 et des alertes à seuil, sans exploiter d'infrastructure de broker sur le réseau de l'usine. Créez un broker avec l'offre gratuite Serverless sur app.connectmq.com, sans carte bancaire, puis passez à un déploiement Dedicated ou BYOC lorsque la ligne entre en production. Si vous êtes encore en phase d'évaluation, le serveur MQTT public gratuit est idéal pour prototyper le payload.
Questions fréquentes
Combien d'images faut-il pour entraîner un modèle d'inspection visuelle par IA ?
Cela dépend de la variabilité des pièces et des défauts. Commencez avec des images du poste réel, couvrez chaque classe de défaut et les variations normales, et ajoutez des exemples chaque fois que le modèle manque quelque chose en mode fantôme.
Faut-il envoyer les images via MQTT ?
En général, non. Envoyez le verdict, la confiance et une référence d'image via MQTT, et stockez les images en local ou dans un stockage objet, car les gros messages binaires atteignent les limites de taille du broker et ralentissent chaque abonné.
L'inspection visuelle par IA peut-elle remplacer la vision industrielle à base de règles ?
Pas toujours. La mesure dimensionnelle précise reste mieux assurée par des règles, tandis que l'IA gère les défauts d'aspect variables. De nombreux postes combinent les deux et publient un verdict unique.
Quelle QoS utiliser pour les résultats d'inspection ?
La QoS 1 est le choix habituel, car chaque résultat doit arriver pour la traçabilité. Rendez l'insertion en base idempotente sur l'identifiant de pièce afin que d'éventuels doublons soient sans conséquence.
