Modèle de Purdue vs ISA-95 : c'est l'une des sources de confusion les plus fréquentes en architecture industrielle, car les deux utilisent des niveaux numérotés de 0 à 4 et se représentent sous forme de couches empilées. Dans ce comparatif, vous verrez pour quoi chaque modèle a été conçu, comment leurs niveaux se correspondent, où ils diffèrent réellement et comment MQTT et un Unified Namespace changent la circulation des données entre niveaux sans renoncer au zonage de sécurité qu'apportent les réseaux de type Purdue.
L'origine de chaque modèle
La Purdue Enterprise Reference Architecture a été développée à l'université Purdue au début des années 1990 comme modèle général pour la production intégrée par ordinateur. Dans le monde de la sécurité industrielle, elle est devenue un raccourci pour désigner une architecture réseau en couches : le procédé physique en bas, l'IT d'entreprise en haut, et des frontières contrôlées entre les deux. Elle sert largement de référence dans les programmes de sécurité OT et a influencé l'approche par zones et conduits de l'ISA/IEC 62443.
L'ISA-95, également publiée sous la référence IEC 62264, est une norme d'intégration. Son objet est de définir comment les systèmes de gestion comme l'ERP et les systèmes de gestion des opérations de production comme le MES échangent des informations : plannings de production, consommation de matières, capacités des équipements, résultats qualité. Elle fournit des modèles d'objets, des modèles d'activités et une hiérarchie fonctionnelle, et elle définit également la hiérarchie des équipements basée sur les rôles : entreprise, site, zone, centre de travail et unité de travail.
En bref : Purdue sert surtout à répondre à la question « comment segmenter les réseaux ? », tandis que l'ISA-95 répond à la question « quelles fonctions existent à chaque niveau, et quelles informations circulent entre la gestion et l'exploitation ? ».
La correspondance des niveaux
Les numéros de niveaux concordent suffisamment pour être utiles, et assez vaguement pour susciter des débats.
| Niveau | Modèle de Purdue (vue réseau) | Hiérarchie fonctionnelle ISA-95 | Systèmes typiques |
|---|---|---|---|
| 5 | Réseau d'entreprise | Non défini séparément | IT d'entreprise, services exposés à Internet |
| 4 | Logistique de l'entreprise | Planification et logistique de l'entreprise | ERP, planification, messagerie |
| 3.5 | DMZ industrielle | Non défini | Serveurs de rebond, serveurs de correctifs, brokers de données |
| 3 | Opérations du site | Gestion des opérations de production | MES, historian, serveurs SCADA du site |
| 2 | Supervision de zone | Supervision et contrôle-commande | IHM, clients SCADA, stations d'ingénierie |
| 1 | Contrôle de base | Mesure et action | PLC, contrôleurs DCS, RTU |
| 0 | Procédé physique | Le procédé physique | Capteurs, actionneurs, variateurs |
Trois différences ressortent :
- Le niveau 3.5 est un concept Purdue. L'ISA-95 n'a pas de DMZ, car elle ne modélise pas les réseaux. Les spécialistes de la sécurité ont ajouté la DMZ industrielle entre les opérations du site et les réseaux d'entreprise pour empêcher tout trafic direct entre IT et OT.
- Le niveau 5 apparaît dans de nombreux schémas Purdue comme un étage distinct d'entreprise ou d'Internet. L'ISA-95 s'arrête au niveau 4.
- L'apport principal de l'ISA-95 est l'interface entre les niveaux 3 et 4, que les schémas Purdue traitent comme une simple frontière de pare-feu.
Modèle de Purdue vs ISA-95 : les différences clés
| Aspect | Modèle de Purdue | ISA-95 |
|---|---|---|
| Nature | Architecture de référence | Norme internationale (IEC 62264) |
| Préoccupation principale aujourd'hui | Segmentation réseau et sécurité | Intégration des systèmes et modèles d'information |
| Définit des modèles de données | Non | Oui, pour la production, la qualité, la maintenance, les stocks |
| Définit une hiérarchie d'équipements | Non | Oui, de l'entreprise à l'unité de travail |
| Définit une DMZ | Oui, généralement au niveau 3.5 | Non |
| Public type | Sécurité OT, ingénieurs réseau | Architectes MES, intégrateurs, exploitation |
| Pertinence pour la conception de topics MQTT | Indirecte, via l'emplacement des brokers | Directe, via la hiérarchie des équipements |
La conséquence pratique : pour concevoir des topics MQTT, utilisez la hiérarchie des équipements ISA-95, que notre guide sur la hiérarchie des équipements ISA-95 explique. Pour décider où tourne le broker et quelles connexions les pare-feu autorisent, raisonnez en zones Purdue.
Comment MQTT aplatit la communication entre niveaux
Dans une usine classique de type Purdue, les données remontent les niveaux un saut à la fois. Un PLC est interrogé par le SCADA au niveau 2, le SCADA alimente l'historian au niveau 3, l'historian est répliqué à travers la DMZ, et l'ERP finit par voir une synthèse. Chaque saut est une intégration point à point avec son propre protocole, son propre mapping et ses propres modes de défaillance.
Une architecture publish/subscribe change la circulation des données. Avec un broker MQTT servant de Unified Namespace, tout producteur autorisé publie une fois et tout consommateur autorisé s'abonne directement. Le MES, l'historian, un tableau de bord et un job d'analytique cloud lisent tous la même télémétrie de la remplisseuse sur le même topic. C'est ce que l'on veut dire quand on affirme que MQTT « aplatit la pyramide ».
Il importe d'être précis sur ce qui est aplati. L'architecture de l'information devient plate : un seul namespace au lieu d'une chaîne de copies. L'architecture réseau, elle, n'a pas à l'être : les zones, les pare-feu et la DMZ existent toujours. MQTT aide ici, car les clients ouvrent toujours des connexions sortantes vers le broker. Une passerelle au niveau 2 peut publier vers un broker situé dans la DMZ ou dans le cloud sans qu'aucun port entrant ne soit ouvert vers le réseau de contrôle-commande.
Où placer le broker
| Emplacement | Fonctionnement | Points d'attention |
|---|---|---|
| Broker de site au niveau 3 | Les passerelles publient à l'intérieur du site ; un bridge ou un consommateur relaie vers le haut | Les données restent locales ; vous exploitez le serveur |
| Broker en DMZ au niveau 3.5 | Les clients OT se connectent en sortant vers la DMZ ; les clients IT se connectent par le haut | Frontière claire ; aucun côté ne se connecte dans la zone de l'autre |
| Broker cloud | Les passerelles edge se connectent en sortant via TLS vers un broker MQTT managé | Aucun serveur à exploiter ; nécessite un accès Internet sortant depuis une zone contrôlée |
| Hybride | Broker de site pour les consommateurs locaux, broker cloud pour l'entreprise et le multisite | Plus de composants, meilleures résilience et portée |
Notre article MQTT dans la DMZ détaille la conception de la DMZ, règles de pare-feu comprises. Si vous choisissez un broker MQTT cloud, un broker MQTT managé comme ConnectMQ gère la partie serveur, et votre pare-feu n'a qu'à autoriser le TLS sortant depuis la zone de la passerelle.
Tester un chemin sortant depuis une zone OT
Avant de vous engager sur un emplacement, vérifiez qu'une passerelle située dans la zone prévue peut joindre le broker sur le bon port et que TLS est validé. Ces commandes peuvent être lancées sans risque depuis une passerelle Linux ou un serveur de rebond ; elles utilisent le serveur MQTT public gratuit, ne publiez donc rien de sensible :
# 1. Le TLS sortant sur 8883 est-il autorisé et le certificat est-il validé ?
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null 2>/dev/null | grep -E "Verify return code|subject="
# 2. Publier un message de test retenu via TLS
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-pub-j2 -r -t "connectmq/demo/j2v6/zone-test/level2-gateway" -m "reachable"
# 3. Le relire depuis une autre zone
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-sub-j2 -t "connectmq/demo/j2v6/zone-test/#" -v -C 1
Une ligne Verify return code: 0 (ok) confirme que la chaîne de certificats est approuvée. Si l'étape 1 reste bloquée, un pare-feu filtre le port 8883 ; si les WebSockets sont la seule option, le port 8084 avec le chemin /mqtt constitue une alternative. Le serveur MQTT public gratuit convient à ce test de connectivité ; le trafic de production doit passer par un broker privé avec identifiants.
La sécurité reste essentielle
Un namespace plat rend les données faciles d'accès : l'authentification et le moindre privilège comptent donc davantage, pas moins.
- Uniquement en sortie. Les passerelles se connectent vers le broker ; n'ouvrez jamais de ports entrants vers les niveaux 0 à 2.
- TLS partout. Port 8883 pour MQTT sur TLS, 8084 pour les WebSockets sécurisés.
- Une identité par client. Délivrez des identifiants par passerelle et par application, afin de pouvoir les révoquer indépendamment. Sur ConnectMQ, les client IDs sont liés aux identifiants délivrés.
- Séparer les chemins de lecture et d'écriture pour le pilotage. Traitez les topics de commande comme à haut risque et gardez le contrôle en boucle fermée sur le réseau de contrôle-commande local.
- Surveiller les connexions. Repérez les clients inattendus et les échecs de connexion. ConnectMQ bloque les IP après des échecs de connexion répétés et applique une protection contre le flood par tenant.
La relation entre les deux modèles s'inscrit dans le débat plus large sur la convergence IT/OT, et notre guide MQTT pour l'IoT industriel montre comment ces éléments s'intègrent dans une architecture d'usine complète.
Reliez vos niveaux avec ConnectMQ
Conserver des zones de type Purdue tout en aplatissant les flux de données exige un broker que chaque zone peut joindre en TLS sortant. ConnectMQ est un broker MQTT managé avec TLS sur le port 8883, WebSockets sécurisés sur le port 8084, identifiants par client et une vue des appareils ISA-95, disponible en déploiement mutualisé, Dedicated ou BYOC. Démarrez avec l'offre gratuite Serverless sur app.connectmq.com, sans carte bancaire.
Questions fréquentes
Le modèle de Purdue est-il obsolète ?
Son flux de données strictement saut par saut est remplacé par des architectures publish/subscribe, mais son idée centrale, segmenter les réseaux en zones avec des frontières contrôlées, reste au cœur de la sécurité OT.
L'ISA-95 définit-elle la sécurité réseau ?
Non. L'ISA-95 définit des fonctions, des modèles d'information et la hiérarchie des équipements. La sécurité des réseaux et des systèmes d'automatisation industrielle relève de la série ISA/IEC 62443.
Quel modèle utiliser pour la conception des topics MQTT ?
Utilisez la hiérarchie des équipements ISA-95 pour les topics, et les zones de type Purdue pour décider où tourne le broker et quelles connexions sortantes sont autorisées.
Un Unified Namespace remet-il en cause le modèle de Purdue ?
Il change la circulation des données, pas nécessairement la segmentation réseau. Avec des connexions MQTT uniquement sortantes et un broker dans la DMZ ou dans le cloud, les zones et les pare-feu restent en place.
