Chronique no 026 — 2026
Detection as Code & SOAR : automatiser sans anesthésier
Detection as Code pour standardiser la détection, SOAR pour industrialiser la réponse : un gain de résilience réel, à condition de ne pas anesthésier les équipes.
Standardiser la détection, industrialiser la réponse, et préserver le seul réflexe qu’aucune machine ne sait reproduire : le jugement face à l’inconnu.
Il est 3h17. Une alerte se déclenche. Le temps que l’analyste de garde émerge, la machine a déjà fait le travail : poste isolé, accès réinitialisé, ticket ouvert et documenté. Au réveil, tout est sous contrôle. C’est exactement ce qu’on attend d’un SOC moderne.
Depuis deux épisodes, nous suivons le fil de l’intelligence au service de la résilience : l’IA défensive qui augmente la détection (024), l’IA offensive qui industrialise l’attaque (025). La suite logique, c’est le passage de la détection à la réponse. Comment standardiser ce que l’on cherche, puis automatiser ce que l’on fait une fois qu’on l’a trouvé ?
Deux approches répondent à cette question : le Detection as Code et le SOAR. La première traite les règles de détection comme du code. La seconde transforme la réponse en chaîne d’exécution automatisée. Ensemble, elles promettent vitesse, cohérence et sérénité.
Le gain de résilience est réel. Mais il a une contrepartie qu’on évoque rarement. À force de confier les gestes aux automatismes, on cesse de les pratiquer. Et le jour où l’attaque sort du cadre prévu, c’est un muscle atrophié qu’on somme de réagir.
La vraie question n’est donc pas : jusqu’où automatiser ? C’est : que reste-t-il d’humain quand tout fonctionne tout seul - et ce jour-là, sait-il encore agir ?
1. Detection as Code : la détection sort de l’artisanat
Pendant longtemps, la détection a été un artisanat. Une règle de corrélation écrite à la main dans la console d’un SIEM, ajustée un soir d’astreinte, jamais documentée. Elle fonctionne - tant que son auteur est là. Le jour où il part, plus personne ne sait pourquoi elle existe, ni si on peut la modifier sans tout casser.
Le Detection as Code applique à la détection les principes qui ont fait leurs preuves dans le développement logiciel. Une règle devient un artefact versionné : stockée dans un dépôt Git, revue par un pair, testée automatiquement, déployée par un pipeline d’intégration continue. On sait qui l’a écrite, quand, pourquoi, et ce qu’elle a changé.
Le standard ouvert de référence s’appelle Sigma : un format générique qui décrit une détection une seule fois, puis se traduit vers n’importe quel SIEM. On retrouve ici un fil tendu depuis l’épisode 002 : écrire ses détections dans un format ouvert, c’est refuser le verrouillage propriétaire. La logique de défense ne doit pas être l’otage d’un éditeur.
Reste à savoir ce que l’on couvre. C’est le rôle de MITRE ATT&CK : cartographier ses règles contre les techniques d’attaque connues permet de mesurer sa couverture - et surtout de voir ses angles morts. Car une carte de couverture, c’est d’abord une carte de ce que l’on ne voit pas encore.
Standardiser la détection n’est pas un confort d’ingénieur. C’est rendre visible ce que l’on ne voyait pas, et reproductible ce que l’on aurait, sinon, fini par oublier.
2. SOAR : du diagnostic à l’action
Le Detection as Code répond à la question « que cherche-t-on ? ». Le SOAR répond à la suivante : « que fait-on quand on a trouvé ? ». Security Orchestration, Automation and Response : il connecte les outils, exécute des tâches sans intervention humaine, et applique des playbooks pré-écrits pour répondre aux incidents. Il est le bras opérationnel de la réponse.
Les gains sont concrets. Sur les incidents répétitifs - tri d’un phishing, mise en quarantaine d’un e-mail, isolement d’un poste, enrichissement d’une alerte - le temps de réponse s’effondre. L’analyste cesse de crouler sous des centaines de notifications quotidiennes. La réaction devient cohérente : plus d’improvisation à 3h du matin sur un cas pourtant connu.
Mais l’ordre des opérations compte. La CISA, dans ses recommandations 2025 sur le SIEM et le SOAR, le rappelle sans détour : on ne déploie pas un SOAR avant que la détection soit fiable. Automatiser une réponse sur la base d’alertes bruitées, c’est industrialiser l’erreur. La détection d’abord ; l’automatisation ensuite.
Surtout, ces recommandations insistent sur un point essentiel : ni le SIEM ni le SOAR ne sont des outils « à installer et oublier ». Ce sont des chantiers permanents, qui exigent du personnel hautement qualifié pour concevoir, maintenir et corriger les playbooks. L’automatisation ne réduit pas le besoin de compétence. Elle le déplace.
Le SOAR ne remplace pas la décision. Il exécute, à grande vitesse, une décision déjà prise à froid - celle que l’on a inscrite dans un playbook.
3. Le vrai bénéfice : libérer du temps de cerveau
On présente souvent l’automatisation comme un moyen de « faire plus avec moins ». C’est une lecture comptable, et elle passe à côté de l’essentiel. Le véritable enjeu n’est pas de réduire les effectifs. C’est de réallouer la ressource la plus rare d’un SOC : l’attention experte.
Le raisonnement est simple. Le répétitif, le connu, le faible enjeu - on l’automatise. Le nouveau, l’ambigu, le critique - on le réserve à l’humain. Chaque faux positif fermé automatiquement, c’est une minute rendue à l’analyste pour traiter le signal faible qui, lui, mérite un cerveau.
C’est exactement la posture défendue à l’épisode 024 : l’IA défensive comme copilote, pas comme pilote automatique. La machine industrialise le geste connu pour que l’humain se concentre sur ce qu’aucune règle n’a anticipé. La valeur d’un expert ne réside pas dans le tri de masse. Elle réside dans le jugement.
Encore faut-il que ce temps libéré soit réinvesti là où il compte - chasse aux menaces, analyse des angles morts, conception de nouveaux scénarios. S’il est simplement supprimé, on n’a pas gagné en résilience : on a réduit la voilure en attendant la tempête.
Automatiser les cas connus pour réserver les neurones aux cas inconnus : voilà l’arbitrage. Il ne s’agit pas de remplacer l’humain, mais de le déplacer là où il est irremplaçable.
4. Le piège : l’anesthésie
Voici le paradoxe que personne n’affiche sur les plaquettes commerciales. En 1983, la chercheuse Lisanne Bainbridge le formulait dans un texte resté célèbre, « Ironies of Automation ». Son constat : en automatisant l’essentiel d’une tâche, on confie à l’humain précisément la part qui ne s’automatise pas - la situation rare, anormale, imprévue - tout en le privant de la pratique quotidienne qui le maintenait compétent.
Transposez au SOC. Quand la machine traite 95 % des alertes, l’analyste perd ses réflexes sur les 5 % restants. Le jour où survient le scénario hors playbook - une attaque inédite, une opération autonome pilotée par IA comme l’espionnage évoqué à l’épisode 025, un enchaînement qu’aucune règle n’avait prévu - il faut improviser. Avec un muscle qui ne s’est pas entraîné depuis des mois.
S’ajoute le paradoxe de la vigilance. L’humain ne fait plus : il surveille une machine qui fait. Or surveiller passivement est épuisant et propice à l’erreur. Pire, un biais s’installe - le biais d’automatisation : on finit par faire confiance au verdict automatique même quand il se trompe. Une isolation déclenchée à tort sur un compte VIP, et la mini-crise interne est garantie.
L’anesthésie, ce n’est donc pas l’automatisation elle-même. C’est l’automatisation que l’on a cessé de questionner. Le système tourne, les voyants sont verts, et l’on confond « ça fonctionne » avec « nous sommes prêts ». Ce sont deux choses différentes.
Plus on automatise, plus la compétence humaine résiduelle devient rare - et plus elle devient précieuse. Le danger n’est pas la machine qui agit. C’est l’humain qui désapprend.
5. Garder l’humain dans la boucle (vraiment)
« Human in the loop » est devenu un slogan. Pour qu’il veuille dire quelque chose, il faut décider, action par action, où placer le curseur. Et ce curseur n’est pas technique : il dépend de deux critères simples - la réversibilité de l’action, et son rayon d’impact. Plus une action est irréversible et large, plus l’humain doit rester à la manœuvre.
Cette gradation n’est pas de la timidité. C’est du discernement. Le retour d’expérience industriel est connu : automatiser l’isolement de systèmes OT a déjà provoqué des blocages intempestifs de production, imposant un retour à la supervision humaine. Tout ce qui touche au critique se décide ; cela ne se script pas aveuglément.
Reste à situer son organisation. La grille de maturité Plan R offre trois paliers :
Le bon niveau d’automatisation n’est pas une question d’outil, mais d’arbitrage : il se règle sur la réversibilité et l’impact. L’irréversible reste humain.
6. Entretenir le muscle
Si l’automatisation atrophie la compétence, alors la compétence doit s’entretenir comme un muscle : par l’exercice. Le NIST, dans la version 3 de son guide de réponse aux incidents (SP 800-61, 2025), le pose noir sur blanc : il est impossible de disposer d’une procédure pour chaque situation. On documente les incidents les plus courants, mais on mise sur l’amélioration continue, nourrie par les leçons de chaque exercice.
Concrètement, cela veut dire débrancher régulièrement le pilote automatique. Faire tourner les analystes sur des investigations manuelles. Organiser des exercices red team / purple team qui génèrent, volontairement, des scénarios hors playbook. Traiter chaque angle mort de couverture ATT&CK comme une découverte à exploiter, pas comme une statistique à ranger.
Car un playbook est une photographie. Il fige la connaissance des menaces d’hier. L’attaquant, lui, cherche précisément la faille que le playbook n’a pas prévue. La couverture de détection d’aujourd’hui dessine, en creux, les angles morts de demain.
C’est là que la boucle se referme avec le bénéfice de la section III : le temps libéré par l’automatisation n’a de sens que s’il est réinvesti dans la chasse à l’inconnu. Automatiser pour cesser de chercher, c’est offrir l’avantage à l’adversaire - et ne s’en apercevoir qu’au prochain scénario inédit.
Un playbook n’est jamais terminé. Le jour où l’on cesse d’en écrire de nouveaux, c’est que l’on a renoncé à anticiper. L’exercice n’est pas un luxe : c’est l’anesthésiant que l’on refuse de prendre.
L’Essentiel pour Agir
1. Versionnez votre détection. Sortez vos règles des consoles : Git, revue par les pairs, tests automatisés, cartographie ATT&CK. Une détection que l’on ne peut ni tracer ni rejouer est une dépendance cachée - celle qui disparaît avec son auteur.
2. Graduez l’automatisation par la réversibilité. Refusez le « tout ou rien ». Croisez réversibilité et rayon d’impact pour chaque action : l’irréversible et le critique restent une décision humaine. Le SOAR exécute ; il n’arbitre pas.
3. Exercez le scénario hors playbook. Débranchez le pilote automatique à intervalles réguliers. Investigations manuelles, exercices red/purple team, simulations de cas inédits : la compétence est un muscle, et le muscle s’entretient ou s’atrophie.
Conclusion
L’automatisation de la détection et de la réponse est un gain de résilience que nul ne devrait bouder. Elle apporte vitesse, cohérence, endurance. Mais elle introduit une dépendance nouvelle, et invisible : envers le playbook, envers le verdict de la machine, envers le confort du voyant vert. Or la résilience, depuis le premier épisode, n’a jamais été l’absence de dépendance. Elle est la conscience de ses dépendances.
Reste alors une question qui monte, et qui sera bientôt la nôtre. Si la machine exécute et que l’humain arbitre, où passe exactement la frontière ? Qu’a-t-on le droit de déléguer à un automatisme - et qu’est-ce que l’on ne devrait jamais lui abandonner, même quand il fait mieux que nous ? Plus nous déléguons, plus cette frontière devient le vrai sujet.
Automatiser, c’est déléguer l’exécution. Ce n’est jamais déléguer le jugement. Le jour où l’on confond les deux, on n’a pas gagné du temps : on a perdu la main.
Bibliographie
« CISA / ACSC - Implementing SIEM and SOAR Platforms: Executive Guidance (2025) »
https://www.cisa.gov/resources-tools/resources/guidance-siem-and-soar-implementation
Recommandations conjointes US/Australie sur le SIEM et le SOAR : déployer le SIEM avant le SOAR, et rappel que ce ne sont pas des outils « à installer et oublier ». Source directe des sections II et V.
« NIST SP 800-61r3 - Incident Response Recommendations and Considerations (2025) »
https://csrc.nist.gov/pubs/sp/800/61/r3/final
Référence de la réponse à incident, alignée sur le CSF 2.0. Pose le principe clé de la section VI : on ne peut documenter chaque situation ; il faut miser sur l’amélioration continue.
« ANSSI (PA-022) - Recommandations de sécurité pour l’architecture d’un système de journalisation (2022) »
Socle français de la détection : journalisation, corrélation et déclenchement d’alertes au SOC (annexe C). Le prérequis indispensable avant toute automatisation de la réponse.
« SigmaHQ - Generic Signature Format for SIEM Systems »
Le standard ouvert du Detection as Code : décrire une détection une fois, la versionner, la partager et la déployer vers n’importe quel SIEM. Cœur de la section I et levier anti-verrouillage propriétaire.
« MITRE ATT&CK - Adversary Tactics and Techniques Knowledge Base »
Référentiel de cartographie des techniques d’attaque. Permet de mesurer la couverture de détection et, surtout, de rendre visibles les angles morts à traiter en priorité.
« Lisanne Bainbridge - « Ironies of Automation », Automatica, vol. 19 (1983) »
https://en.wikipedia.org/wiki/Ironies_of_Automation
Texte fondateur sur le paradoxe de l’automatisation : automatiser l’essentiel laisse à l’humain l’imprévu, tout en érodant la compétence nécessaire pour y faire face. Clé de voûte de la section IV.