Tout le monde parle de digitalisation. Presque personne ne parle de ce sur quoi elle repose

La numérisation est le mot de la décennie en Afrique. On le trouve dans les plans nationaux de développement, dans les discours ministériels, dans les communiqués de presse des banques, dans les pitch decks des startups. Les gouvernements l'annoncent. Les médias le répètent. Les entreprises le mettent dans leurs slogans.

Sous ce mot se cache une réalité bien plus étroite.

Rien ne se numérise vraiment tant que l'argent ne circule pas de façon fiable. Un portail fiscal incapable de collecter un paiement n'est qu'un formulaire. Une plateforme e-commerce sans règlement n'est qu'un catalogue. Un système d'assurance santé incapable de rembourser n'est qu'une base de données. Tout projet de numérisation finit par se heurter au même point : quelqu'un doit payer quelqu'un d'autre, et le système doit avoir raison à ce sujet.

La vraie question n'est donc pas de savoir si un pays se numérise. C'est de savoir s'il dispose d'une couche de paiement à laquelle les gens peuvent faire confiance sans se connaître.

Cette couche, c'est le sujet de cet article.

Voici ce qui surprend la plupart des ingénieurs : un système de paiement n'est pas une application avec une API de paiement à l'intérieur. C'est un ensemble de garanties offertes à des parties qui ne se font pas confiance entre elles et qui doivent malgré tout s'accorder sur qui possède quoi.

Cette distinction change tout. Elle explique pourquoi les systèmes de paiement paraissent surdimensionnés vus de l'extérieur. Elle explique pourquoi ils refusent des choses qui seraient triviales ailleurs. Elle explique pourquoi une équipe qui livre vite dans tous les autres domaines ralentit soudain ici.

Quatre familles de garanties tiennent l'ensemble debout. Les comprendre n'est pas une connaissance optionnelle pour quiconque construit dans ce domaine. C'est le prérequis.

Partie 1. Le paysage : qui fait quoi, et qui porte quel risque

Demandez à un développeur de décrire un paiement, et vous obtenez généralement deux parties. Un client paie. Un marchand reçoit.

Ce modèle est faux, d'une manière qui cause de vrais dégâts. Un paiement n'est pas une transaction entre deux parties. C'est une chaîne de responsabilités, et chaque maillon de cette chaîne porte un type de risque différent.

Les acteurs, et ce qu'ils font réellement

Le marchand vend quelque chose et veut être payé. C'est le seul rôle simple de la chaîne.

Le PSP (Payment Service Provider) est l'élément le plus souvent mal compris. Les ingénieurs le voient comme un connecteur technique, une API plus agréable devant des interfaces d'opérateurs peu commodes. C'est la plus petite partie de ce qu'il fait réellement. Un PSP porte un risque de règlement, détient des fonds en transit, absorbe des obligations de conformité, et répond des litiges. Quand un client conteste une transaction trois jours plus tard, c'est le PSP qui est dans la pièce. Choisir un PSP, ce n'est pas choisir une bibliothèque. C'est choisir une contrepartie.

L'acquéreur est l'institution qui accepte la transaction au nom du marchand et la fait entrer dans le système bancaire. Dans les écosystèmes carte, c'est une entité régulée distincte. Dans de nombreux contextes africains, la frontière entre PSP et acquéreur est floue, et savoir où elle se situe réellement dans votre configuration précise compte davantage que la définition de manuel.

L'émetteur ou l'opérateur de mobile money détient l'argent du client. C'est la partie qui décide si le paiement a lieu ou non. Tout ce qui se passe avant cette décision n'est qu'une requête, pas un fait.

La banque de règlement est là où la valeur finit par atterrir. Pas là où elle est confirmée. Là où elle atterrit.

Le régulateur n'apparaît pas dans votre diagramme d'architecture, mais le contraint quand même. Seuils, obligations de reporting, licences, règles d'identification client. Tout cela façonne votre modèle de données avant même que vous n'écriviez votre première migration.

La distinction que presque personne ne fait

