Comptes utilisateurs & connexion

Le message qui change tout

Une semaine après la mise en ligne, Tom reçoit le retour qui revient le plus souvent. Lina, une élève de 5e, lui écrit : « Monsieur, j'ai coché toutes mes habitudes sur l'ordi du CDI, et le soir sur mon téléphone, tout avait disparu ! » Tom comprend immédiatement : il avait choisi le stockage local au chapitre 3, et localStorage garde les données dans le navigateur de chaque appareil. L'ordinateur du CDI et le téléphone de Lina sont deux mondes séparés qui ne se parlent pas. Pour que l'app suive Lina partout, elle doit pouvoir la reconnaître — et reconnaître quelqu'un, sur le web, ça s'appelle un compte utilisateur.

Souviens-toi : au chapitre 3, « compte utilisateur » figurait dans la liste des mots pièges à bannir de ta v1. Ce n'était pas une interdiction définitive, c'était une question de timing. Tom a d'abord construit, déployé, et recueilli des retours réels. Maintenant, le besoin n'est plus une hypothèse : c'est la demande numéro un de ses utilisateurs. C'est exactement le bon ordre — la complexité se justifie par un besoin prouvé, jamais par un « au cas où ». Tu vas voir que cette complexité, bien abordée, est tout à fait à ta portée.

Authentification : ce qui se passe vraiment

Trois mots de vocabulaire vont transformer tes dialogues avec l'IA sur ce sujet. L'authentification, c'est prouver qui tu es (« je suis bien lina@college.fr »). La session, c'est rester reconnu pendant un moment sans devoir le prouver à chaque clic — c'est elle qui fait que tu n'as pas à te reconnecter toutes les trente secondes. L'autorisation, c'est ce que tu as le droit de voir ou de faire une fois reconnu (« Lina voit SES habitudes, pas celles des autres »). Quand tu utiliseras ces mots dans tes prompts, l'IA saura exactement de quoi tu parles.

Derrière un simple écran de connexion se cache en réalité tout un système : l'inscription, la connexion, la déconnexion, la récupération en cas d'oubli, la protection contre les robots, le stockage sécurisé des identifiants… Construire tout ça soi-même est long, et surtout dangereux : la moindre erreur expose les données de tes utilisateurs. La bonne nouvelle, c'est que personne ne le construit soi-même aujourd'hui — pas même les professionnels. Tout le monde s'appuie sur des services spécialisés qui ont résolu le problème une fois pour toutes.

Les services d’authentification prêts à l’emploi

Ces services s'appellent parfois des BaaS (Backend as a Service) : ils fournissent à ton app les briques serveur dont elle a besoin — dont l'authentification — sans que tu aies à gérer un serveur. Tu crées un compte chez eux, tu récupères deux clés, et ton app leur délègue tout le travail sensible. Trois noms reviennent partout, et l'IA les connaît par cœur :

Pour ce cours, on suivra Tom sur Supabase : son offre gratuite couvre largement une app de classe, et le fait d'avoir l'authentification et la base de données au même endroit simplifiera le chapitre 7. Mais retiens le principe plus que le nom — la méthode que tu vas apprendre s'applique à l'identique chez les concurrents.

Quelle méthode de connexion pour tes utilisateurs ?

Il existe trois grandes façons de se connecter, et le bon choix dépend entièrement de qui sont tes utilisateurs. Le mot de passe classique est universel mais pénible : les gens l'oublient, le réutilisent partout, et il faut gérer la récupération. La connexion via Google ou Apple (« OAuth ») est confortable… à condition que tes utilisateurs aient un compte Google qu'ils utilisent vraiment. Le lien magique (magic link) supprime carrément le mot de passe : l'utilisateur entre son e-mail, reçoit un lien, clique, et le voilà connecté.

• Mot de passe : universel, mais oublis fréquents et gestion de récupération obligatoire.
• Connexion Google / Apple : un clic et c'est fait — si tes utilisateurs ont (et utilisent) ces comptes.
• Lien magique : rien à retenir, rien à oublier. Parfait pour des utilisateurs occasionnels ou jeunes. Seule exigence : accéder à sa boîte mail.

Tom choisit le lien magique : ses élèves ont tous une adresse fournie par le collège, et « mot de passe oublié » serait devenu sa deuxième vie. Pose-toi la même question pour ta propre app : quelle méthode crée le moins de friction pour TES utilisateurs ? Il n'y a pas de bonne réponse universelle, seulement une bonne réponse pour ton public.

sequenceDiagram
  participant E as Élève
  participant A as App de Tom
  participant S as Service Supabase
  E->>A: Saisit son adresse e-mail
  A->>S: Demande un lien magique
  S-->>E: Envoie l'e-mail avec le lien
  E->>A: Clique sur le lien reçu
  A-->>E: Session ouverte et habitudes affichées

