Liste de contrôle de 23 points pour les applications de vibe coding avant le premier paiement

Avant que votre application de vibe coding n’accepte son premier paiement, demandez à un agent IA de vérifier ces 23 points :

1. Il existe un document unique de design system, et toutes les couleurs, tailles de police et marges y correspondent.
2. Des écrans séparés sont prévus pour chaque état : chargement, absence de données et erreur.
3. Les clés privées sont stockées uniquement sur le serveur. Les fichiers front-end et l’historique Git sont vérifiés pour détecter les fuites, et toutes les clés ayant été exposées sont remplacées.
4. Chaque endpoint d’API vérifie l’autorisation et les droits d’accès côté serveur. La base de données a RLS (Row Level Security) activé.
5. Pour tous les services facturés à l’usage, comme l’IA, les SMS et l’e-mail, des limites de dépense ou des alertes sont configurées.
6. Les webhooks de paiement vérifient la signature, et la réception répétée d’une notification pour le même paiement ne provoque pas de comptabilité en double.
7. Les remboursements, annulations et prélèvements échoués sont testés en mode test. Chaque scénario est exécuté une fois et se termine avec le statut correct.
8. Après la fin de la période d’essai ou de l’abonnement, l’accès est révoqué à temps.
9. Lors du passage des paiements de test aux paiements en production, les clés API de production et le secret de signature des webhooks sont reconfigurés.
10. Les montants monétaires sont stockés sous forme d’entiers dans la plus petite unité monétaire, comme dans Stripe. Aucun nombre flottant : en JavaScript, 0.1 + 0.2 n’est pas égal à 0.3.
11. Un double clic sur le bouton d’envoi crée une seule commande.
12. La taxe de vente ou la TVA est configurée pour les pays où vous vendez le produit.
13. Les conditions d’utilisation et la politique de confidentialité correspondent au fonctionnement réel de l’application.
14. Des sauvegardes automatiques quotidiennes sont configurées. L’offre gratuite de Supabase ne les inclut pas, il faut donc passer à Pro ou mettre en place vos propres dumps. Il faut aussi tester une fois la restauration dans une nouvelle base.
15. Pour chaque migration du schéma de base de données, un SQL de rollback est préparé. La migration et son rollback sont testés sur une copie des données de production.
16. Les listes contenant plus de 1 000 enregistrements ne sont pas tronquées silencieusement. Par défaut, l’API Supabase renvoie jusqu’à 1 000 lignes.
17. L’heure est stockée au format timestamptz, et le fuseau horaire de chaque utilisateur est enregistré dans une colonne séparée afin que les rappels arrivent à l’heure locale.
18. On utilise d’abord la suppression logique (soft delete), et RLS masque aussi les enregistrements supprimés. Lors de la suppression d’un compte, les données de l’utilisateur sont définitivement supprimées.
19. Les utilisateurs peuvent exporter leurs propres données.
20. Les noms avec des apostrophes, des emojis ou du texte de droite à gauche ne provoquent pas d’erreurs dans les champs de saisie.
21. Les images utilisent les formats WebP ou AVIF, et le contenu situé sous la zone visible se charge lors du défilement.
22. Des index sont créés pour les champs filtrés le plus souvent. Avec quelques dizaines d’enregistrements de test, tout peut sembler rapide, mais avec des volumes de données réels, des ralentissements apparaissent.
23. Le monitoring d’erreurs est connecté pour que vous appreniez les problèmes avant vos utilisateurs.

Envoyez toute cette liste à votre agent et ajoutez à la fin le prompt suivant. L’agent vérifiera chaque point et présentera les résultats dans un tableau :

Répartissez la vérification entre cinq sous-agents selon les domaines suivants :

1. Design et performance.
2. Sécurité.
3. Paiements.
4. Données.
5. Fonctionnement de l’application après le lancement.

Vérifiez tous les points sans rien modifier. Pour chaque point, indiquez si la vérification est réussie ou non, ainsi que le fichier où le problème a été trouvé.

Si quelque chose ne peut être vérifié que via le tableau de bord d’un service, marquez le point comme « Confirmation requise de ma part » et fournissez des instructions pas à pas pour une vérification manuelle.

Testez les sauvegardes et la restauration uniquement sur une base de données de test, et les paiements exclusivement en mode test. Ne modifiez pas les données de production.

Affichez d’abord le tableau des résultats et ne corrigez rien tant que je n’ai pas confirmé.