Pourquoi un cœur bancaire dans un laboratoire de paiement
Un paiement commence par un débit sur un compte. Sans compte réel, l’exercice reste une simulation d’API.
Les deux premiers projets construisaient la chaîne de paiement et le terrain de commerce qui la sollicite. Il manquait la source : le système qui tient les comptes, écrit les mouvements au grand livre et porte la responsabilité comptable de l’opération. C’est ce que ce troisième projet installe.
Le point critique
Quelques centaines de millisecondes
Entre le débit du compte et la confirmation du rail, l’argent a quitté le client sans être arrivé chez le bénéficiaire.
Si le système s’interrompt à cet instant précis, il faut savoir exactement ce qui se produit. Toute l’ingénierie du laboratoire se concentre sur cet intervalle — et c’est aussi ce qui sépare un développeur d’un ingénieur des paiements.
| Situation | Ce que le système doit faire |
|---|---|
| Le rail confirme | Confirmer l’opération et publier l’événement |
| Le rail refuse explicitement | Contrepasser l’écriture, recréditer le compte, informer le client |
| Le rail ne répond pas | Traiter une situation indéterminée : ni confirmer, ni annuler à l’aveugle |
Le guide détaille les six situations de cet intervalle et le comportement attendu pour chacune.
Six institutions fictives, un seul moteur
Chaque institution dispose de son propre espace bancaire, avec ses produits, ses agences, ses utilisateurs et son plan comptable. C’est le principal atout pédagogique du dispositif : il rend possible l’expérimentation des flux entre institutions, et pas seulement à l’intérieur de l’une d’elles.
| Institution | Rôle | Cas d’usage privilégiés |
|---|---|---|
| OPPL Bank | Banque universelle | Virement, salaire, prélèvement, crédit |
| OPPL Microfinance | Institution de microfinance | Microcrédit solidaire, épargne, collecte |
| OPPL Fintech | Portefeuille et services innovants | API, applications de paiement |
| OPPL Mobile Money | Opérateur simulé | Dépôt, retrait, transfert entre personnes, paiement marchand |
| OPPL Switch | Switch de paiement | Routage, autorisation, transformation de messages, résilience |
| OPPL Instant Payment | Système instantané simulé | Initiation, compensation, règlement |
Trois pièges identifiés avant de commencer
Trois caractéristiques du moteur retenu conditionnent toute la conception. Les ignorer conduit à des impasses découvertes tard.
Le cloisonnement entre institutions repose sur un en-tête d’appel. Une erreur d’en-tête n’échoue pas : elle écrit dans la mauvaise banque. Dans un laboratoire qui en héberge six, c’est un risque permanent, que la passerelle doit neutraliser en injectant elle-même l’institution à partir du jeton d’authentification.
Les API de libre-service ne font plus partie du moteur. La capacité pour un client final de consulter ses comptes et d’initier un virement depuis son téléphone est fournie par un module distinct, publié sous une licence différente. Toute conception d’application mobile doit partir de ce constat.
Le guide expose la troisième caractéristique et la grille de comparaison des quatre moteurs candidats.
Le rapprochement à cinq niveaux
Une même opération existe sous cinq représentations. Le rapprochement vérifie leur cohérence, s’exécute chaque nuit, et produit un rapport où chaque écart est classé et attribué.
| Niveau | Source | Ce qu’il apporte |
|---|---|---|
| 1 | Journal de l’API de libre-service | Ce que le client a demandé |
| 2 | Cœur bancaire | Ce qui a été débité ou crédité |
| 3 | Grand livre | Ce qui a été comptabilisé |
| 4 | Connecteur | Ce qui a été envoyé, et ce qui a été répondu |
| 5 | Rail simulé | Ce qui a effectivement été réglé |
La qualification, avant l’adoption
Le caractère open source d’un composant ne suffit pas à le qualifier pour une infrastructure financière critique. Chaque technologie est évaluée sur sa licence, sa gouvernance, l’activité de sa communauté, sa gestion des vulnérabilités, ses performances, sa sauvegarde et sa restauration, son observabilité, sa documentation, son support disponible, les compétences qu’elle exige, ses dépendances et sa réversibilité.
Les limites, énoncées d’emblée
Ce laboratoire ne confère aucun droit d’exercer une activité bancaire. Recevoir des dépôts du public, octroyer du crédit, émettre de la monnaie électronique ou encaisser pour le compte de tiers sont des activités réglementées, soumises à agrément. Le Lab modélise ces mécanismes à des fins de formation et d’expérimentation.
Un environnement non productif. Données synthétiques, identités fictives, simulateurs de réseaux. Aucune connexion à un système réel n’est établie depuis le laboratoire.
Sur les infrastructures régionales. Les références à GIMPIP, GPSL et PI-SPI décrivent une cible d’intégration simulée. Les spécifications de ces systèmes ne sont pas publiques, et toute connexion effective relève des processus d’homologation de leurs opérateurs.
Hors périmètre de la version 1.0 : toute connexion à un système réel, la certification et l’homologation réglementaires, les modules de sécurité matériels, la haute disponibilité multi-sites, et l’exploitation d’une activité bancaire réelle, quelle qu’elle soit.
Les deux documents
Le guide couvre l’architecture en sept couches, le choix du cœur bancaire et sa grille de comparaison, le déploiement en neuf phases, le développement autour du moteur — orchestrateur de paiements, écriture comptable et contrepassation, plafonds et vélocité, rapprochement —, les rails simulés et les cas d’usage de formation.
Les autres projets
L’OPP Lab assemble la chaîne de paiement elle-même ; le laboratoire e-commerce fournit le terrain qui la sollicite ; le cadre de connecteurs industrialise le lien vers les réseaux extérieurs. Ce cœur bancaire en constitue la source.
L’auteur
Lionel Sakiti
Program Manager Cloud & IA souveraines. Il travaille sur les infrastructures de paiement, les programmes de cloud et d’intelligence artificielle souverains et la gouvernance des données dans la zone UEMOA.