GasyMove / TucTuc

Quel problème GasyMove résout-il ?

Un service de TucTuc à Madagascar réunit trois populations aux besoins opposés : le passager qui commande, le chauffeur qui accepte, l'exploitant qui supervise. À quoi s'ajoute, côté livraison, le restaurant qui reçoit les commandes.

Aucune de ces quatre vues ne peut attendre. Une course, une commande, un paiement : tout est temps réel ou n'a aucune valeur.

Quelles contraintes locales fallait-il gérer ?

Le paiement. Ni carte ni compte bancaire pour la majorité des utilisateurs. Le moyen réel est le Mobile Money — MVola, Orange Money, Airtel Money — agrégé via Efaina. Trois opérateurs, trois comportements, des confirmations asynchrones et des états intermédiaires qu'il faut rendre explicites plutôt que traiter comme des erreurs.

Le réseau. Un chauffeur perd sa connexion en circulant. L'application doit rester utilisable et se resynchroniser, pas afficher une erreur et perdre la course.

Le KYC. Un exploitant de transport est responsable de ses chauffeurs. La validation des pièces est une file de travail, pas une case à cocher.

Comment GasyMove est-il architecturé ?

Flutter avec Firebase, un seul binaire pour deux rôles très différents. Les règles de sécurité Firestore portent la séparation passager/chauffeur : un rôle mal cloisonné côté client seul serait contournable en quelques minutes.

Firestore en écoute temps réel pour l'état des courses et des commandes, plutôt qu'un polling qui viderait la batterie et le forfait data.

Deux dashboards web séparés en Next.js 16 et TypeScript : l'administration (KPI chauffeurs, courses, revenus, file KYC, transactions) et le tableau restaurant, qui a son propre rythme et son propre public.

Qu'est-ce que GasyMove m'a appris ?

Concevoir pour un marché qu'on ne connaît pas de l'intérieur oblige à une discipline simple : ne jamais supposer l'infrastructure. Ni le réseau, ni le moyen de paiement, ni l'appareil. Chaque hypothèse implicite finit par se payer sur le terrain.