Wiki/.claude/workflows/incident.md

Workflow : INCIDENT RESPONSE

Process de gestion d'incident en prod. Cf doc 18 section 9.

Trigger

L'un des suivants :

• Alerte automatique (UptimeRobot, monitoring, healthcheck failed)
• Report utilisateur (Slack, email, ticket)
• Detection logs anormaux

Severites

Niveau	Definition	Reponse cible
SEV1 (CRITICAL)	Service down complet ou data loss en cours	< 15 min
SEV2 (WARNING)	Degradation majeure, partie indisponible, perte donnees evitee	< 4h ouvrees
SEV3 (INFO)	Bug isole, workaround possible	< 24h ouvrees

Acteurs

• Corentin (oncall principal)
• Yan (oncall backup)
• acadenice-devops (investigation + restore)
• bridge-dev (si bug code)
• bridge-tester (regression test post-fix)

Sequence — SEV1 (service down)

[1] DETECT (auto ou manuel)
    - Alerte UptimeRobot/Slack/email
    - Confirmer le scope : qui est down, depuis quand, quoi est perdu
    - Output : situation comprise

[2] TRIAGE (15 min, Corentin oncall)
    - Severite confirmee SEV1 ?
    - Notifier Yan + Ludo si data loss
    - Annoncer canal #ops + banner status si user-facing :
      "[SEV1] formation-hub - investigating, ETA <unknown>"
    - Output : equipe alertee

[3] INVESTIGATE (acadenice-devops)
    - Verifier containers : docker compose ps
    - Verifier healthcheck : ./scripts/healthcheck.sh
    - Verifier logs : docker compose logs --tail=200 <service>
    - Verifier metrics : CPU, memoire, disque
    - Verifier deps : Postgres, Redis joignables ?
    - Output : root cause identifie ou hypothese forte

[4] MITIGATE (acadenice-devops + bridge-dev si code)
    - Selon root cause :
      * Service down : restart container, verifier ressources
      * DB corruption : restore backup recent
      * Bug code : rollback version precedente (cf release.md)
      * Compromission : rotate secrets, isoler env
      * Disque plein : cleanup logs/backups, upsizing
    - Output : service restored

[5] VERIFY (Corentin + acadenice-devops)
    - Healthcheck full : 4/4 OK
    - Smoke test : ./scripts/smoke-test.sh
    - Tester un flow utilisateur reel
    - Output : confirmation prod restoree

[6] COMMUNICATE (Corentin)
    - Slack/Teams : "[SEV1 RESOLVED] formation-hub - back online. Cause: ..."
    - Email all si data loss : compliance RGPD
    - Update banner status : retire
    - Output : equipe et users informes

[7] POST-MORTEM (sous 7 jours, Corentin + Yan)
    - Creer doc : docs/post-mortems/YYYY-MM-DD-<title>.md
    - Format blameless (focus systeme, pas la personne)
    - Sections : Timeline / Impact / Root cause / AI / Lessons learned
    - Action items (AI) : owner + due date
    - Partager avec equipe
    - Update runbooks si pattern recurrent
    - Output : post-mortem publie + AI ouverts

Sequence — SEV2 (degradation)

Idem SEV1 mais sans urgence < 15 min. Reponse cible 4h ouvrees. Pas d'annonce email all sauf si user-facing.

Sequence — SEV3 (bug isole)

[1] Triager via GitHub/Forgejo issue avec label `bug` + severite `low`
[2] Assigner a bridge-dev pour fix dans la prochaine release
[3] Si workaround dispo : documenter dans le ticket
[4] Pas de post-mortem (sauf pattern recurrent)

Comm template SEV1/2 pendant incident

[SEV1] formation-hub - Service degraded
Symptom: <quoi exactement>
Started: <quand>
Investigating: <ou on en est>
ETA: <estimate restore ou "investigating">
Channel: #ops

Mise a jour toutes les 30 min minimum.

Comm template SEV1 resolved

[SEV1 RESOLVED] formation-hub - back online
Duration down: <X>h<Y>m
Root cause: <one-liner>
Impact: <users affectes, data loss oui/non>
Post-mortem: docs/post-mortems/YYYY-MM-DD-<title>.md (publie sous 7j)

Post-mortem template

docs/post-mortems/YYYY-MM-DD-<titre-incident>.md :

# Post-mortem : <titre incident>

## Timeline (heures locales)
- HH:MM detection
- HH:MM triage
- HH:MM mitigation start
- HH:MM service restored
- HH:MM root cause confirmed

## Impact
- Duree downtime : Xh Ym
- Users impactes : Y
- Data loss : oui/non, si oui : combien et quoi
- Cout estime : XX€ (si quantifiable)

## Root cause
<un paragraphe : ce qui a casse + pourquoi>

## Pourquoi notre monitoring n'a pas alerte plus tot ?
<analyse honnete - blind spot detection ?>

## Action items
- [ ] AI 1 : <description> (owner @who, due YYYY-MM-DD)
- [ ] AI 2 : ...

## Lessons learned
<que retenir pour eviter recurrence>

## Mention blameless
Cet incident n'est pas la faute d'une personne. C'est un manque de garde-fous systeme. AIs au-dessus visent a ajouter ces garde-fous.

Runbooks lies (a creer Phase 1)

Dans docs/runbooks/ :

• runbook-docmost-down.md
• runbook-baserow-down.md
• runbook-disk-full.md
• runbook-postgres-corrupted.md
• runbook-restore-from-backup.md
• runbook-rotate-secrets.md

Format runbook :

# Runbook : <INCIDENT_TYPE>
## Symptomes
## Diagnostic (etapes)
## Resolution (etapes)
## Prevention future
## Rollback / escalade

On-call rotation

Phase 0/1 : Corentin = oncall principal, Yan = backup.

Si embauche futur :

• Rotation hebdo
• Handoff weekly avec recap
• Compensation oncall (jour off ou prime)

Limites

• Pas de SLA strict pour Phase 1 (outil interne, pas critique 24/7). Best effort.
• Pas de status page publique en Phase 1 (info via Slack interne suffit).
• Phase 3+ : si on ouvre l'outil a clients externes, considere SLA + status page.

Notes

• Apres incident SEV1/2 : update doc 18 section 6 (runbooks) si pattern detecte
• Apres 3 incidents similaires en 1 mois : escalade strategique (refactor architecture, ressources additionnelles, etc.)