replica-backend
Lit replica/architecture.md. Écrit les migrations et le code serveur, et tient
replica/backend.md (checklist ci-dessous) à jour.
Les règles
- API officielles et publiques uniquement, avec les propres clés de l'utilisateur. N'appelez jamais les points de terminaison privés de l'application originale, ne réutilisez jamais son client OAuth, ne passez jamais par un proxy.
- L'utilisateur crée les comptes et les clés. L'agent ne s'inscrit jamais à des services, ne saisit jamais de mot de passe, de carte ou de clé en production. L'utilisateur crée le projet Stripe, Supabase, Resend ou Google Cloud et place les clés dans
.env.local. L'agent écrit.env.exampleavec chaque nom de variable et aucune valeur. - D'abord en mode test. Clés de test Stripe et cartes de test jusqu'au replica-deploy.
Authentification
- Inscription par email avec vérification, réinitialisation du mot de passe, lien magique si l'original le propose. OAuth (Google, Apple) avec les propres applications développeur de l'utilisateur.
- Sessions : cookies sécurisés http-only. Déconnexion sur tous les appareils.
- Rôles et équipes si la carte de reconnaissance en comporte : propriétaire, administrateur, membre, avec une fonction qui répond "cet utilisateur peut-il faire cette action sur cet enregistrement".
- Suppression de compte qui supprime réellement. Apple l'exige pour les applications avec inscription.
Base de données
- Migrations à partir de
architecture.md, versionnées, exécutées par un script. - Règles d'accès sur chaque table : politiques de sécurité au niveau des lignes sur Supabase, ou fonction d'autorisation appelée dans chaque requête. Testez-la : un second utilisateur ne doit rien obtenir.
- Script de seed avec des données fictives réalistes (pas de vraies personnes).
- Sauvegardes activées (les sauvegardes quotidiennes de l'hôte comptent, vérifiez qu'elles sont activées).
Paiements
- Stripe Checkout pour l'inscription à un abonnement, le portail client pour les modifications et l'annulation. Ne construisez pas de formulaires de carte.
- Webhooks : vérifiez la signature, stockez l'identifiant de l'événement, rendez chaque gestionnaire idempotent (Stripe réessaie). Gérez
checkout.session.completed,customer.subscription.updated,customer.subscription.deleted,invoice.payment_failed. - Le statut de l'abonnement réside dans votre base de données, mis à jour par les webhooks, lu par votre application. Ne faites jamais confiance au client.
- L'annulation se fait en un clic. La facturation difficile à annuler est l'une des principales plaintes concernant la plupart des applications, et dans de nombreux endroits, elle est illégale.
Emails et tâches
- Email transactionnel via Resend ou Postmark depuis votre propre domaine. Modèles rédigés à neuf.
- Tâches pour tout ce qui est basé sur le temps (rappels, digests, synchronisation, nettoyage) avec des tentatives et un journal des lettres mortes. Heures en UTC, affichées dans le fuseau de l'utilisateur.
Intégrations
Pour chaque intégration de la matrice des fonctionnalités : l'API officielle, les étendues OAuth nécessaires (le moins possible), le processus de révision du fournisseur, les limites de débit.
Les étendues Google comme Agenda nécessitent la vérification OAuth de Google avant le lancement public, ce qui prend des semaines.
Commencez tôt et notez-le dans backend.md.
Checklist de sécurité
- secrets uniquement dans les variables d'environnement,
.env*dans.gitignore, rien dans les bundles client - entrées validées sur le serveur (zod ou similaire) sur chaque route
- autorisation vérifiée sur chaque lecture et écriture, testée avec un second utilisateur
- limites de débit sur l'authentification, l'inscription et tout ce qui envoie un email ou un SMS
- les webhooks vérifient les signatures
- téléchargements : limites de taille et de type, servis depuis un domaine ou un bucket séparé
- aucune donnée utilisateur dans les URL ou les logs
- dépendances auditées (
npm audit) - politique de confidentialité liste chaque sous-traitant (Stripe, Resend, hébergeur, analytics)
Résultat
Authentification fonctionnelle, base de données, paiements en mode test, email et intégrations,
.env.example, replica/backend.md avec la checklist cochée,
les lignes de la matrice des fonctionnalités mises à jour. Suite : /replica-test.