audit-production

Audit de 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 de l'idée obsolète de la communauté « production-audit », adaptée pour rester sûre : elle conserve l'optique utile de préparation à la production et supprime l'exécution de code externe non épinglé ainsi que 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 pourrait casser en prod », « qu'avons-nous oublié », « auditez ce dépôt », ou « prêt à être livré ? »
• Une fonctionnalité a été fusionnée et nécessite un passage aux risques avant déploiement ou après fusion.
• Un lancement public, une démo, un déploiement client ou une présentation aux investisseurs approche.
• L'intégration continue est verte, mais l'utilisateur veut des risques de production, pas seulement un statut de test.
• Une URL déployée, une branche de version, une pull request ou la copie de travail actuelle est disponible pour collecter des preuves.

Quand ne pas l'utiliser

• Pendant une implémentation active, où l'angle approprié est le codage sécurisé au niveau de la ligne ; utilisez d'abord security-review.
• Pour des bibliothèques pures, des modèles, des dépôts de documentation uniquement, ou des échafaudages, sauf si l'utilisateur souhaite une préparation à l'empaquetage ou à la publication plutôt qu'à 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 légale, 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, sauf si l'utilisateur approuve explicitement cet outil et ce flux de données.

Utilisez cet ordre :

1. Établissez la surface de publication.
2. Lisez les changements récents et l'état actuel de la branche.
3. Inspectez les limites d'exécution, d'authentification, de données, de paiement, de tâches d'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 d'environnement et le chemin de retour arrière.
5. Produisez une recommandation courte de livraison/refus avec des correctifs spécifiques.

Liste de vérification des preuves

Commencez par des 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 publication, fichiers Docker et manifestes de déploiement.
• Routes API, webhooks, middleware d'authentification, travailleurs d'arrière-plan, tâches cron et migrations de base de données.
• Documentation des variables d'environnement et vérifications de démarrage.
• Points d'observabilité, rapports d'erreurs, journaux, vérifications de santé et tableaux de bord.
• Instructions de retour arrière, d'ensemencement, de migration et de remise à jour.
• Couverture de tests de bout en bout pour les parcours utilisateur les plus importants.

Si une URL déployée est dans le périmètre, utilisez des vérifications HTTP ou de navigateur uniquement contre cette URL et évitez les actions nécessitant des identifiants, sauf si l'utilisateur fournit un compte de test sûr.

Angles de risque

Sécurité et Authentification

• Les routes publiques, les routes API et les routes d'administration sont-elles clairement séparées ?
• L'authentification et l'autorisation sont-elles appliquées côté serveur ?
• Les secrets sont-ils gardés hors des bundles clients, des journaux, des exemples de sortie et des fichiers commités ?
• Les limites de débit, 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 d'IA ou d'agent se défend-elle contre l'injection de prompt, l'abus d'outils et le contenu non fiable qui passe dans des actions privilégiées ?

Intégrité des données

• Les migrations s'exécutent-elles proprement en avant et ont-elles un plan de retour arrière ou de récupération ?
• Les migrations destructrices, les remises à jour et les importations de données sont-elles exécutées en toute sécurité par étapes ?
• Les politiques de base de données, les privilèges et les limites du rôle de service correspondent-ils au modèle de location de l'application ?
• Les nouvelles tentatives sont-elles idempotentes pour les écritures, les tâches et les gestionnaires de webhook ?

Paiements et Webhooks

• Les signatures de webhook 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 cas de rejeu, de livraison en double et de livraison en désordre sont-ils gérés ?
• Les identifiants de mode test et de mode réel sont-ils séparés ?

Opérations

• L'application peut-elle démarrer à partir d'une copie propre en utilisant des commandes documentées ?
• Les variables d'environnement requises sont-elles nommées, validées et échouent-elles rapidement ?
• Existe-t-il une vérification de santé qui prouve que les dépendances sont accessibles ?
• Les chemins de déploiement, de retour arrière et de responsable d'incident sont-ils documentés ?
• Les journaux sont-ils utiles sans fuite de secrets ou de données personnelles ?

Expérience Utilisateur

• Les parcours critiques pour le lancement sont-ils couverts sur ordinateur 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, d'erreur et de permissions refusées informent-ils l'utilisateur de ce qui s'est passé ?
• Existe-t-il un chemin d'assistance ou de récupération lorsque une opération critique échoue ?

Notation

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

Niveau	Score	Signification
Bloqué	0-49	Ne pas livrer avant que les risques majeurs soient corrigés
Risqué	50-69	Livrer uniquement derrière un petit déploiement ou une version bêta interne
Lançable avec réserves	70-84	Livrer 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 absente sur des 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é.
• Des secrets sont exposés dans les bundles clients, les journaux ou les fichiers commités.
• Il n'y a pas de chemin de retour arrière pour une version à fort impact.

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

Format de sortie

Commencez par une phrase :

Audit de production : 76/100, lançable avec réserves, avec l'idempotence des webhooks et la documentation de retour arrière 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.
• Prochaine action : un correctif ou une étape de vérification concrète.

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

Exemple

Utilisateur :

est-ce prêt à être livré ?

Réponse :

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

Bloqueurs :
- Ajouter l'idempotence pour `checkout.session.completed` avant d'exécuter les commandes.
- Écrire et tester le chemin de retour arrière pour `20260511_add_billing_state.sql`.

Correctifs à haute valeur :
- Ajouter une vérification de santé qui vérifie la base de données et l'accessibilité du fournisseur de paiement.
- Ajouter un chemin E2E pour la mise à niveau, l'exécution du webhook et l'actualisation 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

Prochaine action : 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 la source, les secrets, les données clients ou la topologie privée vers un service d'audit externe sans approbation explicite.
• Produire un score sans nommer les preuves vérifiées.
• Traiter une CI verte comme une préparation à la production.
• Terminer par un générique « faites-moi savoir ce que vous voulez faire. »

Voir aussi

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