Par Thales & Claude -- CEO & AI CTO, ZeroSuite, Inc.
Le 3 mars 2026, la plateforme web Deblo.ai était déjà en ligne. Quatre-vingt-seize sessions de profondeur, avec un chat fonctionnel, 24 outils IA, des appels vocaux, des paiements par crédits et un moteur de curriculum complet. Le web était solide. Mais en Afrique de l'Ouest, le « web » ne suffit pas. Les élèves que nous ciblons vivent sur leur téléphone. Si Deblo devait atteindre 250 millions d'élèves africains, il fallait une application mobile native.
Sept jours. Vingt sessions. Un monorepo.
Pourquoi natif, et pourquoi maintenant
Nous avons rejeté l'idée d'encapsuler l'application web SvelteKit dans une WebView pour quatre raisons : les appels vocaux (WebRTC non fiable en WebView sur Android), les notifications push, l'authentification biométrique, et la performance.
Nous avons choisi React Native avec Expo SDK 54, React 19.1 et TypeScript en mode strict.
L'architecture monorepo
Nous avons créé quatre packages partagés :
- @deblo/api -- Client API typé avec injection de token et wrappers pour tous les endpoints.
- @deblo/stores -- Stores Zustand pour auth, chat, voix, paramètres et devises.
- @deblo/streaming -- Le hook de streaming SSE (
useStream) pour les réponses IA en temps réel. - @deblo/i18n -- Internationalisation avec
i18nextetreact-i18next.
Gestion d'état : Zustand avec SecureStore
La décision de design clé : setTokenGetter(() => get().token) est appelé à la création du store. Cela injecte une fonction dans le package @deblo/api que le client API appelle avant chaque requête pour attacher l'en-tête Authorization. Ce pattern a éliminé toute une classe de bugs « token non disponible ».
La barre d'onglets personnalisée
La barre d'onglets K12 utilise le vert (#22c55e) comme couleur principale, contrastant avec le branding orange de la plateforme web. L'onglet central est un bouton d'action flottant (FAB) qui ouvre un modal avec des raccourcis d'outils : nouveau chat, analyse photo, appel vocal, tableau de dessin et générateur d'exercices.
Streaming SSE sur React Native
C'était le défi technique le plus difficile. Nous avons construit un hook useStream personnalisé dans le package @deblo/streaming qui gère le parsing SSE via fetch avec ReadableStream. Le détail critique est la gestion du buffer : les lignes SSE peuvent être réparties sur plusieurs chunks ReadableStream, surtout sur les connexions mobiles lentes.
Authentification : quatre couches
- OTP téléphone -- Le flux principal, identique au web.
- Google Sign-In -- Optionnel, via
@react-native-google-signin/google-signin. - Déverrouillage biométrique -- Face ID ou empreinte digitale via
expo-local-authentication. - PIN élève -- Pour les élèves de CP à CM2 (6-12 ans) qui partagent le téléphone d'un parent.
Le défi MathBlock
Le rendu LaTeX sur React Native était notre baleine blanche. Nous avons opté pour une approche hybride : les expressions inline simples sont rendues avec react-native-mathjax-svg, et les expressions complexes utilisent un renderer basé sur WebView avec KaTeX CSS pré-compilé.
Sept jours en chiffres
- 20 sessions de développement sur 7 jours calendaires
- 4 packages partagés
- 20+ écrans
- 5 méthodes d'authentification
- 1 monorepo avec workspaces
Ce que nous avons appris
Premièrement, les packages partagés ne sont pas optionnels pour les produits multi-plateformes. Sans @deblo/api et @deblo/streaming, nous aurions dupliqué des milliers de lignes de code.
Deuxièmement, Expo a mûri de façon spectaculaire. En 2026, avec le SDK 54, les builds de développement, EAS et Expo Router, c'est le point de départ par défaut.
Troisièmement, le design mobile-first révèle les hypothèses web-first. Chaque écran que nous avons construit pour le mobile nous a fait revenir améliorer le web.
Ceci est l'article 9 de 20 dans la série « Comment nous avons construit Deblo.ai ».