Le poste de detection engineer est apparu quand les SOC ont compris que les règles livrées avec le SIEM ne suffisaient pas. La personne part d'une technique d'attaque, identifie les journaux qui la révèlent, écrit la règle, souvent en Sigma puis dans le langage du SIEM (KQL, SPL, EQL), la teste en rejouant l'attaque et la règle jusqu'à ce que les analystes puissent la traiter. Les questions d'entretien de detection engineer couvrent cette chaîne complète.
Les profils viennent surtout de deux horizons. Un analyste SOC N3 connaît les alertes et les faux positifs, mais a rarement versionné une règle ou écrit une CI. Un ingénieur venu du développement ou de la red team maîtrise Git et les tests, et connaît parfois mal la télémétrie Windows. Le plus parlant est une règle écrite par la personne, la source qu'elle utilisait, le faux positif qui l'a obligée à la corriger et le test qui prouve qu'elle déclenche.
Le poste reste indépendant de l'outil : un bon detection engineer passe de Sentinel à Splunk ou Elastic en quelques semaines. Le PDF détaille l'entretien sur six axes avec un cas de couverture d'une menace.
Les outils et formats d'un detection engineer
MITRE ATT&CK
La base de connaissances des techniques d'attaque, rangées par tactique (accès initial, persistance, mouvement latéral). Les règles y sont rattachées pour mesurer la couverture. Depuis la version 18 (octobre 2025), chaque technique porte des stratégies de détection et des analytics à la place de l'ancien champ de détection ; la version 20 date d'octobre 2026.
Sigma
Un format ouvert en YAML pour décrire une règle de détection sur des journaux, indépendamment du SIEM. Une règle Sigma se convertit avec pySigma et sigma-cli vers SPL, KQL, EQL, ES|QL ou AQL. Le format gère aussi des règles de corrélation (comptage, séquence ordonnée dans le temps).
Langages des SIEM
KQL pour Microsoft Sentinel et Defender XDR, SPL pour Splunk, EQL et ES|QL pour Elastic, YARA-L pour Google SecOps, AQL pour QRadar. Un detection engineer en maîtrise au moins un à fond et lit les autres.
YARA
Un format de règles pour reconnaître des fichiers ou de la mémoire à partir de chaînes et de motifs d'octets. Il sert à identifier une famille de malware, à chasser sur un parc avec l'EDR ou à trier des pièces jointes. À ne pas confondre avec Sigma, qui travaille sur des journaux.
Télémétrie Windows et EDR
Le journal Security de Windows, Sysmon et les données des EDR (Defender for Endpoint, CrowdStrike, SentinelOne, Elastic Defend) fournissent les processus, connexions et accès mémoire. La majorité des règles s'appuient sur ces sources, avec les journaux d'identité Entra ID et Active Directory.
Git et CI (detection as code)
Les règles sont stockées dans un dépôt, relues en merge request, validées et testées par une CI (GitLab CI, GitHub Actions), puis déployées par l'API du SIEM. Cette méthode remplace la modification à la main dans la console.
Atomic Red Team et MITRE Caldera
Deux outils d'émulation d'attaque. Atomic Red Team fournit des tests courts par technique ATT&CK. Caldera enchaîne des techniques dans un scénario d'adversaire. Ils servent à prouver qu'une règle déclenche réellement.
ATT&CK Navigator
Une interface web pour colorier la matrice ATT&CK selon la couverture de détection. Utile pour montrer ce qui est testé, ce qui est couvert en théorie et ce qui manque.
On trouve des detection engineers dans les SOC internes des grandes organisations, chez les prestataires de SOC managé et chez les éditeurs d'EDR ou de SIEM qui maintiennent des règles pour leurs clients. Dans un petit SOC, le rôle se confond avec celui d'analyste N3 ou de threat hunter. Dans une équipe plus large, il forme une cellule à part qui gère le catalogue de règles en code. Le poste demande peu de certifications spécifiques. L'expérience concrète se lit dans les règles écrites, les tests menés et les faux positifs traités, et parfois dans des contributions publiques au dépôt Sigma ou à des dépôts de règles d'éditeurs.
Ce qu'un detection engineer doit prouver
- Conception à partir d'ATT&CK
- Règles Sigma et langages SIEM
- Télémétrie Windows, EDR, identité
- Detection as code et CI
- Validation par émulation
- Réglage et qualité des règles
Cinq questions techniques d'entretien pour un detection engineer
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é
Le RSSI vous demande de couvrir le Kerberoasting. Par où commencez-vous, avant d'écrire la moindre requête ?
Une bonne réponsePar la technique elle-même (T1558.003 dans MITRE ATT&CK) et les traces qu'elle laisse : des demandes de tickets de service (4769) sur les contrôleurs de domaine, souvent avec un chiffrement RC4 (0x17), pour des comptes de service, depuis un compte qui n'en demande pas d'habitude. Il vérifie ensuite que ces journaux sont bien collectés, avec les bons champs, et regarde ce qui est légitime dans le parc (applications anciennes en RC4) avant de fixer la logique.
Signal d'alerteUne requête écrite tout de suite sur un nom d'outil (« Rubeus »), ou une règle sans vérifier que les journaux des contrôleurs de domaine arrivent.
Question 2 · confirmé
Lisez cette règle Sigma : logsource process_creation, une sélection sur Image se terminant par \rundll32.exe et CommandLine contenant javascript:. Que détecte-t-elle et comment la déployez-vous sur votre SIEM ?
Une bonne réponseUn rundll32 qui exécute du JavaScript, technique connue de proxy d'exécution (T1218.011). Pour la déployer : conversion avec sigma-cli et le backend du SIEM (Splunk, Kusto pour Sentinel ou Defender, Elasticsearch), avec un pipeline de traitement qui fait correspondre les champs et la source Sigma aux champs réels (Image vers process.executable ou FolderPath selon l'outil). Il relit la requête produite au lieu de la coller telle quelle, et la teste sur les données.
Signal d'alertePenser que Sigma est un langage que le SIEM exécute directement, ou convertir sans pipeline de correspondance des champs.
Question 3 · senior
Un attaquant lit la mémoire de LSASS pour voler des identifiants. Quelle télémétrie vous permet de le voir, et sur quels champs bâtissez-vous la détection ?
Une bonne réponseUn accès au processus lsass.exe : l'événement 10 de Sysmon (ProcessAccess) avec TargetImage lsass.exe, le processus source et les droits demandés (GrantedAccess), ou l'équivalent dans la télémétrie de l'EDR. Il écarte les sources légitimes (antivirus, EDR, outils de sauvegarde) par chemin et signature, et sait que des méthodes comme un vidage via comsvcs.dll ou un outil signé se voient aussi dans la création de processus et la ligne de commande.
Signal d'alerteUne règle sur le nom « mimikatz.exe » uniquement, ou aucune idée de la source de télémétrie qui voit un accès à un processus.
Question 4 · senior
Comment organisez-vous un dépôt de règles en detection as code, de l'écriture jusqu'à la production ?
Une bonne réponseUne règle par fichier (Sigma ou format natif) avec ses métadonnées : technique ATT&CK, auteur, sources requises, faux positifs connus, guide pour l'analyste. Une merge request relue par un pair, une CI qui valide la syntaxe, convertit si besoin, lance des tests sur des journaux d'exemple positifs et négatifs, puis un déploiement automatique vers le SIEM par son API, recette d'abord. Le dépôt fait foi, toute modification à la main dans la console est repérée.
Signal d'alerte« On met les requêtes dans un fichier Word partagé », ou un dépôt Git qui ne sert que de sauvegarde sans tests ni déploiement.
Question 5 · confirmé
Vous venez d'écrire une règle sur la création de tâches planifiées suspectes. Comment prouvez-vous qu'elle déclenche vraiment ?
Une bonne réponseIl rejoue la technique dans un environnement de test, avec un test Atomic Red Team correspondant (T1053.005) ou une commande schtasks écrite à la main, sur un poste équipé comme la production. Il vérifie que l'événement arrive dans le SIEM avec les bons champs, que l'alerte se crée dans le délai attendu, puis teste une variante (autre ligne de commande, API au lieu de schtasks) pour mesurer la robustesse.
Signal d'alerte« La requête renvoie des résultats sur le dernier mois, donc elle marche », sans test volontaire ni variante.
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
Detection engineer, les questions fréquentes
Detection engineer, threat hunter, analyste SOC : comment les distinguer ?
L'analyste SOC traite les alertes qui arrivent. Le threat hunter cherche ce qui n'a pas déclenché d'alerte, à partir d'hypothèses. Le detection engineer fabrique et entretient les règles qui produisent les alertes. Les trois partagent la connaissance des attaques et des journaux. Le detection engineer se distingue par la méthode d'ingénierie : versionnement, tests, mesure de la qualité. Dans un SOC de petite taille, une même personne peut tenir deux de ces rôles.
La maîtrise du SIEM de l'équipe est-elle exigée ?
C'est un plus, pas une condition. La logique de détection, la connaissance de la télémétrie et la méthode de test se transposent d'un outil à l'autre. Passer de KQL à SPL ou à EQL prend quelques semaines à une personne solide. Compte plutôt la maîtrise d'un langage à fond et la lecture d'une règle Sigma. Une méconnaissance des journaux Windows ou d'Entra ID est plus difficile à rattraper.
Quel exercice est donné à un detection engineer en entretien ?
Un test technique en deux temps fonctionne bien. D'abord une règle Sigma à expliquer puis à régler à partir de quelques faux positifs fournis. Ensuite une technique ATT&CK à couvrir : la personne décrit les sources, écrit la logique et explique comment elle prouverait que la règle déclenche. L'exercice dure quarante-cinq minutes en direct, avec la documentation autorisée, pour juger le raisonnement.
Quelles questions sur la detection as code pour un profil venu d'un SOC classique ?
La question porte sur la façon dont ses règles étaient stockées, qui les relisait, comment elles étaient déployées et comment l'équipe savait qu'une règle marchait encore. Un profil qui n'a connu que la console peut apprendre Git et la CI, à condition de comprendre l'intérêt des tests et de la relecture. La description d'un test unitaire de règle suffit : la réponse montre vite s'il a saisi le principe.
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.
