Vendre en Afrique de l’Ouest : ce que votre plateforme doit prévoir

Une plateforme conçue pour un marché européen fonctionne techniquement en Afrique de l'Ouest. Elle ne vend pas, ou peu, et l'explication tient rarement au produit : elle tient à quatre décisions prises — ou non prises — avant le développement.

Aucune des quatre n'est technique. Ce sont des choix contractuels et financiers, et ce sont eux qui déterminent ensuite l'architecture. Les prendre après coup revient à reconstruire le tunnel de commande.

Pourquoi la carte bancaire ne suffit pas

Dans la plupart des pays de la région, le paiement mobile — un compte adossé à un numéro de téléphone, alimenté en espèces chez un agent de proximité — est le moyen de paiement électronique dominant. Il ne s'agit pas d'une alternative à la carte : pour une grande partie des acheteurs, il n'y a pas de carte.

Une plateforme qui ne propose que la carte n'offre donc pas un choix restreint ; elle n'offre pas de moyen de payer. C'est le point de rupture le plus courant, et le plus coûteux, parce qu'il se produit à la dernière étape, après tout le travail d'acquisition.

Deux conséquences pratiques suivent, souvent négligées. Le paiement mobile s'effectue en plusieurs étapes hors de votre site — l'acheteur reçoit une demande sur son téléphone, saisit un code, confirme —, ce qui suppose une page d'attente et une confirmation qui n'arrive pas immédiatement. Et l'acheteur peut abandonner à chaque étape sans que votre site en soit informé : il faut donc interroger l'état de la transaction plutôt que de l'attendre.

Décision 1 — agrégateur ou intégration directe

Chaque opérateur de paiement mobile expose sa propre interface technique, avec ses règles et sa convention commerciale. Deux voies s'offrent à vous, et aucune n'est meilleure dans l'absolu.

	Agrégateur	Intégration directe
Ce que vous intégrez	Une seule interface, plusieurs opérateurs derrière	Une interface par opérateur
Contrats à signer	Un	Un par opérateur, et par pays
Délai de mise en route	Court	Long, dépend de chaque validation
Coût par transaction	Plus élevé : la commission de l'agrégateur s'ajoute	Plus faible
Dépendance	Un intermédiaire de plus dans la chaîne	Autant de relations à entretenir

La règle empirique : l'agrégateur convient pour démarrer, pour tester un marché, ou quand plusieurs pays sont visés d'emblée. L'intégration directe devient intéressante quand le volume rend la différence de commission significative — et cela se calcule, avec vos propres chiffres.

Un point à vérifier dans les deux cas : la couverture réelle par pays. Un agrégateur qui « couvre l'Afrique de l'Ouest » ne couvre pas nécessairement l'opérateur dominant du pays qui vous intéresse. Le marché n'est pas homogène : chaque pays a ses opérateurs, sa réglementation et ses habitudes.

Décision 2 — le délai de reversement

L'argent encaissé n'est pas l'argent disponible. Entre le paiement du client et le virement sur votre compte s'écoule un délai, propre à chaque prestataire et à chaque contrat, auquel s'ajoutent les questions de devise et de rapatriement si votre société est établie ailleurs.

Ce délai a trois conséquences directes sur votre trésorerie, et elles doivent être connues avant de fixer vos conditions commerciales :

• Quand expédiez-vous ? À la confirmation du paiement, ou à sa réception effective ? Les deux réponses sont défendables, mais la seconde allonge le délai perçu par le client.
• Comment gérez-vous un remboursement demandé avant le reversement, donc sur de l'argent que vous n'avez pas encore ?
• Dans quelle devise êtes-vous reversé, et qui supporte le risque de change ?

Les taux de commission et les délais varient d'un contrat à l'autre, et se négocient au volume. C'est pourquoi aucun chiffre ne figure ici : le seul chiffre utile est celui que votre propre proposition contractuelle mentionne.

Décision 3 — les paiements en échec

Les échecs sont plus fréquents qu'avec la carte, et pour des raisons souvent banales : solde insuffisant, code de confirmation expiré, plafond de transaction atteint, réseau coupé pendant l'opération.

Ce qui distingue une plateforme utilisable d'une autre n'est pas le taux d'échec — vous ne le maîtrisez pas — mais ce que le site affiche ensuite. Trois exigences :

• Un message qui dit quoi faire. « Paiement refusé » n'aide personne. « Le solde de votre compte mobile est insuffisant, rechargez puis réessayez » évite un abandon.
• La commande conservée. L'acheteur doit retrouver son panier et reprendre là où il s'était arrêté, sans tout ressaisir.
• Le double débit traité explicitement. Il arrive qu'un client soit débité alors que la confirmation ne parvient jamais à votre site. Il faut une procédure de vérification et de régularisation, et une adresse à laquelle le signaler. Sans cela, chaque cas devient un litige.

Décision 4 — le rapprochement comptable

C'est le point le plus discret et celui qui devient ingérable le plus vite. Chaque transaction opérateur porte une référence ; chaque commande porte la sienne. Si rien ne relie les deux automatiquement, quelqu'un les rapproche à la main — et cette personne y passera de plus en plus de temps à mesure que le volume monte.

Deux règles suffisent, à condition d'être posées dès le départ. La référence de votre commande doit être transmise à l'opérateur et figurer dans son relevé ; et la référence de transaction retournée doit être enregistrée avec la commande. Cela paraît évident, et c'est régulièrement omis : le tunnel de commande fonctionne parfaitement sans, et le problème n'apparaît qu'à la première clôture comptable.

Un paiement qu'on ne peut pas rattacher à une commande n'est pas un paiement encaissé : c'est une ligne à justifier.

Concevoir pour des réseaux contraints

Trois exigences, qui améliorent d'ailleurs la plateforme partout ailleurs.

Le poids des pages. Sur une connexion mobile facturée au volume, chaque mégaoctet inutile est une dépense pour l'acheteur. Le tunnel de commande doit être le parcours le plus léger du site, pas le plus riche.

La reprise après coupure. Une connexion qui tombe pendant le paiement ne doit pas perdre la commande. L'état doit vivre côté serveur, jamais uniquement dans le navigateur.

La confirmation asynchrone. Ne faites pas dépendre la validation de la présence du client sur votre page. La notification de l'opérateur doit pouvoir arriver plus tard, et la commande se valider seule — l'acheteur ayant déjà fermé son navigateur.

Les questions à poser avant de choisir

1. Quels opérateurs, dans quels pays exactement, et avec quelle couverture réelle ?
2. Quel délai entre l'encaissement et le reversement, et dans quelle devise ?
3. Comment se déclenche un remboursement, et sous quel délai ?
4. Existe-t-il un environnement de test complet, avec simulation des échecs et pas seulement des succès ?
5. Que contient le relevé de transactions, et puis-je l'exporter dans un format exploitable par ma comptabilité ?
6. Quelle est la procédure en cas de double débit, et qui la prend en charge ?

La quatrième question est celle qui départage le plus souvent. Un prestataire dont l'environnement de test ne simule que les succès vous fera découvrir la moitié des cas en production, sur de vraies commandes.

Une remarque sur notre position

Nous développons depuis Lomé, et les contraintes décrites ici sont celles que nous rencontrons sur nos propres projets — pas une lecture d'étude de marché. C'est la seule raison pour laquelle cet article existe, et c'est aussi la seule fois où nous le mentionnons.

Notre page Développement Web & Mobile couvre la construction de ces plateformes. Si vous en êtes au chiffrage, décrivez votre projet : les quatre décisions ci-dessus changent l'estimation davantage que le nombre de pages.