Dans les coulisses d'Ahidaho : décisions d'architecture derrière le lancement

Lancer Ahidaho le 9 mars 2026 n'était pas un exercice d'interface. C'était un problème d'architecture opérationnelle.

Nous devions livrer une seule plateforme capable de supporter acheteurs, vendeurs, livreurs et admins, chacun avec ses règles, priorités et profils de risque.

Forme de l'architecture

Au lancement, Ahidaho fonctionne avec trois applications connectées et un backend central :

• Marketplace côté client
• Espace opérationnel vendeur et livreur
• Dashboard admin
• API Django avec PostgreSQL, Redis et workers

Cette séparation garde des workflows clairs côté utilisateur tout en conservant une seule source de vérité pour commandes, paiements, confiance et états de cycle de vie.

Réalité paiement : COD + mobile money

Sur ce marché, imposer un seul mode de paiement est une erreur produit.

Ahidaho a été conçue avec deux rails financiers en parallèle :

• Mobile Money (KKiaPay) pour le checkout digital
• Paiement à la livraison pour l'adoption et les comportements d'achat locaux

D'un point de vue ingénierie, cela implique des états de règlement distincts, des événements de vérification, une gestion des écarts et des outils d'allocation admin.

Intégrité de livraison par conception

Le modèle de livraison combine attribution et preuve :

• Flux dispatch/réclamation pour attribuer les livreurs
• Vérification QR ou code à la collecte et à la remise
• Heartbeat du livreur en mode en ligne
• Transitions d'état auditables sur tout le cycle de commande

Cela réduit l'ambiguïté logistique et donne aux équipes d'opérations des points d'intervention avant que les échecs ne deviennent des pertes.

Pourquoi l'architecture bilingue compte

Le bilingue n'a pas été ajouté à la fin. Il a été conçu dans le modèle produit :

• Support anglais et français dans les workflows clés
• Entrées admin compatibles traduction pour le contenu géré
• Interfaces opérationnelles localisées pour chaque rôle utilisateur

Traiter la langue comme une exigence de base est ce qui permet d'envisager une montée en échelle régionale.

Leçon du lancement

La principale leçon d'Ahidaho est simple : un logiciel marketplace réussit quand les opérations sont une couche de premier rang, pas une rustine.

Checkout, dispatch, confiance, finance et contrôles admin doivent être conçus ensemble. Si une couche est faible, tout le système se dégrade.

Ce lancement est une étape, pas l'arrivée. Mais il prouve que le stack et le modèle d'exploitation sont désormais en production.