Trois mots sont utilisés indifféremment par des gens qui devraient pourtant savoir mieux. Ce ne sont pas les mêmes choses, et les confondre est exactement ce qui fait qu'un système finit par mentir à ses utilisateurs.

Un marchand qui voit "payé" sur un tableau de bord a généralement vu une autorisation. L'argent n'est pas encore là. Il peut ne pas l'être pendant deux jours. Si votre produit annonce au marchand que l'argent est arrivé alors qu'il n'a été qu'autorisé, vous n'avez pas construit un système de paiement. Vous avez construit un affichage qui finira par se tromper publiquement.

C'est dans cet écart que la confiance se perd le plus souvent, en pratique. Pas dans les pannes. Dans l'espace entre ce que dit l'interface et ce que montre le compte bancaire.

Ce qui est différent avec le mobile money en Afrique centrale

Dans les écosystèmes carte, ces rôles sont séparés par des décennies de réglementation et d'infrastructure. Dans le mobile money, l'opérateur est simultanément le réseau, l'émetteur, et la banque de fait. Il détient le float, gère la relation client, contrôle l'API, et fixe les règles.

Cette concentration change le profil de risque de trois façons concrètes.

La disponibilité n'est pas quelque chose que l'on peut contourner par l'architecture. Si l'opérateur est en panne, il n'existe aucune route alternative vers l'argent de ce client. Il n'y a pas de deuxième acquéreur vers lequel basculer.

Votre surface d'intégration est plus réduite et plus fragile. La sémantique des API varie d'un opérateur à l'autre, et pas de façon cosmétique. Le vocabulaire des statuts diffère. Le comportement des timeouts diffère. Ce qui constitue un état final diffère.

Et sur le plan commercial, vous avez très peu de levier. Les conditions sont les conditions.

Construire dans ce contexte, c'est concevoir en fonction d'une dépendance que vous ne contrôlez pas et ne pouvez pas remplacer. C'est une contrainte stratégique, pas technique, et elle doit être posée sur la table avant que quiconque n'ouvre un éditeur.

Partie 2. La vérité sur les comptes

Voici l'idée unique qui sépare ceux qui ont réellement construit des systèmes de paiement de ceux qui ne l'ont pas fait.

Un solde n'est pas une valeur stockée. C'est un résultat calculé.

Le réflexe de la plupart des développeurs est une colonne balance sur une ligne de compte. Un paiement arrive, on l'ajoute à la colonne. Un retrait a lieu, on le soustrait. Ça fonctionne le premier jour. C'est structurellement faux, et ça échoue d'une manière précise et irrécupérable.

Pourquoi le solde stocké vous détruit

Pas parce que c'est lent. Parce que ça détruit l'historique.

Quand un solde est un nombre modifiable, une erreur devient invisible dès qu'elle se produit. Si un bug ajoute 15 000 deux fois, vous vous retrouvez avec un nombre faux, sans aucun moyen de le savoir, sans aucun moyen de voir quand il est devenu faux, et sans aucun moyen de déterminer quelle aurait dû être la valeur correcte. La preuve a été effacée par l'erreur elle-même.

Dans la plupart des logiciels, on peut se remettre de données erronées en corrigeant le code et en retraitant. En paiement, ce n'est pas possible, parce que le monde extérieur a bougé. De l'argent réel a quitté le compte d'une personne réelle. Votre base de données est censée être la trace de ce mouvement. Si elle est en désaccord avec la réalité et ne peut pas l'expliquer, vous n'avez pas un bug. Vous avez un litige que vous allez perdre.

Le journal comptable

Le modèle correct est un journal d'écritures que l'on ne modifie jamais et que l'on ne supprime jamais.

Chaque mouvement de valeur est enregistré comme une nouvelle ligne. Les lignes sont immuables. En cas d'erreur, on ne corrige pas la ligne. On ajoute une écriture d'annulation qui la compense, et les deux restent visibles pour toujours. L'histoire de l'erreur fait partie intégrante de la trace.

