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