La promesse qu'on avait faite
À l'article 5, j'avais mentionné Supabase en passant. Une promesse glissée entre deux paragraphes : "on y reviendra". Et à l'article 6, on avait construit un générateur de citations. Il fonctionnait. Il était beau. Et à chaque rafraîchissement de page, la citation s'évaporait.
Pas de bug. Pas d'erreur. Juste l'absence d'un endroit où la donnée pouvait vivre entre deux visites.
C'est le moment où on comprend, concrètement, ce que "backend" veut dire. On a parfois un peu l'impression à écouter des devs que c'est le coté obscur de la force, celui dont on ne revient pas indemne. Ce n'est pas un concept technique abstrait. C'est la réponse à une question très simple : où est-ce que ça habite, quand je ferme la fenêtre ?
Cet article tient la promesse de l'article 5. On ouvre Supabase. On fait le tour. On ne construit rien encore.
Créer le compte
Je vais être honnête : j'ai passé plus de temps à choisir le nom de mon projet qu'à créer le compte lui-même.
Supabase.com, "Start your project", un email, un mot de passe. Deux minutes, peut-être trois si on hésite sur le nom. Mon premier projet s'appelle "citations-generator" parce que j'avais décidé d'être pragmatique ce jour-là.
C'est tout. On est dedans.
Ce qu'on voit en premier
La première fois que j'ai ouvert la console Supabase, j'ai eu le réflexe qu'on a tous quand on arrive dans un outil que l'on ne connait pas : regarder le menu de gauche.
C'est là que tout se passe. Un panneau de navigation vertical, une liste d'onglets avec des icônes. Table Editor. Authentication. Edge Functions. Storage. Secrets. Quelques autres que je mettrai de côté pour l'instant.
Mon premier sentiment : c'est rangé. Pas surchargé. Pas intimidant comme un terminal vide, pas fouillis comme certains dashboards qu'on accumule au fil des intégrations. Quelqu'un a fait des choix.
Mon deuxième sentiment, quelques secondes après : je reconnais les problèmes que ces onglets sont censés résoudre. La base de données. Les utilisateurs. Le code distant. Les fichiers. Les clés secrètes. Cinq catégories de problèmes que j'avais déjà croisés, séparément, dans d'autres vies.
On va les parcourir dans l'ordre où ils vont nous être utiles.
Database : l'endroit où les données ne disparaissent plus
C'est le premier onglet qui m'a arrêtée. Table Editor.
J'ai cliqué dessus, et j'ai vu une interface qui ressemble à un tableur vide. Des colonnes, des lignes, un bouton "New table". Rien encore, parce qu'on n'a rien créé. Mais l'espace existe.
C'est exactement ce qui manquait à notre générateur de citations. La citation qu'on avait tapée vivait dans la mémoire de la page, celle qu'on appelle "état" dans le jargon des développeurs. Une mémoire courte, qui s'efface dès qu'on part. Il n'y avait pas de table, pas d'endroit persistant, pas de tiroir où ranger la donnée pour la retrouver plus tard.
Dans l'article suivant, on va créer cette table. On va lui donner des colonnes : un identifiant, le texte de la citation, l'auteur, la date d'ajout. Et à partir de là, les citations ne disparaîtront plus.
Pour l'instant, on regarde juste. On sait que c'est ici que ça se passera. Patience et longueur de temps font plus que force ni que rage. Ce n'est pas de moi, c'est le rat au lion. Bref, je m'égare, revenons à notre mouton.
Le Table Editor de Supabase ressemble à Airtable, mais il est construit sur "PostgreSQL", une base de données relationnelle très répandue. Je ne vais pas creuser ça maintenant, et ce n'est pas nécessaire pour la suite. Ce qu'il faut retenir : c'est robuste, c'est standard, et beaucoup d'outils savent lui parler. et c'est déja pas mal !
Authentication : les deux gestes qu'on avait décortiqués
À l'article 9, on avait découpé le mot "auth" en deux gestes distincts. Authentification : vérifier que tu es bien toi. Autorisation : vérifier ce que tu as le droit de faire.
J'avais pris le temps de cette distinction parce qu'elle compte vraiment dès qu'on commence à construire quelque chose que d'autres personnes vont utiliser. Et parce que pendant longtemps, dans mes bricolages no-code, je les avais confondus.
L'onglet Authentication de Supabase gère les deux. Côté authentification : les utilisateurs qui s'inscrivent, leurs adresses email, leurs sessions actives, les providers qu'on peut activer (connexion par email, par Google, par GitHub, selon ce qu'on veut proposer). Côté autorisation : des règles qui définissent qui peut lire quoi, écrire quoi, modifier quoi.
Je n'ai rien configuré lors de cette première visite. J'ai juste ouvert l'onglet et regardé. Il y avait déjà une section "Users" vide, une section "Providers" avec quelques options désactivées, une section "Policies" que je savais ne pas toucher tout de suite.
Gérer l'authentification soi-même, il y a quelques années, c'était un projet à part entière. On externalisait ça à un prestataire spécialisé, ou on passait des semaines à le construire. Là, c'est un onglet. Il n'est pas encore configuré, mais il existe, il est prêt, et quand on en aura besoin, on saura où aller.
Edge Functions, Storage, Secrets : les trois autres tiroirs
Edge Functions : du code qui tourne ailleurs
Celui-là, je l'ai ouvert avec curiosité parce que le nom ne m'évoquait rien la première fois.
Edge Functions, c'est du code qui tourne sur les serveurs de Supabase, pas sur l'ordinateur du lecteur, pas dans le générateur qu'on a construit. On écrit une fonction, on la déploie, et elle s'exécute quelque part dans le cloud quand on l'appelle. C'est utile pour des opérations qu'on ne veut pas exposer "côté client" (c'est à dire visible lorsque l'utilisateur clique sur inspecter dans le navigateur) : envoyer un email, appeler une API tierce avec une clé secrète, déclencher un traitement lourd.
Je n'en ai pas eu besoin pour les premiers projets qu'on construit dans cette série. Mais j'ai noté l'onglet. Il y aura un moment où on voudra faire quelque chose que le générateur seul ne peut pas faire, et ce sera là.
Storage : pour ce qui ne tient pas dans une table
Storage, c'est pour les fichiers. Photos, PDF, exports, images de profil. Tout ce qui est trop lourd ou trop binaire pour tenir dans une colonne de table. C'est comme un drive un peu organisé en "buckets" (l'équivalent des répertoires sur un drive).
Dans notre générateur de citations, on n'en a pas besoin. Mais si demain on voulait que chaque citation soit accompagnée d'une photo de l'auteur, ou qu'on puisse exporter un PDF de sa collection, c'est ici que ça vivrait.
J'ai ouvert l'onglet, j'ai vu une interface qui ressemble à un explorateur de fichiers vide. c'est comme un drive, où les dossiers s'appellent "buckets". Rien à faire pour l'instant. J'ai refermé.
Secrets : les clés qu'on ne met pas dans le code
Celui-là, je l'ai compris immédiatement, parce que j'avais fait l'erreur inverse.
Dans mes premiers bricolages avec les APIs, j'écrivais les clés d'accès directement dans le code. La clé de l'API météo, la clé de l'API d'envoi d'emails, le mot de passe de la base de données. Pratique, jusqu'au jour où on partage le code avec quelqu'un, sans faire attention.
L'onglet Secrets, c'est l'endroit prévu pour ranger ces clés. On les entre une fois, elles sont chiffrées, et dans le code on y fait référence par un nom, pas par la valeur. La clé ne voyage plus dans le code. Elle reste dans le coffre. ça evite que n'importe qui puisse utiliser son compte gmail par exemple !
C'est une bonne habitude à prendre dès le début. On y reviendra quand on connectera notre générateur à des services externes.
Un compte, cinq problèmes résolus
Quand j'ai commencé à bricoler sérieusement, à l'époque d'Airtable et de Zapier, monter une stack complète pour une petite application demandait de l'assemblage. Une base de données chez un fournisseur, l'authentification chez un autre, le stockage de fichiers chez un troisième, les fonctions serverless chez un quatrième, la gestion des secrets dans un fichier qu'on espérait ne jamais partager par erreur.
Cinq fournisseurs. Cinq documentations à lire. Cinq comptes à créer, cinq factures à surveiller, cinq points où quelque chose pouvait casser ou changer ses conditions tarifaires sans prévenir. Et cinq intégrations à maintenir entre eux.
Ce n'est pas une critique de cette époque. C'était la réalité du métier, et les gens qui montaient ces stacks savaient ce qu'ils faisaient. Mais pour quelqu'un qui construit seule, qui n'a pas une équipe technique derrière elle, c'était une barrière réelle.
Supabase, c'est ces cinq problèmes dans une seule console. Un compte. Une ligne de facturation. Une documentation. Un endroit où regarder quand quelque chose ne fonctionne pas.
A oui et c'est gratuit jusqu'à un certain volume de trafic, de ressources utilisées, parfait pour commencer.
Je ne dis pas que c'est parfait, ni que ça couvre tous les cas. Pour des projets très spécifiques, il y aura des raisons de choisir des outils dédiés. Mais pour démarrer, pour construire un premier produit fonctionnel, pour ne pas passer ses journées à câbler des fournisseurs entre eux, c'est exactement ce dont on a besoin.
On a fait le tour. On sait ce que contient la boîte.
À l'article suivant, on ouvre le premier tiroir et on crée notre première table. La citation qui disparaissait va enfin avoir un endroit où vivre.