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`).

---

# Retours d'usage du 2026-08-19 (3ᵉ série)

## Bug — un livre déjà catalogué peut être réencodé

Vérifié dans le code : `ServiceCatalogue.CreerAsync` ne fait **aucun** contrôle de doublon, et
`HasIndex(l => l.Isbn)` n'est **pas** unique. Scanner deux fois le même livre crée deux fiches.

⚠️ **À trancher avant de coder : refuser, ou avertir ?** Refuser tout net serait un piège, car
posséder deux exemplaires est légitime — on garde le sien et on prête l'autre. Et l'ISBN est
facultatif, donc il ne peut pas être le seul critère.

Trois critères candidats, de plus en plus large :

| Critère | Attrape | Rate / gêne |
|---|---|---|
| **ISBN identique** | le rescan du même livre, cas visé | rien si l'ISBN manque ; refuse un second exemplaire |
| **Clé d'œuvre + auteur** (`CleOeuvre`, comme la liste d'envies) | la saisie manuelle sans ISBN | confond le poche et le grand format, qui sont deux éditions possédées |
| **les deux, en avertissement** | tout ce qui précède | demande une confirmation de plus |

Piste privilégiée : **avertir et laisser confirmer** (« Vous avez déjà *Germinal* — ajouter
quand même ? »), plutôt que l'index unique qui interdirait le second exemplaire. La liste
d'envies, elle, refuse — mais elle décrit une envie, pas un objet, et deux exemplaires d'une
envie n'ont pas de sens.

## À l'ajout d'un livre, retirer l'envie correspondante

Demandé : si le livre ajouté figure dans la liste d'envies, l'en retirer.

⚠️ **La difficulté est la portée, pas le rapprochement.** Le catalogue est **commun**, la liste
d'envies est **personnelle** — ce sont les deux portées que `CLAUDE.md` oppose explicitement.
« Retirer l'envie » n'a donc pas une seule réponse :

- **la sienne uniquement** : simple, sûr, ne franchit aucune frontière. Mais si Camille souhaitait
  le livre et que Mathieu l'ajoute, Camille garde une envie pour un livre que le foyer possède.
- **celle de tout le monde** : cohérent avec « le livre est commun », mais **modifie
  silencieusement la liste d'un autre**, et lui fait perdre sa note (« demandé à Noël »). L'API
  ne sait pas — délibérément — écrire dans la liste d'autrui : ce serait une brèche à ouvrir
  dans un invariant tenu jusqu'ici.
- **ne rien supprimer, mais signaler** : la liste d'envies marque l'entrée « déjà au catalogue ».
  Non destructif, respecte la frontière, et l'écran de bibliographie sait déjà distinguer
  `Possede` de `Souhaite`.

⚠️ Le rapprochement se ferait par `CleOeuvre` + auteur, avec les mêmes limites que la
bibliographie (titre retraduit, tome, intégrale — voir `CLAUDE.md`). Une suppression sur un
rapprochement faillible est **irréversible** ; un signalement ne l'est pas. C'est un argument de
poids pour la troisième voie.

## Bandes dessinées et magazines

Deux demandes distinctes, de coût très différent.

### Les BD : surtout une question de type de document

Une BD est déjà catalogable telle quelle — elle a un ISBN, la BnF la connaît (vérifié au lot 6 :
la BD de Dobbs tirée de *La bête humaine* remonte bien). Ce qui manque est de pouvoir **la
distinguer** : `Format` dit physique ou numérique, pas roman ou BD.

Piste : un `TypeDocument` (roman / BD / magazine…) à côté de `Format`, avec migration, filtre au
catalogue et étiquette. ⚠️ Suivre la règle déjà actée pour le format : **n'afficher que ce qui
n'est pas le cas par défaut**, sinon chaque ligne du catalogue porte une étiquette qui n'apprend
rien.

Champs propres à la BD (série, tome, scénariste/dessinateur) : à ne faire que si le besoin se
confirme. Le modèle actuel met tous les auteurs dans `LivreAuteur` sans distinguer les rôles.

### Les magazines : cela rouvre une décision actée

⚠️ `CLAUDE.md` (lot 1) écarte **délibérément** le catalogage des périodiques : « le modèle de
données n'a ni numéro ni date de parution, et les deux chiffres de parution du code ne sont pas
exploitables comme numéro fiable — douze numéros d'un même magazine partagent leur ISSN et
créeraient douze fiches identiques ». Le scan d'un code `977` nomme donc la revue et bascule sur
la saisie manuelle, **sans** l'ISBN.

Les supporter vraiment demande de lever exactement ce qui avait motivé le refus :

- un **ISSN** distinct de l'ISBN (le ranger dans `Livre.Isbn` casserait tout lookup ultérieur) ;
- un **numéro** et une **date de parution**, seuls capables de distinguer deux exemplaires ;
- de décider si un magazine est **une fiche par numéro** ou **une fiche par revue avec des
  numéros rattachés** — c'est le vrai choix de modélisation, et il change la migration ;
- de reprendre le flux `977` pour qu'il crée au lieu d'expliquer.

À trancher avant tout code. Le reste (filtres, prêts, hors-ligne) suit mécaniquement une fois le
modèle arrêté.

## 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.