Recueille les retours d'usage du 2026-08-21, et ce qu'ils supposent

Dix demandes remontées en usage, rangées en lots Q à Y dans IDEES.md.
Rien n'est acté : le fichier garde la matière brute et ce que la
relecture du code a déjà établi.

Trois demandes changent de nature une fois le code relu : éditer une
envie suppose un PUT /api/souhaits/{id} qui n'existe pas, souhaiter une
revue ou un numéro n'a aucun modèle, et la version à afficher dans une
page « À propos » ne vit nulle part dans le binaire. À l'inverse,
modifier un numéro de revue ne demande qu'un écran, l'API sachant déjà
le faire depuis le lot O.

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

IDEES.md

@@ -461,3 +461,205 @@ Deux points à trancher avant de coder :
 - **Où se fait le geste ?** Depuis l'envie (« Ranger dans une série », avec choix de la série et
   de la position), ou depuis la série (« Ajouter un tome depuis mes envies »). Le second a un
   mérite : c'est là qu'on voit l'ordre de lecture, donc où l'on sait quelle position donner.
+
+---
+
+# Retours d'usage du 2026-08-21 (7ᵉ série)
+
+Dix demandes remontées en usage. **Rien n'est acté** : ce qui suit est la matière brute, classée
+en lots, avec ce que la relecture du code a déjà établi. Deux items portent sur le même sujet
+(la flèche de retour) et sont réunis dans le lot S.
+
+---
+
+## Lot Q — L'ordre des champs du formulaire d'ajout
+
+Demande : dans « Ajouter un ouvrage », placer le **type de document juste après le titre**, puis
+les **thèmes**, puis les **auteurs**, puis — **si c'est une BD** — les rôles, le reste ensuite.
+
+Ce n'est pas un caprice de mise en page : l'ordre actuel fait descendre jusqu'en bas pour dire
+« c'est une BD », alors que **cette réponse commande la suite de la saisie** — les rôles n'ont
+de sens que là. Le formulaire suivrait enfin l'ordre dans lequel on regarde un livre qu'on tient
+en main.
+
+⚠️ **La règle des rôles reste celle actée** (`CLAUDE.md`, « Rôles des auteurs ») : ils
+n'apparaissent **qu'à partir de deux auteurs**. Le déclencheur deviendrait donc « BD **et** au
+moins deux auteurs » — à trancher : afficher les rôles sur une BD signée d'une seule personne
+serait un revirement, pas un détail de rendu.
+
+⚠️ Ne pas en profiter pour présélectionner « Bande dessinée » ou « Roman » : le défaut est
+`NonPrecise`, et il ne prétend rien (décision actée). Remonter le champ le rend visible, ce qui
+est exactement le but ; le préremplir écrirait quelque chose de faux.
+
+---
+
+## Lot R — Le menu ne doit pas fuir au défilement
+
+Deux comportements demandés, un par famille d'appareil :
+
+| Appareil | Aujourd'hui | Demandé |
+|---|---|---|
+| PC (≥ 40 rem) | rangée sous le bandeau, elle **défile avec la page** | rester **collée en haut** au défilement |
+| Téléphone (< 40 rem) | se déploie sous le bandeau, poussant le contenu | **plein écran**, pour choisir d'un coup d'œil |
+
+Le plein écran sur téléphone est ce qui justifie le lot : le menu déployé partage l'écran avec la
+liste qu'on quittait, et l'on choisit sa destination au milieu d'autre chose.
+
+⚠️ **Le point de rupture de 40 rem est écrit à DEUX endroits** — `wwwroot/css/app.css` (le menu
+passe en rangée) et `MainLayout.razor.css` (la bascule se masque). Les deux doivent rester
+identiques : c'est déjà noté dans `CLAUDE.md`, et un lot qui touche au menu est précisément
+l'occasion de les faire diverger.
+
+⚠️ **Et surtout** : les règles des liens du menu vivent en feuille **globale**, jamais en feuille
+scopée — l'attribut de portée de Blazor n'atteint pas ce que rend un `NavLink`. Toute règle
+ajoutée ici doit suivre le même chemin, sous peine d'être morte-née (défaut déjà rencontré, voir
+`CLAUDE.md`).
+
+Le menu **se referme déjà sur `LocationChanged`** : le plein écran hérite de ce comportement,
+mais il faudra aussi une fermeture explicite (croix, Échap, clic hors du menu) — un calque plein
+écran sans porte de sortie est un piège.
+
+---
+
+## Lot S — La flèche de retour
+
+Deux items remontés ensemble, qui ne demandent pas la même chose.
+
+- **S1. Elle ne doit pas faire sortir de l'application.** ⚠️ **C'est censé être déjà tenu** :
+  `js/navigation.js` teste `history.length` et retombe sur le catalogue quand la pile n'a qu'un
+  cran (voir `CLAUDE.md`, lot H). Que le défaut soit encore constaté veut dire l'une de deux
+  choses, et il faut trancher **avant** de coder : soit l'appareil tourne encore une version
+  antérieure (le cas du cache dépareillé, déjà rencontré), soit `history.length` ne dit pas ce
+  qu'on croit dans une PWA `standalone` — il compte l'historique de la session, y compris ce qui
+  précède l'application. **À mesurer sur l'appareil**, pas à déduire.
+
+- **S2. Le retour devrait ramener sur « le menu précédent ».** ⚠️ Cela **renverse** une décision
+  actée : « le retour passe par l'historique du navigateur, jamais par une destination calculée »,
+  au motif qu'un même écran s'atteint par plusieurs chemins (une fiche livre s'ouvre depuis le
+  catalogue, une bibliographie, une série ou une recherche). Le motif reste vrai — mais
+  l'historique remonte aussi les **allers-retours** (filtre, ordre, édition), et l'on peut cliquer
+  cinq fois sans quitter le même écran.
+
+  Piste à instruire : un retour **hiérarchique** (`/livres/{id}/edition` → `/livres/{id}` →
+  écran d'origine), c'est-à-dire une remontée d'un cran de route plutôt qu'une destination fixe.
+  Reste à décider ce que fait la racine d'une branche atteinte de biais. Ne pas coder avant d'avoir
+  écrit les cas : c'est une décision de navigation, pas un correctif.
+
+---
+
+## Lot T — La fiche d'une série : les actions à droite du titre
+
+Demande : sur `/series/{id}`, grouper **« Modifier »** et **« Changer l'ordre »** tout à droite,
+sur la ligne du titre et du compteur « x sur n tomes ».
+
+C'est la disposition déjà retenue ailleurs (lot H : la bibliographie a ses actions groupées à
+droite, la liste des auteurs ses trois colonnes dont une seule élastique). Rien de neuf sur le
+fond : les deux routes existent (`/series/{id}/edition`, `/series/{id}/ordre`), c'est leur
+**place** qui change.
+
+⚠️ Garder la règle actée : « Changer l'ordre » n'apparaît qu'à partir de **deux** tomes ou deux
+sous-séries. Un bouton toujours présent mais inerte serait un recul.
+
+---
+
+## Lot U — Le nombre de pages sur la fiche d'un livre
+
+Nouvelle colonne sur `Livre`, donc **migration**. Deux points à trancher avant de coder :
+
+- **Nullable, obligatoirement.** Aucun livre déjà catalogué n'a cette information, et `0` page se
+  lirait comme une donnée, pas comme une absence. Même famille de piège que le `TypeDocument`
+  dont le défaut ne prétend rien, et que le `GetValueOrDefault` qui rendait `0` au lieu de `null`.
+- **Prérempli depuis la BnF ?** Le Dublin Core expose `dc:format`, qui porte des mentions du genre
+  « 1 vol. (349 p.) ». ⚠️ **Non vérifié**, et le projet n'en lit rien aujourd'hui : aucun service
+  ne parse ce champ. À mesurer sur un échantillon avant de promettre quoi que ce soit — et de
+  toute façon la saisie manuelle reste la voie sûre, comme pour les thèmes.
+
+Question ouverte : le nombre de pages a-t-il un sens pour un **ebook** ? Il varie avec la police.
+S'il est saisi, il l'est comme une indication, pas comme une propriété du fichier.
+
+---
+
+## Lot V — Dans la liste des revues, toute la ligne s'ouvre
+
+Aujourd'hui seul le **titre** est cliquable. C'est le motif inverse de ce que le projet tient
+ailleurs : sur une carte du catalogue, c'est la carte entière qui mène à la fiche.
+
+⚠️ Le seul vrai risque est d'avaler des actions : si la ligne porte un jour un bouton (retirer,
+ajouter un numéro), il faudra que son clic **n'atteigne pas** la ligne. À traiter en même temps
+que le lot W, qui ajoute précisément des boutons sur ces écrans.
+
+---
+
+## Lot W — La fiche d'une revue : mêmes actions à droite, et l'édition d'un numéro
+
+Symétrique du lot T, en trois demandes :
+
+1. **« Ajouter un numéro » et « Modifier la revue » groupés à droite** du titre.
+2. **Modifier un numéro déjà possédé.** ⚠️ L'API sait déjà le faire : `PUT
+   /api/revues/numeros/{id}` existe depuis le lot O — sans quoi couverture, une et note
+   n'auraient existé qu'à la création. Il manque **l'écran**, pas le point d'entrée.
+3. **Retirer un numéro.** `DELETE /api/revues/numeros/{id}` existe aussi.
+
+Reste à décider **où** : la demande dit « si modification de la revue », donc dans l'écran
+d'édition. À peser contre la règle du lot B (« consulter d'abord, modifier ensuite ») : éditer un
+numéro depuis la consultation de la revue serait un geste courant — c'est déjà l'exception
+accordée au statut de lecture et au prêt. Ne pas trancher au clavier : c'est une question d'usage.
+
+---
+
+## Lot X — Éditer une envie, et savoir ce qu'on peut souhaiter
+
+Demande : dans `/souhaits`, un bouton **« Éditer »** au-dessus de « Retirer », pour corriger le
+livre souhaité.
+
+⚠️ **Le point d'entrée n'existe pas.** Vérifié : `SouhaitsEndpoints` expose `POST`, `PUT
+/ordre` et `DELETE /{id}` — **aucun `PUT /{id}`**. Ce lot est donc une vraie fonctionnalité,
+pas un bouton à poser.
+
+Trois contraintes que l'API devra tenir, toutes déjà écrites dans `CLAUDE.md` :
+
+- **la liste d'envies est personnelle** : éditer l'envie d'un autre répond **404**, jamais 403 ;
+- **`TitreNormalise` (clé d'œuvre) et `AuteurNormalise` se recalculent** à l'écriture, sinon le
+  rapprochement « déjà au catalogue » se fait sur l'ancienne forme ;
+- **l'unicité `(Utilisateur, TitreNormalise, AuteurNormalise)`** peut être violée par une
+  édition, contrairement à un simple renommage : renommer une envie en une autre qu'on a déjà
+  doit répondre proprement, pas planter sur une contrainte.
+
+**Second volet de la demande, à instruire** : peut-on souhaiter **une revue, un numéro de revue,
+une BD** ? Réponses, telles que le modèle les donne aujourd'hui :
+
+| Souhait | Possible ? | Pourquoi |
+|---|---|---|
+| Une **BD** | **oui**, sans rien changer | une envie n'a ni format ni type ; c'est un titre et un auteur |
+| Une **revue** ou un **numéro** | **non** | `LivreSouhaite` n'a aucun lien vers `Revue` ni `NumeroRevue`, et l'unicité porte sur (titre, auteur) — un numéro n'a pas d'auteur |
+
+⚠️ Rien n'**interdit** d'y taper « Médor n° 43 » comme titre libre : ça marcherait, et ne serait
+rapproché de rien. À trancher : est-ce suffisant (une envie est une note qu'on emporte en
+librairie), ou faut-il une notion d'envie de périodique ? Le premier a le mérite de ne rien
+casser ; le second rouvre la question d'une table de plus.
+
+---
+
+## Lot Y — Une page « À propos »
+
+Contenu demandé : **manuel** (à venir), **e-mail** `mailto:info@limonier.be`, **site**
+`www.limonier.be` dans une autre fenêtre, **version publiée**, et la **licence du dépôt**.
+
+Deux points sont plus qu'un remplissage de page :
+
+- ⚠️ **L'application ne connaît pas sa version.** Vérifié : la version vit dans le
+  `manifest.toml` du dépôt `mabibli_ynh` et dans les tags git — **rien n'est injecté dans le
+  binaire**. Afficher une version demande que `build/publier-release.sh` la pose dans l'assembly
+  (`InformationalVersion`), puis que l'API la rende. Sans cela, la page afficherait un numéro
+  faux ou figé, ce qui est **pire que pas de version du tout** — c'est exactement la valeur qu'on
+  lira pour diagnostiquer un appareil dépareillé.
+- **La licence est l'AGPL v3** (fichier `LICENSE`). ⚠️ L'AGPL demande que les utilisateurs d'un
+  service en réseau puissent obtenir la **source** : un lien vers le dépôt à côté de la mention
+  n'est pas un ornement, c'est ce que la licence attend.
+
+⚠️ Un lien externe en `target="_blank"` porte `rel="noopener"`. Et il ne doit **pas** être un
+`<a>` inerte hors-ligne : c'est la même famille que les liens d'export, qui basculent en boutons
+désactivés faute de pouvoir aboutir.
+
+Où la ranger : une septième destination dans le menu déséquilibrerait une navigation qu'on vient
+justement de reprendre (lot R). À peser — pied de page, ou entrée à part visuellement.