Ce que c’est
Grand livre financier programmable en partie double, conçu pour les systèmes de paiement.
Ce qu’on y travaille dans le laboratoire
- ·Modéliser un plan de comptes et ses mouvements
- ·Séparer la tenue de compte de la comptabilisation
- ·Comparer sa logique à celle du grand livre intégré au cœur bancaire
Parcours de maîtrise
Six niveaux, vingt-quatre modules, une quarantaine de travaux pratiques et un projet final — du principe de la partie double à l’architecture d’un registre de paiement.
Niveau 1 · 4 modules · 5 TP · Niveau L1
Ledger Fundamentals
Comprendre un registre financier avant de manipuler l’outil.
- Rôle d’un registre, journal, transactions, balances, source de vérité
- Partie double : débit, crédit, écritures équilibrées, conservation de la valeur
- Ce qui distingue cœur bancaire, switch, orchestrateur, registre et moteur de règlement
- Propriétés attendues : atomicité, immuabilité, idempotence, auditabilité, multi-actifs
Niveau 2 · 4 modules · 7 TP · Niveau L2
Formance Ledger Builder
Installer et construire un premier système financier.
- Installation, base de données, interfaces de programmation et en ligne de commande
- Plan de comptes : trésorerie, clients, marchands, frais, comptes de passage et de règlement
- Actifs, transactions, écritures, balances, multi-devises
- Métadonnées, identifiants métier, corrélation, recherche et historique
Niveau 3 · 4 modules · 8 TP · Niveau L3
Numscript Developer
Programmer la logique des mouvements financiers.
- Syntaxe : variables, comptes, montants, actifs
- Sources et destinations : un paiement qui se répartit entre plusieurs bénéficiaires
- Répartitions et commissions : place de marché, acquisition, partage de revenu, taxes
- Modèles réutilisables : entre particuliers, marchand, entrée et sortie de fonds, remboursement, annulation, règlement
Niveau 4 · 4 modules · 8 TP · Niveau L4
Payment Ledger Engineer
Reproduire des scénarios réalistes de l’industrie des paiements.
- Paiement instantané entre deux banques, paiement marchand et ses trois niveaux de frais
- Cycle de vie : initié, autorisé, retenu, capturé, réglé — et les chemins d’échec
- Compensation, positions nettes, règlement
- Cas difficiles : duplicata, expiration, relance, réponse tardive, transaction inconnue
Niveau 5 · 4 modules · 7 TP · Niveau L5
Ledger Platform Engineer
Déployer et exploiter le registre comme un composant de plateforme.
- Conteneurisation, configuration, secrets, persistance
- Orchestration : charges avec état, exposition, mise à l’échelle
- Sécurité : identités, passerelle, chiffrement, rôles, audit
- Observabilité, sauvegarde, restauration, plan de reprise, tests de charge
Niveau 6 · 4 modules · 5 TP · Niveau L6
Payment Ledger Architect
Positionner le registre dans une infrastructure de paiement complète.
- Responsabilités respectives : cœur bancaire, switch, hub, orchestrateur, registres
- Registre événementiel : alimentation du rapprochement, du reporting, de la fraude
- Haute disponibilité, partitionnement, réplication, objectifs de reprise
- Revue d’architecture : modèle de comptes, modèle transactionnel, sécurité, déploiement
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.
Six objets que l’on confond, et qui ne font pas le même métier
La distinction du module 3 conditionne toute la suite : un registre n’est ni un cœur bancaire, ni un moteur de règlement.
Les six propriétés attendues d’un registre de paiement
Elles ne sont pas négociables, et chacune se vérifie par un exercice.
| Propriété | Ce qu’elle impose |
|---|---|
| Atomicité | Soit l’ensemble des écritures passe, soit rien ne passe |
| Immuabilité | Aucune modification a posteriori : on corrige par une écriture compensatrice, jamais en effaçant |
| Idempotence | Un même ordre rejoué ne produit pas deux mouvements |
| Traçabilité | Chaque mouvement porte ses références métier et son identifiant de corrélation |
| Auditabilité | L’historique complet est reconstituable et opposable |
| Multi-actifs | Devises, jetons et unités de compte coexistent sans confusion |
Un paiement marchand, vu par le registre
Dix mille unités payées par un client ne se soldent pas par une écriture, mais par quatre mouvements simultanés. C’est ce que le langage de script permet de décrire en une transaction atomique.
Le cycle de vie que le registre doit représenter
Cinq états nominaux, et quatre chemins d’échec qui doivent être aussi bien modélisés.
Les cas qui font échouer les modèles naïfs
Le niveau 4 les fait tous traverser, parce que ce sont eux que la production produit.
- 01Paiement dupliqué et rejeu du même ordre
- 02Expiration, relance, réponse tardive
- 03Transaction inconnue du registre au moment de la réponse
- 04Compensation d’une opération partiellement exécutée
- 05Rapprochement avec les systèmes amont
Le projet final
Concevoir et déployer une infrastructure de registre intégrée à une chaîne de paiement régionale complète.
- 01Plan de comptes de paiement complet
- 02Transactions programmées : entre particuliers, marchand, frais, remboursement, annulation
- 03Intégration avec les systèmes de paiement en amont
- 04Déploiement, exploitation, rapport d’architecture et de tests
- 05Recommandations pour une mise en production
Une mise en garde
Sur la place du registre dans l’étude.
Le registre ne doit pas être étudié isolément. Le laboratoire ne prend son sens qu’en le connectant progressivement au cœur bancaire, à la monétique, à la messagerie, au dispositif instantané et à l’orchestration — chacun ayant sa propre fiche dans ce radar.
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | formance.com |
| Dépôt public | github.com/formancehq/ledger |
À 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
Apache Fineract · Mifos X · Mifos Pay · TigerBeetle · Open Bank Project