Pourquoi Supabase est le backend par défaut des applications web Coderblock

Créer une interface réussie n’est qu’un début. Dès qu’une application doit gérer des comptes, des données persistantes, des fichiers, des autorisations ou des paiements, elle a besoin de plus qu’un frontend : il lui faut un backend capable de prendre en charge le fonctionnement d’un véritable produit.

C’est là qu’intervient Supabase, le backend par défaut des applications web standard de Coderblock. Lorsque vous décrivez une application en langage naturel, Coderblock ne se contente pas de générer une maquette avec des données temporaires. Il crée une véritable application full stack : un frontend basé sur React, Vite, TypeScript et Tailwind CSS, relié à un projet Supabase dédié.

L’idée est simple : la même demande qui modifie l’interface peut également modifier ce qui se trouve derrière.

Vous ajoutez une inscription ? L’authentification est configurée. Vous ajoutez une nouvelle entité ? La structure de la base de données peut être mise à jour. Vous ajoutez l’importation de fichiers ? Le stockage entre en jeu. Vous ajoutez une fonctionnalité réservée ? Les autorisations correspondantes sont également définies.

Vous obtenez ainsi un backend qui évolue avec l’application, au lieu d’être un élément distinct à configurer ultérieurement.

Une base backend unique pour toute l’application

Un produit web peut rapidement nécessiter de nombreux services backend différents. Une plateforme de réservation a besoin de clients, de disponibilités, de réservations et de rôles administratifs. Un site e-commerce doit gérer des produits, des paniers, des commandes, des images et des paiements. Un tableau de bord peut devoir afficher des données différentes selon l’utilisateur connecté.

Supabase réunit tous ces composants dans un seul backend :

• Postgres pour les données structurées de l’application
• Supabase Auth pour la connexion par e-mail ou via les réseaux sociaux
• Row Level Security pour les règles d’accès au niveau de la base de données
• Storage pour les fichiers de l’application et ceux importés par les utilisateurs
• Deno Edge Functions pour la logique côté serveur

Avec Coderblock, vous n’avez pas à assembler ces services un par un. Chaque application web standard dispose de son propre projet Supabase, et l’agent peut intervenir sur les différentes couches de la stack lorsqu’il met en œuvre une nouvelle demande.

Vous pouvez par exemple écrire :

Ajoute une table de réservations avec une vue administrateur.

L’agent peut prendre en charge le schéma de la base de données, le relier à l’interface, configurer les autorisations nécessaires et mettre à jour l’aperçu en direct. Vous n’avez pas à interrompre votre travail pour configurer manuellement des API, des migrations ou des services backend. Et surtout, chaque modification reste liée aux précédentes. Le backend n’est pas un ensemble de composants indépendants : il évolue avec le produit.

Postgres donne vie aux applications générées

Postgres est la base de données relationnelle sur laquelle reposent de nombreuses fonctionnalités nécessaires à une application web : profils, produits, rendez-vous, abonnements, messages, réservations et bien plus encore. Cela devient particulièrement important lorsqu’on travaille en langage naturel.

Vous pouvez dire :

Permets aux clients d’enregistrer leurs biens immobiliers favoris.

Vous n’avez pas besoin de préciser les tables, les clés étrangères ou les requêtes SQL. Vous décrivez une fonctionnalité du point de vue du produit ; l’agent traduit ensuite cette demande en une structure de données capable de la prendre en charge.

Coderblock rend également visible ce qui se passe derrière la conversation. Depuis l’onglet Backend de l’éditeur, vous pouvez consulter les tables du projet, les utilisateurs authentifiés, le stockage et les fonctions. Il n’est pas nécessaire de connaître chaque détail de l’infrastructure pour travailler sur l’application, mais vous pouvez tout de même constater qu’un véritable backend existe derrière l’interface.

C’est une différence majeure par rapport à un simple prototype. Les données sont réellement enregistrées et restent disponibles d’une session à l’autre. L’aperçu sur <app>.coderblock.dev ne se contente pas de montrer à quoi le produit pourrait ressembler : il vous permet de tester les flux de données sur lesquels celui-ci repose.

L’authentification et les autorisations fonctionnent ensemble

La connexion n’est qu’une partie de l’authentification. Un système complet doit gérer les comptes et les sessions, protéger les pages réservées, associer les données aux utilisateurs et empêcher une personne d’accéder à des informations qui ne lui appartiennent pas.

