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