UMOJA DS · Mobilité
Tugo
Réserver un trajet et le payer en Mobile Money, depuis n'importe quel téléphone.
- Mon rôle
- Responsable technique — architecture, paiements, infrastructure
- Période
- 2024 — 2026
- Pour quel pays
- Cameroun · Belgique
- Lien
- Site en ligne
Tugo est une plateforme de mobilité : on réserve un trajet, on choisit une disponibilité, on paie avec son compte Mobile Money. Web, Android et iOS partagent la même API. J'en suis le référent technique depuis 2024 : architecture, choix de stack, intégration des paiements, infrastructure et coordination des équipes.
Le problème.
En Afrique centrale, la carte bancaire n'est pas le moyen de paiement par défaut — le Mobile Money l'est. Une plateforme de réservation qui ne sait pas encaisser via MTN MoMo ou Orange Money ne sert à rien sur ce marché. Il fallait donc un parcours de réservation où le paiement est une étape native et fiable, pas une pièce rapportée, et une infrastructure capable d'absorber les pics de trafic sans équipe d'astreinte pléthorique.
Précisément, voici ma contribution sur ce projet.
Ce que j'ai fait
- 01
Architecture et choix technologiques
J'ai défini l'architecture de la plateforme : une API REST unique qui sert le web comme le mobile, un modèle de données pour les trajets, les disponibilités et les réservations, et le découpage en services. C'est moi qui tranche les choix de stack et qui les documente pour que l'équipe s'aligne dessus.
- 02
Moteur de réservation et de disponibilités
J'ai conçu le module qui gère les trajets, les créneaux et les places restantes — la partie où les conditions de course font le plus de dégâts. Réservation, modification, annulation et libération des places passent par des règles serveur centralisées plutôt que par la confiance dans le client.
- 03
Intégration des paiements Mobile Money
J'ai branché les agrégateurs Mobile Money (CinetPay, MonetBil) sur le parcours de réservation : initiation du paiement, écoute des webhooks de confirmation, réconciliation des transactions, et gestion des cas tordus — paiement confirmé après expiration du panier, double notification, échec silencieux de l'opérateur. Une réservation n'est validée que lorsque l'argent est réellement confirmé côté opérateur.
- 04
Applications web, Android et iOS
J'ai piloté la déclinaison du produit sur trois supports à partir d'une même API : un front Next.js et des applications React Native Android et iOS, avec des composants et des règles métier partagés pour éviter que les plateformes divergent.
- 05
Infrastructure cloud-native et CI/CD
J'ai conteneurisé les services avec Docker, orchestré le tout sur Kubernetes (GKE) chez GCP, et mis en place les pipelines GitLab CI/CD : build, tests, images versionnées et déploiement automatisé. Les mises en production sont devenues une formalité au lieu d'un événement.
- 06
Encadrement des équipes
Je coordonne les équipes backend, frontend et produit : découpage des chantiers, revues de code, documentation technique et arbitrages quand le calendrier et la qualité s'opposent.
Où ce produit vit, et d'où il a été construit.
Pour quel pays
Le produit sert le marché camerounais, où le Mobile Money est le moyen de paiement dominant. L'équipe et le pilotage, eux, sont répartis entre Yaoundé et la Belgique — une organisation distribuée qui a façonné autant l'architecture que les process.
Cameroun
Yaoundé
3.85°, 11.50°
Belgique
Bruxelles
50.85°, 4.35°
Cameroun · Belgique
La stack.
Frontend
- Next.js
- React Native
- TypeScript
- Tailwind CSS
Backend
- Node.js
- API REST
- PostgreSQL
Paiement
- Mobile Money
- CinetPay
- MonetBil
- Webhooks
Infra
- Docker
- Kubernetes (GKE)
- GCP
- GitLab CI/CD
Ce que ça a donné.
Un produit en production sur trois plateformes — web, Android et iOS — alimenté par une seule API.
Le paiement Mobile Money traité comme un parcours critique : confirmation asynchrone, réconciliation, reprise sur échec.
Des déploiements automatisés sur Kubernetes, reproductibles et sans intervention manuelle.