Application mobile (B2B) : Android, white-label, offline-friendly

Architecture

Stack : React Native + Expo Router v4 (file-based), NativeWind v4, TanStack Query, Zustand, expo-secure-store. Monorepo via pnpm (node-linker=hoisted).
Auth : Supabase avec AsyncStorage ; l'application envoie un Bearer JWT vers une surface dédiée /api/mobile/* (~47 endpoints) qui retourne des structures et des plans simplifiés.
White-label : un ThemeProvider dynamique lit le thème du tenant sur /api/mobile/me après la connexion ; le branding avant connexion provient de l'endpoint public /api/mobile/tenant-branding.
Mises à jour OTA : expo-updates avec runtimeVersion fixé à la version du SDK ; un AppVersionGate peut forcer la mise à jour lorsque le build installé est en dessous d'un minimum configuré.

Contenu de l'application

Domaine	Écrans
Apprentissage	tableau de bord, cours (liste + catalogue + détail), lecteur de leçon, progression
Évaluation	quiz player natif, envoi de devoir
Tuteur	chat du tuteur IA (SSE), avatar parlant (WebView), avertissements de quarantaine/sécurité
Social	messages directs, forums (forum → fil → réponse), annonces, supports de cours
Gamification	XP/niveau/streak, badges, classement, concours, boutique de récompenses
Relevés	notes, certificats, notifications (liste + marquer comme lu)
En direct	cours en direct (WebView), calendrier

SSO sur mobile

La route /api/auth/sso/[tenantSlug] accepte un deep link redirect=studeia://... ; le callback émet un 302 vers studeia://auth/callback#access_token=...&refresh_token=.... Un listener Linking dans le fournisseur d'auth appelle supabase.auth.setSession(), et l'écran SSO utilise une session de navigateur in-app pour que le focus retourne à l'application.

Modèle de sécurité

Les endpoints mobiles réutilisent les mêmes guards d'autorisation que le web : guards d'accès aux forums/fils, accès aux leçons (publication + prérequis + inscription), pièces jointes de devoirs dans un bucket privé avec préfixe validé, et assainissement du HTML côté serveur avant tout rendu dans une WebView (les WebViews s'exécutent avec une liste blanche d'origines stricte et le JS désactivé dans la mesure du possible).

Avatar sur mobile

L'avatar parlant s'exécute dans une WebView qui charge la même page /avatar-embed utilisée sur le web (sans modules WebRTC natifs dans Expo) ; un bridge React Native transmet les messages de contrôle.

Roadmap

iOS n'a pas encore été publié — cela nécessite un compte Apple Developer et un build EAS dédié.

Voir aussi

FAQ

Studeia dispose-t-il d'une application mobile pour les apprenants ?

Oui — une application B2B native développée avec React Native/Expo (SDK 52), publiée pour Android. Elle s'authentifie via Supabase (Bearer JWT), prend en charge le SSO par deep link et applique dynamiquement le thème white-label de chaque établissement après la connexion. iOS nécessite un compte Apple Developer et un build dédié (roadmap).

L'application mobile est-elle white-label par établissement ?

Oui. Après la connexion, l'application appelle /api/mobile/me et applique le thème du tenant (couleurs, logo, nom) via le ThemeProvider mobile. Avant la connexion, elle prévisualise le branding via l'endpoint public /api/mobile/tenant-branding en utilisant le dernier slug, de sorte que l'apprenant voit l'identité de son école et non une interface générique de Studeia.

Que peut faire l'apprenant dans l'application ?

Tableau de bord, catalogue et détail de cours, lecteur de leçon, quiz player natif, envoi de devoir, chat du tuteur IA via SSE, notes, cours en direct (WebView), calendrier, messages directs, forums, supports de cours, gamification (XP, badges, classement, concours, boutique de récompenses), certificats, progression, notifications push et l'avatar parlant du tuteur IA.