Files

T

mathieuandClaude Opus 5 0c98abdecd Note le lot P : ranger une envie dans une série, sans la trahir au foyer

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

2026-08-20 23:14:50 +02:00

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

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. Traité pour la recherche « nouveautés d'un auteur » du lot E : elle charge jusqu'à 1000 notices avec un bornage explicite. La bibliographie générale reste plafonnée à 200 et continue d'annoncer honnêtement qu'elle est tronquée.
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)

Ce qui reste des magazines : confirmer l'EAN-2 sur un vrai kiosque

Le numéro scanné est implémenté (voir CLAUDE.md) : zbar lit l'add-on EAN-2 — après l'avoir activé, il est désactivé par défaut — et l'écran de la revue le propose dans un champ à vérifier.

⚠️ Ce qui n'est toujours pas vérifié : que les magazines réels portent bien leur numéro de parution dans cet add-on, et non autre chose. La chaîne de décodage est prouvée sur un code généré ; l'usage éditorial demande un exemplaire devant la caméra. À faire sur trois ou quatre numéros d'un même titre : si l'EAN-2 suit la parution, le message d'avertissement pourra s'alléger ; s'il ne la suit pas, c'est le pré-remplissage qu'il faudra retirer.

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.

Retours d'usage du 2026-08-19 (4ᵉ série)

Matière brute remontée après usage sur téléphone. Rien n'est acté. Les items sont regroupés en lots : chaque lot tient dans un même geste de conception et pourrait faire une phase. L'ordre des lots est un ordre de dépendance et non de priorité — le lot A débloque tout le reste visuellement, le lot B fixe un motif que les lots C à E réutilisent.

Le classement est un regroupement, pas un arbitrage : ce qui suit n'a pas encore été instruit, et plusieurs items voisins pourraient se révéler être le même travail — ou des travaux sans rapport.

