Sprint 4 — Post-achat & livraison À FAIRE¶

Runbook technique (Stripe events, retry, watchdog, tests) : demo-conductor/docs/sprints/sprint-4-post-achat.md Cette page = vue stratégique pour Marc + Cyrille.

Robustifier le tunnel paiement → génération → livraison.

Contexte¶

Le code Stripe/Brevo est prêt mais 35 études sur 41 n'ont pas de pipeline. Sans fallback, un client qui paie une étude non implémentée reçoit une erreur silencieuse.

Scope¶

Webhook Stripe complet¶

• checkout.session.completed → déjà géré
• payment_intent.failed → notifier admin + client
• charge.dispute.created → geler la commande, alerter admin
• charge.refunded → marquer refund, notifier client
• checkout.session.expired → cleanup commande pending

Endpoints API¶

• POST /api/orders/{id}/cancel — annulation avant génération
• POST /api/orders/{id}/refund — remboursement Stripe

Fallback 35 études¶

• Détection : commande sur étude sans pipeline → email admin automatique
• Notification client : "Votre étude sera traitée manuellement sous 48h"
• Admin dashboard : queue visuelle des commandes manuelles

Robustesse pipeline¶

• Retry automatique : 3 tentatives max en cas d'échec LLM
• Watchdog : commande en generating > 30 min → alerte admin
• Polling espace client : refresh auto toutes les 30s

Notifications¶

• Changement de statut commande → email client
• Lien de téléchargement rapport avec expiration 30 jours

Dépendances¶

flowchart TD
    M1[Marc : compte Stripe] --> S4
    M2[Marc : compte Brevo] --> S4
    M3[Marc : domaine DNS] --> S4
    M4[Marc : déploiement VPS] --> S4
    S4[Sprint 4]

    classDef action fill:#c9a84c,stroke:#0d1f3c,color:#0d1f3c
    classDef sprint fill:#0d1f3c,stroke:#e87722,color:#fff
    class M1,M2,M3,M4 action
    class S4 sprint