mabibli/IDEES.md

# IDEES.md — améliorations envisagées

Ce fichier recueille les idées et corrections identifiées en cours de route, **pas encore implémentées**. Il n'a pas valeur de décision : rien ici n'est acté tant que ce n'est pas repris dans `CLAUDE.md` ou traité dans une phase.

Le travail visuel de fond (couleurs, typographie, mise en page) est repoussé volontairement : il sera fait quand les fonctionnalités seront en place.

---

## Qualité des données

### Recherche insensible aux accents

« Emile » ne trouve pas « Émile ». Gênant sur un fonds francophone.

**Semble réglé par la refonte du schéma** (colonnes normalisées, voir `CLAUDE.md`) : vérifié le 2026-08-18 sur l'API, `recherche=Emile` remonte bien les livres d'« Émile Zola ». Laissé ici faute d'avoir été traité comme un point à part entière — à confirmer sur un fonds réel avant de le retirer.

---

## Recherche : la ligature « œ » n'est pas réduite à « oe »

Repéré le 2026-08-18 en implémentant la liste d'envies. `NormalisationTexte.Normaliser`
décompose en **NFD**, qui sépare les accents mais laisse les ligatures intactes — seul NFKD les
défait. Conséquence : `L'Œuvre` et `L'oeuvre` ne se rencontrent jamais.

Ce n'est pas propre à la liste d'envies : la même fonction alimente la **recherche du catalogue**
et la **clé unique des auteurs**. Zola a écrit *L'Œuvre*, que la BnF orthographie avec la
ligature ; un utilisateur qui tape « oeuvre » ne le trouvera pas, et ne verra pas non plus le
livre grisé dans la bibliographie.

Correction envisagée : passer en NFKD, ou traiter explicitement `œ`/`Œ` et `æ`/`Æ`. **Non fait
volontairement** — changer cette fonction déplace deux invariants en base (les colonnes
normalisées et l'index unique `CleRegroupement`). `ServiceRenormalisation` sait recalculer les
colonnes au démarrage, mais la fusion d'auteurs que la nouvelle règle provoquerait mérite d'être
regardée avant. Documenté par un test (`CleOeuvreTests.Ne_reduit_pas_la_ligature_oe`) pour que
la limite reste visible.

---

## Bibliographie : ce qui reste à creuser

La bibliographie par auteur est implémentée (voir `CLAUDE.md`). Deux pistes non traitées :

- **Plafond de 200 notices.** Suffisant pour un auteur contemporain (Werber : 203, Nothomb : 277),
  très insuffisant pour un classique (Zola : 2692). L'écran le dit, mais on pourrait charger les
  pages suivantes à la demande plutôt que d'annoncer un extrait.
- **OpenLibrary en second rideau.** La BnF ne connaît pas les auteurs étrangers non traduits ;
  l'écran affiche alors une liste vide et l'explique. OpenLibrary expose les œuvres d'un auteur
  (`/authors/{id}/works.json`) et pourrait prendre le relais — à ne faire que si le cas se
  présente réellement en usage.

---

# Retours d'usage du 2026-08-18 (2ᵉ série)

Demandes et anomalies remontées après quelques jours d'usage réel. **Rien n'est acté** :
ce qui suit est la matière brute, classée par sujet, avec ce que le diagnostic a déjà établi.

## Scan et saisie d'ISBN

### Le scan caméra rate souvent sur ordinateur

**La douchette USB est faite** (voir `CLAUDE.md`, « La douchette USB est le vrai remède ») :
champ focalisé à l'ouverture, validation sur `Entrée`. Reste à confirmer en usage réel qu'elle
suffit.

Si elle ne suffit pas, pistes non traitées : choisir la caméra quand il y en a plusieurs,
demander une résolution plus haute, exposer un curseur de zoom/torche là où l'API le permet,
et laisser **déposer une photo** du code-barres à décoder (ZXing lit un fichier aussi bien
qu'une frame).

### ISBN `9782846391009` : le scan n'aboutit pas

**La donnée existe pourtant côté BnF** — vérifié le 2026-08-18 :

```
bib.isbn all "9782846391009"  → 1 notice
  dc:title   = La thérapie émotivo-rationnelle / Albert Ellis et Robert A. Harper
  dc:creator = Ellis, Albert (1913-2007). Auteur du texte
  dc:creator = Harper, Robert A. (1915-2004). Auteur du texte
(la forme ISBN-10 « 2846391009 » ne renvoie rien : ici c'est bien l'ISBN-13 qui indexe)
```

L'échec est donc **au décodage de l'image**, pas au lookup. Rejoint le point ci-dessus.
⚠️ À 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

Constaté le 2026-08-19 en vérifiant la bibliographie de Robert A. Harper : parmi les 7 œuvres
retenues figure *Between two worlds : a new introduction to geography* (1973, Houghton Mifflin),
qui est d'un **géographe homonyme**, pas du psychothérapeute.

Le post-filtre d'auteur ne peut rien : `RapprochementAuteurs` compare des **noms**, et ces
deux-là portent le même. Départager demanderait les dates de vie (`dc:creator` les porte souvent :
« Harper, Robert A. (1915-2004) »), ce que le parser jette aujourd'hui au nettoyage ISBD.

⚠️ Ne pas en faire une urgence : une œuvre en trop se voit et s'ignore, contrairement à une œuvre
manquante. Piste si le cas se répète : conserver les dates extraites de `dc:creator` et écarter
une notice dont les dates contredisent celles majoritairement observées pour l'auteur.

### OpenLibrary en second rideau — la justification est retombée

Le cas « Robert A. Harper » semblait l'imposer : il s'est révélé être un **délai dépassé**, pas un
trou de couverture (voir `CLAUDE.md`). La BnF connaît bien cet auteur.

La piste reste valable pour les auteurs étrangers **non traduits**, avec ses deux difficultés
inchangées : résoudre un nom vers un identifiant OpenLibrary (`/search/authors.json`), étape sans
équivalent BnF et sensible aux homonymes ; et des œuvres remontées **en langue originale**, donc
non rapprochables du catalogue par `CleOeuvre` — l'écran afficherait une liste où presque rien ne
serait marqué « possédé ». À ne faire que si le cas se présente réellement.