- Architecture
- Conférence
- 55 min
Rejouer une partie, rejouer le système de la matrice : des replays de jeux vidéo à l’event sourcing
Date mercredi
Horaire 15h00 à 15h55
Salle Amphi E
Description
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.
Orateur·ices
Pierre Fervel
Développeur fullstack senior & game dev Fullstack avec 10+ ans d'expérience : Java Spring Boot, Angular/TypeScript. Game dev passionné : Godot (C#/GDScript), game jams régulières (Global Game Jam, Ludum Dare). Conférencier : DevFest Strasbourg, BreizhCamp. Talks internes Mission : lier expertise pro et passion jeux vidéo pour des projets et des architectures résilientes sous pression 🎮💻
Actions rapides
Les sessions futures sur le même thème
- Architecture
- Conférence
Vous pensiez que la dette technique était le pire? Voici la dette de conception !
Dans nos métiers, la dette technique est sans doute la chose la plus frustrante, éprouvante et coriace contre laquelle nous devons lutter. Bien sûr, il existe des bonnes pratiques : refactoriser, viser la simplicité avec KISS, éviter de trop anticiper avec YAGNI afin de limiter cette dette au maximum. Et pourtant, on n’y vient jamais vraiment à bout. Pire encore, elle continue de s’accumuler même lorsque nous les appliquons, comme une fatalité. Et si ces mêmes bonnes pratiques ne faisaient parfois qu’empirer le problème au lieu de le résoudre ? La dette technique peut n’être que la partie visible de quelque chose de plus profond : la dette de design accidentelle. Un problème bien plus complexe, donnant lieu à des logiciels spaghettis et à des microservices en « monolithe distribué », dont nous sommes souvent à l’origine sans même nous en rendre compte. Dans cette conférence, nous explorerons les mécanismes de la dette de design et ses impacts, conséquents sur notre architecture, nos processus, notre organisation, et même notre business. À travers des exemples concrets, nous verrons comment la détecter, analyser sa profondeur et agir avant qu’elle ne s’ancre durablement.
Jeudi
8h30 à 9h25 - Amphi A- Architecture
- Conférence
Du rate limiting technique à la plateforme API monétisée : notre retour d'expérience
Fin 2025, nous avons mis en place un mécanisme de rate limiting sur nos APIs à l’aide de Spring Cloud Gateway. Début 2026, le business y voit une opportunité plus large : quotas journaliers, endpoints premium et facturation à l’usage. Nous avons du réagir et faire évoluer un mécanisme purement technique en une plateforme API beaucoup plus large : Gateway custom vs solution d’API Management sur étagère (Kong, Gravitee...) Quotas persistants vs limites court terme Gestion in-memory vs stockage Redis distribué Performance à 200 requêtes par seconde et 400k utilisateurs Observabilité interne vs exposition client Dans ce talk, nous décrirons la mise en place de notre rate limiting technique puis les dilemmes rencontrés en le transformant en plateforme API commercialisable
Jeudi
14h00 à 14h55 - Amphi A- Architecture
- Conférence
Gateway API, 10 ans de maturation pour une nouvelle API Kubernetes
Exposer une application Kubernetes au monde peut devenir un vrai casse tête 🧐. Nous avons d'un côté les API standards avec Ingress, service de `type=LoadBalancer`, voir même les NodePorts… et de l'autre, les APIs custom proposées par les Ingress Controllers et Service-Meshes très avancées mais non standard 😅 Après tant d'années de confusion, une nouvelle API, nommée Gateway API, arrive tout juste en v1.0 (🎉) pour contenter à la fois les développeurs et les opérateurs de cluster ou d'infrastructure 🤯! Nous découvrirons ensemble cette nouvelle API, ses fonctionnalités avancées et les implémentations qui vous permettrons de les utiliser dans votre cluster ⚡️!
Vendredi
8h30 à 9h25 - Amphi D