0.3.5-beta.2

docs/studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/027-V0_3_5_REALTIME_TRANSPORT_MEASUREMENT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Étude 0.3.5 — caractérisation bornée WebSocket / WebTransport
 
@@ -175,9 +175,9 @@ Les dimensions utiles sont :
 - capacité à soutenir la fenêtre applicative bornée ;
 - observation distincte de la capacité datagram.
 
-## Conclusion technique provisoire
+## Conclusion technique retenue
 
-Décision `alpha.10` : **retain**.
+Décision consolidée pour `0.3.5` : **retained**.
 
 Cela signifie : conserver WebTransport comme second backend realtime expérimental/évolutif à côté de WebSocket. Cette décision repose sur l'ensemble des preuves `0.3.5` déjà acquises :
 
@@ -188,4 +188,6 @@ Cela signifie : conserver WebTransport comme second backend realtime expériment
 - fallback WebSocket strictement classifié ;
 - datagrams optionnels backend-spécifiques.
 
-Cette conclusion **ne signifie pas** que WebTransport est déclaré plus rapide que WebSocket. Les chiffres de `alpha.10` servent à détecter des écarts grossiers et à documenter la baseline locale avant la validation large `beta.1`.
+Cette conclusion **ne signifie pas** que WebTransport est déclaré plus rapide que WebSocket. Les runs `alpha.10.fix.1` et `beta.1` montrent au contraire des avantages différents selon le pattern mesuré : établissement plus coûteux pour WebTransport, RTT local plus faible dans ces runs, throughput 64 KiB supérieur pour WebSocket et fenêtre 1 KiB nettement supérieure pour WebTransport. Ces écarts servent à caractériser les wrappers actuels, pas à produire un classement général.
+
+La validation large a ensuite confirmé le workspace complet, les smokes natifs, le chemin navigateur/WASM réel et la cross-compilation Android ARM64/API 21. Les valeurs exactes des runs validés restent dans `history/0.3.5/alpha.10.fix.1.md` et `history/0.3.5/beta.1.fix.1.md`.