• Architecture
  • UniversitĂ©
  • AvancĂ©
  • 2h00

❌ [ANNULÉ] ❌

  • Date mercredi
  • Horaire 8h00 Ă  10h00
  • Salle Amphi B

Actions rapides


Les sessions futures sur le mĂȘme thĂšme

    • Architecture
    • ConfĂ©rence

    Rejouer une partie, rejouer le systĂšme de la matrice : des replays de jeux vidĂ©o Ă  l’event sourcing

    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.

    Mercredi 15h00 Ă  15h55 - Amphi E
    • 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

    Cache-moi si tu peux : patterns et piĂšges du cache en production

    "On va mettre un cache, ça ira plus vite." Cette phrase a dĂ©jĂ  coĂ»tĂ© des nuits blanches Ă  bien des Ă©quipes. Le cache est souvent introduit comme une "optimisation" rapide Ă  mettre en place. En rĂ©alitĂ©, il transforme profondĂ©ment le comportement d'un systĂšme : cohĂ©rence Ă©ventuelle, donnĂ©es obsolĂštes, effets de bord distribuĂ©s... et bugs impossibles Ă  reproduire. Aujourd'hui, ces mĂȘmes dĂ©fis rĂ©apparaissent dans les architectures intĂ©grant des LLMs, avec l'Ă©mergence de modĂšles comme le *semantic caching*. Partons ensemble pour un voyage pragmatique dans le monde du cache : - ce qu'est rĂ©ellement un cache (et ce qu'il n'est pas), - les principaux patterns de caching et leurs compromis, - les anti-patterns classiques qui transforment une application rapide en cauchemar opĂ©rationnel, - un arbre de dĂ©cision pour choisir la bonne stratĂ©gie. Cette session vous donnera les outils pour construire des systĂšmes rapides et prĂ©visibles, et vous aidera Ă  ne plus jamais considĂ©rer le cache comme un simple dĂ©tail d'implĂ©mentation.

    Jeudi 11h30 Ă  12h25 - Amphi B