Il y a quelque chose d'inconfortable dans le fait de construire un produit pour un marché que tout le monde autour de toi connaît, mais que personne n'a encore vraiment servi. C'est exactement ce qu'on a vécu avec SARO.
SARO est une plateforme intélligente de suivi scolaire pensée pour les établissements secondaires camerounais. Pas une adaptation d'un outil occidental. Pas un "MVP rapide" pour tester un marché. Une solution construite à partir des vrais problèmes : les cahiers de texte perdus, les résultats communiqués par voie orale, les directeurs qui pilotent leur école à l'intuition.
Aujourd'hui, SARO est en phase de tests dans des établissements pilotes. On n'a pas encore "réussi" — mais on a déjà beaucoup appris. Voici ce qu'on aurait aimé savoir avant de commencer.
1. Le vrai produit, c'est la confiance
On a passé du temps à concevoir des fonctionnalités : tableaux de bord, bulletins numériques, gestion des absences. Ce n'était pas du temps perdu. Mais la première vraie barrière n'était pas technique.
Quand on a présenté SARO à des proviseurs, la question qu'on entendait le plus souvent n'était pas "comment ça marche ?". C'était "pourquoi on vous ferait confiance ?"
Une école, c'est un monde fermé. Les données des élèves sont sensibles. Les habitudes sont ancrées. Et une startup inconnue qui arrive avec un ordinateur et une présentation PowerPoint, ça ne rassure pas spontanément.
La leçon : Avant de vendre un produit, on doit vendre une relation. On a commencé à passer plus de temps dans les établissements, à écouter, à poser des questions sans pitcher. C'est seulement après que les portes ont commencé à s'ouvrir.
2. Le "bon sens" du marché occidental ne s'importe pas
On avait une hypothèse de départ : les établissements camerounais allaient vouloir un système de paiement en ligne intégré pour les frais de scolarité. C'est ce que font les EdTechs modernes, non ?
Faux, pour notre contexte.
La grande majorité des parents ne paient pas en ligne. Beaucoup n'ont pas de smartphone. Et ceux qui en ont utilisent Mobile Money — mais pas de la manière fluide qu'on imagine depuis un bureau. Le paiement reste souvent un acte physique, social, parfois négocié.
On a failli construire une brique entière autour d'une hypothèse qu'on n'avait jamais validée sur le terrain.
La leçon : Chaque fonctionnalité doit être précédée d'une observation. Pas d'un sondage. Une vraie observation. Aller voir comment les choses se passent aujourd'hui, sans les juger.
3. La "simplicité" est relative
On pensait avoir fait simple. Interface épurée, parcours court, pas de superflu. Et pourtant, lors des premières démonstrations, on a vu des enseignants hésiter devant des écrans qu'on trouvait évidents.
Ce n'est pas une question d'intelligence. C'est une question d'habitude. Beaucoup de nos utilisateurs cibles n'ont pas l'habitude des interfaces numériques au quotidien. Un bouton qu'on trouve intuitif peut être invisible pour quelqu'un qui n'a jamais utilisé ce type d'outil.
On a revu notre conception de l'UX à plusieurs reprises. Moins de clics, des libellés plus explicites, des confirmations visuelles plus claires.
La leçon : "Simple" n'est pas un état absolu. C'est toujours simple pour qui. On doit concevoir pour nos utilisateurs réels, pas pour nos utilisateurs imaginaires.
4. Un établissement pilote, ça s'accompagne — ça ne se livre pas
On avait l'image du SaaS classique : déployer, former, laisser tourner. On a vite compris que cette vision ne colle pas à notre réalité.
Les établissements pilotes ont besoin d'être accompagnés dans la durée. Pas parce qu'ils sont incapables, mais parce que le changement d'habitude prend du temps. Un outil qui n'est pas utilisé la première semaine risque de ne jamais être adopté, même s'il est excellent.
On a mis en place des points de suivi réguliers. On répond aux questions rapidement. On note chaque retour, même anecdotique. C'est chronophage — mais c'est ce qui fait la différence entre un outil qu'on tolère et un outil qu'on défend.
La leçon : En phase d'adoption, le support est un produit à part entière. Sous-estimer cet effort, c'est saboter le déploiement.
5. Construire en Afrique, c'est un avantage compétitif — si on l'assume
Il y a une tentation de vouloir ressembler aux startups qu'on voit depuis l'étranger. Interfaces anglaises, discours globaux, métriques en dollars. Comme si être "local" était une faiblesse à compenser.
On a pris le contre-pied.
SARO est pensé pour le Cameroun. Les libellés sont adaptés au système éducatif camerounais. Les flux correspondent aux réalités administratives locales. On parle à nos utilisateurs dans leur langue — littéralement et culturellement.
Et c'est précisément ce qui nous distingue. Aucune solution internationale ne peut faire ça aussi bien que nous, parce qu'aucune ne vit ici.
La leçon : La proximité est une compétence. La comprendre profondément, c'est notre avantage concurrentiel le plus durable.
Et maintenant ?
SARO est encore jeune. Les tests pilotes nous donnent des retours précieux, parfois flatteurs, parfois qui font mal. On itère. On corrige. On recommence.
Ce qu'on sait, c'est qu'on construit quelque chose qui manquait — pas par intuition, mais parce que des directeurs d'établissement nous l'ont dit eux-mêmes.
C'est peut-être la leçon la plus importante : le meilleur signal que ton produit a du sens, c'est quand tes utilisateurs commencent à le défendre à ta place.
On n'en est pas encore là. Mais on y travaille.