L'ingénieur SOAR travaille pour les analystes du SOC. Il relève les tâches qu'ils répètent cent fois par semaine, comme le phishing signalé, les connexions à risque ou les alertes d'antivirus, et les confie à une plateforme d'orchestration : Cortex XSOAR, Splunk SOAR, les playbooks Logic Apps de Microsoft Sentinel ou le SOAR de Google SecOps. Les questions d'entretien d'ingénieur SOAR tiennent compte d'un poste qui mêle développement d'intégrations en Python et connaissance fine du traitement d'un incident.
Deux profils se présentent souvent. L'analyste SOC passé à l'automatisation connaît bien les procédures, mais écrit parfois des scripts fragiles. Le développeur maîtrise les API et le code, et sous-estime ce qu'une isolation automatique sur un faux positif coûte à l'exploitation. Le récit d'un playbook en production est parlant : ce qu'il fait, ce qui se passe quand une API ne répond pas et qui peut l'arrêter.
Les offres récentes ajoutent l'intégration de modèles de langage dans le SOC, sous le titre d'ingénieur IA pour SOC. L'entretien vérifie alors la prudence sur l'injection de consignes et sur les droits laissés au modèle. Le PDF propose l'entretien complet sur six axes, avec un cas d'automatisation du phishing.
Plateformes et briques techniques d'un ingénieur SOAR
Cortex XSOAR
La plateforme SOAR de Palo Alto Networks, en SaaS ou sur site en version 8. Elle gère les cas, les indicateurs et les playbooks, avec des intégrations en Python distribuées par packs sur sa Marketplace. Des engines installés dans le réseau interne permettent d'atteindre les outils non exposés.
Splunk SOAR
L'ancien Phantom, racheté par Splunk. Les événements y sont des containers, les observables des artifacts, et les connexions aux outils passent par des apps configurées en assets. Les playbooks s'écrivent dans un éditeur visuel ou en Python.
Microsoft Sentinel et Logic Apps
Dans Sentinel, des règles d'automatisation déclenchent des playbooks Logic Apps sur les incidents et les alertes. Microsoft annonce que Sentinel ne sera plus pris en charge dans le portail Azure après le 31 mars 2027 et passera entièrement dans le portail Defender.
Google SecOps SOAR et autres plateformes
Google SecOps intègre un SOAR issu du rachat de Siemplify. D'autres outils indépendants existent, comme Tines ou Torq, ou Shuffle en open source, souvent choisis par des SOC multi-outils. Les grands principes se retrouvent d'une plateforme à l'autre.
API REST et webhooks
Le SOAR parle aux autres outils par leurs API : EDR, pare-feu, messagerie, annuaire, ticketing, bacs à sable. L'ingénieur gère l'authentification (OAuth 2.0, clés, certificats), les quotas, la pagination et les erreurs, et sécurise les webhooks entrants.
Python
Le langage des intégrations sur mesure dans la plupart des plateformes. On attend un code testé, avec gestion des erreurs et des délais d'attente, sans secret en dur, maintenable par le reste de l'équipe.
Gestion des cas et ticketing
Les playbooks alimentent le cas : observables, résultats d'enrichissement, décisions et actions. Beaucoup de SOC synchronisent aussi les cas avec ServiceNow, Jira ou TheHive pour le suivi avec les autres équipes.
Modèles de langage (LLM)
Utilisés pour résumer un cas, expliquer une ligne de commande ou rédiger un brouillon de rapport. Le contenu des alertes peut contenir des consignes malveillantes : le modèle doit rester sans droit d'action et ses sorties relues.
Le poste apparaît dans les SOC internes qui ont atteint un volume d'alertes que les analystes ne suivent plus, et chez les prestataires de SOC managé qui doivent traiter de nombreux clients avec la même équipe. Selon l'organisation, il est rattaché à l'équipe build du SOC, à la détection ou à une cellule d'automatisation transverse. Les annonces mentionnent surtout Cortex XSOAR, Microsoft Sentinel et Python, et, dans les offres récentes, l'intégration de LLM. Les certifications d'éditeur existent, mais le niveau se mesure à des playbooks en production, à leur taux d'échec et au temps réellement gagné par les analystes.
Les six compétences d'un ingénieur automatisation SOC
- Conception de playbooks
- Intégrations API et Python
- Plateformes SOAR
- Garde-fous sur les actions
- Tests et supervision
- Mesure du gain et IA
Les questions d'entretien qui révèlent un bon ingénieur SOAR
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é
Les analystes passent dix minutes sur chaque signalement de phishing. Comment découpez-vous le playbook qui doit les soulager ?
Une bonne réponseDes étapes séparées : récupération du message signalé et extraction des observables (expéditeur, URL, pièces jointes, en-têtes), enrichissement par la réputation et le bac à sable, recherche des autres destinataires du même message, décision (automatique quand le verdict est net, analyste sinon), puis actions : retrait du message des boîtes, blocage de l'URL ou de l'expéditeur, réponse à l'utilisateur. Il réutilise des sous-playbooks d'enrichissement communs et chronomètre le traitement manuel avant de construire, pour mesurer le gain ensuite.
Signal d'alerteUn seul playbook linéaire qui supprime le message et bloque l'expéditeur dès qu'un moteur le juge suspect, sans recherche des autres destinataires ni décision humaine sur les cas douteux.
Question 2 · confirmé
L'API de votre outil de réputation renvoie une erreur 429 pendant un pic d'alertes. Que fait votre intégration ?
Une bonne réponseElle lit l'en-tête Retry-After quand il existe, attend puis retente avec un délai croissant et un nombre maximal d'essais. Elle met en cache les réponses pour ne pas interroger dix fois le même domaine et limite son propre débit selon le quota du contrat. Si l'enrichissement échoue malgré tout, le playbook continue avec un statut « non enrichi » visible par l'analyste au lieu de bloquer le cas.
Signal d'alerteUne boucle qui retente immédiatement sans limite, ou un playbook qui reste en échec silencieux et laisse le cas sans traitement.
Question 3 · senior
Un playbook isole automatiquement un poste quand l'EDR signale un rançongiciel. Quels garde-fous mettez-vous avant de l'activer ?
Une bonne réponseUne liste d'exclusions des machines critiques (contrôleurs de domaine, serveurs de production, postes de direction selon la politique) qui passent par une validation humaine. Une condition sur la confiance et la gravité de l'alerte, un plafond d'isolements par heure qui coupe l'automatisation en cas d'avalanche, une notification immédiate de l'astreinte et une procédure de levée de l'isolement testée. La règle est validée par écrit avec le RSSI et l'exploitation.
Signal d'alerteIsoler tout ce que l'EDR signale sans exception ni plafond, au risque de couper la moitié du parc sur un faux positif de signature.
Question 4 · confirmé
Où stockez-vous les identifiants et les secrets dont vos playbooks ont besoin pour appeler les API ?
Une bonne réponseDans le coffre de la plateforme (gestionnaire d'identifiants de Cortex XSOAR, assets de Splunk SOAR) ou un coffre externe, par exemple Azure Key Vault lu par l'identité managée d'une Logic App. Un compte de service par intégration, avec les droits minimaux, une rotation planifiée et des journaux d'accès. Il évite les secrets dans le code des scripts, dans Git ou dans les champs visibles du cas.
Signal d'alerteUn mot de passe en clair dans un script Python ou un compte administrateur partagé par toutes les intégrations.
Question 5 · confirmé
Vous modifiez un playbook utilisé en production par le SOC. Comment le testez-vous avant de le publier ?
Une bonne réponseSur une instance ou un espace de développement, avec des alertes d'exemple rejouées (cas réels anonymisés et cas limites), des intégrations pointées vers des environnements de test ou en mode simulation pour les actions destructives. Le playbook est versionné (export dans Git, ou contrôle de version de la plateforme), relu par un pair, puis déployé avec une possibilité de revenir à la version précédente.
Signal d'alerteUne modification directe en production, testée sur le prochain incident réel.
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 SOAR : les questions fréquentes
Ingénieur SOAR ou développeur Python : faut-il un profil cyber ?
Un développeur peut écrire des intégrations solides, mais sans connaissance du traitement d'un incident il automatise mal : mauvais ordre des étapes, actions trop brutales, pas de décision humaine là où il en faut. Un analyste SOC qui code connaît les procédures, mais doit souvent progresser en qualité de code. Le bon profil a vécu le SOC ou a travaillé longtemps avec lui. L'entretien teste les deux moitiés.
Un spécialiste de Splunk SOAR peut-il reprendre des playbooks Cortex XSOAR ?
Les principes se transposent : playbooks, intégrations, cas, garde-fous. Passer de Splunk SOAR à Cortex XSOAR ou à Logic Apps demande quelques semaines à une personne qui maîtrise déjà une plateforme et Python. La plateforme devient exigible si le poste démarre par une migration ou une reprise urgente. Sinon, la qualité des intégrations écrites compte davantage, tout comme et la prudence sur les actions automatiques.
Comment mettre un ingénieur SOAR en situation pendant l'entretien ?
Le candidat reçoit une documentation d'API simple et une alerte de phishing en JSON. Il découpe le playbook, puis écrit une fonction Python qui appelle l'API, gère la pagination et une erreur 429. Une question sur l'action de confinement et ses garde-fous termine l'exercice. Ce test technique tient en une heure en direct et montre à la fois le code, la méthode et la prudence.
Comment évaluer un candidat qui se présente comme ingénieur IA pour SOC ?
Un cas d'usage réel le révèle : quelle tâche le modèle traite, avec quelles données, quel gain mesuré. L'entretien aborde aussi l'injection de consignes par le contenu des alertes, la fuite de données vers un service externe et les droits du modèle. Un bon profil garde le modèle en lecture seule, relit ses sorties et sait dire où il ne sert à rien.
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.
