Documenter le choix de la bibliothèque de code-barres, à trancher

L'ISBN 9782846391009 n'est pas décodé par l'application, mais l'est par
une application d'essai avec ZBar, sur le même appareil et le même livre.

Le raisonnement qui écartait ce sujet était faux : CLAUDE.md conclut que
« le décodeur n'y est pour rien » à partir de mesures de VITESSE, qui ne
disent rien du taux de réussite.

Poids mesuré sur le publish Release de l'application d'essai : ZBar coûte
~168 Ko brotli, contre ~346 Ko déjà documentés pour ZXing.Net — dont la
queue d'assemblies BCL (Regex à 98 Ko, Numerics) que ZBar ne traîne pas.
Le remplacement allégerait l'application d'environ 180 Ko, à confirmer
par une comparaison de deux publish du projet.

Rien n'est acté : la décision se paie du départ du décodage hors du C#,
qui était la justification du choix de ZXing.Net.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

IDEES.md

@@ -84,6 +84,77 @@ L'échec est donc **au décodage de l'image**, pas au lookup. Rejoint le point c
 ⚠️ À reproduire en saisissant l'ISBN à la main avant de conclure : si la saisie manuelle échoue
 aussi, le défaut est ailleurs et ce diagnostic tombe.
 
+## Choix de la bibliothèque de lecture de code-barres — à trancher
+
+**Constat qui rouvre le sujet, 2026-08-19.** L'ISBN `9782846391009` n'est pas décodé par
+l'application, alors qu'il l'est par une application d'essai (`~/Code/TestBarcode`) sur le
+**même appareil et le même livre**, avec **ZBar**.
+
+⚠️ **Le raisonnement qui écartait ce sujet était faux.** `CLAUDE.md` conclut que « le décodeur
+n'y est pour rien » à partir de mesures de **vitesse** (4-6 ms/frame en WASM interprété). Or la
+vitesse ne dit **rien du taux de réussite** : un décodeur peut être rapide et rater. Les mesures
+existantes ne pouvaient donc pas soutenir cette conclusion, et l'essai la contredit.
+
+### Ce que l'essai établit, et ce qu'il n'établit pas
+
+**Établi** : ZBar lit ce code-barres, ZXing.Net (portage C#) ne le lit pas, dans les mêmes
+conditions physiques.
+
+**Non établi** : que le moteur soit seul en cause. Notre implémentation ne fait pas que décoder,
+elle **prétraite** — réduction à 640 px de large, puis **recadrage sur la bande centrale**
+(`PartHauteur = 0,45`). ZBar, lui, analyse l'image entière. Deux causes candidates cohabitent
+donc, et l'essai ne les sépare pas :
+
+1. le moteur (ZXing.Net est un portage d'une version ancienne de ZXing, réputé moins robuste que
+   `zbar` ou que `zxing-js`) ;
+2. notre prétraitement (bande trop étroite, ou résolution insuffisante pour la largeur de module
+   à la distance de prise de vue).
+
+Adopter ZBar rendrait la seconde question sans objet : le composant gère lui-même la caméra et
+l'image.
+
+### Le poids : mesuré, et à l'inverse de ce qu'on croyait
+
+Somme brotli réelle du publish `Release` de l'application d'essai :
+
+| Fichier | brotli |
+|---|---|
+| `zbar.wasm` (moteur C compilé) | 138 938 o |
+| `ZBar.Blazor.<empreinte>.wasm` (assembly .NET) | 21 232 o |
+| `zbar.js` | 5 247 o |
+| `camera.js` + `image.js` + `scanner.js` | 2 457 o |
+| CSS isolé | 199 o |
+| **Total ZBar** | **≈ 168 Ko** |
+
+À comparer au coût de ZXing.Net **déjà documenté dans `CLAUDE.md`** : **≈ 346 Ko brotli**, dont
+seulement 192 Ko d'assembly — le reste étant les assemblies BCL que le trimmer ne peut plus
+retirer (`System.Text.RegularExpressions` passant de 7 à 98 Ko parce que ZXing utilise Regex,
+plus `System.Runtime.Numerics`).
+
+Vérifié dans le publish d'essai : `System.Text.RegularExpressions` y pèse **7 137 o**, et
+`System.Runtime.Numerics` est **absent**. ZBar ne traîne pas cette queue.
+
+**Le remplacement allégerait donc l'application d'environ 180 Ko brotli**, au lieu de l'alourdir.
+⚠️ Chiffre à confirmer par une comparaison de deux publish de *notre* application, comme l'a été
+celui de ZXing.Net : le coût d'une bibliothèque n'est pas le poids de son assembly.
+
+### Ce qu'on perdrait
+
+- **Le décodage quitte le C#.** C'est l'argument qui avait fait retenir ZXing.Net : « réutilisable
+  hors navigateur si le projet évolue en scanner de bibliothèque ». Cet usage est **hypothétique
+  et n'a jamais été exercé** ; il se paie aujourd'hui en codes-barres non lus.
+- **`IsbnScanner`, `BancEssaiScan`, `ScannerCodeBarres` et `wwwroot/js/scanner-camera.js`**
+  disparaîtraient au profit du composant `ZBarCamera`.
+- **Une dépendance jeune** : `ZBar.Blazor` 1.1.0. À regarder avant de s'engager (maintenance,
+  licence, taille de la communauté).
+
+### Ce qu'on gagnerait, au-delà du code lu
+
+- **Le format est remonté** (`ISBN_13` vs `EAN_13`), là où nous le déduisons du préfixe.
+- **Les add-ons EAN-5 (prix) et EAN-2 (numéro) sont décodés** et rattachables au code principal —
+  l'EAN-2 est précisément ce qui accompagne les périodiques en `977`.
+- **Plus de pipeline image maison** à entretenir (capture, réduction, recadrage, `RGBLuminanceSource`).
+
 ## Auteurs et bibliographie
 
 ### Homonymes : « Between two worlds », un autre Robert Harper