Prompt d'analyse de cause racine d'un bug

Quand l'utiliser

Utilisez ce prompt lorsqu'une panne imprévue survient en production et que vous avez besoin d'un document post-mortem structuré et non accusatoire (blameless). Remplacez les détails de l'incident par vos propres traces de pile (stack traces), journaux d'événements et données de télémétrie avant de le diffuser aux parties prenantes de l'ingénierie.

Le prompt

## Rôle
Agis en tant qu'ingénieur fiabilité senior (Staff Reliability Engineer). Fais preuve d'un jugement diagnostique rigoureux tout en veillant à ce que les explications techniques restent claires, tant pour les ingénieurs que pour les partenaires transverses.

## Contexte
KitePay, une plateforme de paiement en ligne, a subi une interruption de traitement des paiements de 27 minutes sur son cluster d'API principal. La télémétrie des erreurs a révélé un pic soudain d'erreurs HTTP 504 Gateway Timeout à la suite du déploiement de la version v2.14.0. Cette mise en production a introduit une recherche sur clé étrangère non indexée dans la table `merchant_settlements` lors de l'autorisation des jetons, entraînant l'épuisement du pool de connexions PostgreSQL. Le rollback vers la version v2.13.9 a résolu les timeouts.

## Objectif
Rédiger une analyse de cause racine (RCA) complète expliquant comment la modification du code a déclenché la saturation des connexions à la base de données, comment la défaillance a été atténuée et comment empêcher sa récurrence.

## Public cible
Les lecteurs principaux sont les ingénieurs backend et les responsables d'ingénierie (Engineering Managers). Fournis suffisamment de détails architecturaux pour justifier les travaux correctifs sans tomber dans des digressions théoriques inutiles.

## Exigences
Un document d'analyse RCA de 400 à 600 mots comprenant : un tableau récapitulatif de l'incident ; une chronologie séquentielle de la détection, de la réponse et de la résolution ; une décomposition technique de la cause racine via la méthode des 5 Pourquoi ; les actions correctives immédiates effectuées ; et des mesures préventives à long terme. Inclus des recommandations précises sur les requêtes et index de la base de données.

## Contraintes
N'invente aucun composant d'infrastructure non mentionné, aucun chiffre de latence arbitraire, aucun montant de dédommagement client ni aucune dépendance de service non vérifiée. Limite les constats techniques à la base de données et à la défaillance du pool de connexions fournies. Indique clairement les facteurs spéculatifs comme étant des hypothèses non confirmées.

## Ton et style
Sois objectif, constructif (culture du "sans blâme") et rigoureux sur le plan analytique. Utilise un langage technique simple, des listes à puces concises et une hiérarchie structurelle claire. Évite les formulations défensives, les approximations et les promesses vagues.

## Format de sortie
Présente d'abord le document RCA avec des titres markdown distincts. Insère la chronologie et les responsables des actions correctives dans des tableaux markdown propres. Conclus par une liste de contrôle (checklist) de vérification détaillant les alertes de télémétrie et les règles de revue de code qui doivent être auditées.

## À éviter
Évite les conclusions superficielles telles que "l'erreur humaine", les affirmations infondées de zéro indisponibilité, ainsi que l'omission du mécanisme spécifique de requête en base de données ayant causé l'épuisement du pool de connexions.

## Critères de succès
Un lead tech ou responsable d'ingénierie doit pouvoir lire le document, expliquer le mécanisme exact de la défaillance, comprendre pourquoi le rollback a rétabli le service et assigner des tâches préventives concrètes.

## Questions de clarification
Pose un maximum de trois questions ciblées uniquement s'il manque des informations architecturales critiques. Dans le cas contraire, poursuis en utilisant les faits du scénario, énonce tes hypothèses de travail et présente les vérifications de télémétrie nécessaires pour valider le correctif.

Pourquoi ça fonctionne

• Le scénario fournit au modèle un mécanisme d'échec technique concret plutôt que de le laisser basculer vers des poncifs génériques de crash serveur.
• Les exigences imposent des livrables d'ingénierie standards tels que l'analyse des 5 Pourquoi et un calendrier de remédiation précis.
• Les contraintes empêchent le modèle d'halluciner des failles d'infrastructure hors sujet ou des métriques manquantes.
• Les critères de succès garantissent que le rapport obtenu est immédiatement révisable et exploitable par les leads techniques.

Personnalisez-le

Créez une version sur mesure avec PromptDeck en remplaçant le scénario fictif par votre propre télémétrie d'incident, vos horodatages et votre stack architecturale. Conservez la checklist de vérification afin que les tâches d'ingénierie préventive fassent l'objet d'un audit en bonne et due forme.