Un agrégateur de paiement mauritanien, ce qui doit exister

Après avoir raconté la scène ordinaire d'une vendeuse de Tevragh-Zeina qui perd un client parce que celui-ci n'a pas le bon wallet, puis analysé pourquoi cette fragmentation persiste malgré des années de mobile money mauritanien, il reste à décrire ce qui doit exister. Non pas un catalogue théorique, mais un cahier des charges fonctionnel et technique, une liste de contraintes locales à respecter, et une image concrète de ce que cela changerait pour le pays.

Cet article s'adresse aux commerçants qui veulent enfin accepter les paiements en ligne, aux développeurs qui voudront intégrer ce type de service dans leur produit, et aux confrères de l'écosystème mauritanien qui construisent, eux aussi, des couches d'infrastructure pour notre pays.

Le principe : une seule interface, plusieurs wallets

Le principe de départ est simple, presque évident. Un marchand n'intègre pas quatre wallets un par un. Il intègre une seule interface. Quand un client arrive au moment de payer, la couche d'agrégation lui présente les moyens de paiement disponibles selon ses préférences et la configuration du site, gère le parcours propre à chacun, confirme la transaction, envoie un reçu au marchand et au client, met à jour le back-office.

Le marchand n'a plus qu'à consulter un tableau de bord unique, à voir en clair chaque commande payée, chaque commande en attente, chaque paiement contesté, et à toucher son argent selon un calendrier de reversement défini à l'avance.

Cette promesse tient en une phrase. La construire demande de résoudre trois problèmes techniques : parler à chaque opérateur, confirmer chaque paiement de manière fiable, sécuriser l'ensemble bout en bout. Et un problème humain : accepter que certains choix initiaux ne survivront pas au premier contact avec la réalité mauritanienne.

Parler à chaque opérateur

Les opérateurs de paiement mauritaniens ne se ressemblent pas dans leur ouverture technique. Certains proposent aujourd'hui une interface commerçant utilisable par un tiers dans des conditions industrielles. C'est le cas de BCI Pay, avec un parcours de paiement en ligne clair et des mécanismes de notification qui permettent à un serveur marchand de savoir en temps réel qu'une transaction s'est terminée. C'est aussi le cas de Click, avec ses propres règles et ses propres formats, mais avec une logique comparable de callbacks et de signatures.

Il faut intégrer ces services selon les règles classiques d'une intégration de paiement : conception détaillée du parcours, tests en environnement de bac à sable quand il est disponible, échanges avec les équipes techniques des opérateurs, mise en production progressive, monitoring resserré des premières transactions, ajustements successifs.

D'autres opérateurs n'exposent pas encore d'interface commerçant utilisable par un tiers indépendant dans les conditions dont un marchand a besoin ici. C'est le cas historique de Bankily et de Masrvi. Cela ne signifie pas que ces wallets sont fermés ou hostiles aux commerçants. Cela signifie que les mécanismes d'intégration disponibles étaient conçus pour d'autres usages, souvent bancaires internes, et qu'ils ne permettaient pas à un site en ligne tiers de savoir de manière fiable, en temps réel, qu'un paiement venait d'arriver.

Pendant longtemps, la seule "confirmation de paiement" fiable dont un vendeur mauritanien disposait, dans ces cas-là, c'était le SMS reçu sur son propre téléphone après un transfert. Ce SMS contient tout : le montant, le numéro d'expéditeur, la référence de la transaction, l'horodatage. Il est envoyé de manière quasi instantanée par l'opérateur. Il est vérifiable, il est signé implicitement par la source qui l'émet. Le vendeur, historiquement, le lisait avec les yeux et il validait sa commande à la main.

Une bonne couche d'agrégation prend ce SMS au sérieux comme brique technique. Un vieux téléphone Android bas de gamme, sans grand écran ni caméra, parfaitement adapté à la fonction. La carte SIM du numéro marchand insérée dedans. Le téléphone posé sur un bureau, dans un endroit sûr et avec une connexion internet stable. Une application d'automatisation qui capture chaque SMS entrant et l'envoie, immédiatement, à un point d'entrée sécurisé du serveur.

Ce serveur reçoit le SMS brut, l'analyse, extrait le montant, le numéro d'expéditeur, la référence de la transaction, et met à jour la commande correspondante dans la base. Ce dispositif est simple, peu coûteux, robuste. Il ne remplace pas une interface officielle, il la complète pour les cas où elle n'existe pas encore dans un format exploitable.