A1 à A4 traités le 2026-08-20 (voir CLAUDE.md, section « Habillage — retours d'usage du 2026-08-19 traités »). Reste ouvert :

A5. Alléger les couvertures (redimensionnement / WebP)

Le cache hors-ligne des couvertures est fait (voir CLAUDE.md), mais chaque affichage en ligne retélécharge toujours l'image OpenLibrary à sa taille d'origine — rien n'est redimensionné à la taille réellement affichée, ni converti en WebP.

⚠️ À peser avant de s'y engager, même règle que pour l'AOT : une conversion n'a de sens que si la mesure montre un gain réel. Pas encore mesuré à l'échelle d'un vrai fonds.

Lot B — Consulter d'abord, modifier ensuite — traité le 2026-08-20

Un seul motif, déjà acté et éprouvé pour la fiche livre (/livres/{id} consulte, /livres/{id}/edition modifie, le mode est dans l'URL), à étendre aux écrans qui présentent encore un formulaire vivant sous le pouce.

B1. Fiche d'une série : vue de lecture seule + bouton « Modifier ». La liste des tomes s'y présente comme le catalogue (même carte, même pastille de statut), au lieu d'une liste à part.
B2. Liste d'envies : idem — on la consulte bien plus souvent qu'on ne la réordonne, et les flèches monter/descendre sont précisément ce qu'on déclenche par erreur en faisant défiler. ⚠️ Même raisonnement que le retrait des boutons de statut des cartes du catalogue.
B3. Bibliographie d'un auteur : même carte que le catalogue, et un clic ouvre le détail de l'œuvre au lieu de s'arrêter à une ligne.

✅ Traité : voir la décision et les limites retenues dans CLAUDE.md.

⚠️ Le point commun des trois n'est pas cosmétique : c'est une seule carte de livre réutilisée partout. Si les trois écrans réimplémentent la carte chacun de leur côté, les pastilles divergeront comme le filtre a divergé (voir A2).

Lot C — Séries, cycles et arborescence — traité le 2026-08-20

Le lot le plus structurant, et le seul qui touche au modèle.

C1. Ordonner les séries d'un cycle par ordre de lecture — la position existe déjà (Serie.Position), il manque le geste dans l'écran.
C2. Replier / déplier le contenu de chaque série dans un cycle, chaque série repliée montrant sa vue de consultation (lot B).
C3. Totaliser les livres d'un cycle, en sommant ce qui est plus bas dans l'arbre (possédés / manquants).
C4. Un véritable arbre descendant sur plusieurs niveaux, plutôt que deux niveaux affichés. ⚠️ La profondeur est déjà non bornée en base ; c'est l'affichage qui s'arrête. Se souvenir que la remontée de parenté est bornée par le nombre de séries, garde-fou anti-boucle à ne pas perdre en descendant.
C5. Ajouter un tome depuis la série, sans repasser par le catalogue : soit comme livre possédé, soit comme envie, avec les métadonnées pré-remplies.

Cas donné : 9791028111403. C'est le seul item du lot qui relie trois portées — la place dans la série est commune, l'envie est personnelle, le livre est commun. MettreEnEnviesAsync fait déjà la traversée ; ce qui manque est le pré-remplissage (lookup ISBN depuis la place), et il lèverait au passage la limite connue « aucun auteur transmis à l'envie créée », donc l'absence de marquage « déjà au catalogue » à l'achat.

⚠️ Formulation d'origine : « ajouter les livres, magazines et BD depuis série comme un livre possédé ». Les revues y sont mentionnées alors qu'ElementSerie.LivreId pointe Livre : rattacher un numéro de revue à une série demanderait un second lien nullable, ou une parenté commune. À instruire avant de promettre — ce n'est pas le même travail que le reste du lot.

✅ Traité : voir CLAUDE.md (C1 à C5). Les revues restent explicitement hors périmètre de C5.

Lot D — La bibliographie devient un écran de travail

✅ Traité le 2026-08-20 : voir CLAUDE.md, section « Lot D — bibliographie écran de travail ».

Aujourd'hui elle se consulte ; les cinq items la font servir à constituer une liste.

D1. Mettre en cache une bibliographie déjà demandée. Elle coûte ~0,85 s par page, deux pages en parallèle, et on y revient. ⚠️ Elle est déjà le seul écran où une source muette est distinguée d'une source vide : ne jamais mettre en cache un SourceMuette, sous peine de figer « rien trouvé » pour un incident réseau — c'est exactement le défaut corrigé le 2026-08-19, sous une autre forme.
D2. Un bouton « Filtrer », avec au minimum « ceux que j'ai déjà » (et son inverse).
D3. Afficher le statut de lecture sur les œuvres possédées — la pastille du lot B suffirait.
D4. Masquer des œuvres pour y voir clair, le filtre permettant de réafficher les masquées. ⚠️ C'est la première exception assumée à la règle « on grise, on ne masque jamais », qui existe parce qu'un rapprochement par titre rate des choses. Un masquage explicite de l'utilisateur n'est pas un rapprochement automatique — mais il faut décider sa portée (personnelle comme les envies ? commune comme le catalogue ?) et le rendre visible (« 12 masquées ») plutôt que silencieux.
D5. Sélection multiple pour ajouter plusieurs œuvres aux envies en une fois. C'est ce qui transforme l'écran : cocher dix titres de Werber et valider.

Lot E — Trouver ce qu'on veut souhaiter

✅ Traité le 2026-08-20 : voir CLAUDE.md, section « Lot E — trouver ce qu'on veut souhaiter ».

L'écran /souhaits/ajout rend aujourd'hui une liste plate.

E1. ISBN et couverture dans les résultats de recherche. ⚠️ L'ISBN existe déjà dans la notice (dc:identifier, il alimente CoverUrl) : c'est de l'affichage, à passer par FormatageIsbn.Afficher.
E2. Trier les résultats par date, éditeur ou titre.
E3. Recherche par auteur limitée aux nouveautés : ce qui est paru depuis le livre le plus récent que l'on possède de cet auteur. C'est la question « qu'est-ce qui m'a échappé ? », et elle est aujourd'hui sans réponse.

⚠️ Deux pièges connus la rendent moins simple qu'elle n'en a l'air : le représentant d'une œuvre est la notice la plus ancienne (édition originale), donc « paru depuis » ne se lit pas sur la date affichée ; et le plafond de 200 notices écrête justement les auteurs les plus réédités. À instruire avec la reprise de pagination (voir « Bibliographie : ce qui reste à creuser »).

Lot F — Enrichir la fiche d'un livre

F1. Un lien vers la notice source (BnF, OpenLibrary) sur la fiche. Traité le 2026-08-20 : l'URL est conservée à la création quand le livre vient d'un lookup ISBN et affichée sur la fiche. Peu coûteux, et c'est le recours quand une donnée paraît fausse. ⚠️ Suppose de conserver l'identifiant de la notice au lookup, ce que le modèle ne fait pas aujourd'hui : ce n'est donc pas un simple lien à afficher, mais une colonne de plus.
F2. Des thèmes en étiquettes (dark fantasy, science-fiction, space opera…). Traité le 2026-08-20 : thèmes communs au foyer dans Theme/LivreTheme, saisis manuellement et normalisés pour éviter les doublons. La BnF n'alimente pas ces étiquettes : son dc:subject est en vocabulaire Rameau, inadapté aux mots-clés grand public. Le filtre catalogue est volontairement reporté ; le formulaire accepte une liste séparée par des virgules et les thèmes s'affichent sur les cartes et fiches.
F3. Renommer un auteur, la correction se répercutant sur tous ses livres. Traité le 2026-08-20 : le renommage recalcule les formes et propose une fusion confirmable en cas de collision. ⚠️ Le n-n est déjà en place, donc un seul Auteur.Nom à changer — mais NomNormalise et CleRegroupement se recalculent, et la clé porte un index unique. Renommer « Hamilton » en « Peter F. Hamilton » peut donc entrer en collision avec une fiche existante : le geste est alors une fusion, pas un renommage, et il faut le dire à l'utilisateur au lieu d'échouer sur une contrainte.

Lot G — Prêts — traité le 2026-08-20

G1. Filtrer les prêts en cours par nom d'emprunteur : fait, en mémoire, sans colonne normalisée (voir CLAUDE.md).

À faire demain — retours d'usage du 2026-08-20 (6ᵉ série)

Non actés : ce fichier ne fait pas autorité, CLAUDE.md reste la référence.

Lot I — La bibliographie d'un auteur

I1. « Tout cocher », à côté de « Tout décocher ». Dès qu'une case est cochée, la barre de sélection n'offre que le geste inverse : pour ajouter aux envies l'essentiel d'une bibliographie, il faut cocher ligne à ligne. ⚠️ « Tout » doit signifier ce qui est actuellement visible — donc après filtre (« à découvrir », masquées affichées ou non) — et non les 200 notices remontées : cocher des lignes qu'on ne voit pas est exactement le défaut que le compteur par bouton cherche à éviter.
I2. Voir la couverture d'une œuvre non possédée, au clic sur la ligne. Le repli inline n'affiche aujourd'hui que l'ISBN et le nombre d'éditions, là où les œuvres possédées ont leur vignette via CarteLivre. ⚠️ L'image se charge à la demande, au dépliage, pas pour toute la liste : une bibliographie compte des dizaines de lignes. La règle « sans ISBN, pas de couverture, et on n'en invente pas » reste entière — la formule OpenLibrary s'applique à l'ISBN déjà repris du dc:identifier, et le substitut à initiale sert de repli.

Lot J — Le scan là où il manque

J1. Scanner depuis une série, sur une place vide. Le flux existe déjà en pièces détachées (/ajout décode, la place sait accueillir un livre créé par ISBN), mais il faut passer par l'écran d'ajout puis revenir rattacher à la main. ⚠️ Le retour doit ramener sur la série et sur la place visée : sans cela on rattache le mauvais tome. Les revues (977) restent hors de ce flux — ElementSerie.LivreId ne pointe que vers Livre.
J2. Scanner depuis « ajouter une envie ». /souhaits/ajout propose déjà la voie « par ISBN » en saisie ; c'est le même composant de scan que /ajout, sans création de Livre au bout. Cas d'usage direct : le livre est en main, en librairie.

Lot K — Couvertures et saisie

K1. Photographier la couverture quand aucune source n'en fournit. ⚠️ C'est le premier point du projet qui stocke un fichier, ce que « Ebooks : fiches uniquement » écartait jusqu'ici : espace disque YunoHost, sauvegarde plus lourde, et cache hors-ligne à alimenter autrement que par le magasin couvertures (dont la clé est une URL). À trancher avant de coder : où vivent les octets (data_dir ? base ?), et quelle taille maximale. La caméra, elle, est déjà ouverte par scanner-camera.js.
K2. Les tirets de l'ISSN, posés automatiquement. Un ISSN se coupe toujours au même endroit (2466-6718, quatre chiffres puis quatre), contrairement à l'ISBN dont les tranches dépendent de l'éditeur — c'est donc bien plus simple que FormatageIsbn. ⚠️ Trancher où : la règle actée est que les champs de saisie gardent la valeur nue (découper pendant la frappe se bat avec l'utilisateur, et la douchette tape des chiffres). Le tiret est donc d'abord un travail d'affichage ; s'il est posé à la saisie, ce doit être à la validation, jamais à chaque frappe, et la valeur stockée reste nue pour que bib.issn reste interrogeable.

Lot L — Rendre l'attente visible

L1. Un indicateur pendant les appels lents, faute de quoi une recherche BnF (≈1 s par page, jusqu'à dix pages pour les nouveautés) se lit comme une application plantée. ⚠️ Le besoin n'est pas décoratif : le lot H a montré qu'un écran qui ne dit rien pousse à recliquer, donc à relancer l'appel. Doit couvrir au minimum le lookup ISBN, les recherches BnF, les bibliographies et les nouveautés. À faire avec les règles déjà tenues : un bouton en cours d'appel se désactive avec son motif, et une source muette garde ses états EtatSourceBibliographie — un indicateur ne remplace pas le message d'échec.

Lot M — Détails d'écran

M1. Séries : « Nom d'une série » et le bouton « Créer » sur la même ligne. Le champ et son bouton s'empilent aujourd'hui. ⚠️ À 320 px, la ligne doit rester lisible : le champ prend la place restante, le bouton garde sa largeur propre — et le libellé ne se tronque pas.

Lot N — Les couvertures lentes au rechargement (téléphone)

✅ N1 traité le 2026-08-20 : le cache IndexedDB est consulté d'abord, en ligne comme hors ligne — voir CLAUDE.md, section « Les couvertures viennent du cache AUSSI en ligne ». N2 (stocker l'URL finale) reste ouvert, et n'est plus urgent : une couverture déjà vue ne repasse plus par les redirections.

Constat d'usage : après un rechargement sur téléphone, les couvertures n'apparaissent pas tout de suite — alors que deux images dont l'URL a été collée à la main (Fnac) s'affichent sans attendre.

⚠️ L'URL est DÉJÀ en base (Livre.CoverUrl, LivreSouhaite.CoverUrl) : la lenteur n'est donc pas un aller-retour de résolution à faire disparaître. La différence entre les deux cas désigne autre chose — covers.openlibrary.org répond 302, deux fois, avant d'aboutir sur archive.org (mesuré au lot du relais de couvertures), là où une URL de CDN collée à la main va droit au fichier. Sur un lien mobile, trois allers-retours par vignette et une dizaine de vignettes à l'écran, c'est exactement ce qui se voit.

⚠️ Deuxième cause probable, à mesurer avant de coder : Couverture.razor n'utilise le magasin IndexedDB couvertures que hors ligne (!Reseau.EnLigne). En ligne, chaque rechargement repart donc du réseau, même pour une image déjà rangée sur l'appareil.

Pistes, dans l'ordre où elles se testent :

N1. Servir le blob caché même en ligne, l'URL réseau ne servant que de repli. ⚠️ Ce serait renverser la règle actée « en ligne, rien ne doit ralentir la voie rapide » : une lecture IndexedDB précéderait l'affichage. À mesurer, pas à supposer — et il faudra décider quand le blob est rafraîchi, une couverture pouvant changer.
N2. Résoudre les redirections une fois pour toutes : stocker l'URL finale plutôt que celle de covers.openlibrary.org. ⚠️ Rien ne garantit que l'URL d'archive.org reste stable ; le repli sur l'URL d'origine doit rester.
N3. Mesurer d'abord. C'est la règle déjà tenue pour l'AOT WASM et l'allègement des couvertures (A5) : constater le coût réel — nombre de requêtes, temps par vignette, part des redirections — avant de choisir laquelle des deux pistes vaut son risque.

Lot O — Les numéros de revue s'enrichissent

O1. Une image par numéro de revue. NumeroRevue n'a aujourd'hui aucune couverture, et aucune source ne peut en fournir : l'ISSN désigne la revue, pas la parution. L'image viendra donc d'une photo ou d'une URL collée. ⚠️ Même question ouverte que K1 — si c'est une photo, ce sont des octets à stocker, ce que le projet n'a jamais fait ; si c'est une URL, le magasin couvertures et le relais GET /api/couvertures fonctionnent déjà, mais le garde du relais n'accepte que les URL présentes dans Livres.CoverUrl ou LivresSouhaites.CoverUrl : il faudrait y ajouter la colonne des numéros, sans quoi l'image s'affichera en ligne et jamais hors-ligne (exactement le défaut corrigé le 2026-08-20).

O2. Des étiquettes par numéro : les articles à la une. ✅ Tranché avec l'utilisateur le 2026-08-20 : sur le NUMÉRO (NumeroRevue), pas sur la revue — les articles à la une changent à chaque parution ; posés sur Revue, ils décriraient une ligne éditoriale, pas un sommaire.

Le modèle existe déjà à côté : Theme / LivreTheme (nom, NomNormalise, index unique, n-n). Deux façons de faire, à choisir :

	Réutiliser `Theme`	Une table à part
Pour	un vocabulaire commun livres/revues, une seule normalisation	un titre d'article n'est pas un thème, et remplirait `/livres` de bruit
Contre	« Ukraine : le front d'hiver » deviendrait un thème de livre	une seconde table à entretenir dans `ServiceRenormalisation`

Un titre d'article étant unique à sa parution, il ne se réutilise pas : la table à part semble la bonne, mais c'est une décision à acter, pas un détail d'implémentation.

✅ Séparateur tranché le 2026-08-20 : le point-virgule. Un titre d'article contient souvent une virgule (« Ukraine, deux ans après »), qui couperait le titre en deux. ⚠️ Reste une question ouverte : les thèmes de livres se saisissent à la virgule — faut-il les aligner sur ; pour que deux champs voisins ne se saisissent pas différemment, ou assumer la divergence parce qu'un thème (« dark fantasy ») ne contient jamais de virgule ? À poser à l'utilisateur avant de coder. Le reste suit les règles déjà tenues : dédoublonnage avant résolution, NormalisationTexte, premier libellé saisi = forme affichée.

Lot P — Ranger une envie dans une série

Demande : depuis la liste d'envies, placer un livre souhaité dans une série, comme on y place un livre du catalogue. C'est le chemin inverse de MettreEnEnviesAsync, qui fait déjà « place vide → envie ».

⚠️ Le piège est un invariant, pas une difficulté technique : les séries sont communes au foyer, la liste d'envies est personnelle — et son sens même est de préparer un cadeau sans que l'autre le voie venir. Une envie rattachée telle quelle à une série s'afficherait à tout le monde.

Deux façons de faire, et la première est à écarter :

	`ElementSerie.LivreSouhaiteId` (FK)	Une place ordinaire, titre repris de l'envie
Portée	⚠️ met du personnel dans une table commune : le foyer verrait qui veut quoi	la place reste commune, l'envie reste personnelle — rien ne les relie en base
Ce qu'on voit	« tome 3 souhaité par Mathieu »	« tome 3 » manquant, comme n'importe quel trou
À l'achat	il faudrait défaire la FK	la place s'attache au `Livre` créé, geste déjà en place

La seconde revient à ce que fait déjà la saisie manuelle d'un tome manquant : LivreId reste NULL, Titre porte celui de l'envie. Le geste ne fait alors qu'épargner une resaisie, ce qui est exactement la demande.

⚠️ Ne pas croire que « ça ne fuite rien » pour autant : un tome ajouté à une saga est visible du foyer. Ce qui doit rester invisible est le lien avec la liste d'envies de quelqu'un, pas l'existence du tome — qu'on aurait de toute façon saisie à la main.

Deux points à trancher avant de coder :

L'envie survit-elle au rattachement ? Par cohérence avec « une envie déjà au catalogue est signalée, jamais supprimée » : oui, elle reste dans la liste. Rien n'a été acheté.
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.

25 KiB Raw Blame History