La plupart des apps créées par IA connectent les utilisateurs avec Supabase (Lovable, Bolt, v0 et beaucoup d’apps de Cursor ou Claude Code), Firebase (Antigravity), Clerk, ou la connexion propre au générateur (Replit, Base44). Les pages des fournisseurs couvrent chacun en détail : problèmes Supabase, problèmes Firebase. Cette page couvre ce que les apps générées ajoutent par-dessus.
Cela fonctionne pour vous, et pour personne d’autre
Vous avez créé l’app, donc vous faites partie de l’équipe du projet Supabase, vous êtes sans doute encore connecté, et vous testez sur le domaine que le générateur vous a montré. Un testeur n’a rien de tout cela :
- Le service d’e-mail n’écrit qu’à vous. L’expéditeur intégré de Supabase ne livre qu’à l’équipe du projet, 2 e-mails par heure au maximum. Configurez un SMTP personnalisé. Sur Lovable Cloud, vérifiez les limites d’envoi dans les réglages Auth.
- Vous êtes déjà connecté. Une inscription cassée paraît normale à quelqu’un qui a une session. Testez dans une fenêtre privée, avec une adresse jamais utilisée.
Le lien ouvre l’aperçu, ou localhost
Le lien de l’e-mail est construit à partir du réglage de l’adresse publique de l’app. S’il est resté sur http://localhost:3000, ou réglé sur un lien d’aperçu qui a changé au déploiement suivant, les gens arrivent sur une page qui ne s’ouvre pas. Sur Lovable Cloud, Lovable le règle à la publication sauf si vous l’avez défini vous-même ; sur votre propre projet Supabase, c’est la Site URL. Réglez-la sur le domaine publié et listez les aperçus dans Redirect URLs. Plus de détails dans pourquoi les e-mails pointent vers localhost. Proxy Mail QA signale ces liens sur la ligne de l’adresse.
Cliquer sur le lien ne connecte personne
Le lien renvoie un code à votre app, et une page doit l’échanger contre une session. Les apps générées envoient souvent le lien vers la page d’accueil, qui ignore le code : la personne arrive déconnectée et pense que cela a échoué. Demandez une page qui termine la connexion (souvent /auth/callback) et vers laquelle pointe le lien de l’e-mail. Avec Supabase, les testeurs doivent ouvrir le lien dans le navigateur où ils se sont inscrits : pourquoi.
« Vérifiez vos e-mails », quoi qu’il arrive
Les formulaires d’inscription générés affichent souvent le même message de succès quelle que soit la réponse du fournisseur. Derrière :
- L’adresse a déjà un compte. Supabase répond comme si l’inscription avait réussi et n’envoie rien, pour ne pas révéler qui a un compte. L’app devrait dire : « Si cette adresse est nouvelle, nous avons envoyé un lien. Déjà inscrit ? Connectez-vous ou réinitialisez votre mot de passe. »
- C’était trop tôt. Une deuxième demande dans les 60 secondes est refusée, et l’app masque l’erreur.
- La confirmation par e-mail est désactivée. Le compte a été créé et connecté, sans aucun e-mail.
Demandez au générateur d’afficher l’erreur du fournisseur quand il y en a une, et de formuler le message de succès pour qu’il soit vrai dans tous les cas.
L’e-mail de réinitialisation ne mène nulle part
Un lien de réinitialisation de mot de passe connecte la personne, puis l’app doit afficher un formulaire « choisir un nouveau mot de passe ». Les apps générées omettent souvent cette page : la personne est connectée avec son ancien mot de passe sans moyen de le changer. Demandez une page de réinitialisation ouverte par le lien, et testez-la de bout en bout : Tester les e-mails de réinitialisation de mot de passe.
Des formulaires qui refusent de vraies personnes, ou laissent passer de mauvaises données
- Trop stricts : certains formulaires générés rejettent les adresses avec un
+, des majuscules ou une extension de domaine récente comme.dev, ou les noms avec une apostrophe. Adresses inhabituelles et noms et mots de passe inhabituels listent quoi essayer. - Trop permissifs : le formulaire accepte une valeur que la base de données refuse, et l’inscription échoue avec « Database error saving new user » quand la table
profilesde l’app la rejette. Un nom de 255 caractères ou un nom d’utilisateur vide les révèle.
La confirmation a été désactivée pendant le développement
Les générateurs désactivent parfois la confirmation par e-mail pour que l’inscription soit plus rapide à essayer, et elle reste désactivée au lancement. N’importe qui peut alors s’inscrire avec une adresse qui ne lui appartient pas, et vous ne voyez jamais si l’e-mail de confirmation fonctionne. Réactivez-la avant de partager l’app, et testez-la avec une adresse qui reçoit du courrier.
L’agent dit que c’est terminé
Un agent de codage vérifie que le formulaire s’envoie, pas que l’e-mail arrive ni que son lien fonctionne. Connectez le MCP server Proxy Mail QA et demandez-lui de s’inscrire avec une nouvelle adresse, d’attendre le code ou le lien et de terminer l’inscription. Il ne lit que le code ou le lien, jamais le texte de l’e-mail.
Prompts à copier-coller pour votre générateur
Check our login setup: list every email the app sends (sign-up confirmation, magic link, password reset, email change), which service sends it, and the page each link opens. Flag any link built from localhost or a preview address, and any link that opens a page that doesn't finish signing in.Add a page that finishes sign-in when someone opens the link in a confirmation or magic-link email, and a page to choose a new password after a reset link. Point the email links at them.On sign-up, show the error the login service returns, if any. When it succeeds, say: "If that address is new, we've sent a link. Already signed up? Sign in or reset your password." Never say an email was sent when it wasn't.Le guide de votre générateur
Chacun couvre ses propres options et réglages de connexion : Lovable, Bolt, v0, Replit, Base44, Antigravity, Cursor et Claude Code. Vous ne savez pas quelle connexion le vôtre utilise ? Comparatif des méthodes de connexion.