0.3.5-beta.2

docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Architecture réseau et serveur
 
@@ -21,22 +21,19 @@ Actix Web porte le Web/API, l'authentification, les comptes, Hall of Fame, metad
 
 Le realtime est séparé du Web/API classique.
 
-Baseline :
+Backends retenus :
 
 ```text
-Tokio
-tokio-tungstenite
 WebSocket
-```
+    Tokio + tokio-tungstenite
+    baseline/fallback de référence
 
-Candidat à évaluer :
-
-```text
 WebTransport
-QUIC
+    QUIC + HTTP/3
+    second backend retenu
 ```
 
-La simulation authoritative ne dépend directement d'aucun de ces transports.
+La simulation authoritative ne dépend directement d'aucun de ces transports. WebTransport est retenu à l'issue du POC `0.3.5` pour son chemin fiable natif/navigateur et sa capacité datagram optionnelle, sans remplacer WebSocket ni élargir artificiellement le contrat commun.
 
 ## Frontière de transport
 
@@ -52,7 +49,7 @@ synchronization
 authoritative simulation
 ```
 
-Le client utilise une realtime transport API. WebSocket reste le fallback de référence. WebTransport est évalué lorsqu'il apporte un bénéfice mesuré.
+Le client utilise une realtime transport API fiable/ordonnée commune. WebSocket reste le fallback de référence. WebTransport peut satisfaire cette même frontière via son stream bidirectionnel primaire ; ses datagrams restent backend-spécifiques car leur sémantique non fiable/non ordonnée n’appartient pas à `RealtimeConnection`. Le choix WebTransport-first/fallback WebSocket appartient à la composition ou à un adapter de plateforme, jamais au gameplay.
 
 ## gRPC
 
@@ -83,3 +80,13 @@ L'architecture permet ensuite de séparer Web/API, Assets, Realtime, Database et
 Debian Stable est la cible opérationnelle préférée.
 
 Le choix futur d'un edge/reverse proxy HTTP/3, stockage ou composant d'infrastructure reste reporté aux POC correspondants et doit tenir compte de la disponibilité/maturité sur Debian Stable.
+## Portabilité démontrée par le POC WebTransport 0.3.5
+
+La preuve `0.3.5` couvre :
+
+- Linux natif client/server WebTransport en loopback ;
+- client navigateur/WASM réel contre le serveur Rust natif ;
+- cross-compilation du backend pour Android ARM64 `aarch64-linux-android`, API 21, avec NDK `28.2.13676358`.
+
+La preuve Android est une preuve de compilation et ne vaut pas smoke runtime réseau sur appareil. Les plateformes Apple ne sont pas déclarées validées par cette version. Les résultats de caractérisation loopback sont documentés séparément et ne sont pas extrapolés à Internet/mobile.
+

docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Architecture des POC plateforme et réseau
 
@@ -32,9 +32,9 @@ Cette décision n’interdit pas Tauri Desktop. Le Desktop reste une distributio
 
 ## POC réseau
 
-Avant le Mode 3, comparer au minimum WebSocket/tokio-tungstenite, WebTransport/QUIC, fallback automatique, charge, reconnect/resync, backpressure, snapshots/deltas et mobilité réseau.
+`0.3.4` puis `0.3.5` ont fermé la question du transport de base : WebSocket/tokio-tungstenite reste la baseline/fallback de référence et WebTransport/QUIC est retenu comme second backend. Les deux partagent le contrat fiable/ordonné minimal de `game-realtime-transport-lib`; les datagrams WebTransport restent une capacité backend-spécifique. Le fallback est possédé par la composition, pas par le gameplay.
 
-Le même protocole métier doit pouvoir être exercé sur plusieurs transports.
+Les questions reconnect/resync, snapshots/deltas, mobilité réseau et protocole de session restent des couches supérieures distinctes. Elles ne doivent pas être présentées comme déjà validées par le POC transport `0.3.5`. Le même futur protocole métier doit pouvoir être exercé sur plusieurs transports lorsque cette couche sera réellement introduite.
 
 ## Build