Ce que c’est
Moteur de flux durables, avec reprise et relance automatiques.
Ce qu’on y travaille dans le laboratoire
- ·Écrire un paiement comme un flux durable plutôt qu’une suite d’appels
- ·Traiter les compensations et les annulations
- ·Survivre à un redémarrage au milieu d’une transaction
Parcours de maîtrise
Huit niveaux, trente travaux pratiques, une soixantaine d’heures — de l’exécution durable à l’architecture complète d’orchestration des paiements.
Niveau 1 · ≈ 4 h · 3 TP · TP 1 à 3
Foundations
Comprendre l’exécution durable et l’architecture du moteur.
- Exécution durable : un processus qui survit aux pannes et aux redémarrages
- Espace de noms, file de tâches, historique d’exécution
- Flux et activités : la logique métier d’un côté, les appels externes de l’autre
- Installation, interface en ligne de commande, console d’observation
Niveau 2 · ≈ 8 h · 4 TP · TP 4 à 7
Developer
Maîtriser les bases du développement.
- Flux, activités, exécutants, client
- Paramètres, résultats, appels vers l’extérieur
- Premier flux de paiement : valider, débiter, notifier
- Déclenchement depuis une interface REST
Niveau 3 · ≈ 8 h · 4 TP · TP 8 à 11
Reliability
Construire des flux qui résistent aux défaillances.
- Politique de relance et attente exponentielle
- Expirations : de démarrage à fin, battement de cœur
- Annulation et traitement des échecs
- Activités idempotentes et rejeu de l’historique
Niveau 4 · ≈ 8 h · 4 TP · TP 12 à 15
Workflow Engineering
Aller au-delà du flux linéaire.
- Signaux, interrogations, minuteries
- Flux enfants et poursuite sous nouvelle exécution
- Versionnement d’un flux en cours d’exécution
- Intervention humaine dans la boucle
Niveau 5 · ≈ 10 h · 5 TP · TP 16 à 20
Payment Workflows
Appliquer l’orchestration aux rails du laboratoire.
- Flux de paiement par carte, adossé à la monétique
- Flux de paiement en messagerie normalisée
- Flux de paiement instantané
- Écriture au registre et orchestration multi-prestataires
Niveau 6 · ≈ 8 h · 4 TP · TP 21 à 24
Distributed Architecture
Traiter la transaction distribuée et sa compensation.
- Transaction longue : débiter, transférer, créditer
- Compensation automatique quand la dernière étape échoue
- Articulation avec le bus d’événements
- Orchestration entre plusieurs prestataires
Niveau 7 · ≈ 8 h · 3 TP · TP 25 à 27
Production
Déployer et exploiter le moteur.
- Installation autonome puis orchestrée
- Haute disponibilité et persistance
- Sécurité, secrets, chiffrement du transport
- Métriques, journaux, traces, supervision, sauvegarde
Niveau 8 · ≈ 6 h · 3 TP · TP 28 à 30
Architecte
Concevoir l’architecture complète d’orchestration durable.
- Moteur de transaction longue pour le paiement
- Orchestrateur multi-rails : instantané, carte, portefeuille, prestataire
- Gouvernance, montée en charge, bonnes pratiques
- Projet final : moteur de paiement durable
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ègle de répartition des rôles
C’est le principe le plus utile du parcours, et il vaut bien au-delà de cet outil : chaque composant d’une chaîne de paiement fait une chose, et une seule.
| Composant | Ce dont il répond |
|---|---|
| Bus d’événements | Transporter les événements |
| Moteur d’orchestration | Conduire les processus durables |
| Registre | Enregistrer la vérité financière |
| Connecteurs | Parler aux rails de paiement |
| Plateforme d’intégration | Intégrer, router, transformer |
| Couche de services | Exposer les services métier |
Le point de vigilance du niveau 3
Il conditionne tout l’intérêt de l’orchestration durable.
Une relance d’orchestration ne doit jamais provoquer un double débit. Chaque opération financière doit donc porter ses propres mécanismes d’idempotence, de corrélation et de contrôle d’état métier. Le moteur garantit que le processus reprendra ; il ne garantit pas que l’opération financière n’aura lieu qu’une fois — c’est au concepteur de l’assurer.
La transaction longue et sa compensation
Le schéma du niveau 6 : trois étapes, et ce qui se passe quand la dernière échoue.
Un flux avec intervention humaine
Le cas du niveau 4, le plus parlant pour une direction : un contrôle de risque qui suspend le paiement jusqu’à décision d’un opérateur, sans perdre l’état du processus.
Les douze scénarios du projet final
Chacun met à l’épreuve une propriété différente du moteur.
- 01Paiement simple, puis asynchrone
- 02Paiement avec expiration, et paiement nécessitant une validation
- 03Paiement multi-rails
- 04Relance contrôlée, compensation, annulation
- 05Écriture au registre et publication d’événements
- 06Rapprochement, et reprise après panne d’un exécutant
La progression métier visée
Six paliers, du développeur à l’architecte de l’orchestration durable.
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | temporal.io |
| Dépôt public | github.com/temporalio/temporal |
À 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 Kafka · NATS · RabbitMQ · Apache Pulsar · Apache Flink