Notre article sur le triage assisté par l'IA traite de la première moitié du problème : réduire le bruit avant qu'il n'atteigne l'analyste. Celui-ci porte sur la seconde, plus délicate, où l'automatisation ne classe plus mais agit. Un faux positif de triage coûte une vérification ; un faux positif de réponse coupe l'accès d'un directeur commercial en pleine négociation.
Trois niveaux d'automatisation, et la ligne à ne pas franchir sans réflexion
Enrichir. Rassembler le contexte autour d'une alerte : réputation d'une adresse, historique du poste, appartenance de l'utilisateur, incidents antérieurs similaires. Aucune action sur le système. C'est sans risque, c'est le premier chantier, et c'est souvent celui qui fait gagner le plus de temps, parce que l'analyste passe l'essentiel de son temps à collecter du contexte.
Contenir de façon réversible. Isoler un poste du réseau, suspendre une session, mettre un message en quarantaine, bloquer une adresse en périphérie. Ces actions se défont en une commande. Elles peuvent être automatisées sur des scénarios bien caractérisés.
Agir de façon coûteuse à annuler. Désactiver un compte, réinitialiser des identifiants, supprimer des fichiers, couper une liaison partenaire. Ces actions ont un coût métier immédiat et se défont mal. Elles demandent une validation humaine, sauf sur un périmètre étroit et explicitement accepté.
La règle qui tient : automatiser sans supervision ce qui est réversible en moins d'une minute et sans effet visible pour un utilisateur légitime. Le reste passe par une décision.
Ce que l'IA apporte vraiment à la réponse
L'apport n'est pas la décision d'agir, c'est la préparation de cette décision.
Regrouper. Vingt alertes issues d'un même mouvement latéral se présentent comme vingt incidents. Les rapprocher par entité et par fenêtre temporelle produit un incident unique avec sa chronologie. Le gain n'est pas cosmétique : un analyste qui voit la séquence prend une autre décision que face à une alerte isolée.
Proposer une action motivée. Un modèle qui suggère « isoler ce poste » sans dire pourquoi ne fait gagner aucun temps, puisque l'analyste doit refaire l'analyse pour valider. La proposition doit porter ses éléments : ce qui a été observé, ce qui écarte les explications bénignes, ce que l'action va couper.
Rédiger la trace. La chronologie, les actions menées, les systèmes touchés. C'est la partie que les équipes sous pression documentent le moins bien, et c'est celle qu'on regrette au retour d'expérience et à la notification réglementaire.
Les modes d'échec à anticiper
L'action juste au mauvais moment. Isoler un poste pendant qu'un attaquant y est actif alerte l'attaquant et peut accélérer le chiffrement. Le playbook doit distinguer observer et couper, et ce choix n'est pas automatisable : il dépend de ce qu'on cherche à protéger.
La boucle d'automatisation. Une action qui génère un événement qui déclenche la même action. Toute automatisation doit porter un compteur d'exécutions et un plafond, avec arrêt et alerte au-delà.
L'automatisation qui masque la panne. Si un connecteur tombe, l'action n'est pas exécutée. Sans supervision de l'exécution elle-même, l'équipe croit le poste isolé alors qu'il ne l'est pas. Ce mode d'échec est le plus dangereux, parce qu'il produit une fausse assurance. Chaque automatisation doit vérifier son propre effet plutôt que supposer que la commande a abouti.
La dérive du périmètre. Une règle écrite pour un cas précis s'élargit au fil des mois par ajout d'exceptions. Une revue périodique des automatisations actives, avec leur taux de déclenchement et leur taux d'annulation manuelle, est la seule parade.
Mesurer le gain, et ne pas se mentir
Trois indicateurs, dont le troisième est le seul qui compte vraiment.
Le délai de confinement, entre détection et action effective. Le taux d'annulation manuelle des actions automatiques : au-delà de quelques pour cent, la règle est mal calibrée et l'équipe perdra confiance. Et le temps analyste réellement libéré, qui est la seule mesure du retour sur investissement.
Ce troisième chiffre déçoit souvent, parce qu'une automatisation mal supervisée déplace le travail plutôt qu'elle ne le supprime : l'analyste ne traite plus l'alerte, il vérifie ce que l'automate a fait. Le mesurer avant et après est la seule façon de le savoir.
Le contrôle humain reste une exigence, pas une préférence
Pour une entité soumise à NIS2, la responsabilité de la gestion des incidents ne se délègue pas à un outil. Et dès lors qu'un système d'IA participe à des décisions affectant des personnes, l'AI Act impose un contrôle humain effectif, ce qui suppose que l'opérateur puisse comprendre la proposition et l'écarter.
Concrètement, cela veut dire garder une trace de qui a validé quoi, et conserver la possibilité de revenir en arrière. Une automatisation qui ne se documente pas est un angle mort pour l'auditeur comme pour le retour d'expérience.
Ce que Zaxyr apporte
Zaxyr trace chaque action automatisée avec son déclencheur, son motif et son résultat vérifié, distinguant l'action demandée de l'action effective. Ces traces alimentent directement les preuves attendues sur la gestion des incidents, et le décompte des délais de notification démarre à l'ouverture de l'incident plutôt qu'à sa qualification.