Si vous exploitez un environnement industriel, vous avez sans doute déjà déployé ou évalué une plateforme de sécurité OT-native comme Claroty, Dragos ou Nozomi. Vient alors la question : Cloudflare remplace-t-il cet outil, ou est-ce l'inverse qui rend Cloudflare superflu ? Ni l'un ni l'autre. Ce ne sont pas des produits concurrents : ils opèrent à des endroits différents et résolvent des problèmes différents.
Cloudflare et les plateformes OT-natives comme Claroty, Dragos ou Nozomi ne sont pas des alternatives l'une à l'autre. Les plateformes OT-natives travaillent à l'intérieur du réseau OT, où elles découvrent les actifs, inspectent les protocoles industriels et détectent les anomalies de procédé. Cloudflare travaille autour, à la frontière IT/OT, où il contrôle les accès, cloisonne les zones, filtre le trafic et absorbe les attaques réseau. Aucun ne fait le travail de l'autre, et un programme de sécurité OT complet utilise les deux.
Cet article met les deux couches côte à côte : ce que fait chacune, là où elles s'arrêtent, et comment elles s'articulent.
Note de transparence : Brixio est partenaire de service agréé Cloudflare (ASDP). Nous déployons la couche frontière Cloudflare et la faisons coexister avec la plateforme OT-native déjà en place chez le client. Notre intérêt, c'est que les deux couches travaillent ensemble, pas que l'une remplace votre outil de supervision. Le comparatif qui suit part de là et ne cherche aucunement à imposer Cloudflare à la place des outils OT.
Ce que font vraiment les plateformes OT-natives
Elles surveillent l'intérieur du réseau OT. Leur métier, c'est la visibilité : actifs, protocoles industriels, anomalies de procédé.
Ces plateformes se situent sous le pare-feu, au plus près des automates, là où tourne la production.
Elles découvrent et inventorient les actifs industriels (automates programmables, interfaces homme-machine, serveurs SCADA et le reste du parc installé), souvent sans balayage actif, car un sondage trop intrusif peut perturber des équipements fragiles. Elles inspectent en profondeur les protocoles industriels comme Modbus, DNP3 ou S7, que les outils informatiques classiques ne comprennent pas. À partir de cette ligne de base, elles détectent les anomalies de procédé et les menaces connues sur les systèmes de contrôle industriel (ICS), et alimentent la gestion des vulnérabilités du parc OT.
C'est une description de catégorie, pas un classement. Claroty, Dragos et Nozomi s'y prennent différemment, mais visent la même chose : savoir ce qui se trouve dans le réseau OT et repérer quand il se comporte anormalement. Ce qu'aucun d'eux n'est conçu pour faire, c'est sécuriser la façon dont les personnes et les systèmes se connectent à ce réseau depuis l'extérieur.
Ce que fait Cloudflare à la frontière IT/OT
Cloudflare intervient à l'autre bout du problème : la frontière où l'IT et l'OT se rejoignent désormais, et les connexions qui la traversent. Il ne regarde pas à l'intérieur du procédé OT ; il contrôle ce qui l'atteint.
Cinq fonctionnalités couvrent cette frontière.
- Cloudflare Access applique l'accès réseau Zero Trust (ZTNA) : il vérifie l'identité et la posture de l'appareil à chaque requête et donne accès à un système précis plutôt qu'au réseau entier, ce qui remplace la confiance large d'un VPN.
- Cloudflare WAN (anciennement Magic WAN) cloisonne les zones avec des réseaux virtuels qui isolent le routage, et filtre le trafic aux couches 3 et 4.
- Cloudflare Gateway filtre le trafic DNS, réseau et HTTP des systèmes adjacents à l'OT.
- Cloudflare Tunnel supprime l'exposition entrante en établissant une connexion sortante uniquement, sans adresse IP publique.
- Le pare-feu applicatif web (WAF) corrige virtuellement les interfaces exposées en bloquant les exploits connus en périphérie.
Au-delà de l'accès, Cloudflare Magic Transit absorbe les attaques DDoS volumétriques sur un réseau mondial dont la capacité dépasse 500 Tbit/s.
Le détail fonctionnalité par fonctionnalité est dans notre article compagnon sur les cinq fonctionnalités Cloudflare qui sécurisent la frontière IT/OT. Ce qui compte ici, c'est le positionnement : Cloudflare sécurise le réseau autour de l'environnement OT, pas le procédé à l'intérieur.
Le vide que chaque couche laisse
Énoncé simplement, chaque couche a un angle mort que l'autre comble.
Une plateforme OT-native ne sécurise pas la frontière. Elle n'offre pas :
- d'accès distant et tiers sécurisé
- de transport réseau entre sites
- de cloisonnement logiciel des zones et conduits
- d'absorption des attaques volumétriques par déni de service.
Ce sont des fonctions de frontière réseau.
Cloudflare, à l'inverse, ne voit pas l'intérieur du procédé OT. Il n'assure pas :
- l'inspection des protocoles OT
- la découverte et l'inventaire des actifs industriels
- la détection des anomalies de procédé sur une ligne de base OT.
Cela suppose des sondes à l'intérieur du réseau industriel.
La sécurité de la frontière réseau et la supervision OT-native couvrent deux surfaces différentes : l'une sécurise les connexions vers le réseau OT et autour de lui, l'autre voit les actifs et les procédés à l'intérieur. Aucune ne couvre les deux, et c'est pourquoi on les déploie ensemble plutôt que de choisir entre elles.
Frontière réseau et supervision OT-native, côte à côte
Sur chaque dimension, les deux couches se complètent : l'une voit l'intérieur du réseau, l'autre en sécurise le périmètre.
Le tableau ci-dessous oppose les deux couches sur le même jeu de dimensions. Il décrit des catégories, pas des produits précis, et s'appuie sur la documentation publiée par les éditeurs, la documentation officielle de Cloudflare et la norme IEC 62443.
| Dimension | Supervision OT-native | Frontière réseau Cloudflare |
|---|---|---|
| Où ça opère | À l'intérieur du réseau OT, sous le pare-feu | Autour du réseau OT, à la frontière IT/OT |
| Ce que ça voit | Actifs, protocoles industriels, comportement des procédés | Connexions, sessions et trafic en périphérie |
| Fonction principale | Découverte d'actifs, inventaire, détection de menaces ICS | ZTNA, cloisonnement, filtrage, correctif virtuel, protection DDoS |
| Mode de déploiement | Sondes passives ou actives (SPAN ou TAP) | Surcouche : sans agent en périphérie, plus un connecteur cloudflared |
| Touche aux équipements OT | Les supervise (lecture seule) | Non, il s'installe autour |
| Ce que ça ne fait pas | Accès sécurisé, transport, cloisonnement inter-zones, DDoS | Inventaire d'actifs, inspection des protocoles OT, détection ICS |
| Résultat principal | Visibilité et détection d'anomalies | Contrôle d'accès et réduction de l'exposition |
Vous ne savez pas où s'arrête votre outillage OT actuel et où commence la frontière réseau ? Brixio cartographie les deux couches sur votre environnement avant tout déploiement. → Réserver un diagnostic de sécurité de la frontière OT
Déjà équipé de Claroty, Dragos ou Nozomi ? Ajoutez Cloudflare en surcouche
Si une plateforme OT-native est déjà en place, Cloudflare ne la remplace pas. Il s'ajoute en surcouche autour des équipements existants, sans toucher aux automates et sans interrompre la production. La plateforme de supervision continue de faire ce qu'elle fait bien, voir à l'intérieur du réseau, pendant que Cloudflare verrouille les chemins d'accès et l'exposition à internet à la frontière. L'inverse vaut aussi : un site qui démarre avec Cloudflare à la frontière devra ajouter ensuite la visibilité interne.
Cela s'articule naturellement avec nos travaux sectoriels dans l'énergie et l'industrie manufacturière, où les sites convergents disposent souvent d'une supervision mais héritent d'une frontière réseau faible.
Conseil d'expert : commencez par cartographier ce que votre plateforme OT-native ne voit pas, l'accès distant des tiers, les flux inter-zones et l'exposition à internet. Cet angle mort est précisément le périmètre que la couche Cloudflare est là pour verrouiller.
Au regard de l'IEC 62443 : complémentaires, pas redondantes
Au regard de l'IEC 62443, les deux couches satisfont des exigences fondamentales différentes. La complémentarité tient aussi côté conformité.
L'IEC 62443 est la norme de référence en cybersécurité industrielle ; elle organise la sécurité autour d'un ensemble d'exigences fondamentales. Cloudflare adresse les exigences tournées vers la frontière : identification et authentification, contrôle de l'utilisation, restriction des flux de données, et disponibilité des ressources. Les exigences qui dépendent de la visibilité à l'intérieur du réseau OT, comme l'intégrité du système et la réponse aux événements, relèvent de la supervision OT-native.
Les deux couches correspondent donc à des exigences différentes de la même norme, soit la même complémentarité vue du côté conformité. La correspondance détaillée, exigence par exigence, entre Cloudflare et l'IEC 62443 est exposée dans notre guide de conformité IEC 62443, et l'architecture d'ensemble dans notre solution de sécurité de la convergence IT/OT. Le reste de la série pose le contexte : la différence entre sécurité IT et OT, la façon dont le Zero Trust modernise le modèle Purdue, et ce que les données de menace 2026 révèlent sur la concentration du risque.
Comment Brixio intègre les deux couches
Brixio déploie la couche Cloudflare en surcouche et la fait fonctionner avec votre plateforme OT existante, sans toucher aux automates.
En tant que partenaire de service agréé Cloudflare (ASDP), Brixio intègre la couche frontière Cloudflare et la fait coexister avec la plateforme OT-native que le client exploite déjà. Le travail se déroule en trois phases :
- Audit et découverte : cartographie du Shadow IT, des appareils non gérés et des flux de trafic réels.
- Architecture et déploiement : ajout des contrôles de frontière en surcouche, sans perturber les automates.
- Exploitation continue : ajustement des règles à mesure que l'environnement et la réglementation comme NIS2 évoluent.
L'objectif n'est pas de tout standardiser sur un seul fournisseur. C'est de garantir que la couche frontière et la couche de supervision couvrent ensemble tout l'environnement, sans laisser de vide ni faire double emploi. Pour les organisations qui veulent d'abord mesurer cet écart, Brixio réalise un diagnostic de sécurité IT/OT avant tout déploiement.
PREUVE TERRAIN
Ce que ça donne en production, chez nos clients.
Sur deux aéroports, le VPN donnait d'emblée accès à tout le réseau. Frontière reprise en main par un accès Zero Trust, en surcouche.
Quatre entités, autant de frontières à tenir. Une couche d'accès unifiée posée par-dessus, sans remplacer l'existant.
Une infrastructure critique à protéger côté exposé, pas côté OT. Sécurité applicative ajoutée à la frontière, en complément des outils en place.
Questions fréquentes
Oui. Votre plateforme OT-native voit l'intérieur du réseau, mais elle ne sécurise pas l'accès distant, le transport ni l'exposition à internet à la frontière. Cloudflare ajoute cette couche en surcouche, sans remplacer la plateforme que vous exploitez déjà.
Non. Les deux opèrent à des endroits différents, autour du réseau d'un côté, à l'intérieur de l'autre, et couvrent des fonctions différentes. Aucun ne fait le travail de l'autre : on les déploie ensemble plutôt que de choisir entre eux.
Cloudflare couvre les exigences de frontière (authentification, contrôle de l'utilisation, restriction des flux de données et disponibilité), tandis que les exigences qui dépendent de la visibilité interne (intégrité du système, réponse aux événements) restent du ressort de la supervision OT-native. La correspondance complète, exigence par exigence, est dans notre guide de conformité IEC 62443.
Non. Cloudflare sécurise la frontière réseau ; il ne découvre pas les actifs industriels et n'inspecte pas les protocoles OT. Un programme de sécurité OT complet combine la couche frontière et la supervision interne.
Sécuriser les deux couches de votre environnement OT
Brixio cartographie votre supervision actuelle et votre frontière réseau, identifie l'écart entre les deux, et conçoit la couche de contrôle avant tout déploiement.
CTA primaire : Réserver un diagnostic de sécurité de la frontière OT
CTA secondaire : Voir notre méthodologie de déploiement IT/OT
