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

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é.