Confirmer chaque paiement de manière fiable

Un SMS reçu ne suffit pas à lui seul. Il faut le corréler à une commande précise, faite parfois trente secondes plus tôt, parfois plusieurs minutes plus tard si le client a hésité, avec des montants qui peuvent parfois se ressembler entre plusieurs commandes de la même heure.

Une bonne logique de réconciliation associe le paiement entrant à la bonne commande en fonction de trois éléments : le montant exact, l'horodatage dans une fenêtre raisonnable et le numéro de téléphone du payeur communiqué au moment du checkout. Chaque paiement une fois associé est signé, horodaté et archivé. Un accusé est envoyé au marchand et au client. Les cas ambigus, en pratique très minoritaires mais jamais nuls, sont mis en attente sur un tableau de bord d'exceptions, avec les éléments nécessaires pour qu'un opérateur humain tranche en quelques secondes.

Cette approche a une conséquence importante. Elle oblige à maintenir une rigueur constante sur l'identification du payeur au moment du paiement. Le checkout doit rappeler clairement au client de saisir le numéro exact depuis lequel il fera son transfert. Des vérifications visuelles doivent être ajoutées pour les numéros mal saisis. Des messages d'aide en français simple doivent éviter les erreurs les plus courantes.

Sécuriser l'ensemble

La sécurité d'un service de paiement se joue à plusieurs niveaux. Il faut s'appuyer sur des mécanismes standards, éprouvés, et éviter toute forme d'invention cryptographique maison.

Tous les échanges entre la couche d'agrégation et les sites marchands doivent passer par des signatures HMAC. Chaque site dispose de sa propre clé, chaque appel est signé, chaque réception vérifie la signature. Les webhooks émis vers les marchands portent une signature équivalente, et la documentation insiste pour que les marchands la vérifient à leur tour.

Les données sensibles sont chiffrées au repos, avec les mécanismes que Postgres offre en standard. Les accès à la base sont limités par des politiques d'isolation stricte qui empêchent un compte marchand de voir les données d'un autre marchand, même en cas d'erreur applicative.

Le téléphone d'ingestion SMS ne stocke rien localement. Il transmet et il oublie. En cas de perte ou de vol du terminal, il n'y a pas d'historique de paiements sur l'appareil. Les accès administrateur à la console passent par une authentification renforcée.

Fiabilité plutôt qu'exhaustivité

Un choix produit important à assumer dès le départ : préférer la fiabilité à l'exhaustivité. Il vaut mieux dire honnêtement à un marchand "ces quatre méthodes marchent, vraiment, à chaque commande, avec un taux d'échec proche de zéro" plutôt que d'en afficher six dont deux échouent une fois sur trois pour des raisons qui échappent au contrôle direct de la plateforme.

Un paiement en ligne raté fait beaucoup plus de dégâts, en confiance et en réputation, qu'une méthode absente clairement documentée. Une méthode annexe qui n'atteint pas le standard de fiabilité doit être temporairement désactivée, et ne réintégrer le catalogue que le jour où sa fiabilité correspond au reste.

Contraintes locales, décisions concrètes

Une couche d'agrégation adaptée à la Mauritanie doit répondre à plusieurs contraintes locales concrètes.

La documentation doit être en français, avec des exemples de code testés, un guide pas à pas et une check-list de mise en production. Un environnement de bac à sable doit permettre de simuler les quatre wallets, en montant les cas nominaux et les cas d'erreur.

L'accompagnement humain compte autant que la qualité technique. Chaque nouveau marchand doit être accompagné pendant sa première semaine, avec un canal direct pour les questions, parce que rien ne remplace, dans un pays où l'écosystème technique est encore jeune, un humain qui répond vite et bien à une question qui bloque la première commande.

Pour les marchands qui n'ont pas de développeur, des liens de paiement clé en main doivent être disponibles. Un restaurateur, un coach, un artisan doit pouvoir créer en trois clics un lien à partager sur WhatsApp ou Instagram, sans écrire une ligne de code. Le lien mène à une page de paiement hébergée avec la marque du marchand.

Les quatre expertises qui rendent ce type de plateforme possible

