Incident de production : les informations à préparer avant d’appeler

Décrire l’impact observable, pas la cause supposée

Commencez par ce que vous voyez : les services affectés, les utilisateurs concernés, l’heure de début et les parcours qui fonctionnent encore. Une page qui ne répond plus et une transaction qui échoue ne mobilisent pas les mêmes investigations, et la seconde est souvent plus grave que la première.

Séparez explicitement les faits observés des hypothèses. « La base est saturée » est une hypothèse ; « les commandes échouent depuis 14 h 20 avec une erreur 500 » est un fait. Une hypothèse énoncée comme un fait oriente l’investigation dans une direction, et il faut ensuite du temps pour en revenir.

Retracer les derniers changements

Recensez les déploiements, modifications d’infrastructure, changements de configuration et opérations sur les données proches du début de l’incident. Conservez leurs références : numéro de version, identifiant de livraison, ticket, auteur.

Une corrélation temporelle aide à investiguer sans constituer, à elle seule, une preuve de cause. Beaucoup d’incidents surviennent après une livraison sans être causés par elle : un changement de volume, un certificat expiré ou une tâche planifiée peuvent coïncider.

Organiser les échanges avant de les subir

Identifiez deux personnes : un contact capable d’autoriser les actions qui modifient le système, et un interlocuteur technique qui connaît l’application. Sans la première, l’intervention s’arrête à chaque décision ; sans la seconde, chaque question coûte un aller-retour.

Convenez d’un canal d’échange unique et d’un rythme de points de situation. Notez les actions déjà réalisées : c’est ce qui évite les doublons et, surtout, les changements contradictoires lancés en parallèle par deux personnes qui s’ignorent.

Partager les éléments utiles, sans les secrets

Préparez les messages d’erreur et les extraits de journaux pertinents, en retirant les données personnelles qui ne servent pas au diagnostic. Les accès techniques s’organisent par un canal adapté, avec un périmètre et une durée définis.

• Aucun mot de passe, clé d’API ou jeton dans un formulaire ou un e-mail.
• Des extraits de journaux datés, avec le fuseau horaire.
• Les codes d’erreur exacts plutôt que leur reformulation.
• Une capture du parcours qui échoue, côté utilisateur.

Ce qui change après le rétablissement

Une réponse HTTP correcte ne prouve pas que le service est rétabli : les parcours métier concernés doivent être vérifiés avec vos interlocuteurs. Une commande passe-t-elle réellement de bout en bout, e-mail de confirmation compris ?

Le compte rendu distingue ensuite trois choses : le correctif immédiat, la cause identifiée ou encore incertaine, et les actions de prévention. Confondre les trois donne un document rassurant et inutile.

Un incident bien documenté vaut mieux qu’un incident rapidement oublié : c’est le seul moment où l’organisation apprend quelque chose de son système.