Ce que c’est
Base de données transactionnelle spécialisée dans les écritures financières débit-crédit, orientée débit élevé.
Ce qu’on y travaille dans le laboratoire
- ·Éprouver la tenue en charge d’un grand livre
- ·Comparer performance et garanties avec une base relationnelle classique
- ·Étudier le coût réel d’une écriture financière
Parcours de maîtrise
Vingt niveaux, vingt laboratoires, huit à douze semaines et cinq paliers de certification — du mini-registre sur papier à la plateforme de paiement temps réel.
Niveau 1 · 1 semaine · LAB 1 · mini-registre sur papier
Fondamentaux du registre
Poser le vocabulaire comptable avant de toucher à l’outil.
- Compte, débit, crédit, solde, journal
- Partie double, actif, passif, produit, charge
- Solde en attente et solde définitif
Niveau 2 · 2 jours · LAB 2
Installation
Démarrer un environnement de développement.
- Installation locale et grappe de développement
- Clients disponibles selon le langage
- Chaîne application, client, moteur
Niveau 3 · 3 jours · LAB 3 · cent portefeuilles
Comptes
Comprendre l’objet le plus simple, et ses quatre soldes.
- Identifiant, registre, code, indicateurs
- Débits et crédits, en attente puis définitifs
- Comptes immuables : ce qui ne se modifie jamais
Niveau 4 · 1 semaine · LAB 4 · transfert entre particuliers
Transferts
Écrire et relire des mouvements.
- Création de comptes et de transferts
- Consultation de comptes et de transferts
- Premier transfert entre deux portefeuilles
Niveau 5 · 3 jours · LAB 5
Idempotence et fiabilité
La propriété qui évite le double paiement.
- Identifiant de transfert comme clé de déduplication
- Relance, rejeu, sémantique d’exactement une fois
- Dix relances après expiration réseau, un seul mouvement financier
Niveau 6 · 1 semaine · LAB 6 · autorisation de carte
En attente, définitif, annulé
Modéliser l’autorisation puis la capture.
- Autorisation produisant un mouvement en attente
- Capture le rendant définitif
- Annulation libérant les fonds retenus
Niveau 7 · 1 semaine · LAB 7 · paiement marchand
Registre de paiement en partie double
Relier clients, marchands et comptes de frais.
- Comptes clients, comptes marchands, comptes de frais
- Paiement client vers marchand et commission
- Règlement au marchand
Niveau 8 · 1 semaine · LAB 8
Transaction multi-transferts
Un paiement, plusieurs bénéficiaires, une seule transaction.
- Répartition entre marchand, acquéreur, switch et réseau
- Atomicité de l’ensemble
- Aucune écriture isolée ne doit pouvoir passer seule
Niveau 9 · 1 semaine · LAB 9
Conception du registre
Structurer avant de coder.
- Un registre par devise
- Codes de comptes : client, marchand, règlement, frais, compensation
- Contraintes posées à la création des transactions
Niveau 10 · 3 jours · LAB 10
Contrôles de solde
Interdire le découvert par construction.
- Contrainte empêchant les débits d’excéder les crédits
- Contrainte symétrique pour les comptes de passif
- Un paiement supérieur au solde est rejeté par le moteur, pas par le code applicatif
Niveau 11 · 3 jours · LAB 11
Annulation et remboursement
Corriger sans réécrire l’histoire.
- Remboursement partiel et total
- Annulation d’une opération
- Écritures compensatrices, historique préservé
Niveau 12 · 1 semaine · LAB 12
Règlement
Passer des transactions aux positions.
- Acteurs simulés : émetteur, acquéreur, marchand, switch, réseau, banque de règlement
- Positions brutes, positions nettes, positions de règlement
- Dix banques, cent marchands, dix mille paiements
Niveau 13 · 1 semaine · LAB 13
Monétique et registre
Relier le monde de la carte au registre.
- Correspondance des messages financiers vers des transferts
- Annulation et avis d’annulation
- Chaîne terminal, switch, service de paiement, registre
Niveau 14 · 1 semaine · LAB 14
Messagerie normalisée et registre
Relier le monde ISO 20022 au registre.
- Débiteur, créditeur, montant, devise, identifiant de transaction
- Traduction en comptes et en transferts
- Cohérence des références de bout en bout
Niveau 15 · 1 semaine · LAB 15 · interface du registre
Interfaces de paiement
Exposer le registre sans le laisser à nu.
- Points d’accès : paiements, remboursements, transferts, soldes, transactions
- Passerelle en frontal
- Contrats d’interface et gestion des erreurs
Niveau 16 · 1 semaine · LAB 16
Registre événementiel
Diffuser ce que le registre enregistre.
- Capture des changements et publication sur un bus
- Événements : paiement créé, comptabilisé, remboursé, réglé
- Consommateurs : fraude, rapprochement, notifications, analyse
Niveau 17 · 1 semaine · LAB 17
Rapprochement
Confronter le registre aux systèmes extérieurs.
- Écarts avec le switch, la banque, le réseau
- Transaction manquante, duplicata, montant erroné
- Compte erroné, règlement tardif
Niveau 18 · 1 semaine · LAB 18
Haute disponibilité
Exploiter une grappe.
- Déploiement, matériel, supervision
- Mise à jour et reprise
- Perte d’un nœud, coupure réseau, redémarrage
Niveau 19 · 3 jours · LAB 19 · générateur de charge
Performance
Mesurer honnêtement, dans son propre environnement.
- Montée en charge par paliers
- Latence, débit, processeur, disque, réseau
- Effet de la taille des lots
Niveau 20 · 1 semaine · LAB 20 · plateforme complète
Architecture de registre
Décider ce qui appartient au registre, et ce qui n’y appartient pas.
- Registre financier d’un côté, base métier de l’autre
- Quand employer un bus, un cache, une base relationnelle
- Observabilité, sécurité, audit et reprise
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.
L’exercice qui résume le parcours
Le laboratoire du niveau 5 tient en trois lignes, et il décide de tout le reste.
Une requête de paiement, une expiration réseau, dix relances. Résultat attendu : un seul transfert financier. Un registre qui échoue ici ne protège rien — et aucune couche applicative ne rattrapera durablement cette faiblesse.
Un paiement, quatre bénéficiaires, une transaction
Le niveau 8 impose l’atomicité : soit les quatre mouvements passent, soit aucun. Aucune écriture ne doit pouvoir aboutir seule.
Le découvert interdit par construction
Le niveau 10 déplace un contrôle métier vers le moteur lui-même. C’est une différence de nature, pas de confort.
| Contrainte | Ce qu’elle garantit |
|---|---|
| Les débits ne peuvent excéder les crédits | Un compte client ne peut pas passer sous zéro, quelle que soit l’erreur applicative |
| Les crédits ne peuvent excéder les débits | Symétrique, pour les comptes de passif et de garantie |
| Rejet par le moteur | Un paiement de douze mille sur un solde de dix mille est refusé avant toute écriture |
Ce que le registre ne doit pas contenir
Le niveau 20 est une leçon d’architecture : savoir ce qu’on n’y met pas.
- 01Le registre financier tient les comptes, les mouvements et les soldes
- 02La base métier tient les clients, les commandes, les métadonnées et l’historique applicatif
- 03Le bus d’événements diffuse ; il ne fait pas autorité
- 04Le cache accélère ; il ne conserve rien de financier
- 05Se tromper de frontière produit un registre lent, ou une base métier fausse
Les cinq paliers de certification
La progression vise un rôle identifiable, du développeur à l’architecte.
| Palier | Ce qu’il atteste |
|---|---|
| Fundamentals | Vocabulaire comptable, comptes, soldes, premiers transferts |
| Developer | Transferts, idempotence, états en attente et définitifs, contrôles de solde |
| Payment Ledger Engineer | Paiements réels, multi-transferts, remboursements, règlement |
| Distributed Ledger Engineer | Grappe, haute disponibilité, reprise, performance mesurée |
| Payment Ledger Architect | Interface, registre, règlement, rapprochement, diffusion d’événements, haute disponibilité, observabilité |
Le projet final
Une plateforme de registre temps réel couvrant l’ensemble des cas travaillés.
- 01Transfert entre particuliers et paiement marchand
- 02Autorisation, capture, remboursement, annulation
- 03Frais, compensation, règlement, multi-devises
- 04Rapprochement, diffusion d’événements, observabilité
Deux réserves à conserver
Elles figurent dans le parcours, et elles évitent deux erreurs coûteuses.
Les seuils de performance cités dans le parcours sont des objectifs d’exercice. Les performances réelles se mesurent dans l’environnement du laboratoire, et ne constituent aucune garantie produit.
Le moteur est positionné comme registre transactionnel financier spécialisé. Il ne remplace ni une base relationnelle, ni la base métier d’une institution.
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | tigerbeetle.com |
| Dépôt public | github.com/tigerbeetle/tigerbeetle |
À 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 · Formance Ledger · Open Bank Project