docs(knowledge): capitalisation backend — intégration du triage local (mai-juin 2026)

Triage et intégration des propositions backend du buffer 95_a_capitaliser.md
(lot local RL799_V2 + app-alexandrie, mai-juin 2026), distinct de la capitalisation
remote antérieure (triage 2026-05-02).

~73 entrées intégrées sur knowledge/backend/, dont :
- patterns/auth.md : série "membrane d'auth fédérée BFF/OIDC" (9 patterns) + jose algo whitelist
- patterns/prisma.md : recette fusionnée "Migration String/Int → enum" (backfill + Cas A/B/C),
  row réactivable, endpoint replace atomique, updateMany conditionnel, etc.
- risques/general.md : 19 risques (epoch s vs ms, keepAliveTimeout=0, upsert+filtre liste,
  fail-safe catch-all, retrait asymétrique front/back, anti-énumération rate-limit, etc.)
- patterns/general, async, nestjs, contracts, tests + risques/auth, contracts, prisma, redis, stripe, tests
- compléments d'entrées existantes (authorize-after-fetch, P3014, cursor opaque, DI swc, Stripe v20...)
- README patterns/risques mis à jour

Doublons internes corrigés en relecture (suppression-champ .map() → general seul ;
e2e DB-based → tests.md seul). Doublons hors backend / entrées projet / rejets non intégrés.
Source 95_a_capitaliser.md non purgée à ce stade (purge en fin de capitalisation complète).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

knowledge/backend/patterns/stripe.md

@@ -158,3 +158,43 @@ handlePackWebhookEvent(event): PackWebhookResult | null
 - Règle métier explicitée
 - Guards alignés sur la sémantique choisie
 - Fixtures et seeds cohérents
+
+---
+
+<a id="pattern-price-data-inline-checkout-dynamique"></a>
+
+## Pattern : Prix défini en base → `price_data` inline pour un checkout dynamique
+
+- Objectif : faire d'un checkout Stripe one-shot la source de vérité d'un montant qui vit dans NOTRE base (saisi par un admin métier), sans Price pré-créé dans le dashboard Stripe.
+- Contexte : produit one-shot dont le prix est défini en back-office et non figé dans Stripe.
+- Quand l'utiliser : checkout `mode: 'payment'` dont le montant est piloté par la base.
+- Quand l'éviter : récurrent/abonnement (`mode: 'subscription'`) — garder un `Price` recurring pré-créé.
+- Avantage :
+  - l'admin ne saisit qu'un montant (+ devise) ; aucun objet `Price` à gérer dans Stripe
+  - un changement de prix prend effet immédiatement au prochain checkout
+- Limites / vigilance :
+  - `unit_amount` est en **centimes** = stockage entier (jamais de flottant)
+  - le montant venant de notre base, ajouter une garde anti-fraude best-effort (voir ci-dessous)
+- Validé le : 05-06-2026
+- Contexte technique : Stripe Checkout / NestJS — app-alexandrie (ux-parcours-3/7 + bo-6)
+
+### Implémentation
+
+```typescript
+stripe.checkout.sessions.create({
+  mode: 'payment',
+  line_items: [{
+    price_data: {
+      currency,                      // ISO 4217 minuscules, normalisée à l'écriture
+      unit_amount: amountInCents,    // entier, centimes
+      product_data: { name },
+    },
+    quantity: 1,
+  }],
+});
+```
+
+### Garde-fous
+
+- **Anti-fraude (best-effort, non bloquant)** : au webhook, comparer `amount_total`/`currency` au montant attendu (retrouvé via metadata) et logguer tout écart (`stripe_amount_suspicious`). Stripe a déjà encaissé → log, pas de blocage.
+- **Validation devise stricte côté écriture** (ISO 4217 minuscules) sur TOUS les modèles qui pilotent un checkout : un schéma lâche sur l'un et strict sur l'autre = devise invalide passée à Stripe. Défense serveur : défauter la devise quand un montant est posé sans elle (un montant sans devise = produit non achetable).