Quand la régulation bloque, le produit s'adapte

Comment on a "hacké" (légalement) la limite des 500k XAF ?

Introduction

"Votre transaction dépasse la limite autorisée."

Le message était sec. Brutal. Un client voulait transférer 1 200 000 XAF. Notre système répondait :

❌  Montant supérieur à 500 000 XAF. Transaction refusée.

Techniquement, tout fonctionnait. Réglementairement, nous étions conformes. Mais d'un point de vue business ? C'était un mur. Et ce mur nous coûtait de la confiance.

Dans notre contexte (Cameroun), les transactions par paiement mobile sont plafonnées à 500 000 XAF. Ce plafond n'est pas négociable ; il dépend du cadre régulatoire. Mais nos utilisateurs, eux, ont des besoins réels — notamment le paiement des frais d'examens pour des candidats groupés. Leur problème n'était pas réglementaire. Il était opérationnel. Et notre système les bloquait.

Première idée naïve : "On n'a qu'à fractionner"

"On va juste faire plusieurs transactions de 500k." Simple ? Non. Parce que derrière cette phrase se cachent des bombes à retardement.

Bombe #1 — L'expérience utilisateur (le vrai risque)

Sur le papier, fractionner en trois paiements semblait simple. Dans la réalité, c'était potentiellement explosif.

Imaginons la scène : un client initie un transfert de 1 200 000 XAF. Il reçoit immédiatement :

📳  Notification débit 500 000
📳  Notification débit 500 000
🔇  Silence sur la troisième...

Puis, quelques secondes plus tard :

❌  Paiement échoué.

Que comprend-il ? Pour lui, ce n'est pas un "échec partiel". C'est : "On m'a pris 1 000 000 XAF et mon paiement n'est pas passé."

À cet instant, il ne pense ni à la régulation, ni à l'architecture. Il pense à son argent.

En fintech, la confiance est plus fragile que la latence réseau.

Une expérience mal conçue ici ne crée pas juste de la frustration. Elle sème le doute, génère du stress, et peut coûter cher en réputation. Dans notre marché, la rumeur va plus vite que la documentation.

Le véritable enjeu n'était donc pas technique. Il était psychologique. Comment faire en sorte que l'utilisateur sente que le système maîtrise la situation, même quand plusieurs transactions s'exécutent en coulisses ?

C'est là qu'on a compris : fractionner un paiement n'est pas un problème de backend. C'est un problème de confiance produit.

Bombe #2 — La cohérence financière

Avant, notre modèle était simple : 1 paiement → 1 transaction → 1 résultat.

Après décomposition : 1 intention → N transactions techniques.

Ce n'est plus la même chose. Le paiement devient un processus. Et un processus peut échouer partiellement. La question n'était plus "Est-ce que la transaction a réussi ?" mais : "Où en est le processus global ?"

Bombe #3 — Le réseau

Chaque sous-paiement signifiait un appel indépendant vers le fournisseur, avec ses propres risques : timeouts, retries, rate limiting, et double exécution.

Multiplier les transactions, c'était multiplier les points de défaillance. Un simple plafond réglementaire venait d'exposer les limites de notre architecture.

La vraie solution : introduire la notion d'intention

Le problème ne venait pas des transactions. Il venait de la façon dont on représentait le besoin utilisateur.

Un utilisateur ne veut pas faire "3 transactions". Il veut effectuer un paiement de 1 200 000 XAF.

On a donc introduit une nouvelle notion dans notre système : la Commande (Order).

Elle représente ce que l'utilisateur veut accomplir. Elle contient le montant total, le bénéficiaire, le contexte et un état global. Le système génère immédiatement toutes les sous-transactions conformes, et surtout : l'utilisateur les voit.

Notre choix a été pragmatique : ne pas masquer la complexité, mais la structurer.

Exécution maîtrisée

Dès la création d'une intention, l'utilisateur voit le montant total, le nombre de sous-transactions, le montant de chacune, et l'état global du paiement. Il comprend exactement ce qui va se passer.

L'utilisateur exécute les transactions une par une. Pourquoi ?

• Cela évite les débits invisibles.
• Cela renforce le sentiment de contrôle.
• Cela réduit le stress en cas d'échec.

Gestion des échecs partiels

Chaque transaction possède son propre identifiant, son propre statut, et sa propre clé d'idempotence. Si une transaction échoue, l'utilisateur peut la relancer uniquement elle. Chaque sous-transaction est isolée. Le retry est sûr.

L'état global intelligent

La Commande possède un état dérivé, pas un état arbitraire. Il dépend de l'agrégation des N transactions :

• Toutes SUCCESS → 🟢 COMPLETE
• Au moins une FAILED → 🟡 PARTIAL
• Toutes PENDING → 🔵 PENDING

L'état global devient une projection cohérente, pas une approximation.

Impact sur le grand livre (Ledger)

Un paiement de 1 200 000 XAF ne génère plus une seule écriture comptable, mais trois transactions financières distinctes, liées à une même intention. L'invariant est garanti : montant_exécuté ≤ montant_demandé. La traçabilité est complète.

Impact produit réel

Les résultats ont été immédiats :

• Plus aucun rejet bloquant pour montant élevé.
• Réduction des tickets support liés aux échecs flous.
• Meilleure compréhension du processus par l'utilisateur.
• Conformité réglementaire totale maintenue.
• Augmentation des volumes de transactions.

La contrainte réglementaire est devenue un avantage produit.

Conclusion

En fintech, la régulation ne bloque pas l'innovation. Elle révèle :

• Les failles d'architecture cachées.
• Les zones floues du produit.
• Les fragilités du réseau.
• Les manques d'orchestration.

On pensait avoir un système de paiement. On a découvert qu'on devait construire un système d'orchestration financière.

Et tout a commencé par une limite à 500 000 XAF.

Publié par Ivan Joel Tchatchoua