Introduction
Votre première version prend forme : les pages existent, le parcours principal fonctionne. Reste une question que tout fondateur rencontre tôt ou tard : comment vos utilisateurs vont-ils se connecter ? Mot de passe classique, lien reçu par e-mail, code à six chiffres, bouton « Continuer avec Google » ? Le choix paraît technique, mais il pèse sur votre taux d'inscription, votre charge de support et la sécurité de vos données.
Bonne nouvelle : pour un MVP, vous n'avez pas besoin de tout proposer. Ce guide compare les trois options les plus courantes, explique les pièges qui surprennent la plupart des débutants (notamment l'envoi des e-mails de connexion) et vous donne une règle simple pour choisir.
Les points techniques cités viennent de la documentation officielle de Supabase, une base de données avec authentification très utilisée dans les projets créés avec l'IA ou le no-code. Les recommandations pratiques sont notre analyse, à adapter à votre projet.
Pourquoi la connexion mérite une vraie décision
Dans une application, deux questions se posent toujours. La première : qui est cette personne ? C'est l'authentification. La seconde : a-t-elle le droit de voir cette donnée ? C'est l'autorisation. La documentation de Supabase distingue précisément les deux : l'authentification vérifie l'identité, l'autorisation détermine à quelles ressources l'utilisateur a accès.
Les deux sont liées : le jeton remis à l'utilisateur après sa connexion sert ensuite à limiter l'accès aux données ligne par ligne, grâce aux règles d'accès de la base (les « Row Level Security »). Choisir un mode de connexion ne se résume donc pas à une question d'ergonomie : c'est la porte d'entrée de toute la protection de vos données. Pour la partie règles d'accès, voyez notre guide pour sécuriser une application créée avec l'IA.
Option 1 : l'e-mail et le mot de passe
C'est le mode que tout le monde connaît. L'utilisateur crée un compte avec une adresse e-mail et un mot de passe, puis s'en sert à chaque visite.
Ses avantages
- Les utilisateurs comprennent immédiatement le principe.
- La connexion est instantanée une fois le compte créé : aucun e-mail à attendre.
- Les assistants IA et les outils no-code savent tous le mettre en place.
Ses inconvénients
- Il faut prévoir la réinitialisation du mot de passe, qui passe elle aussi par un e-mail.
- Les mots de passe oubliés génèrent des demandes de support.
- Vous stockez, même indirectement, un secret que vos utilisateurs réutilisent peut-être ailleurs.
C'est un bon choix si vos utilisateurs reviennent souvent et si la connexion doit être rapide, par exemple pour un outil utilisé chaque jour.
Option 2 : le lien magique
L'utilisateur saisit son adresse e-mail, reçoit un message et clique sur un lien pour entrer. Aucun mot de passe à créer ni à retenir.
D'après la documentation de Supabase, ce lien :
- fonctionne uniquement avec une adresse e-mail et n'est utilisable qu'une seule fois ;
- expire par défaut au bout d'une heure ;
- peut être demandé au maximum une fois toutes les 60 secondes par adresse ;
- crée automatiquement un compte si l'adresse est inconnue, sauf si vous désactivez ce comportement.
Pour un MVP, c'est souvent le meilleur compromis : l'inscription tient en un seul champ, vous n'avez aucun mot de passe à protéger, et vous n'écrivez pas de parcours « mot de passe oublié ». Le revers : l'utilisateur doit ouvrir sa boîte mail à chaque connexion, ce qui pèse si l'application s'utilise plusieurs fois par jour.
Option 3 : le code à usage unique par e-mail
Variante du lien magique : au lieu d'un lien, l'e-mail contient un code à six chiffres que l'utilisateur recopie dans l'application. La documentation précise que les deux méthodes ne diffèrent que par le contenu de l'e-mail : c'est le même mécanisme technique, activé par défaut.
Le code a un avantage concret : il fonctionne même quand l'utilisateur lit son e-mail sur son téléphone et utilise votre application sur un ordinateur, là où un lien s'ouvrirait dans le mauvais navigateur. En contrepartie, la saisie du code ajoute une étape.
Et la connexion avec Google ou un autre compte ?
Supabase prend en charge une vingtaine de fournisseurs de connexion sociale, d'Apple à Zoom. Le bouton « Continuer avec Google » réduit la friction pour l'utilisateur et évite l'e-mail de confirmation.
Pour un MVP, nous le déconseillons au départ, pour deux raisons : la configuration chez le fournisseur ajoute du travail avant d'avoir validé votre idée, et elle reste dispersée entre plusieurs consoles. Vous pouvez toujours l'ajouter une fois que des utilisateurs réels vous le demandent. Le même raisonnement s'applique à la connexion d'entreprise (SSO) et à la connexion par téléphone, qui supposent un service tiers.
Le piège que presque tout le monde découvre trop tard : l'envoi des e-mails
Les options 1, 2 et 3 reposent toutes sur l'envoi d'e-mails : confirmation d'inscription, lien magique, code, mot de passe oublié. Or le service d'envoi fourni par défaut par Supabase n'est pas conçu pour la production. Sa documentation indique :
- seules les adresses appartenant à l'équipe de votre organisation peuvent recevoir des messages ; les autres échouent avec l'erreur « Email address not authorized » ;
- le volume est limité à 2 messages par heure, une valeur susceptible de changer sans préavis ;
- aucune garantie de livraison ni de disponibilité n'est donnée.
Concrètement : tout fonctionne quand vous testez seul, puis vos premiers vrais utilisateurs ne reçoivent rien. C'est l'un des pièges les plus fréquents au lancement.
La solution : configurer votre propre serveur d'envoi (SMTP) auprès d'un service d'e-mails transactionnels avant d'inviter qui que ce soit. La documentation précise qu'avec un SMTP personnalisé, les messages peuvent atteindre n'importe quelle adresse et que la limite par défaut passe à 30 messages par heure, réglable ensuite dans les paramètres.
Comment choisir : une règle simple
Posez-vous deux questions :
1. À quelle fréquence vos utilisateurs reviennent-ils ? Plusieurs fois par jour : privilégiez le mot de passe. Une fois par semaine ou moins : le lien magique convient très bien. 2. Avez-vous déjà configuré l'envoi d'e-mails ? Si non, faites-le en premier, quel que soit le mode choisi.
Dans le doute pour une première version : le lien magique, avec un serveur d'envoi configuré. Vous gagnez du temps de construction, vous évitez de gérer des mots de passe et vous pourrez ajouter d'autres méthodes plus tard. Pour la méthode complète de construction, voyez notre guide sur la création d'un MVP avec l'IA et celui sur les outils no-code pour un MVP.
Checklist avant d'ouvrir l'accès à vos premiers utilisateurs
- Testez la connexion avec une adresse e-mail qui n'est pas la vôtre, ni celle de votre équipe.
- Vérifiez que l'e-mail arrive bien (et pas dans les courriers indésirables) avec un vrai serveur d'envoi.
- Contrôlez que le lien ou le code expire et ne peut pas être réutilisé.
- Testez ce qui se passe quand l'utilisateur redemande un lien en moins de 60 secondes : un message clair vaut mieux qu'une erreur.
- Vérifiez avec deux comptes différents que chacun ne voit que ses propres données.
Questions fréquentes
Un utilisateur peut-il se connecter sans créer de compte ?
Avec un lien magique ou un code, le compte est créé automatiquement à la première connexion si l'adresse est inconnue. L'utilisateur n'a donc pas de formulaire d'inscription séparé à remplir.
Faut-il proposer plusieurs modes de connexion dès le départ ?
Non. Chaque mode ajouté est un parcours de plus à tester et à maintenir. Commencez par un seul, observez ce que demandent vos premiers utilisateurs, puis élargissez.
Mon assistant IA peut-il mettre cela en place à ma place ?
Il peut écrire le code de connexion, mais il ne configurera pas toujours l'envoi des e-mails ni les règles d'accès aux données. Demandez-lui explicitement ces deux points, puis vérifiez par vos propres tests, comme dans la checklist ci-dessus.
Pourquoi mes e-mails de connexion n'arrivent-ils pas ?
La cause la plus fréquente est le service d'envoi par défaut : il est limité à l'équipe du projet et à un très faible volume. Configurez un serveur d'envoi personnalisé.
Sources
- Supabase, « Auth » : https://supabase.com/docs/guides/auth
- Supabase, « Passwordless email logins » : https://supabase.com/docs/guides/auth/auth-email-passwordless
- Supabase, « Send emails with custom SMTP » : https://supabase.com/docs/guides/auth/auth-smtp
Questions fréquentes
Un utilisateur peut-il se connecter sans créer de compte ?
Avec un lien magique ou un code, le compte est créé automatiquement à la première connexion si l'adresse est inconnue : pas de formulaire d'inscription séparé.
Faut-il proposer plusieurs modes de connexion dès le départ ?
Non. Chaque mode ajouté est un parcours de plus à tester et à maintenir. Commencez par un seul, puis élargissez selon les demandes de vos premiers utilisateurs.
Mon assistant IA peut-il mettre cela en place à ma place ?
Il peut écrire le code de connexion, mais pas toujours configurer l'envoi des e-mails ni les règles d'accès aux données. Demandez-lui explicitement ces deux points, puis vérifiez par vos propres tests.
Pourquoi mes e-mails de connexion n'arrivent-ils pas ?
La cause la plus fréquente est le service d'envoi par défaut, limité à l'équipe du projet et à un très faible volume. Configurez un serveur d'envoi personnalisé.
Prochaine étape
Construire votre première version avec les bons réflexes ?
Avec StartupWeek, vous créez la première version testable de votre application avec l'IA et le No-Code, en intégrant dès le départ les choix qui comptent.
