Continuity Plan Agent

Documente "quoi faire quand ça casse" et "comment revenir en arrière au niveau métier". Ce n'est pas de l'observabilité : c'est un runbook opérationnel.

Quand l'utiliser

Obligatoire si au moins un trigger est vrai :

• Changement DB à risque (migration, backfill, suppression, transformation)
• Dépendance externe critique (paiement, email transactionnel, stockage, signature, webhooks)
• Process métier non réversible (facturation, signature, droits/rôles, clôture/validation)
• Charge/volume pouvant dégrader la prod (listes/recherche, jobs longs, fichiers volumineux)
• Surface sécurité accrue (auth, permissions, PII)
• Ajout/modification de cron, queue, jobs ou configuration sensible

Quand ne pas l'utiliser

• Feature mineure sans impact data ni dépendance externe
• Bug fix simple sans risque de régression métier
• Modification UI uniquement

Entrées requises

Entrée	Source
Feature Spec	Flux métier, cas d'erreur
Domain & Database	Migrations, données impactées
API Contract	Dépendances externes
Release Plan	Étapes de déploiement

Sortie attendue

Le repo applicatif DOIT contenir docs/ops/continuity.md (source de vérité unique, versionnée).

• Si absent, il doit être créé à l'initialisation du projet avec un template minimal.
• Le projet DOIT exposer une page admin /admin/continuity qui affiche ce Markdown.

Ajouter ou mettre à jour une section dans docs/ops/continuity.md :

## [Nom de la capability]

### What can go wrong
- [Risque 1 : ex. "Webhook Stripe échoue, paiement non enregistré"]
- [Risque 2 : ex. "Job d'import timeout sur fichier > 10MB"]
- [Risque 3 : ex. "Migration corrompt les données existantes"]

### Detection
| Symptôme | Log/Alerte |
|----------|------------|
| Paiement non crédité | `payment.failed` dans logs + absence en DB |
| Import bloqué | Job `ProcessImport` en status `failed` |
| Données incohérentes | Requête de vérification : `SELECT ... WHERE ...` |

### Rollback
| Situation | Procédure |
|-----------|-----------|
| Migration échouée | `php artisan migrate:rollback --step=1` |
| Données corrompues | Restaurer backup + re-run migration corrigée |
| Webhook défaillant | Désactiver endpoint + replay manuel |

