Files

T

mathieuandClaude Opus 5 278d6579f7 Basculer le décodage des codes-barres de ZXing.Net vers zbar

L'ISBN 9782846391009 n'était pas décodé par l'application, alors qu'il
l'était par une application d'essai utilisant zbar, sur le même livre et
le même appareil.

⚠️ Le raisonnement qui avait écarté cette piste était faux : CLAUDE.md
concluait que « le décodeur n'y est pour rien » à partir de mesures de
VITESSE (4-6 ms/frame). La vitesse ne dit rien du taux de réussite.

Le décodage quitte donc le C# pour zbar compilé en WebAssembly, dont les
assets viennent du paquet ZBar.Blazor.

Ce que la bascule apporte, au-delà du code lu :
- plus aucun pixel ne traverse le pont JS→C# (un byte[] par frame avant),
  seule la valeur décodée le fait ;
- l'image ENTIÈRE est analysée, à 960 px, là où l'ancienne version
  recadrait sur la bande centrale à 640 px pour alléger ce transfert —
  c'était la seconde cause possible des codes non lus, elle disparaît ;
- zbar.wasm est chargé À LA DEMANDE, à la première ouverture du scanner.

⚠️ Le composant ZBarCamera du paquet n'est PAS utilisé : il ouvre la
caméra lui-même et avale les erreurs. On y perdrait les messages qui
distinguent permission refusée, absence de caméra, caméra occupée et
contexte non sécurisé, ainsi que facingMode environment (caméra arrière)
et l'indication de résolution. Seuls zbar.js et zbar.wasm sont empruntés.

Poids, comparaison de deux publish Release complets (somme brotli) :
  _framework  3 281 558 → 2 978 700 o   (−296 Kio au démarrage)
  total       3 281 558 → 3 125 541 o   (−152 Kio)
L'écart vient de la traîne que ZXing imposait au trimmer :
System.Text.RegularExpressions retombe de 98 374 à 7 137 o, et
System.Runtime.Numerics disparaît.

⚠️ Coût assumé : six tests de décodage disparaissent avec IsbnScanner,
le décodeur n'étant plus en C#. Le décodage a été vérifié dans le
navigateur sur un EAN-13 rendu en canvas — 9782846391009 ressort bien en
ZBAR_EAN13 — mais cela reste une vérification, pas un garde-fou.
À confirmer avec le livre en main.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-19 00:51:56 +02:00

12 KiB

Raw Blame History

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

Deux remèdes appliqués, tous deux dans CLAUDE.md : la douchette USB (champ focalisé, validation sur Entrée) et surtout la bascule de ZXing.Net vers zbar — c'était bien le décodeur, contrairement à ce qu'on avait conclu de mesures de vitesse.

Reste à confirmer en usage réel. Si cela ne suffisait toujours pas : choisir la caméra quand il y en a plusieurs, exposer un curseur de zoom/torche là où l'API le permet, et laisser déposer une photo du code-barres à décoder.

ISBN `9782846391009` : résolu — c'était le décodeur

Le livre existe bien à la BnF : l'échec était au décodage de l'image. Confirmé le 2026-08-19 — zbar lit ce code-barres, ZXing.Net ne le lisait pas, sur le même appareil et le même livre. La bascule est faite (voir CLAUDE.md).

⚠️ À confirmer avec le livre en main : la vérification faite jusqu'ici porte sur un EAN-13 rendu en canvas, pas sur une image de caméra.

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, signaler l'envie correspondante

Décidé le 2026-08-19 : on ne supprime rien, on signale. La liste d'envies marque l'entrée « déjà au catalogue ».

Pourquoi pas la suppression, qui était la demande initiale :

le catalogue est commun, la liste d'envies personnelle. Supprimer l'envie d'un autre modifierait sa liste en silence et lui ferait perdre sa note (« demandé à Noël ») ; l'API ne sait pas — délibérément — écrire dans la liste d'autrui, et l'ouvrir serait une brèche dans un invariant tenu partout ailleurs ;
le rapprochement se fait par CleOeuvre + auteur, donc faillible (titre retraduit, tome, intégrale — voir CLAUDE.md). Une suppression fondée sur un rapprochement faux est irréversible ; un signalement se corrige d'un coup d'œil.

Reste à implémenter : le marquage dans SouhaitDto, calculé comme l'est déjà Possede dans la bibliographie, et son rendu sur l'écran des envies.

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 : une fiche par revue, les numéros à l'intérieur

⚠️ Rouvre la décision du lot 1, qui écartait le catalogage des périodiques faute de modèle. Le modèle est maintenant choisi.

Décidé le 2026-08-19 : une fiche par REVUE, et dans sa page, la sélection d'un numéro précis. C'est exactement ce qui évite le défaut redouté — douze numéros d'un même magazine ne font plus douze fiches identiques, puisqu'ils partagent la fiche de leur revue.

Ce que cela demande :

un ISSN sur la fiche de revue, distinct de l'ISBN. ⚠️ Ranger un code 977 dans Livre.Isbn casserait tout lookup ultérieur sur cette fiche ;
une table de numéros rattachés à la revue, portant au minimum un numéro et une date de parution ;
reprendre le flux 977 : il nomme aujourd'hui la revue et bascule sur la saisie manuelle, il devra créer ou compléter la fiche puis proposer d'ajouter le numéro scanné. ⚠️ Les deux chiffres de parution du code-barres ne sont pas un numéro fiable ; l'add-on EAN-2, que zbar sait maintenant décoder, est le bon candidat — à vérifier sur des magazines réels ;
décider ce qu'un prêt signifie pour une revue : on prête un numéro, pas un abonnement.

Sagas et cycles : plusieurs livres, un ordre de lecture

Demandé le 2026-08-19. Cas donné : Drizzt Do'Urden — plusieurs regroupements de plusieurs livres, à lire dans un ordre précis. Vaut pour les romans comme pour les BD.

C'est la première demande du projet qui porte sur une relation entre livres plutôt que sur un livre. Ce que le cas Drizzt impose, et qu'un simple champ « série » ne couvrirait pas :

Deux niveaux. La Légende de Drizzt regroupe plusieurs trilogies (L'Elfe noir, La Séquence de l'Icewind Dale…) : un cycle contient des séries, qui contiennent des tomes. Un champ texte plat perdrait ce regroupement.
L'ordre de lecture n'est pas l'ordre de publication. L'Elfe noir est une préquelle écrite après. C'est précisément l'information qu'on vient chercher : elle doit être stockée, pas déduite de l'année.
Un livre peut appartenir à plusieurs regroupements (une intégrale, une série, un cycle).
Ce qu'on possède est partiel. L'intérêt de l'écran est de montrer les trous — « il vous manque le tome 3 » — comme la bibliographie montre déjà ce qui manque d'un auteur.

Questions à trancher avant tout modèle :

D'où viennent les séries ? La BnF ne les expose pas de façon exploitable en Dublin Core. Saisie à la main, déduction depuis le titre (« Tome 3 »), ou source tierce ?
Portée : commune au foyer, comme le catalogue, ou personnelle ? L'ordre de lecture est une propriété de l'œuvre et non du lecteur — donc commune, a priori.
Les tomes non possédés existent-ils en base, ou sont-ils seulement affichés ? S'ils existent, ils ressemblent beaucoup à des envies, et il faudra dire comment les deux cohabitent.

⚠️ Ne pas confondre avec le regroupement d'œuvres de la bibliographie (CleOeuvre), qui réunit les rééditions d'un même titre. Ici, ce sont des titres différents qui se suivent.

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.

12 KiB Raw Blame History