Ouvrir son app vibe-codée à de vrais clients : la checklist avant lancement

Avant d’ouvrir une app vibe-codée à de vrais clients, vous n’avez pas besoin de résoudre tous les défauts du produit. Identifiez les incidents encore acceptables, ceux qui seraient graves et la façon de réagir si l’un d’eux arrive.

Cette checklist aboutit à trois décisions possibles :

• ouvrir si les parcours critiques sont maîtrisés ;
• limiter le pilote si le risque peut être contenu par le nombre d’utilisateurs ou le périmètre ;
• décaler si une erreur peut exposer des données, encaisser à tort ou rendre le produit irrécupérable.

1. Les comptes et les accès

• Un utilisateur peut créer son compte et confirmer son adresse.
• Il peut réinitialiser son mot de passe sans intervention manuelle.
• Une session expirée renvoie vers la connexion sans perdre silencieusement une action.
• Les pages d’administration refusent réellement les comptes standards.
• Un utilisateur supprimé ou désactivé ne conserve pas une session active indéfiniment.

Pour quelques testeurs que vous connaissez, un accès sur invitation peut compenser une inscription encore imparfaite. Si des inconnus peuvent créer un compte, testez les accès avant l’ouverture.

2. La séparation des données

• Un client ne peut pas consulter les données d’un autre en changeant un identifiant dans l’URL.
• Les exports, pièces jointes et liens de téléchargement appliquent les mêmes permissions que les écrans.
• Les comptes de support ou d’administration ont des droits explicites.
• Les environnements de développement n’utilisent pas une copie librement accessible des données réelles.

Ne vous contentez pas de parcourir l’interface avec deux comptes. Tentez une action interdite. Les failles fréquentes des apps générées par IA se cachent souvent derrière un écran qui paraît correctement filtré.

Si l’isolation entre clients n’est pas démontrée, décalez. Réduire le nombre de testeurs ne protège pas les données de chacun.

Le test ne consiste pas seulement à deviner un autre numéro. L’OWASP recommande de créer plusieurs comptes puis de rejouer les lectures, modifications, suppressions et exports avec le mauvais utilisateur.

3. Les actions irréversibles

• Une suppression demande une confirmation claire.
• Une action importante ne part pas deux fois après un double clic.
• Les changements sensibles laissent une trace exploitable.
• Vous savez quelles données peuvent être restaurées après une erreur.

Un pilote reste possible si les actions irréversibles sont désactivées et traitées manuellement. Ne les laissez pas actives « pour voir ».

4. Les paiements

• Le montant et la devise sont vérifiés côté serveur.
• Un paiement refusé ne donne pas accès au service payant.
• Un paiement confirmé n’est pas perdu si le client ferme son onglet.
• Un même événement reçu plusieurs fois ne crée pas plusieurs commandes.
• Le remboursement et l’annulation ont été essayés au moins une fois.
• Le mode test et le mode production utilisent des clés et des produits distincts.

Si vous n’avez pas testé le refus, le retard et le remboursement, lancez sans paiement ou limitez-vous à une facturation manuelle pendant le pilote.

Les webhooks doivent aussi supporter les doublons. Stripe indique qu’un endpoint peut recevoir plusieurs fois le même événement et recommande d’enregistrer les identifiants déjà traités.

5. Les emails et services externes

• Les emails essentiels arrivent sur plusieurs fournisseurs de messagerie.
• Un échec d’envoi est visible quelque part.
• Les comptes des services externes appartiennent au projet ou à l’entreprise.
• Les clés secrètes ne sont ni dans le navigateur ni dans le dépôt Git.
• Une limite de quota ne bloque pas silencieusement tout le produit.

Une fonction secondaire peut être coupée. Surveillez dès le premier jour une dépendance indispensable sans solution de repli.

6. Les erreurs compréhensibles

• Un formulaire invalide explique quoi corriger sans effacer les autres réponses.
• Une erreur serveur n’affiche pas de secret, de requête ou de détail interne.
• L’équipe peut relier le message d’un utilisateur à une erreur enregistrée.
• Les écrans vides et chargements infinis ont été cherchés sur mobile et ordinateur.

Une formulation imparfaite n’empêche pas un pilote. En revanche, une erreur impossible à diagnostiquer sur le parcours principal le bloque.

7. Les sauvegardes et le retour arrière

• Vous savez quand la dernière sauvegarde exploitable est créée.
• Une restauration a été testée dans un environnement isolé.
• La version précédente de l’application peut être redéployée.
• Une migration de base de données dispose d’une procédure de retour ou de correction.
• Une personne précise sait quoi faire si le lancement se passe mal.

Ne lancez pas une opération irréversible si votre seul plan consiste à demander ensuite à l’IA comment revenir en arrière.

La CNIL demande de tester régulièrement l’intégrité des sauvegardes et leur restauration. La présence d’une option « sauvegarde automatique » dans un tableau de bord ne suffit donc pas à cocher cette partie.

8. Le support des premiers clients

• Les utilisateurs savent où signaler un problème.
• Vous pouvez identifier leur compte sans leur demander un mot de passe.
• Les incidents sont classés par impact, pas par ordre d’arrivée.
• Une réponse temporaire existe pour les fonctions non critiques.
• Vous avez réservé du temps après l’ouverture pour observer le produit.

Le support des premiers jours fait partie du lancement. Évitez de programmer l’ouverture juste avant une période où personne ne pourra regarder les erreurs.

Un pilote avec cinq personnes bien accompagnées peut être plus instructif qu’une ouverture publique prématurée.

9. Les règles de confiance

• Les mentions légales et la politique de confidentialité correspondent au produit réel.
• La collecte de données est limitée à ce qui est utile maintenant.
• Les utilisateurs savent ce que fait une fonction IA avec leurs données.
• Les conditions annoncées sur les prix, essais ou annulations sont applicables dans le produit.

Cette checklist ne remplace pas une validation juridique. Elle évite toutefois le décalage le plus courant : promettre sur le site un contrôle que l’application ne sait pas encore appliquer.

10. Le test final en conditions réelles

Créez un nouveau compte avec une adresse qui n’a jamais servi. Utilisez un téléphone sur un réseau mobile. Suivez le parcours sans accès à la base, sans corriger le code et sans ouvrir l’outil qui a généré l’app.

Notez chaque moment où vous devez « savoir » quoi faire. Un vrai client ne connaît pas les raccourcis du créateur.

Pour une revue plus technique, utilisez les douze points de l’audit d’un prototype IA. Pour juger le niveau de maturité global, relisez aussi ce qu’un prototype Lovable doit vérifier avant la production.

Choisir entre ouverture, pilote limité et report

Ouvrez si les permissions, les données, les paiements et le retour arrière sont maîtrisés sur le parcours principal.

Limitez le pilote si les défauts restants peuvent être contenus : inscriptions sur invitation, paiement manuel, faible volume, fonction secondaire désactivée et support rapproché.

Décalez si vous ne pouvez pas exclure une fuite entre clients, un encaissement incohérent ou une perte de données sans restauration testée.

Vous n’avez pas besoin d’un audit si cette checklist produit un verdict clair et que le risque reste faible. Si plusieurs cases critiques restent impossibles à vérifier, réservez un échange de 30 minutes avec TechSprint. Nous regarderons ce qui bloque la décision, pas le nombre de cases cochées.

Fabrice Payet — fondateur de TechSprint, La Réunion.