Skip to content

ADR-001 : Séparer DEV/TEST et PROD (Firebase) + validation Stripe PWA-first

Date : 2025-12-13
Statut : Accepté

Contexte

Objectif : avoir deux environnements isolés pour Stripe et Firebase :

  • DEV/TEST : Stripe en mode test + données de test
  • PROD : Stripe en mode live + données de prod

Contraintes principales :

  • Application multi-plateforme (Web/PWA, Android, iOS, Windows à terme)
  • Intégration Stripe actuelle via l'extension Firebase stripe/firestore-stripe-payments@0.3.4
  • Aujourd'hui, le repo pointe vers un seul projet Firebase : yin-shi-1967c

Constat : tant que l'application pointe vers un seul projet Firebase, elle ne peut pas avoir un backend Stripe “test” séparé d'un backend Stripe “prod” sans risque (données partagées, secrets partagés, erreurs humaines).

Décision

1) Séparation stricte par projets Firebase

Adopter la stratégie : 1 projet Firebase = 1 environnement.

  • PROD : projet existant yin-shi-1967c
  • DEV/TEST : nouveau projet Firebase à créer (ex : yin-shi-dev)

Chaque projet aura ses propres ressources : Auth, Firestore, Functions/Extensions, Secret Manager, Hosting (si activé).

2) Ordre de mise en place : PWA-first

Valider la mise en place DEV/TEST et Stripe d'abord via le Web/PWA, car c'est le chemin le plus rapide pour itérer (pas de stores).

  • URL PWA DEV/TEST : https://yinshi-test.yinshi.app/

Les étapes mobiles (Android/iOS) sont repoussées à une phase suivante, une fois le backend DEV/TEST validé.

3) Android (plus tard) : une seule app Play Store, builds différents selon track

Pour Android, la stratégie retenue est : une seule app Play Store (même applicationId), mais des builds configurés différemment :

  • build “test” (track internal/closed) → pointe sur Firebase DEV/TEST
  • build “prod” (track production) → pointe sur Firebase PROD

Conséquences

Impacts Firebase

  • Le projet DEV/TEST devra très probablement être en Blaze (extensions + Cloud Functions).
  • Il faut reproduire/synchroniser : règles Firestore, index, extension Stripe, collections de configuration non sensibles.

Impacts Stripe

  • DEV/TEST utilisera sk_test_* et un webhook secret de test whsec_*.
  • PROD utilisera sk_live_* et un webhook secret live whsec_*.
  • Les produits/prix doivent exister en mode test et en mode live.
  • Les URLs de retour (success/cancel) doivent pointer vers l'environnement correspondant, notamment pour DEV/TEST sur https://yinshi-test.yinshi.app/.

Impacts Flutter / Web

  • Le build web “test” doit pointer vers le projet Firebase DEV/TEST (config FlutterFire dédiée).
  • Les workflows existants .github/workflows/deploy-web.yml et .github/workflows/deploy-web-test.yml facilitent déjà le déploiement Web prod vs test, mais il faudra compléter la configuration pour que le build “test” pointe vers Firebase DEV/TEST (et pas par défaut vers yin-shi-1967c).

Ce qu'on fait maintenant

  • Créer et configurer le projet Firebase DEV/TEST.
  • Installer/configurer l'extension Stripe en DEV/TEST.
  • Configurer le Web/PWA pour pointer vers DEV/TEST et valider le flow Stripe en mode test sur https://yinshi-test.yinshi.app/.

Ce qu'on ne fait pas maintenant (plus tard)

  • Flavors Android + gestion Play Console (tracks) + config Firebase par build.
  • Schemes iOS + config Firebase par build.
  • Industrialisation CI/CD complète multi-plateforme.

Références

  • docs/05_chantiers_actifs/stripe/ARCHITECTURE_STRIPE.md
  • docs/05_chantiers_actifs/stripe/README.md
  • docs/05_chantiers_actifs/stripe/OPTIONS_ENVIRONNEMENTS_TEST_PROD.md (document de travail / mise en place)