L’intelligence artificielle a changé la manière dont les équipes de sécurité et d’exploitation gèrent les incidents, puisqu’elle est désormais utilisée pour le tri des alertes, la récupération de procédures opérationnelles, la proposition d’actions et même la préparation d’analyses post-incident. Mais les exercices de simulation connus sous le nom de Tabletop Exercises testent encore principalement la connaissance des procédures par les personnes et leur capacité à prendre des décisions sous pression, sans tester le système intelligent qui s’est interposé entre elles et les informations.
L’article, publié par Webflow sous forme de contenu sponsorisé, estime que cela crée une lacune opérationnelle : si l’intelligence artificielle fait partie du processus réel de réponse, elle doit également faire partie des tests. Cela vaut pour les équipes de sécurité, les équipes de fiabilité des sites qui l’utilisent pour trier les pannes, les équipes d’assistance qui s’appuient sur elle pour orienter les escalades et les opérations informatiques qui l’utilisent pour automatiser les demandes d’accès.
Passer du test des personnes au test de l’ensemble du système
Les exercices de simulation traditionnels partaient du principe que les outils étaient stables et que la principale variable était constituée par les personnes : qui reçoit l’alerte ? Qui a le pouvoir de décision ? Et l’équipe suit-elle suffisamment rapidement la procédure opérationnelle ? Mais la défaillance d’un outil d’intelligence artificielle ne se manifeste pas nécessairement par une panne évidente. Il peut fournir un résumé erroné avec assurance, récupérer une procédure obsolète parce qu’elle correspond aux mots-clés, ou proposer une action qui semble logique mais qui n’est pas sûre.
Ces défaillances discrètes peuvent ralentir la réponse ou conduire l’équipe à prendre une mauvaise décision sans afficher de message d’erreur pour l’alerter. Par conséquent, un exercice qui n’intègre pas ces situations ne teste qu’une partie du dispositif qui sera utilisé lors de l’incident réel.
Situations à intégrer à l’exercice
- Réponse erronée donnée avec assurance : il est possible de simuler une hallucination dans l’identification de la cause racine ou la récupération d’un document proche mais ancien. L’objectif n’est pas de supposer que le système ne se trompera pas, mais de tester la capacité des intervenants à vérifier l’information et à ne pas traiter la réponse comme une vérité.
- Panne du système d’intelligence artificielle : il convient de tester ce qui se passe si le système utilisé pour l’investigation devient indisponible ou est lui-même affecté par l’incident, et de vérifier si l’équipe sait toujours effectuer le tri manuellement.
- Contournement des garde-fous sous pression : les contrôles peuvent sembler adaptés lors d’une revue sereine, mais être négligés lorsque l’incident dure des heures et que quelqu’un veut que le système exécute l’action au lieu de la proposer à l’approbation humaine.
- Érosion des compétences manuelles : une longue dépendance à la récupération automatisée peut affaiblir la capacité de l’équipe à rechercher des informations dans la documentation et à exécuter les étapes sans assistance.
- Ambiguïté du point de relais : il faut tester si les collaborateurs savent clairement où s’arrête le rôle du système et où commence la décision humaine, en particulier lorsque la recommandation automatisée est convaincante mais partiellement erronée.
Comment les équipes peuvent-elles mettre à jour leurs exercices ?
Les organisations n’ont pas besoin d’annuler leurs programmes actuels, mais plutôt d’y ajouter une couche ciblant l’outil d’intelligence artificielle lui-même. Il convient d’impliquer les personnes qui construisent et gèrent ces outils, car elles sont les mieux placées pour déterminer leurs modes de défaillance. La séance de revue doit également dépasser la question « l’équipe a-t-elle suivi la procédure opérationnelle ? » pour poser une autre question : « l’équipe a-t-elle accordé au système le niveau de confiance approprié ? » Une confiance trop faible gaspille l’utilité de l’outil, tandis qu’une confiance excessive peut transformer une réponse erronée en cause directe de l’aggravation de l’incident.
L’article souligne qu’un seul test ne suffit pas, car les modèles, les sources de récupération et les garde-fous évoluent avec le temps. Il faut donc répéter l’exercice chaque fois que les composants du système qui influent sur la réponse changent.
Lecture éditoriale de certi.news
Le véritable changement ne consiste pas ici à ajouter l’intelligence artificielle à la liste des outils, mais à la voir occuper une position influente dans la chaîne de décision. Cela élargit le périmètre de la réponse aux incidents : l’équipe ne teste pas seulement la préparation de ses membres, mais aussi la fiabilité de l’intermédiaire qui synthétise les informations et propose l’étape suivante. Les limites de cette approche restent claires : l’article ne fournit pas de résultats de mesure indépendants ni de norme unifiée pour évaluer ces exercices, et il s’appuie sur l’expérience de Webflow. Ses recommandations doivent donc être considérées comme un cadre pratique adaptable, et non comme une preuve générale.