Qu'est-ce que la réponse aux incidents ?

Qu'est-ce que la réponse aux incidents ?

La réponse aux incidents (incident response) est la manière organisée dont une équipe traite un incident : un événement imprévu qui perturbe un service ou menace la sécurité, comme une panne, une fuite de données ou un compte compromis. Elle couvre la détection du problème, l'évaluation de son ampleur, la limitation des dégâts, le rétablissement du service et l'apprentissage pour que cela arrive moins souvent.

Il en existe deux variantes. Les incidents d'exploitation (pannes, lenteurs, mauvais déploiement) visent à rétablir le service vite. Les incidents de sécurité (intrusion, logiciel malveillant, identifiants volés) ajoutent la conservation des preuves et des obligations légales. Ils partagent la même ossature, c'est pourquoi un seul processus peut couvrir les deux.

Le cycle de réponse aux incidents : pas de nombre de phases unique

Il n'existe pas de nombre de phases universel. Le modèle classique de NIST SP 800-61 révision 2 (2012) en compte quatre : préparation, détection et analyse, confinement, éradication et reprise, puis activité post-incident. En avril 2025, NIST a remplacé cette révision par SP 800-61 révision 3, qui organise la réponse autour des six fonctions du NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) et réinjecte les enseignements dans chacune. Elle précise aussi que chaque organisation doit utiliser le modèle de cycle qui lui convient le mieux. Les quatre phases classiques restent un vocabulaire pratique :

1. Préparation. Se fait avant que quoi que ce soit ne casse : astreintes, circuits d'escalade, runbooks, rôles, modèles de messages, exercices.
2. Détection et analyse. Une alerte se déclenche ou un client signale un problème. Quelqu'un le confirme, évalue la gravité et les personnes touchées, puis déclare l'incident.
3. Confinement, éradication et reprise. On arrête d'abord les dégâts (retour arrière, désactivation d'une fonction, bascule, révocation d'identifiants), puis on supprime la cause et on remet le service en marche.
4. Retour d'expérience. On reconstitue la chronologie, on identifie les causes contributives, on convient d'actions et on les mène à terme. Sans chercher de coupable, sinon les gens cessent de signaler ce qui ne va pas.

Les rôles

Même une équipe de deux personnes gagne à nommer qui fait quoi ; une personne peut cumuler plusieurs rôles :

• Commandant d'incident (incident commander) : dirige la réponse et tranche. Il coordonne au lieu de réparer.
• Intervenants : enquêtent et appliquent le correctif sous la direction du commandant.
• Responsable de la communication : tient clients et collègues informés. Voir communication d'incident.
• Scribe : note la chronologie au fil de l'eau, ce qui facilite beaucoup le retour d'expérience.

Un exemple

L'exemple est fictif. À 14:05, deux sites de supervision signalent que POST /checkout renvoie des erreurs 500. L'ingénieur d'astreinte le confirme, déclare un incident majeur (les niveaux de gravité et leurs noms sont ceux que votre équipe définit) et désigne un commandant. Le responsable de la communication publie "Investigation en cours" sur la page de statut. Un intervenant relie les erreurs au déploiement de 13:50 et le commandant choisit de revenir en arrière plutôt que de déboguer en direct. Les erreurs cessent, l'équipe surveille le taux d'erreurs un moment, puis clôt l'incident. Le retour d'expérience montre que le déploiement avait sauté un contrôle en préproduction ; la liste d'actions ajoute ce contrôle et une alerte plus rapide.

Erreurs courantes