Un solde, dès lors, n'est rien de plus que la somme de toutes les écritures affectant un compte. Il est dérivé, pas stocké. S'il faut y accéder rapidement, on le met en cache, et ce cache n'est qu'un détail de performance, toujours reconstructible à partir du journal. Le journal est la vérité.

Ce n'est pas une préférence architecturale. C'est le seul modèle capable de répondre à la question à laquelle tout système de paiement doit finir par répondre : pas "quel est le solde", mais "comment en est-on arrivé là, et prouvez-le."

La partie double, sans le jargon comptable

La partie double sonne comme une formalité de comptabilité. C'est en réalité un mécanisme de détection d'erreurs, et le plus efficace de tout le système.

Le principe : l'argent n'apparaît jamais et ne disparaît jamais. Il se déplace, c'est tout. Chaque montant qui quitte un compte arrive dans un autre. Chaque écriture a une contre-écriture correspondante, et sur l'ensemble du système, la somme de tous les mouvements doit être nulle.

C'est la conséquence qui compte. Si vos comptes ne s'équilibrent pas, vous n'avez pas perdu un simple arrondi. Vous avez de l'argent non comptabilisé, qui se trouve quelque part que votre système ne peut pas nommer. La partie double n'empêche pas cela d'arriver. Elle rend la chose impossible à cacher.

Un système sans cela peut se tromper silencieusement pendant des mois. Un système avec cela ne peut pas se tromper plus d'une journée sans que quelqu'un le sache.

Les comptes qui n'appartiennent à personne

Un véritable journal comptable contient des comptes qui ne correspondent à aucune personne. Ils existent parce que l'argent passe du temps dans des espaces intermédiaires entre les parties.

Un compte de transit détient des fonds capturés mais pas encore réglés au marchand. Un compte de frais collecte ce que la plateforme retient. Un compte d'attente détient des montants reçus par le système mais qu'il ne peut pas encore attribuer à quelqu'un, ce qui arrive plus souvent qu'on ne le pense.

Ce ne sont pas des rustines. C'est la façon de rendre explicites les états intermédiaires de l'argent, plutôt que de prétendre qu'ils n'existent pas. Un système sans compte d'attente n'a pas moins de paiements non attribués. Il a des paiements non attribués cachés dans le solde de quelqu'un d'autre.

La réconciliation

Et voici la partie qui remet tout le monde à sa place.

Votre base de données n'est pas la source de vérité. Le relevé de l'opérateur l'est.

Quoi que dise votre journal comptable, l'enregistrement faisant autorité de ce qui s'est réellement passé est détenu par l'opérateur de mobile money et la banque de règlement. Le travail de votre système consiste à être en accord avec eux, et à savoir immédiatement quand ce n'est pas le cas.

La réconciliation est le processus quotidien qui consiste à comparer vos écritures avec le relevé de l'opérateur, ligne par ligne, et à enquêter sur chaque différence. Pas un échantillon. Chaque différence.

Un système qui ne se réconcilie pas quotidiennement n'a pas moins d'écarts. Il découvrira un mois d'écarts d'un coup, sans avoir la moindre idée de quelle transaction est à l'origine du problème.

C'est la pratique unique qui distingue le plus un vrai système de paiement d'un prototype fonctionnel. Pas le débit. Pas l'architecture. Le fait que quelqu'un vérifie, chaque jour, que les comptes correspondent à la réalité.

Partie 3. Ce qui doit tenir quand les choses cassent

Tout système finit par échouer. Ce qui rend le paiement différent, c'est ce que coûte l'échec et la forme qu'il prend.

Dans un logiciel ordinaire, une erreur coûte un rechargement de page. Ici, elle coûte de l'argent réel à quelqu'un, et ce coût n'est pas symétrique.

Perdre un paiement est réparable. L'enregistrer deux fois ne l'est pas.

Si une transaction est perdue, l'argent est toujours chez le client ou l'opérateur. On peut le retrouver, le tracer, le retraiter. La réconciliation existe précisément pour attraper ce cas. C'est un problème qui a une procédure.

