Si vous sécurisez un réseau industriel, le modèle de Purdue est sans doute votre carte de référence : les automates en bas, la supervision au milieu, la bureautique en haut, une DMZ pour séparer le tout. Ce découpage est la grammaire commune de la cybersécurité industrielle, et il a structuré aussi bien la doctrine du cloisonnement que les chantiers de mise en conformité. Le schéma n'a pas vieilli. C'est l'usine autour qui a changé.
Le modèle de Purdue suppose un monde hiérarchique et cloisonné, où les flux montent et descendent sagement entre niveaux voisins et où un pare-feu central suffit à tenir la frontière entre informatique de gestion et informatique industrielle. Ce monde a disparu. Les capteurs et passerelles de l'IIoT (Internet industriel des objets) remontent leurs données directement vers le cloud, la télémaintenance ouvre des accès depuis l'extérieur, et la frontière censée tout filtrer est devenue un point de passage que personne ne contrôle vraiment.
Le modèle de Purdue reste valide comme cartographie des niveaux et des zones. Ce qui a cédé, c'est l'hypothèse de départ : une confiance accordée par défaut à l'intérieur de chaque zone, et une frontière unique au Niveau 3.5. Le Zero Trust modernise les conduits entre zones sans remettre en cause le modèle.
L'enjeu n'est donc pas de remplacer Purdue, mais de le remettre au goût du jour. Voici où il tient encore, où il lâche, et comment une approche Zero Trust en modernise les zones et les conduits sans rien démonter.
Le modèle de Purdue et ses hypothèses d'origine
Le modèle de Purdue, ou Purdue Enterprise Reference Architecture (PERA), est né de travaux de l'université Purdue avant d'irriguer la norme ISA-95 sur l'intégration des systèmes de gestion et de conduite. Il découpe l'installation industrielle en niveaux superposés :
- Niveau 0, le procédé : capteurs et actionneurs au contact du monde physique.
- Niveau 1, la commande : automates programmables et postes de télégestion (RTU) qui pilotent le procédé.
- Niveau 2, la supervision : systèmes SCADA et interfaces homme-machine (IHM) sous les yeux des opérateurs.
- Niveau 3, la conduite de site : systèmes d'exécution de la fabrication (MES), serveurs d'historisation, gestion d'atelier.
- Niveau 3.5, la DMZ industrielle : la zone tampon entre l'OT et l'IT.
- Niveaux 4 et 5, l'informatique d'entreprise : ERP, messagerie, le système d'information de gestion.
Tout le modèle repose sur quelques postulats hérités des années 90. Le réseau industriel est isolé, voire physiquement coupé (air gap). Les échanges sont verticaux et prévisibles. À l'intérieur d'un même niveau, les équipements se font confiance sans contrôle. Et l'unique passage entre l'OT et l'IT transite par la DMZ du Niveau 3.5, où l'ANSSI recommande de longue date de concentrer le cloisonnement et la défense en profondeur.
Ces postulats ont tenu deux décennies. Aucun ne résiste à la réalité d'aujourd'hui.
Où le modèle de Purdue lâche
Le modèle ne s'est pas trompé : ce sont ses conditions d'emploi qui ont disparu. Quatre points de rupture reviennent sur le terrain.
La télémaintenance rouvre la frontière. C'est le talon d'Achille le plus courant. Pour intervenir sur un automate, un intégrateur ou un équipementier ouvre un accès distant, le plus souvent via un VPN qui dépose l'utilisateur sur le réseau. Résultat : un accès large au lieu d'un accès à la machine concernée, et autant de postes de prestataires qui deviennent des portes d'entrée. Or un accès réseau large, c'est exactement ce dont a besoin un attaquant pour se propager.
L'IIoT court-circuite la hiérarchie. Capteurs connectés, passerelles de télémétrie, maintenance prédictive : ces équipements parlent directement à une plateforme cloud. Leur trafic ne gravit pas les niveaux et ne passe pas par la DMZ. Il sort par le bas, sans rien demander à la frontière du 3.5, qui ne le voit jamais.
Le pare-feu du Niveau 3.5 est aveugle aux flux internes. Une DMZ filtre les flux Nord-Sud, entre l'IT et l'OT. Elle ne dit presque rien des flux Est-Ouest à l'intérieur d'une zone, ni des connexions cloud qui traversent désormais le périmètre. Le point de contrôle existe toujours, mais il a cessé de voir l'essentiel du trafic.
La confiance interne reste uniforme. Une fois passé la frontière, tout équipement d'une zone est réputé de confiance. Rien n'arrête alors le déplacement latéral, cette progression de proche en proche d'une machine compromise vers la suivante. Purdue protège les frontières entre niveaux, jamais l'espace à l'intérieur.
Rien de tout cela ne disqualifie la défense en profondeur. Cela montre simplement qu'il faut un modèle de confiance qui accompagne le trafic, et pas seulement un périmètre figé. Sur la dissolution du périmètre par la convergence, voir notre solution de sécurité de la convergence IT/OT.
Le Zero Trust ne remplace pas Purdue, il en modernise les conduits
Lire « Purdue est dépassé » comme « il faut tout jeter » serait une erreur. Les niveaux restent une bonne grille de lecture de l'usine, et le couple zones/conduits, ces regroupements d'actifs et les chemins maîtrisés qui les relient, demeure le bon vocabulaire. Ce qui doit changer, c'est la confiance accordée à l'intérieur des zones et entre elles.
Le Zero Trust substitue à cette confiance implicite une vérification à chaque requête : quelle identité, sur quel équipement, dans quel état de conformité, contrôlés à chaque connexion et non une seule fois à l'entrée. Transposé au modèle de Purdue, le principe garde la structure et réécrit les conduits :
- Les zones restent des regroupements d'actifs, mais la confiance n'y est plus uniforme. Chaque flux est vérifié pour lui-même. C'est tout l'objet de la micro-segmentation : non plus un VLAN par zone, mais un chemin contrôlé par flux autorisé.
- Les conduits ne sont plus du câblage ou des VLAN figés mais des politiques logicielles. Un conduit se définit par qui a le droit de joindre quoi, et s'applique partout où passe le trafic, pas uniquement sur la DMZ.
La frontière de l'exercice doit rester nette. Le Zero Trust agit sur les conduits et sur la frontière IT-OT. Il ne modifie pas la topologie physique des niveaux 0 à 2 et ne touche pas aux automates. Ce vocabulaire de zones et de conduits n'a d'ailleurs rien d'arbitraire : c'est celui que formalise la norme de cybersécurité industrielle IEC 62443, dont nous mappons les exigences fondamentales sur une architecture Cloudflare dans un article dédié.
Moderniser la segmentation OT avec Cloudflare
Cette couche Zero Trust n'a rien de théorique : ce sont des briques qui se posent en surcouche (overlay) autour du réseau existant. Trois d'entre elles portent l'essentiel de la modernisation d'une segmentation de type Purdue.
Des conduits définis en logiciel. Cloudflare WAN (ex-Magic WAN) isole le trafic entre environnements grâce à des réseaux virtuels. Un conduit devient une règle de routage et non un câble : le cloisonnement attendu par le modèle de Purdue se pilote en logiciel et se modifie sans rien recâbler dans l'atelier.
Un accès distant sans déplacement latéral. Cloudflare Access applique le Zero Trust Network Access (ZTNA). Là où un VPN raccorde le prestataire à l'ensemble du réseau, Access n'ouvre l'accès qu'à une machine précise, en SSH, VNC ou RDP, après vérification de l'identité et de l'état du poste à chaque connexion. La télémaintenance ne débouche plus sur le réseau, donc plus de surface à parcourir latéralement.
La micro-segmentation. Chaque flux étant vérifié individuellement, le confinement devient logique plutôt que physique. Une machine compromise dans une zone n'hérite plus d'une liberté de circulation : elle se heurte à un contrôle de politique à chaque conduit. C'est la réponse concrète à la confiance uniforme que Purdue laisse béante.
Pour le détail brique par brique, Gateway, Tunnel et WAF compris, voir notre décryptage de comment Cloudflare sécurise la frontière IT/OT, fonctionnalité par fonctionnalité.
Le Zero Trust modernise le modèle de Purdue en faisant de ses zones des réseaux virtuels et de ses conduits des politiques vérifiées à chaque requête : le cloisonnement devient piloté par l'identité et l'état de l'équipement, sans jamais toucher aux automates des niveaux 0 à 2.
Le modèle de Purdue modernisé : une architecture de référence
Il ne s'agit pas de redessiner l'usine, mais de garder les niveaux de Purdue intacts et de poser une couche de confiance sur les conduits qui les relient. Le tableau ci-dessous met chaque élément du modèle en regard de sa limite actuelle et de la façon dont le Zero Trust le modernise.
| Élément du modèle de Purdue | Limite aujourd'hui | Modernisation Zero Trust | Brique Cloudflare |
|---|---|---|---|
| Zones (groupes d'actifs) | Confiance uniforme dans la zone | Micro-segmentation, vérification par requête | Cloudflare WAN (réseaux virtuels) |
| Conduits (chemins entre zones) | Câblage ou VLAN figés | Conduits définis en politique logicielle | Cloudflare WAN et politiques |
| Frontière Niveau 3.5 (DMZ) | Aveugle aux flux IIoT et Est-Ouest | Frontière vérifiée, flux IIoT repris sous politique | Tunnel (sortant) et Gateway |
| Accès distant / télémaintenance (VPN) | Accès réseau large, propice au déplacement latéral | Accès au moindre privilège à une machine précise | Cloudflare Access (ZTNA) |
| Niveaux physiques 0 à 2 (automates, capteurs) | Inchangés | Hors frontière réseau (supervision OT-native) | Non couvert |
Conseil d'expert : sur une installation existante, profitez de la cartographie pour modéliser chaque conduit comme un réseau virtuel plutôt que comme une règle de pare-feu de plus. Vous modifiez alors le cloisonnement en éditant une politique logicielle, sans intervenir physiquement sur le réseau. Et votre cartographie reste à jour quand l'installation évolue, au lieu de devoir la reconstituer en relisant la configuration de chaque commutateur.
Ce que le Zero Trust ne fait pas
Être précis sur la portée d'une couche réseau, c'est aussi être précis sur ce qu'elle ne touche pas.
Les niveaux physiques restent physiques. Les capteurs, les automates et les boucles de régulation des niveaux 0 à 2 ne sont pas modifiés par une couche réseau. Cloudflare protège les conduits et la frontière ; il ne s'exécute pas sur l'automate et ne touche pas au câblage du procédé.
La visibilité à l'intérieur d'une zone relève d'un autre métier. Inspecter les protocoles industriels comme Modbus, DNP3 ou S7, dresser l'inventaire des actifs, détecter une anomalie sur le procédé lui-même : tout cela suppose de voir dans le réseau OT, pas seulement à sa lisière. C'est le terrain des plateformes de supervision OT-natives, qui travaillent à côté de la couche frontière. La répartition des rôles fait l'objet de notre comparaison entre Cloudflare et les éditeurs OT natifs.
Comment Brixio modernise la segmentation Purdue sans interruption
Partenaire certifié Cloudflare (ASDP), Brixio installe la couche de cloisonnement en surcouche : elle enveloppe l'existant sans modifier les automates ni arrêter la production. La démarche tient en quatre temps :
- Audit et cartographie : relever les zones, conduits et flux réels, y compris les remontées IIoT et les accès de télémaintenance que la documentation passe sous silence.
- Architecture : traduire les zones et conduits de Purdue en politiques Cloudflare, pour un cloisonnement appliqué en logiciel et non déduit du matériel.
- Documentation et mapping : produire la cartographie de cloisonnement sur laquelle un audit ou une revue NIS2 peut s'appuyer.
- Maintien en condition de sécurité : garder les politiques à jour à mesure que l'installation et la menace évoluent.
La limite reste affichée d'un bout à l'autre. Brixio modernise la couche réseau et la frontière ; les niveaux physiques et la supervision interne aux zones restent du ressort des équipes OT et des outils OT-natifs. Le sujet concerne d'abord les secteurs régulés et fortement équipés, au premier rang desquels l'industrie et l'énergie, et s'inscrit dans notre solution de sécurité de la convergence IT/OT. Il prolonge le reste de la série : pourquoi la sécurité IT et la sécurité OT suivent des règles opposées, et ce que les données de menace 2026 révèlent sur la concentration du risque.
PREUVE TERRAIN
Ce que ça donne en production, chez nos clients.
Sur deux aéroports, un seul VPN ouvrait l'accès à tout le réseau. Place à une segmentation par identité : chaque flux vérifié à chaque connexion.
Quatre entités, quatre réseaux où franchir l'entrée suffisait à tout atteindre. Recloisonnés en zones distinctes, avec des règles d'accès à la place des portes ouvertes.
Infrastructure portuaire critique exposée, sans coupure possible. Frontière cloisonnée et filtrée par étapes, sans rien changer aux opérations.
Questions fréquentes
Oui, comme cartographie des niveaux et des zones. Ce qui a vieilli, c'est la confiance accordée par défaut à l'intérieur des zones et l'idée d'une frontière unique au Niveau 3.5. La bonne approche est de moderniser le modèle avec une couche de confiance fondée sur la vérification, pas de l'abandonner.
Non. Il en modernise les conduits : vérification de chaque requête et micro-segmentation. Les niveaux et les zones de Purdue restent la structure de référence pour décrire et organiser l'installation.
Le Niveau 3.5 est une frontière unique, la DMZ industrielle, qui sépare l'IT de l'OT en un seul point. Le Zero Trust cloisonne chaque flux individuellement par micro-segmentation et supprime la confiance uniforme qui règne dans une zone une fois la frontière franchie.
Oui. La couche Zero Trust se pose en surcouche, réseaux virtuels et ZTNA, autour du réseau existant. Elle ne demande pas de toucher aux automates et n'interrompt pas le procédé.
Modernisez votre segmentation OT
Si votre cloisonnement repose encore sur un périmètre unique et des VLAN figés, le premier geste est de cartographier vos zones et conduits réels, puis de repérer où une couche Zero Trust les modernise sans toucher à vos automates. C'est exactement ce que nous vous aidons à faire. Cartographier votre segmentation IT/OT avec Brixio.
