ArvinAbrahamian1/production-app

Production App

L'idée

Toute grande entreprise converge vers la même forme : un edge devant, un frontend déployable, un backend séparé derrière une passerelle, des workers consommant une file d'attente, un système relationnel de référence, un cache, une backplane d'événements ou de jobs, un stockage objet, et de l'observabilité autour de tout cela. Shopify, Notion, Figma, Instacart et Airbnb diffèrent par leurs langages et leurs fournisseurs, pas par la forme.

La forme ne change pas entre un MVP de week-end et une entreprise dotée d'une équipe plateforme. Seul le fournisseur derrière chaque boîte change. Ce skill construit donc la forme complète dès le premier jour avec des fournisseurs gérés bon marché, applique une courte liste de règles de portabilité et conserve un playbook par couche pour échanger le fournisseur lorsqu'un déclencheur mesurable se produit. Ainsi, passer de Vercel et Supabase à Kubernetes et RDS est une série de changements de configuration et de copies de données, jamais une réécriture.

Comment utiliser ce skill

1. Lisez la description du projet. Posez uniquement les questions du questionnaire ci-dessous sur ce qu'elle omet.
2. Choisissez un fournisseur par couche avec references/providers-and-tiers.md. Commencez au niveau 1, sauf si une règle de sélection indique le contraire.
3. Rédigez docs/PLAN.md à partir du modèle ci-dessous, en incluant le diagramme adapté de references/architecture.md, et montrez-le avant d'échafauder.
4. Échafaudez et construisez dans l'ordre ci-dessous.
5. Avant le lancement, exécutez references/launch-checklist.md et signalez uniquement les échecs avec leurs correctifs.
6. Lorsqu'un déclencheur se produit plus tard, ouvrez references/migrations.md et déplacez cette couche. Ne déplacez jamais deux couches la même semaine.

Pour une application existante : auditez d'abord. Cartographiez le dépôt sur la forme, listez les lacunes classées par risque (fuite de données, panne, abus, verrouillage, coût), et arrêtez-vous. Les modifications interviennent après que le propriétaire a choisi dans la liste.

Questionnaire

Posez uniquement ce que la description laisse sans réponse, en un seul message.

1. Qui sont les utilisateurs et quel est le locataire : l'unité qui possède les données (une entreprise, un bâtiment, un concessionnaire, une personne) ?
2. Qu'est-ce qui est lourd : flux, messages, uploads, vidéo, événements, recherche ? Nombre approximatif de lignes ou de fichiers par jour, et croissance.
3. Web, iOS, Android, ou un mélange ? Qu'est-ce qui sort en premier ?
4. Besoins temps réel : chat, présence en direct, édition collaborative, ou le polling est-il suffisant ?
5. Argent : abonnements, paiements uniques, paiements sur une marketplace, rien ?
6. Quelque chose de réglementé ou sensible : paiements stockés, santé, mineurs, localisation, acheteurs gouvernementaux ou entreprises qui demanderont un SOC 2 ?
7. Géographie du public : un pays ou mondial ?
8. Contraintes : crédits cloud existants, fournisseur existant, langage imposé.

Les réponses déterminent les règles de sélection dans references/providers-and-tiers.md.

La forme

Chaque couche a un rôle, une référence de grande entreprise et la règle unique qui la rend portable. Les fournisseurs par niveau se trouvent dans references/providers-and-tiers.md.