Si une transaction est enregistrée deux fois, vous avez crédité une valeur qui n'a jamais existé. Vous avez payé un marchand avec de l'argent qu'on ne vous a jamais donné. Vous le découvrirez plus tard, vous devrez le récupérer auprès de quelqu'un qui l'a déjà dépensé, et chaque partie de la chaîne a maintenant la preuve que votre système ne sait pas compter.

Cette asymétrie est le principe de conception derrière tout ce qui suit dans cette section. En cas de doute, faites moins. Une transaction manquée est une tâche. Une transaction dupliquée est une perte de confiance.

L'idempotence

L'idempotence signifie que la même intention produit le même résultat, quel que soit le nombre de fois où elle est soumise.

Ce n'est pas une précaution défensive de confort. C'est une exigence, car le réseau garantit que des doublons se produiront.

Un client appuie sur payer, la réponse est lente, il appuie à nouveau. Une connexion mobile coupe en plein milieu d'une requête et le client retente. Votre propre logique de retry se déclenche parce qu'un timeout ressemblait à un échec alors que l'opération avait en réalité réussi. Un utilisateur rafraîchit une page de confirmation. Un opérateur envoie le même callback deux fois, ce qui arrive, régulièrement.

Aucun de ces cas n'est un cas limite. Tous sont le quotidien.

Le mécanisme consiste à faire porter à chaque intention de paiement un identifiant unique attribué une seule fois, à l'origine, avant toute tentative. Chaque opération suivante est liée à cet identifiant. Quand le même identifiant réapparaît, le système renvoie le résultat de la première tentative plutôt que d'en effectuer une seconde.

Ce qui compte vraiment, c'est le moment où l'identifiant est généré. S'il est créé au moment du traitement, il ne protège de rien, car un retry en génère un nouveau. Il doit être créé au moment de l'intention et transporté à travers toute la chaîne.

PENDING est un état légitime

La plupart des ingénieurs modélisent un paiement comme un succès ou un échec. Deux résultats, un booléen, terminé.

Ce modèle est faux, et il cause de vrais dégâts financiers.

Il existe un troisième état, et ce n'est pas une anomalie. Un paiement peut être réellement en cours : le client a été sollicité, l'opérateur attend, le réseau est lent, la confirmation n'est pas encore revenue. Cet état peut durer quelques secondes. Il peut durer quarante minutes. Dans certaines conditions, il dure des heures.

Pendant cette fenêtre, votre système ne sait qu'une chose : il ne sait pas.

L'erreur qui coûte cher, c'est de traiter l'inconnu comme un échec. Car si vous le marquez comme échoué et dites au client de réessayer, et que le premier paiement finit par se réaliser, vous avez pris de l'argent deux fois à quelqu'un à qui on avait dit que rien ne s'était passé. C'est l'erreur asymétrique qui entre par la porte principale.

Supposez que la notification n'arrivera jamais

Toute intégration de paiement propose des callbacks. L'opérateur vous notifiera quand la transaction sera résolue.

Concevez comme si ce n'était pas le cas.

Les callbacks se perdent d'une manière que personne ne contrôle. Votre serveur redémarrait. Une partition réseau l'a avalé. La file d'attente de l'opérateur l'a fait tomber. Sa politique de retry a abandonné après trois tentatives pendant que vous étiez indisponible quatre minutes.

Un système dont le seul chemin vers la vérité est la notification entrante est un système qui sera durablement dans l'erreur sur une fraction de ses transactions.

La règle est simple : il doit toujours exister un moyen de demander. Toute transaction dans un état non final doit pouvoir être interrogée auprès de l'opérateur, et quelque chose doit effectuer ces requêtes activement, selon un calendrier. Le callback est une optimisation qui accélère la résolution. La requête active est le mécanisme qui la rend certaine.

Construire dans l'autre sens, avec le callback comme mécanisme principal et sans filet de sécurité, est l'erreur structurelle la plus courante des intégrations de paiement.

La dégradation, et le courage de refuser

Quand une dépendance devient indisponible, la plupart des systèmes se dégradent en continuant à accepter du travail et en le mettant en file d'attente.

