Le mur invisible entre la production et l’informatique
Dans une ETI industrielle typique, deux mondes coexistent sans se comprendre. D’un côté, l’équipe automatisme gère des automates Siemens ou Rockwell, câblés en Profinet ou EtherNet/IP, avec des cycles de rafraîchissement à la milliseconde. De l’autre, la DSI administre un ERP SAP ou Sage, des flux REST, des serveurs Windows, et raisonne en disponibilité de service. Ces deux mondes parlent des langages réseau différents, obéissent à des contraintes temporelles incompatibles, et pourtant l’industrie 4.0 exige qu’ils échangent des données en continu.
Le modèle Purdue — formalisé par l’ISA-95 (aujourd’hui IEC 62264) — est le cadre qui structure cette cohabitation. Ce n’est pas un standard académique déconnecté du terrain : c’est la grille de lecture utilisée par les intégrateurs, les architectes réseau industriels, et les responsables cybersécurité OT pour décider où passe chaque câble, chaque flux, chaque pare-feu.
Cet article décompose le modèle couche par couche, avec les protocoles réels à chaque niveau, les architectures de déploiement concrètes, et la question que tout le monde pose en 2026 : où brancher l’IA dans cette pile.
1. Le modèle Purdue / ISA-95 — les six niveaux
Le Purdue Enterprise Reference Architecture (PERA) découpe le système d’information industriel en six niveaux, du capteur physique au cloud. Chaque niveau a ses propres contraintes de latence, de sécurité et de protocole.
Niveau 0 — Le monde physique (capteurs et actionneurs)
C’est le point de contact avec la réalité. Les capteurs mesurent (température, pression, vibration, position, débit), les actionneurs agissent (vannes, moteurs, vérins). La communication est souvent analogique (boucle 4-20 mA, signaux 0-10 V) ou numérique bas niveau.
Protocoles et interfaces :
| Interface | Type | Caractéristique |
|---|---|---|
| 4-20 mA | Analogique | Immunité au bruit, câblage 2 fils, standard depuis 50 ans |
| 0-10 V | Analogique | Simple mais sensible aux longueurs de câble |
| IO-Link | Numérique point-à-point | Jusqu’à 230,4 kbps, câble non blindé 20 m max |
| HART | Hybride (analogique + numérique superposé) | Compatible 4-20 mA existant, diagnostic enrichi |
| AS-Interface (ASi) | Bus terrain binaire | 62 esclaves, 100 m, profil sécurité SIL 3 |
Le niveau 0 ne connaît pas TCP/IP. Toute tentative d’y connecter un équipement Ethernet directement est une erreur d’architecture. Les capteurs IO-Link communiquent via un maître IO-Link, qui lui-même est raccordé au niveau 1.
Contraintes temps réel : Les cycles de rafraîchissement sont de l’ordre de 1 à 10 ms pour les entrées rapides (encodeurs, capteurs de position), 100 ms à 1 s pour les capteurs process (température, pression).
Niveau 1 — Contrôle de base (automates PLC/DCS)
Les automates programmables industriels (PLC) et les systèmes de contrôle distribués (DCS) exécutent la logique de commande. Ils lisent les entrées du niveau 0, appliquent le programme automate, et pilotent les sorties. Un PLC Siemens S7-1500 ou un Rockwell ControlLogix tourne avec un temps de cycle de 1 à 50 ms selon la complexité du programme.
Protocoles réseau :
| Protocole | Constructeur | Couche OSI | Cycle typique | Particularité |
|---|---|---|---|---|
| Profinet IRT | Siemens | 2 (Ethernet modifié) | 250 µs | Isochrone, déterministe, réservation de bande |
| Profinet RT | Siemens | 2-3 | 1-10 ms | Temps réel souple, cohabite avec TCP/IP |
| EtherNet/IP | Rockwell, ODVA | 4-7 (TCP/UDP) | 1-100 ms | CIP sur TCP/UDP standard |
| EtherCAT | Beckhoff | 2 | 100 µs | Trame Ethernet traversante, pas de switch |
| Modbus TCP | Schneider (ouvert) | 4-7 (TCP) | 10-100 ms | Simple, universel, pas de sécurité native |
| POWERLINK | B&R | 2 | 200 µs | Ethernet temps réel, cycle maître/esclave |
| SERCOS III | Bosch Rexroth | 2 | 62,5 µs | Motion control, synchronisation multi-axes |
La règle fondamentale du niveau 1 : le déterminisme prime sur le débit. Un automate qui rate un cycle à cause d’une collision réseau peut provoquer un arrêt machine, voire un accident. C’est pourquoi les protocoles de niveau 1 utilisent des mécanismes qui garantissent la livraison dans un temps borné — soit en modifiant Ethernet (Profinet IRT, EtherCAT), soit en réservant des slots temporels.
Architecture typique : Un réseau Profinet de niveau 1 est physiquement séparé du réseau bureautique. Il utilise ses propres switches industriels (Scalance chez Siemens, Stratix chez Rockwell), souvent en topologie anneau avec temps de basculement < 50 ms (MRP ou HSR).
Niveau 2 — Supervision et contrôle de zone (SCADA, HMI, Historian)
Le niveau 2 concentre les outils de visualisation et d’archivage. L’opérateur surveille le process via des interfaces HMI (écrans tactiles sur machine) et des systèmes SCADA (supervision multi-sites). L’Historian enregistre toutes les variables process à haute fréquence pour l’analyse ultérieure.
Composants typiques :
- HMI : Siemens Comfort Panel, Rockwell PanelView, Schneider Magelis
- SCADA : Ignition (Inductive Automation), WinCC (Siemens), FactoryTalk View (Rockwell), AVEVA System Platform
- Historian : OSIsoft PI (aujourd’hui AVEVA PI), InfluxDB, TimescaleDB, Ignition Tag Historian
Protocoles :
| Protocole | Usage | Caractéristique |
|---|---|---|
| OPC-UA | Communication SCADA ↔ PLC, inter-systèmes | Sécurisé (certificats X.509), modèle d’information riche, pub/sub disponible |
| OPC-DA/HDA | Legacy SCADA ↔ PLC | COM/DCOM Windows, pas de sécurité, en voie de remplacement |
| SQL (ODBC/JDBC) | Historian ↔ applications | Requêtes sur données archivées |
| Modbus TCP | SCADA ↔ équipements simples | Polling cyclique, pas d’événementiel |
OPC-UA est le pivot du niveau 2 en 2026. Son modèle d’information permet de structurer les données machine de manière sémantique (pas juste des registres numérotés comme en Modbus), et sa couche de sécurité (authentification par certificats, chiffrement AES-256) en fait le seul protocole OT nativement compatible avec les exigences de cybersécurité modernes.
L’Historian est le point d’entrée naturel pour l’IA. C’est ici que les données de process sont déjà numériques, horodatées, et stockées dans un format interrogeable. Un modèle de maintenance prédictive ne lit jamais directement un automate — il interroge l’Historian.
Niveau 3 — Gestion des opérations (MES, MOM)
Le Manufacturing Execution System (MES) — ou Manufacturing Operations Management (MOM) dans la terminologie ISA-95 — orchestre la production. Il gère les ordres de fabrication, la traçabilité produit, la qualité, les flux matières, et le suivi des performances (OEE/TRS).
Systèmes typiques :
- MES : AVEVA MES, Siemens Opcenter, Rockwell Plex, Wonderware
- Quality Management : InfinityQS, QAD CEBOS
- Scheduling : Preactor, Asprova, Siemens Opcenter APS
Protocoles et interfaces :
| Interface | Direction | Protocole |
|---|---|---|
| MES → PLC | Descendant (ordres de fab, recettes) | OPC-UA, API propriétaire |
| MES → ERP | Ascendant (consommations, productions) | REST API, SOAP, fichiers plats (IDocs SAP) |
| MES → Historian | Lateral | SQL, OPC-UA HDA |
| MES → Edge/IA | Lateral | MQTT, REST API, OPC-UA pub/sub |
Le niveau 3 est la couche d’intégration critique — c’est le traducteur entre le monde temps réel (niveaux 0-2) et le monde transactionnel (niveau 4). Toute donnée qui monte vers l’ERP ou le cloud transite par ici, contextualisée (numéro d’OF, référence produit, poste de charge).
MQTT au niveau 3 : Le protocole MQTT s’est imposé comme le standard de fait pour la communication événementielle entre les équipements de niveau 2-3 et les plateformes d’analyse. Léger (overhead minimal), pub/sub (découplage producteur/consommateur), QoS configurable (0 = fire-and-forget, 1 = at least once, 2 = exactly once).
Niveau 4 — Planification et logistique (ERP, SI entreprise)
Le système d’information de gestion. L’ERP (SAP, Oracle, Microsoft Dynamics, Sage X3) gère la planification, les achats, la finance, les RH. Il ne connaît pas les capteurs — il raisonne en ordres de fabrication, en nomenclatures, en délais.
Protocoles :
| Interface | Protocole | Exemple |
|---|---|---|
| ERP → MES | REST API, SOAP, IDocs | SAP PP → Opcenter via RFC/BAPI |
| ERP → fournisseurs | EDI (EDIFACT, X12) | Commandes, avis d’expédition |
| ERP → BI | SQL, ODBC | Extraction vers Power BI, Qlik |
| ERP → portail | REST/GraphQL | Interface web clients/fournisseurs |
Contraintes : Le niveau 4 fonctionne en temps transactionnel (secondes à minutes). Un mouvement de stock SAP prend 200-500 ms. Ce n’est pas un problème — personne n’attend du temps réel d’un ERP. Mais cette latence explique pourquoi connecter directement un ERP à un automate est une aberration architecturale : les temporalités sont incompatibles d’un facteur 1 000.
Niveau 5 — Cloud, IA, analytics
Le niveau le plus récent dans le modèle. Il n’existait pas dans la version originale de Purdue (1990). Il recouvre les services cloud, les plateformes de data science, les datalakes, et les applications d’intelligence artificielle.
Services typiques :
- Plateformes IoT : Azure IoT Hub, AWS IoT Core, Siemens MindSphere, PTC ThingWorx
- Data Lake : Databricks, Snowflake, Azure Data Lake
- ML/AI : MLflow, Vertex AI, SageMaker, modèles on-premise
- Monitoring : Grafana Cloud, Datadog, New Relic
Protocoles :
| Protocole | Usage | Sécurité |
|---|---|---|
| HTTPS/REST | API cloud, dashboards | TLS 1.3, OAuth2 |
| gRPC | Communication inter-services haute performance | TLS, HTTP/2 |
| MQTT over TLS | Remontée de données IoT | TLS 1.3, certificats clients |
| WebSocket | Streaming temps réel vers dashboards | TLS, tokens |
| AMQP | Message queuing (Azure Service Bus, RabbitMQ) | TLS, SASL |
2. La DMZ IT/OT — le point névralgique
La zone démilitarisée entre les niveaux 3 et 4 est l’endroit le plus critique de l’architecture. C’est le mur entre le monde OT (où une intrusion peut arrêter une production ou blesser quelqu’un) et le monde IT (où une intrusion vole des données ou chiffre des fichiers).
Pourquoi c’est le point critique
Les attaques ciblant les systèmes industriels ne cessent d’augmenter. Depuis Stuxnet (2010), les incidents se multiplient : WannaCry a paralysé Renault en 2017 (le réseau OT non segmenté a été contaminé par le réseau bureautique), TRITON a visé les Safety Instrumented Systems d’une raffinerie en 2017, et Colonial Pipeline (2021) a montré qu’un ransomware sur le SI de gestion peut arrêter toute une production même sans toucher les automates.
La DMZ IT/OT n’est pas un luxe de grande entreprise — c’est une nécessité pour toute ETI connectée.
Architecture concrète
flowchart TB
subgraph IT["Réseau IT (Niveau 4-5)"]
style IT fill:#2C3E42,color:#fff
ERP["ERP / BI / Cloud"]
FW_IT["Pare-feu IT (L7)"]
end
subgraph DMZ["DMZ IT/OT"]
style DMZ fill:#E99971,color:#000
PROXY["Proxy OPC-UA / Broker MQTT"]
JUMP["Jump Server (accès maintenance)"]
DIODE["Diode de données (sens unique OT→IT)"]
SIEM["Collecteur SIEM / Sonde IDS"]
end
subgraph OT["Réseau OT (Niveau 0-3)"]
style OT fill:#7DB5A5,color:#000
FW_OT["Pare-feu OT (L3/L4)"]
MES["MES / SCADA / Historian"]
PLC["Automates / HMI"]
end
ERP --> FW_IT --> PROXY
PROXY --> FW_OT --> MES
MES --> PLC
DIODE --> FW_IT
MES -.-> DIODE
JUMP --> FW_OT
SIEM -.-> FW_ITComposants de la DMZ
Pare-feu OT (L3/L4) : Filtre par IP source/destination et port. Autorise uniquement les flux nécessaires (OPC-UA sur port 4840, MQTT sur 8883). Exemples : Fortinet FortiGate Rugged, Palo Alto PA-220R, Cisco ISA-3000.
Pare-feu IT (L7) : Inspection applicative. Peut décoder le protocole OPC-UA et n’autoriser que certaines opérations (lecture seule, pas d’écriture sur les variables automate depuis l’IT). Deep Packet Inspection sur le contenu des trames.
Diode de données : Composant matériel qui garantit physiquement que les données ne peuvent circuler que dans un sens (OT → IT). Aucune possibilité de retour, même en cas de compromission du côté IT. Utilisé pour les données d’archivage Historian vers le datalake. Exemples : Waterfall Security, Owl Cyber Defense, Fox-IT.
Proxy OPC-UA : Serveur intermédiaire qui expose un sous-ensemble contrôlé des données OT au monde IT. L’IT ne voit jamais directement le serveur OPC-UA de l’automate. Le proxy peut appliquer des règles de filtrage, de rate limiting, et d’anonymisation.
Jump Server : Point d’accès unique pour la maintenance à distance des systèmes OT. Authentification forte (MFA), session enregistrée, accès temporaire. Jamais d’accès VPN direct vers le réseau OT.
Sonde IDS/SIEM : Capture passive du trafic réseau OT (port mirroring) pour détecter les comportements anormaux. Solutions spécialisées : Claroty, Nozomi Networks, Dragos.
3. Protocoles par niveau — tableau comparatif
| Protocole | Niveau Purdue | Couche OSI | Débit typique | Latence | Sécurité native | Usage principal |
|---|---|---|---|---|---|---|
| 4-20 mA / HART | 0 | 1 (physique) | 1,2 kbps (HART) | N/A | Aucune | Capteurs analogiques, process continu |
| IO-Link | 0-1 | 1-2 | 230 kbps | < 2 ms | Aucune (point-à-point) | Capteurs intelligents, paramétrage |
| Profinet IRT | 1 | 2 | 100 Mbps | 250 µs | Aucune (réseau fermé) | Motion control, synchronisation |
| EtherCAT | 1 | 2 | 100 Mbps | 100 µs | Aucune (réseau fermé) | Axes rapides, packaging |
| EtherNet/IP | 1-2 | 4-7 | 100 Mbps - 1 Gbps | 1-10 ms | CIP Security (TLS optionnel) | Contrôle Rockwell, intégration |
| Modbus TCP | 1-2 | 4-7 | 10 Mbps | 10-100 ms | Aucune | Legacy, équipements simples |
| OPC-UA | 2-3 | 4-7 | Mbps à Gbps | 10-100 ms | Certificats X.509, AES-256 | Interopérabilité, MES, SCADA |
| MQTT | 2-3-5 | 7 | Variable | 50-500 ms | TLS 1.3, auth utilisateur | IoT, événementiel, edge→cloud |
| REST/HTTPS | 3-4-5 | 7 | Variable | 50-2000 ms | TLS 1.3, OAuth2, JWT | API MES, ERP, cloud |
| gRPC | 4-5 | 7 | Haute (HTTP/2, binaire) | 10-100 ms | TLS 1.3, mTLS | Microservices, ML serving |
| AMQP | 4-5 | 7 | Variable | 10-200 ms | TLS, SASL | Message queuing, intégration |
| SAP RFC/BAPI | 4 | 7 | Variable | 200-1000 ms | SNC (Secure Network Comm.) | Intégration SAP spécifique |
Règle de conception
Plus on descend dans les niveaux, plus la latence doit être faible et le déterminisme élevé. Plus on monte, plus la sécurité (chiffrement, authentification) devient prioritaire. Il n’existe pas de protocole universel qui couvre tous les niveaux — c’est précisément pourquoi le modèle Purdue existe.
4. Où brancher l’IA — la règle d’or
La règle : jamais directement aux automates
Un modèle d’IA — qu’il s’agisse d’un algorithme de maintenance prédictive, d’un optimiseur de paramètres process, ou d’un système de détection d’anomalies — ne doit jamais communiquer directement avec un automate PLC de niveau 1. Jamais.
Pourquoi :
-
Déterminisme. Un automate exécute son programme en boucle avec un temps de cycle garanti. Toute communication externe non déterministe (appel REST, inférence ML avec latence variable) peut perturber le cycle et provoquer un arrêt de sécurité.
-
Sécurité fonctionnelle. Les systèmes de niveau 1 sont souvent certifiés SIL (Safety Integrity Level). Connecter un composant non certifié (un modèle ML) en écriture sur ces systèmes invalide la certification.
-
Surface d’attaque. Chaque connexion réseau vers un automate est un vecteur d’attaque potentiel. Un modèle ML compromis qui a accès en écriture à un PLC peut provoquer des dommages physiques.
-
Cycle de vie. Un modèle ML est mis à jour fréquemment (retraining, A/B testing). Un programme automate est figé et validé par l’automaticien. Mélanger ces deux cycles de vie crée un cauchemar de validation.
Où brancher, alors ?
L’IA se connecte aux niveaux 3 et 4 :
flowchart LR
subgraph N01["Niveaux 0-1 (OT temps réel)"]
style N01 fill:#2C3E42,color:#fff
PLC["Automates PLC"]
end
subgraph N2["Niveau 2 (Supervision)"]
style N2 fill:#7DB5A5,color:#000
HIST["Historian / SCADA"]
end
subgraph N3["Niveau 3 (MES)"]
style N3 fill:#7DB5A5,color:#000
MES["MES / Edge Gateway"]
end
subgraph N45["Niveaux 4-5 (IT/Cloud)"]
style N45 fill:#2C3E42,color:#fff
IA["Modèle IA / ML"]
DASH["Dashboard / Alertes"]
end
PLC -->|"données process"| HIST
HIST -->|"OPC-UA / SQL"| MES
MES -->|"MQTT / REST"| IA
IA -->|"recommandation"| DASH
IA -.->|"consigne validée par opérateur"| MES
MES -.->|"écriture OPC-UA (après validation)"| PLCLe chemin normal : Les données remontent (PLC → Historian → MES → IA). L’IA produit une recommandation. Cette recommandation est affichée à l’opérateur (dashboard) ou injectée dans le MES comme consigne. Si une écriture vers l’automate est nécessaire, elle passe par le MES et est validée par un humain ou par un mécanisme de sécurité fonctionnelle (bornes, rate limiting, validation de cohérence).
Exceptions encadrées
Il existe des cas où l’IA opère plus près du terrain :
-
Edge AI sur gateway industrielle. Un modèle de détection d’anomalies embarqué sur un edge gateway (Siemens IPC, Advantech, Nvidia Jetson) peut lire les données en temps réel via OPC-UA et générer des alertes locales. Mais il n’écrit jamais sur l’automate.
-
Contrôle avancé (APC). Les systèmes de contrôle avancé (Model Predictive Control) existent depuis 30 ans en process continu (chimie, raffinerie). Ils sont intégrés au niveau 2 et certifiés comme composants de contrôle. Ce n’est pas du ML au sens moderne — c’est du contrôle optimal avec des modèles physiques.
-
Vision industrielle en ligne. Une caméra avec un modèle de classification (défaut/conforme) peut communiquer directement avec l’automate via un signal TOR (tout ou rien). Mais c’est un signal binaire validé, pas un modèle complexe qui écrit des paramètres.
5. Architectures concrètes de déploiement
Architecture A — Full on-premise (données sensibles)
Pour les industries avec des contraintes de souveraineté (défense, nucléaire, pharma) ou des données hautement confidentielles (recettes de fabrication, paramètres propriétaires).
flowchart TB
subgraph SITE["Site industriel — réseau privé"]
style SITE fill:#2C3E42,color:#fff
subgraph OT_ZONE["Zone OT"]
style OT_ZONE fill:#7DB5A5,color:#000
CAP["Capteurs / PLC"]
SCADA["SCADA + Historian"]
end
subgraph DMZ_ZONE["DMZ"]
style DMZ_ZONE fill:#E99971,color:#000
PROXY_A["Proxy OPC-UA"]
FW["Firewall L7"]
end
subgraph IT_ZONE["Zone IT (on-prem)"]
style IT_ZONE fill:#2C3E42,color:#fff
TSDB["TimescaleDB / InfluxDB"]
ML["Serveur ML (GPU on-prem)"]
DASH_A["Grafana / Dashboard"]
ERP_A["ERP"]
end
end
CAP --> SCADA
SCADA --> PROXY_A
PROXY_A --> FW
FW --> TSDB
TSDB --> ML
ML --> DASH_A
ERP_A --> FWAvantages : Contrôle total des données, pas de dépendance internet, latence minimale pour l’inférence.
Inconvénients : Coût hardware (serveurs GPU), maintenance de l’infrastructure ML à charge interne, pas de scalabilité élastique.
Quand choisir : Industrie de défense, pharma (GxP), données client ultra-sensibles, sites sans connectivité fiable.
Architecture B — Hybride edge + cloud
L’architecture la plus courante en 2026 pour les ETI industrielles. Le traitement temps réel reste en local (edge), l’entraînement des modèles et l’analyse historique vont dans le cloud.
flowchart TB
subgraph SITE_B["Site industriel"]
style SITE_B fill:#2C3E42,color:#fff
subgraph OT_B["Zone OT"]
style OT_B fill:#7DB5A5,color:#000
CAP_B["Capteurs / PLC"]
SCADA_B["SCADA + Historian"]
end
subgraph EDGE["Edge Layer"]
style EDGE fill:#7DB5A5,color:#000
GW["Edge Gateway (Jetson / IPC)"]
BROKER["Broker MQTT local"]
end
end
subgraph CLOUD["Cloud (Azure / AWS)"]
style CLOUD fill:#2C3E42,color:#fff
IOT["IoT Hub / IoT Core"]
LAKE["Data Lake"]
TRAIN["ML Training (GPU cloud)"]
SERVE["ML Serving (API)"]
DASH_B["Dashboard cloud"]
end
CAP_B --> SCADA_B
SCADA_B --> GW
GW -->|"inférence locale (anomalies)"| BROKER
GW -->|"MQTT over TLS"| IOT
IOT --> LAKE
LAKE --> TRAIN
TRAIN -->|"modèle mis à jour"| GW
SERVE --> DASH_B
BROKER -->|"alertes locales"| SCADA_BAvantages : Inférence locale rapide (< 100 ms), entraînement scalable dans le cloud, mise à jour OTA des modèles, coût optimisé.
Inconvénients : Complexité de gestion (deux environnements), dépendance au cloud pour le retraining, nécessite une connectivité minimale.
Quand choisir : ETI manufacturière classique, maintenance prédictive, optimisation process, multi-sites.
Architecture C — Full cloud (données non-sensibles)
Pour les cas où les données ne sont pas critiques et où la latence n’est pas une contrainte (rapports, planification, analytics historiques).
flowchart TB
subgraph SITE_C["Site industriel"]
style SITE_C fill:#2C3E42,color:#fff
CAP_C["Capteurs / PLC"]
SCADA_C["SCADA + Historian"]
AGENT["Agent collecteur (Telegraf / Kepware)"]
end
subgraph CLOUD_C["Cloud"]
style CLOUD_C fill:#7DB5A5,color:#000
IOT_C["Plateforme IoT"]
STREAM["Stream Processing (Kafka / Kinesis)"]
STORE["Data Warehouse"]
ML_C["ML Pipeline (Vertex AI / SageMaker)"]
APP["Applications (dashboards, alertes, rapports)"]
end
CAP_C --> SCADA_C
SCADA_C --> AGENT
AGENT -->|"HTTPS / MQTT TLS"| IOT_C
IOT_C --> STREAM
STREAM --> STORE
STORE --> ML_C
ML_C --> APPAvantages : Zéro infrastructure ML à maintenir, scalabilité infinie, services managés.
Inconvénients : Latence élevée (200 ms à 2 s), dépendance internet, coûts récurrents cloud, données hors du périmètre physique.
Quand choisir : Analytics pur (pas d’action en temps réel), rapports de performance, benchmarking multi-sites, données non-confidentielles.
6. Exemple concret : pipeline vibration → maintenance prédictive
Prenons un cas réel — la surveillance vibratoire d’un moteur de broyeur dans une cimenterie. L’objectif : détecter un désalignement ou un roulement défaillant 2 à 4 semaines avant la panne.
Composants du pipeline
| Composant | Niveau Purdue | Rôle | Produit exemple |
|---|---|---|---|
| Accéléromètre triaxial | 0 | Mesure vibration 0-10 kHz, 25,6 kS/s | IFM VVB001, SKF CMSS 2200 |
| Maître IO-Link | 0-1 | Agrégation capteurs, conversion Ethernet | IFM AL1350 |
| PLC (rack E/S déportées) | 1 | Collecte cyclique, stockage tampon | Siemens ET 200SP |
| Edge Gateway | 2-3 | Pré-traitement FFT, extraction features, inférence locale | Siemens IPC227E, Advantech UNO-2484G |
| Broker MQTT | 3 | Routage événements vers cloud et local | Mosquitto, HiveMQ |
| TimescaleDB | 3-4 | Stockage time-series haute résolution | TimescaleDB sur PostgreSQL |
| ML Pipeline | 4-5 | Entraînement modèle (Isolation Forest + LSTM) | MLflow + Python |
| API d’inférence | 4 | Serving du modèle, prédiction temps réel | FastAPI + ONNX Runtime |
| Dashboard + alertes | 4-5 | Visualisation tendances, notification maintenance | Grafana + PagerDuty |
Flux de données détaillé
-
Acquisition (Niveau 0). L’accéléromètre mesure les vibrations sur trois axes à 25 600 échantillons/seconde. Signal brut analogique converti en numérique par le capteur IO-Link.
-
Collecte (Niveau 1). Le maître IO-Link agrège les données et les transmet au PLC via Profinet. Le PLC stocke un buffer circulaire de 1 seconde de signal brut.
-
Pré-traitement edge (Niveau 2-3). L’edge gateway récupère le buffer toutes les secondes via OPC-UA, calcule une FFT (Fast Fourier Transform), extrait les features spectrales (RMS, kurtosis, crest factor, fréquences caractéristiques des roulements : BPFO, BPFI, BSF, FTF), et publie un message MQTT contenant le vecteur de features (environ 40 valeurs).
-
Stockage (Niveau 3-4). TimescaleDB ingère le vecteur de features via un consumer MQTT. Rétention : 2 ans en résolution 1s, 10 ans en résolution 1 min (agrégation continue).
-
Inférence (Niveau 4). Toutes les 10 secondes, le modèle Isolation Forest évalue le vecteur de features et produit un score d’anomalie. Si le score dépasse le seuil pendant 5 minutes consécutives, un LSTM prend le relais pour estimer le RUL (Remaining Useful Life).
-
Alerte (Niveau 4-5). Si le RUL estimé passe sous 14 jours, une alerte est générée dans Grafana et un ticket est créé dans la GMAO. Le responsable maintenance reçoit une notification avec le diagnostic probable (désalignement, roulement interne, balourd).
Performance du pipeline
| Métrique | Valeur |
|---|---|
| Latence capteur → alerte | < 30 secondes |
| Faux positifs | < 2 % (après 6 mois de tuning) |
| Détection anticipée | 14-28 jours avant panne |
| Coût d’un arrêt non planifié broyeur | 15 000 - 50 000 EUR/jour |
| Coût du pipeline complet (matériel + setup) | 8 000 - 15 000 EUR |
| ROI typique | < 6 mois sur un équipement critique |
7. Sécurité réseau industrielle
Segmentation — la première ligne de défense
La segmentation réseau est le fondement de la sécurité OT. Le principe : chaque niveau Purdue est un segment réseau distinct, avec des règles de pare-feu explicites entre chaque segment. Aucun flux n’est autorisé par défaut.
VLAN par niveau :
| VLAN | Niveau Purdue | Plage IP (exemple) | Accès autorisé |
|---|---|---|---|
| 10 | 1 — Automates | 10.1.10.0/24 | → VLAN 20 uniquement (OPC-UA) |
| 20 | 2 — SCADA/HMI | 10.1.20.0/24 | → VLAN 10, 30 |
| 30 | 3 — MES | 10.1.30.0/24 | → VLAN 20, DMZ |
| 50 | DMZ | 10.1.50.0/24 | → VLAN 30, 100 (unidirectionnel) |
| 100 | 4 — IT/ERP | 10.1.100.0/24 | → DMZ, Internet |
Règles de pare-feu — principe du moindre privilège
# Exemple de règles FW entre VLAN 10 (PLC) et VLAN 20 (SCADA)
ALLOW VLAN20 → VLAN10 : TCP/4840 (OPC-UA) — lecture seule
ALLOW VLAN20 → VLAN10 : UDP/34964 (Profinet DCP) — discovery
DENY VLAN10 → VLAN20 : ALL — les automates n'initient pas de connexion
DENY ANY → VLAN10 : ALL — règle par défautLes automates ne doivent jamais initier de connexion sortante. Si un automate tente de contacter une IP externe, c’est un indicateur de compromission (IoC) qui doit déclencher une alerte immédiate.
Certificats OPC-UA
OPC-UA supporte nativement l’authentification par certificats X.509. En production :
- Chaque serveur OPC-UA (PLC, SCADA) possède son propre certificat signé par une CA interne.
- Chaque client (MES, Historian, edge gateway) possède son certificat.
- Trust list : seuls les certificats explicitement approuvés peuvent communiquer. Pas de trust automatique.
- Chiffrement : AES-256-CBC ou AES-128-CBC sur toutes les sessions. Le mode
None(pas de chiffrement) doit être désactivé en production. - Rotation : certificats renouvelés annuellement. Révocation via CRL distribuée.
TLS partout au-dessus du niveau 2
À partir du niveau 3, tout flux non chiffré est une vulnérabilité :
- MQTT : toujours sur port 8883 (MQTT over TLS), jamais sur 1883 (non chiffré)
- REST API : HTTPS exclusivement, certificats Let’s Encrypt ou CA interne
- Base de données : connexions TLS obligatoires (PostgreSQL
sslmode=require) - gRPC : mTLS (mutual TLS) entre microservices
Audit trail et détection d’intrusion
Logging centralisé : Tous les équipements réseau (switches, pare-feu, proxies) envoient leurs logs vers un SIEM centralisé via syslog over TLS. Conservation minimum : 12 mois (recommandation ANSSI pour les OIV/OSE).
Détection d’anomalies réseau : Les sondes IDS spécialisées OT (Claroty, Nozomi, Dragos) apprennent le comportement normal du réseau (quels équipements communiquent entre eux, sur quels ports, avec quel volume) et alertent sur toute déviation. Un nouveau flux réseau entre un automate et une IP inconnue est une alerte critique.
Mise à jour et patching : Les équipements OT ne sont pas patchés comme des serveurs IT. Un patch sur un PLC nécessite un arrêt de production et une revalidation. La stratégie est de compenser par la segmentation et la surveillance plutôt que par le patching systématique.
8. Checklist architecte réseau industriel
Pour conclure, voici les questions qu’un architecte réseau industriel doit se poser à chaque nouveau projet :
| Question | Bonne réponse | Signal d’alarme |
|---|---|---|
| Les niveaux 0-1 sont-ils sur un réseau physiquement séparé ? | Oui, VLAN dédié + switch industriel | ”On utilise le même switch que la bureautique” |
| Existe-t-il une DMZ entre OT et IT ? | Oui, avec pare-feu L7 + diode | ”Le MES accède directement à Internet” |
| Les flux OPC-UA sont-ils chiffrés ? | Oui, certificats X.509, mode None désactivé | ”On a laissé en mode None pour le debug” |
| L’IA écrit-elle directement sur les automates ? | Non, toujours via MES avec validation | ”Le modèle ML envoie des consignes au PLC en REST” |
| Les accès de maintenance passent-ils par un jump server ? | Oui, MFA + session enregistrée | ”Le fournisseur a un VPN direct vers le réseau automate” |
| Existe-t-il une cartographie réseau à jour ? | Oui, revue trimestrielle | ”On ne sait pas exactement ce qui est connecté” |
| Les logs réseau OT sont-ils collectés et analysés ? | Oui, SIEM + IDS spécialisé OT | ”On n’a pas de visibilité sur le trafic OT” |
| Le réseau OT a-t-il accès à Internet ? | Non, jamais directement | ”Les HMI ont accès au web pour les mises à jour” |
Synthèse
Le modèle Purdue n’est pas un cadre théorique poussiéreux — c’est la colonne vertébrale de toute architecture réseau industrielle sérieuse. En 2026, avec la convergence IT/OT et l’arrivée massive de l’IA dans les usines, comprendre ces six niveaux est devenu une compétence fondamentale pour tout DSI, responsable automatisme ou architecte réseau.
L’erreur la plus fréquente est de traiter le réseau industriel comme un réseau IT classique. Ce n’est pas le cas. Les contraintes de déterminisme, de sécurité fonctionnelle, et de cycle de vie sont radicalement différentes. Le modèle Purdue fournit le vocabulaire et la structure pour concevoir des architectures qui respectent ces contraintes tout en permettant l’innovation — à condition de respecter les frontières entre niveaux et de ne jamais prendre de raccourcis sur la DMZ.