Un plan de gestion des incidents pour une petite équipe logicielle

Un plan de gestion des incidents doit aider votre équipe à traiter avec méthode le travail interrompu. Choisissez un parcours important de votre logiciel et décrivez comment sa panne est reconnue, qui décide et quelle preuve est nécessaire pour reprendre l’activité.

Nommer le parcours touché

Dans cet exemple fictif, l’incident I-72 touche un portail client. La page d’accueil répond, mais les nouvelles demandes ne peuvent pas être enregistrées intégralement avec une pièce jointe. La demande A-72 et le fichier F-72 servent uniquement d’exemples de test. Il ne s’agit pas d’une panne d’exploitation observée ici.

Pour ce cas, la seule disponibilité de la page d’accueil ne suffit pas à clore l’incident. Le plan nomme le parcours complet de la demande, avec stockage du fichier, contrôle des rôles et travail ultérieur. Il précise aussi quelles modifications sont autorisées pendant l’intervention.

Remplir une fiche d’intervention avec les rôles

Google SRE décrit des rôles clairs, un état de travail à jour et des transferts confirmés. Une petite équipe peut confier plusieurs rôles à une même personne. Il doit néanmoins rester clair qui coordonne, qui modifie le système et qui transmet les informations.

Le tableau décrit des étapes prévues, et non un rétablissement déjà effectué. Désignez un remplaçant et un contact d’escalade joignable. Le document de travail doit rester accessible même si le portail est indisponible.

Planifier la communication comme une tâche distincte

Nommez la personne qui informe les personnes touchées et les services concernés. Un point de situation indique l’impact connu, l’état de l’intervention et le prochain point d’information convenu. Une cause supposée apparaît comme une hypothèse ; une estimation de rétablissement sans fondement n’est pas transmise comme une promesse.

Lors d’un changement de personne pendant l’incident, l’état courant est transmis et la prise en charge est confirmée. Le transfert comprend aussi les actions infructueuses et les contrôles encore ouverts. Un message simplement envoyé ne garantit pas que la nouvelle coordination a été prise en charge.

Distinguer la reprise du travail ultérieur

Avant la reprise, l’équipe vérifie le parcours concerné dans un environnement adapté avec les cas de test convenus. Le retour à un état antérieur dépend aussi des données modifiées entre-temps ; un redémarrage seul ne prouve pas le rétablissement.

Consignez qui autorise la reprise et quelles tâches ouvertes restent sous surveillance. L’analyse ultérieure des causes peut améliorer le plan, sans être confondue avec la première stabilisation. Exercez-vous avec la fiche sur un scénario approuvé et corrigez les contacts, accès ou étapes de contrôle manquants.

Sources

• Google SRE: Managing Incidents