En paiement, cette approche mérite un examen attentif, car accepter un paiement que vous ne pouvez pas vérifier est pire que refuser un paiement que vous auriez pu traiter.

Certaines choses peuvent se dégrader sans risque. Lire l'historique, consulter des transactions passées, naviguer, générer des rapports. Rien de tout cela ne crée d'obligation financière.

Certaines choses doivent s'arrêter. Si vous ne pouvez pas confirmer auprès de l'opérateur qu'un paiement a réussi, vous ne devez dire à personne qu'il a réussi. Si vous ne pouvez pas écrire dans le journal comptable de façon fiable, vous ne devez pas accepter de nouvelles transactions. Un refus clair coûte quelques minutes à un client. Une fausse confirmation coûte de l'argent et de la crédibilité.

Savoir à l'avance dans quelle catégorie se situe chaque opération, c'est un travail de conception. Le découvrir en plein incident n'en est pas un.

La question de la performance, et pourquoi elle n'est pas ce que vous croyez

Un petit détour, car la performance en paiement est régulièrement mal comprise.

Partout ailleurs, la latence est un problème de confort. Une page lente est ennuyeuse. Les utilisateurs attendent ou partent.

En paiement, la latence se convertit directement en problème de justesse.

Au-delà d'un certain délai, l'utilisateur en conclut que ça a échoué. Il n'attend pas. Il appuie à nouveau, ou il lance un nouveau paiement, ou il appelle le marchand qui lance à son tour une nouvelle requête. La réponse lente ne vous a pas coûté quelques secondes de patience. Elle a généré une tentative dupliquée sur de l'argent réel.

C'est pour cette raison que la performance, ici, est un enjeu de justesse, pas un enjeu d'optimisation. C'est aussi pour cette raison que la réponse honnête face à une opération lente n'est pas toujours de la rendre plus rapide. C'est parfois de rendre l'état d'attente visible et sans ambiguïté, pour que l'utilisateur sache la différence entre "c'est toujours en cours" et "ça n'a pas fonctionné".

Le système qui vous dit clairement qu'il est toujours en train de traiter est plus sûr que le système légèrement plus rapide mais silencieux.

Partie 4. Ce qui doit tenir devant un tiers

Tout ce qui précède concerne la justesse du système. Cette section concerne quelque chose de différent, et tout aussi important.

Le jour où quelqu'un conteste, le système doit pouvoir prouver, pas seulement affirmer.

Un client dit qu'il n'a jamais autorisé la transaction. Un marchand dit qu'il n'a jamais rien reçu. Un régulateur demande les registres des transactions au-dessus d'un seuil. Une enquête interne demande qui a approuvé un remboursement. Dans chaque cas, "notre système le dit" n'est pas une réponse. C'est une affirmation, et elle pèse exactement autant que l'affirmation contraire de l'autre partie.

La non-répudiation

La non-répudiation signifie un enregistrement qu'aucune partie ne peut nier de façon crédible. Ni le client, ni le marchand, et surtout pas vous.

Ce dernier point est celui que les équipes oublient. Un journal que vos propres ingénieurs peuvent modifier ne prouve rien sur votre conduite, car vous êtes également partie au litige. Une preuve contrôlée par l'accusé n'en est pas une.

Ce qui fait tenir un enregistrement combine plusieurs éléments : une trace créée au moment de l'action plutôt que reconstruite après coup, une signature cryptographique rendant la falsification détectable, des horodatages fiables, et un chaînage tel que retirer ou altérer un enregistrement rompt visiblement la séquence.

La piste d'audit n'est pas de la journalisation

Ces deux choses sont constamment confondues, et elles servent des objectifs complètement différents.

Cette dernière ligne compte plus qu'il n'y paraît. Une piste d'audit que seul un ingénieur peut interpréter ne fonctionne pas comme une piste d'audit. Si un représentant du régulateur ou un responsable de la conformité ne peut pas lire un enregistrement et comprendre ce qui s'est passé, l'enregistrement ne remplit pas sa fonction.