1. Edge : DNS, TLS, CDN, DDoS, WAF, limitation de débit, filtrage de bots, devant chaque hôte. Grandes entreprises : Cloudflare, Akamai, Fastly, CloudFront avec AWS WAF. Règle : vous possédez la zone DNS ; chaque fournisseur est derrière un CNAME, donc changer de fournisseur est un changement DNS.
2. Frontend : un déploiement séparé, statique ou rendu serveur, ne contenant aucune logique métier et aucun accès à la base de données. Grandes entreprises : une application React ou Next.js construite dans un conteneur et servie via le CDN. Règle : le frontend se compile comme un conteneur Node standard ou un bundle statique et ne communique qu'avec l'API publique.
3. Passerelle : un répartiteur de charge ou une passerelle API qui termine le TLS depuis l'edge, route par chemin et applique des limites approximatives. Grandes entreprises : ALB, Envoy, NGINX ingress, Kong. Règle : l'API ne dépend jamais des fonctionnalités de la passerelle qu'elle ne peut pas reproduire dans son propre middleware.
4. Backend : un service monolithique derrière la passerelle, divisé en services uniquement lorsque les équipes entrent en collision. Grandes entreprises : Rails chez Shopify et GitHub, Django chez Instagram, Node chez Notion, gRPC à l'intérieur, GraphQL ou REST à l'extérieur. Règle : un conteneur Docker avec un endpoint de santé, configuration depuis les variables d'environnement, aucun SDK fournisseur dans la logique métier.
5. Workers et file d'attente : des processus de longue durée séparés consommant des jobs ; un moteur de workflow lorsque les jobs ont plusieurs étapes ou des attentes humaines. Grandes entreprises : Sidekiq et consommateurs Kafka chez Shopify, Temporal chez Netflix et Duolingo, Kafka chez Notion. Règle : les jobs sont idempotents, portent des identifiants et non des blobs, et la file d'attente est un protocole Redis ou Kafka standard.
6. Base de données relationnelle : une base Postgres (ou MySQL) primaire comme système de référence, des réplicas pour les lectures, un sharding uniquement au-delà des limites d'une seule machine. Grandes entreprises : RDS Postgres avec PgBouncer chez Notion et Figma, 100 shards MySQL et plus chez Shopify. Règle : protocole filaire Postgres uniquement, migrations SQL dans le dépôt, rôles et RLS en SQL, rien qui ne fonctionne que sur l'API d'un seul fournisseur.
7. Cache : Redis ou Memcached pour les lectures à chaud, compteurs de limitation de débit, verrous, sessions. Règle : protocole Redis standard, clés limitées au locataire et versionnées, l'application doit pouvoir fonctionner avec le cache vide.
8. Stockage objet : S3 ou un bucket compatible S3 pour chaque fichier ; jamais la base de données. Règle : API S3 uniquement, clés préfixées par locataire, servies via des URL signées ou le CDN.
9. Identité : un fournisseur d'identité émettant des JWT, une table users appartenant à l'application. Grandes entreprises : interne plus Okta ou Auth0 pour le SSO d'entreprise. Règle : l'API vérifie elle-même les tokens via JWKS et possède la table des utilisateurs, donc l'émetteur peut changer.
10. Événements et analytique : analytique produit et, plus tard, un entrepôt alimenté par la capture de données de changement. Grandes entreprises : Kafka dans Snowflake ou BigQuery. Règle : l'entrepôt lit depuis la base de données, jamais d'écritures dupliquées depuis l'application.
11. Observabilité : logs structurés, erreurs, métriques, traces, disponibilité, alertes liées à un playbook. Grandes entreprises : Datadog, Grafana, Honeycomb, Sentry, OpenTelemetry. Règle : l'application émet des logs OpenTelemetry et JSON, donc le backend est un paramètre d'exportateur.
12. Livraison : CI à chaque push, infrastructure en tant que code, déploiements canary ou blue/green, feature flags, rollback rapide. Grandes entreprises : Terraform, Buildkite ou GitHub Actions, ArgoCD ou Spinnaker, LaunchDarkly. Règle : tout ce qui est cliqué dans un tableau de bord est écrit dans infra/ le même jour et Terraform à partir du niveau 2.

Règles de portabilité

Ce sont elles qui rendent la migration ultérieure peu coûteuse. Elles ne coûtent presque rien à la taille d'un MVP et font la différence entre une migration de week-end et une réécriture d'un trimestre.