Construire ce type de couche d'agrégation mobilise quatre expertises complémentaires, qui doivent être disponibles au sein d'une même équipe ou de partenaires étroitement coordonnés. La data ingère les SMS, structure les paiements, gère la réconciliation avec les commandes, alimente la comptabilité des marchands et prépare les exports nécessaires en fin de mois. La business intelligence offre aux commerçants et aux dirigeants des tableaux de bord clairs sur leurs ventes, leurs pics d'activité, leurs conversions par wallet, leurs taux d'échec par méthode. L'intelligence artificielle apporte l'analyse anti-fraude, l'extraction robuste de données depuis des SMS aux formats variés selon les opérateurs, la détection d'anomalies et la reconnaissance des patterns de paiement irréguliers. L'automatisation orchestre les webhooks, les notifications, les reversements aux marchands, la relance des paiements en attente, la gestion des exceptions. C'est l'articulation de ces quatre savoir-faire qui fait la différence entre un jouet technique et une infrastructure qu'un cabinet médical, une école ou un restaurant peut adopter sans réserve.

Les cas d'usage que cela ouvre immédiatement

Une bonne couche d'agrégation ouvre immédiatement des cas d'usage qui restaient hors de portée.

Un cabinet médical à Nouakchott peut recevoir les paiements de consultations à distance depuis Aioun, Kaédi, Zouérat. Ses patients de l'intérieur ne se déplacent plus pour un contrôle ou un ajustement de traitement. Ils paient proprement, sans virement bancaire compliqué, sans cash déposé chez un cousin.

Un éditeur de logiciels mauritanien peut vendre des abonnements mensuels au lieu d'annuels. Sans une brique de paiement récurrent fiable, un éditeur local est condamné à vendre en gros ou en gré à gré. Avec cette brique, il peut proposer une formule mensuelle, plus accessible pour le client, plus prévisible pour lui.

Une plateforme de livraison de repas peut demander le paiement à la commande, ce qui met fin au débat entre livreur, restaurateur et client sur qui doit avancer les frais et qui doit rendre la monnaie. Fini aussi le risque de commandes fantômes.

Une école privée peut collecter les frais de scolarité mensuels sans faire la queue devant le bureau de la caissière. Chaque parent reçoit un lien de paiement personnalisé, paie depuis son wallet préféré, et la direction voit en temps réel qui a payé.

Une association humanitaire peut ouvrir une page publique de collecte de dons. La diaspora en Europe, dans le Golfe, en Amérique du Nord, peut contribuer sans passer par un intermédiaire familial. Les reçus horodatés servent de preuve dans les rapports financiers.

Ce que cela ouvre à l'échelle du pays

Quand un pays règle sa friction de paiement en ligne, plusieurs choses se produisent en même temps, parfois sans que l'on s'en rende compte immédiatement.

Le commerce en ligne local cesse d'être un exercice d'héroïsme réservé à quelques passionnés. Une jeune mère qui veut vendre les vêtements qu'elle coud à la maison n'a plus besoin d'un local, d'un carnet de comptes, d'une caisse et d'une négociation quotidienne avec la banque pour ouvrir un compte marchand. Elle peut, en une matinée, mettre en place un lien de paiement, une page produit et un canal de communication, et commencer à vendre le soir même.

Les éditeurs de logiciels mauritaniens peuvent facturer chez eux, en ouguiya, sans envoyer leurs clients chez Stripe ou PayPal, ce qui suppose une carte bancaire internationale que la majorité de nos concitoyens n'ont pas. Cette contrainte a longtemps forcé les éditeurs locaux à vendre en annuel, en espèces, en gré à gré, ce qui limitait mécaniquement leur croissance et rendait leur trésorerie fragile.

Les artisans, les commerçants, les créateurs peuvent recevoir un paiement de la diaspora sans passer par un intermédiaire familial. Ce point est plus important qu'il n'y paraît. Une part importante des flux monétaires vers la Mauritanie est aujourd'hui informelle, gérée par des chaînes de confiance qui fonctionnent parce que la parenté et le voisinage tiennent lieu de contrat.

Les écoles, cabinets, cliniques encaissent proprement, avec des reçus horodatés, une comptabilité à jour, une visibilité en temps réel sur les impayés et une capacité renouvelée à concentrer leurs équipes sur leur métier plutôt que sur la caisse.

Chacun de ces effets, pris isolément, semble modeste. Mis bout à bout, ils changent la texture même de l'économie numérique du pays. Ils créent un marché adressable pour les développeurs mauritaniens, qui peuvent enfin vivre de produits payés localement. Ils légitiment le métier de vendeur en ligne. Ils ouvrent la voie à une comptabilité plus propre pour des dizaines de milliers de petites entreprises. Ils élargissent la base fiscale sans forcer personne.

Une souveraineté numérique de niveau infrastructure

