Quand j'ai commencé à construire Lydia-Edu, ma première erreur a été de partir des hypothèses standards du développement web : une connexion stable, un navigateur récent, un écran de taille décente. Des hypothèses raisonnables en Europe. Des hypothèses qui excluent une large partie de mes utilisateurs cibles au Bénin.
La réalité du terrain est différente. Un directeur d'école à Parakou qui essaie d'accéder au tableau de bord de sa plateforme pendant une coupure de réseau. Un enseignant qui télécharge les bulletins en fin de journée parce que la connexion est meilleure le soir. Un parent qui consulte les notes de son enfant avec un smartphone à 512 Mo de RAM.
L'approche offline-first comme philosophie
L'offline-first n'est pas une fonctionnalité — c'est une philosophie de conception. Elle impose de renverser la logique habituelle : au lieu de construire une app connectée et d'ajouter un mode hors-ligne comme amélioration, on construit d'abord pour fonctionner sans réseau, et on traite la synchronisation comme une couche additionnelle.
Concrètement, cela implique :
- Service Workers pour la mise en cache des assets et des données critiques
- IndexedDB ou localStorage pour la persistance locale des données utilisateur
- Stratégies de synchronisation — queue d'actions locales à rejouer quand la connexion revient
- Résolution de conflits — que se passe-t-il si deux utilisateurs ont modifié la même donnée hors ligne ?
Ce que Lumio m'a enseigné
Sur Lumio, la plateforme d'initiation à l'informatique pour enfants que je conçois actuellement, j'ai poussé cette logique encore plus loin. L'ensemble du contenu pédagogique — leçons, exercices, quizzes — doit être disponible sans aucune connexion. La synchronisation des progrès se fait en arrière-plan, de manière transparente.
Le défi le plus intéressant : comment concevoir des exercices interactifs (drag-and-drop, labs de code) qui fonctionnent offline sans dépendre de bibliothèques lourdes qui ralentiraient le chargement initial ?
L'interface comme levier d'inclusion
La contrainte technique n'est qu'une partie du problème. L'autre partie est l'interface. Une plateforme EdTech destinée à des enfants de 8-12 ans dans un contexte africain doit être visuellement engageante, intuitive pour des utilisateurs non-numériques, et performante sur des appareils d'entrée de gamme.
Concevoir pour la contrainte, pas contre elle, c'est accepter que la contrainte est une spécification du produit, pas un obstacle. C'est de là que viennent les vrais produits innovants.