Operational Ambiguity on Incident Response Scope

Quand plusieurs équipes ou organisations opèrent le même environnement — exploitant interne, prestataire d’exploitation, équipe sécurité, éditeurs applicatifs — le partage opérationnel des rôles pendant un incident n’est défini nulle part : qui isole une machine, qui préserve les preuves, qui décide de restaurer, qui informe les utilisateurs, qui coordonne l’ensemble.

Chaque partie a une représentation implicite du partage — et ces représentations ne coïncident pas, précisément sur les actions les plus lourdes. C’est structurel : la répartition des tâches s’est construite autour de l’exploitation nominale (tickets, demandes, maintenance), et l’incident majeur n’a jamais été projeté sur cette organisation. L’ambiguïté est indolore tant qu’elle n’est pas testée — donc elle survit, invisible, jusqu’au jour où elle coûte.

Deux modes de défaillance symétriques, tous deux observables dans les premières heures :

• le trou : chaque partie croit qu’une action essentielle appartient à l’autre. Personne ne préserve les journaux, personne ne coupe l’accès suspect — et l’action manquante se découvre des heures plus tard, quand son absence a déjà produit ses effets ;
• le chevauchement : deux équipes agissent sans coordination sur le même objet. L’une réinstalle ce que l’autre analysait, détruisant les preuves ; l’une restaure pendant que l’autre confine, réintroduisant la compromission fraîchement éradiquée.

S’ajoute le coût de négociation : définir les rôles pendant l’incident consomme les heures les plus chères, sous des intérêts divergents devenus soudain visibles — chacun mesure ce que l’incident va lui coûter, et la discussion des rôles devient une discussion des torts.

Le pattern est difficile à voir de l’intérieur : chaque partie, interrogée seule, décrit un partage clair — le sien. L’identification doit donc croiser les représentations :

• soumettre séparément aux parties prenantes la même liste d’une dizaine d’actions concrètes — « isoler un serveur de production », « copier les journaux avant réinstallation », « décider de restaurer », « informer les utilisateurs », « tenir la main courante » — et demander pour chacune : qui l’exécute, qui la décide ?
• les écarts entre les réponses sont la mesure du pattern — inutile d’interpréter, il suffit de compter ;
• un exercice conjoint, même court, le révèle plus vite encore : les flottements se voient à la première injection (« qui fait ça ? » suivi d’un silence) ;
• signal complémentaire dans les documents : si l’incident de sécurité n’apparaît que comme un type de ticket dans les procédures d’exploitation, la projection n’a jamais été faite.

Produire une matrice de responsabilités spécifique à l’incident — pas celle de l’exploitation courante :

• pour chaque famille d’actions — détection, qualification, isolement, préservation des preuves, éradication, restauration, communication interne et externe, coordination — définir qui exécute, qui décide, qui est informé ;
• y joindre les coordonnées d’astreinte de chaque partie, vérifiées ;
• la faire valider par toutes les parties, pas rédiger par une seule : une matrice non contresignée reproduit l’ambiguïté qu’elle prétend lever, avec l’autorité en moins ;
• prévoir explicitement la coordination : qui tient la main courante commune, sur quel canal — un canal qui reste joignable même si l’environnement est dégradé ;
• la tester dans un exercice conjoint annuel (voir MFL-011) : c’est le seul mécanisme qui expose les divergences résiduelles avant qu’un incident ne le fasse.

L’ambiguïté se réduit pendant l’incident par trois gestes simples :

• nommer un coordinateur unique dans la première heure : le rôle peut échoir à n’importe quelle partie compétente — l’important est l’unicité et l’acceptation explicite par les autres, pas le choix optimal ;
• tenir une liste partagée des actions en cours et à venir, avec un propriétaire par action : le trou et le chevauchement se voient immédiatement sur une liste, jamais dans des conversations parallèles ;
• poser une règle de préservation par défaut tant que les rôles flottent : aucune réinstallation, aucun redémarrage non indispensable, aucune suppression — les actions irréversibles attendent d’avoir un propriétaire désigné.

Les désaccords de fond sur le partage des rôles se traitent après l’incident, avec la main courante comme matière première : pendant, la seule question est de savoir qui fait quoi dans l’heure qui vient.