Note trois idées sur le paquet YunoHost

Simplification du paquet, icône, et RAM déclarée au plus près du réel —
ces deux dernières valeurs étant posées à l'estime et jamais mesurées.

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

IDEES.md

@@ -729,3 +729,55 @@ en second rideau** et l'**EAN-2 à confirmer en kiosque** — la série du 2026-
   entière** (`Numero` à `NULL`), et posséder un numéro ne comble pas ce souhait-là. Un signalement
   faux sur une liste de cadeaux est pire que pas de signalement — même raisonnement que le grisage
   faillible de la bibliographie.
+
+---
+
+# Le paquet YunoHost — retours du 2026-08-22
+
+## Simplifier `mabibli_ynh`
+
+Demande telle quelle : « retravailler la partie YunoHost pour la simplifier ». Rien n'est
+diagnostiqué à ce stade — le paquet **fonctionne** (installé, mis à jour, sauvegardé et restauré
+sur un vrai serveur, voir `CLAUDE.md`), il s'agit de le rendre plus simple à lire et à
+entretenir, pas de le réparer.
+
+Ce qu'il contient aujourd'hui : `manifest.toml`, `conf/nginx.conf`, `conf/systemd.service`,
+`scripts/{install,upgrade,remove,backup,restore,_common.sh}`, `doc/`, et `build/publier.sh`
+(18 Ko à lui seul).
+
+⚠️ **Deux choses ne se simplifient pas sans perdre ce qu'elles protègent**, et il faudra le
+redire au moment de tailler :
+
+- l'unité systemd porte `ProtectSystem=strict`, `ProtectHome=tmpfs` + `BindPaths`, et le
+  guillemetage de `Environment=` — les trois viennent de pannes **réellement constatées** en
+  production, pas de la prudence de principe ;
+- `publier.sh` refuse de publier un tag déjà existant ou un dépôt sale. C'est ce qui a remplacé
+  les deux scripts d'avant, dont la coexistence était le défaut.
+
+À décider avant de commencer : ce qu'on entend par « simplifier » — moins de fichiers, moins de
+lignes, ou moins de choses à savoir pour publier une version ? Ce ne sont pas les mêmes coupes.
+
+## L'icône du paquet
+
+`mabibli_ynh/logo.png` **existe** (824 o, 256×256, même dessin que l'application). Reste à
+établir ce qui manque exactement — le catalogue YunoHost et la tuile du portail ne lisent pas
+forcément le même fichier au même endroit. ⚠️ À ne pas confondre avec les icônes **de la PWA**
+(`favicon.png`, `icon-192.png`, `icon-512.png`), qui sont dans le dépôt du code et déjà en place.
+
+## Ajuster la RAM déclarée au plus près du réel
+
+`manifest.toml` annonce `ram.build = "50M"` et `ram.runtime = "200M"` — des valeurs **posées à
+l'estime**, jamais mesurées. YunoHost s'en sert pour refuser une installation sur une machine
+trop petite : trop haut, on interdit une installation qui aurait marché ; trop bas, on la laisse
+se faire pour finir en OOM.
+
+⚠️ **Se mesurer sur le serveur, pas ici.** Un `dotnet run` de développement ne dit rien de la
+consommation d'un publish self-contained sous systemd. Le relevé utile est celui du service en
+marche (`systemctl show mabibli -p MemoryCurrent`, ou `MemoryPeak`), après une navigation
+ordinaire **et** après un lookup ISBN — c'est là que le client HTTP et le parseur travaillent.
+
+⚠️ `ram.build` ne désigne pas une compilation : **rien n'est compilé sur le serveur** (le
+self-contained est justement là pour ça). Ce qu'il couvre, c'est le téléchargement et la
+**décompression** d'une archive de 69 Mo. La valeur à chercher n'est donc pas celle d'un build
+.NET, et il ne faut pas aller la chercher là.
+