Mon produit « vibe-codé » est-il prêt pour de vrais utilisateurs ? Checklist de lancement

Vous avez construit votre produit avec Lovable, Bolt, Cursor ou Claude, il fonctionne sur votre écran, et les premiers utilisateurs attendent. C'est une vraie réussite : les outils d'IA permettent aux fondateurs de construire en quelques jours ce qui prenait des mois. Mais « ça marche en démo » et « c'est prêt pour de vrais utilisateurs et de vraies données » ne sont pas la même chose. Cette checklist couvre ce que nous regardons en premier quand un fondateur nous demande si son produit conçu avec l'IA est prêt à être lancé.

La réponse courte

Un produit vibe-codé est généralement prêt à être montré, et souvent pas encore prêt à se voir confier des données clients ou des paiements. Les failles se trouvent rarement dans ce que l'on voit. Elles apparaissent quand quelqu'un utilise le produit d'une façon que vous n'avez pas testée : un utilisateur qui modifie un identifiant dans la barre d'adresse, une clé qui fuit, un paiement qui échoue, une base de données sans sauvegardes. Parcourez la checklist ci-dessous avant de lancer, ou demandez à quelqu'un qui sait le faire.

1. Secrets et clés

• Ouvrez votre site en ligne, affichez le code source et cherchez « key », « secret » et « token ». Les clés d'API des prestataires de paiement, des modèles d'IA ou des services d'e-mail ne doivent jamais se trouver dans du code exécuté dans le navigateur.
• Conservez-les dans des variables d'environnement sur le serveur, et renouvelez toute clé qui a déjà été présente dans le navigateur ou dans un dépôt public.
• Fixez des plafonds de dépenses et des alertes sur les API payantes, afin qu'une clé qui fuit ou une boucle ne puisse pas générer une grosse facture en une nuit.

2. Qui peut voir quoi

• Connectez-vous avec un utilisateur de test et essayez d'ouvrir les données d'un autre utilisateur en changeant un identifiant dans l'URL ou dans la requête. Si cela fonctionne, chaque client peut voir les données de tous les autres.
• Si vous utilisez Supabase, assurez-vous que Row Level Security est activé sur chaque table, avec des politiques qui correspondent à qui doit lire et écrire chaque ligne. Sans cela, toute personne disposant de votre clé publique peut interroger la table.
• Vérifiez que les pages et actions d'administration sont protégées côté serveur, et pas seulement masquées dans l'interface.

3. Paiements

• Ne faites jamais confiance à un prix ou à un statut « payé » venant du navigateur. Les prix sont fixés côté serveur, et les commandes sont confirmées par le webhook du prestataire de paiement, dont la signature est vérifiée.
• Testez les paiements refusés, les remboursements et les doubles clics dans le mode test du prestataire, pas seulement le scénario idéal.

4. Données et sauvegardes

• Assurez-vous que votre base de données est sauvegardée automatiquement, et restaurez une sauvegarde une fois pour prouver que cela fonctionne.
• Sachez où vos données sont stockées et qui y a accès. Vos clients le demanderont, et la loi aussi.

5. Quand quelque chose casse

• Ajoutez un suivi des erreurs, pour voir les erreurs que rencontrent vos utilisateurs au lieu de l'apprendre des jours plus tard.
• Ajoutez une surveillance de disponibilité pour le site et les parcours les plus importants, comme l'inscription et le paiement.
• Testez avec des volumes de données réalistes. Une page rapide avec dix enregistrements peut dépasser le délai avec dix mille.

6. Vie privée et bases juridiques

• Une politique de confidentialité qui indique ce que vous collectez et pourquoi, et un consentement aux cookies là où les statistiques ou la publicité l'exigent.
• Si vous avez des utilisateurs dans l'UE, le RGPD s'applique ; en Thaïlande, la PDPA. Les deux donnent aux utilisateurs des droits sur leurs données, comme l'accès et la suppression.

7. Pouvez-vous continuer à construire ?

• Le code est-il dans un dépôt qui vous appartient, comme GitHub, et pouvez-vous le déployer sans l'outil qui l'a généré ?
• Un développeur pourrait-il le comprendre ? Le code généré par l'IA répète souvent la même logique à de nombreux endroits, ce qui rend chaque modification ultérieure plus lente et plus risquée.
• Les parcours critiques, comme l'inscription, la connexion et le paiement, sont-ils couverts par au moins quelques tests automatisés ?

Un rapide autodiagnostic

Question	Prêt	Pas encore
Toutes les clés secrètes sont-elles uniquement sur le serveur ?	Oui, et renouvelées	Certaines sont dans le code du navigateur
Un utilisateur ne voit-il que ses propres données ?	Testé avec deux comptes	Pas testé
Les paiements sont-ils confirmés par le prestataire ?	Webhook avec signature vérifiée	Le navigateur dit « payé »
Y a-t-il une sauvegarde testée ?	Restaurée au moins une fois	On ne sait pas
Saurez-vous quand cela casse ?	Suivi des erreurs et alertes de disponibilité	Les utilisateurs nous le diront
Le code vous appartient-il ?	Dans notre propre dépôt	Uniquement dans l'outil d'IA

Et maintenant ?

Commencez par une analyse gratuite de votre site en ligne avec EngineeringScore, notre propre outil d'audit : il note la sécurité, la performance, le SEO, l'accessibilité et la fiabilité, et vous donne une liste priorisée. Il ne voit pas l'intérieur de votre code ni de votre base de données ; pour les points ci-dessus, un développeur doit donc encore regarder. Nous le faisons sous forme de petit projet, facturé à la journée, ou avec l'aide d'urgence quand le feu est déjà là. Nous aimons les produits conçus avec l'IA ; nous utilisons ces outils tous les jours nous-mêmes. Nous veillons simplement à ce qu'ils soient prêts pour les personnes qui vont s'y fier.