En bref
| Méthode de connexion | Ce que font vos utilisateurs | E-mails envoyés | Testable avec Proxy Mail QA |
|---|---|---|---|
| E-mail et mot de passe | Choisir un mot de passe, puis confirmer leur e-mail | Confirmation, réinitialisation du mot de passe, changement d’e-mail | Oui, tous |
| Code par e-mail | Saisir un code court reçu par e-mail | Un nouveau code à chaque connexion | Oui, avec un bouton Copier |
| Lien magique | Cliquer sur un lien dans un e-mail | Un nouveau lien à chaque connexion | Oui, et nous n’ouvrons jamais le lien avant vous |
| Google, Apple, Microsoft ou GitHub | Cliquer sur un bouton et choisir leur compte | Aucun pour se connecter | Non : utilisez un vrai compte qui vous appartient |
| Code par téléphone | Saisir un code reçu par SMS | Aucun : c’est un SMS | Non : nous recevons uniquement des e-mails |
| Connexion d’entreprise (SSO) | Se connecter via le système d’authentification de son employeur | Aucun pour se connecter | Non |
Quel que soit votre choix, votre app envoie toujours ses propres e-mails, comme les invitations, les reçus et les notifications. Vous pouvez vérifier qu’ils arrivent et renvoient au bon endroit, quelle que soit la méthode de connexion.
E-mail et mot de passe
La méthode que tout le monde connaît. Les utilisateurs choisissent un mot de passe et, si la confirmation par e-mail est activée, ils reçoivent un e-mail avec un lien ou un code et ne peuvent pas se connecter avant de l’avoir utilisé.
E-mails envoyés : une confirmation d’inscription, les réinitialisations de mot de passe et un e-mail pour confirmer la nouvelle adresse quand quelqu’un change la sienne.
Ce qui pose souvent problème :
- La confirmation est désactivée, donc n’importe qui peut s’inscrire avec une adresse qui n’est pas la sienne, ou avec une faute de frappe, et vous ne pourrez jamais le joindre.
- La confirmation est activée, mais l’e-mail n’arrive jamais, souvent parce que l’app utilise encore l’expéditeur d’e-mails par défaut de son outil de création ou de sa base de données, qui a des limites basses. Pourquoi les e-mails n’arrivent pas.
- Le lien ouvre localhost ou une adresse de prévisualisation au lieu de votre app publiée. Comment corriger.
- Le lien de réinitialisation du mot de passe mène à une page qui ne permet pas de choisir un nouveau mot de passe.
Testez-le : inscrivez-vous avec une nouvelle adresse et utilisez le lien ou le code. Déconnectez-vous, puis reconnectez-vous. Demandez ensuite une réinitialisation du mot de passe et allez jusqu’au bout. Étape par étape.
Codes par e-mail
Les utilisateurs saisissent leur e-mail, reçoivent un code court (souvent 6 chiffres) et le saisissent. Aucun mot de passe à retenir. Certaines apps utilisent aussi un code pour confirmer l’inscription : c’est le cas de Base44 et de Clerk.
E-mails envoyés : un nouveau code à chaque connexion.
Ce qui pose souvent problème :
- Le code expire avant l’arrivée de l’e-mail.
- Demander un deuxième code n’annule pas le premier, ou annule les deux.
- Quelqu’un qui demande deux fois reçoit « too many requests » et se retrouve bloqué.
Testez-le : demandez un code et utilisez-le. Demandez-en deux d’affilée et vérifiez que seul le plus récent fonctionne. Proxy Mail QA affiche un compte à rebours quand l’e-mail indique la durée de validité du code. En savoir plus sur le test des codes.
Liens magiques
Les utilisateurs saisissent leur e-mail et cliquent sur le lien que vous leur envoyez. Un clic, pas de mot de passe.
E-mails envoyés : un nouveau lien à chaque connexion.
Ce qui pose souvent problème :
- Le lien ouvre localhost au lieu de votre app.
- Le lien échoue dans un autre navigateur, ou sur un téléphone où l’app de messagerie ouvre son propre navigateur.
- Dans certaines entreprises, les scanners de sécurité des e-mails ouvrent les liens avant la personne, ce qui les consomme.
Testez-le : demandez un lien et ouvrez-le dans le même navigateur, puis essayez-le sur un autre appareil. Vérifiez qu’un lien déjà utilisé ou expiré explique quoi faire. Proxy Mail QA n’ouvre ni ne précharge jamais les liens, donc le vôtre est encore valide quand vous cliquez dessus. En savoir plus sur les liens magiques.
Boutons Google, Apple, Microsoft et GitHub
Les utilisateurs cliquent sur Continuer avec Google (ou Apple, Microsoft ou GitHub) et choisissent leur compte. Votre app ne gère jamais de mot de passe, c’est pourquoi les outils de création d’apps par IA les ajoutent si volontiers.
E-mails envoyés : aucun pour la connexion. Le fournisseur s’en charge.
Ce qui pose souvent problème :
- Cela fonctionne en prévisualisation mais échoue sur votre app publiée ou votre domaine personnalisé. La nouvelle adresse ne figure pas dans la liste des redirections autorisées du fournisseur, et Google affiche
redirect_uri_mismatch. - L’écran de connexion affiche le nom de votre outil de création, pas celui de votre app. Lovable et Base44 proposent tous deux une configuration partagée qui fonctionne immédiatement. Passez à vos propres identifiants avant le lancement si cela compte pour vous.
- Quelqu’un s’inscrit avec e-mail et mot de passe, puis clique plus tard sur Continuer avec Google avec la même adresse. Décidez si cela doit donner un seul compte ou une erreur, et testez-le.
- Sign in with Apple peut masquer l’e-mail des utilisateurs. Votre app reçoit une adresse se terminant par
privaterelay.appleid.com, et vos e-mails n’atteignent la personne que si vous avez enregistré votre domaine d’envoi auprès d’Apple.
Testez-le : ces boutons nécessitent un vrai compte, utilisez donc un compte Google ou Apple qui vous appartient, sur l’app publiée comme sur la prévisualisation.
Codes par téléphone
Les utilisateurs saisissent leur numéro de téléphone et reçoivent un code par SMS. Cela nécessite un fournisseur SMS comme Twilio, et chaque SMS est payant. Proxy Mail QA ne reçoit que des e-mails, il ne peut donc pas vous aider ici.
Connexion d’entreprise (SSO)
Pour les apps vendues aux entreprises : les employés se connectent via le système d’authentification de leur employeur, comme Okta ou Microsoft Entra ID, généralement via un standard appelé SAML. Lovable et Base44 le prennent tous deux en charge. Aucun e-mail n’est envoyé pour la connexion, mais les invitations d’équipe passent généralement toujours par e-mail.
Se connecter avec le compte de l’outil de création
Certains outils de création permettent de se connecter avec un compte sur l’outil lui-même. Avec Replit Auth, vos utilisateurs se connectent avec un compte Replit sur une page aux couleurs de Replit, et Replit envoie les e-mails, comme les réinitialisations de mot de passe. Lovable propose aussi Sign in with Lovable. Cela convient aux outils internes et aux apps destinées à d’autres créateurs. Pour une app publique, vous voudrez généralement vos propres comptes : sur Replit, c’est Clerk Auth.
Que doit utiliser une nouvelle app ?
Pour la plupart des apps : e-mail plus Google.
- Google est l’inscription la plus rapide pour la plupart des gens.
- L’e-mail couvre tous les autres : les personnes sans Google, celles qui utilisent une adresse professionnelle et celles qui préfèrent ne pas lier leur compte.
- Préférez les codes ou les liens magiques si vous ne voulez pas de mots de passe. Les codes fonctionnent mieux quand les gens lisent leurs e-mails sur leur téléphone mais utilisent votre app sur un ordinateur portable.
- Laissez la confirmation par e-mail activée, et envoyez les e-mails depuis votre propre domaine avant le lancement.
Quelle connexion votre outil de création configure-t-il ?
| Créé avec | Connexion fournie | Options de connexion |
|---|---|---|
| Lovable | Lovable Cloud, ou votre propre projet Supabase | E-mail (par défaut), Google, Apple, Microsoft, téléphone, SAML SSO, Sign in with Lovable |
| Replit | Replit Auth (comptes Replit), ou Clerk Auth (vos propres comptes) | E-mail, Google, GitHub, Apple, X |
| Bolt | La base de données intégrée de Bolt | E-mail, Google |
| Base44 | La connexion intégrée de Base44 | E-mail et mot de passe avec un code envoyé par e-mail, Google, Microsoft, Facebook, SSO d’entreprise |
| v0 | Généralement Supabase, parfois Clerk | E-mail et mot de passe, codes, liens magiques, Google et autres |
| Antigravity | Généralement Firebase Authentication | E-mail et mot de passe, liens par e-mail, Google et autres |
| Claude Code, Codex, Cursor | Ce que vous demandez | Généralement Supabase, Clerk, Firebase, Auth.js ou Better Auth |
Services de connexion utilisés par les agents de codage
Quand vous développez avec un agent de codage, il relie votre app à un service de connexion. Chacun envoie des e-mails différents, et chacun a un point qui les casse le plus souvent :
| Service de connexion | E-mails envoyés | Ce qui les casse le plus souvent |
|---|---|---|
| Supabase Auth | Confirmation, lien magique ou code, réinitialisation du mot de passe, invitation, changement d’e-mail | La Site URL, et l’expéditeur intégré, qui ne livre qu’à votre équipe Supabase, 2 par heure, tant que vous n’avez pas configuré un SMTP personnalisé |
| Clerk | Un code (ou lien) de vérification, des codes de connexion, des codes de réinitialisation du mot de passe | Le développement et la production sont séparés, avec des utilisateurs distincts ; la production nécessite les enregistrements DNS de votre propre domaine |
| Firebase Authentication | Lien de vérification, lien de réinitialisation du mot de passe, connexion par lien e-mail | Les utilisateurs peuvent se connecter avant d’avoir vérifié leur adresse, sauf si votre app le contrôle ; les liens doivent pointer vers un domaine autorisé |
| Auth.js | Liens magiques, via un fournisseur d’e-mails comme Resend | L’inscription par mot de passe n’inclut aucun e-mail : la vérification et les réinitialisations sont du code que vous ajoutez |
| Better Auth | Vérification, réinitialisation du mot de passe, et liens magiques ou codes via des plugins | Il appelle une fonction d’envoi que vous écrivez, donc rien ne part tant qu’elle n’est pas reliée à un fournisseur d’e-mails |