L'architecture cœur : la séparation des responsabilités

La plus grande erreur dans un SaaS no-code est d'utiliser une plateforme tout-en-un (Bubble, Glide) où le frontend et le backend sont étroitement couplés. Cela provoque trois problèmes à l'échelle : les performances se dégradent car vous ne pouvez pas scaler le frontend et le backend indépendamment, vos données sont verrouillées dans la plateforme, et vous ne pouvez pas optimiser chaque couche séparément.

L'architecture correcte sépare les responsabilités : - Frontend : WeWeb (livré via CDN, scalable indépendamment) - Logique métier : Xano (API horizontalement scalable) - Base de données : Supabase (PostgreSQL managé, scale jusqu'à des milliards de lignes) - Automatisation : Make ou n8n (jobs asynchrones, webhooks, notifications)

Cette approche est la même que celle adoptée par les équipes techniques qui construisent des SaaS sur AWS ou GCP — sauf que vous remplacez le code custom par des outils no-code. Pour les startups françaises en phase de levée de fonds seed, cette architecture répond favorablement aux questions de due diligence technique posées par des fonds comme Partech ou Kima Ventures.

La couche données : PostgreSQL avec RLS

Votre modèle de données est la décision architecturale la plus importante. Faites-la bien et le scaling est facile. Faites-la mal et vous devrez tout reconstruire.

Principes clés pour une base de données SaaS no-code scalable : 1. Chaque table a created_at, updated_at, et une clé primaire (bigserial) 2. Multi-tenancy via une clé étrangère workspace_id sur chaque table 3. Politiques Row-Level Security sur chaque table exposée aux utilisateurs 4. Index sur workspace_id, user_id, status, created_at 5. Ne jamais stocker des valeurs calculées dans la base — calculez dans Xano

Supabase PostgreSQL gère cela magnifiquement. Les politiques RLS signifient que vos endpoints API ne peuvent pas accidentellement retourner les données d'un autre tenant — la base de données applique l'isolation. Dans le contexte français, cet argument résonne fort auprès des équipes DPO et des RSSI lors des audits de sécurité pré-contractuels avec des clients grands comptes.

Commencez votre schéma avec une table `workspaces`, une table `workspace_members` (user_id, workspace_id, role), et des politiques RLS qui filtrent par workspace_id sur toutes les tables métier. C'est la fondation de tout SaaS multi-tenant robuste.

La couche API : logique métier Xano

Xano se place entre votre frontend et votre base de données. Chaque action utilisateur passe par un endpoint Xano, pas directement par Supabase. Cela vous donne : - Validation des entrées avant d'atteindre la base de données - Logique métier (calculs de prix, machines à états, vérifications de permissions) - Intégrations tierces (Stripe, SendGrid, Twilio) en un seul endroit - Logging d'audit au niveau de l'API

Structurez vos endpoints Xano de manière RESTful : GET /workspaces/:id/projects, POST /projects, PATCH /projects/:id. Évitez les endpoints de style RPC. Gardez les endpoints petits et composables.

Un pattern que nous utilisons systématiquement : créez des "fonction utilitaire" Xano pour chaque service externe (Stripe, emails, SMS). Ces utilitaires gèrent l'appel API, la gestion des erreurs et le parsing de la réponse — puis appelez-les depuis vos stacks de logique métier. Cela garde votre code propre et facilite les mises à jour d'intégrations. Pour les applications destinées au marché français, pensez également aux intégrations locales : Pennylane pour la comptabilité, Sellsy pour le CRM, HelloSign pour les signatures électroniques.

La couche frontend : performances WeWeb

WeWeb génère une vraie application web : HTML/CSS/JS statique livré via CDN, avec des données dynamiques récupérées via des appels REST API. Cela signifie : - Le premier chargement est rapide (assets statiques mis en cache sur CDN) - Les données se chargent de manière asynchrone (pas de goulot d'étranglement server-side rendering) - Le frontend scale infiniment (ce ne sont que des fichiers sur un CDN)

Pour les performances à l'échelle : paginez toutes les requêtes de liste (50 éléments maximum par page), utilisez le caching intégré de WeWeb pour les données statiques, et chargez les composants lourds en lazy loading.

Un avantage souvent sous-estimé : WeWeb génère du vrai HTML, ce qui signifie que vos pages marketing et pages publiques sont correctement indexées par Google. Pour un SaaS B2B qui s'appuie sur le SEO pour l'acquisition, c'est un argument décisif face à Bubble dont les scores Lighthouse restent faibles sur mobile. Les équipes de growth des startups que nous accompagnons à Station F apprécient particulièrement cet avantage.

Authentification et multi-tenancy

Utilisez Supabase Auth pour l'authentification des utilisateurs — c'est battle-tested et gratuit sur le plan Free. Le flux : 1. L'utilisateur s'inscrit/se connecte via Supabase Auth 2. Supabase émet un JWT avec user_id et workspace_id 3. WeWeb stocke le JWT, l'envoie avec chaque requête API Xano 4. Xano valide le JWT et extrait le contexte utilisateur 5. Les politiques RLS de la base de données utilisent auth.uid() pour appliquer l'isolation au niveau des lignes

Pour le multi-tenancy : créez une table `workspaces`, une table `workspace_members` (user_id, workspace_id, role), et passez workspace_id dans chaque requête API. Xano vérifie l'appartenance avant toute opération.

N'oubliez pas de gérer les cas limites : que se passe-t-il si un utilisateur est membre de plusieurs workspaces ? Comment gérez-vous l'invitation par email ? Ces patterns sont documentés et bien connus — ne les réinventez pas. Xano a des templates pour l'auth multi-tenant qui vous font gagner plusieurs jours de développement.

Quand migrer vers du code custom

Cette architecture scale confortablement jusqu'à 100 000 MAU pour la plupart des types de SaaS. Au-delà, des goulots d'étranglement spécifiques peuvent apparaître :

- Débit d'écriture très élevé (>1 000 écritures/seconde) : le PostgreSQL managé de Supabase peut nécessiter une instance dédiée - Fonctionnalités temps réel complexes (multijoueur, collaboration en direct) : vous pourriez vouloir une infrastructure WebSocket custom - Inférence LLM custom : les modèles auto-hébergés nécessitent une infrastructure spécifique

Pour 95 % des produits SaaS, cette architecture est plus que suffisante à toute échelle. Et quand vous devez migrer une couche, vous pouvez le faire — vos données sont dans un PostgreSQL standard, votre API est REST, votre code frontend vous appartient. Il n'y a pas de lock-in.

Cette flexibilité est particulièrement valorisée par les investisseurs lors des due diligences techniques : ils veulent voir que le produit peut être pris en main par une équipe d'ingénieurs traditionnels si nécessaire. Avec cette architecture, la réponse est clairement oui.