Base de données : tes données partout

La pièce manquante

Les élèves de Tom se connectent maintenant avec leur e-mail — mais Lina, fidèle au poste, signale que ses habitudes du CDI ne sont toujours pas sur son téléphone. Normal : l'authentification dit qui est là, mais les données, elles, vivent encore dans le localStorage de chaque appareil. Il manque un lieu central où ranger les habitudes de chaque compte : une base de données en ligne. C'est le chantier de ce chapitre, et c'est probablement le plus transformateur du cours — après lui, ton app cesse d'être un gadget de navigateur pour devenir un vrai service.

Le changement de logique tient en une phrase : au lieu que chaque navigateur garde sa propre copie des données, tous les appareils lisent et écrivent au même endroit, un serveur de base de données. Ton app devient un guichet : elle affiche ce que dit la base, et elle y enregistre chaque action. Lina coche « Lecture » sur son téléphone ; la coche part dans la base ; le lendemain au CDI, l'app demande à la base « montre-moi les habitudes de Lina » et tout est là.

Une base de données, concrètement

Si tu as déjà ouvert un tableur, tu connais 80 % du concept. Une base de données est un ensemble de tables ; chaque table ressemble à une feuille de calcul avec des colonnes (les types d'informations) et des lignes (les enregistrements). Chaque ligne possède un identifiant unique (id), et — c'est la partie magique — une ligne peut pointer vers une autre : la colonne user_id d'une habitude dit « cette habitude appartient à cet utilisateur ». C'est ce qu'on appelle une relation, et c'est elle qui relie proprement les données aux comptes du chapitre 6.

Le modèle de Tom est minimaliste : une table habits (une ligne par habitude, avec son nom et le user_id de son propriétaire) et une table checks (une ligne par jour coché, reliée à son habitude). Deux tables, quatre colonnes utiles chacune — résiste à la tentation d'en prévoir dix « pour plus tard ». Tu n'as pas besoin d'écrire ce qui suit toi-même, mais sache le lire : c'est le langage SQL que l'IA générera pour créer les tables.

create table habits (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users not null,
  name text not null,
  created_at timestamptz default now()
);

create table checks (
  id uuid primary key default gen_random_uuid(),
  habit_id uuid references habits not null,
  day date not null
);

Lis-le comme du presque-français : « crée une table habits ; chaque ligne a un id unique, appartient à un utilisateur, porte un nom, et garde sa date de création ». La ligne references auth.users est la relation : impossible de créer une habitude orpheline, sans propriétaire. Demande toujours à l'IA de t'expliquer le schéma qu'elle propose — c'est dans ces lectures commentées que tu apprends le plus.

flowchart LR
  T["Téléphone de Lina"] -->|"Coche une habitude"| B["Base de données Supabase"]
  O["Ordinateur du CDI"] -->|"Même compte"| B
  B -->|"Renvoie les mêmes données"| T
  B -->|"Renvoie les mêmes données"| O

La sécurité d’abord : chacun voit ses données

Question cruciale avant d'écrire la moindre donnée : qu'est-ce qui empêche l'app de Lina de lire les habitudes de Karim ? Réponse : rien, par défaut. C'est à toi de l'exiger, via ce que Supabase appelle la Row Level Security (RLS) — la « sécurité au niveau des lignes ». Le principe est limpide : chaque table reçoit une règle du type « un utilisateur ne peut lire et modifier que les lignes dont le user_id est le sien ». La base elle-même refuse tout le reste, quoi que fasse le code de l'app.

Migrer sans rien perdre

Tes utilisateurs existants ont des données dans leur localStorage : les jeter serait leur faire payer ta montée en gamme. Le plan de migration est classique et élégant : à la première connexion d'un utilisateur, l'app regarde s'il reste des données locales, et lui propose de les importer dans son compte. Après import réussi, le localStorage est nettoyé, et la base devient l'unique source de vérité. Voici le prompt complet de Tom — remarque qu'il découpe lui-même le chantier en étapes :

Fais évoluer mon app de suivi d'habitudes du localStorage vers Supabase.
Contexte : l'authentification par lien magique fonctionne déjà (chapitre précédent).
Étapes que je veux, dans cet ordre :
1. crée les tables habits et checks, liées à l'utilisateur connecté via user_id
2. active la Row Level Security avec une règle par table : chaque utilisateur ne lit et ne modifie que ses propres lignes
3. fais lire et écrire l'app dans la base au lieu du localStorage : ajout, suppression, cochage, calcul du streak
4. à la première connexion d'un utilisateur qui a encore des données locales, propose-lui de les importer dans son compte, puis nettoie le localStorage
Fais UNE étape à la fois et attends que je confirme mon test avant de passer à la suivante.
À chaque étape, explique-moi en deux phrases ce que tu as fait.

Ce prompt condense tout ce que tu as appris : la vision complète annoncée d'emblée (chapitre 3), le découpage en étapes testables (chapitre 4), la sécurité exigée explicitement, et la demande d'explication qui transforme chaque étape en leçon. Quand l'IA aura fini l'étape 1, va voir tes tables dans le tableau de bord Supabase (onglet « Table Editor ») : voir tes données « en vrai », dans l'interface du service, rend tout le concept concret.

Tester la persistance pour de vrai

La migration touche au cœur de ton app : le test doit être à la hauteur. Ne te contente pas de « ça a l'air de marcher » — déroule un scénario complet, avec plusieurs comptes et plusieurs appareils. Voici la checklist de Tom :

• Persistance : coche une habitude, recharge la page, ferme le navigateur, reviens — la coche est toujours là.
• Multi-appareils : coche sur ton téléphone, recharge sur l'ordinateur — la coche apparaît.
• Isolation : crée deux comptes de test, ajoute des habitudes différentes dans chacun, et vérifie qu'aucun ne voit les données de l'autre.
• Migration : sur un navigateur qui a d'anciennes données locales, connecte-toi et vérifie que l'import est proposé, puis que tout est arrivé dans le compte.
• Déconnexion : déconnecté, l'app ne doit afficher aucune donnée.

Pour le test d'isolation — le plus important — fais-toi aider activement. L'IA est excellente pour générer des scénarios de test plus malins que les tiens :

J'ai créé deux comptes de test : eleve1@test.fr et eleve2@test.fr.
Donne-moi un scénario de test pas à pas pour vérifier que :
- chaque compte ne voit que ses propres habitudes et coches
- une coche faite sur un appareil apparaît sur un autre appareil du même compte après rechargement
- un utilisateur déconnecté ne voit aucune donnée
Explique-moi ensuite comment vérifier directement dans le tableau de bord Supabase que chaque ligne de habits porte le bon user_id, et comment tester que la Row Level Security bloque vraiment un accès croisé.

Latence et états de chargement

Un changement subtil accompagne la migration : tes données ne sont plus instantanées. Avec localStorage, tout était sur place ; avec une base en ligne, chaque lecture et chaque écriture fait un aller-retour réseau de quelques dizaines ou centaines de millisecondes. La plupart du temps, c'est imperceptible — mais sur une connexion lente, une liste qui met une seconde à s'afficher sans aucun indicateur donne l'impression d'une app cassée. Demande à l'IA d'ajouter des états de chargement (« un petit indicateur pendant que les habitudes se chargent ») et un message clair si le réseau échoue (« impossible de joindre le serveur, réessaie »).

C'est aussi le moment d'apprendre un réflexe de pro : tester ton app en simulant un mauvais réseau. Dans les outils de développement du navigateur (F12), l'onglet « Network » permet de brider la connexion (« Slow 3G »). Trente secondes de test dans ces conditions te montrent exactement ce que vivront tes utilisateurs les moins bien connectés — et ce qu'il faut améliorer.

Ce que Tom vient de gagner

Mesure le chemin : l'app de Tom a maintenant des comptes, des données centralisées, sécurisées ligne par ligne, et synchronisées entre tous les appareils. Lina coche au CDI, vérifie son streak dans le bus, et tout est cohérent. Mais il y a un gain plus discret : Tom dispose désormais d'un vrai backend. Toutes les fonctionnalités « impossibles » d'avant — envoyer des e-mails, accepter un paiement, brancher de l'IA — deviennent accessibles, car elles ont enfin un endroit où s'appuyer. C'est exactement le programme du prochain chapitre.