Une piste d'audit est complète, immuable, conservée et compréhensible. Les logs ne sont, par nature, rien de tout cela, et c'est très bien ainsi. Ce sont simplement des artefacts différents, et l'un ne peut pas remplacer l'autre.

La sécurité, pensée par le risque plutôt que par la checklist

La sécurité en paiement est habituellement présentée comme une liste : chiffrer en transit, chiffrer au repos, faire tourner les clés, restreindre les accès. Tout cela est correct, et tout cela reste insuffisant comme façon de penser.

Le cadre le plus utile consiste à se demander où la valeur peut réellement être détournée.

Une partie du risque est externe. Vol d'identifiants, abus d'API, injection, interception. Ce sont des risques réels et bien connus, et les défenses habituelles s'appliquent.

Mais une part importante des pertes dans les systèmes de paiement n'est pas externe du tout. Elle est interne, et elle ne ressemble pas à une attaque.

Quelqu'un ayant accès à la base de données de production peut ajuster un solde. Quelqu'un disposant de privilèges de remboursement peut effectuer des remboursements vers un compte qu'il contrôle. Quelqu'un ayant des droits de déploiement peut déployer du code qui détourne une fraction des transactions. Rien de tout cela ne nécessite d'intrusion.

C'est pour cette raison que la séparation des tâches, la double approbation sur les opérations sensibles, l'accès restreint à la production et des pistes d'audit complètes ne sont pas de la bureaucratie. Ce sont les contrôles qui traitent le risque qui se matérialise le plus souvent : une personne de confiance sous pression.

Une posture de sécurité qui ne considère que les personnes extérieures comme des adversaires est incomplète, d'une manière précise et coûteuse.

La conformité façonne le modèle de données

Exigences KYC, plafonds de transaction, seuils de reporting, durées de conservation. Les ingénieurs ont tendance à traiter cela comme du travail administratif à gérer plus tard, par quelqu'un d'autre.

Cela ne peut pas être géré plus tard, car cela détermine le modèle de données.

Si la réglementation exige une identité vérifiée au-delà d'un certain seuil, l'état de vérification d'identité doit exister dans votre flux de transaction dès le départ. Si des plafonds s'appliquent par client et par période, vous avez besoin d'agrégation dès que vous avez des clients. Si des rapports doivent être produits pour certaines catégories, ces catégories doivent être enregistrées au moment de la transaction, pas déduites ultérieurement à partir de données qui ne portent plus cette distinction.

Introduire la conformité après coup dans un système de paiement en production signifie migrer des enregistrements financiers, ce qui est l'une des opérations les plus dangereuses qui existent. Concevoir pour cela dès le premier jour coûte très peu. L'ajouter en deuxième année coûte disproportionnellement plus, et cela se fait sous la pression d'un délai imposé par un régulateur.

Retour à la numérisation

Alors : qu'est-ce qu'un système de paiement numérique ?

Ce n'est pas une interface. Ce n'est pas une application mobile. Ce n'est pas une intégration avec l'API d'un opérateur.

C'est un journal comptable capable de prouver sa propre histoire, un ensemble de garanties qui survivent aux pannes réseau, et un corpus de preuves qui tient debout quand un tiers le conteste. Tout ce qui est visible repose sur cette base. La partie visible est la partie facile.

C'est pour cela que l'écart entre annoncer la numérisation et l'accomplir est si large. Construire une interface prend des semaines. Construire une couche de paiement à laquelle institutions, marchands et citoyens peuvent faire confiance sans se connaître exige les principes ci-dessus, appliqués avec constance, et vérifiés chaque jour.

Un pays se numérise quand cette couche existe et qu'elle tient. Pas quand a lieu l'événement de lancement.

Pour un ingénieur, entrer dans ce domaine signifie accepter un arbitrage précis. Dans la plupart des logiciels, la vitesse de livraison est la vertu première, et la justesse se négocie face à elle. Ici, cet ordre s'inverse, définitivement. Avoir raison prime sur être rapide, car le coût de se tromper n'est pas un rapport de bug.

C'est l'argent de quelqu'un.