Ce que c’est
Hub d’intégration open source permettant à une institution de relier son cœur bancaire, ses canaux et des dispositifs de paiement externes.
Ce qu’on y travaille dans le laboratoire
- ·Relier le cœur bancaire à un dispositif de paiement instantané
- ·Étudier une architecture de connecteurs en microservices
- ·Servir de plateforme d’intégration entre les rails et les services
Parcours de maîtrise
Douze semaines, de cent vingt à cent cinquante heures, plus de vingt-cinq travaux pratiques et un projet final — de la distinction hub et switch à l’architecture de production.
Niveau 1 · Semaine 1 · TP 1
Fondamentaux
Distinguer ce que le vocabulaire du métier confond.
- Hub, switch, passerelle de paiement, passerelle d’API, bus d’intégration
- Orchestration, rail, dispositif, participant, système de tenue de compte
- Compensation, règlement, canal
- Première architecture conceptuelle dessinée
Niveau 2 · Semaine 2 · TP 2 et 3
Installation
Déployer l’environnement et savoir expliquer chaque composant.
- Conteneurs, orchestration, paquets de déploiement
- Configuration, secrets, exposition, résolution de noms
- Journaux et diagnostic
- Capacité à expliquer le rôle de chaque composant déployé
Niveau 3 · Semaine 3 · TP 4
Architecture interne
Cartographier les familles de composants.
- Connecteurs de canal, de système de comptes, de rail
- Moteur de flux, exploitation, import et export
- Pour chaque composant : responsabilité, protocole, entrées, sorties
- Dépendances, données manipulées, exigences de sécurité
Niveau 4 · Semaine 4 · TP 5 et 6
Flux et modélisation
Décrire un paiement comme un processus, pas comme un appel.
- Notation de processus, tâches de service, messages, rappels
- Expiration, nouvelle tentative, compensation
- États et identifiant de corrélation
- Flux de référence : valider, retrouver le bénéficiaire, coter, autoriser, transférer
Niveau 5 · Semaine 5 · TP 7 et 8
Intégration du cœur bancaire
Relier le hub au système qui tient les comptes.
- Recherche et validation de compte, consultation de solde
- Débit, crédit, transaction, journal
- Idempotence des ordres
- Scénario complet depuis un client jusqu’au paiement
Niveau 6 · Semaine 6 · TP 9 à 12
Intégration d’un dispositif
Raccorder le hub à un dispositif de paiement instantané.
- Recherche du bénéficiaire
- Cotation puis transfert
- Rappels asynchrones et corrélation
- Traitement des erreurs remontées par le dispositif
Niveau 7 · Semaine 7 · TP 13
Ingénierie de connecteur
Construire son propre connecteur plutôt que d’utiliser ceux des autres.
- Fonctions minimales : initier, consulter le statut, recevoir un rappel, exposer la santé
- Authentification et interface
- Tâches de traitement, correspondance des champs, tests
- Gestion des erreurs et des cas limites
Niveau 8 · Semaine 8 · TP 14 et 15
Routage
Décider dynamiquement par où passe un paiement.
- Critères : devise, pays, montant, coût, disponibilité, type de paiement, risque
- Écriture et test d’une règle de routage
- Repli sur un second rail quand le premier est indisponible
- Continuité du paiement malgré la bascule
Niveau 9 · Semaine 9 · TP 16 à 18
Paiements de masse
Traiter le versement social et salarial à grande échelle.
- Import de masse par fichier ou par interface
- Découpage en sous-lots et suivi
- États : abouti, échoué, en attente, à relancer
- Restitution et reporting au donneur d’ordre
Niveau 10 · Semaine 10 · TP 19
Exploitation et observabilité
Voir ce qui se passe, en transactions comme en lots.
- Suivi des transactions, des lots, des flux et des connecteurs
- Latence, erreurs, relances, disponibilité
- Tableau de bord : débit, taux de réussite, latence au 95e centile
- Transactions en attente, expirations, relances
Niveau 11 · Semaine 11 · TP 20 à 22
Sécurité
Sécuriser les interfaces et les flux entre composants.
- Délégation d’autorisation, jetons, chiffrement mutuel
- Gestion des identités et des rôles : opérateur, administrateur, auditeur
- Gestion des secrets et infrastructure à clés
- Sécurisation des échanges entre le hub et ses connecteurs
Niveau 12 · Semaine 12 · TP 23 à 26
Architecture de hub
Passer d’intégrateur à architecte.
- Haute disponibilité, mise à l’échelle horizontale, partitionnement, régulation de charge
- Résilience : relance, expiration, coupe-circuit, file d’échec, compensation
- Reprise après sinistre et réplication
- Tests de panne : connecteur, composant de flux, rail indisponible, message dupliqué
Le parcours se valide sur preuve. Chaque niveau se franchit par une démonstration en conditions réelles devant un jury, avec un critère d’acceptation écrit à l’avance — la règle de la Méthode SAKITI appliquée au laboratoire.
Le flux de référence
Sept étapes, que l’on retrouve derrière presque tous les paiements orchestrés. Le niveau 4 consiste à les décrire comme un processus, pas comme une suite d’appels.
L’exigence qui ne se négocie pas
Elle figure en toutes lettres dans le niveau 12 du parcours, et elle conditionne la validation finale.
Aucun double paiement. Les tests de panne — connecteur arrêté, composant de flux indisponible, rail muet, message dupliqué injecté — n’ont qu’un seul juge : le système a-t-il payé deux fois ? Un hub qui échoue sur ce point n’est pas un hub perfectible, c’est un hub inutilisable.
Sur quoi se décide un routage
Neuf critères, combinables. Une règle de routage lisible en est la traduction directe.
- 01Devise et pays
- 02Montant
- 03Coût du rail
- 04Disponibilité constatée
- 05Participant destinataire
- 06Type de paiement
- 07Engagement de service
- 08Niveau de risque
Le projet final
Suivre un paiement de bout en bout, à travers toutes les couches construites pendant le parcours.
La validation finale
Quinze démonstrations à produire pour obtenir le niveau expert du parcours.
- 01Expliquer l’architecture d’un hub de paiement et déployer son environnement
- 02Intégrer un cœur bancaire, puis un rail de paiement
- 03Construire un connecteur et orchestrer un flux de paiement
- 04Mettre en œuvre du routage et traiter des paiements de masse
- 05Observer les transactions de bout en bout et sécuriser interfaces et flux
- 06Gérer erreurs, relances et expirations, et démontrer l’idempotence
- 07Éprouver des scénarios de panne, documenter l’architecture, défendre le projet final
Une réserve sur la pile technique
Le laboratoire assemble beaucoup d’outils autour du hub.
La pile citée dans le parcours est une pile de laboratoire. Elle ne constitue pas la liste des dépendances obligatoires du hub, et ne doit pas être lue comme telle par une équipe qui évalue la charge d’un déploiement réel.
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | mifos.org |
| Dépôt public | github.com/openMF/ph-ee-env-labs |
À vérifier au moment de la qualification. Licence exacte, version courante, activité du projet, gestion des vulnérabilités et conditions de support évoluent. Le statut affiché sur ce radar ne vaut ni certification, ni aptitude au déploiement en production dans une infrastructure de paiement.
Les autres briques du domaine
Prowide ISO 20022 · Prowide Core · Apache Camel · Apache NiFi · Kafka Connect