Pourquoi un Lab plutôt qu’un catalogue
Ce qui compte n’est pas ce qu’un composant promet isolément, mais la manière dont il se comporte une fois intégré.
Les décisions d’architecture de paiement engagent une institution pour une décennie : un switch, un core banking ou un ledger ne se remplacent pas au rythme d’une application web. Évaluer un composant sur sa documentation ou sur une démonstration commerciale ne suffit donc pas. Comment gère-t-il l’idempotence d’une requête rejouée ? Comment se rétablit-il après la perte d’un nœud ? Comment trace-t-il une transaction à travers six services ?
L’intégration révèle ce que l’évaluation isolée masque : frictions de modèles de données, incompatibilités de protocoles, coûts opérationnels cachés, compétences manquantes. Elle transforme une veille passive en capital de compétences.
Le Lab n’affirme pas que l’open source doit tout remplacer. Il donne aux équipes les moyens de décider, composant par composant, en connaissance de cause : construire, acheter, réutiliser, étendre ou remplacer.
Les huit verbes
La démarche est structurée par huit actions, chacune adossée à un livrable vérifiable.
| Verbe | Objectif | Livrable attendu |
|---|---|---|
| Installer | Déployer chaque brique de façon reproductible, sans intervention manuelle | Manifestes versionnés, runbook d’installation |
| Intégrer | Faire dialoguer les briques par des contrats explicites | Contrats d’API et d’événements, adaptateurs, tests de contrat |
| Tester | Vérifier le nominal et les cas d’erreur | Suites automatisées, jeux de données positifs et négatifs |
| Simuler | Reproduire les acteurs absents : émetteurs, acquéreurs, PSP, régulateur | Simulateurs et bouchons |
| Observer | Suivre une transaction à travers tous les services | Traces distribuées, métriques, journaux corrélés |
| Casser | Provoquer des pannes pour valider la résilience | Scénarios de chaos, durées de reprise mesurées |
| Sécuriser | Appliquer la sécurité par défaut et les contrôles | Politiques, secrets, inventaire des composants, rapports de scan |
| Benchmarker | Mesurer débit, latence et coût des ressources | Rapports comparables et reproductibles |
Les dix briques
Sept couches, de l’exposition d’API à l’observabilité, assemblées autour d’un modèle canonique de paiement commun.
| Brique | Rôle dans la chaîne |
|---|---|
| jPOS | Switch et traitement ISO 8583 |
| Prowide ISO 20022 | Messagerie ISO 20022 |
| Mojaloop | Paiements instantanés et interopérabilité |
| Mifos Payment Hub EE | Hub d’intégration et connecteurs |
| Hyperswitch | Orchestration et routage des paiements |
| Formance | Ledger financier, source de vérité comptable |
| Tazama | Détection de fraude et surveillance des transactions |
| Keycloak | Gestion des identités et authentification |
| Apache Kafka | Diffusion d’événements |
| OpenTelemetry et OpenSearch | Observabilité et corrélation |
Trois niveaux, selon la taille de l’équipe
| Niveau | Cible | Socle | Usage |
|---|---|---|---|
| 1 | Une personne | Conteneurs sur un poste de travail | Découverte, formation, développement d’un adaptateur |
| 2 | Cinq à vingt personnes | Kubernetes léger, trois nœuds | Intégration complète, cas d’usage de bout en bout, démonstrations |
| 3 | Organisation | Cluster dédié | Banc d’essai partagé et campagnes de mesure |
Les trois niveaux partagent le même dépôt et les mêmes contrats : seule la topologie change.
Douze semaines, jalon par jalon
| Semaines | Jalon | Livrables |
|---|---|---|
| 1 – 2 | Socle et services transverses | Cluster, GitOps, secrets, identité, politiques, passerelle, événements, observabilité |
| 3 – 4 | Ledger et switch | Ledger, plan de comptes, switch ISO 8583 |
| 5 – 6 | ISO 20022 et saga | Adaptateur de messages, orchestration durable, worker de saga |
| 7 – 8 | Instantané et intégration | Paiements instantanés, outillage de test, hub d’intégration |
| 9 | Orchestration | Routage et connecteurs |
| 10 | Fraude | Surveillance des transactions et scénarios |
| 11 | Tests, chaos, benchmark | Campagnes, rapports, corrections |
| 12 | Décision et restitution | Grille de décision, fiches d’architecture, démonstration à la direction |
Les limites, énoncées d’emblée
Un environnement non productif. Le Lab manipule exclusivement des données synthétiques et des numéros de carte de test. Toute trajectoire vers la production suppose une analyse de risques, une homologation et des décisions de licence spécifiques.
Ni certification, ni produit prêt à l’emploi. Le Lab ne se substitue pas à l’homologation réglementaire ni aux certifications de l’industrie des paiements. Il n’est pas davantage une plateforme livrable en l’état.
Un projet vivant. La liste des briques évolue avec les retours d’expérience. Les captures du guide sont des maquettes illustratives, destinées à être remplacées par celles de votre propre instance.
Les deux documents
Le guide couvre l’architecture de référence, les fiches des dix briques, le déploiement en onze phases, le développement des composants d’intégration, sept cas d’usage testés, la stratégie de tests et de benchmark, la sécurité et la gouvernance. La présentation en restitue la démarche en cinquante diapositives.
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.