L'architecture SaaS no-code qui tient la charge jusqu'à 10 000 utilisateurs

Le stack central

Frontend : WeWeb, UI pixel perfect, se connecte à n'importe quel backend, se déploie sur votre propre domaine via Cloudflare CDN.

Base de données + Auth : Supabase, PostgreSQL, Row-Level Security, souscriptions temps réel, stockage de fichiers.

Logique métier + API : Xano, constructeur d'API REST, logique métier personnalisée, intégrations tierces, webhooks.

Paiements : Stripe, abonnements, factures, webhooks vers Xano.

Email : Resend ou SendGrid, emails transactionnels déclenchés par Xano.

Ce stack gère 10 000 MAU sans transpirer. Nous l'avons fait fonctionner à 50 000 MAU sans changement d'infrastructure. Pour le marché français, nous recommandons de choisir une région EU pour Supabase afin de garantir la conformité RGPD. Vous pouvez travailler avec un développeur WeWeb expérimenté pour mettre en place cette architecture dès le premier sprint.

Multi-tenancy avec Supabase RLS

Chaque table possède une colonne workspace_id. Toutes les politiques Row-Level Security filtrent sur workspace_id = auth.jwt() ->> 'workspace_id'.

Les utilisateurs appartiennent à des workspaces via une table workspace_members avec une colonne role (owner, admin, member). Lorsqu'un utilisateur se connecte, le JWT inclut son workspace_id et son rôle, Supabase l'applique automatiquement au niveau de la base de données.

C'est la décision architecturale la plus importante dans un SaaS B2B. La corriger dès le jour 1 évite une refonte douloureuse lors de votre croissance. Nous avons vu des startups perdre 2-3 mois de développement pour avoir négligé ce point au démarrage.

Architecture de facturation avec Stripe

Dans Xano, créez un endpoint webhooks qui reçoit les événements Stripe. Gérez : checkout.session.completed (créer un enregistrement d'abonnement), customer.subscription.updated (mettre à jour le plan), invoice.payment_failed (restreindre l'accès).

Stockez le statut d'abonnement dans une table workspace_settings. Dans WeWeb, vérifiez le statut d'abonnement avant d'afficher les fonctionnalités premium, et dans les politiques RLS de Supabase pour les restrictions au niveau des données.

Ne faites jamais confiance au frontend pour les contrôles de facturation. Vérifiez toujours dans la base de données. En France, pensez aussi à la conformité TVA et à l'intégration avec les outils de facturation locaux comme Pennylane.

Optimisation des performances

Stratégie d'indexation : indexez chaque clé étrangère, chaque colonne status/type utilisée dans les filtres, et toute colonne sur laquelle vous triez. Dans Supabase, cela prend 2 minutes dans l'éditeur SQL.

Pagination : tous les endpoints de liste doivent paginer. Ne retournez jamais de requêtes non bornées. Utilisez la pagination par curseur pour les données temps réel (défilement infini) et l'offset pour les tables d'administration.

Cache : Xano supporte la mise en cache des réponses pour les endpoints qui retournent les mêmes données à tous les utilisateurs (contenu public, tables de référence). Utilisez-le agressivement.

Monitoring et gestion des erreurs

Ajoutez Sentry à votre code personnalisé WeWeb pour les erreurs frontend. Xano journalise toutes les requêtes API, exportez-les vers Datadog ou utilisez le monitoring d'erreurs intégré de Xano.