1. Le frontend et le backend sont des dépôts séparés et des déploiements séparés dès le premier commit. Ils communiquent via une API HTTP versionnée avec des schémas partagés.
2. Le backend et le worker sont des images Docker qui s'exécutent partout où un conteneur s'exécute. Pas de fonctions serverless pour l'API : les fonctions Vercel, les handlers Lambda et les fonctions edge sont la seule chose qui ne peut pas être intégrée dans un conteneur plus tard sans réécriture.
3. Communiquer avec l'infrastructure uniquement via des standards : protocole filaire Postgres, protocole Redis, API S3, SMTP ou une API HTTP email derrière une interface, JWKS pour les tokens, OpenTelemetry pour la télémétrie. La bibliothèque client d'un fournisseur est autorisée uniquement dans un module adaptateur fin qui peut être échangé.
4. Aucune fonctionnalité du fournisseur dans la logique métier : pas d'appels PostgREST, pas de client Supabase ou Firebase dans le backend, pas d'API de mise en cache spécifiques à Vercel, pas de Workers KV. Le frontend peut utiliser le SDK d'authentification d'un fournisseur uniquement pour la connexion.
5. L'application possède son schéma : migrations SQL dans le dépôt, appliquées par un outil de migration, jamais par un tableau de bord. Les rôles, RLS et fonctions sont des fichiers SQL que le dépôt peut rejouer sur n'importe quel Postgres.
6. L'application possède ses utilisateurs : une table users reflétée depuis le fournisseur d'identité lors de la première connexion, avec les identifiants du fournisseur stockés comme une colonne. Les données d'autorisation résident dans les tables de l'application.
7. La configuration est constituée de variables d'environnement validées au démarrage. Les secrets résident dans le coffre de secrets de la plateforme mais atteignent l'application en tant que variables d'env, donc le coffre peut changer.
8. Vous possédez la zone DNS (Cloudflare). Chaque fournisseur est une cible CNAME. Rien n'est pointé vers les serveurs de noms d'un fournisseur.
9. Les clés de stockage objet et la disposition des buckets sont les mêmes sur R2 et S3 ; le code utilise le SDK S3 avec un paramètre de point de terminaison.
10. Chaque couche a une exportation documentée : pg_dump et réplication logique pour la base de données, rclone pour les objets, un dump Redis n'est jamais nécessaire car le cache est jetable et la file d'attente se vide.
11. Les endpoints de santé, l'arrêt gracieux sur SIGTERM et l'apatridie horizontale existent dès le premier jour, car chaque plateforme, de Railway à Kubernetes, en dépend.
12. La télémétrie et les logs sont OpenTelemetry et JSON dès le premier jour ; les agents des fournisseurs ne sont pas installés dans le code.

Niveaux

Trois niveaux par couche. Les déclencheurs sont mesurables ; le tableau complet avec les fournisseurs, le coût et les règles de sélection se trouve dans references/providers-and-tiers.md.

• Niveau 1, MVP : fournisseurs gérés qui se configurent en quelques minutes et coûtent moins d'environ 150 $ par mois au total. Frontend sur Vercel, conteneur backend sur Railway, Postgres sur Supabase, Redis sur Railway, objets sur R2, edge sur Cloudflare, Sentry et Better Stack. Jusqu'à ce qu'il y ait des clients payants qui s'interrogent sur la disponibilité, ou les chiffres ci-dessous.
• Niveau 2, croissance : la même forme sur votre propre compte cloud là où c'est important : Postgres sur RDS ou Aurora Multi-AZ avec PgBouncer ou RDS Proxy, conteneurs sur ECS Fargate ou un petit EKS, ElastiCache, S3 ou R2, Terraform pour tout, un réplica en lecture, Temporal pour les workflows. Déclencheur : un client payant demande un SLA ou SOC 2, ou 5 000 utilisateurs actifs mensuels soutenus avec un CPU de base de données supérieur à 60 %, ou la facture PaaS dépasse 500 $ par mois, ou un deuxième ingénieur arrive.
• Niveau 3, échelle : ce que Shopify et Notion exécutent. Kubernetes avec autoscaling, primaire shardé ou partitionné, Kafka comme backplane d'événements, entrepôt par CDC, lectures multi-régions, Datadog ou Grafana, une équipe plateforme. Déclencheur : 1 000 requêtes par seconde soutenues, une primaire proche de 1 To ou limitée en écriture après réplicas et mise en cache, une exigence multi-région, ou une équipe ops existe pour l'exécuter.

Le changement de niveau se fait par couche, pas tout à la fois. La base de données déménage généralement en premier, puis le backend, puis le frontend en dernier, car le frontend est le moins coûteux à laisser là où il est.

Ordre de construction

1. Schéma, migrations, rôles, RLS (references/database.md, references/security.md).
2. Middleware de vérification d'identité et de contexte de locataire.
3. Routes API principales avec validation et idempotence sur les écritures.
4. Middleware de limitation de débit et de mise en cache (references/rate-limiting.md, references/caching.md).
5. Worker et files d'attente ; tout ce qui est lent ou externe quitte le chemin de requête (references/jobs-and-queues.md).
6. Frontend contre l'API.
7. Mobile contre la même API.
8. Logs, métriques, traces, contrôles de santé, alertes (references/observability-and-reliability.md).
9. Porte de lancement, test de charge à trois fois le pic attendu, un test de restauration (references/launch-checklist.md).

