getpaidskills/launch-checklist

checklist-de-lancement

Exécutez l'audit automatisé, corrigez ce qui échoue dans le code, relancez jusqu'à ce que tout soit propre, puis parcourez les éléments manuels que le script ne peut pas voir. Signalez à l'utilisateur ce que vous avez modifié et ce qui nécessite encore son action.

Étape 1 — Exécuter l'audit

Contre l'URL de production si elle existe, sinon contre une build de production locale (npm run build && npm start, pas le serveur de développement — les serveurs de développement ajoutent des scripts et ignorent le cache) :

python3 scripts/audit_site.py https://example.com            # rapport texte
python3 scripts/audit_site.py http://localhost:3000 --max-pages 30 --json > audit.json

Ce qui est vérifié (détails dans references/checks.md) :

• Par page : <title> (10–60 caractères), meta description (50–160), exactement un <h1>, <html lang>, viewport, canonical (absolue, même hôte), og:title/description/image, twitter:card, <img> sans alt, taille HTML, temps de réponse, noindex sur des pages que vous souhaitez probablement indexées, titres/descriptions en double entre pages.
• Site : /robots.txt existe et ne Disallow: / pas tout, référence un sitemap ; /sitemap.xml (ou celui nommé dans robots) s'analyse et ses URLs renvoient 200 sur le même hôte ; favicon accessible ; apple-touch-icon ; une URL aléatoire renvoie 404 (pas 200 ou une redirection vers l'accueil) ; redirection http→https (pour les sites https) ; liens vers la politique de confidentialité / conditions (et la politique de remboursement si le site vend quelque chose) ; présence de /llms.txt (informationnel uniquement).

Code de sortie 1 lorsqu'un FAIL est présent. Pages explorées : URL de départ + liens vers le même hôte, jusqu'à --max-pages (20 par défaut).

Étape 2 — Corriger dans la base de code

Détectez le framework et utilisez la recette correspondante. Pour Next.js App Router, references/fixes-nextjs.md contient des fichiers prêts à l'emploi (robots.ts, sitemap.ts, not-found.tsx, metadata, conventions d'icônes). Générique HTML/autres frameworks : references/fixes-generic.md.

Règles :

• Corrigez la cause racine (layout partagé / assistant de métadonnées), pas page par page, lorsque le problème se répète.
• N'ajoutez jamais noindex ou ne bloquez pas les robots sans demander.
• Pages légales manquantes : générez-les avec la compétence legal-pages si installée ; sinon informez l'utilisateur — n'inventez pas de texte légal en ligne.
• Images OG manquantes : utilisez la compétence og-image-kit si installée.

Étape 3 — Relancer jusqu'à l'absence de FAIL

Relancez la même commande. Éléments WARN : corrigez les moins coûteux, listez les autres pour l'utilisateur.

Étape 4 — Éléments manuels (le script ne peut pas vérifier)

Parcourez references/manual-checklist.md avec l'utilisateur — analytics installés, suivi des erreurs, délivrabilité des e-mails transactionnels (SPF/DKIM/DMARC), flux de paiement testé de bout en bout avec un petit paiement réel, sauvegardes, moniteur de disponibilité, vérification Search Console / Bing Webmaster et soumission du sitemap, état du renouvellement du domaine. Marquez chaque élément comme fait / non applicable / à faire par l'utilisateur.

Étape 4b — Auto-contrôle des paiements (si le site prend de l'argent)

python3 scripts/payment_check.py --src . --provider creem          # analyse du code
python3 scripts/payment_check.py --url http://localhost:3000        # sonde une build en cours
python3 scripts/payment_check.py --url http://localhost:3000 --secret "$CREEM_WEBHOOK_SECRET"  # secret en mode test uniquement

FAIL : le webhook accepte des requêtes non signées ou falsifiées, analyse JSON avant vérification, pas de déduplication sur l'ID d'événement, la page de succès accorde l'accès, les secrets de paiement dans NEXT_PUBLIC_* ou commités, le webhook redirige ou se trouve derrière un défi bot. Corrigez-les, relancez, puis effectuez les tests de carte manuels dans references/payment-checks.md (carte réussie, carte refusée, remboursement, renvoi depuis le tableau de bord, annulation). Ne passez jamais un secret de webhook en direct. scripts/test_payment_check.py est le test propre du script. Les fichiers de test, specs et fixtures (*.test.ts, *.spec.tsx, test_*.py, tout ce qui se trouve sous tests/, e2e/, __tests__/, fixtures/) ne sont pas jugés comme des gestionnaires ou des pages de succès, car ils envoient intentionnellement des requêtes non signées et insèrent des lignes ; ils sont toujours analysés pour les clés en direct commitées. Le rapport indique combien ont été ignorés (INFO test files).

Format du rapport

Audit de lancement pour <url> — <date>
FAIL corrigé : …   (fichier:ligne modifié)
WARN corrigé : …
Toujours ouvert (vous devez agir) : …
Liste de contrôle manuelle : x/y effectué