Debug erreur production depuis logs

---
name: debug-erreur-production-logs
description: "Analyse une stacktrace ou un extrait de logs Sentry, Datadog, Logtail, Axiom ou Vercel pour produire 3 à 5 hypothèses de root cause classées par probabilité, avec pour chacune les vérifications à faire dans le code, la requête SQL à lancer ou la commande à exécuter. À utiliser quand un dev ou un SRE découvre une erreur en production et veut structurer une investigation rapide plutôt que de partir à l'aveugle dans la base de code."
metadata:
  iaskills_title: "Debug erreur production depuis logs"
  metier_slug: dev
  metiers:
    - Dev
  secteur: "Tech & DSI"
  tier: free
  compatible:
    - claude-code
    - cowork
    - cursor
    - codex
  version: "1.0.0"
  author: "iaskills"
  editorial:
    pitch: "Transforme une stacktrace floue ou un graphique d'erreurs en plan d'investigation actionnable. 3 à 5 hypothèses classées, vérifications associées, pas de panique."
    long_description: "En production, l'erreur arrive rarement seule, la stacktrace est tronquée, et le réflexe d'ouvrir 12 onglets dans Sentry consomme une heure pour rien. Ce skill structure la première demi-heure d'investigation. Tu colles une stacktrace, un extrait de logs Datadog ou un dump Sentry, et le skill produit une note d'investigation : contexte reconstruit, 3 à 5 hypothèses de root cause classées par probabilité, vérifications concrètes pour chacune (fichier à ouvrir, requête SQL, commande shell, panneau Datadog à consulter), signaux d'urgence à vérifier (RGPD, données sensibles, SLA), et plan de communication si l'incident escalade. Le skill reste strict sur le périmètre : il ne corrige pas le bug, il guide l'investigation pour identifier la cause avant de toucher au code."
    bullets:
      - "Reconstruit le contexte depuis stacktrace ou logs"
      - "3 à 5 hypothèses classées par probabilité"
      - "Vérifications concrètes par hypothèse (fichier, SQL, cmd)"
      - "Flag RGPD, secrets, SLA et données sensibles"
      - "Note d'investigation prête à coller dans Notion ou Slack"
      - "Périmètre strict : guide l'enquête, ne patch pas"
    exemple_avant: "Erreur Sentry remontée à 14h12, message TypeError: cannot read properties of undefined reading 'userId'. Le dev ouvre Sentry, scrolle la stacktrace, va dans le code, ouvre 3 fichiers, lit 200 lignes, repart sur Sentry parce qu'il a oublié quelle release. 45 minutes après, il a juste reconstitué le contexte mais pas testé une hypothèse."
    exemple_apres: "Note d'investigation en 12 lignes : contexte (release v2.18, endpoint /api/orders, 23 utilisateurs touchés en 8 min, débuts à 14h04 UTC). 4 hypothèses classées : 1. payload Stripe webhook sans champ user (probable, à vérifier dans Sentry breadcrumbs), 2. race condition session expirée (peu probable, vérifier middleware auth), 3. migration DB sur table users (à vérifier dans Supabase logs), 4. caching CDN obsolète. Pour chaque hypothèse : la commande à lancer ou le fichier à ouvrir. Flag RGPD : pas de PII exposée dans la stacktrace, OK."
    recommended_metiers:
      - dirigeant-pme
    secteurs:
      - tech-dsi
      - startup-vc
      - assurance-banque
      - marketing-commerce
      - tourisme-hotellerie
      - secteur-public-associatif
    metiers_individuels:
      - dev-backend
      - dev-frontend
      - devops
      - cto
      - architecte-si
      - chef-de-projet-it
      - rssi-cybersecurite
      - mlops
      - qa-engineer
    connecteurs:
      - slack
      - notion
---

# Debug erreur production depuis logs

## Quand utiliser ce skill

Déclencher quand un dev, un SRE, un tech lead, un DevOps ou un CTO d'astreinte découvre une erreur en production via Sentry, Datadog, Logtail, Axiom, Vercel, Grafana ou un canal d'alerte, et veut structurer la première demi-heure d'investigation avant de toucher au code. Le skill produit une note d'investigation, pas un correctif.

Ne pas utiliser pour un bug local en développement, pour une demande de revue de code, pour un refactor opportuniste, ou pour générer le patch lui-même. Pour le post-mortem une fois l'incident résolu, basculer vers `rca-post-mortem-blameless`.

## Ce que tu dois faire

1. Récupérer auprès de l'utilisateur les éléments factuels : stacktrace ou extrait de logs (Sentry, Datadog, Logtail, Vercel, etc.), horodatage de la première occurrence, release ou commit déployé, environnement (production, staging, preview), volume d'erreurs observé et tendance.
2. Reconstituer le contexte en 3 à 5 lignes : quel service, quel endpoint ou job, quelle release, combien d'utilisateurs touchés, depuis quand. Si une donnée critique manque, demander avant d'inventer.
3. Identifier 3 à 5 hypothèses de root cause distinctes et les classer par probabilité estimée. Prioriser les hypothèses récentes (déploiement, migration, config) avant les hypothèses dormantes (race condition, edge case).
4. Pour chaque hypothèse, produire une vérification concrète et exécutable : fichier précis à ouvrir, requête SQL à lancer sur la DB, commande shell ou kubectl, panneau Datadog ou Sentry breadcrumb à consulter, valeur d'env var à vérifier.
5. Flag les signaux d'urgence : exposition de PII dans les logs, secret hardcodé visible dans la stacktrace, dépendance externe down, SLA en risque, déclencheur RGPD (article 33 si violation données personnelles), incident sécurité.
6. Si le contexte le justifie, suggérer une mitigation immédiate non destructive : rollback de release, désactivation d'un feature flag, scale up temporaire, communication client. Ne jamais suggérer de désactiver une garantie de sécurité, un contrôle, ou une alerte.
7. Renvoyer la note d'investigation en Markdown, prête à coller dans Notion ou dans un thread Slack incident.