DEV Community: thibaudlepan77-svg

Rapprocher des paiements Wave et Orange Money quand le payeur n'est pas le client

thibaudlepan77-svg — Mon, 19 Oct 2026 10:20:10 +0000

Le versement qui n'a pas de nom

Un client écrit à vingt-deux heures avec une capture d'écran Wave et demande pourquoi il reçoit encore une relance. Le gérant ouvre l'application, cherche le montant, remonte trois jours de transactions, et n'est toujours pas certain que ce versement corresponde bien à cette facture. Voilà le point de départ des rapprochements de paiements que nous concevons pour des entreprises d'Afrique de l'Ouest, et la difficulté réelle n'est pas celle que l'on imagine en lisant l'énoncé.

Sur un relevé mobile money, le payeur n'apparaît pas sous le nom que porte la facture, il apparaît sous un numéro de téléphone, et souvent ce numéro n'est pas le sien, c'est celui de son épouse, de son apprenti, du chauffeur envoyé récupérer la commande ou du cousin qui avait du solde ce jour-là. Le caissier sait de tête que tel numéro correspond à tel restaurant de Ouakam, jusqu'au jour où il est absent, et ce savoir non écrit est la vraie raison pour laquelle personne d'autre que lui ne peut faire le pointage. Toute la conception tient dans ce constat, il faut sortir ce carnet mental d'une seule tête, sans prétendre le deviner à sa place.

L'entrée par fichier déposé, et ce qu'elle coûte

Le premier arbitrage porte sur la façon dont les données entrent. Nous aurions préféré un accès direct aux transactions, un flux qui pousse chaque encaissement dès qu'il tombe. Dans la majorité des dossiers, cet accès n'existe pas pour l'entreprise, ni du côté de l'opérateur mobile, ni du côté de la banque dont le relevé arrive en fin de mois avec des virements groupés et des intitulés que personne ne reconnaît. Nous avons donc écarté l'intégration applicative comme condition de démarrage, et nous construisons sur ce que le dirigeant peut déjà sortir lui-même, l'export du tableau de bord Wave Business, le relevé Orange Money, le relevé bancaire, en tableur ou en PDF.

Le fichier est déposé dans un dossier partagé ou envoyé à une adresse dédiée, puis il est lu, daté et conservé tel quel, sans jamais être réécrit. Ce choix a un prix et nous le disons. Le rapprochement n'est pas instantané, il suit le rythme des dépôts, et il dépend d'un geste humain que l'on peut oublier. En échange, il survit à une connexion qui tombe au milieu de l'après-midi, il ne casse pas quand un opérateur change son interface, il laisse toujours la pièce brute à montrer au comptable ou au client, et il fonctionne dès le premier jour plutôt qu'après des semaines de démarches. Quand un accès direct devient disponible, il se branche derrière la même chaîne et plus personne ne dépose rien, mais la chaîne n'aura jamais été suspendue à cette ouverture.

Un format commun avant toute comparaison

Les trois relevés ne se ressemblent pas. Wave Business donne un horodatage, un montant, des frais et un numéro de téléphone. Orange Money présente les mêmes informations autrement, avec ses propres libellés. Le relevé bancaire parle une troisième langue. Pendant ce temps les factures vivent dans un classeur Excel, dans un Google Sheets partagé ou dans un logiciel de facturation, et c'est là qu'il faut aller les lire plutôt que de demander à l'entreprise de changer d'outil, un chantier qui se décide pour d'autres raisons que le pointage des paiements.

La deuxième décision consiste à ne rien rapprocher avant d'avoir ramené chaque ligne, d'où qu'elle vienne, à la même forme, une date et une heure, un montant reçu, les frais retenus, le canal, le numéro du payeur, la référence de transaction et le libellé d'origine. C'est le travail ingrat de la chaîne et c'est lui qui rend tout le reste possible. La référence de transaction y joue un rôle particulier, elle sert de clé d'unicité, parce que les doublons d'export sont fréquents dès que l'on télécharge deux fois le même relevé sur des périodes qui se chevauchent.

Nous avons aussi écarté une tentation, celle de normaliser les noms de payeurs pour les rapprocher par ressemblance. Sur un relevé mobile money il n'y a pas de nom fiable à comparer, et une correspondance approximative sur un identifiant faible produit des erreurs silencieuses, c'est-à-dire la pire catégorie d'erreurs quand le résultat finit en comptabilité.

Des règles ordonnées, de la plus sûre à la plus souple

Le moteur essaie les règles dans un ordre explicite plutôt que de calculer un score global. D'abord la référence de facture citée dans le motif du paiement, qui ne laisse aucun doute. Puis le numéro de téléphone déjà associé à un client dans le carnet de correspondances. Puis le montant exact d'une facture ouverte dans une fenêtre de quelques jours. Puis les combinaisons, plusieurs versements qui font ensemble le total d'une facture, ou un versement qui couvre deux factures du même client. Chaque rapprochement porte une mention de confiance qui dit par quelle règle il a été obtenu.