Intégrer l’authentification avec l’IA

La démarche tient en trois temps : créer ton projet sur Supabase (un compte, un clic « New project »), récupérer tes deux clés d'accès, puis demander à l'IA de brancher tout ça. Comme pour le déploiement au chapitre 5, tu n'as pas à mémoriser la procédure — tu demandes un guidage pas à pas adapté à ton niveau. Voici le prompt complet de Tom :

Je veux ajouter des comptes utilisateurs à mon app de suivi d'habitudes.
Contexte : app HTML/CSS/JS déployée sur Vercel, données en localStorage pour l'instant.
Utilise Supabase Auth avec connexion par lien magique, sans mot de passe.
Ce que je veux :
1. un écran de connexion simple : champ e-mail + bouton « recevoir mon lien »
2. après clic sur le lien reçu par e-mail, l'utilisateur revient sur l'app, connecté
3. un bouton « se déconnecter » discret en haut de page
4. si l'utilisateur n'est pas connecté, il voit l'écran de connexion ; sinon, ses habitudes
IMPORTANT : ne touche pas encore aux données — on garde localStorage pour l'instant.
Guide-moi d'abord pour créer le projet Supabase et trouver mes deux clés, étape par étape, avant d'écrire le moindre code.

La ligne « ne touche pas encore aux données » est stratégique. Ajouter l'authentification ET migrer les données en même temps, c'est deux gros changements d'un coup — exactement ce que le chapitre 4 t'a appris à éviter. Ce chapitre branche la reconnaissance des utilisateurs ; le chapitre 7 s'occupera de leurs données. Une marche à la fois, même quand l'escalier est grand.

Les clés d’API : tes premiers secrets

En créant ton projet Supabase, tu vas rencontrer deux clés. La clé publique (dite « anon ») identifie ton app : elle peut vivre dans le code du navigateur, c'est prévu pour. La clé secrète (dite « service_role ») donne TOUS les droits sur ton projet : elle ne doit jamais, jamais apparaître dans du code visible par un navigateur. Ces secrets se rangent dans un fichier spécial, le .env, que Git ignore :

# Fichier .env — reste sur ta machine, jamais publié
SUPABASE_URL=https://tonprojet.supabase.co
SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIs...   # publique : OK côté navigateur
SUPABASE_SERVICE_ROLE_KEY=eyJzZXJ2aWNl...   # SECRÈTE : jamais côté navigateur

Tester le flux comme un utilisateur

L'authentification se teste de bout en bout, sans raccourci : entre une vraie adresse, va chercher l'e-mail (regarde aussi dans les spams, c'est le blocage classique), clique sur le lien, vérifie que tu arrives connecté. Puis déconnecte-toi et recommence. Enfin, le test décisif : ouvre l'app dans deux navigateurs différents avec deux adresses différentes, et vérifie que chacun a sa propre session. Si quelque chose coince, applique la méthode du chapitre 4 — rapport de bug en quatre points. Voici la version adaptée à l'authentification :

Bug de connexion à corriger.
Ce que je fais : j'entre mon adresse, je reçois l'e-mail du lien magique, je clique sur le lien.
Ce que j'attendais : revenir sur l'app, connecté.
Ce qui se passe : je reviens sur l'app mais je vois encore l'écran de connexion.
Erreur dans la console : [colle ici la ligne rouge exacte, s'il y en a une]
Vérifie en priorité la configuration des URL de redirection dans Supabase — l'URL de mon site déployé est https://mon-app.vercel.app — et dis-moi quoi corriger, étape par étape.

Ce prompt montre un réflexe de niveau supérieur : Tom oriente le diagnostic (« vérifie en priorité les URL de redirection ») parce que c'est LA cause classique de ce symptôme — le service renvoie l'utilisateur vers une adresse qui ne correspond pas au site déployé. Tu n'es pas obligé de connaître ces causes classiques : demande à l'IA « quelles sont les trois causes les plus fréquentes de ce problème ? » et elle te les listera.

Ce qui t’attend au prochain chapitre

À la fin de cette étape, l'app de Tom reconnaît chaque élève… mais leurs habitudes vivent encore dans le localStorage de chaque appareil. Lina peut se connecter au CDI et sur son téléphone, mais elle n'y voit pas encore les mêmes données. Il manque la seconde moitié de la solution : une base de données en ligne, où les habitudes de chaque compte seront stockées une bonne fois pour toutes, accessibles depuis n'importe où. C'est tout le programme du chapitre 7 — et tu as déjà posé la fondation idéale pour l'accueillir.