Ce que c’est
Plateforme de diffusion d’événements adaptée aux applications critiques.
Ce qu’on y travaille dans le laboratoire
- ·Publier le cycle de vie d’un paiement sous forme d’événements
- ·Rejouer une séquence pour reconstituer un incident
- ·Comprendre le paiement comme machine à états plutôt que comme appel
Parcours de maîtrise
Sept niveaux, douze semaines, de cent vingt à cent cinquante heures et trente travaux pratiques — du premier événement à la dorsale événementielle d’une plateforme de paiement.
Niveau 1 · Semaines 1 et 2 · TP 1 à 6 · Foundations
Fundamentals
Comprendre les concepts et envoyer ses premiers événements.
- La bascule mentale : penser en événements plutôt qu’en appels
- Messages, sujets, partitions
- Installation et premier producteur, premier consommateur
- Ce qu’est réellement un événement de paiement
Niveau 2 · Semaines 3 et 4 · TP 7 à 12 · Reliability
Core
Développer des producteurs et des consommateurs fiables.
- Courtiers, sujets, partitions, réplication
- Producteurs avancés : accusés de réception, regroupement en lots
- Consommateurs, groupes, décalages de lecture, rééquilibrage
- Clés de partitionnement et ordre des événements
Niveau 3 · Semaines 5 et 6 · TP 13 à 18 · Integration
Intégration
Connecter le bus aux systèmes de paiement existants.
- Contrats de données et registre de schémas
- Connecteurs entrants et sortants
- Intégration avec les bases de données
- Capture des changements et file d’attente d’échec
Niveau 4 · Semaines 7 et 8 · TP 19 à 24 · Payment Streaming
Traitement en flux
Traiter les événements en temps réel, à grande échelle.
- Filtrage, transformation, agrégation
- Fenêtres temporelles et jointures de flux
- Détection de doublons et rapprochement
- Premiers cas d’usage de détection de fraude
Niveau 5 · Semaines 9 et 10 · TP 25 à 30 · Production
Exploitation
Opérer une grappe robuste et sécurisée.
- Architecture de la grappe et haute disponibilité
- Sécurité : chiffrement du transport, authentification, listes de contrôle d’accès
- Supervision et indicateurs de retard de consommation
- Performance, réglage, tests de charge
Niveau 6 · Semaines 11 et 12 · Niveau 6
Paiements
Concevoir des architectures de paiement événementielles.
- Schémas distribués : transaction longue, boîte d’envoi transactionnelle, séparation lecture-écriture, historisation des événements
- Relance, file d’attente d’échec, rejeu, idempotence
- Cycle de vie complet d’un paiement en événements
- Intégration monétique, messagerie normalisée, paiement instantané, cœur bancaire
Niveau 7 · En continu · Niveau 7
Architecte
Concevoir et conduire des plateformes de paiement critiques.
- Architecture distribuée complète
- Planification de capacité, objectifs de service, procédures d’exploitation
- Résilience et reprise après sinistre
- Déploiement déclaratif et conduite technique d’équipe
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 cycle de vie d’un paiement, en événements
Sept événements successifs. C’est la traduction, pour le laboratoire, de ce qu’une architecture événementielle apporte à un paiement : chaque étape devient observable, rejouable et auditable.
Les trente travaux pratiques
Cinq blocs de six, du premier démarrage au déploiement en production.
TP 1 à 6 — Fondations
- Installer le bus
- Explorer l’architecture d’une grappe
- Créer sujets et partitions
- Construire un producteur
- Construire un consommateur
- Expérimenter les groupes de consommateurs
TP 7 à 12 — Fiabilité
- Configurer la réplication
- Étudier les décalages de lecture
- Provoquer un rééquilibrage
- Simuler la panne d’un courtier
- Implémenter l’idempotence
- Tester les transactions
TP 13 à 18 — Intégration
- Base de données vers le bus
- Bus vers base de données
- Connecteurs
- Capture des changements
- Contrats de données et registre de schémas
- Interface REST vers le bus, avec file d’échec
TP 19 à 24 — Flux de paiement
- Premier traitement en flux
- Routage de paiements
- Agrégation temps réel
- Détection de doublons
- Rapprochement
- Détection simple de fraude
TP 25 à 30 — Production
- Chiffrement du transport
- Authentification et contrôle d’accès
- Supervision et tableaux de bord
- Tests de charge et retard de consommation
- Test de chaos et reprise
- Déploiement orchestré
Ce que le projet final doit porter
Onze exigences, qui distinguent une démonstration d’un système exploitable.
- 01Identifiant de corrélation traversant toute la chaîne
- 02Clé d’idempotence et horodatages
- 03Piste d’audit complète
- 04Relance, file d’attente d’échec, rejeu
- 05Supervision et tableau de bord
- 06Sécurité et déploiement orchestré
Les schémas distribués à maîtriser
Le niveau 6 les traite tous, parce qu’aucun paiement fiable ne s’en passe.
| Schéma | Ce qu’il résout |
|---|---|
| Transaction longue | Enchaîner plusieurs étapes sans transaction globale, avec compensation en cas d’échec |
| Boîte d’envoi transactionnelle | Garantir qu’un événement est publié si et seulement si l’écriture métier a eu lieu |
| Séparation lecture-écriture | Servir les consultations sans peser sur le chemin d’écriture |
| Historisation des événements | Reconstituer un état à partir de la suite des faits, et non l’inverse |
| Rejeu | Reconstruire un consommateur, ou refaire un calcul, sans rejouer les paiements |
Une distinction à garder en tête
Sur le rôle du bus dans une architecture financière.
Le bus d’événements transporte et conserve ; il ne fait pas autorité sur les soldes. La source de vérité financière reste le registre. Confondre les deux produit des réconciliations impossibles — c’est l’erreur la plus fréquente des architectures événementielles appliquées au paiement.
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | kafka.apache.org |
| Dépôt public | github.com/apache/kafka |
À 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
NATS · RabbitMQ · Apache Pulsar · Temporal · Apache Flink