Un score unique aurait été plus élégant à écrire et plus court à maintenir. Nous l'avons écarté parce qu'il est inexplicable au comptoir. Un gérant doit pouvoir lire pourquoi la machine propose cette association, et un ordre de règles se raconte en une phrase là où une pondération ne se raconte pas.

Ce qui ne tombe pas juste n'est jamais deviné, cela part dans une file triée par type.

un versement reçu sans facture correspondante
une facture échue sans versement
un montant inférieur ou supérieur au dû
un numéro de payeur encore inconnu
un paiement arrivé après un avoir

La file reste courte parce qu'elle est vidée chaque jour plutôt qu'une fois par mois, et le point du matin part sur WhatsApp ou par mail, parce que c'est là que le dirigeant lit réellement ses messages.

Les frais retenus méritent leur propre règle. Le montant facturé et le montant effectivement reçu sont suivis séparément, avec les frais entre les deux, et une facture dont il ne manque que la part des frais n'est pas comptée comme un impayé tant que l'écart tient dans la tolérance fixée par l'entreprise. Au-delà de cette tolérance, l'écart remonte, parce qu'un manquant inhabituel n'est pas toujours un frais.

Ce que nous avons constaté, et ce qui reste limité

Avant toute mise en service, nous rejouons les règles sur des mois passés dont le résultat est déjà connu, puis nous comparons ligne à ligne avec le pointage fait à la main. Ce sont les désaccords qui enseignent, ils révèlent soit une règle trop large, soit une erreur ancienne que personne n'avait vue. Ensuite la chaîne tourne en parallèle de la méthode existante, et l'ancienne façon de faire n'est abandonnée que lorsque les deux disent la même chose.

Les limites sont nettes. Un versement sans référence, venu d'un numéro inconnu, pour un montant qui ne correspond à aucune facture ouverte, reste indécidable, et il doit le rester. Le carnet de correspondances démarre vide, donc les premières semaines demandent plus de confirmations que les suivantes, chaque confirmation étant mémorisée pour que le versement suivant se rattache seul. Si les factures ne sont aujourd'hui écrites nulle part de façon exploitable, il n'y a rien à comparer et le chantier commence ailleurs. Et la capture d'écran envoyée sur WhatsApp ne prouve rien par elle-même, la preuve est la ligne du relevé de l'opérateur avec sa référence de transaction, ce qui évite aussi à un vendeur de juger seul une image sur un téléphone.

La validation humaine est le dernier maillon

Rien ne part sans qu'une personne de l'entreprise ait tranché. Elle arbitre les écarts et les rapprochements incertains, elle valide les associations nouvelles entre un numéro de téléphone et un client, elle confirme avant qu'une facture passe en payée. La machine prépare, propose et montre sur quoi elle s'appuie. Elle ne solde jamais un écart d'elle-même, ne déclare payée une facture sur un rapprochement douteux, n'envoie aucune relance et n'écrit rien dans la comptabilité sans accord.

Ce point n'est pas une précaution de façade, il découle de l'architecture. Une chaîne qui classe ses incertitudes au lieu de les masquer n'a besoin d'un humain que sur la marge, et c'est précisément là que son jugement vaut quelque chose. Si vous construisez ce genre de rapprochement ailleurs sur le continent, la première question à poser n'est pas celle de l'outil, c'est celle du carnet, qui sait aujourd'hui, dans l'entreprise, que ce numéro est ce client, et que se passe-t-il le jour où cette personne n'est pas là.

Relancer des factures impayées au Sénégal, l'architecture derrière un rappel poli

thibaudlepan77-svg — Mon, 05 Oct 2026 19:08:42 +0000

Le problème réel arrive avant la relance

Quand une entreprise du Sénégal nous décrit sa relance d'impayés, la demande arrive presque toujours sous la forme d'un envoi de messages, parce que c'est la partie visible, celle qui manque et qu'on aimerait voir partir seule. Nous avons appris à ne pas commencer par là. Dans la plupart des organisations, la relance n'est le travail de personne en particulier, le dirigeant y pense le soir, la comptabilité s'en occupe une fois la clôture finie, le commercial n'ose pas écrire à un client qu'il veut garder, si bien que la facture glisse d'une semaine à l'autre jusqu'à ce que le client la range lui aussi en bas de sa pile.

Mais le frein qui bloque vraiment un projet d'automatisation n'est pas la rédaction du message, c'est le paiement qu'on ne voit pas. Relancer un client qui a déjà réglé est le faux pas le plus coûteux, parce qu'il abîme une relation que la facture ne valait pas, et c'est exactement ce qui se produit quand les paiements mobiles, les virements et les commandes ne sont pas rapprochés. Beaucoup d'équipes préfèrent donc ne relancer personne plutôt que de risquer ce message de trop. Autrement dit, la fonctionnalité attendue est un envoi, la contrainte réelle est un état, et toute l'architecture découle de ce décalage.

Ce que le terrain impose avant toute décision technique

Avant de choisir quoi que ce soit, nous regardons comment le client final lit et comment il paie, parce que ces deux faits déplacent la conception bien plus qu'un choix de bibliothèque.

