Ajouter des comptes utilisateurs à son application avec Supabase : le parcours débutant

Créer un compte, recevoir un lien et se connecter ne suffisent pas à protéger les dossiers. Voici comment préparer le parcours complet, de l’invitation à la déconnexion, avec deux utilisateurs fictifs et des résultats à vérifier.

Ajouter des comptes utilisateurs à une application consiste à résoudre deux questions : qui est la personne qui arrive, puis à quelles informations a-t-elle accès ? Supabase propose un service d’authentification pour la première question. Les règles de votre application et de sa base doivent répondre à la seconde.

Nous allons préparer le parcours d’un petit espace de dossiers, avec deux utilisateurs fictifs : Alice et Bilal. Chacun doit retrouver uniquement ses propres dossiers. L’exemple reste volontairement plus simple qu’un SaaS avec plusieurs entreprises et plusieurs rôles. Ce guide donne un plan de construction et une recette à exécuter ; il ne certifie pas une intégration que nous n’avons pas inspectée.

Décider qui peut créer un compte

Votre application est-elle ouverte à toute personne disposant d’une adresse électronique, ou réservée à des invités ? Cette décision doit être explicite. Un bouton de connexion peut, selon la configuration, entraîner la création d’un utilisateur qui n’existait pas encore. Ne vous fiez pas au seul texte affiché sur le bouton.

Pour notre espace fictif, seuls les invités peuvent consulter un dossier. Alice reçoit une invitation ; Bilal reçoit la sienne. Une troisième personne peut arriver sur la page, mais elle ne doit pas obtenir un accès simplement en saisissant une adresse. Il faut relier l’identité confirmée à l’autorisation prévue, sans laisser le navigateur décider qui est invité.

Rédigez aussi le cas d’une adresse erronée. La personne doit pouvoir corriger sa saisie. Le message affiché ne devrait pas révéler inutilement quels comptes existent déjà. Une formulation sobre, accompagnée d’un moyen de réessayer, réduit la confusion sans transformer la page de connexion en annuaire des utilisateurs.

Choisir un mode de connexion compréhensible

Un mot de passe impose un parcours de création et de récupération. Un lien de connexion envoyé par courriel évite d’en mémoriser un, mais suppose que le message arrive et que son ouverture soit correctement traitée. Un code à saisir est une autre option. Le choix dépend du public, du contexte et des exigences de votre application.

La documentation Supabase sur les liens et codes de connexion décrit les méthodes sans mot de passe, leurs paramètres et la création automatique d’utilisateurs. Pour notre exemple, retenons un lien envoyé à l’adresse autorisée. Son utilisation, son expiration et les nouvelles tentatives devront apparaître dans les essais.

Évitez de cumuler dès le départ mot de passe, plusieurs connexions sociales et lien magique. Chaque méthode ajoute des situations à comprendre : deux identités qui correspondent à la même personne, une adresse différente de celle invitée ou une session ouverte dans un autre navigateur. Commencez par un parcours cohérent et observable.

Pour comprendre · illustration du guide

Préparer les adresses de retour avant l’envoi du premier lien

Après confirmation, l’utilisateur doit revenir vers une page prévue de votre application. L’adresse de développement et le domaine public ne sont pas les mêmes. Un lien qui renvoie sur l’ordinateur du créateur est inutilisable pour un client. Supabase documente les adresses de redirection autorisées et l’URL principale du site.

Préparez séparément le parcours local, l’environnement d’essai et la production. Autorisez seulement les destinations nécessaires, avec une configuration adaptée à chacun. Ne corrigez pas un problème de redirection en acceptant indistinctement n’importe quelle adresse de retour. Demandez à l’assistant d’expliquer la liste qu’il propose.

Dans notre recette, Alice ouvre le lien depuis un courriel sur son téléphone ; Bilal l’ouvre dans son navigateur habituel. Le traitement doit correspondre au flux choisi, notamment lorsque le lien est ouvert ailleurs que dans l’onglet initial. Notez les conditions réellement prises en charge au lieu de supposer qu’un essai sur votre ordinateur couvre tous les appareils.

Relier chaque dossier à un propriétaire

Les dossiers de notre exemple possèdent une référence et l’identifiant de leur propriétaire. Cet identifiant provient de l’identité authentifiée, pas d’une valeur librement modifiable dans le formulaire. Sinon, une personne pourrait tenter d’attribuer une création ou une lecture à quelqu’un d’autre.

Dans Supabase, les politiques de sécurité au niveau des lignes, souvent appelées RLS, permettent de conditionner les opérations sur les données. La documentation officielle RLS explique leur rôle. Activez et vérifiez les protections adaptées aux tables exposées ; l’authentification seule ne les remplace pas.

