Exemple de scénario de crise informatique

Une indisponibilité généralisée du système d’information ne devient pas une crise parce qu’un serveur est arrêté. Elle le devient lorsque les activités critiques ne peuvent plus être assurées dans des délais acceptables, que les décisions doivent être prises sous incertitude et que les parties prenantes attendent une réponse coordonnée. Cet exemple de scénario de crise informatique montre comment articuler réponse technique, continuité d’activité, communication et gouvernance.

Le scénario ci-dessous n’est pas un script à appliquer mécaniquement. Il constitue une base de travail pour un exercice de crise, l’élaboration d’un plan de réponse à incident ou la revue d’un dispositif de continuité. Chaque organisation doit l’ajuster à son analyse d’impact sur l’activité, à ses dépendances technologiques, à ses obligations réglementaires et à son niveau de maturité.

Exemple de scénario de crise informatique : une attaque par rançongiciel

Une entreprise de services B2B opère une plateforme de traitement des commandes, un portail clients et plusieurs applications financières interconnectées. Un lundi matin, le centre opérationnel de sécurité détecte des authentifications anormales sur un compte à privilèges. Quelques minutes plus tard, plusieurs serveurs de fichiers deviennent inaccessibles. Des messages de rançon apparaissent sur les postes de travail de plusieurs directions.

L’investigation initiale indique qu’un rançongiciel a chiffré une partie du réseau, y compris des serveurs hébergeant des données partagées et une application utilisée pour préparer les commandes. Les sauvegardes récentes sont présentes, mais leur intégrité n’est pas encore confirmée. Le portail client reste accessible, mais les données affichées ne sont plus synchronisées avec le système de gestion interne.

La difficulté ne réside pas seulement dans le chiffrement. L’organisation doit rapidement répondre à plusieurs questions : la propagation est-elle stoppée ? Des données ont-elles été exfiltrées ? Quelles activités doivent continuer en mode dégradé ? Quel niveau d’information transmettre aux clients, aux collaborateurs, aux autorités et aux partenaires ? La crise informatique devient alors un enjeu de résilience opérationnelle.

Déclenchement : qualifier l’incident sans attendre une certitude totale

La première erreur consiste à attendre l’analyse forensique complète avant de mobiliser la gouvernance de crise. À ce stade, l’incertitude est normale. Le déclenchement doit reposer sur des critères préétablis : indisponibilité d’un service critique au-delà de son délai d’interruption maximal admissible, suspicion de compromission étendue, risque de fuite de données ou impact significatif sur la capacité à servir les clients.

Dans notre scénario, le responsable SSI alerte le responsable de la gestion de crise et le responsable PCA. Une cellule de crise restreinte est convoquée, réunissant au minimum la direction concernée, l’IT, la cybersécurité, la continuité d’activité, les métiers affectés, la communication et le juridique. Selon le contexte, les ressources humaines, la protection des données, les achats ou la sûreté peuvent également être mobilisés.

Le premier point de situation doit distinguer clairement les faits établis, les hypothèses et les décisions à prendre. Cette discipline évite que des informations techniques incomplètes soient interprétées comme des certitudes par la direction ou communiquées prématurément à l’extérieur.

Les premières décisions : contenir, maintenir, documenter

La priorité technique est le confinement. L’équipe IT isole les segments compromis, désactive les comptes suspects, bloque les accès distants non indispensables et suspend, si nécessaire, certains flux entre environnements. Ces mesures peuvent dégrader davantage le service à court terme. C’est un arbitrage fréquent : préserver l’intégrité du système et empêcher la propagation peut primer sur le maintien immédiat de la disponibilité.

En parallèle, les métiers activent les procédures de continuité prévues. Le traitement des commandes peut basculer vers un mode manuel ou vers un outil de secours, avec des règles précises de saisie différée et de rapprochement. Le service client reçoit une consigne homogène : reconnaître l’incident sans spéculer sur son origine, enregistrer les demandes prioritaires et ne pas promettre de délai de rétablissement non validé.

Toute action doit être horodatée et consignée. Ce journal de crise est utile pour piloter la réponse, reconstituer la chronologie, justifier les décisions et préparer le retour d’expérience. Il facilite aussi la coordination lorsque les équipes se relaient pendant plusieurs jours.

Une cellule de crise n’est pas une réunion technique élargie

La cellule de crise pilote les décisions qui dépassent un domaine : priorisation des services à restaurer, arbitrage sur les modes dégradés, validation des messages, information de la direction générale et mobilisation de prestataires. Les experts techniques conservent la conduite de l’investigation et de la remédiation, mais leurs analyses doivent être traduites en impacts opérationnels et en choix de gestion.

Un rythme de points de situation est fixé dès le départ. Il peut être de trente minutes au début, puis s’espacer à mesure que la situation se stabilise. Chaque point doit produire des décisions explicites, un responsable désigné et une échéance. Sans cette rigueur, la crise s’enlise dans une succession de constats techniques sans trajectoire de reprise partagée.

