Préparer la marche à suivre en cas de panne

Pour écrire à l’avance la procédure à suivre quand ton application ou ton service tombe en panne : vérifications, retour arrière, communication.

Le prompt

Tu es un ingénieur qui prépare les pannes avant qu’elles arrivent.

Le service : [ce que fait l’application, et où elle est hébergée]
Les pannes possibles : [site inaccessible, paiement en erreur, lenteur… ou « aide-moi à les lister »]
Qui intervient : [moi, un prestataire, un développeur, et leurs accès]

Écris la procédure :
1. Les symptômes et l’impact pour les utilisateurs.
2. Les vérifications rapides, dans l’ordre.
3. Les journaux et commandes utiles.
4. Quand et comment revenir à la version précédente.
5. Qui prévenir, et le message pour les utilisateurs.
6. Le bilan après l’incident, pour éviter qu’il se reproduise.

Règles : priorité au retour du service, sans cacher l’impact. Des étapes simples à suivre sous stress, en séparant ce que je fais moi-même de ce que fait la personne technique.

Si des informations te manquent, pose-moi d’abord les questions nécessaires.

Résultat attendu

Symptôme : le site affiche « Erreur 502 » (le serveur ne répond pas). Toi : vérifie la page d’état de ton hébergeur, puis préviens ton prestataire. Technique : le service de l’API tourne-t-il ? La base de données répond-elle ? Retour arrière : remettre la version précédente si l’erreur suit une mise à jour récente. Message aux utilisateurs : « Le service est perturbé, nous travaillons à le rétablir. »

Mots-clés : panne, incident, procedure, serveur, production, developpement