SAFIRI
Reprendre une application existante, et faire fonctionner ce qui devait l’être.
SAFIRI est une application de réservation de courses pensée pour la République démocratique du Congo, où les solutions internationales s’adaptent mal aux usages locaux. Je suis intervenu sur un projet déjà commencé : mon rôle a été de le reprendre, d’en refondre des parties structurantes et de le remettre en état de marche.
- Catégorie
- Application mobile de réservation
- Plateformes
- iOS · Android · Web
Le point de départ
Le marché impose des contraintes que les applications de VTC classiques ne prennent pas en charge : le paiement se fait exclusivement en espèces, la devise est le franc congolais, et l’interface doit exister en français, en anglais et en swahili. L’application sert trois publics différents — les passagers, les chauffeurs et l’administration qui pilote la flotte et valide les chauffeurs.
Le point difficile n’est pas de prendre une commande, c’est d’attribuer une course. Il faut la proposer au bon chauffeur, à proximité, lui laisser un délai court pour accepter ou refuser, passer au suivant en cas de refus, et empêcher que deux chauffeurs acceptent la même course. Le tout sans personne pour arbitrer derrière un téléphone.
Ce qui a été construit
L’attribution est traitée côté serveur : la course est proposée à un chauffeur à la fois, du plus proche au plus éloigné, avec un compte à rebours et un passage automatique au suivant en cas de refus. Le téléphone ne décide de rien — il observe et signale. Les tarifs sont pilotés à distance, ce qui permet de les ajuster sans republier l’application, un point important dans un contexte de forte inflation.
Ce que le produit fait
Attribution automatique des courses
La course est proposée au chauffeur disponible le plus proche, avec un délai de réponse court et un passage automatique au suivant. Aucun standard humain n’est nécessaire.
Destination au doigt ou par recherche
Le passager place un point sur la carte ou tape une adresse ; celle-ci est traduite automatiquement en texte lisible.
Quatre catégories de véhicules
Voiture, confort, moto et tuktuk, avec un prix estimé. Une catégorie sans chauffeur à proximité est grisée : le passager ne voit que ce qui est réellement disponible.
Proposition de prix par le passager
Le passager peut proposer un montant inférieur à l’estimation, une pratique courante sur ce marché.
Suivi de la course en temps réel
Passager, chauffeur et serveur suivent le même document : la position affichée au passager est bien celle que le chauffeur transmet.
Messagerie pendant la course
Un fil de discussion réel et persistant entre le passager et son chauffeur.
Revenus du chauffeur
Gains agrégés par jour, semaine, mois et année, calculés à partir des courses réellement effectuées.
Validation des chauffeurs
Les chauffeurs déposent leurs justificatifs ; l’administration les valide ou les refuse pièce par pièce, avec un motif.
Les décisions qui comptent
Décider côté serveur, pas dans le téléphone
L’attribution des courses ne peut pas vivre dans l’application : elle doit fonctionner quand le passager a mis son téléphone en veille, rester indépendante de la version installée, et ne pas pouvoir être contournée. Le serveur est donc seul décideur, et les applications se contentent d’observer et de signaler. C’est ce qui rend l’attribution automatique fiable.
Un délai de vingt secondes sur un système qui ne descend pas sous la minute
Le produit demande une réponse du chauffeur en vingt secondes, alors que le déclencheur programmé côté serveur ne peut pas descendre sous la minute. Plutôt que de construire une infrastructure coûteuse pour ce seul besoin, l’application du chauffeur décompte localement et envoie elle-même le refus à l’expiration, tandis qu’un passage toutes les minutes rattrape les cas où l’application a été fermée. Un compromis assumé, avec sa contrepartie documentée : l’attente peut s’allonger si le chauffeur ne répond pas du tout.
La course porte son propre état
Plutôt qu’un service d’orchestration séparé, tout l’état de l’attribution — la file des chauffeurs candidats, celui à qui la course est proposée, l’heure d’expiration — est stocké sur la course elle-même. Chacun s’abonne à ce document et réagit aux changements. Le système devient lisible et se débogue en regardant une seule donnée, au lieu de reconstituer un échange entre services.
Payer la carte, pas le calcul d’itinéraire
L’affichage cartographique utilise Google Maps, à la demande du client. En revanche, la recherche d’adresses et le calcul des trajets passent par des services ouverts et gratuits. C’est un arbitrage coût/qualité délibéré, rendu possible par une abstraction propre du service de géolocalisation : la qualité d’affichage attendue, sans la facturation associée.
Des tarifs ajustables sans republier
Prix au kilomètre, à la minute, tarif minimum et coefficients par type de véhicule sont stockés à distance plutôt que dans le code. Dans une économie à forte inflation, changer un tarif ne doit pas dépendre d’une mise à jour et d’une validation de store : cela transforme une opération de plusieurs jours en un réglage immédiat.
Comment c’est assemblé
Application Flutter
Trois interfaces — passager, chauffeur, administration — depuis une seule base de code
Cloud Functions
L’attribution des courses décidée côté serveur, jamais par le téléphone
Cloud Firestore
La course elle-même porte son état : tout le monde suit le même document
Remote Config
Les tarifs se règlent à distance, sans republier l’application
Les technologies utilisées
Frontend
- Flutter
- Dart
- Provider
- Google Maps
Backend
- Cloud Functions
- Node.js
Infrastructure
- Firebase
- Cloud Firestore
- Firebase Storage
Services
- Firebase Cloud Messaging
- Remote Config
- OpenStreetMap
- OSRM
Ce qui a été livré
Reprise d’une application existante couvrant trois parcours — passager, chauffeur et administration — depuis une seule base de code. Le cœur métier fonctionne de bout en bout : commande, attribution automatique côté serveur, acceptation par le chauffeur, suivi en temps réel et clôture de la course. Mon intervention a porté sur la conception de l’attribution côté serveur, la migration cartographique sur six écrans, la refonte d’identité et les arbitrages de périmètre. L’application n’est pas publiée sur les stores à ce jour.
- iOS
- Android
- Web
Besoin d’un produit similaire ?
Parlons de ce que vous voulez construire. Je vous réponds personnellement, généralement sous 24 heures.