### Data recovery
- Backup : [fréquence, rétention, localisation]
- Re-run possible : [Oui/Non, conditions d'idempotence]
- Données perdues : [Quoi, impact métier, mitigation]

### Runbook (3 actions max)
1. [Action immédiate : ex. "Mettre en maintenance"]
2. [Diagnostic : ex. "Vérifier logs : `tail -f storage/logs/laravel.log | grep payment`"]
3. [Correction : ex. "Relancer le job : `php artisan queue:retry {id}`"]

> **Si > 3 actions nécessaires** : c'est un signal que la feature nécessite un feature flag, circuit breaker ou mode maintenance dédié. Simplifier l'architecture avant de documenter un runbook trop complexe.

Page admin obligatoire : /admin/continuity

Chaque projet DOIT exposer cette page :

Critère	Exigence
URL	/admin/continuity (existe dans tous les projets)
Accès	Admin-only (rediriger vers login ou 403/404 si non admin, jamais public)
Source	Afficher docs/ops/continuity.md depuis le filesystem du build (pas de duplication)
Rendu	Texte brut accepté ; si rendu Markdown, interdire tout HTML raw (pas de rehype-raw)
Auto-update	Tout changement dans docs/ops/continuity.md visible après commit + redeploy

Contenu obligatoire de la page /admin/continuity

La page doit afficher :

1. En-tête : Titre "Plan de continuité" + date de dernière mise à jour (commit date)
2. Contact support : Coordonnées de l'équipe de développement
3. Contenu : Le fichier docs/ops/continuity.md rendu

Bloc contact obligatoire en haut de page :

## Contact support

| Urgence | Contact | Délai réponse |
|---------|---------|---------------|
| Critique (prod down) | dev@vigee.fr | < 2h (heures ouvrées) |
| Haute (feature KO) | dev@vigee.fr | < 4h (heures ouvrées) |
| Standard | dev@vigee.fr | < 24h |

> En dehors des heures ouvrées : laisser un message, traité dès le lendemain matin.

Escalade et responsabilités

Niveau	Qui	Action
N1 - Détection	Équipe client / Monitoring	Identifier le symptôme, consulter /admin/continuity
N2 - Diagnostic	Vigee (dev@vigee.fr)	Appliquer le runbook, identifier la cause
N3 - Résolution	Vigee	Fix + déploiement + post-mortem si critique

Revue périodique

Fréquence	Action
À chaque release majeure	Vérifier que les runbooks sont à jour
Trimestriel	Audit des sections : supprimer l'obsolète, ajouter le nouveau
Après incident	Mise à jour immédiate du runbook concerné

Sécurité du runbook

• Aucun secret dans docs/ops/continuity.md (pas de tokens, clés API, mots de passe)
• Le fichier est versionné et potentiellement visible par tous les contributeurs du repo
• Utiliser des références (voir .env, Dashboard Stripe) plutôt que des valeurs

Andon (STOP)

Conditions bloquantes

• docs/ops/continuity.md n'existe pas (ou template minimal absent)
• Bloc "Contact support" absent du fichier (pas de coordonnées Vigee)
• /admin/continuity n'existe pas dans le projet
• /admin/continuity n'est pas protégé admin (accessible publiquement)
• Runbook contient des secrets (tokens, clés, mots de passe en clair)
• Rendu Markdown permet HTML brut (rehype-raw activé)
• Trigger présent mais aucune section continuity ajoutée/mise à jour
• Runbook avec plus de 3 étapes sans feature flag/circuit breaker prévu
• Pas de procédure de rollback testée (staging, dry-run ou plan documenté)
• Backup inexistant ou non vérifié pour données critiques
• Dépendance externe sans fallback ni monitoring

Checklist Done

- [ ] `docs/ops/continuity.md` existe (créé si nécessaire) et respecte le template
- [ ] Bloc "Contact support" présent en haut du fichier (dev@vigee.fr)
- [ ] `/admin/continuity` existe et est admin-only
- [ ] `/admin/continuity` affiche le contenu du Markdown (pas de duplication)
- [ ] Trigger identifié et documenté
- [ ] Section capability ajoutée/mise à jour dans `docs/ops/continuity.md`
- [ ] What can go wrong : 3 risques max, réalistes
- [ ] Detection : symptômes + logs/alertes identifiés
- [ ] Rollback : procédure testée (staging, dry-run, ou plan documenté si staging impossible)
- [ ] Data recovery : backup vérifié, idempotence confirmée si re-run
- [ ] Runbook : 3 actions max (si > 3 : prévoir feature flag/circuit breaker)
- [ ] Aucun secret présent ; rendu safe (pas de HTML raw)

Exemple minimal

Contenu de docs/ops/continuity.md pour la capability "Webhooks" :

# Plan de continuité

## Webhooks (Stripe, Resend)

### What can go wrong
- Webhook Stripe échoue → paiement reçu mais non crédité en DB
- Double webhook → double crédit (si pas d'idempotence)
- Endpoint webhook down → événements perdus pendant l'indisponibilité

### Detection
| Symptôme | Log/Alerte |
|----------|------------|
| Paiement client non visible | Absence `webhook.received` dans logs |
| Double crédit | 2 entrées même `event_id` |
| Webhook timeout | `504` dans logs + alerte provider |

### Rollback
| Situation | Procédure |
|-----------|-----------|
| Webhook raté | Replay via dashboard provider |
| Double traitement | Reverser manuellement + fix idempotence |
| Endpoint cassé | Rollback code + redeploy |

### Data recovery
- Backup : quotidien, 30 jours, S3
- Re-run : Oui, webhook idempotent sur `event_id`
- Données perdues : Aucune si replay < 30 jours

### Runbook
1. Vérifier statut provider : Dashboard Stripe/Resend → Events
2. Checker logs : `grep "webhook" storage/logs/laravel.log | tail -50`
3. Replay événement : Dashboard provider → Webhooks → Retry

La page /admin/continuity affiche ce fichier tel quel.

Organisation du fichier docs/ops/continuity.md

# Plan de continuité

> Dernière mise à jour : [date du dernier commit]

## Contact support

| Urgence | Contact | Délai réponse |
|---------|---------|---------------|
| Critique (prod down) | dev@vigee.fr | < 2h (heures ouvrées) |
| Haute (feature KO) | dev@vigee.fr | < 4h (heures ouvrées) |
| Standard | dev@vigee.fr | < 24h |

---

## Auth & Sessions
[...]

## Paiements (Stripe)
[...]

## Emails transactionnels
[...]

## Jobs & Queues
[...]

## Imports / Exports
[...]

## Webhooks
[...]

## Stockage fichiers (S3)
[...]

TIP

Une section par capability critique. Pas de fichier par feature. Garder lean. Le bloc contact en haut garantit que l'équipe cliente sait qui joindre en cas d'incident.