Une couche d'agrégation mauritanienne, opérée par des Mauritaniens, hébergée sur des serveurs qui obéissent au droit mauritanien, documentée en français et en arabe, accessible à un développeur de Nouakchott aussi facilement qu'à un développeur de Paris, c'est un morceau de souveraineté qui compte.

La souveraineté numérique n'est pas un slogan, c'est une somme de choix concrets : qui écrit le code, où vivent les données, qui contrôle les clés de chiffrement, à quelle juridiction on répond en cas de conflit, dans quelle langue on comprend les erreurs, à quel numéro on appelle quand un paiement ne passe pas un samedi soir.

Chaque fois qu'un flux de paiement essentiel passe par un prestataire étranger sans contrôle local, ce sont nos données commerciales qui voyagent vers des juridictions lointaines, notre marge qui s'évapore, notre écosystème local qui s'assèche par manque de commandes, nos développeurs qui n'apprennent pas les subtilités d'une infrastructure critique. Cette perte silencieuse ne se voit pas dans les rapports annuels. Elle se mesure dans l'appauvrissement lent d'un écosystème qui n'accumule pas ses propres compétences.

L'agrégation des paiements marchands mauritaniens, en ouguiya, entre wallets mauritaniens, pour des clients mauritaniens, est un cas d'école où la construction locale est à la fois possible, souhaitable et rentable.

Ce que cela ouvre comme chantiers pour la suite

Une fois la brique de base en place, plusieurs chantiers s'ouvrent naturellement.

Le paiement transfrontalier maghrébin et ouest-africain, aujourd'hui compliqué pour un marchand mauritanien qui vend à un client marocain ou sénégalais, deviendra progressivement praticable. Les briques techniques existent, les accords bilatéraux se construisent.

La facturation d'un service mauritanien par un client de la diaspora se simplifiera. Les Mauritaniens qui vivent à l'étranger pourront régler une école pour un neveu, une consultation médicale pour un parent, un abonnement à un journal local, une contribution à un projet familial, sans passer par des mécanismes informels.

Le microcrédit adossé à un historique de paiements mobile devient possible, sur des bases beaucoup plus saines que le scoring déclaratif d'aujourd'hui. Un commerçant qui a un historique de six mois de ventes régulières est un candidat crédible pour un prêt de trésorerie.

La comptabilité automatisée des petites entreprises trouve enfin des données propres à ingérer. Les logiciels de gestion mauritaniens, jusqu'ici privés de flux structurés, pourront enfin proposer des tableaux de bord, des exports, des déclarations fiscales assistées, sur la base de vraies transactions horodatées.

Ce qu'une couche technique ne fera pas seule

Il faut être honnête sur les limites. Aucune brique n'a la prétention d'être la seule réponse. Un pays où plusieurs agrégateurs coexistent, avec des standards ouverts et une saine concurrence, est un pays qui a résolu son problème pour de bon. Cette concurrence est de loin préférable à un monopole confortable.

Il faut aussi que l'action publique avance. Chaque décision qui facilite l'interopérabilité, ouvre les interfaces, clarifie le cadre juridique des établissements de paiement et sécurise juridiquement les acteurs privés qui investissent, se traduit en emplois pour les jeunes de Nouakchott, en recettes fiscales pour l'État, en indépendance stratégique pour le pays et en confiance pour les investisseurs.

Un appel simple

Si vous êtes commerçant, restaurateur, prestataire, association, école, cabinet, essayez d'accepter les paiements en ligne, même modestement, même sur une partie de votre activité, même en commençant par un lien à partager sur WhatsApp. Ce n'est plus compliqué, ce n'est plus cher, cela ne demande plus d'expertise particulière. C'est même, dans la plupart des cas, la chose qui débloquera votre prochain palier de croissance et qui vous rendra du temps sur votre métier.

Si vous êtes développeur ou éditeur de logiciel, intégrez une brique de paiement mauritanienne dans votre produit et parlez ouguiya dans votre facturation. Vous découvrirez que le marché existe, qu'il est plus grand qu'on ne le dit, qu'il est demandeur.

Un pays de cinq millions d'habitants qui ne sait pas payer en ligne chez lui-même prive sa jeunesse d'un futur. Un pays qui sait le faire, en revanche, ouvre chaque année des dizaines de milliers de possibilités. C'est ce basculement, discret mais réel, qui est aujourd'hui à portée.

Une dernière question

Que ferait la Mauritanie de plus, chaque jour, si personne dans le pays n'avait jamais à se demander comment payer en ligne ?