Modèle de PLAN.md

# Plan de <Projet>
## Produit en trois phrases
## Utilisateurs, locataire, rôles
## Fournisseurs par couche         (niveau par couche, pourquoi, le déclencheur qui le déplace, depuis providers-and-tiers.md)
## Modèle de données                 (tables, tenant_id marqué, index, tables partitionnées)
## Surface API                (routes par ressource, niveau d'authentification, niveau de limitation de débit)
## Jobs en arrière-plan            (file d'attente, déclencheur, clé d'idempotence, politique de réessai)
## Tiers                    (service, objectif, nom du secret, limite, mode de défaillance)
## Carte de mise en cache                (quoi, clé, TTL, quelles écritures l'invalident)
## Modèle de menace               (5 principaux cas d'abus et le contrôle pour chacun)
## Hypothèses d'échelle          (utilisateurs, lignes, requêtes par minute au lancement et à 10x)
## Coût au lancement             (par fournisseur, par mois)
## Plan de sortie par fournisseur     (le playbook migrations.md qui s'applique, en une ligne chacun)
## Diagramme

Règles non négociables

1. Chaque table appartenant à un locataire a tenant_id ; RLS activé et forcé ; l'API définit le locataire par transaction à partir d'une adhésion vérifiée, jamais à partir de l'entrée de la requête.
2. Les clients ne touchent jamais à la base de données ni ne détiennent de clés privilégiées. Tout passe par l'API.
3. Chaque entrée est validée à la frontière avec rejet des clés inconnues ; chaque requête paramétrée.
4. L'API et les workers se connectent via un pooler avec de petits pools ; des délais d'instruction définis par rôle.
5. Limites de débit à l'edge et dans l'API, avec des clés par utilisateur, locataire et IP. Clés de cache limitées au locataire et versionnées.
6. Secrets dans le coffre de la plateforme, un ensemble par environnement, jamais dans git ou un bundle mobile. La production et le staging sont des projets et des comptes séparés.
7. PITR activé et une restauration testée une fois.
8. Signature des webhooks vérifiée, protégée contre la relecture, idempotente, répondue en moins de deux secondes.
9. Délais d'attente sur chaque appel sortant ; réessais avec gigue uniquement sur un travail idempotent ; les jobs en échec visibles pour un humain.
10. Identifiant de requête et identifiant de locataire sur chaque ligne de log ; alertes sur le taux d'erreur, la latence p95, le nombre de 5xx, l'âge de la file d'attente, les jobs en échec, les connexions à la base de données.

Mobile

1. Application React Native ou Expo existante : elle reste.
2. Nouvelle application, iOS uniquement ou iOS en premier : Swift et SwiftUI natifs. Les grandes entreprises sont passées au natif en 2026 (Shopify de retour vers Swift et Kotlin, Notion vers SwiftUI) car les agents de codage ont supprimé le coût de la deuxième base de code ; la même chose vaut pour une petite équipe. Kotlin uniquement lorsqu'Android est réellement construit.
3. Nouvelle application qui doit livrer iOS et Android le même jour avec une ou deux personnes : Expo.
4. Dans tous les cas, l'application ne communique qu'avec l'API, conserve les tokens dans un stockage sécurisé et n'incorpore rien de secret dans le bundle.

Fichiers de référence

• references/providers-and-tiers.md : le tableau par couche (pratique des grandes entreprises, fournisseurs des niveaux 1, 2, 3, déclencheur, coût) et les règles de sélection qui transforment une description de projet en choix.
• references/migrations.md : le playbook étape par étape pour déplacer chaque couche vers un niveau supérieur.
• references/architecture.md : le diagramme avec les étiquettes de niveau, les trois chemins de requête, les dispositions des dépôts, les environnements, la configuration edge et plateforme.
• references/security.md : location et RLS, identité, secrets, en-têtes, entrée, uploads, webhooks, chiffrement, suppression et exportation, mobile, journal d'audit, incidents.
• references/rate-limiting.md : quatre couches avec des chiffres et le middleware.
• references/caching.md : chaque couche de cache, schéma de clés, TTL, invalidation, protection contre les emballements.
• references/database.md : règles de schéma, rôles, pooling, migrations, RLS, sauvegardes, PITR, exportation.