Faites écrire la règle en français avant son implémentation : « Une personne connectée peut lire ses dossiers et créer un dossier pour elle-même ; elle ne peut ni lire ni modifier ceux d’un autre utilisateur. » Cette formulation doit ensuite être vérifiée pour chaque opération autorisée, y compris les accès directs au service de données.

Prévoir les écrans entre la connexion et le travail

Le parcours comprend plus que deux formulaires. Il faut un état « message envoyé », un lien expiré, un renvoi possible, une arrivée sans dossier et une session qui doit être renouvelée. Dans chaque cas, l’utilisateur doit savoir s’il peut continuer et quelle action effectuer.

Pour Alice, la première arrivée sans dossier propose « Créer mon premier dossier » avec une explication courte. Bilal, lui, retrouve un dossier d’essai qui lui a été attribué. Aucun des deux ne voit les exemples de l’autre. Les données de démonstration, si elles existent, doivent être identifiées et séparées des données privées.

En cas de session expirée pendant une saisie, décidez ce qui reste conservé et où. Ne promettez pas qu’un brouillon a été enregistré si vous ne l’avez pas vérifié. Si vous conservez une copie locale, tenez compte des appareils partagés et du changement de compte. Le confort de reprise ne doit pas exposer le texte du précédent utilisateur.

Protéger les accès techniques nécessaires à la construction

Les clés destinées au navigateur et les secrets privilégiés n’ont pas le même rôle. Une clé de service capable de contourner des contrôles ne doit pas être livrée à l’utilisateur. Demandez où sont stockés les secrets, quelle opération en a besoin et pourquoi. Une correction de droits ne devrait jamais consister à donner un accès administratif au navigateur.

Si votre application utilise un serveur pour gérer la session, suivez les recommandations correspondant à son environnement. La documentation Supabase pour les applications rendues côté serveur distingue les clients et les usages. Faire fonctionner la connexion sur une page ne prouve pas que toutes les opérations serveur vérifient correctement l’utilisateur.

Avant d’inviter un public réel, vérifiez également l’envoi des courriels : configuration du service d’envoi, domaine, limites et arrivée effective chez les destinataires. Les possibilités d’un environnement de test ne suffisent pas à dimensionner le parcours de production. Notez un contact de support utilisable lorsqu’un lien n’arrive pas.

Exécuter la recette avec deux vrais comptes d’essai autorisés

Créez uniquement des comptes dont vous contrôlez les adresses. Préparez un dossier A pour Alice et un dossier B pour Bilal. Utilisez deux sessions séparées pour éviter de confondre les identités. Conservez les références des dossiers afin de vérifier aussi les accès directs, pas seulement les cartes affichées dans la liste.

• Alice suit son invitation : elle arrive au bon domaine et retrouve son espace.
• Un lien expiré est ouvert : aucune session nouvelle n’est accordée ; une marche à suivre est proposée.
• Alice recharge puis revient plus tard : l’état de connexion correspond à la politique de session choisie.
• Alice demande le dossier B : son contenu est refusé, même en utilisant sa référence exacte.
• Bilal tente de modifier le propriétaire de son dossier : la règle d’accès bloque l’opération interdite.
• Alice se déconnecte puis Bilal se connecte sur le même appareil : aucune donnée privée d’Alice ne reste affichée.

Ces essais doivent être rejoués après une modification des droits ou de la connexion. Notez les résultats obtenus et l’environnement concerné. Une réussite dans une copie locale ne prouve pas que la base de production possède les mêmes politiques, les mêmes adresses de retour ou la même configuration de courriel.

Traiter le départ d’un utilisateur

Définissez ce que signifie retirer un accès : désactiver une invitation, retirer un rôle, fermer un compte ou supprimer ses données sont des opérations différentes. Une personne qui quitte l’équipe peut encore posséder une session ouverte. Vérifiez comment les autorisations sont réévaluées et quel délai de retrait vous pouvez réellement tenir.

Pour notre espace individuel, prévoyez un export autorisé du travail et une décision sur sa conservation. Si vous ajoutez ensuite des équipes, la propriété des dossiers peut appartenir à une organisation plutôt qu’à une seule personne. Le guide des espaces d’entreprise SaaS traite ce modèle plus complexe sans le mélanger à la première connexion.

La fiche Supabase : comptes, accès et recette rassemble les décisions et les cas Alice/Bilal. Vous pouvez l’utiliser comme brief dans Maestro ou avec votre équipe. Demandez d’abord le parcours complet de connexion, puis la démonstration des refus d’accès. Les deux sont nécessaires avant de confier des dossiers réels à l’application.