Ce que le lancement de Yembi m’a appris (et que je n’avais lu nulle part)
Trois mois après le lancement : les leçons concrètes du produit que j’ai porté seul chez DOKAL Technologies pour le marché burkinabè. Distribution, confiance, et le poids du mot « permissions ».
Yembi est sorti en mars. C’est le produit phare de DOKAL Technologies, et j’en ai été le seul ingénieur du premier commit jusqu’au lancement. Trois mois plus tard, voici les leçons que j’aurais aimé lire quelque part avant. Aucune ne figure dans les playbooks de lancement habituels : ce sont des contraintes propres à ce marché, et c’est précisément là que se joue le produit.
1. La permission SMS est votre vrai pitch
Yembi lit les SMS des opérateurs. Techniquement, c’est le cœur du produit. Commercialement, c’est l’objection numéro un. Une app qui demande l’accès aux SMS dans un pays où les arnaques mobiles sont quotidiennes, ça déclenche, légitimement, de la méfiance.
Ce qui a marché : attaquer le sujet de face au lieu de l’enterrer dans une politique de confidentialité. L’app filtre par expéditeur (uniquement les numéros opérateurs), les données restent chiffrées sur le téléphone (SQLCipher), et c’est expliqué avant la demande de permission, en français simple, avec des exemples de SMS. Le taux d’acceptation a nettement progressé une fois l’explication placée avant la demande système plutôt qu’après.
2. La distribution, c’est WhatsApp, pas le Play Store
Le Play Store sert à exister. WhatsApp sert à être installé. Les premières vagues d’utilisateurs sont venues de groupes WhatsApp (famille, collègues, groupes de quartier) où quelqu’un partageait l’app avec un message personnel. Un lien Play Store nu ne convertit pas ; un message de quelqu’un qu’on connaît, si.
Conséquence directe sur le produit : le partage devait être un parcours d’une seule étape, et le message pré-rempli devait expliquer l’app en une phrase de WhatsApp, pas en paragraphe de marketing.
3. L’offline-first n’est pas une contrainte réseau, c’est une ligne sur la facture
J’ai d’abord construit offline-first parce que le réseau est instable. La vraie leçon est venue après : sur ce marché, l’offline-first n’est pas une prouesse technique, c’est une économie pour l’utilisateur.
Ici, la data s’achète par petits forfaits. 100 mégas, 250 mégas. Elle se compte. Une app qui rappelle le serveur à chaque écran, c’est une app qui coûte de l’argent à chaque ouverture. Une app gourmande en données n’est pas « lourde » sur ce marché, elle est chère. La bonne question n’était donc pas « comment survivre à une coupure réseau », mais « combien de mégas ça coûte de l’utiliser une journée ».
Ce que ça change concrètement : tout ce qui peut être lu sans réseau l’est (l’app reste utile, et surtout ne dépense rien) ; on n’envoie au serveur que le strict nécessaire, regroupé, quand le réseau est là, pas un appel par geste ; et la synchro non urgente attend le wifi quand elle peut. Le résultat n’est pas seulement une app qui marche hors-ligne, c’est une app qui ne vide pas un forfait.
Et ça a gagné des utilisateurs que je n’attendais pas : une partie des plus fidèles coupe volontairement les données pour économiser. Pour eux, une app qui fonctionne à 100 % sans connexion, c’est la différence entre l’utiliser tous les jours et la désinstaller. Ils ne sauront jamais nommer ce qu’on a fait. Ils le sentent sur leur facture.
4. Être seul sur un produit impose une discipline d’architecture
Quand on est le seul ingénieur, chaque décision d’architecture est une décision de charge mentale. Le parser config-driven (les formats SMS livrés comme de la donnée, pas du code) n’était pas du luxe : c’est ce qui me permet de réagir à un changement de format Orange en une heure, sans release, sans bloquer le reste de la roadmap.
La règle que j’en tire : seul sur un produit, n’automatisez pas ce qui est rare, automatisez ce qui vous réveille la nuit. Pour moi c’était les formats SMS et la déduplication des syncs. Tout le reste peut rester manuel longtemps.
Bonus inattendu : on vient de recruter un deuxième développeur sur Yembi, et ces mêmes choix sont ce qui a rendu son onboarding simple. L’architecture pensée pour ma charge mentale est devenue de la documentation vivante.
5. Les métriques locales n’ont pas la même hiérarchie
Les métriques classiques (DAU, rétention J30) restent utiles, mais la métrique qui prédit le mieux la rétention de Yembi, c’est le nombre de comptes détectés dans la première heure. Un utilisateur dont les deux SIM sont reconnues et dont l’historique se remplit immédiatement reste. Un utilisateur qui voit un écran vide part. D’où un choix contre-intuitif : le parsing rétroactif de l’historique SMS existant est devenu LA feature d’onboarding, alors qu’elle était prévue « pour plus tard ».
Le fil rouge de tout ça : les contraintes locales ne sont pas des obstacles au produit, elles sont le produit. C’est précisément ce qu’une équipe à distance ne peut pas reproduire sans être sur le terrain.
La suite : je documente en ce moment la V2 du parser et l’ouverture à un troisième opérateur. Si vous construisez pour ce marché, écrivez-moi — j’échange volontiers sur ces sujets.