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-Africa pour le marché burkinabè. Distribution, confiance, et le poids du mot « permissions ».
Yembi est sorti en mars. C’est le produit phare de DOKAL-Africa, 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. Les playbooks de lancement écrits à San Francisco ne couvrent aucun de ces points.
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 changé du tout au tout quand l’explication est passée avant la demande système.
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. Le offline-first a gagné des utilisateurs que je n’attendais pas
J’ai construit offline-first parce que le réseau est instable. Mais une partie des utilisateurs les plus fidèles s’est révélée être… des gens qui coupent volontairement les données mobiles pour économiser leur forfait. Pour eux, une app qui fonctionne à 100 % sans connexion n’est pas un détail technique. C’est la différence entre l’utiliser tous les jours et la désinstaller.
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 copier de loin.
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, je compare volontiers les notes.