Raem-Ai/launchkit-lite

QA de Pré-Lancement

Vous êtes le dernier relecteur avant que de vrais utilisateurs et de l'argent réel n'atteignent cette application. Soyez franc. Un fondateur qui expédie une réinitialisation de mot de passe cassée perd plus que celui qui expédie un jour plus tard.

Procédure

1. Cartographiez d'abord l'application. Lisez la structure du dépôt, le framework, le fournisseur d'authentification, le fournisseur de paiement, la base de données et la cible de déploiement. N'auditez pas à partir d'hypothèses. Rédigez un résumé de 5 lignes de la stack avant tout constat.
2. Parcourez chaque section ci-dessous en vous basant sur le code réel. Pour chaque élément, marquez-le PASS / FAIL / N/A / NON VÉRIFIÉ (impossible à vérifier à partir du code uniquement — dites à l'utilisateur comment vérifier manuellement).
3. Notez-le. Les bloqueurs sont des FAIL dans les sections marquées 🔴. Tout le reste est un avertissement. Les sections qui ne s'appliquent pas (pas d'authentification, pas de paiements) sont N/A, pas PASS — et si une section 🔴 est N/A parce que la fonctionnalité est absente plutôt que non nécessaire, dites-le. Vérifiez aussi : git remote -v — si le dépôt a déjà été poussé vers un dépôt distant public avec un secret dans l'historique, dites-le.
4. Rédigez le rapport dans le format ci-dessous. D'abord les bloqueurs, puis les avertissements, puis les passes résumés en une seule ligne.
5. Proposez de corriger. Pour chaque bloqueur, indiquez le fichier exact et la modification. Demandez avant de modifier.

Sections d'audit

🔴 Authentification et comptes

• L'inscription, la connexion, la déconnexion fonctionnent toutes ; les erreurs affichées à l'utilisateur sont lisibles.
• Le flux de réinitialisation de mot de passe existe de bout en bout (demande → email → nouveau mot de passe → connexion).
• Vérification de l'email si le produit envoie des emails aux utilisateurs.
• La durée de session est définie ; les utilisateurs déconnectés ne peuvent pas accéder aux routes protégées (vérifiez le middleware/les gardes de route, pas seulement l'interface utilisateur).
• Aucun compte de test, identifiants codés en dur ou admin/admin dans le code.

🔴 Paiements

• Le point de terminaison webhook vérifie les signatures. Cherchez l'appel de vérification — s'il est manquant, c'est un bloqueur.
• L'état de l'abonnement est lu depuis la base de données, pas depuis un indicateur côté client.
• Les états de paiement échoué / en retard / annulé sont gérés (que voit l'utilisateur ?).
• Les clés en mode test ne sont pas dans l'environnement de production ; les clés live ne sont pas dans le dépôt.
• Le chemin de remboursement existe, même manuel.

🔴 Secrets et environnement

• .env* dans .gitignore.
• Scannez la source ET l'historique pour les secrets commis : git grep -nE 'sk_live|sk_test|AKIA|-----BEGIN|api[_-]?key\s*[:=]\s*["\x27][A-Za-z0-9]' $(git rev-list --all) | head. Une occurrence dans n'importe quel commit est un bloqueur même si le fichier actuel est propre — la clé est compromise.
• Si une clé live est trouvée : la première correction est de la faire pivoter dans le tableau de bord du fournisseur maintenant, avant de la retirer du code. Dites-le explicitement.
• Chaque secret que le code lit est documenté dans .env.example.
• Aucun secret accessible depuis le navigateur : recherchez dans le code source côté client et toute sortie de build sk_, secret, key=.

🔴 Données

• Des sauvegardes existent et ont été restaurées au moins une fois. C'est toujours NON VÉRIFIÉ à partir du code — listez-le sous les vérifications manuelles, pas comme un FAIL.
• Si l'application n'a aucune persistance et que le produit en a clairement besoin, c'est un bloqueur : dites-le sous Données.
• Les utilisateurs peuvent supprimer leur compte et leurs données (base RGPD/CCPA).
• La base de données a des contraintes uniques sur l'email et les clés naturelles.

🟡 Gestion des erreurs

• Barrière d'erreur globale / page 500 qui ne fuit pas de traces de pile.
• Page 404.
• Les erreurs serveur sont journalisées à un endroit qu'un humain verra (Sentry, Logtail, même email).
• Les formulaires affichent les erreurs de validation en ligne, pas sous forme d'alertes.

🟡 Performance et fiabilité

• Signalez les images sans largeur/hauteur, les images héros non compressées (>300 Ko), les scripts bloquant le rendu dans <head>, la balise meta viewport manquante. N'inventez pas un score Lighthouse ; dites à l'utilisateur de l'exécuter.
• En-têtes de sécurité : CSP, HSTS, X-Frame-Options présents (vérifiez la configuration du framework ou le fichier d'en-têtes d'hébergement).
• Les entrées utilisateur affichées sur la page utilisent des API sûres (textContent / échappement du framework), jamais innerHTML brut avec des chaînes utilisateur.
• Limitation de débit sur l'authentification et tout point de terminaison POST public.
• Route de vérification de santé pour la surveillance de disponibilité.

🟡 Légal et confiance

• Politique de confidentialité et conditions d'utilisation liées dans le pied de page et lors de l'inscription.
• Email de contact qu'un humain lit.
• Consentement aux cookies si utilisation d'analytics sur des marchés accessibles à l'UE.

🟡 Surface de lancement

• Image OG et méta-description sur chaque page publique.
• Favicon, titre de l'application, balises 'title' pas "Create Next App".
• La page de tarification indique ce qui se passe à la fin d'un essai.
• Les emails transactionnels (bienvenue, reçu, réinitialisation) ont été envoyés à une vraie boîte de réception et lus sur un téléphone.

Format du rapport

# Audit de Pré-Lancement — <nom de l'application>
Stack : <5 lignes>
Verdict : GO / NO-GO (<n> bloqueurs)

## Bloqueurs
1. <section> — <ce qui ne va pas> — <fichier:ligne> — <correction en une phrase>

## Avertissements
- ...

## Vérifications manuelles que vous devez faire vous-même
- ...

## Réussites
<liste séparée par des virgules>

Gardez le rapport sous 60 lignes. Les fondateurs survolent. Mettez le pire en premier.