Incident informatique : tenir les métiers informés pendant la panne

Prenons une situation fictive : l’application de commandes ne répond plus. Le technicien cherche la panne, le responsable commercial téléphone au DSI et les agences sollicitent directement leurs contacts habituels. Chacun reçoit un fragment d’explication. Une hypothèse technique finit par circuler comme une heure certaine de remise en service.

Je prépare la communication pour éviter cette dispersion. Les métiers ont besoin de savoir ce qu’ils peuvent faire, ce qui reste bloqué et quand ils auront des nouvelles. La cause détaillée viendra ensuite. Voici l’organisation que je proposerais à une DSI dont les spécialistes doivent aussi assurer le dépannage.

Déclencher l’information à partir de l’impact métier

Je définis à froid les situations qui appellent un message collectif : une activité partagée indisponible, une dégradation qui empêche de travailler normalement ou un incident qui suscite des demandes convergentes. Une difficulté isolée reste traitée avec son demandeur. Le nombre de serveurs touchés ne décide pas du besoin de communiquer.

Le premier message part avec les faits disponibles. Si plusieurs signalements concernent les commandes, mais que le périmètre reste incertain, je le dis ainsi. Attendre de connaître toutes les agences concernées laisserait les premières sans réponse. En revanche, je n’annonce pas une panne générale sur la base d’un seul retour non vérifié.

Je note l’heure du constat et sa source : signalements utilisateurs, contrôle du support ou confirmation d’un prestataire. Cela permet de corriger ensuite le périmètre sans réécrire l’histoire. Une précision nouvelle doit apparaître comme une mise à jour identifiable.

Les modèles de communication d’incident d’Atlassian distinguent notamment l’investigation, l’interruption complète et la dégradation partielle. J’en retiens une discipline : décrire l’état réellement connu. Le vocabulaire du message doit permettre au lecteur de comprendre si son activité est concernée, même lorsqu’il ignore le nom technique du service.

Désigner la personne qui parle aux métiers

Au déclenchement, je fais nommer le responsable de l’information et son relais. Cette personne prend les faits auprès des intervenants, prépare les messages et rassemble les questions. Les responsables métier savent à qui s’adresser, sans appeler successivement chaque technicien.

Google distingue coordination, opérations et communication dans son cadre de réponse aux incidents. Une petite DSI peut en reprendre les responsabilités sans reproduire toute l’organisation. Le DSI peut coordonner et communiquer pendant qu’un collègue intervient. Ce cumul doit toutefois rester tenable : quelqu’un absorbé par une manipulation délicate ne peut pas répondre simultanément aux agences.

Je fixe aussi qui peut publier le message courant. Faire valider chaque point de situation par toute la hiérarchie bloque la diffusion. Le responsable désigné doit pouvoir annoncer un impact confirmé dans un cadre convenu. Une décision engageant l’activité, comme suspendre les prises de commandes, reste soumise au responsable métier compétent.

Les dirigeants reçoivent une synthèse adaptée à leurs décisions : activité touchée, solution provisoire et arbitrage attendu. Ils n’ont pas besoin d’assister à chaque échange technique. Cette répartition complète les règles de gestion des interruptions dans la DSI, mais doit être activée explicitement pendant l’incident.

Préparer un message qui aide à agir

J’utilise une trame stable : service et population concernés, effet observé, consigne immédiate, action en cours et prochain point. L’horodatage reste visible, surtout si le texte est transféré ou copié. Une capture d’écran sans date devient vite une information impossible à situer.

Dans notre exemple fictif, le message pourrait prendre cette forme, après vérification des faits et validation de la consigne :

Point de situation à 10 h 15. La saisie des commandes est indisponible pour les agences ayant signalé le problème. Nous vérifions si d’autres sites sont concernés. Ne ressaisissez pas les commandes dont la confirmation manque ; conservez leur référence pour contrôle avec le support. L’équipe recherche l’origine du blocage. Aucun délai de reprise n’est confirmé. Prochain point à 10 h 45, même sans évolution.

