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.