Le coût caché du point à point
À six rails, il faut quinze interfaces. À dix, quarante-cinq.
Connecter deux systèmes de paiement demande une interface. Trois en demandent trois. La croissance n’est pas linéaire mais quadratique — et chaque interface doit être maintenue, sécurisée, testée, documentée et exploitée.
Le coût visible, le développement, n’est pas le plus élevé. Le coût réel apparaît plus tard : chaque interface a sa propre gestion d’erreurs, sa propre idée de l’idempotence, ses propres journaux, son propre mode d’exploitation. Une correction de sécurité doit être appliquée quinze fois.
La règle fondamentale du cadre : un rail ne doit jamais être couplé directement à un autre rail. Chaque rail parle à son connecteur ; les connecteurs parlent tous le même modèle canonique.
La chaîne de responsabilités
Trois couches, trois rôles distincts. La discipline du cadre tient à ce que chacune ne fasse que le sien.
| Couche | Responsabilité |
|---|---|
| Connecteur de rail | Comprendre et traduire le rail : protocole, message, correspondance vers le modèle canonique |
| Plateforme d’intégration | Intégrer, router, orchestrer, gérer la transaction |
| Couche de services | Construire et exposer les services de paiement destinés aux produits |
Ce qui n’appartient jamais au connecteur
| Ce qui n’y entre pas | Pourquoi |
|---|---|
| Le choix du rail | Un connecteur qui décide d’aller vers un autre rail a reconstitué le couplage point à point |
| La tarification commerciale | Elle appartient à la couche de services ; seuls les frais imposés par le rail transitent |
| Les plafonds commerciaux | Limites réglementaires et commerciales s’évaluent une fois, en amont, pour tous les rails |
| L’évaluation du risque | Un score de fraude par connecteur donne autant de politiques que de rails |
| La logique produit | Ce qui distingue un virement instantané d’un paiement marchand relève du produit, pas du transport |
| La comptabilité | Elle relève du cœur bancaire et du grand livre |
Le cadre en dix étapes
Chaque étape produit un livrable vérifiable. Le guide détaille ce qui est collecté à la découverte — protocoles, formats, sécurité, cycle transactionnel, contraintes de service — et l’architecture standard d’un connecteur, de l’adaptateur d’entrée au gestionnaire de transaction.
La distinction fondatrice
Ce qui distingue un paiement d’un appel d’API
Un appel d’API qui échoue se rejoue. Un paiement qui échoue peut avoir été exécuté.
Le connecteur doit à tout moment savoir distinguer trois situations : le rail a accepté, le rail a refusé, et je ne sais pas ce que le rail a fait. « Le rail a refusé » est un résultat ; « je ne sais pas » est une absence de résultat. Les traiter de la même façon produit soit des doubles paiements, soit des clients débités sans motif. Aucune autre erreur de conception n’a des conséquences aussi coûteuses.
Le principe le plus contre-intuitif
On écrit le simulateur du rail avant le connecteur.
Attendre l’accès au rail réel pour commencer à développer est la meilleure façon de perdre trois mois. Développer sans pouvoir provoquer d’erreurs est la meilleure façon de livrer un connecteur qui ne tient pas en production. Le simulateur résout les deux problèmes à la fois — et il fournit les scénarios obligatoires que le connecteur devra affronter : succès, refus, absence de réponse, réponse tardive, duplicata, incohérence de montant.
Les six portes de certification
Un connecteur est certifié après avoir franchi six portes, dans l’ordre. Une porte non franchie bloque la publication au catalogue : il n’existe ni publication partielle, ni dérogation.
Porte 1
Fonctionnelle
Messages, correspondances, cycle de vie transactionnel, erreurs, annulations, rapprochement.
Porte 2
Interopérabilité
Conformité au modèle canonique, compatibilité avec la plateforme, la couche de services et le rail.
Porte 3
Sécurité
Authentification, chiffrement, gestion et rotation des secrets, journalisation.
Porte 4
Résilience
Comportement sous panne, expiration, duplicata, indisponibilité du rail.
Porte 5
Performance
Débit, latence, tenue dans la durée, mesurés honnêtement.
Porte 6
Documentation
Spécification, exploitation, procédures et versionnement.
Le kit de développement
Ce que chaque connecteur reçoit sans avoir à l’écrire : le modèle canonique, la bibliothèque de protocoles, la bibliothèque de sécurité, le cadre transactionnel, le cadre d’erreurs, le kit d’observabilité, le kit de rapprochement, le kit de tests, le cadre de simulation et le générateur de connecteurs.
C’est ce qui transforme un projet en processus. Sans kit commun, chaque connecteur réinvente l’idempotence, les journaux et la gestion des secrets — et le cadre redevient une collection d’interfaces.
Les limites, énoncées d’emblée
Un environnement non productif. Le cadre est développé et éprouvé contre des simulateurs paramétrables. 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. 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.
Les deux documents
Le guide couvre la règle d’architecture, les dix étapes, le modèle canonique et la discipline du mapping, la connectivité et la rotation des secrets, le moteur transactionnel et sa taxonomie d’erreurs, l’observabilité et la piste d’audit, les tests et les six portes de certification, le kit de développement et la fabrique de connecteurs.
Les autres projets
La Bank-in-a-Lab tient les comptes, l’OPP Lab assemble la chaîne, le laboratoire e-commerce la sollicite. Ce cadre industrialise ce qui les relie aux réseaux extérieurs.
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.