Temps de lecture estimé : 3 min · Publié le
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.
- Parcours réels retestés en production.
- Demandes manquées recherchées.
- Plan et responsabilités corrigés après retour d’expérience.
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.
- Accès et données personnelles
Actualité à mettre en perspective
Documents de référence
Complément de lecture
Si un visiteur ne peut pas ouvrir le site, ce diagnostic aide à comparer appareils, réseaux et services avant de conclure à une panne du serveur. Il complète la communication d’incident en distinguant un problème d’accès local d’un problème du site. Les preuves serveur et les résultats du parcours restent à examiner séparément.
Contenu mis à jour le