Dans la plupart des jeux vidéo modernes, un “replay” n’est pas une vidéo mais une simple liste d’événements : les inputs des joueurs, quelques événements système et un état initial minimal. Pour revoir une partie, le moteur ne fait “que” tout rejouer dans l’ordre et reconstruit ainsi l’intégralité de la session. 🎮📜

Côté backend, l’event sourcing applique exactement la même idée : au lieu de stocker uniquement l’état courant, on enregistre la chronologie des décisions métier (events) qui ont mené à cet état. On peut alors “remonter le temps” pour débuguer un bug tordu, auditer un comportement étrange, ou reconstruire un système sur une nouvelle architecture.

Dans ce talk, on partira de cas concrets côté jeux (replays, rewind, killcams) pour expliquer pas à pas :
- comment fonctionne un système de replay basé sur un log d’événements,
- en quoi ce modèle diffère d’une approche CRUD classique,
- ce que l’event sourcing reprend de cette idée pour nos SI.

Je montrerai un mini-système de replay dans un petit jeu ainsi qu’un exemple d’event store côté backend (Java/TypeScript), sans masquer les limites : coût de relecture, complexité, tooling… 🎯

Public cible : dévs backend / fullstack, architectes, curieux d’architecture qui aiment les métaphores vidéoludiques 💾

Plan proposé
1 - “Un replay, ce n’est pas une vidéo”
Comment les jeux enregistrent une partie : log d’événements + état initial.
Démo simple : rejouer une partie en réinjectant les inputs dans une boucle de jeu.

2 -De la partie au système : introduction concrète à l’event sourcing
Modèle CRUD vs modèle “flux d’événements rejoués”.
Notions d’event store, projection/lecture, relecture d’événements.

3 - Cas d’usage réels : debug, audit, résilience
Time-travel debugging, audit, reconstruction d’état / migration.

4 - Limites, pièges et conseils pragmatiques
Coût de la relecture, snapshots, complexité pour les équipes, tooling et quand ne PAS utiliser l’event sourcing.