diff --git a/CLAUDE.md b/CLAUDE.md
index bd94be3..2749051 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -60,18 +60,54 @@ Le décodage EAN-13 se fait en **C# avec [ZXing.Net](https://www.nuget.org/packa
|---|---|
| Décodage EAN-13 propre (380×160) | 0,04 ms/frame |
| **Pire cas** : frame 640×480 bruitée sans code-barres (échec) | 0,53 ms/frame |
-| Surcoût du payload PWA | +192 Ko (brotli) |
+| Poids de l'assembly `zxing.wasm` seul | +192 Ko (brotli) |
Le pire cas est le chiffre qui gouverne le framerate : la majorité des frames caméra ne contiennent pas de code-barres lisible, et c'est l'échec de décodage qui coûte le plus cher.
-⚠️ Ces chiffres sont mesurés en **JIT x64 natif**. En Blazor WASM le code est *interprété* par défaut : compter un facteur ~10-20×, soit ~5-10 ms/frame — largement suffisant pour scanner à 10-15 fps. Activer `true` ramène ça à 1-2 ms, au prix d'un build nettement plus lent.
+### Mesures en WASM réel — faites le 2026-08-18, phase scan
+
+L'estimation « ~5-10 ms/frame en interprété » ci-dessus n'était qu'une extrapolation. Elle a
+été **vérifiée dans un vrai navigateur** (Chromium 148, x86_64 de bureau), sur le publish
+`Release` du client, en appelant le décodeur depuis la console via `BancEssaiScan` :
+
+| Configuration | Pire cas 640×288 (bande visée) | Pire cas 640×480 |
+|---|---|---|
+| Publish `Release`, interprété | **4,4 – 6,4 ms/frame** | 6,7 – 7,8 ms/frame |
+| Build `Debug`, interprété | 17,7 ms/frame | 28,7 ms/frame |
+
+**L'estimation était bonne** : le mode interprété tient largement les 10-15 fps visés (une
+frame toutes les 80 ms n'utilise que ~6 % du budget). **Aucune raison d'activer l'AOT** —
+il reste à confirmer sur un téléphone, sensiblement plus lent qu'un x86_64 de bureau.
+
+⚠️ Ne jamais juger la fluidité sur un build `Debug` : il est **4 à 5× plus lent** que le
+`Release`, de quoi conclure à tort qu'il faut l'AOT.
+
+### ⚠️ Le surcoût de payload réel est bien supérieur à 192 Ko
+
+Mesuré par différence entre deux publish `Release` complets (somme brotli de `_framework`) :
+**+351 Ko** au total, dont ~4,7 Ko de code applicatif. Le coût imputable à ZXing.Net est donc
+d'environ **+346 Ko brotli**, soit **1,8× le poids de son propre assembly**. Le surplus vient
+des assemblies BCL que le trimmer ne peut plus retirer :
+
+| Assembly | Delta brotli |
+|---|---|
+| `zxing.wasm` | +192 495 o |
+| `System.Text.RegularExpressions` | +91 237 o (de 7 Ko à 98 Ko : ZXing utilise Regex, tout le moteur reste) |
+| `System.Runtime.Numerics` | +30 701 o (nouveau) |
+| `System.Private.CoreLib` | +17 586 o |
+| divers (`Threading`, `Collections`, `InteropServices`…) | ~14 Ko |
+
+Ne pas reprendre « +192 Ko » comme coût du scan : c'est le poids de l'assembly, pas celui
+de la fonctionnalité.
### Pièges à connaître
- **Le JS interop ne disparaît pas.** `getUserMedia` et `