Checklist de gestion de crise lors d’une panne IT | badr
Il y a quelques années, j’ai vécu l’une des nuits les plus longues de ma carrière. Une panne majeure frappait Avito en plein pic de trafic, des milliers d’utilisateurs ne pouvaient plus accéder au service, et faute de véritable gestion de crise, l’équipe technique tournait en rond sans procédure claire.
Cette expérience m’a appris, parfois douloureusement, ce que signifie vraiment piloter une gestion de crise dans un environnement IT. Voici la checklist que j’aurais voulu avoir ce soir-là, et les leçons que j’en ai tirées.
Ma checklist de gestion de crise : Ce que j’ai appris lors d’une panne majeure chez Avito
Temps de lecture : ~6 min
Sommaire
- Ce que j’ai compris sur la gestion de crise en IT
- Ma checklist pour les deux premières heures
- Comment structurer une cellule de crise IT efficace
- Le plan de communication interne et externe
- L’encadré « À faire / À ne pas faire »
- Le post-mortem : l’étape que trop d’équipes sautent
- FAQ
- La gestion de crise IT comme réflexe de maturité organisationnelle
Ce que j’ai compris sur la gestion de crise en IT
Les spécificités de la gestion de crise en environnement IT
La gestion de crise, dans sa définition la plus simple, consiste à planifier, organiser et coordonner des actions pour faire face à des événements graves qui perturbent le fonctionnement normal d’une organisation. Dans l’IT, ces événements prennent des formes très concrètes : une panne d’infrastructure, une cyberattaque, une mise en production ratée, ou encore une corruption de base de données critique.
Ce soir-là chez Avito, le problème n’était pas uniquement technique. Le vrai problème, c’était l’absence de structure. Personne ne savait précisément qui devait prendre la parole, qui devait décider, ni dans quel ordre agir. On a perdu un temps précieux à se coordonner plutôt qu’à résoudre. C’est ce constat qui m’a poussé à construire une méthode reproductible, étape par étape.
Une crise IT suit généralement quatre grandes phases : identifier et évaluer le problème, activer une cellule de réponse, communiquer de façon maîtrisée, puis analyser ce qui s’est passé pour ne pas répéter les mêmes erreurs. La difficulté, c’est que ces phases se chevauchent sous la pression, et que sans préparation, on saute directement à « réparer » en oubliant tout le reste.
Ma checklist pour les deux premières heures
Les 5 réflexes à adopter dans les deux premières heures
Les deux premières heures d’une crise sont les plus déterminantes. Ce que tu fais (ou ne fais pas) dans cette fenêtre conditionne tout ce qui suit. Voici les cinq réflexes que j’applique systématiquement aujourd’hui.
1. Identifier les faits techniques avec précision. Avant toute action, il faut poser les bases : quelle est la nature de l’incident (panne réseau, erreur de déploiement, attaque externe…), quel est le périmètre affecté (quelles applications, quels utilisateurs, quelles données), et depuis quand exactement. Sans cette cartographie initiale, les équipes travaillent dans le flou.
2. Alerter les bons interlocuteurs, pas tout le monde. En cas de panne majeure, la tentation est d’envoyer des messages dans tous les sens. C’est une erreur. Il faut alerter l’on-call technique ou l’équipe SRE en premier, puis remonter vers le responsable IT ou le CISO si des données personnelles sont concernées, et enfin impliquer la direction ou la communication uniquement si l’impact client ou médiatique est avéré.
3. Geler toute communication externe non validée. C’est une règle absolue. Désigner un seul responsable de la communication de crise, et interdire toute prise de parole non approuvée vers les clients ou la presse. Un message mal formulé en pleine panne peut aggraver la situation bien au-delà de la panne elle-même.
4. Organiser les rotations d’équipe dès le départ. Une crise longue épuise les équipes. Planifier les relèves dès la première heure évite les erreurs liées à la fatigue et préserve la capacité de jugement des personnes en première ligne.
5. Préparer l’accès aux ressources critiques. Logs, outils de supervision, documentation d’architecture, contacts des prestataires hébergeurs ou éditeurs : tout cela doit être accessible immédiatement, sans avoir à chercher pendant la crise.
Comment structurer une cellule de crise IT efficace
Les rôles essentiels au sein de la cellule de crise
Une cellule de crise IT n’est pas une réunion de plus. C’est un dispositif temporaire avec des rôles définis, des règles de fonctionnement claires et un objectif unique : reprendre le contrôle de la situation le plus vite possible.
Les rôles clés à définir à l’avance sont les suivants : un leader de crise qui prend les décisions et assume la responsabilité, un coordinateur qui gère le flux d’information entre les équipes, des responsables techniques par domaine (infrastructure, réseau, sécurité, applicatif), et un relais vers les RH et la communication. Ce n’est pas la taille de l’équipe qui compte, c’est la clarté des responsabilités.
Le leader de crise, en particulier, joue un rôle humain autant que technique. Les études sur la gestion des situations critiques au travail montrent que les leaders efficaces restent calmes, informent clairement leurs équipes sur ce qui est connu et ce qui ne l’est pas encore, et expliquent ce qui est fait pour gérer la situation. Ce comportement réduit l’anxiété collective et maintient la capacité d’action de chacun.
Lors de la panne chez Avito, l’un des apprentissages les plus durs a été précisément là : en l’absence de leader clairement identifié, chacun tentait de tout faire en même temps, et personne ne gardait la vue d’ensemble. Depuis, je considère que nommer un leader de crise est la première décision à prendre, avant même de chercher la cause technique.
Le plan de communication interne et externe
La communication pendant une crise IT se joue sur deux fronts distincts, et les confondre est une source d’erreur fréquente.
En interne, l’objectif est de maintenir les équipes alignées sur l’état de la situation, les priorités techniques et les actions en cours. Des points de situation réguliers (toutes les 30 à 60 minutes selon l’intensité de la crise) permettent d’éviter les rumeurs, les doublons d’action et la perte de cohésion. Ces points doivent être courts, factuels et centrés sur trois questions : où en est-on, que fait-on maintenant, quand est le prochain point.
En externe, la communication doit être validée par la cellule de crise avant tout envoi. Les messages types à préparer à l’avance incluent une notification initiale d’incident (sans détails techniques sensibles), des mises à jour régulières sur l’avancement, et un message de résolution avec un résumé de l’impact. Une page de statut dédiée (status page) est un outil précieux : elle centralise l’information et réduit la pression sur les équipes support.
L’encadré « À faire / À ne pas faire »
| À faire | À ne pas faire |
|---|---|
| Nommer un leader de crise dès le début | Laisser plusieurs personnes prendre des décisions en parallèle |
| Documenter chaque action en temps réel | Agir sans tracer ce qui a été fait |
| Communiquer régulièrement en interne | Laisser les équipes dans l’incertitude |
| Valider chaque message externe avant envoi | Publier des estimations non confirmées |
| Organiser les rotations pour éviter la fatigue | Garder les mêmes personnes mobilisées pendant 12 heures d’affilée |
| Déclencher le PRA si les seuils d’impact sont atteints | Attendre trop longtemps par crainte de « sur-réagir » |
Le post-mortem : l’étape que trop d’équipes sautent
Une fois la crise résolue, la tentation est forte de passer à autre chose rapidement. C’est une erreur. Le post-mortem (souvent appelé post-mortem dans les environnements tech) est l’étape qui transforme une crise en apprentissage durable.
Un bon post-mortem analyse quatre dimensions : le délai de détection (combien de temps s’est-il écoulé entre le début de l’incident et la première alerte), le délai de réaction (combien de temps entre l’alerte et l’activation de la cellule de crise), l’efficacité de la communication (interne et externe), et la qualité des procédures techniques appliquées. Il ne s’agit pas de chercher des coupables, mais d’identifier les failles systémiques et d’améliorer le plan pour la prochaine fois.
Après la panne chez Avito, notre post-mortem a révélé trois choses : nos alertes de monitoring n’étaient pas calibrées pour détecter ce type d’incident, notre documentation de procédure de bascule était incomplète, et nous n’avions pas de message type prêt pour informer les utilisateurs. Ces trois points sont devenus des actions correctives concrètes, avec un responsable et une date limite.
FAQ
Qui prévenir en premier lors d’une panne majeure ?
La priorité va toujours à l’équipe technique on-call ou SRE, qui peut évaluer rapidement la nature et le périmètre de l’incident. Ensuite seulement, selon la gravité, on remonte vers le responsable IT, le CISO si des données sont exposées, puis la direction si l’impact client est significatif. Alerter trop de monde trop tôt crée de la confusion sans apporter de valeur.
Comment communiquer avec les clients pendant une crise IT ?
La règle de base est de communiquer tôt, même avec peu d’information, plutôt que d’attendre d’avoir tous les détails. Un message simple du type « Nous sommes au courant d’un incident affectant le service, nos équipes sont mobilisées » vaut mieux qu’un silence de deux heures. Les mises à jour régulières, même courtes, maintiennent la confiance. Toute communication doit être validée par le responsable désigné avant publication.
Quand faire appel à un prestataire externe en gestion de crise IT ?
Faire appel à un expert externe est pertinent dans plusieurs cas : lorsque l’incident dépasse les compétences internes (cyberattaque sophistiquée, compromission de comptes administrateurs), lorsque la durée de la crise s’étend et que les équipes sont épuisées, ou lorsque des obligations réglementaires imposent une réponse formalisée (notification à l’ANSSI, au CERT-FR ou à la CNIL en cas de fuite de données personnelles). Idéalement, ces prestataires sont identifiés et contractualisés avant la crise, pas pendant.
La gestion de crise IT comme réflexe de maturité organisationnelle
Une panne majeure n’est jamais agréable à vivre, mais elle peut devenir l’un des meilleurs investissements en termes de maturité organisationnelle, à condition d’en tirer les bonnes leçons. La gestion de crise n’est pas une compétence réservée aux grandes DSI : c’est un réflexe que toute équipe technique peut et doit cultiver, quelle que soit sa taille.
Si tu veux aller plus loin sur ces sujets et découvrir d’autres retours d’expérience concrets, tu peux explorer les ressources disponibles sur badrlaghmari.com.