• Pas de responsable unique. Plusieurs personnes qui modifient des choses en parallèle se marchent dessus. Nommez toujours un commandant.
• Enquêter avant de contenir. Il vaut généralement mieux arrêter les dégâts avec un correctif provisoire, puis chercher la cause à tête reposée. Pour un incident de sécurité, préservez les preuves pendant le confinement.
• Alertes bruyantes. Si les alertes sont ignorées, un vrai incident s'y perd. Voir fatigue d'alerte.
• Silence vers l'extérieur. Les clients remarquent la panne avant votre message. Hébergez la page de statut sur une infrastructure qui survit à l'incident.
• Un retour d'expérience sans suite. Un postmortem dont les actions ne sont jamais réalisées ne fait qu'enregistrer à l'avance le prochain incident.
• Lire le runbook pour la première fois pendant l'incident. Entraînez-vous avec des exercices sur table (tabletop) ou des game days.

Incidents de sécurité et délais légaux

Les incidents de sécurité peuvent déclencher des délais légaux. Selon l'article 33 du RGPD, le responsable du traitement doit notifier à l'autorité de contrôle une violation de données à caractère personnel dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si la violation n'est pas susceptible d'engendrer un risque pour les droits et libertés des personnes physiques. Sachez à l'avance qui en décide.

Lien avec les tests et la surveillance

La réponse commence par la détection, qui dépend de l'observabilité : métriques, journaux et contrôles qui vous disent que quelque chose ne va pas avant vos clients. Elle s'inscrit aussi dans l'ingénierie de la fiabilité, où les retours d'expérience sans blâme et les objectifs de niveau de service décident de ce qui est corrigé ensuite. LoadFocus n'est pas une plateforme de réponse aux incidents et ne gère ni vos astreintes ni votre processus. Il apporte deux éléments :

• La surveillance d'API exécute des contrôles scriptés à intervalle régulier (toutes les 5 minutes avec l'offre gratuite) depuis plusieurs de ses 25 régions, vérifie le code de statut, le corps, les en-têtes et le temps de réponse, et alerte par e-mail, Slack, Microsoft Teams ou webhook, et sur les offres payantes aussi par PagerDuty et Opsgenie. Exiger plusieurs échecs consécutifs ou plusieurs sites en échec réduit les fausses alertes.
• Les pages de statut portent le volet public : les mises à jour passent d'investigation à cause identifiée, surveillance puis résolu, et un postmortem peut être publié ensuite. C'est sur la page de statut que les clients regardent en premier.

Les tests de charge relèvent de la préparation : les tests de charge montrent où un système cède sous le volume avant que le trafic réel ne le découvre. Pour les habitudes qui gardent les alertes utiles, voir le guide des bonnes pratiques de surveillance.

Questions fréquentes : réponse aux incidents

Combien de phases compte la réponse aux incidents ?

Cela dépend du modèle. NIST SP 800-61 révision 2 utilisait quatre phases. La révision 3 (avril 2025) rattache la réponse aux six fonctions du Cybersecurity Framework 2.0 et invite chaque organisation à choisir le cycle qui lui convient. L'essentiel est de couvrir préparation, détection, confinement avec reprise, et apprentissage, quel que soit le nom qu'on leur donne.

Qui devrait être commandant d'incident ?

Une personne formée au rôle, pas forcément la plus senior. La mission est de coordonner et de décider, pas de réparer. Beaucoup d'équipes entretiennent un vivier tournant de commandants pour que le rôle ne dépende pas d'une seule personne.

Quelle différence entre incident et problème ?

Dans le vocabulaire ITIL, un incident est une interruption imprévue ponctuelle et un problème est la cause sous-jacente d'un ou plusieurs incidents. Un même problème, comme un pool de connexions saturé, peut provoquer plusieurs incidents au fil du temps.

Faut-il publier les postmortems ?

C'est une question de jugement. Beaucoup d'équipes publient un résumé public plus court pour les incidents majeurs visibles des clients et gardent l'analyse détaillée en interne. Dans les deux cas, dites ce qui s'est passé, ce que vous changez et pour quand.

Comment s'entraîner à la réponse aux incidents ?

Déroulez un scénario lors d'un exercice sur table, organisez un game day en injectant une vraie panne dans un environnement sûr, et laissez les nouveaux astreignants observer une intervention avant d'en diriger une.