Une sonde OT ne voit que le trafic qu'on lui copie. Avant de parler d'alertes, l'ingénieur détection OT choisit les points de copie avec l'équipe réseau et les automaticiens : ports miroirs sur les switchs d'atelier, TAP là où la copie doit être fiable. Il installe les sondes, laisse la phase d'apprentissage bâtir une baseline des échanges habituels, puis règle les alertes avant de les envoyer au SIEM. Les questions d'entretien gagnent à suivre ces trois étapes.
Beaucoup de CV citent Claroty ou Nozomi après une démonstration. L'expérience réelle se reconnaît quand la personne explique pourquoi l'inventaire d'un site restait incomplet, comment un automate mal identifié a été corrigé, ou ce qu'elle a fait d'une alerte de modification de programme qui sonnait à chaque passage de la maintenance. Un profil passé par un SOC sait aussi ce qu'un analyste attend d'une alerte reçue la nuit.
Un automaticien ou le responsable de la sécurité industrielle participe à l'entretien quand c'est possible : il repère vite un candidat qui n'a jamais travaillé à côté d'une ligne en marche. Le principe des outils se ressemble d'un éditeur à l'autre, et une personne formée sur Nozomi Guardian prend en main Claroty sans repartir de zéro. Le PDF propose 30 questions sur six axes et un cas de déploiement sur trois ateliers.
Sondes, protocoles et intégrations d'un ingénieur détection OT
Claroty xDome et CTD
xDome est la plateforme de Claroty livrée en SaaS, avec des collecteurs posés sur site. CTD (Continuous Threat Detection) reste proposé pour les installations gérées entièrement sur place. Les deux combinent écoute passive, requêtes ciblées sur les équipements (Safe Queries) et analyse des fichiers de projet des automates. La personne doit dire lequel elle a déployé et dans quels cas elle a activé les requêtes.
Nozomi Networks Guardian
La sonde réseau de Nozomi Networks, branchée sur un port miroir ou un TAP. Elle apprend les échanges normaux du site, puis signale les écarts et les menaces connues. Les sondes remontent vers Vantage en SaaS ou vers la Central Management Console sur site, et Arc ajoute une collecte sur les postes. Mitsubishi Electric a finalisé le rachat de Nozomi Networks en janvier 2026.
Armis
Une plateforme d'inventaire venue de l'IT et de l'IoT, étendue à l'OT. Elle croise l'écoute du trafic avec les données déjà présentes dans le SI : switchs, pare-feu, outils de gestion des postes. ServiceNow a finalisé son rachat en avril 2026, et la plateforme Armis Centrix reste vendue seule. Les offres françaises l'associent souvent à ServiceNow, pour alimenter la CMDB et le traitement des incidents de sécurité.
Microsoft Defender for IoT
Des capteurs OT installés sur site, gérés depuis le portail Azure ou, en préversion, depuis le portail Microsoft Defender. La version 26.1 du capteur, sortie en 2026, passe sur Debian 12. La console de gestion sur site n'est plus téléchargeable depuis le 1er janvier 2025, un point à vérifier chez les candidats qui l'ont connue. Il intéresse surtout les équipes déjà sous Sentinel ou Defender XDR.
Ports miroirs (SPAN) et TAP
Les deux façons de copier le trafic vers une sonde. Le SPAN se configure sur un switch existant mais peut perdre des paquets quand le port est saturé. Le TAP est un boîtier passif plus fiable, qu'on pose en coupant le lien, donc pendant un arrêt planifié. Le choix entre les deux dit beaucoup de l'expérience de terrain.
Protocoles industriels
Modbus TCP, S7comm, Profinet, EtherNet/IP (CIP), OPC UA, DNP3 ou IEC 60870-5-104 selon les sites. La sonde décode les commandes, et l'ingénieur doit savoir distinguer une lecture de variables d'une écriture, d'un téléchargement de programme ou d'un passage de l'automate en STOP. Sans cette lecture, il ne peut ni régler une alerte ni l'expliquer au SOC.
SIEM, SOAR et CMDB
Les alertes partent vers Splunk, Microsoft Sentinel, QRadar ou un autre SIEM, en syslog au format CEF ou par le connecteur de l'éditeur. L'inventaire peut alimenter une CMDB comme ServiceNow. Une intégration réussie envoie peu d'alertes, mais chacune arrive avec le nom de l'équipement, sa zone et sa criticité.
Modèle de Purdue et IEC 62443
Le modèle de Purdue découpe le site en niveaux, des capteurs et automates jusqu'au SI de gestion. L'IEC 62443 raisonne en zones et en conduits. L'ingénieur détection s'en sert pour placer ses sondes, rattacher chaque équipement à une zone et repérer les flux qui sautent un niveau.
Le poste se publie sous plusieurs intitulés : ingénieur cybersécurité OT, ingénieur intégration de solutions de sécurité OT, consultant Nozomi ou Claroty, parfois ingénieur SOC OT. Chez un intégrateur, la personne pose des sondes sur de nombreux sites et passe d'un éditeur à l'autre. Dans un groupe industriel, elle tient un parc de sondes sur la durée, gère les exceptions et répond aux demandes du SOC. Les éditeurs ont leurs propres certifications, et la GICSP ou les formations ISA/IEC 62443 couvrent le socle industriel. Certains postes demandent une habilitation, à signaler dès l'annonce.
Les points à contrôler chez un ingénieur détection OT
- Placement des sondes et copie du trafic
- Lecture des protocoles industriels
- Inventaire passif et qualité des actifs
- Baseline, alertes et réglage
- Intégration au SIEM et au SOC
- Vulnérabilités et exploitation du parc de sondes
Questions de déploiement et de réglage pour un ingénieur détection OT
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Sur un site de trois ateliers, vous disposez de quatre sondes. Comment choisissez-vous où copier le trafic ?
Une bonne réponseIl part d'un schéma des flux par niveau de Purdue et cherche les points où passent les échanges entre SCADA, postes d'ingénierie et automates. Il préfère les switchs de distribution des ateliers plutôt que le cœur de réseau, parce que le trafic entre deux automates du même switch d'accès ne remonte jamais plus haut. Il vérifie que le port miroir supporte le débit copié et que les VLAN utiles sont inclus. Une semaine après la pose, il contrôle les paquets perdus et les sessions incomplètes dans les statistiques de la sonde.
Signal d'alerte« Sur le cœur de réseau, la sonde voit tout. » Ou un placement décidé sans schéma ni échange avec les automaticiens.
Question 2 · confirmé
Une alerte signale une écriture Modbus sur un automate qui n'en reçoit jamais. Que regardez-vous pour comprendre ce qui s'est passé ?
Une bonne réponseLe code fonction (écriture d'une bobine ou d'un registre, simple ou multiple), les registres touchés et les valeurs écrites. Ensuite la source : un poste d'ingénierie connu, le SCADA ou un équipement jamais vu. Il compare l'heure avec les interventions prévues et appelle l'exploitation avant toute action. Il rappelle que Modbus n'a pas d'authentification : n'importe quel hôte du segment peut écrire, d'où l'intérêt de savoir qui avait accès au réseau à ce moment.
Signal d'alerteBloquer l'adresse source sur le pare-feu sans prévenir le site, ou classer l'alerte sans avoir regardé le code fonction ni les registres.
Question 3 · confirmé
Après un mois, l'inventaire de la sonde compte 40 % d'équipements inconnus. D'où cela vient-il et comment faites-vous baisser ce chiffre ?
Une bonne réponseDes équipements qui parlent peu ou seulement en diffusion, des protocoles non décodés ou chiffrés, une sonde placée au-dessus d'un routeur qui ne voit plus les adresses MAC, des appareils derrière une passerelle série ou une translation d'adresses. Il ajoute un point de copie là où il manque, propose des requêtes actives limitées (Safe Queries chez Claroty, Smart Polling chez Nozomi) avec l'accord de l'automaticien, importe les fichiers de projet ou la liste de l'exploitation, et complète à la main ce qui reste.
Signal d'alerte« Ce sont des équipements éteints. » Ou lancer un scan réseau classique sur les automates pour compléter l'inventaire.
Question 4 · confirmé
Les alertes de modification de programme automate sonnent à chaque intervention de la maintenance. Comment les réglez-vous sans perdre la détection ?
Une bonne réponseIl garde la règle et encadre les cas légitimes : postes d'ingénierie référencés, automates concernés, fenêtres d'intervention déclarées par l'exploitation, idéalement reliées aux ordres de travail. Dans ces conditions, l'alerte descend en priorité basse et reste tracée. Tout téléchargement depuis un poste inconnu ou hors fenêtre reste en priorité haute. Il revoit les exceptions à intervalle fixe pour qu'elles ne s'accumulent pas.
Signal d'alerteDésactiver la règle, ou déclarer tout le sous-réseau de maintenance comme source de confiance sans limite de temps.
Question 5 · confirmé
Le SOC reçoit vos alertes OT et ne sait pas quoi en faire. Que changez-vous dans ce que vous lui envoyez ?
Une bonne réponseIl filtre d'abord : seules les alertes utiles partent au SIEM, le reste reste dans la console. Chaque alerte transmise porte le nom métier de l'équipement, sa zone, sa criticité, le protocole, la commande vue, la source, la destination et un lien vers la console. Il ajoute la technique MITRE ATT&CK for ICS correspondante et une fiche réflexe par type d'alerte, avec le contact d'astreinte du site et les actions que le SOC n'a pas le droit de prendre seul.
Signal d'alerteTout envoyer en syslog brut, ou estimer que le SOC n'a qu'à se former à l'OT.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ingénieur détection OT : questions fréquentes
Claroty, Nozomi ou Armis : faut-il exiger l'outil déjà installé sur le site ?
Pas forcément. Les trois reposent sur la même logique : copie du trafic, décodage des protocoles industriels, baseline et alertes. Une personne qui a déployé et réglé l'un d'eux sur plusieurs sites prend en main un autre en quelques semaines. L'expérience du terrain compte davantage : placement des sondes, inventaire corrigé avec les automaticiens, exceptions tenues dans le temps. L'outil exact compte davantage si le poste porte sur l'intégration avancée, par exemple Armis avec ServiceNow.
Quelle différence entre un ingénieur détection OT et un ingénieur cybersécurité OT ?
L'ingénieur cybersécurité OT couvre un champ large : segmentation, accès distants des mainteneurs, correctifs, durcissement, conformité IEC 62443. L'ingénieur détection OT se concentre sur la visibilité : sondes, inventaire, alertes et lien avec le SOC. Dans les petites équipes, la même personne fait les deux. Si le besoin est un déploiement de sondes sur plusieurs sites, l'annonce doit le dire clairement, sinon arrivent surtout des profils d'architecture ou de conformité.
Quel test technique proposer à un ingénieur détection OT ?
Une capture réseau d'un atelier, anonymisée, se prête bien à un exercice en direct. Le candidat identifie les équipements et leurs rôles, repère les commandes d'écriture ou de programmation et dit lesquelles mériteraient une alerte. Une variante consiste à commenter une console de sonde avec quelques alertes réelles. L'exercice se fait à voix haute, en une heure au plus, et montre vite si la personne lit vraiment les protocoles.
Un analyste SOC venu de l'IT peut-il évoluer vers la détection OT ?
Oui, à condition d'accepter une période d'apprentissage sur les protocoles et les contraintes de production. Il apporte la culture de l'alerte, du SIEM et de l'enquête. Il lui manque souvent la connaissance des automates, des fenêtres de maintenance et du réflexe de ne rien couper sans l'exploitation. L'entretien vérifie qu'il a déjà approché un réseau industriel, même en laboratoire, et il travaille avec un automaticien lors des premières poses de sondes.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