Pour les jobs en arrière-plan critiques (webhooks de facturation, déclencheurs d'emails), ajoutez des notifications d'erreur dans Slack via Make. Vous devez connaître les échecs avant vos utilisateurs.

Monitoring de base de données : Supabase fournit des informations sur les performances des requêtes. Passez en revue les requêtes lentes chaque semaine. Un bon monitoring dès le départ est la différence entre découvrir un problème à 2h du matin et le prévenir.

Patterns de multi-tenancy : bases partagées vs isolées

Il existe trois modèles de multi-tenancy : base de données partagée avec RLS (tous les tenants dans les mêmes tables, isolés par des politiques), base de données partagée avec schémas séparés (chaque tenant a son propre schéma PostgreSQL), et bases de données séparées par tenant. La grande majorité des apps SaaS à 10 000 utilisateurs ou moins devraient utiliser le premier modèle, base de données partagée avec RLS. C'est le plus simple à construire, le moins cher à opérer, et le RLS de Supabase le rend réellement sécurisé.

Les schémas séparés par tenant (souvent appelés "schema-per-tenant") deviennent pertinents quand les tenants ont des structures de données légitimement différentes, ce qui est rare en pratique. Les bases de données séparées par tenant sont une fonctionnalité enterprise utilisée quand les tenants exigent des garanties contractuelles de résidence des données ou leurs propres identifiants de base de données. Chez App Studio, nous implémentons le modèle base partagée avec RLS pour tous les produits SaaS, jusqu'à ce qu'un client ait une exigence contractuelle spécifique pour une isolation plus forte.

Le détail d'implémentation critique : chaque INSERT doit définir workspace_id explicitement, et vos politiques RLS WITH CHECK doivent s'assurer que workspace_id correspond au workspace de l'utilisateur authentifié. Si vous ratez cela sur ne serait-ce qu'un seul endpoint, un utilisateur pourrait insérer des données dans le workspace d'un autre tenant. Nous validons cela avec une suite de tests de sécurité qui crée deux workspaces de test et vérifie l'isolation des données sur les 50+ endpoints.

Principes de conception de base de données pour un SaaS no-code

Le schéma de base de données est la fondation sur laquelle tout le reste repose. De mauvaises décisions de schéma au mois 1 causent une douleur en cascade au mois 12. Le principe le plus important : concevoir pour vos requêtes, pas pour une normalisation théorique. Si vous allez toujours interroger les projets avec leur workspace et leur propriétaire associés, stockez workspace_id et owner_id directement sur la table projects plutôt que de joindre via workspace_members à chaque fois.

Utilisez des contraintes au niveau de la base de données comme seconde couche de validation. Clés étrangères (project.workspace_id référence workspaces.id), contraintes not-null sur les champs requis, et contraintes check pour les valeurs de type enum (status IN ('active', 'paused', 'cancelled')). Ces contraintes attrapent les bugs de votre couche applicative avant qu'ils ne corrompent vos données. Supabase les applique nativement, ajoutez-les à la création de vos tables, pas après coup.

Pour la facturation SaaS, utilisez une table subscription dédiée plutôt que de stocker les données de plan directement sur la table workspace. Un abonnement a un cycle de vie (trialing, active, past_due, cancelled) avec des horodatages pour chaque transition d'état. Stocker cela comme une entité séparée rend la logique de facturation propre et vous donne une piste d'audit complète, essentielle pour résoudre les litiges de facturation et déboguer les anomalies de revenu.

Stratégie de cache : quoi mettre en cache et où

La mise en cache dans une stack SaaS no-code fonctionne à trois niveaux : le cache d'endpoint Xano (niveau réponse), les vues matérialisées Supabase (niveau requête), et l'état côté client de WeWeb (niveau UI). Chacun sert un objectif différent et a des exigences d'invalidation différentes.

Le cache d'endpoint Xano est approprié pour les données identiques pour tous les utilisateurs et qui changent rarement : tables de référence (listes de pays, catégories de secteur), plans tarifaires publics, configurations de feature flags. Fixez un TTL de 5 à 60 minutes selon la fréquence de changement des données. Cela réduit significativement la charge de la base de données pour les endpoints appelés à chaque chargement de page.

Les vues matérialisées de Supabase sont l'outil adapté pour les requêtes d'agrégation coûteuses : métriques d'usage au niveau workspace, données de rapports mensuels, calculs de classements. Rafraîchissez-les sur un planning (toutes les 15 minutes pour des dashboards quasi temps réel, une fois par jour pour les rapports de facturation) en utilisant l'extension cron de Supabase. Nous avons réduit le temps de chargement de dashboard par 10 sur des apps SaaS riches en analytics en déplaçant les agrégations vers des vues matérialisées.

La mise en cache côté client de WeWeb via son store de variables intégré réduit les appels API redondants au sein d'une session. Mettez en cache les paramètres de workspace de l'utilisateur actuel, le statut d'abonnement et les feature flags à la connexion, ce sont des données nécessaires à chaque page et qui ne changent pas en cours de session. Invalidez le cache à la déconnexion et lors d'une mise à niveau de plan.

Jobs en arrière-plan : patterns pour le traitement asynchrone

Toute opération qui prend plus de 500 ms devrait être asynchrone. Dans une stack SaaS no-code, les jobs en arrière-plan tournent dans la file de tâches de Xano, déclenchés via des planificateurs Make.com ou n8n, ou via des Supabase Edge Functions déclenchées par des changements en base de données.

Les jobs en arrière-plan les plus courants dans les produits SaaS que nous construisons : traitement du renouvellement d'abonnement (vérifier tous les workspaces avec un renouvellement dû aujourd'hui, débiter Stripe, mettre à jour le statut d'abonnement, envoyer un email de reçu), génération d'exports de données (l'utilisateur demande un export CSV, un job le génère et envoie un lien de téléchargement par email, ne jamais bloquer l'UI pour cela), synchronisation tierce (pousser les nouveaux contacts CRM vers HubSpot, synchroniser les événements de calendrier vers Google Calendar), et le comptage d'usage (agréger les appels API ou l'usage de fonctionnalités chaque heure pour la facturation).

