« Si une action peut être automatisée, elle doit l’être. »
La vitesse n’est pas le seul critère. Une action d’incident peut modifier des comptes, couper un service, supprimer une preuve ou publier une information.
01Classe les candidats
lab=/tmp/soria-ir-lot5-$USER
column -s, -t "$lab/source/automation/actions.csv"Le corpus distingue LOW + SAFE_CANDIDATE de HIGH + RESTRICTED. Créer une tâche interne n’a pas le même impact que désactiver un compte ou publier un message externe.
02Ajoute un gate humain
column -s, -t "$lab/source/automation/approvals.csv"Une action sûre mais non approuvée reste différée. L’approbation est une preuve explicite, pas une intention implicite.
03Observe la décision dérivée
bash module5-coordination-intelligence-learning.sh run "$lab"
column -s, -t "$lab/output/automation-plan.csv"Deux actions seulement deviennent APPROVED_FOR_SIMULATION. Les actions à haut risque restent DEFERRED.
04Ne confonds jamais approbation et exécution
Toutes les lignes gardent execution_status=NOT_EXECUTED. Le lab ne contacte aucun SOAR, SIEM, MISP, annuaire, firewall ou plateforme cloud.
05Définis la frontière d’un futur workflow réel
Avant une automatisation authentique, il faudrait au minimum : scope explicite, identité du demandeur, préconditions, approbation, journalisation, idempotence, rollback, preuve de résultat et gestion de l’échec.
06Teste les garde-fous
grep '^unsafe-auto-approval' "$lab/output/negative-results.csv"
grep '^automation-' "$lab/output/negative-results.csv"Les variantes à haut risque, non approuvées ou prétendument exécutées sont bloquées.
Classe six actions
Propose six tâches de réponse à incident et classe-les en automatisable, soumise à approbation ou interdite. Justifie le risque, le propriétaire et la preuve attendue.
✓À retenir
Une automatisation sûre réduit le travail répétitif sans retirer l’autorité humaine sur les décisions à impact élevé.