0.2.0-0-pre.2-fix.1

docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Inventaire fonctionnel initial
 
@@ -331,21 +331,96 @@ Aucun provider ne doit remonter dans le kernel.
 
 ## Server services candidates
 
+### Services Web non temps réel
+
 Besoins identifiés :
 
 - auth/identity ;
 - profile ;
 - save/progression cloud ;
 - leaderboard ;
-- match/lobby ;
-- realtime authoritative session ;
-- chat éventuel ;
+- inventory/economy authoritative lorsqu'une valeur partagée existe ;
+- configuration/rulesets distants ;
 - asset metadata/CDN orchestration ;
 - administration/modération selon besoins ;
-- anti-cheat/validation serveur pour compétitif ;
-- économie/reward authority pour tout jeu avec valeur monétaire ou crypto.
+- anti-cheat/validation de résultats ;
+- reward authority pour tout jeu avec valeur monétaire ou crypto.
 
-Le déploiement peut commencer comme modular monolith sans imposer le découpage physique initial.
+Ces services peuvent être exposés en HTTP(S) et ne doivent pas être placés dans la boucle temps réel uniquement parce qu'un jeu possède aussi un mode multijoueur.
+
+### Lobby / matchmaking / session control
+
+Besoins identifiés :
+
+- création et découverte de partie ;
+- invitation/join/leave ;
+- matchmaking ;
+- allocation d'une room/session ;
+- roster de joueurs ;
+- ready/start/end ;
+- reprise de session ;
+- spectator policy éventuelle ;
+- routing vers l'instance realtime responsable.
+
+Le control plane d'une partie peut être séparé du data plane temps réel.
+
+### Realtime multiplayer server
+
+Capacités à étudier explicitement :
+
+- endpoint/gateway WebSocket ou transport realtime équivalent ;
+- authentification et attachement d'une connexion à une session ;
+- ingestion d'inputs/commands client plutôt que confiance dans un état client arbitraire ;
+- tick ou cadence serveur ;
+- simulation/état authoritative lorsque le jeu l'exige ;
+- ordre des messages, sequence numbers et déduplication ;
+- acknowledgement lorsque nécessaire ;
+- snapshots complets ;
+- deltas/patches entre snapshots ;
+- version/revision de l'état ;
+- interest management pour ne diffuser qu'un sous-ensemble pertinent du monde ;
+- broadcast/multicast par room ;
+- backpressure et limites de file ;
+- détection de timeout/heartbeat ;
+- disconnect/reconnect ;
+- reprise et resynchronisation après trou de messages ;
+- late join ;
+- spectator éventuel ;
+- historique court/replay buffer lorsque nécessaire ;
+- validation anti-cheat des inputs/actions ;
+- séparation entre données persistantes et état éphémère de session ;
+- métriques, logs, traces et health du service temps réel ;
+- horizontal scaling, room placement et transfert/rehydration éventuel d'une session.
+
+### Synchronisation client associée
+
+Les capacités client correspondantes peuvent inclure :
+
+- buffer d'inputs ;
+- interpolation ;
+- extrapolation limitée ;
+- client-side prediction ;
+- reconciliation ;
+- rollback pour les genres qui le justifient ;
+- clock/tick synchronization ;
+- snapshot application ;
+- delta application ;
+- reconnect/resync state machine.
+
+Toutes ne sont pas nécessaires pour tous les jeux. Par exemple Snake à faible fréquence, racing et fighting n'ont pas les mêmes exigences de latence ni la même stratégie de synchronisation.
+
+### Chat et présence
+
+À séparer du gameplay realtime :
+
+- présence online/offline ;
+- chat lobby ;
+- chat de partie ;
+- modération ;
+- rate limiting ;
+- historique selon produit.
+
+Le déploiement peut commencer comme modular monolith, mais les responsabilités doivent rester séparables afin que le service realtime puisse évoluer indépendamment du Web/API classique.
 
 ## Tooling candidates