Production Readiness (MVP → Production)

Que fait Production Readiness (MVP → Production) ?

Objectif : dire au propriétaire, avec des preuves, si le produit est prêt pour de vrais utilisateurs, ce qui bloque le lancement et le plus petit ensemble de travaux pour combler les écarts. Adapté au produit — jamais une liste générique de 200 items.

Règles strictes

1. Preuve ou c'est Inconnu. Chaque élément est PASS / GAP / N/A / UNKNOWN, et PASS nécessite une preuve (chemin de fichier, config, exécution CI, tableau de bord, lien doc). Ne jamais marquer PASS à partir d'une affirmation dans le README.
2. Adapté au niveau. Ne pas exiger une reprise multi-région pour une bêta de 50 utilisateurs. Taguez chaque écart avec le niveau auquel il est requis.
3. Vérifier les règles des plateformes en direct. Les règles des stores, OAuth, paiements et expéditeurs d'emails changent chaque année. Avant de citer une exigence d'un store/vendeur, vérifiez la documentation officielle du vendeur (recherche web) et citez le lien + la date de vérification.
4. Réutiliser, ne pas dupliquer. Si pm-ai-shipping:ship-check, security-audit-static, performance-audit-static ou derive-tests sont disponibles, exécutez-les pour obtenir des preuves au niveau du code et intégrez les résultats. Ce skill possède tout ce qui entoure le code.
5. Sortie simple. Le propriétaire lit un tableau de bord d'une page ; les détails vont en annexe et dans le backlog.
6. Gouvernance dans le workflow, pas à la fin. Préférez les vérifications qui s'exécutent là où le travail se fait (CI, modèles de PR, pre-commit, barrières dans le produit) plutôt que des réunions de revue ajoutées avant le lancement. Une porte qui ne s'exécute qu'à la fin devient le goulot d'étranglement.
7. Livré n'est pas adopté. La plupart des produits stagnent après le lancement parce que les personnes et les processus n'ont pas changé, pas parce que le code a échoué. La préparation inclut le plan d'adoption (domaine 13), pas seulement le système.

Niveaux de préparation

Niveau	Signification	Barre typique
T1 Bêta publique	Vrais utilisateurs, faible échelle, peut tolérer quelques temps d'arrêt	Pas de fuite de secrets, auth solide, sauvegardes restaurées, erreurs tracées, pages légales, rollback fonctionne
T2 GA	Utilisateurs payants, attentes SLA	+ SLOs/alertes/astreinte, testé en charge, runbooks, chemin de support, fallbacks d'intégration
T3 Entreprise / réglementé	Contrats B2B, PHI/PCI/enfants, audits	+ SSO/SCIM, logs d'audit, DPAs/BAAs, test de pénétration, contrôles SOC 2 / HIPAA, exercices de reprise

Flux de travail

Étape 0 — Profiler le produit (demander une fois, grouper les questions)

Capturer : niveau cible et date de lancement ; la métrique de succès unique et son objectif (ce qui fait de ce lancement un succès, mesuré comment, d'ici quand) ; propriétaire nommé et parties prenantes de validation (produit, ingénierie, sécurité, juridique/confidentialité, support, marketing — signaler juridique/confidentialité dès le premier jour si des données personnelles, des sorties IA ou des utilisateurs réglementés sont impliqués) ; surfaces (web, iOS, Android, desktop, API publique, CLI, extension navigateur, outil développeur/plugin/bibliothèque distribué à d'autres développeurs) ; hébergement/stack ; types de données (PII, PHI, paiement, données de mineurs) ; utilisateurs (B2C/B2B), régions (UE/autres) ; fonctionnalités IA/LLM ; paiements ; chaque intégration externe (API consommées, webhooks reçus, marketplaces/stores où publié, SSO/IdPs). Scannez d'abord le repo (manifests de paquets, modèles d'environnement, imports SDK) pour pré-remplir la liste d'intégrations, puis demandez au propriétaire seulement de confirmer/combler les lacunes.

Le profil sélectionne les modules applicables. Enregistrez-le en haut du rapport.

Étape 1 — Rassembler les preuves

Repo (code, config CI, IaC, modèles d'environnement, migrations), tableaux de bord hébergement/connecteurs si disponibles (Vercel, Railway, Supabase, Render, etc.), tracker de tickets, docs existantes. Exécuter les skills d'audit disponibles. Noter ce qui n'a pas pu être inspecté → UNKNOWN.

Étape 2 — Évaluer les domaines fondamentaux (toujours) + modules applicables

Noter chaque élément. Sévérité : BLOCKER (ne peut pas lancer au niveau cible) / HIGH (à corriger dans les 2 premières semaines) / LATER.

Étape 3 — Livrer

1. Tableau de bord (1 page) : Go / Go-avec-conditions / No-go ; nombre de bloqueurs ; tableau RAG par domaine ; top 5 risques en français simple.
2. Backlog d'écarts : un ticket par écart — titre, pourquoi c'est important, critère d'acceptation, preuve nécessaire pour fermer, niveau, sévérité, taille approximative (S/M/L). Si Linear/Jira/GitHub Issues est connecté, proposer de les créer sous forme de projet/milestone ; sinon, un tableau.
3. Kit de durcissement (sur demande) : générer une porte qualité CI spécifique au repo, un fichier de règles d'agent (CLAUDE.md/.cursorrules), .env.example, des ébauches de runbook — construit à partir de ce que le repo utilise réellement, pas d'un modèle générique.
4. Mode re-exécution : lors des exécutions ultérieures, faire un diff par rapport au dernier rapport et montrer uniquement ce qui a changé.

Domaines fondamentaux (toujours évalués)

1. Secrets & configuration — aucun secret dans le code ou l'historique git (gitleaks/trufflehog sur tout l'historique) ; .env ignoré, .env.example présent ; secrets de production dans le coffre de la plateforme ; clés séparées dev/staging/prod ; plan de rotation et personnes autorisées à tourner ; étapes de réponse en cas de fuite de clé.

