Dans un SOC, l'ingénieur SIEM fait le build. Il intègre les sources, écrit et maintient les parsers, déploie les règles, suit le coût d'ingestion et livre au run des détections documentées. Selon l'organisation, il travaille sur Splunk, Microsoft Sentinel, QRadar, Elastic, Google SecOps ou une plateforme française comme Sekoia, souvent avec un pipeline de télémétrie en amont.
Les CV mélangent volontiers administration de l'outil et ingénierie de la détection. Quelqu'un qui a installé des collecteurs ne sait pas forcément expliquer pourquoi une règle ne voit plus rien depuis la mise à jour d'un pare-feu. Les bonnes questions partent de la donnée : volume mesuré, champ mal normalisé, source muette, facture qui grimpe. Les réponses solides restent valables d'un éditeur à l'autre.
Une question sur la conservation des journaux et les données personnelles a aussi sa place. La CNIL a publié une recommandation sur la journalisation, et le guide de l'ANSSI sur l'architecture d'un système de journalisation reste la référence française. Le PDF propose trente questions, un cas de vingt minutes et une grille de notation.
Les briques techniques du métier
Plateformes SIEM
Splunk Enterprise Security, Microsoft Sentinel, IBM QRadar, Elastic Security, Google SecOps, Cortex XSIAM, Sekoia ou CrowdStrike Falcon Next-Gen SIEM. Chaque outil a son langage et son modèle de licence. L'expérience sur l'un se transpose si la personne maîtrise la logique de collecte et de normalisation.
Collecte : agents, syslog, WEF, API
Les journaux arrivent par agent sur les serveurs, par syslog depuis les équipements réseau, par Windows Event Forwarding pour un parc Windows, ou par API pour les services cloud et SaaS. Chaque mode a ses pertes possibles, ses délais et sa charge d'exploitation.
Pipelines de télémétrie
Cribl, Logstash, Vector, Fluent Bit ou Kafka, placés entre les sources et le SIEM. Ils filtrent, enrichissent, routent vers plusieurs destinations et absorbent les pics. Les offres récentes les citent souvent, en particulier pour réduire la facture d'ingestion.
Parsing et modèles de normalisation
Le parsing découpe un journal brut en champs. La normalisation les ramène à un modèle commun : CIM chez Splunk, ECS chez Elastic, ASIM chez Microsoft, UDM chez Google, OCSF en format ouvert. C'est la condition pour écrire une règle valable pour plusieurs sources.
Règles de corrélation et Sigma
Les règles transforment des événements en alertes. Sigma, format ouvert en YAML, permet d'écrire une détection indépendante du SIEM puis de la convertir. Les équipes matures gèrent leurs règles dans Git avec revue, tests et déploiement automatique.
Stockage et rétention
Stockage chaud pour la recherche rapide, froid pour la conservation longue et moins chère. La durée dépend des obligations, des besoins d'investigation et de la recommandation de la CNIL sur la journalisation, qui retient six mois à un an dans le cas général.
SOAR et outil de tickets
Le SIEM transmet ses alertes à un SOAR (Splunk SOAR, Cortex XSOAR, Logic Apps, Tines) et à l'outil de tickets du SOC. L'ingénieur SIEM s'assure que les champs arrivent normalisés et que les échecs d'envoi se voient.
Python, Ansible, Git et CI
Python pour les connecteurs et les scripts, Ansible ou Terraform pour déployer collecteurs et configurations, Git et une CI pour les parsers et les règles. Une partie des offres demande aussi PowerShell.
Référentiels français
Les guides de l'ANSSI sur l'architecture d'un système de journalisation et sur la journalisation en environnement Active Directory, la recommandation de la CNIL sur la journalisation, et le référentiel PDIS pour les prestataires de détection qualifiés.
Le poste existe dans les SOC internes, chez les intégrateurs et chez les prestataires de détection, dont certains sont qualifiés PDIS par l'ANSSI. On parle selon les cas d'ingénieur SIEM, d'ingénieur build SOC, d'intégrateur SIEM ou de SOC engineer. Les missions de build alternent avec des projets : déploiement d'un nouveau SIEM, migration d'un outil vers un autre, mise en place d'un pipeline de télémétrie. Les offres demandent presque toujours un ou deux SIEM nommés, du scripting et une connaissance des sources Microsoft. Pour un outil précis, les fiches par éditeur vont plus loin.
Compétences attendues d'un ingénieur build SOC
- Architecture et dimensionnement
- Collecte et intégration des sources
- Parsing et normalisation
- Règles et detection-as-code
- Coût, rétention et conformité
- Supervision de la chaîne et passage au run
Questions techniques pour un ingénieur SIEM
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é
On vous demande de dimensionner un SIEM pour 8 000 postes, 400 serveurs et une centaine d'équipements réseau. Que réclamez-vous avant de chiffrer ?
Une bonne réponseLa liste des sources réellement utiles aux cas d'usage, puis leur volume mesuré : événements par seconde en moyenne et en crête, gigaoctets par jour, sur un échantillon de quelques jours plutôt qu'avec un ratio par poste. Il ajoute la durée de rétention en stockage chaud et froid, la croissance attendue, la haute disponibilité et le modèle de licence de l'éditeur (volume ingéré, débit, nombre d'actifs ou capacité de calcul).
Signal d'alerteUn ratio par poste trouvé sur internet, sans mesure, ou un dimensionnement sur la moyenne qui ignore les crêtes.
Question 2 · confirmé
Les journaux d'un parc Windows doivent arriver dans le SIEM. Agent ou Windows Event Forwarding : comment choisissez-vous ?
Une bonne réponseAvant l'outil, la politique d'audit avancée par GPO : sans elle, aucun mode de collecte ne remonte les bons événements. WEF est natif, s'abonne par GPO et ne demande pas d'agent, mais impose des serveurs collecteurs (WEC) à dimensionner et un second saut vers le SIEM. Un agent filtre à la source, garde les événements en tampon pendant une coupure et porte Sysmon, au prix d'un déploiement et d'une maintenance sur tout le parc. Les bons profils citent le guide de l'ANSSI sur la journalisation en environnement Active Directory.
Signal d'alerte« On installe l'agent de l'éditeur » sans parler de la politique d'audit ni des événements à collecter.
Question 3 · confirmé
Après une mise à jour, un pare-feu change le format de ses journaux. Comment le savez-vous avant que les règles cessent de se déclencher ?
Une bonne réponseUne supervision du taux de parsing par source : part des événements non reconnus, champs obligatoires vides, chute brutale d'un type d'événement. Les parsers sont versionnés et testés sur des échantillons de chaque variante. L'équipe réseau prévient le build avant ses mises à jour, et un journal d'exemple de la nouvelle version est testé en recette.
Signal d'alerteL'apprendre par un analyste qui ne trouve plus rien pendant une investigation.
Question 4 · senior
Comment gérez-vous les règles de détection comme du code ?
Une bonne réponseUn dépôt Git, un format (Sigma ou le langage natif du SIEM), une revue par un pair avant fusion. Chaque règle porte ses métadonnées : technique ATT&CK, sources et champs requis, faux positifs connus, sévérité, propriétaire. La CI vérifie la syntaxe, lance des tests sur des journaux d'exemple (un cas qui doit déclencher, un qui ne doit pas) et déploie par l'API du SIEM, d'abord en recette. Un retour arrière se fait par un revert.
Signal d'alerteDes règles modifiées à la main dans la console de production, sans historique de qui a changé quoi.
Question 5 · confirmé
Le volume ingéré par le SIEM est passé de 300 à 600 Go par jour depuis janvier, sans nouveau périmètre. Comment trouvez-vous la cause ?
Une bonne réponseLe volume par source et par type d'événement, pour trouver les gros contributeurs : journaux de pare-feu en autorisation, DNS, événements Windows de filtrage réseau, niveau debug laissé actif. Puis la question de l'usage : quelles règles et quelles recherches utilisent ces données. Ce qui ne sert pas est filtré ou agrégé en amont (pipeline de télémétrie), ou routé vers un stockage moins cher. Chaque coupe est documentée avec son effet sur la détection.
Signal d'alerteCouper la source la plus volumineuse sans vérifier les règles qui en dépendent.
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 SIEM : les questions fréquentes
Ingénieur SIEM ou analyste SOC confirmé : en quoi les profils diffèrent-ils ?
L'analyste traite les alertes et investigue. L'ingénieur SIEM construit et maintient ce qui produit ces alertes : sources, parsers, règles, intégrations, supervision. Un analyste N2 ou N3 qui a beaucoup ajusté de règles peut évoluer vers le build, à condition de savoir scripter et de s'intéresser aux formats de journaux. L'entretien le teste sur une source à intégrer plutôt que sur une alerte à qualifier.
Faut-il connaître le SIEM exact de l'entreprise ?
Pour une mission courte de déploiement, oui, car le temps manque pour apprendre. Pour un poste durable, la maîtrise d'un autre SIEM suffit souvent si la personne raisonne en volumes, en modèles de données et en règles testées. Il faut quelques semaines pour le langage de requête et l'architecture propre à l'outil. Les certifications d'éditeur attestent la connaissance du produit, sans dire comment la personne gère une source mal parsée.
Quel test technique donner à un ingénieur SIEM ?
Un extrait de journaux bruts d'une source peu courante, avec deux ou trois variantes de format. La personne propose le découpage en champs, le mapping vers le modèle de données du SOC et une règle simple sur ces champs, puis explique comment elle la testerait. Quarante-cinq minutes suffisent. L'exercice montre la rigueur sur la donnée, que les questions orales ne révèlent pas toujours.
Comment repérer un profil qui maîtrise vraiment les coûts d'un SIEM ?
Le bon signe est une facture qu'il a réduite : de combien, sur quelles sources, avec quelle conséquence sur la détection. Un profil solide cite des chiffres de volume par source, parle de filtrage en amont, de stockage froid et des règles qui dépendent de chaque source. Un profil moins mûr propose de couper la plus grosse source sans regarder ce qui l'utilise.
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.
