Une gestion d’incident relie le signal, l’impact métier, la décision prise et la correction vérifiée après le retour au service.
Un incident ne se résume pas à une erreur serveur. Une facture bloquée ou un export incomplet peut interrompre l’activité alors que le site reste accessible. Le support doit qualifier l’impact et prévenir les personnes concernées.
Détecter et qualifier
Utilisez les métriques, les alertes et les signalements utilisateurs. Notez le début supposé, les fonctions touchées, les entreprises concernées et le niveau de priorité. Les indicateurs d’observabilité doivent aider à trouver ces informations.
Décider une réponse
Une action peut consister à désactiver une fonction, retarder une file ou restaurer une sauvegarde. Notez qui décide et pourquoi. Les messages aux utilisateurs doivent donner un état confirmé et la prochaine mise à jour prévue.
Vérifier le retour
Un service disponible ne prouve pas que les données sont correctes. Vérifiez les files, les doublons, les exports et les opérations en attente. Le plan de reprise doit fournir les contrôles pertinents.
Apprendre sans chercher un responsable
Après l’incident, établissez une chronologie et les facteurs qui ont permis l’erreur. Ajoutez une action mesurable, un propriétaire et une échéance. Une analyse utile modifie une procédure, un test ou une alerte.
Sources : Google SRE, gestion des incidents, NIST, réponse aux incidents.
Conserver les preuves utiles
Archivez la chronologie, les alertes, les décisions et les contrôles de retour dans un emplacement auquel l’équipe peut accéder. Retirez les informations personnelles qui ne sont pas nécessaires à l’analyse. Un résumé public peut différer du document interne, mais les faits opérationnels doivent rester vérifiables.
Ajoutez les scénarios de l’incident à la suite de régression lorsque le défaut peut revenir. Vérifiez l’alerte avec une simulation et mesurez le temps entre détection et prise en charge. Une action terminée sans preuve ne réduit pas le risque de manière démontrable.
Réviser les dépendances
Un incident peut venir d’un service externe, d’une clé expirée, d’une migration ou d’un changement de configuration. Notez la dépendance et la procédure de secours. Les secrets doivent avoir un propriétaire et une date de rotation.
Une revue mensuelle des alertes et incidents montre les problèmes répétitifs. Les actions sans propriétaire doivent être attribuées ou supprimées après décision. La gestion d’incident devient alors une boucle d’amélioration qui touche le code, les données et les procédures.
Organiser les rôles
Pendant l’incident, une personne coordonne, une autre enquête et une autre communique. Ces responsabilités peuvent être réunies dans une petite équipe, mais elles doivent rester explicites. Le coordinateur conserve la chronologie et annonce les décisions ; les intervenants fournissent des faits vérifiables.
Une procédure de relais évite qu’un incident reste attaché à une personne absente. Les accès de secours, le numéro d’escalade et les propriétaires des dépendances doivent être testés périodiquement. Les secrets et les certificats expirés font partie des contrôles opérationnels.
Préparer des exercices
Simulez une file bloquée, une base indisponible ou une réponse externe trop lente. L’objectif est de vérifier les décisions, les outils et la communication, pas de surprendre une personne. Mesurez le temps avant détection, prise en charge et vérification du retour.
Après l’exercice, retirez les accès temporaires et archivez les résultats. Ajoutez les actions qui réduisent réellement la probabilité ou l’impact d’un prochain incident.
Tenir une chronologie
Notez les signaux, les hypothèses, les changements et les résultats avec une heure et une zone clairement définies. Une chronologie évite de confondre le moment où un problème a commencé, celui où il a été détecté et celui où une action a été exécutée.
L’identifiant de corrélation permet de relier une demande, une tâche et une erreur. Utilisez les journaux d’observabilité sans recopier les données confidentielles. Les décisions importantes doivent rester lisibles même après la fin de l’incident.
Réduire l’impact
Une réponse peut désactiver une fonction, limiter le trafic, arrêter un import ou proposer un traitement manuel. Écrivez l’effet attendu et la condition de retour. Une désactivation doit être visible dans l’application si elle change les actions offertes aux utilisateurs.
Un traitement manuel doit conserver une liste des opérations effectuées. Les reprises doivent être idempotentes et vérifiées avant une nouvelle tentative. Le plan de reprise d’activité doit indiquer les données à comparer après restauration.
Communiquer avec précision
Annoncez les fonctions touchées, l’état connu et l’action disponible. Évitez de donner une cause avant qu’elle soit confirmée. Une mise à jour régulière peut dire que l’enquête continue, mais elle doit apporter une information nouvelle.
Le support doit disposer d’un identifiant et d’une procédure pour recueillir un exemple sans demander un fichier sensible par un canal inadapté. Les utilisateurs peuvent alors signaler l’impact sans transmettre plus de données que nécessaire.
Faire une analyse utile
Après le retour, distinguez la cause technique, les conditions facilitantes et les moyens de détection. Ajoutez des actions vérifiables : un test de concurrence, une alerte sur l’âge d’une file, une limite d’export ou une procédure de rotation de secret. Attribuez chaque action à une personne et une échéance.
Relisez les actions après quelques semaines. Une tâche fermée doit montrer la correction ou le test qui la confirme. L’analyse devient ainsi une amélioration durable des parcours et de l’exploitation.