Évaluer les impacts métier et réglementaires

Après le confinement initial, l’organisation doit mesurer les conséquences sur les activités critiques. L’analyse ne se limite pas au nombre de serveurs touchés. Elle porte sur les processus interrompus, les engagements contractuels, les données indisponibles, les risques financiers, les obligations de notification et les effets potentiels sur la réputation.

Dans cet exemple, la préparation des commandes est arrêtée, la facturation est retardée et les équipes commerciales ne disposent plus d’une vision fiable des stocks. Le responsable PCA rapproche ces impacts des objectifs de temps de reprise définis dans l’analyse d’impact sur l’activité. Si l’objectif de reprise de la préparation des commandes est de quatre heures et qu’aucun mode dégradé fiable n’est actif après ce délai, le niveau de crise doit être réévalué.

La question des données personnelles exige une attention particulière. Une indisponibilité n’implique pas nécessairement une violation de données, mais l’hypothèse d’une exfiltration doit être examinée. Le délégué à la protection des données et le juridique évaluent les éléments disponibles, les obligations applicables et les modalités de notification. Les exigences varient selon le secteur, la nature des données, les contrats et les juridictions concernées.

Communiquer avec précision, sans minimiser ni surinterpréter

Une communication de crise informatique efficace repose sur des messages factuels, cohérents et proportionnés. Les collaborateurs doivent savoir ce qu’ils peuvent faire, ce qu’ils doivent éviter et à qui remonter une difficulté. Les clients concernés doivent recevoir une information utile sur l’impact du service, les solutions temporaires disponibles et le prochain point d’information.

Il est préférable de dire que l’organisation enquête sur un incident de cybersécurité affectant certains services plutôt que d’affirmer trop tôt qu’aucune donnée n’a été consultée ou extraite. De la même manière, annoncer une heure de rétablissement sans validation de l’équipe en charge de la reprise crée un risque de perte de confiance si le délai n’est pas tenu.

La communication doit être pilotée, mais elle ne doit pas devenir un goulot d’étranglement. Des modèles de messages préapprouvés, adaptés aux principaux scénarios, accélèrent la réponse tout en garantissant la cohérence avec les exigences juridiques et la stratégie de crise.

Reprendre en sécurité plutôt que restaurer dans la précipitation

La phase de reprise ne commence pas lorsque les fichiers sont restaurés. Elle débute lorsque l’organisation a établi un environnement suffisamment maîtrisé pour redémarrer les services sans réintroduire la compromission. Dans le scénario présenté, les sauvegardes sont testées dans un environnement isolé. Les comptes à privilèges sont réinitialisés, les vulnérabilités exploitées sont traitées et les mécanismes de surveillance sont renforcés avant la remise en production.

L’ordre de restauration est défini selon les priorités métier, les dépendances applicatives et la disponibilité des équipes. Un portail client peut sembler prioritaire parce qu’il est visible, mais il peut être plus pertinent de restaurer d’abord les référentiels, les fonctions d’authentification ou l’application permettant d’exécuter les opérations critiques. Le plan de reprise informatique doit donc être aligné sur les objectifs de continuité, et non seulement sur l’architecture technique.

La validation de la reprise associe les équipes IT et les représentants métier. Un service techniquement disponible n’est pas nécessairement opérationnel : les données peuvent être incomplètes, les interfaces non synchronisées ou les procédures de contrôle non réalisées. Le retour à la normale est progressif et doit inclure le traitement des opérations réalisées en mode dégradé.

Transformer le scénario en exercice utile

Un scénario de crise n’a de valeur que s’il permet de tester des décisions réelles. Un exercice pertinent place les participants face à des informations partielles, des délais contraints et des arbitrages crédibles. Il ne cherche pas à piéger les équipes, mais à évaluer l’efficacité des dispositifs, la clarté des rôles et la capacité à maintenir les activités prioritaires.

Pour cet exemple de scénario de crise informatique, les injects peuvent inclure la découverte d’une exfiltration présumée, l’indisponibilité d’un prestataire cloud, un client majeur demandant des garanties immédiates ou l’apparition d’informations non vérifiées sur les réseaux sociaux. Chaque inject doit être relié à un objectif d’exercice : tester l’escalade, la communication, le mode dégradé, la coordination avec un tiers ou la gouvernance de reprise.

Le retour d’expérience doit déboucher sur des actions attribuées, datées et suivies. Il peut révéler un manque de procédures de bascule, des responsabilités imprécises, des coordonnées obsolètes, une dépendance non recensée ou une compréhension différente des seuils de crise. Ce sont précisément ces écarts, identifiés avant un incident réel, qui renforcent la résilience.

La préparation ne consiste pas à prédire chaque attaque. Elle consiste à donner aux décideurs et aux équipes un cadre fiable pour agir lorsque les informations sont incomplètes et que le temps manque. Des scénarios régulièrement exercés, reliés au PCA, au PRA et à la gouvernance de crise, transforment cette exigence en capacité opérationnelle mesurable.

Cet article est également disponible en :