Construire les fondations de ton application

Tu as appris les outils un par un. Maintenant on assemble : une base de données, une interface admin, une page publique, un premier agent. En une session guidée avec Claude Code, tu poses les fondations de ton app.

Ce qu'on a devant soi

Ce blog a une page que tout le monde peut voir, une page d'accueil, des articles... Il a aussi un espace privé où j'écris mes articles, je gère mes agents, mes réglages, mes données. Et entre les deux, une base de données qui stocke tout ce qui fait tourner la machine. Trois couches. C'est le même schéma que Gmail, que Notion, que n'importe quelle app que tu utilises au quotidien. Une face publique, une face privée, un socle de données en dessous.

Ce qu'on va construire ici suit exactement ce patron. Pas parce que c'est élégant en théorie, mais parce que c'est le seul qui tient la route quand ton projet grandit. J'ai passé vingt ans à bricoler des outils dans Access, dans Excel, dans Airtable. Chaque fois que j'ai essayé de tout mettre dans une seule couche, j'ai fini par tout casser au bout de six mois.

Le skill base-builder va construire les fondations pour toi. Cet article, lui, raconte ce que chaque brique fait là, pourquoi elle est à cet endroit, et ce qui se passe dans ta base pendant que Claude travaille.

Pourquoi cette architecture et pas une autre

Une partie publique, une partie privée

Ouvre Gmail. Tu vois un écran de connexion. Tu tapes ton adresse, tu entres. Tu arrives dans ta boîte de réception. Personne d'autre ne voit tes mails. C'est le patron de base de presque toutes les apps. Une porte d'entrée visible par tout le monde. Derrière la porte, un espace qui ne montre que tes données à toi.

Screenshot manuel

Ce qu'on construit suit ce schéma. La page publique, c'est la vitrine de ton projet, ce que n'importe qui peut voir sans se connecter. L'interface admin, c'est ton cockpit personnel, là où tu gères tout. La base de données relie les deux, mais chaque côté ne voit que ce qu'il a le droit de voir.

La séparation n'est pas cosmétique. C'est une question de sécurité. Supabase gère ça avec ce qu'on appelle les Row Level Security policies, des règles qui filtrent les données ligne par ligne selon qui les demande. Concrètement : même si quelqu'un trouve l'adresse de ta base, il ne verra que les données que les règles l'autorisent à voir. Le videur vérifie ta carte à chaque requête, pas juste à l'entrée.

À l'échelle d'une personne seule

Quand j'ai construit mon premier outil interne en entreprise il y a une dizaine d'années, on avait une équipe tech pour gérer l'infrastructure. Ici, c'est toi toute seule. Et c'est justement pour ça que l'architecture doit être simple. Trois couches, cinq tables, un système d'authentification géré par Supabase. Pas de serveur à maintenir, pas d'infrastructure à surveiller la nuit. La complexité est absorbée par les outils. Toi, tu te concentres sur ce que ton app fait.

Les cinq tables que Claude va créer pour toi

profiles, ta fiche

Quand tu te connectes pour la première fois, l'app a besoin de savoir qui tu es. Pas ton mot de passe, Supabase gère ça. Ton nom, tes préférences, ta photo si tu en mets une. C'est la table profiles. Dans Pimpela, c'est cette table qui stocke le style déco de chaque utilisatrice et son niveau de bricolage. Sans elle, l'app traiterait tout le monde pareil.

dashboard_tabs, tes écrans

Ton interface admin a plusieurs onglets. Peut-être un pour tes agents, un pour tes notifications, un pour tes réglages. La liste de ces onglets, leur ordre, leur nom, tout ça vit dans dashboard_tabs. Pourquoi une table et pas du code en dur ? Parce que tu vas vouloir ajouter un onglet dans trois semaines. Si la liste est dans le code, il faut modifier le code. Si elle est dans la base, tu ajoutes une ligne.

J'ai appris ça à mes dépens avec un tableau de bord que j'avais construit dans Airtable. Chaque nouvel onglet demandait de recâbler trois automatisations. Le jour où j'ai mis la structure des onglets dans une table à part, tout est devenu modulable.

agents, notifications, app_settings, le reste du socle

La table agents stocke les fiches de tes assistants IA. Pour l'instant, juste leur nom, leur description, leurs instructions. Pas d'IA branchée derrière, on y viendra. La table notifications est ta boîte aux lettres interne. Quand quelque chose se passe dans l'app, un message atterrit là. Tu le lis, tu le marques comme lu, il disparaît de ta vue. C'est le même mécanisme que la cloche en haut à droite de n'importe quelle app.

La table app_settings est peut-être la plus discrète, mais c'est celle qui t'évitera le plus de douleur. Elle stocke tout ce qui est configurable sans toucher au code : le nom de ton app, la couleur principale, le texte de ta page d'accueil. Un seul endroit pour tout modifier.

L'auth et les réglages : deux décisions qu'on prend une fois

Le magic link : pourquoi pas un mot de passe

Tu entres ton adresse email. Tu reçois un mail avec un lien. Tu cliques. Tu es connectée. Pas de mot de passe à inventer, pas de mot de passe à oublier, pas de formulaire "réinitialiser mon mot de passe" à construire. Le magic link délègue la sécurité à ta boîte mail, qui est déjà protégée par ton propre mot de passe ou ton empreinte digitale.

Pour une app construite par une personne seule, c'est un raccourci énorme. Gérer des mots de passe, c'est gérer du hachage, du stockage sécurisé, des tentatives de brute force, des politiques de complexité. Supabase fait tout ça pour toi avec le magic link.

