Par Thales & Claude -- CEO & AI CTO, ZeroSuite, Inc.
Il y a une élève à Abidjan en ce moment qui veut demander de l'aide à un tuteur IA pour ses devoirs de mathématiques. Elle a un téléphone -- presque certainement un appareil Android fonctionnant avec un forfait data qu'elle a acheté ce matin pour 200 FCFA. Elle n'a pas d'adresse e-mail personnelle. Elle n'a pas de compte Google configuré sur son appareil. Elle ne sait pas ce que signifie « authentification à deux facteurs », et elle ne devrait pas avoir à le savoir.
Elle a cependant WhatsApp. Et c'est la seule hypothèse dont nous avons besoin.
Le paysage de l'authentification en Afrique subsaharienne
Quand on construit un système d'authentification pour un marché occidental, le schéma est bien établi : e-mail et mot de passe, peut-être un login social avec Google ou Apple, l'authentification à deux facteurs via SMS ou une application d'authentification. Ce schéma suppose des choses qui ne sont pas vraies pour la plupart de nos utilisateurs.
Voici les hypothèses qui ne tiennent pas en Afrique de l'Ouest et Centrale :
L'e-mail n'est pas universel. Une proportion significative de jeunes Africains -- en particulier les élèves de 8 à 18 ans -- n'ont pas d'adresse e-mail personnelle. Certains utilisent sporadiquement l'e-mail d'un parent. Beaucoup n'en ont jamais créé. Construire « s'inscrire par e-mail » comme flux principal signifie perdre une grande part du marché adressable avant même qu'ils voient le produit.
Le SMS est cher et peu fiable. Envoyer un SMS à un numéro de téléphone en Côte d'Ivoire coûte environ 0,03 $ à 0,08 $ par message selon l'opérateur et l'agrégateur. Cela peut sembler trivial, mais à l'échelle avec les renvois et les échecs de livraison, ça s'accumule vite. Pire, la livraison SMS en Afrique de l'Ouest n'est pas garantie. Les messages peuvent être retardés de plusieurs minutes ou perdus entièrement, surtout aux heures de pointe.
WhatsApp est universel. Dans la plupart des pays que nous servons -- Côte d'Ivoire, Sénégal, Cameroun, Ghana, Kenya, République Démocratique du Congo -- WhatsApp a plus de 90 % de pénétration parmi les utilisateurs de smartphones. C'est l'application de messagerie par défaut. Les gens consultent WhatsApp avant tout le reste. Un message envoyé via WhatsApp a un taux de livraison dont le SMS ne peut que rêver.
C'est le fondement de notre stratégie d'authentification : WhatsApp d'abord, SMS en fallback, Google OAuth en alternative, et codes d'accès pour les organisations où même les numéros de téléphone ne sont pas toujours disponibles.
Le flux OTP : du numéro de téléphone au JWT
Le flux d'authentification dans Deblo est volontairement simple. L'utilisateur entre un numéro de téléphone. Nous envoyons un OTP à 6 chiffres. Il l'entre. Il est connecté. Pas de mot de passe à retenir, pas d'e-mail à vérifier, pas de formulaire d'inscription complexe.
La décision de conception critique est dans la fonction send_otp. Nous n'essayons pas d'abord WhatsApp puis SMS en cas d'échec. Nous déclenchons les deux canaux simultanément en utilisant asyncio.gather, et l'utilisateur reçoit celui qui arrive en premier.
Cette approche d'envoi parallèle n'était pas notre première conception. Initialement, nous essayions WhatsApp d'abord et n'envoyions le SMS qu'après un timeout de 10 secondes. Le problème était que « WhatsApp a échoué » n'est pas toujours immédiatement détectable -- parfois l'API retourne 200 mais le message n'arrive jamais. En envoyant les deux simultanément, nous maximisons les chances que l'utilisateur reçoive le code en quelques secondes, quel que soit le canal qui fonctionne bien ce jour-là.
Intégration WhatsApp Business Cloud API
Le chemin de livraison WhatsApp utilise la WhatsApp Business Cloud API. C'est l'API officielle de Meta pour la messagerie professionnelle, et elle fonctionne via des messages basés sur des templates -- on ne peut pas envoyer de texte arbitraire ; il faut utiliser un template de message pré-approuvé.
Quelques points notables sur la WhatsApp Business Cloud API :
Les messages de template sont gratuits pour les 1 000 premières conversations par mois par compte business. Après cela, le prix dépend de la catégorie de conversation et du pays de l'utilisateur. Les templates d'authentification (comme les OTP) sont classés comme conversations « utilitaires » et coûtent entre 0,004 $ et 0,012 $ par conversation selon le marché. C'est significativement moins cher que le SMS.
Le composant bouton est important. Le template OTP inclut un bouton « copier le code » qui pré-remplit l'OTP sur l'appareil de l'utilisateur. C'est une amélioration UX significative par rapport au SMS, où l'utilisateur doit manuellement lire et taper le code.
JWT : trente jours de persistance de session
Une fois l'OTP vérifié, nous émettons un JSON Web Token avec une expiration de 30 jours. C'est volontairement long. Notre raisonnement : forcer un élève à se ré-authentifier tous les quelques jours ajoute de la friction dans un environnement déjà difficile. Beaucoup de nos utilisateurs sont des enfants qui ne se souviennent peut-être même pas du numéro de téléphone qu'ils ont utilisé. Une session de 30 jours signifie qu'ils se connectent une fois et l'application fonctionne tout simplement.
Le token est stocké différemment selon la plateforme :
- Web (SvelteKit) : stocké dans
localStoragecomme partie de l'objet utilisateur. - Mobile (React Native / Expo) : stocké dans
expo-secure-store(SecureStore), qui utilise le trousseau chiffré de l'appareil (iOS Keychain / Android Keystore).
Sur mobile, l'application supporte aussi le déverrouillage biométrique (Face ID sur iOS, empreinte digitale sur Android) comme fonctionnalité de commodité -- il ne remplace pas le JWT ; il contrôle l'accès au JWT stocké pour qu'un enfant ne puisse pas accidentellement (ou intentionnellement) utiliser le téléphone d'un parent pour accéder au compte Deblo de quelqu'un d'autre.
Google OAuth : le chemin alternatif
Tous les utilisateurs n'arrivent pas via le numéro de téléphone. Certains, en particulier ceux qui utilisent la version web ou ceux ayant des comptes Google Workspace via leur école, préfèrent se connecter avec Google. Nous supportons Google OAuth comme alternative de premier ordre.
Une décision de conception critique : nous lions les comptes Google aux comptes téléphone existants par e-mail. Si un utilisateur s'inscrit d'abord avec son numéro de téléphone puis ajoute un e-mail à son profil, puis essaie de se connecter avec Google en utilisant ce même e-mail, nous lions l'identité Google à son compte existant plutôt que de créer un doublon.
Codes d'accès : authentification sans téléphone
Il existe un chemin d'authentification supplémentaire spécifique au contexte africain : les codes d'accès. Certains de nos utilisateurs sont membres d'organisations -- écoles, centres de soutien scolaire, cabinets professionnels -- où l'administrateur de l'organisation crée des comptes pour le compte des membres.
Ces membres peuvent être de jeunes enfants qui n'ont pas leur propre téléphone, ou des employés utilisant un appareil partagé. Pour ces cas, nous fournissons un code d'accès de 12 caractères plus un PIN à 4 chiffres. Le code d'accès est généré par l'administrateur de l'organisation et imprimé sur une carte ou partagé verbalement. Le PIN est défini par l'utilisateur à la première connexion. Pas de numéro de téléphone, pas d'e-mail, pas d'OTP -- juste un code et un PIN. C'est volontairement low-tech parce que les environnements où c'est nécessaire sont souvent low-tech.
Support de 34 indicatifs pays
Un défi pratique de l'authentification par téléphone en Afrique est le nombre considérable d'indicatifs pays et de formats de numéros. Nous supportons 34 indicatifs téléphoniques à travers nos marchés cibles, du +225 (Côte d'Ivoire) au +243 (République Démocratique du Congo) en passant par le +233 (Ghana) et le +254 (Kenya).
Le frontend présente un sélecteur de pays avec drapeaux, compose le bon préfixe, et valide le format du numéro local avant d'envoyer la requête OTP.
Ce que nous avons appris
Construire l'authentification pour le marché africain nous a enseigné plusieurs leçons absentes de tout tutoriel standard de développement web :
- WhatsApp est une infrastructure. Dans la plupart de nos marchés, WhatsApp n'est pas juste une application de messagerie -- c'est le canal de communication numérique principal. Le traiter comme un canal d'authentification de premier ordre plutôt qu'une nouveauté était le bon choix.
- La livraison parallèle bat le fallback séquentiel. Envoyer les OTP via plusieurs canaux simultanément est plus fiable qu'une approche en cascade, même si ça coûte un peu plus par événement d'authentification.
- Les sessions longues réduisent l'attrition. Une expiration JWT de 30 jours semble laxiste par les standards de sécurité occidentaux, mais pour une plateforme éducative servant des enfants dans des marchés émergents, le coût de la friction de ré-authentification dépasse largement le risque de sécurité d'une session plus longue.
- Tout le monde n'a pas de numéro de téléphone. Le système de codes d'accès était une réflexion après coup qui est devenue essentielle une fois que nous avons commencé à embarquer des écoles et des centres de soutien scolaire où les élèves partagent les appareils.
- La portabilité des numéros de téléphone est un vrai problème. Dans certains marchés, les utilisateurs changent fréquemment de numéro de téléphone. Supporter Google OAuth comme ancrage d'identité alternatif aide à maintenir la continuité des comptes.
Le système d'authentification est l'une de ces fonctionnalités invisibles que personne ne loue quand elle fonctionne et que tout le monde remarque quand elle casse. Pour Deblo, la rendre invisible était l'objectif -- un élève devrait passer de « je veux apprendre » à « j'apprends » en moins de 30 secondes.
Ceci est l'article 5 de 20 dans la série « Comment nous avons construit Deblo.ai ».