2. Identité & accès — fournisseur d'authentification éprouvé ou bibliothèque bien évaluée (pas de crypto maison) ; autorisation côté serveur sur chaque route de données (vérifier les IDOR / filtres de locataire manquants / RLS permissif) ; durées de vie des sessions/tokens et révocation ; limites de taux sur login, inscription, réinitialisation, OTP ; MFA pour les admins ; comptes de service avec privilèges minimaux ; actions admin journalisées.

3. Sécurité des applications & périmètre — HTTPS + HSTS ; en-têtes de sécurité (CSP, frame-ancestors, etc.) ; CORS strict ; validation d'entrée aux frontières ; limites/tests de type pour les fichiers uploadés ; protections SSRF sur les récupérateurs d'URL ; WAF/protection anti-bot à T2+ ; analyse des dépendances + lockfiles ; SAST dans le CI ; SBOM et vérification de licence à T3.

4. Données — sauvegardes automatisées et une restauration testée (enregistrer le temps de restauration réel) ; restauration à un instant dans le temps si la base le supporte ; migrations rétrocompatibles (étendre → migrer → contracter) ; staging sans PII brute de production ; rétention + chemin de suppression (la suppression du compte utilisateur supprime effectivement dans la base, le stockage, les logs, les fournisseurs) ; chiffrement au repos/en transit par défaut confirmé.

5. Fiabilité — timeouts sur chaque appel sortant ; tentatives avec backoff + jitter uniquement sur les opérations idempotentes ; clés d'idempotence pour les paiements/webhooks/jobs ; travail en arrière-plan sur une file d'attente durable ; dégradation gracieuse quand une dépendance est indisponible ; SLOs définis (disponibilité, latence) à T2+ ; test de charge/capacité à un pic attendu ×3 à T2+.

6. Observabilité — suivi des erreurs avec tag de version (ex : Sentry) ; logs structurés avec identifiants de requête/trace et masquage des PII ; métriques clés (taux, erreurs, durée) par endpoint ; vérifications de disponibilité depuis l'extérieur ; alertes basées sur les symptômes acheminées à un humain qui les verra réellement ; tableaux de bord pour le jour du lancement.

7. CI/CD & release — vérifications obligatoires sur main (lint, vérification de types, tests, scan de secrets, audit de dépendances) ; environnement de prévisualisation/staging ; rollback en un clic prouvé une fois ; feature flags pour les fonctionnalités risquées ; migrations exécutées en toute sécurité dans le déploiement ; notes de version/changelog ; protection de branche.

8. Tests — tests sur les chemins critiques (auth, paiements, écritures de données, permissions) plutôt qu'un pourcentage de couverture ; tests d'intégration contre une vraie base ; tests de fumée E2E sur les parcours principaux exécutés après le déploiement ; tests de contrat ou fixtures enregistrées pour les API externes.

9. Performance & coût — Core Web Vitals / budgets de démarrage de l'application ; vérification des N+1 et index manquants ; cache/CDN ; alertes de dépenses par fournisseur et plafonds durs (cloud, LLM, SMS, email) ; estimation du coût par utilisateur actif ; scénarios d'abus qui peuvent faire grimper la facture (spam d'inscription, boucles de prompts LLM, pompage SMS).

10. Exploitation & support — propriétaire/astreinte nommé même si une seule personne ; processus d'incident (sévérité, communications, postmortem) ; runbooks pour les 5 principaux modes de défaillance ; page de statut à T2+ ; canal de support et SLA ; outils d'administration pour les tâches de support courantes (pour que les correctifs n'aient pas besoin de SQL brut).

11. Juridique & confiance — Conditions d'utilisation, Politique de confidentialité correspondant aux flux de données réels ; consentement aux cookies là où requis (UE/Royaume-Uni) ; DPAs avec les fournisseurs traitant des données personnelles ; liste des sous-traitants à T3 ; cible d'accessibilité (WCAG 2.2 AA) et un audit basique ; conformité des licences open-source ; vérification de la marque/nom pour le nom du produit.

12. Préparation produit — analytics sur l'entonnoir d'activation (avec consentement) ; onboarding et états vides ; emails transactionnels délivrés (voir module Web) ; docs d'aide/FAQ ; tarification/facturation en ligne si payant ; boucle de feedback ; interrupteur d'arrêt pour les fonctionnalités problématiques.

13. Adoption & modèle opérationnel — métrique de succès et critères de sortie du pilote écrits avant le lancement (ce qui le fait passer du pilote à