Lorsque vous demandez à Coderblock d’« ajouter une connexion et des comptes utilisateur », l’agent peut intégrer Supabase Auth dans toute l’application : inscription, connexion, gestion des sessions, routes protégées et Row Level Security liée à l’utilisateur authentifié. Vous pouvez également ajouter une connexion via les réseaux sociaux si nécessaire. Chaque application comprend déjà une table de profils et une structure de base pour la gestion des rôles. L’agent peut ainsi créer plus facilement des expériences distinctes pour les clients, les membres, les collaborateurs ou les administrateurs. Vous n’avez pas non plus à développer manuellement un système de mots de passe ou une solution d’authentification personnalisée.

Supabase Auth gère l’identité. Row Level Security définit quant à elle les données que chaque utilisateur peut consulter ou modifier. Cette distinction est fondamentale. Masquer un bouton dans le frontend n’empêche pas un utilisateur d’accéder aux données associées à ce bouton. Une politique définie au niveau de la base de données peut, par exemple, garantir que chaque client ne voie que ses propres réservations, tandis qu’un administrateur autorisé peut toutes les consulter.

Avec Coderblock, ces règles peuvent faire partie intégrante de la fonctionnalité demandée, au lieu de devenir une tâche distincte à traiter après la création de l’interface.

Fichiers, intégrations et logique serveur sans stack distincte

Une véritable application doit souvent faire bien plus que lire et écrire des données. Elle peut devoir gérer des photos de profil, des documents, des images de produits ou d’autres fichiers importés par les utilisateurs. Elle peut aussi devoir effectuer des opérations privilégiées ou communiquer avec des services externes sans exposer d’identifiants dans le navigateur.

Supabase Storage et Deno Edge Functions répondent à ces besoins au sein du même backend. Lorsqu’une intégration nécessite un secret, Coderblock le gère à l’aide d’une invite dédiée et sécurisée pour les variables d’environnement. La valeur est conservée côté serveur, sans être insérée dans le code généré ni affichée dans la conversation ordinaire.

Stripe en est un exemple concret. Vous pouvez demander directement dans la conversation d’ajouter un abonnement ou un processus de paiement. Dans le mode géré par défaut, l’agent configure Stripe pour le projet après avoir recueilli quelques informations de base, puis la plateforme prend en charge le webhook de paiement.

Si vous préférez utiliser votre propre compte Stripe, vous pouvez choisir le mode BYOK. Dans ce cas, l’agent demande la STRIPE_SECRET_KEY de manière sécurisée et configure automatiquement le webhook.

Dans les deux cas, Coderblock peut créer les produits, les tarifs et les processus de paiement, puis relier le flux de paiement au frontend comme au backend de l’application. L’objectif reste toujours le même : ajouter une fonctionnalité complète, et pas seulement son composant visuel.

Un backend qui accompagne l’application de l’idée à la publication

Le flux de travail de Coderblock est conçu pour être continu.

Vous décrivez une application. Vous la générez. Vous la testez dans l’aperçu en direct. Vous la modifiez. Vous la publiez.

Les modifications apparaissent sur <app>.coderblock.dev en quelques secondes. Le backend doit donc, lui aussi, pouvoir évoluer avec l’interface. C’est tout l’intérêt d’intégrer le backend au processus : lorsque vous modifiez le produit, vous pouvez également faire évoluer les données, les autorisations et la logique qui le sous-tendent, sans devoir reconstruire manuellement l’infrastructure à chaque itération.

Lorsque l’application est prête, vous pouvez la publier en un clic sur <app>.coderblock.app ou connecter un domaine personnalisé, avec SSL inclus. Supabase est le backend par défaut des applications web standard, mais Coderblock utilise d’autres architectures lorsque le projet l’exige. Les projets Enterprise Web Platform, par exemple, utilisent Python et FastAPI avec Neon Postgres afin de répondre à des besoins spécifiques de plateforme.

Pour la plupart des applications web, toutefois, l’association de Postgres, Auth, Row Level Security, Storage et Edge Functions offre une base complète pour transformer une idée en un produit réellement fonctionnel.

Le backend ne devrait pas être un deuxième projet

Lorsque vous créez une application au fil d’une conversation, vous ne voulez pas devoir passer sans cesse de l’idée au frontend, du frontend à la base de données, puis de la base de données à l’infrastructure. Vous voulez pouvoir dire :

« Ajoute des comptes pour les clients. »

Puis :

« Maintenant, fais en sorte que chaque client ne puisse voir que ses propres réservations. »

Puis :

« Ajoute la possibilité d’importer une photo de profil. »

Chaque demande doit pouvoir évoluer naturellement vers la suivante. C’est le rôle du backend dans Coderblock : ne pas être un système distinct à configurer après avoir créé l’interface, mais la partie de l’application qui grandit avec votre idée. Vous obtenez ainsi une application full stack que vous pouvez générer, tester et continuer à développer depuis la même interface conversationnelle.