app_settings : ne jamais graver dans le marbre

J'ai fait l'erreur suffisamment de fois pour la reconnaître au premier coup d'œil. Tu codes le nom de ton app en dur dans un fichier. Puis dans un autre. Puis dans un troisième. Le jour où tu changes de nom, tu fais une recherche dans tout le projet et tu en oublies un. Ta page d'accueil dit "Pimpela" et ton email de bienvenue dit encore "Mon App Test". La table app_settings règle ça. Chaque valeur configurable vit dans une seule ligne de la base. L'app va la chercher là, à chaque fois. Tu changes la valeur une fois, elle change partout.

C'est la différence entre un template figé et un outil vivant. Le template, tu le remplis une fois et tu n'y touches plus. L'outil, tu le fais évoluer chaque semaine. Si chaque évolution demande de fouiller dans le code, tu arrêteras d'évoluer.

Le premier agent : une fiche sans IA derrière

Dans Pimpela, mon agent principal s'appelle Lola. Elle analyse les photos de pièces et génère des suggestions déco. Mais avant de brancher le moindre modèle d'IA, j'ai créé sa fiche : un nom, une description, un jeu d'instructions. C'est exactement ce que le skill va te faire faire. Tu vas créer une entrée dans la table agents avec les quatre gestes de base : créer, lire, modifier, supprimer. En développement, on appelle ça le CRUD, et c'est le geste fondamental de toute application qui gère des données.

Pourquoi commencer par là plutôt que par l'IA ? Parce que l'IA sans structure, c'est un cerveau sans corps. Tu peux avoir le meilleur modèle du monde, si tu n'as nulle part où stocker ses instructions, ses conversations, ses résultats, tu ne construis rien de durable. La fiche de l'agent, c'est son contrat de travail. L'intelligence vient après.

Le MCP Supabase : Claude qui travaille dans ta base

Jusqu'ici dans la série, Claude Code travaillait dans ton dossier de projet. Il lisait tes fichiers, modifiait ton code, créait des composants. Avec la connexion MCP vers Supabase, il accède directement à ta base de données. Concrètement, ça veut dire que tu peux lui demander "montre-moi toutes les entrées de la table agents" et il va les chercher. Tu peux lui dire "ajoute un onglet Statistiques dans dashboard_tabs" et il l'insère. Plus besoin de copier-coller du SQL dans la console Supabase.

Quand j'ai branché le MCP pour la première fois sur Pimpela, le changement a été immédiat. Je pouvais parler de mes données en français et Claude allait les chercher, les modifiait, me confirmait le résultat. La base de données n'était plus un endroit séparé où j'allais faire des requêtes à la main (et que de temps perdu...). Elle faisait partie de la conversation.

> Pour lancer ton skill, il va te falloir une base de données, connectée via MCP. Très simple : tu crées un compte supabase.com c'est gratuit. Tu crées un projet, tu lui donnes le nom que tu veux. Puis tu vas dans claude (le chat), en bas à gauche tu cliques sur ton nom, tu cliques sur paramètres, puis Connecteurs. Là tu cherches le connecteur Supabase et tu suis les instructions pour te connecter à ton projet. voila c'est fait !

Le skill base-builder : lancer la session

Ce que Claude va te demander

Le skill base-builder est un fichier d'instructions que Claude Code charge au démarrage. Il contient toute la procédure de construction, étape par étape, pour que tu n'aies pas à te souvenir de chaque détail technique. Attention : assure toi d'avoir bien créer ton compte supabase.com et d'avoir connecté Claude à Supabase via les connecteurs.

Pour l'installer, tu ouvres Claude Code dans Cursor (article 4 si tu as besoin d'un rappel), ou tu vas directement dans Claude Code sur l'appli desktop de Anthropic, tu copies la commande d'installation que tu vas trouver en bas de page, et tu la colles. Il installe. Puis tu lui dis de lancer base-builder.

À partir de là, Claude te guide. Il te demande le nom de ton projet. Il te demande tes couleurs. Il te demande quels onglets tu veux dans ton tableau de bord. Il crée les cinq tables dans ton projet Supabase, construit l'interface, met en place l'authentification magic link.

Tu réponds à ses questions, il construit. Tu as des questions, tu peux lui demander au fil de l'eau. La session dure entre trente et quarante-cinq minutes.

Ce que tu auras à la fin

Une app qui tourne sur ton ordinateur. Pas un prototype sur un bout de papier, pas un wireframe dans Figma. Une app avec une vraie page publique, un vrai système de connexion par magic link, un vrai tableau de bord admin avec tes onglets, une fiche d'agent créée, et cinq tables dans Supabase qui stockent tout. Tu pourras te connecter, naviguer dans ton interface, modifier tes réglages dans app_settings et voir les changements apparaître. L'app ne sera pas déployée sur internet, elle tourne en local sur ton ordinateur. Le déploiement, c'est l'étape d'après.

Tout ce que tu as appris dans les vingt articles précédents, le terminal, les bases de données, les API, l'auth, Supabase, les MCP, les skills, se retrouve dans cette session.

Ressource

La commande prête à coller.

$
npx skills add notespourplustard/nppt-base-builder

Colle-la dans Claude Code et laisse-toi guider.

Fait partie du chantierConstruire avec Claude Code/ Acte V : Se jeter à l'eau

Recevoir la newsletter

Hebdo. Les projets en cours et ce que j'en tire.