Le client lit WhatsApp avant ses courriels, donc le canal principal d'un rappel ici n'est pas celui que supposent les outils conçus ailleurs, et le courriel reste nécessaire dès que l'interlocuteur est un service comptable qui traite les factures.
Le paiement arrive souvent par Wave ou Orange Money, parfois en plusieurs fois, ce qui veut dire qu'un solde partiel est le cas courant et non le cas limite.
La connexion n'est pas toujours là au moment où le traitement tourne, ni du côté de l'entreprise, ni du côté de la personne qui doit valider depuis son téléphone, et un traitement qui ne supporte pas d'être rejoué finira par envoyer deux fois le même rappel.
Les méthodes de relance disponibles en ligne viennent surtout de marchés où l'on écrit des lettres recommandées et où l'on paie par virement bancaire, et leur rythme, plus sec, coûterait ici plus cher que la créance elle-même.

L'architecture que nous retenons, et son prix

Le cœur est un lot quotidien, pas un flux événementiel. Chaque matin, avant la préparation du moindre message, le système lit les factures là où elles vivent déjà, un logiciel de facturation, un tableur partagé ou un dossier de documents, en relève le montant en FCFA, l'échéance, le client et le moyen de le joindre, puis rapproche les paiements Wave, Orange Money et bancaires des factures encore ouvertes. Une facture réglée sort de la liste avant même qu'une relance existe. Un paiement partiel place la facture dans un état distinct, pour que le texte parle du solde restant et jamais du montant complet.

Le rapprochement n'a pas le droit de deviner. Nous le concevons avec deux issues seulement, un rattachement certain, ou un signalement à la personne qui valide. Un paiement mobile reçu sans référence lisible ne ferme pas la facture et ne déclenche pas non plus de rappel, il attend un arbitrage humain. Ce choix coûte quelque chose, une petite file de cas à trancher chaque matin, qui ne disparaîtra jamais complètement. Nous l'assumons, parce que l'alternative revient à écrire au client le jour où l'heuristique se trompe.

La liste des relances prêtes est ensuite soumise à une personne de l'entreprise, sur WhatsApp ou par courriel, et rien ne part avant son accord. Elle retire un client, corrige une phrase, met un dossier en attente, puis valide. Chaque envoi est inscrit dans l'historique du client, ce qui rend la séquence rejouable sans dégât, un même rappel ne peut pas sortir deux fois parce que le traitement a été relancé ou parce que la connexion a coupé en cours de route. Dès qu'un paiement est constaté, la séquence s'arrête d'elle-même pour ce client, et si celui-ci répond pour contester ou demander un délai, elle se suspend et la conversation revient à une personne de l'équipe.

Le prix de ce découpage est net. Le lot quotidien introduit un délai, un rappel se prépare au lendemain de l'échéance et non à la minute, et le point de validation ajoute une dépendance humaine quotidienne, si personne ne valide, rien ne part. En échange, le système reste explicable à celui qui l'utilise, rejouable après une coupure, et arrêtable.

Ce que nous avons écarté, et pourquoi

Le déclenchement en temps réel à l'instant de l'échéance. Il paraît plus propre, mais il expose à relancer une facture dont le paiement n'est pas encore rapproché, c'est-à-dire précisément l'erreur à éviter. Le lot du matin nous donne un moment où l'état est cohérent.
Le changement de logiciel de facturation. Nous construisons autour de ce que l'équipe utilise déjà, parce qu'un outil imposé à l'occasion d'un projet de relance déplace le travail au lieu de le réduire, et parce que la façon de facturer n'a aucune raison de bouger.
L'envoi de bout en bout sans relecture. Il est plus simple à écrire que le point de validation, et c'est justement pourquoi nous le refusons, puisqu'un traitement qui écrit seul à un client en litige cause un dégât qu'aucun temps gagné ne rachète.
L'escalade automatique, pénalité, coupure de service, transfert au recouvrement. Ces gestes engagent l'entreprise et une relation commerciale, ils n'appartiennent pas à une tâche planifiée.

Ce qui reste limité

Une automatisation de relance ne lit pas les arrangements pris de vive voix. Quand un gérant accorde un délai au téléphone à un chef de chantier, cet accord n'existe nulle part dans les données, et le système préparera un rappel tant que quelqu'un ne l'a pas marqué une fois dans le dossier. Nous traitons donc le marquage des exceptions, client en litige, négociation en cours, délai accordé, partenaire que le dirigeant préfère appeler lui-même, comme une fonction de premier plan et non comme un réglage avancé.

La qualité du rapprochement dépend aussi de ce que le client écrit au moment de payer, et aucune architecture ne corrige un transfert mobile sans référence, elle peut seulement refuser de conclure. Le ton, enfin, ne s'automatise pas. Nous préparons des modèles, cordial au premier rappel, plus précis aux suivants, jamais menaçant, mais c'est l'entreprise qui les écrit comme elle écrirait elle-même, et c'est une personne qui regarde la liste du jour avant que le moindre message ne sorte. Cette étape n'est pas une précaution de démarrage que l'on retire après quelques semaines de confiance, elle fait partie de la conception.

Si vous construisez ce genre de traitement sur un autre marché, la question que nous vous poserions en premier est simple, savez-vous chaque matin, avec certitude, qui a réellement payé.