Deux institutions, deux rôles
L’université porte les parcours ; le laboratoire fournit l’environnement.
| Entité | Ce dont elle répond |
|---|---|
| UMS | Conception des parcours, pédagogie, évaluation et attestations internes |
| OPPL | Laboratoires, environnements techniques et projets appliqués |
Une règle qui ne souffre aucune exception. Les transactions et les fonds utilisés en formation sont strictement simulés. Aucun flux réel, aucun compte réel, aucune connexion à un système en exploitation.
Six niveaux, cinquante-deux semaines
Environ douze mois hors pauses. L’admission directe à un niveau supérieur peut être envisagée après évaluation diagnostique.
| Niveau | Objectif | Preuve de compétence |
|---|---|---|
| P0 · 4 sem. | Payment Explorer — acteurs, flux, standards, licences, chaîne de valeur | Cartographie d’un paiement de bout en bout |
| P1 · 8 sem. | Payment Builder — API de paiement simulée, compte, journal, service d’autorisation | Service fonctionnel et ses tests |
| P2 · 8 sem. | Payment Integrator — connecter des services, transformer des messages, gérer les erreurs | Connecteur ISO 8583 vers ISO 20022, en simulation |
| P3 · 10 sem. | Payment Platform Engineer — conteneurs, orchestration, chaîne de livraison, passerelle, secrets | Plateforme déployée et automatisée |
| P4 · 10 sem. | Payment Reliability & Security Engineer — sécuriser, superviser, éprouver la résilience, gérer les incidents | Rapport d’audit technique et exercice de reprise |
| P5 · 12 sem. | Payment Systems Architect — concevoir une architecture complète et justifier les choix | Architecture de référence et soutenance |
Les durées et modalités restent à valider lors d’une cohorte pilote.
Douze laboratoires techniques
Chaque laboratoire s’appuie sur des briques du radar technologique, dont les fiches détaillent le parcours de maîtrise. Les liens ci-dessous y conduisent directement.
| Laboratoire | Briques étudiées | Compétences visées |
|---|---|---|
| 01 | Fineract, Formance, TigerBeetle | Comptes, écritures, soldes, invariants comptables |
| 02 | jPOS, Moov ISO8583 | Messages cartes, autorisation, switch simulé |
| 03 | Prowide, Payment Hub EE | Validation et transformation de messages financiers |
| 04 | Mojaloop et simulateurs | Transferts, états, gestion des échecs |
| 05 | Hyperswitch | Routage, orchestration, nouvelles tentatives |
| 06 | Open Payments, Keycloak | Interfaces, identité, autorisations, consentement |
| 07 | Connecteurs et simulateurs pédagogiques | Interopérabilité entre systèmes et devises fictives |
| 08 | Moov Watchman, moteurs de règles | Scénarios de détection et alertes |
| 09 | SoftHSM2, OpenBao, Keycloak | Clés, certificats, secrets, cryptographie |
| 10 | Kafka, Temporal | Événements et flux distribués |
| 11 | OpenTelemetry, Prometheus, Grafana | Rapprochement, métriques, traces, incidents |
| 12 | Simulateurs de dépôts tokenisés | Modèles de jetons, règlement, conservation |
Vérifications préalables obligatoires. Licences exactes et dépendances, disponibilité des éditions ouvertes, maintenance, sécurité, documentation et conditions d’utilisation de chaque projet. Cette sélection n’atteste ni leur maturité ni leur caractère intégralement ouvert.
Le projet intégrateur
Une plateforme de paiement simulée, assemblée couche par couche au fil des niveaux.
| Couche | Ce qu’elle porte |
|---|---|
| Applications clientes | Mobile, web, banque fictive |
| Interface et passerelle | Authentification, contrôle d’accès, routage |
| Plateforme d’intégration | ISO 8583, ISO 20022, transformation, journal |
| Services et connecteurs | Orchestration, fraude, rapprochement ; switch et systèmes externes simulés |
| Registre et règlement | Comptabilisation, compensation, règlement fictif |
| Socle transversal | Identités, infrastructure à clés, orchestration, sécurité applicative, observabilité |
Le livrable final. La démonstration d’une transaction de bout en bout, de l’initiation à la comptabilisation et au rapprochement, avec ses échecs, ses reprises et ses traces. Un connecteur peut viser un simulateur inspiré des principes d’un dispositif de paiement instantané — sans prétendre y être connecté, certifié ou homologué.
La cohorte pilote
| Période | Activités |
|---|---|
| Mois 1 | Référentiel, sélection technique, environnements, formateurs et tests |
| Mois 2 | Recrutement indicatif de quinze à vingt apprenants, diagnostic, niveau P0 |
| Mois 3 – 4 | Niveau P1 : développement de services et preuves individuelles |
| Mois 5 – 6 | Niveau P2 : intégration, projet collectif et soutenance |
Infrastructure minimale envisagée : machines virtuelles, conteneurs, dépôt de code, chaîne de livraison, registre d’images et supervision. L’orchestration peut être introduite progressivement. Le budget et le dimensionnement supposent des tests et une définition précise des travaux pratiques.
Évaluation et portfolio
| Critère | Poids indicatif |
|---|---|
| Développement et intégration | 30 % |
| Sécurité et fiabilité | 20 % |
| Tests et documentation | 20 % |
| Compréhension des paiements | 15 % |
| Soutenance technique | 15 % |
Le portfolio rassemble le code, les schémas d’architecture, les tests, les rapports d’incidents et les démonstrations. La pondération reste à valider, et aucun seuil de réussite n’est encore arrêté.
Sur la portée des attestations. Elles décrivent les compétences effectivement évaluées. Elles ne doivent être présentées ni comme des diplômes reconnus par un État, ni comme des certifications officielles de fondations tierces sans autorisation correspondante.
Les fonctions visées
- ·Développeur de services de paiement
- ·Ingénieur d’intégration
- ·Ingénieur plateformes de paiement et sécurité applicative
- ·Ingénieur fiabilité et sécurité des paiements
- ·Architecte de systèmes de paiement
Ce sont des objectifs de formation, sans garantie d’emploi ni d’aptitude immédiate à occuper chacun de ces postes.
Le laboratoire qui accueille les apprenants
L’OPPL fournit les environnements et les projets appliqués : quatre travaux publiés, un radar de soixante-douze briques et une cohorte de dix juniors.