Checklist de connectivité IIoT pour les ingénieurs d'usine

Cette checklist de connectivité IIoT rassemble les questions qui déterminent si un projet de connexion d'usine sera en service en une semaine ou s'enlisera pendant des mois. Parcourez-la avant l'arrivée de la première passerelle et vous saurez exactement quelles règles de pare-feu demander, quels protocoles convertir, comment nommer vos données et à quel broker vous connecter.

La checklist est organisée en six domaines. Chaque point est vérifiable, pas un vague principe, et plusieurs sont accompagnés d'une commande que vous pouvez exécuter dès aujourd'hui.

1. Périmètre et responsabilités

La plupart des projets enlisés échouent à cause des personnes, pas des paquets. Réglez ces points avant toute discussion matérielle.

1. Désignez un responsable côté OT et un côté IT, chacun habilité à approuver les changements dans son domaine.
2. Formulez le premier cas d'usage en une phrase, par exemple « afficher l'état en direct et le nombre de pièces des six machines CNC de la cellule 4 ».
3. Listez les machines concernées, leurs contrôleurs et leur emplacement physique.
4. Mettez-vous d'accord sur ce qui est hors périmètre pour la phase un. L'écriture dans les automates est ce que l'on reporte le plus souvent.
5. Définissez comment vous mesurerez le succès : latence des données, complétude, et utilisation effective des données par ceux qui les ont demandées.

Si ces réponses restent floues, notre plan de preuve de concept IIoT vous donne une structure sur 30 jours pour les préciser.

2. Checklist de l'accès réseau

Vos données ont besoin d'un chemin de la machine jusqu'au broker. Cartographiez-le saut par saut.

1. Identifiez la zone réseau de chaque machine et passerelle : réseau de cellule isolé, réseau OT de l'usine, DMZ ou réseau d'entreprise.
2. Confirmez si la passerelle se connectera directement à internet, via un broker en DMZ ou via un proxy. Notre guide sur le placement de MQTT dans une DMZ industrielle compare ces options.
3. Demandez l'ouverture en sortie du port TCP 8883 (MQTT sur TLS) vers le nom d'hôte du broker. Évitez le 1883 en clair à travers toute frontière de zone.
4. Si des navigateurs ou des tableaux de bord web ont besoin de données en direct, demandez aussi le port TCP 8084 (MQTT sur WebSocket sécurisé).
5. Confirmez la résolution DNS depuis le réseau de la passerelle.
6. Demandez si un proxy d'inspection TLS se trouve sur le chemin. Si oui, demandez une exception pour le nom d'hôte du broker.
7. Vérifiez le timeout d'inactivité du pare-feu et réglez le keepalive MQTT en dessous.
8. Confirmez que la passerelle peut joindre un serveur NTP. Une horloge erronée casse la validation TLS et les horodatages.

Vérifiez le chemin depuis la passerelle elle-même, pas depuis votre ordinateur portable. Les commandes ci-dessous visent le serveur MQTT public gratuit broker.connectmq.com, réservé aux tests ; remplacez-le ensuite par votre propre broker :

# Passerelle Linux : DNS, TCP et TLS en une fois
getent hosts broker.connectmq.com
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null \
  | grep -E "subject=|issuer=|Verify return code"

# Test MQTT de bout en bout avec un client ID et un topic uniques
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i gw-test-$RANDOM -t connectmq/demo/gw-test-$RANDOM/ping -m hello -d

Sur une passerelle ou un PC d'IHM sous Windows, l'équivalent rapide est :

powershell -Command "Test-NetConnection broker.connectmq.com -Port 8883"

Un Verify return code: 0 (ok) d'OpenSSL et un CONNACK (0) de mosquitto_pub -d signifient que la partie réseau est réglée.

3. Checklist des protocoles et sources de données

Vos machines parlent la langue avec laquelle elles ont été construites. Faites-en l'inventaire.

1. Consignez le protocole, l'adresse IP et le port ou les paramètres série de chaque source.
2. Confirmez qu'un accès en lecture seule est possible et obtenez l'accord écrit du responsable automatisme.
3. Exportez la liste des variables ou des registres et marquez celles dont vous avez réellement besoin. Vingt bonnes variables valent mieux que deux mille inutilisées.
4. Notez les limites d'interrogation. Certains contrôleurs anciens peinent lorsqu'on les interroge plus d'une fois par seconde.
5. Décidez si la passerelle utilisera MQTT simple avec du JSON ou Sparkplug B. Les deux fonctionnent ; les mélanger sans plan, non.

4. Checklist de la modélisation des données

Des données qui arrivent avec des noms cryptiques sont des données que personne n'utilise.

1. Choisissez une hiérarchie de topics, idéalement alignée sur ISA-95 : entreprise, site, zone, ligne, cellule, puis la machine.
2. Mettez les règles de nommage par écrit : minuscules, pas d'espaces, tirets ou underscores, unités cohérentes.
3. Définissez le format du payload, par exemple {"value": 72.4, "unit": "C", "ts": "2026-10-16T08:00:00Z"}.
4. Décidez quels topics sont retenus (état courant) et lesquels sont des événements (alarmes, fins de pièces).
5. Mettez-vous d'accord sur les règles de report by exception : quelle variation de valeur justifie un nouveau message.
6. Réservez une sous-arborescence distincte pour la santé des passerelles et des appareils : état en ligne, dernière activité, version du firmware.

