Ce que c’est
Implémentation de référence d’Interledger et des API Open Payments destinée aux établissements teneurs de comptes.
Ce qu’on y travaille dans le laboratoire
- ·Faire circuler de la valeur entre deux portefeuilles de devises différentes
- ·Étudier demandes de paiement, cotations et autorisations
- ·Construire le laboratoire transfrontalier
Parcours de maîtrise
Six niveaux, cinquante travaux pratiques, environ deux cents heures — du premier paiement entre deux établissements simulés à une passerelle d’interopérabilité.
Niveau 1 · 1 semaine · ≈ 10 h · TP 1 à 3 · premier paiement entre deux établissements simulés
Explorer
Comprendre le protocole avant l’implémentation.
- Principes et architecture du routage de valeur entre grands livres
- Établissement teneur de comptes, adresse de portefeuille
- Actifs et échelle de représentation des montants
- Paiements entrants et sortants : deux objets distincts
Niveau 2 · 2 semaines · ≈ 20 h · TP 4 à 10 · projet : mini-banque raccordée
Operator
Administrer le service et ses objets.
- Composants : traitement, autorisation, interface d’administration
- Création d’actifs et gestion des adresses de portefeuille
- Cotation puis autorisation d’un paiement
- Notifications sortantes et suivi des transactions
Niveau 3 · 3 semaines · ≈ 30 h · TP 11 à 18 · projet : adaptateur bancaire
Integration Engineer
Relier le service à un système de comptes réel ou simulé.
- Adaptateur de comptes et association compte-adresse
- Réservation puis libération des fonds, gestion de la liquidité
- Traitement des notifications, intégration au registre
- Idempotence, relance, échecs, multi-actifs, conversion de devises
Niveau 4 · 3 semaines · ≈ 40 h · TP 19 à 28 · défi : trois établissements en chaîne
Interledger Payment Engineer
Concevoir, exploiter et diagnostiquer un réseau multi-participants.
- Routage et appairage entre établissements
- Analyse des paquets échangés, routage à plusieurs sauts
- Multi-devises et gestion de la liquidité insuffisante
- Observabilité, tests de performance, haute disponibilité et reprise
Niveau 5 · 4 semaines · ≈ 50 h · TP 29 à 40 · livrable : schéma directeur de production
Architect
Industrialiser avec les exigences d’une plateforme de paiement.
- Haute disponibilité et déploiement orchestré
- Gestion des secrets, identités, chiffrement mutuel
- Sécurisation des notifications entrantes, filtrage de conformité simulé
- Piste d’audit, observabilité, ingénierie du chaos et de la capacité
Niveau 6 · 4 semaines · ≈ 50 h · TP 41 à 50 · projet final : passerelle d’interopérabilité
Interoperability Architect
Positionner la brique dans une architecture d’interopérabilité régionale.
- Adaptateur vers la plateforme d’intégration
- Correspondance entre messagerie normalisée et interfaces ouvertes de paiement
- Orchestration multi-rails, routage par coût puis par disponibilité
- Simulation transfrontalière, rapprochement multi-systèmes
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.
La réserve qui encadre tout le niveau 6
Elle figure dans votre document, et elle doit rester visible.
L’architecture d’interopérabilité étudiée au dernier niveau est une hypothèse de laboratoire, destinée à être expérimentée. Elle ne constitue en aucun cas l’architecture officielle d’un dispositif régional de paiement instantané, dont la définition appartient à son opérateur.
Ce qui distingue ce laboratoire du dispositif instantané
Deux briques du radar traitent d’interopérabilité, et on les confond souvent. Elles ne répondent pas à la même question.
| Approche | Ce qu’elle suppose |
|---|---|
| Dispositif de paiement instantané | Un ensemble fermé de participants, des règles communes, une compensation et un règlement centralisés |
| Routage de valeur entre grands livres | Des établissements hétérogènes, sans dispositif commun, reliés de proche en proche — chacun ne connaît que ses voisins immédiats |
| Dans le laboratoire | Les deux coexistent : l’un pour l’interopérabilité domestique, l’autre pour le transfrontalier et le multi-devises |
Le cycle d’un paiement, côté protocole
Cinq étapes, dont deux que les interfaces classiques n’ont pas.
Le cas qui forme le plus
Le travail pratique du niveau 4 sur la liquidité insuffisante.
Dans un réseau où chaque établissement ne connaît que ses voisins, un paiement échoue rarement parce qu’il est refusé : il échoue parce qu’un intermédiaire n’a plus la liquidité nécessaire. Diagnostiquer cela suppose de savoir lire un chemin de bout en bout — c’est la compétence qui distingue un intégrateur d’un ingénieur d’interopérabilité.
Ce que le projet final doit démontrer
Dix capacités, sur un réseau reliant plusieurs établissements et plusieurs rails.
- 01Paiement, autorisation, routage
- 02Écriture au registre et traitement des notifications
- 03Rapprochement et observabilité
- 04Reprise après défaillance et sécurité
- 05Intégration multi-rails
Les six paliers de certification
De la découverte du protocole à l’architecture d’interopérabilité.
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | rafiki.dev |
| Dépôt public | github.com/interledger/rafiki |
À 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
Interledger Protocol · Open Payments · Open Payments SDK Node · Open Payments SDK Go · Open Payments SDK Rust