Préparer la réponse à un incident de site web

Classer les incidents par impact observable

Listez les parcours essentiels : consultation d’une offre, demande de contact, réservation, paiement, accès à une information de service. Pour chacun, décrivez un échec reconnaissable et son effet sur les visiteurs. Une page lente n’a pas la même urgence qu’une commande confirmée sans enregistrement.

Définissez qui peut constater, qualifier et décider d’une intervention. Le signal peut venir d’une alerte, d’un client ou d’un contrôle manuel. Conservez l’heure, l’URL, le symptôme et les changements récents avant de chercher une cause.

• Parcours critiques connus.
• Critères de gravité reliés à un impact réel.
• Heure et symptômes consignés.

Prévoir les premières actions

Assignez un responsable de coordination et un contact technique de secours. Indiquez où se trouvent l’historique des déploiements, les sauvegardes, la documentation des fournisseurs et le statut des services externes, sans inscrire les secrets dans le plan. Évitez les modifications simultanées non consignées qui rendent le diagnostic plus difficile.

Pour un incident de sécurité ou de données, l’équipe doit suivre ses procédures spécialisées et demander l’appui compétent. Ce guide traite l’organisation d’une réponse au niveau du site ; il ne remplace pas une analyse technique ou juridique propre au cas.

• Coordination et remplaçant désignés.
• Journal unique des actions et décisions.
• Procédure d’escalade connue.

Informer sans promettre une heure inconnue

Préparez un message factuel : fonction touchée, conséquence pour l’utilisateur, solution provisoire lorsqu’elle existe et moment du prochain point. Publiez-le sur un canal encore disponible et indiquez comment contacter l’équipe si le formulaire du site est touché. Ne présentez pas une hypothèse technique comme une cause confirmée.

Adaptez le message aux personnes concernées plutôt que de communiquer toutes les anomalies au même niveau. Si une information publique était erronée, identifiez les pages et communications à corriger. Gardez la même version du fait dans les langues réellement publiées.

• Canal alternatif identifié.
• Message daté et compréhensible.
• Prochain point annoncé sans délai inventé.

Vérifier la reprise et apprendre

Après correction, refaites les parcours affectés sur le site réel : formulaire, paiement, courriels, redirections, contenu et accès mobile selon le cas. Vérifiez que les demandes survenues pendant l’incident ont été retrouvées ou traitées. La disparition d’une alerte ne prouve pas que le parcours est réparé.

Rédigez ensuite une note courte : chronologie, impact, cause établie ou encore incertaine, actions utiles et mesure préventive. Testez le plan de restauration et mettez à jour les contacts ainsi que la procédure avant le prochain incident.

Chronologie fictive du 22 octobre 2026 en UTC : un incident est constaté à 10:00, puis la version précédente est réinstallée à 10:05. À 10:08, l’accueil répond de nouveau avec le statut 200 ; à 10:12, une demande de test échoue encore. Le retour d’une page ne suffit donc pas à annoncer la reprise du formulaire. À 10:20 seulement, le parcours convenu obtient une référence effectivement enregistrée.

Consignez séparément observation, action et hypothèse de cause. Le retour à une ancienne version ne démontre pas que la nouvelle version était seule responsable. Après le contrôle de 10:20, gardez la réconciliation des demandes et la décision du responsable dans la liste de suivi ; ne transformez pas cet essai ponctuel en clôture automatique. Les horaires de l’exemple ne constituent pas un engagement de rétablissement.

• Parcours réels retestés en production.
• Demandes manquées recherchées.
• Plan et responsabilités corrigés après retour d’expérience.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

• Google SRE : Managing Incidents

  Google SRE, consulté le 22 octobre 2026 : coordination et suivi d’incident. La chronologie et les décisions de recette sont fictives.

Décider dans une situation concrète

Exemple fictif : une indisponibilité coïncide avec une mise à jour, sans cause confirmée. Préparez les contacts, observations et décisions de reprise ; revenir en arrière ne suffit pas à conclure que l’incident a été expliqué.

Dans la chronologie, séparez faits observés, actions et hypothèses. Conservez des traces limitées aux besoins d’analyse et indiquez qui peut décider ; évitez toute manipulation destructive qui effacerait une preuve encore utile.

• Informer les visiteurs pendant une indisponibilité

  Préparer un message d’interruption, un contact de secours et des contrôles de reprise sans promettre un délai non confirmé.