Une preuve de concept IIoT doit répondre à une question métier précise avec de vraies données d'usine, dans un délai court et fixe, et 30 jours suffisent si vous gardez un périmètre serré. Dans ce guide, vous trouverez un plan semaine par semaine, les métriques de réussite à valider avant de commencer, une stack légère composée d'une passerelle, d'un broker MQTT managé et d'un tableau de bord, ainsi qu'un simulateur fonctionnel pour construire le pipeline de données avant même l'arrivée du matériel.
Pourquoi la plupart des pilotes IIoT s'enlisent
Les pilotes d'IoT industriel échouent rarement parce que la technologie ne fonctionne pas. Ils s'enlisent parce que le périmètre s'étend jusqu'à « connecter toute la ligne », parce que personne ne s'est mis d'accord sur ce qu'est une réussite, ou parce que le pilote dépend d'une infrastructure qui met des mois à être validée. Résultat : le fameux purgatoire des pilotes, une démo qui impressionne une fois et ne sert plus jamais.
Une bonne preuve de concept est tout l'inverse. Elle est assez petite pour être terminée, assez importante pour que quelqu'un dans l'atelier en attende le résultat, et construite sur des composants capables de monter en charge sans réécriture si elle réussit.
Étape 1 : choisir un périmètre étroit et utile
Choisissez une question à laquelle une personne précise a besoin d'une réponse. De bons exemples :
- « Pourquoi la CNC goulot de la cellule 3 s'arrête-t-elle, et pendant combien de temps ? »
- « Le compresseur tourne-t-il quand l'usine est à l'arrêt la nuit ? »
- « À quelle fréquence le four 2 sort-il de sa plage de température ? »
Limitez ensuite volontairement le périmètre :
- Une à trois machines, idéalement du même type.
- Trois à dix signaux, par exemple l'état, le compteur de pièces, le courant et une alarme.
- Lecture seule. Aucune écriture dans les automates pendant la preuve de concept.
- Un seul tableau de bord, utilisé par des personnes nommément identifiées.
Gardez les ambitions plus larges, comme un jumeau numérique de toute la ligne, pour la phase qui suit une preuve de concept réussie.
Si la machine visée n'a pas d'interface réseau, prévoyez plutôt des capteurs additionnels. Notre guide sur la modernisation des machines anciennes pour l'IoT présente les pinces ampèremétriques et les compteurs de pièces.
Étape 2 : valider les métriques de réussite avant le jour 1
Écrivez les métriques et faites-les signer par le directeur d'usine. Mélangez mesures techniques et mesures métier.
| Métrique | Exemple d'objectif | Comment la mesurer |
|---|---|---|
| Complétude des données | Données présentes pour au moins 98 % des minutes de production | Trous dans la série temporelle |
| Latence | État de la machine visible sur le tableau de bord en moins de 5 secondes | Comparer avec un chronomètre à la machine |
| Exactitude | Les événements d'arrêt correspondent au journal opérateur | Comparaison côte à côte pendant une semaine |
| Adoption | Le chef d'équipe consulte le tableau de bord chaque jour | Lui demander, ou vérifier les accès au tableau de bord |
| Enseignement | Au moins une action décidée grâce aux données | Décision documentée |
| Effort pour ajouter une machine | Moins d'une journée par machine supplémentaire | Chronométrer le dernier ajout |
Les objectifs ci-dessus sont des exemples. Fixez les vôtres, mais rendez-les mesurables. « Montrer la valeur de l'IIoT » n'est pas une métrique. Beaucoup d'équipes estiment aussi le retour sur investissement attendu pour le business case ; notre article sur le ROI de l'IIoT explique comment le présenter honnêtement.
Étape 3 : choisir une stack légère
Résistez à la tentation de construire une plateforme. Une preuve de concept a besoin de quatre éléments :
- Une source de données. L'automate de la machine via une passerelle de protocole, ou des capteurs additionnels via un microcontrôleur.
- Une passerelle edge. Un petit PC industriel ou un Raspberry Pi exécutant Node-RED, un script Python ou une passerelle commerciale qui lit la source et publie en MQTT.
- Un broker. Un broker MQTT managé, pour que personne ne passe la première semaine à installer et sécuriser un serveur.
- Un tableau de bord. Node-RED Dashboard, Grafana alimenté par un petit abonné, ou le tableau de bord du broker lui-même pour les tout premiers jours.
C'est le même modèle en couches que celui décrit dans notre référence sur l'architecture IIoT, avec un seul composant par couche. Comme chaque couche parle MQTT, chaque élément peut être remplacé plus tard sans toucher aux autres.
Le plan de preuve de concept IIoT sur 30 jours
| Semaine | Objectif | Activités clés | Critères de sortie |
|---|---|---|---|
| 1 | Fondations | Confirmer périmètre et métriques, cartographier le chemin réseau, demander la règle de pare-feu sortante sur 8883, créer le broker, définir les noms de topics, lancer le simulateur | Données simulées visibles sur un tableau de bord |
| 2 | Données réelles | Installer la passerelle, se connecter à l'automate ou aux capteurs en lecture seule, publier vers le broker, valider les valeurs par rapport à l'IHM | Données en temps réel de toutes les machines du pilote |
| 3 | Rendre l'outil utile | Construire le tableau de bord avec les opérateurs, ajouter les durées d'état et la liste des arrêts, configurer les alertes à seuil | Le chef d'équipe utilise le tableau de bord chaque jour |
| 4 | Prouver et décider | Mesurer les métriques, comparer avec les relevés manuels, documenter l'effort et les enseignements, présenter les résultats | Décision go ou no-go chiffrée |
Pour le travail réseau de la semaine 1, la checklist de connectivité IIoT fournit les règles exactes et les commandes de test.
Construire le pipeline avant l'arrivée du matériel
Le matériel et les autorisations de pare-feu prennent souvent une semaine ou plus. N'attendez pas. Construisez le pipeline complet dès le premier jour avec un simulateur, en utilisant le serveur MQTT public gratuit, afin que la vraie passerelle remplace simplement le simulateur lors de sa mise en service.
import json
import random
import time
import uuid
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
POC_ID = uuid.uuid4().hex[:6]
BASE = f"connectmq/demo/{POC_ID}/plant1/cell3"
MACHINES = ["cnc01", "cnc02"]
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"poc-sim-{POC_ID}")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
print(f"Subscribe to: {BASE}/#")
state = {m: {"state": "RUNNING", "parts": 0} for m in MACHINES}
while True:
now = datetime.now(timezone.utc).isoformat(timespec="seconds")
for m in MACHINES:
s = state[m]
# Changements d'état aléatoires : surtout en marche, parfois à l'arrêt ou en attente
r = random.random()
new_state = "RUNNING" if r < 0.85 else ("IDLE" if r < 0.95 else "STOPPED")
if new_state != s["state"]:
s["state"] = new_state
client.publish(f"{BASE}/{m}/state",
json.dumps({"value": new_state, "ts": now}),
qos=1, retain=True)
if s["state"] == "RUNNING":
s["parts"] += 1
client.publish(f"{BASE}/{m}/parts",
json.dumps({"value": s["parts"], "ts": now}),
qos=1, retain=True)
amps = round(random.uniform(8, 12) if s["state"] == "RUNNING" else random.uniform(0.5, 2), 2)
client.publish(f"{BASE}/{m}/current",
json.dumps({"value": amps, "unit": "A", "ts": now}), qos=0)
time.sleep(5)
Observez le flux depuis un autre terminal avec le topic affiché par le script :
mosquitto_sub -h broker.connectmq.com -p 1883 -i poc-watch-$RANDOM \
-t 'connectmq/demo/<POC_ID>/plant1/cell3/#' -v
Le simulateur utilise la même structure de topics et le même format de payload que la vraie passerelle : état et compteur de pièces retenus, mesures de courant non retenues, horodatage ISO dans chaque message. Construisez votre tableau de bord sur cette base. Quand la passerelle est prête, basculez le tableau de bord et la passerelle vers votre broker privé avec TLS et les identifiants du portail. Le serveur MQTT public gratuit sert uniquement au développement, car n'importe qui peut le lire.
Qui fait quoi pendant les 30 jours
Une preuve de concept a besoin d'une petite équipe aux rôles clairs, pas d'un comité de pilotage. Trois ou quatre personnes suffisent généralement :
- Le sponsor, souvent le directeur d'usine ou de production, porte la question métier et prend la décision go ou no-go au jour 30.
- L'automaticien est responsable de tout ce qui se passe à la machine : quels tags ou capteurs lire, l'accès en lecture seule et la validation des valeurs par rapport à l'IHM.
- La personne IT ou data est responsable du chemin réseau, des identifiants du broker et du tableau de bord.
- L'utilisateur final, généralement un chef d'équipe ou un responsable maintenance, teste le tableau de bord chaque jour à partir de la semaine 3 et dit honnêtement s'il est utile.
Organisez un point de quinze minutes deux fois par semaine. Tout ce qui est bloqué plus de deux jours remonte directement au sponsor, car un plan de 30 jours n'a aucune marge pour attendre des validations.
Les pièges courants d'une preuve de concept
- Commencer par la machine la plus difficile. Commencez par une machine dotée d'une interface accessible et d'un responsable coopératif.
- Ne pas impliquer les opérateurs. S'ils n'ont pas participé au tableau de bord, ils ne l'utiliseront pas, et l'adoption est une métrique de réussite.
- Tout collecter. Deux mille tags ralentissent le pilote et rendent les enseignements plus difficiles à trouver. Commencez par les signaux qui répondent à votre question.
- Négliger les métriques ennuyeuses. La complétude des données et la latence sont ce que les équipes IT et OT demanderont avant de passer à l'échelle. Mesurez-les.
- Construire une infrastructure jetable. Un broker sur l'ordinateur portable de quelqu'un devra être reconstruit pour passer à l'échelle. Utilisez une solution capable de porter le déploiement en production.
De la preuve de concept au déploiement
Si le pilote réussit, la question suivante est la vitesse à laquelle vous pouvez ajouter des machines. Avec une hiérarchie de topics propre et un broker qui évolue selon l'offre, ajouter la dixième machine se fait comme ajouter la deuxième. ConnectMQ vous permet de démarrer avec l'offre Serverless gratuite (jusqu'à 25 connexions, QoS jusqu'à 1, messages de 256 Ko), qui couvre largement un pilote de 30 jours, puis de passer au Serverless payant avec QoS 2 et abonnements partagés ou à un cluster Dedicated à mesure que le déploiement grandit, sans changer les topics ni le code client. L'explorateur de topics en temps réel du portail, la vue des appareils ISA-95 et les règles d'alerte à seuil soutiennent directement les semaines 2 et 3. Pour la suite du parcours au-delà du pilote, lisez le guide de l'IoT industriel avec MQTT.
Lancez votre pilote de 30 jours sur ConnectMQ
Créez gratuitement un broker Serverless sur app.connectmq.com, sans carte bancaire. Exécutez le simulateur sur votre propre broker ConnectMQ dès le premier jour, construisez le tableau de bord pendant que le matériel est en commande et arrivez au jour 30 avec de vrais chiffres.
Questions fréquentes
Combien de temps doit durer une preuve de concept IIoT ?
Environ 30 jours est réaliste pour une à trois machines et une question ciblée. Les pilotes plus longs ont tendance à s'étendre sans aboutir à une décision.
Combien coûte une preuve de concept IIoT ?
Surtout du temps humain, plus une passerelle et éventuellement des capteurs. Une offre gratuite de broker MQTT managé et des outils open source comme Node-RED limitent le coût logiciel.
Combien de machines un pilote doit-il inclure ?
Une à trois, idéalement du même type. C'est suffisant pour prouver le chemin des données et la valeur sans transformer le pilote en déploiement.
Que se passe-t-il après une preuve de concept réussie ?
Utilisez l'effort documenté par machine et les métriques mesurées pour planifier un déploiement par phases. Conservez la même hiérarchie de topics et le même broker pour que le pilote devienne la première phase plutôt qu'un prototype jetable.
