audit-production

Audit Production

Utilisez cette compétence lorsque l'utilisateur demande si une application est prête à être livrée, ce qui pourrait casser en production, ou ce qui doit être corrigé avant un lancement. Il s'agit d'une réécriture sûre pour les mainteneurs de l'idée obsolète de la communauté "audit-production" : elle conserve la perspective utile de la préparation à la production et supprime l'exécution externe non épinglée et le partage de données avec des tiers.

Quand l'utiliser

• L'utilisateur demande "est-ce prêt pour la production", "qu'est-ce qui casserait en prod", "qu'avons-nous oublié", "auditez ce dépôt" ou "prêt à livrer ?"
• Une fonctionnalité a été fusionnée et nécessite une passe de risque pré-déploiement ou post-merge.
• Un lancement public, une démo, un déploiement client ou une présentation aux investisseurs est proche.
• L'intégration continue (CI) est verte mais l'utilisateur souhaite des risques de production, pas seulement l'état des tests.
• Une URL déployée, une branche de version, une PR ou l'état actuel du checkout est disponible pour la collecte de preuves.

Quand ne pas l'utiliser

• Pendant l'implémentation active lorsque la bonne approche est le codage sécurisé au niveau ligne ; utilisez d'abord security-review.
• Pour les bibliothèques pures, les modèles, les dépôts de documentation uniquement ou les échafaudages, à moins que l'utilisateur ne souhaite la préparation à l'empaquetage/à la release plutôt que la préparation de l'application.
• Lorsque l'utilisateur demande un audit de conformité formel. Cette compétence est un triage d'ingénierie, pas une certification juridique, financière, médicale ou réglementaire.
• Lorsque la seule preuve disponible est une idée de produit sans dépôt, déploiement, CI ou surface d'exécution.

Comment ça fonctionne

Construisez l'audit à partir de preuves locales et autorisées par l'utilisateur. N'exécutez pas de code distant non épinglé, ne téléchargez pas le contenu du dépôt vers des services tiers et n'appelez pas de scanners externes à moins que l'utilisateur n'approuve explicitement cet outil et ce flux de données.

Utilisez cet ordre :

1. Établissez la surface de livraison.
2. Lisez les modifications récentes et l'état actuel de la branche.
3. Inspectez les limites d'exécution, d'authentification, de données, de paiement, de tâches en arrière-plan, d'IA et de déploiement qui existent réellement dans le dépôt.
4. Vérifiez la CI, les tests, les migrations, la documentation environnementale et le chemin de retour arrière.
5. Produisez une recommandation courte (livrer/bloquer) avec des correctifs spécifiques.

Liste de vérification des preuves

Commencez par les signaux locaux peu coûteux :

git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD

Inspectez ensuite la surface spécifique au projet :

• Scripts de package, workflows CI, scripts de release, fichiers Docker et manifests de déploiement.
• Routes API, webhooks, middleware d'authentification, workers en arrière-plan, tâches cron et migrations de base de données.
• Documentation des variables d'environnement et vérifications au démarrage.
• Hooks d'observabilité, rapports d'erreurs, logs, vérifications de santé et tableaux de bord.
• Instructions de rollback, seed, migration et backfill.
• Couverture E2E pour les parcours utilisateur les plus importants.

Si une URL déployée est dans le périmètre, utilisez uniquement des vérifications navigateur ou HTTP contre cette URL et évitez les actions authentifiées à moins que l'utilisateur ne fournisse un compte de test sécurisé.

Lentilles de risque

Sécurité et Authentification

• Les routes publiques, les routes API et les routes admin sont-elles clairement séparées ?
• L'authentification et l'autorisation sont-elles appliquées côté serveur ?
• Les secrets sont-ils conservés hors des bundles clients, des logs, des exemples de sortie et des fichiers versionnés ?
• Les limites de taux, les protections CSRF, la politique CORS et la validation des téléchargements sont-elles présentes là où l'application en a besoin ?
• La surface IA ou agent se défend-elle contre l'injection de prompts, l'abus d'outils et le contenu non fiable qui franchit les actions privilégiées ?

Intégrité des données

• Les migrations s'exécutent-elles proprement et ont-elles un plan de rollback ou de récupération ?
• Les migrations destructrices, les backfills et les importations de données sont-ils déployés en toute sécurité ?
• Les politiques de base de données, les droits et les limites des rôles de service correspondent-ils au modèle de location de l'application ?
• Les nouvelles tentatives sont-elles idempotentes pour les écritures, les jobs et les gestionnaires de webhooks ?

Paiements et Webhooks

