Aller au contenu
Studeia Docs
AI-assisted translation — last updated 2026-07-18. For original (pt-BR or en-US), use the language switcher.

Multi-tenancy et isolation des données

Architecture multi-tenant de Studeia : chaque établissement bénéficie d'une isolation complète au niveau de la base de données avec filtrage par tenantId, RLS Supabase, clés API par tenant, white-label total et SSO indépendant.

Par Équipe Studeia 2026-07-18 7 min
Resposta curta

Le multi-tenancy chez Studeia garantit que les données de chaque établissement sont totalement isolées des autres — une exigence en matière de confidentialité et de sécurité pour opérer en toute confiance. Chaque tenant dispose de sa propre marque, de sa propre configuration IA (avec possibilité d'utiliser ses propres clés) et de ses propres clés API, avec une isolation au niveau de la base de données et les RLS comme filet de sécurité. En pratique, votre établissement fonctionne comme si la plateforme lui était dédiée.

Modèle conceptuel

Tenant (Établissement)
  ├── Users (étudiants, professeurs, coordinateurs, admin institutionnel)
  ├── Courses → Modules → Lessons
  ├── ClassGroups (groupes de classe)
  ├── MediaAssets (bibliothèque multimédia)
  ├── Automations
  ├── EmailTemplates
  ├── VideoProviderConfig (BBB/Zoom/Teams/Meet)
  ├── TenantApiKey (clés API propres)
  ├── TenantSubscription (facturation)
  ├── ...toutes les autres entités

Les utilisateurs sans tenantId sont B2C (plateforme directe). Les utilisateurs avec tenantId appartiennent à un établissement.

Isolation des données — 3 couches

Couche 1 : Filtrage obligatoire dans les requêtes

Toute requête Prisma dans le code applicatif filtre par tenantId :

const { tenantId } = requireTenant(user);
const courses = await prisma.course.findMany({
  where: { tenantId }, // OBLIGATOIRE
});

requireTenant() dans apps/web/lib/tenant.ts retourne un NextResponse 403 si l'utilisateur n'a pas de tenant. Sans cet appel, il est impossible d'accéder aux données B2B.

Couche 2 : RLS dans Supabase

En tant que filet de sécurité contre les bugs, les politiques RLS dans Supabase renforcent l'isolation même pour les requêtes directes. Si un code oublie le filtre tenantId, la base de données refuse.

Couche 3 : Audit de l'admin global

Lorsqu'un admin global doit accéder aux données d'un tenant (support, débogage), il utilise l'impersonation via un cookie HMAC avec :

  • TTL fixe d'1 heure (non prolongeable)
  • Signature HMAC-SHA256 avec IMPERSONATION_SECRET
  • Audit dans AdminAuditLog (action impersonate.start, IP, user-agent)
  • getUserProfile() retourne isImpersonating: true + overlay en mémoire
  • L'auth Supabase n'est JAMAIS modifiée (overlay uniquement)
  • Une bannière sticky sur /institution/ avertit l'admin pendant la session

Le panneau admin SaaS global inclut l'impersonation pour le support.

Clés API par tenant

Par défaut, tous les appels LLM utilisent les clés globales de Studeia (ANTHROPIC_API_KEY, OPENAI_API_KEY, etc.). Les coûts sont imputés au tenant via le metering.

Mais les établissements qui disposent déjà de comptes Anthropic/OpenAI/Google peuvent utiliser leurs propres clés (TenantApiKey, chiffrée AES-256-GCM en base de données) :

  1. Les coûts vont DIRECTEMENT sur le compte du tenant chez Anthropic/OpenAI
  2. Studeia ne facture pas de marge sur l'IA — uniquement l'abonnement mensuel
  3. Résolution automatique : TenantApiKeyProviderApiKey global → process.env (cascade dans apps/web/lib/api-key-resolver.ts)

Ne modifie JAMAIS process.env à l'exécution (conflits entre tenants) — la clé est transmise via les options du SDK.

White-label complet

Chaque tenant peut personnaliser :

AspectComment
Logo, faviconImport dans les paramètres
Couleurs (primary, accent, background)Éditeur avec aperçu
Police (Google Fonts)Menu déroulant
Thème visuel (parmi 9 options)Basculement par utilisateur ou par défaut du tenant
CSS personnaliséAssaini, max 10 Ko
Domaine personnaliséDNS CNAME + TXT _studeia-verify + TLS automatique Caddy (on-demand)
Logo dans les e-mailsPar modèle
E-mail expéditeur (SMTP/Resend/SendGrid)TenantEmailConfig
Masquer la marque StudeiaOui (plan Enterprise)

Rôles et permissions

RôlePérimètrePeut faire
studentSa propre progressionChat tuteur, cours, examens blancs, gamification
parentEnfants liésVoir la progression, alertes, rapports
teacherSes propres classes/coursCréer des cours, importer du contenu, voir les étudiants de ses classes
coordinatorToutes les classes du tenantGérer les classes, voir tous les étudiants
pedagogueTous les étudiants du tenantAccompagnement pédagogique, rapports
institution_adminTout le tenantConfig IA, clés API, white-label, utilisateurs
adminGlobal (plateforme)Tout + gestion des tenants

Limites par plan

Limites appliquées via checkTenantResourceLimit(tenantId, resource) dans apps/web/lib/plan-limits.ts :

PlanÉtudiants maxProfesseursCoursIA
Demo111Haiku uniquement, 10 msg/jour
Mini10IllimitéIllimitéTous les providers
Crescimento50IllimitéIllimitéTous les providers
Escala100IllimitéIllimitéTous les providers
EnterprisePersonnalisé (maxStudentsOverride)IllimitéIllimitéTous les providers

7 points d'application (tous audités le 2026-04-11) :

  1. POST /api/courses/[courseId]/enroll — auto-inscription de l'étudiant
  2. POST /api/institution/courses/[id]/clone — duplication de cours
  3. POST /api/institution/courses/import — import IMS CC
  4. executeEnrollUser() dans une automatisation
  5. POST /api/scim/v2/Users — provisionnement SCIM
  6. POST /api/institution/users — rattacher un utilisateur existant
  7. PATCH /api/institution/users/[id] — promouvoir un rôle

Comment demander un override Enterprise

Les tenants Enterprise peuvent faire ajuster Tenant.maxStudentsOverride: Int? par l'admin global. Sans override (null), Enterprise = illimité. Contactez l'équipe commerciale via contact@studeia.com.

Limitations

  • Un User appartient à UN seul tenant. Pour les enseignants intervenant dans plusieurs établissements, créer des utilisateurs distincts.
  • Le partage de cours entre tenants n'est pas natif (chaque tenant dispose de son propre CMS isolé). Feuille de route : marketplace de cours avec système de licences.
  • La migration d'un tenant vers un autre plan est instantanée, mais un downgrade qui violerait les limites actuelles est bloqué jusqu'à ce que le tenant ajuste ses ressources.

Voir aussi

FAQ

Les données des tenants sont-elles réellement isolées ?

Oui. Trois couches : (1) toute requête Prisma filtre obligatoirement par tenantId (règle critique 30 du projet) ; (2) les politiques RLS dans Supabase servent de filet de sécurité ; (3) audit automatisé des requêtes cross-tenant via les tests. L'impersonation par un admin global est auditée (AdminAuditLog) et utilise un cookie HMAC avec un TTL fixe d'1 heure.

Puis-je avoir mon propre domaine (white-label complet) ?

Oui. Configurez Tenant.customDomain dans les paramètres + pointez un CNAME vers le domaine Studeia. TLS automatique via Let's Encrypt sur Caddy (on-demand TLS, après vérification du domaine par enregistrement TXT). Logo, favicon, couleurs, polices, 9 thèmes visuels et même les messages d'e-mail sont personnalisables. Vous pouvez supprimer entièrement la marque Studeia.

Les coûts d'IA sont-ils calculés par tenant ?

Oui. Chaque appel LLM est enregistré dans AiUsageLog avec le tenantId. L'admin global dispose d'une ventilation des coûts par tenant dans /admin/finance/ai-cost (avec calcul de marge vs MRR). Les tenants peuvent utiliser leurs propres clés API (TenantApiKey) — dans ce cas, les coûts sont imputés au tenant, et non à Studeia.

Comment les utilisateurs cross-tenant sont-ils gérés ?

Par conception, un User appartient à UN seul tenant (User.tenantId). Pour les cas B2B où un pédagogue intervient dans plusieurs établissements, nous recommandons de créer des utilisateurs distincts par établissement. L'admin global peut réaffecter des utilisateurs via /admin/tenants (action auditée).

Veja tambem

Multi-tenancy et isolation des données