Le guide des topics MQTT ISA-95 contient des exemples concrets que vous pouvez adapter. Un modèle de données propre dès la phase un est aussi ce qui permettra plus tard d'alimenter un jumeau numérique de l'usine.

5. Checklist de la sécurité

1. Chaque client s'authentifie avec son propre nom d'utilisateur et mot de passe. Aucun identifiant partagé entre passerelles.
2. TLS sur chaque connexion qui franchit une frontière de zone.
3. Les passerelles ne publient que vers le haut en phase un. Tout chemin de commande est explicitement conçu et revu.
4. Les identifiants sont stockés sur la passerelle dans un fichier protégé, et non codés en dur dans des scripts qui finissent dans le gestionnaire de versions.
5. Un message last will signale chaque passerelle hors ligne lorsqu'elle se déconnecte de façon inattendue.
6. Vous disposez d'une procédure pour révoquer un identifiant lorsqu'une passerelle est remplacée ou volée.
7. Rien de sensible n'est jamais publié sur un broker public, y compris le serveur MQTT public gratuit utilisé pour les tests ci-dessus.

Considérez ces points comme des minimums : une passerelle qui échoue à l'un d'eux ne doit pas être connectée, même pour un pilote.

6. Checklist du choix du broker

Le broker est le hub dont tout le reste dépend. Évaluez-le au regard des besoins de votre usine, pas seulement d'une liste de fonctionnalités.

1. Prend en charge MQTT 3.1.1 et 5.0, pour que les anciennes passerelles comme les clients modernes puissent se connecter.
2. Propose TLS sur le 8883 et le WebSocket sécurisé pour les tableaux de bord dans le navigateur.
3. Supporte votre nombre de connexions et vos tailles de messages, avec de la marge pour la croissance.
4. Prend en charge au minimum le QoS 1, et le QoS 2 si un consommateur a besoin d'une livraison exactement une fois.
5. Prend en charge les retained messages et les sessions persistantes pour que l'état survive aux reconnexions.
6. Comprend les payloads industriels comme Sparkplug B, ou au moins permet de les inspecter.
7. Vous donne de la visibilité : qui est connecté, quels topics sont actifs, et des alertes sur seuils.
8. Apporte une réponse claire à la question de savoir qui le met à jour et le supervise. Un broker auto-hébergé, c'est un serveur de plus à la charge de l'équipe OT.

Pour une comparaison plus approfondie, consultez comment choisir un broker MQTT pour l'IoT et notre guide sur le modèle du broker MQTT cloud. Pour voir comment toutes ces pièces s'assemblent dans une usine, lisez le guide de l'IoT industriel avec MQTT.

Comment ConnectMQ répond à la checklist

ConnectMQ est un broker MQTT managé, entièrement exploité pour vous et conçu en pensant aux connexions d'usine. Il prend en charge MQTT 3.1.1 et 5.0 sur TCP 1883, TLS 8883, WebSocket 8083 et WebSocket sécurisé 8084, utilise un certificat Let's Encrypt déjà reconnu par les magasins de certificats standard, et lie les client ID aux identifiants émis. Il détecte les topics ISA-95 et Unified Namespace, décode les payloads Sparkplug B et peut republier les données Sparkplug dans des topics ISA-95 lisibles. Le portail inclut un client MQTT dans le navigateur, un explorateur de topics en direct et des règles d'alerte à seuil, ce qui facilite la vérification des points des sections 4 et 6 pendant la mise en service.

Démarrer avec ConnectMQ

Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Vous aurez vos identifiants en quelques minutes : vous pourrez ainsi exécuter les tests réseau de la section 2 sur votre propre point de connexion ConnectMQ et cocher dès aujourd'hui la première moitié de cette checklist.

Questions fréquentes

Quels ports une passerelle IIoT doit-elle ouvrir pour joindre un broker MQTT ?

Généralement, uniquement le port TCP 8883 en sortie pour MQTT sur TLS. Ajoutez le TCP 8084 si des tableaux de bord dans le navigateur se connectent en WebSocket sécurisé. Aucun port entrant vers l'usine n'est nécessaire.

Qui doit piloter un projet de connectivité IIoT ?

L'OT et l'IT ensemble. Désignez un responsable de chaque côté habilité à approuver les changements, car la plupart des retards viennent d'approbations floues plutôt que de problèmes techniques.

Faut-il utiliser Sparkplug B ou JSON pour les données d'usine ?

Les deux fonctionnent. Sparkplug B ajoute un modèle strict de session et d'état que les outils SCADA comprennent, tandis que le JSON associé à une arborescence de topics ISA-95 est plus facile à lire et à intégrer. Choisissez l'un ou l'autre par source de données et documentez ce choix.

Comment tester la connectivité avant d'installer un logiciel de passerelle ?

Exécutez les tests DNS, OpenSSL et mosquitto_pub depuis une machine située dans la même zone réseau que la future passerelle. Si les trois réussissent sur le port 8883, le chemin réseau est prêt.