• Les signatures des webhooks sont-elles vérifiées avant d'analyser les champs de confiance ?
• Chaque webhook de paiement, d'abonnement ou d'exécution est-il idempotent ?
• Les livraisons en double, rejouées et hors ordre sont-elles gérées ?
• Les identifiants de mode test et de mode live sont-ils séparés ?

Opérations

• L'application peut-elle démarrer à partir d'un checkout propre en utilisant des commandes documentées ?
• Les variables d'environnement requises sont-elles nommées, validées et en échec rapide ?
• Existe-t-il une vérification de santé qui prouve que les dépendances sont joignables ?
• Les chemins de déploiement, de rollback et de responsable d'incident sont-ils documentés ?
• Les logs sont-ils utiles sans fuiter de secrets ou de données personnelles ?

Expérience Utilisateur

• Les chemins critiques pour le lancement sont-ils couverts sur desktop et mobile ?
• Les formulaires sont-ils utilisables sur mobile sans zoom d'entrée, chevauchement de mise en page ou états de soumission bloqués ?
• Les états de chargement, vide, erreur et refus d'autorisation indiquent-ils à l'utilisateur ce qui s'est passé ?
• Existe-t-il un chemin de support ou de récupération lorsqu'une opération critique échoue ?

Scoring

Utilisez les scores pour forcer la priorisation, pas pour impliquer une certitude mathématique.

Gamme	Score	Signification
Bloqué	0-49	Ne livrez pas tant que les principaux risques ne sont pas corrigés
Risqué	50-69	Livrez uniquement derrière un petit déploiement ou une bêta interne
Publiable avec réserves	70-84	Livrez si les propriétaires acceptent les risques listés
Solide	85-100	Aucun bloqueur de lancement évident d'après les preuves disponibles

Plafonnez le score à 69 si l'une de ces conditions est vraie :

• L'authentification ou l'autorisation est manquante sur les données sensibles.
• Les webhooks de paiement ou d'exécution ne sont pas idempotents.
• Les migrations requises ne peuvent pas être exécutées en toute sécurité.
• Les secrets sont exposés dans les bundles clients, les logs ou les fichiers commités.
• Il n'existe pas de chemin de rollback pour une version à fort impact.

Plafonnez le score à 84 si la CI n'est pas verte ou si le chemin critique pour le lancement n'a pas été testé de bout en bout.

Format de sortie

Commencez par une phrase :

Audit production : 76/100, publiable avec réserves, avec l'idempotence des webhooks et la documentation de rollback comme les deux risques à corriger avant le lancement public.

Listez ensuite :

• Bloqueurs : éléments à corriger impérativement avant le déploiement.
• Correctifs à haute valeur : correctifs suivants si l'utilisateur souhaite améliorer le score.
• Preuves vérifiées : fichiers, commandes, CI, URL déployée ou PR inspectés.
• Preuves manquantes : ce qui changerait la confiance si fourni.
• Action suivante : un correctif concret ou une étape de vérification.

Gardez les points forts courts. L'utilisateur a demandé la préparation, donc la réponse utile est le risque restant et l'action suivante.

Exemple

Utilisateur :

est-ce prêt à livrer ?

Réponse :

Audit production : 68/100, risqué, car les webhooks Stripe sont vérifiés mais pas idempotents et il n'y a pas de note de rollback pour la migration en attente.

Bloqueurs :
- Ajoutez l'idempotence pour `checkout.session.completed` avant d'exécuter les commandes.
- Écrivez et testez le chemin de rollback pour `20260511_add_billing_state.sql`.

Correctifs à haute valeur :
- Ajoutez une vérification de santé qui vérifie la joignabilité de la base de données et du fournisseur de paiement.
- Ajoutez un chemin E2E pour la mise à niveau, l'exécution du webhook et le rafraîchissement de la page de facturation.

Preuves vérifiées :
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- Exécution GitHub Actions pour la branche de version

Action suivante : Voulez-vous que je corrige d'abord l'idempotence du webhook ?

Anti-patrons

• Exécuter npx <package>@latest ou un scanner distant comme chemin d'audit par défaut.
• Télécharger du code source, des secrets, des données client ou une topologie privée vers un service d'audit externe sans approbation explicite.
• Produire un score sans nommer les preuves vérifiées.
• Considérer une CI verte comme une préparation à la production.
• Terminer par un "faites-moi savoir ce que vous voulez faire" générique.

Voir aussi

• Compétence : security-review
• Compétence : deployment-patterns
• Compétence : e2e-testing
• Compétence : tdd-workflow
• Compétence : verification-loop