Les horaires illustrent la trame ; ils ne constituent pas une cadence recommandée pour toutes les pannes. La consigne doit correspondre au fonctionnement de l’application : on ne copie pas un conseil sur les doublons sans en vérifier la pertinence.

Je retire les noms de composants qui n’aident pas à décider. Je conserve les limites utiles : consultation disponible, saisie bloquée, contournement réservé à un périmètre précis. Une formule générale sur la mobilisation des équipes ne remplace aucune de ces informations.

Tenir les rendez-vous sans inventer une heure de reprise

Je m’engage sur l’heure de la prochaine information, pas sur une heure de rétablissement que personne ne sait défendre.

La cadence dépend de l’activité interrompue, de son échéance et de la capacité à produire une information fiable. Je conviens du prochain rendez-vous à chaque message. Si la situation change avant, notamment si le périmètre s’étend, je communique sans attendre ce rendez-vous.

Le tableau suivant donne des formulations illustratives à adapter aux faits confirmés.

Une estimation du prestataire reste une estimation. Je précise ce qu’elle couvre : fin d’une intervention, remise à disposition d’un composant ou retour effectif du service. Si les contrôles métier viennent après, annoncer directement cette heure comme celle de la reprise serait trompeur.

Répéter un message inchangé peut agacer. Je préfère néanmoins respecter le rendez-vous, en expliquant ce qui reste inconnu, puis adapter la fréquence avec les destinataires. Espacer les points se dit ; disparaître laisse chacun chercher ses propres réponses.

Prévoir un canal qui reste accessible pendant la panne

Je choisis un emplacement de référence pour les mises à jour, puis les moyens d’en signaler l’existence. Une page de statut ne sert à rien si personne ne connaît son adresse. Un message aux responsables de site ne suffit pas s’ils ne savent pas qui doit relayer l’information localement.

Le chapitre Google sur la gestion des incidents souligne la difficulté de dépendre du service à réparer pour coordonner la réponse. Je vérifie donc l’accès à la communication dans le scénario retenu : messagerie indisponible, réseau de site coupé ou authentification inaccessible. Le canal alternatif doit être connu avant l’incident.

Je sépare l’espace de diagnostic de celui destiné aux utilisateurs. Le premier contient des hypothèses et des détails techniques ; le second reçoit les faits validés et les consignes. Sur une page publique, je limite les informations à ce qui peut être diffusé publiquement. Les échanges internes restent dans un espace approprié.

Le dispositif doit aussi permettre de faire remonter un impact nouveau. J’indique comment signaler un autre site touché ou une opération métier bloquée, avec les informations attendues. Ces retours passent par le responsable de communication, qui transmet les éléments utiles aux intervenants sans transformer chaque demande de nouvelles en interruption.

Annoncer la reprise et tester le dispositif à froid

Une correction technique déclenche une vérification, puis un message adapté au résultat. Je demande au métier de confirmer une opération représentative avant d’annoncer le retour du service. Si des traitements restent en attente ou si certains sites demeurent bloqués, le message les distingue explicitement.

L’annonce précise les actions attendues : reprendre le travail, vérifier une transaction incertaine ou attendre une consigne pour les opérations accumulées. Je donne un point de contact pour les difficultés restantes. Le diagnostic de la cause peut continuer après la reprise ; je ne le présente pas comme terminé par commodité.

Pour préparer cela dès la semaine prochaine, je réunirais le support et un responsable métier autour d’une panne fictive. Nous désignerions l’émetteur, écririons le premier message et vérifierions sa réception par le canal prévu. Puis nous rendrions ce canal indisponible dans le scénario pour essayer le relais, sans couper un service réel.

Je conserverais les modèles corrigés, les destinataires et les responsabilités dans une fiche accessible à l’équipe. Après le prochain incident, la revue porterait sur les messages effectivement reçus, les consignes ambiguës et les rendez-vous manqués. C’est ainsi que le dispositif devient utilisable, au-delà d’une procédure rangée dans un dossier.