L’idée
L’objectif n’est pas de construire un concurrent de Shopify.
C’est de disposer d’un environnement où un paiement existe vraiment : un client qui commande, un panier, un choix de moyen de paiement, une autorisation, une confirmation, un remboursement éventuel, un rapprochement et un règlement. Un simulateur isolé n’enseigne pas cela. Une boutique qui fonctionne, si.
Le commerce en ligne a une propriété que peu de cas d’usage possèdent : il mobilise, sur une seule transaction, le checkout, l’orchestration, le routage, la tokenisation, la fraude, le remboursement, le rapprochement et l’observabilité. C’est un terrain d’apprentissage complet.
La chaîne, de bout en bout
| Étage | Rôle | Briques ouvertes envisagées |
|---|---|---|
| Storefront | Catalogue, panier, checkout, compte client, suivi de commande | Next.js, React |
| Moteur de commerce | Catalogue, commandes, promotions, multi-canal, marketplace | Saleor ou Vendure, en mode découplé |
| Couche de paiement | API de paiement, routage, tokenisation, fraude, remboursement, rapprochement | Développée par le Lab : c’est le cœur pédagogique |
| Moteur de facturation | Paiements unitaires, abonnements, facturation, chargebacks, abstraction des prestataires | Kill Bill |
| Connecteurs | Cartes, mobile money, QR, prestataires, banques, paiement instantané | Développés par les apprenants |
La couche de paiement, cœur du dispositif
C’est la partie que le Lab construit lui-même, et donc celle qui forme. Six fonctions, chacune ouvrant un champ d’expérimentation.
API de paiement
Exposer
- Services exposés en REST et en GraphQL, derrière une passerelle.
- Contrats explicites, versionnés, testés.
Routage
Choisir
- Sélection dynamique d’un prestataire ou d’un réseau.
- Selon la disponibilité, le coût, la devise, le canal, le pays, le type de paiement.
Tokenisation
Protéger
- Limiter l’exposition des données sensibles.
- Préparer des architectures compatibles avec des exigences de sécurité élevées.
Fraude et risque
Filtrer
- Règles, scoring, contrôles de vélocité, listes de surveillance.
- Analyse de comportements en temps réel.
Remboursement et annulation
Défaire
- Remboursement total ou partiel, annulation, reversal.
- Expiration, nouvelle tentative, compensation.
Rapprochement
Réconcilier
- Commande, transaction, paiement, règlement, comptabilité.
- Le point où les architectures mal conçues se révèlent.
Treize labs de formation
Chaque lab isole une difficulté réelle du métier et la fait travailler jusqu’à ce qu’elle soit maîtrisée.
| Lab | Ce qu’on y apprend |
|---|---|
| Checkout | Panier, initiation de paiement, confirmation |
| Connecteur de paiement | Développer un connecteur vers un prestataire, une banque, un wallet |
| Paiement instantané | Connecter une boutique de test à un système instantané, simuler les échanges ISO 20022, gérer les statuts |
| Carte | Autorisation, capture, remboursement, chargeback |
| QR | QR marchand, initiation, confirmation, notification |
| Routage | Arbitrer entre plusieurs prestataires selon disponibilité, coût et règles métier |
| Panne | Expiration, nouvelle tentative, prestataire indisponible, duplicata, idempotence, reversal |
| Fraude | Règles, scoring, contrôles temps réel |
| Rapprochement | Commandes, transactions, paiements, règlements |
| Remboursement | Total, partiel, reversal |
| Abonnement | Facturation périodique, renouvellement |
| Marketplace | Multi-vendeurs, commissions, paiement fractionné, règlement vendeur |
| Observabilité | Journaux, traces, métriques, tableaux de bord d’un paiement |
Le lab qui compte le plus est celui des pannes. Un ingénieur qui n’a jamais vu un paiement expirer, se dupliquer ou repartir en double n’est pas un ingénieur des paiements. Ici, la panne est provoquée volontairement.
Ce qu’un Payment Engineer doit savoir faire
À la sortie, dix capacités vérifiables — ce sont elles que la soutenance met à l’épreuve.
- 01Comprendre une chaîne de paiement de bout en bout
- 02Intégrer une API de paiement
- 03Développer un connecteur
- 04Gérer les erreurs et les cas limites
- 05Implémenter l’idempotence
- 06Comprendre le règlement interbancaire
- 07Réaliser un rapprochement
- 08Instrumenter un paiement
- 09Intégrer des contrôles de sécurité
- 10Connecter une application métier à une infrastructure de paiement
Le socle technique
| Domaine | Technologie |
|---|---|
| Base de données | PostgreSQL |
| Cache | Redis |
| Diffusion d’événements | Kafka ou Redpanda |
| Identités et accès | Keycloak |
| Passerelle d’API | KrakenD |
| Observabilité | OpenTelemetry, Prometheus, Grafana |
| Orchestration | Kubernetes |
Ce que le laboratoire rend possible
Au-delà de la formation, le dispositif ouvre plusieurs capacités que l’OPPL peut proposer à l’écosystème.
| Capacité | Pour qui |
|---|---|
| Laboratoire de certification de paiement e-commerce | Banques, fintechs, prestataires, agrégateurs, commerçants, établissements de paiement |
| Usine à connecteurs | Institutions ayant à industrialiser des connecteurs vers des réseaux et des prestataires |
| Bac à sable mutualisé | Acteurs qui n’ont pas les moyens d’un environnement de test propre |
| Tests d’intégration de paiement | API, performance, résilience, sécurité, compatibilité |
| Académie d’ingénierie des paiements | Payment Engineers, architectes, ingénieurs de fiabilité et de plateforme |
Le périmètre, et ce qui en sort
Le Lab est un environnement non productif. Il manipule exclusivement des données synthétiques, des numéros de carte de test et des simulateurs de contrepartie. Aucune connexion à un système réel n’est établie depuis le laboratoire.
Sur les infrastructures régionales. Les connecteurs décrits — notamment celui du paiement instantané, dont la cible est PI-SPI via GIMPIP et GPSL — décrivent une cible d’intégration, pas une implémentation. 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.
| Dans le périmètre | Hors périmètre en version 1.0 |
|---|---|
| Storefront de démonstration, moteur de commerce, couche de paiement, moteur de facturation | Toute connexion à un système réel : réseaux cartes, opérateurs mobile money, infrastructures régionales, core banking |
| Connecteurs et leurs simulateurs de contrepartie | La certification PCI DSS |
| Socle technique, treize labs, chaîne de tests et observabilité | Les modules matériels de sécurité physiques, remplacés par un équivalent logiciel de test ; la haute disponibilité multi-sites ; l’exploitation commerciale de la boutique |
La boucle du laboratoire
Apprendre, construire, casser, observer, corriger, industrialiser.
Les six verbes se suivent dans cet ordre, et le troisième n’est pas facultatif. C’est en cassant volontairement une chaîne de paiement qu’on apprend ce qu’elle exige.
Les deux documents
Le guide couvre l’architecture de référence en sept couches, le choix du moteur de commerce, le déploiement en neuf phases, la construction de la couche de paiement — modèle canonique, idempotence, routage, tokenisation, fraude, rapprochement —, l’intégration du moteur de facturation, les connecteurs et les treize labs. La présentation en restitue la démarche en cinquante diapositives.
Le premier projet
L’OPP Lab assemble dix briques open source en une chaîne de paiement complète. La Bank-in-a-Lab en fournit la source : les comptes et le grand livre. Ce laboratoire e-commerce en constitue le prolongement côté commerce et formation.
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.