Pendant des années, les exercices sur table (tabletop exercises) ont testé si les équipes feraient la bonne chose sous pression. Maintenant que l'IA rédige des playbooks, trie les alertes et propose des réponses pendant les incidents en direct, elle doit faire partie du test.
Les exercices sur table (tabletop exercises) existent pour répondre à une seule question : quand quelque chose tombe en panne, les personnes chargées de le réparer feront-elles vraiment la bonne chose, dans le bon ordre, assez vite ? Pendant des années, la réponse dépendait presque entièrement des humains : leur formation, leurs runbooks et leur jugement sous pression. On partait du principe que l'outillage était statique. Nous avons toujours testé les personnes parce que les personnes étaient la variable.
Cette hypothèse ne tient plus.
Chez Webflow, nous avons passé un an à intégrer l'IA dans les parties de la réponse aux incidents qui étaient autrefois purement humaines : trier les alertes, aller chercher le bon playbook, proposer des réponses, et même rédiger la PIA (Post Incident Analysis, analyse post-incident) et ses actions de suivi. Nous avons déjà écrit comment cela a multiplié notre équipe sécurité plutôt que de la remplacer, mais ce changement a une conséquence à laquelle peu d'équipes se confrontent encore. Si l'IA fait désormais du vrai travail pendant un incident, l'IA fait désormais partie de ce qu'un exercice sur table doit tester. Pas seulement si vos intervenants connaissent les runbooks, mais si le système censé leur fournir le runbook le fait réellement, et le fait correctement, sous la même pression que celle qui ne s'appliquait autrefois qu'aux humains.
Ce n'est pas qu'un problème d'équipe sécurité. Toute équipe qui a laissé discrètement un système d'IA s'intégrer à sa réponse (le support qui route les escalades clients, le SRE qui trie les pannes, l'IT qui résout automatiquement les demandes d'accès) a la même dépendance non testée dans son processus. Si vos formats d'exercice sur table n'ont pas changé depuis que vous avez injecté de l'IA dans vos systèmes, vous testez une équipe qui n'existe plus, et vous restez aveugle aux failles.
Les exercices sur table testaient les personnes. Ils doivent désormais tester un système.
La conception classique d'un exercice sur table supposait un ensemble fixe d'outils et un ensemble variable d'humains. Le scénario change, mais les injects sont construits autour de points de décision : qui est alerté, qui a l'autorité de trancher et si le runbook est suivi sous stress. L'outillage fait partie du décor, il ne tombe pas en panne ni n'induit en erreur, et il n'a pas besoin de sa propre ligne dans le rapport post-action.
Ce n'est plus vrai dès lors que l'IA se place entre votre équipe et les informations sur lesquelles elle agit. Si votre système de triage résume les alertes, une défaillance de l'IA pendant un incident en direct ne ressemble pas à un serveur qui tombe. Elle ressemble à un résumé faux avec aplomb, à une recherche documentaire qui remonte un playbook obsolète parce qu'il correspond mieux aux mots-clés que le playbook actuel, ou à une action de réponse suggérée qui semble raisonnable et qui est discrètement risquée. Ces défaillances sont silencieuses. Elles ne déclenchent aucune erreur. Elles rendent simplement vos intervenants plus lents ou potentiellement dans l'erreur, sans que personne ne s'en aperçoive avant plus tard. Un exercice sur table qui n'injecte jamais l'une de ces défaillances ne teste que la moitié du système qui tournera réellement lors d'un vrai incident.
Ce qui doit réellement figurer dans l'exercice aujourd'hui
Quelques catégories de défaillance sont assez récentes pour que la plupart des bibliothèques d'exercices existantes n'aient pas encore d'injects pour elles. Elles méritent d'être intégrées :
L'IA donne une réponse fausse ou incomplète avec une assurance totale. C'est la plus importante et la plus facile à éluder, parce qu'il est inconfortable de concevoir un test contre ses propres outils. Jouez un scénario où l'étape de triage assistée par IA hallucine la cause racine, ou où la recherche de playbook renvoie un document proche mais obsolète. Le test n'est pas de savoir si l'IA a raison. Elle finira par halluciner, c'est acquis. Le test est de savoir si vos intervenants le remarquent, et s'ils ont l'habitude de vérifier plutôt que l'habitude de faire confiance.
Disponibilité du système d'IA. C'est la version la plus aiguë du problème pour les équipes sécurité en particulier : que se passe-t-il quand ce sur quoi vous vous appuyez normalement pour enquêter sur une compromission est justement ce qui est compromis, ou hors ligne parce que l'incident l'a emporté avec lui ? La plupart des équipes ont un plan de repli pour « le SIEM est en panne ». Moins nombreuses sont celles qui ont répété « le système d'IA que nous utilisons pour le triage est indisponible, et la moitié de l'équipe n'a jamais fait de triage sans lui ». Cette lacune n'apparaît que lorsqu'on la cherche.
Les garde-fous sont testés sous une pression réelle, pas dans une démo. Des garde-fous qui tiennent lors d'une revue de conception sereine sont souvent discrètement contournés quand quelqu'un en est à trois heures d'incident et veut simplement que l'IA exécute l'action plutôt que de rédiger une suggestion qu'un humain doit valider. Un bon inject d'exercice sur table place un intervenant exactement dans cette position et observe ce qu'il fait, pas ce que la politique dit qu'il doit faire.
Plus personne ne se souvient de la manière d'avant. Le revers du fait que l'IA fasse bien le triage et la recherche documentaire, c'est que la mémoire musculaire pour le faire manuellement s'atrophie. Si votre équipe a passé un an avec une IA qui fait remonter de manière fiable le bon playbook en quelques secondes, la plupart de ses membres n'ont pas fouillé eux-mêmes votre documentation sous contrainte de temps depuis longtemps. Testez cette compétence directement, volontairement, avant qu'un incident ne vous force à découvrir si elle est perdue.
Le point de passage de relais n'est pas clair. La réponse assistée par IA fonctionne parce qu'il existe une frontière : l'IA fait remonter et suggère, un humain dans la boucle décide et agit. Les exercices sur table sont un bon endroit pour découvrir si cette frontière est réellement comprise par les personnes qui opèrent dessus, ou si elle est seulement écrite quelque part. Construisez un inject où la suggestion de l'IA « évidemment correcte » est subtilement fausse, et voyez qui s'en aperçoit et qui ne s'en aperçoit pas.
Ce que cela change à la façon de mener l'exercice
Rien de tout cela n'exige de jeter votre programme d'exercices existant. Il s'agit d'y ajouter une couche. Quelques changements pratiques :
Rédigez des injects qui ciblent spécifiquement la couche IA, pas seulement la couche humaine. Si votre document de scénario ne décrit jamais que ce qui arrive aux systèmes et aux personnes, et jamais ce qui arrive à l'outillage d'IA qui se trouve entre les deux, il vous manque une catégorie de défaillance qui fait désormais partie de votre surface d'attaque réelle pour la qualité de la réponse.
Intégrez à l'exercice les personnes qui construisent et maintiennent l'outillage d'IA, pas seulement les intervenants qui l'utilisent. Elles sont souvent les seules à comprendre réellement les modes de défaillance qui valent la peine d'être injectés, et l'exercice les pousse à y réfléchir aussi.
Faites le débrief sur votre outillage d'IA de confiance, pas seulement sur le respect du processus. La question traditionnelle du retour d'expérience est « l'équipe a-t-elle suivi le runbook ». La nouvelle question qui l'accompagne est « l'équipe a-t-elle fait confiance au système d'IA dans la juste mesure », ni trop peu, ce qui gaspille l'investissement, ni trop, ce qui fait d'une mauvaise réponse un incident à part entière.
Considérez « nous l'avons testé une fois » comme insuffisant. Les systèmes d'IA évoluent : les modèles sont mis à jour, des sources de recherche sont ajoutées, des garde-fous sont ajustés, d'une manière que votre documentation statique ne reflète pas. Un exercice sur table qui a testé votre processus de réponse assisté par IA il y a un an teste un système qui n'existe plus.
La partie inconfortable
Les équipes les plus susceptibles de passer cette étape sont celles qui ont le plus réussi avec la réponse assistée par IA, parce que cela fonctionne et que le tester donne l'impression de chercher des problèmes qui n'existent pas. C'est exactement l'inverse. Plus le système d'IA devient porteur, plus il coûte cher de découvrir ses modes de défaillance pour la première fois lors d'un vrai incident plutôt que lors d'un incident répété. Nous n'avons pas intégré l'IA à notre processus de réponse pour le rendre fragile. Les exercices sur table sont la façon de nous assurer que ce n'est pas le cas.
Si votre équipe s'appuie sur l'IA pour le triage, la recherche ou la réponse, en sécurité ou ailleurs, la question à se poser ce trimestre n'est pas de savoir si vos équipes sont prêtes pour le prochain incident. C'est de savoir si vous avez réellement testé le système sur lequel elles vont compter pour y parvenir.
Testez le système avant que l'incident ne le fasse à votre place.