La gestion des erreurs pour les jobs en arrière-plan demande plus de soin que pour les endpoints synchrones, il n'y a pas d'utilisateur qui attend une réponse. Chaque job devrait : journaliser son début et sa fin, attraper toutes les erreurs et les écrire dans une table job_errors, envoyer une alerte Slack en cas d'échec, et implémenter une logique de retry avec backoff exponentiel pour les échecs transitoires (erreurs réseau, limites de débit). La file de tâches de Xano gère les retries nativement, pour les jobs déclenchés par Make.com, implémentez la logique de retry dans le scénario.

Monitorer un SaaS no-code en production

Le monitoring en production sans équipe DevOps demande de choisir les bons outils et d'automatiser les alertes. Pour la stack que nous utilisons, la configuration de monitoring minimum viable est : Sentry pour les erreurs frontend (intégration au code personnalisé WeWeb), les logs de requêtes intégrés de Xano avec alertes d'erreur, les informations de performance de base de données et le monitoring du pool de connexions de Supabase, et le dashboard de Stripe pour les taux d'échec de paiement.

Au-delà du monitoring d'erreurs, suivez des métriques de santé au niveau business : utilisateurs actifs quotidiens (requête Supabase), distribution du temps de réponse API (export des logs Xano), tentatives de connexion échouées (événements de sécurité potentiels), et taux de churn d'abonnement (webhooks Stripe → Supabase → une vue de reporting simple). Mettez en place des rapports automatisés hebdomadaires qui envoient ces métriques par email au fondateur, la plupart des problèmes deviennent visibles comme des changements de tendance avant de devenir des crises.

Pour les apps SaaS au-dessus de 5 000 MAU, ajoutez un monitoring de disponibilité via Better Uptime ou Pingdom sur vos endpoints critiques (connexion, workflow central). Alertez sur Slack dans les 2 minutes suivant une panne. À ce nombre d'utilisateurs, même une panne de 10 minutes pendant les heures ouvrées génère un volume de support significatif. Le coût du monitoring de disponibilité (20 à 50 €/mois) est facilement justifié.