Ouvre une voie d'hébergement hors YunoHost, en disant ce qu'elle coûte

Un tiers veut installer le projet sur un Synology, où rien du paquet
`_ynh` n'existe. L'application n'étant qu'un processus et un fichier
SQLite, un `Dockerfile` suffit — mais l'essentiel n'est pas là.

Sans portail SSO, il n'y a pas d'identité, et l'application ne s'en
invente pas : les données personnelles se ferment, les communes non.
Mesuré plutôt que supposé, et écrit comme tel : les deux replis
(utilisateur simulé, en-tête injecté) n'authentifient personne, et le
port ne doit être publié que sur la boucle locale.

Le déploiement de référence reste `mabibli_ynh`.

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

README.md

@@ -71,6 +71,10 @@ pour les trois (`MaBibli.Client`, `MaBibli.Shared`, `MaBibli.Api`). `--self-cont
 embarque le runtime .NET dans le dossier produit : aucun `dotnet-runtime` n'est requis
 côté serveur.
 
+Pour un hébergement **sans YunoHost** (Synology, VPS), voir « Installer ailleurs que sur
+YunoHost » plus bas : le `Dockerfile` de la racine fait ce même publish, mais sans
+`--self-contained` — dans un conteneur, l'image `aspnet` fournit déjà le runtime.
+
 ⚠️ **Ne jamais compiler sur le serveur YunoHost lui-même** : ce serait imposer le SDK
 complet à une machine qui n'en a pas besoin, pour une compilation lente. Voir
 `CLAUDE.md`, section « Chaîne de publication ».
@@ -468,6 +472,103 @@ Les trois doivent être négatifs. Le domaine, lui, reste déclaré dans YunoHos
 
 ---
 
+## Installer ailleurs que sur YunoHost (Synology, NAS, VPS)
+
+Le déploiement de référence reste le paquet `mabibli_ynh` : c'est lui qui est éprouvé, et
+c'est le seul qui apporte une **authentification**. Ce qui suit sert aux hébergements qui
+n'ont pas de portail SSO. `Dockerfile`, `.dockerignore` et `compose.yaml`, à la racine de
+ce dépôt, existent pour ça.
+
+L'application n'est qu'**un processus et un fichier SQLite** : `MaBibli.Api` sert lui-même
+le client Blazor. Il n'y a donc rien à orchestrer.
+
+### ⚠️ Hors YunoHost, il n'y a AUCUNE authentification
+
+C'est le point à comprendre avant tout le reste, et il ne se contourne pas par la
+configuration. `FournisseurUtilisateurSsowat` lit l'en-tête `YNH_USER` que le portail
+injecte ; sans portail, il n'y a pas d'identité, et l'application **ne s'en invente pas**.
+
+Conséquence exacte, vérifiée en exécution :
+
+| | Sans identité |
+|---|---|
+| Catalogue, auteurs, séries, revues, prêts (**communs** au foyer) | fonctionnent |
+| Statuts de lecture, listes d'envies (**personnels**) | refusés — `400 « Impossible d'ajouter une envie sans savoir à qui elle appartient. »` |
+
+Deux façons de rendre une identité, **aucune des deux n'authentifie qui que ce soit** :
+
+- `Identite__UtilisateurSimule` en variable d'environnement. C'est le mécanisme prévu pour
+  le développement, mais c'est de la configuration ordinaire : elle vaut aussi en
+  production. Mono-utilisateur.
+- l'en-tête `YNH_USER` injecté par le proxy inversé (DSM : *Portail des applications >
+  Proxy inversé > En-tête personnalisé*). Même niveau de sécurité, mais si un proxy
+  authentifiant est ajouté un jour (Authelia, authentik), il n'y a plus qu'à lui faire
+  recopier son `Remote-User` vers `YNH_USER` : l'application n'a rien à changer.
+
+⚠️ Dans les deux cas, **quiconque atteint le port EST cet utilisateur**. Le port ne doit
+donc être publié que sur la boucle locale (`127.0.0.1:8080:8080`), le proxy inversé restant
+le seul chemin d'accès. C'est la transposition exacte de la contrainte d'écoute que le
+paquet YunoHost pose comme dure.
+
+### Trois prérequis qui ne se négocient pas
+
+- **Une machine x86_64.** Le publish visé est `linux-x64` : les NAS ARM (les modèles « j »
+  notamment) demanderaient de republier en `linux-arm64`, ce qui n'est pas éprouvé ici.
+- **HTTPS**, sans quoi le scan du code-barres ne s'ouvrira **jamais** : la caméra exige un
+  contexte sécurisé. Sur Synology, cela veut dire proxy inversé + certificat Let's Encrypt
+  sur un nom DDNS (`mabibli.xxx.synology.me`).
+- **Un nom d'hôte entier, pas un sous-chemin** — `mabibli.xxx.synology.me`, jamais
+  `nas.xxx.synology.me/mabibli`. La raison est la même que pour le `full_domain` de
+  YunoHost, et elle est développée plus bas : `<base href="/">` et les empreintes du
+  service worker sont figés à la compilation.
+
+### La marche à suivre
+
+```bash
+git clone <ce dépôt> mabibli && cd mabibli
+# éditer compose.yaml : nom d'utilisateur, chemin du volume
+docker compose up -d --build
+```
+
+Sur Synology, le même `compose.yaml` se colle dans *Container Manager > Projet*, en
+remplaçant `./donnees` par un chemin réel (`/volume1/docker/mabibli`).
+
+Les migrations EF Core s'appliquent seules au premier démarrage : la base se crée dans le
+volume, et c'est **le volume seul** qui la fait survivre au remplacement de l'image.
+
+### Ce qu'il faut savoir avant de s'y mettre
+
+- **La sauvegarde ne se fait pas en copiant le `.db`.** SQLite tourne en mode WAL : copier
+  le seul fichier d'une base active peut ne rien sauvegarder du tout. Il faut arrêter le
+  conteneur, ou passer par `sqlite3 … ".backup"` — c'est ce que fait le paquet YunoHost, et
+  la raison est écrite dans `mabibli_ynh/doc/ADMIN.md`.
+- **Il n'y a pas de mécanisme de mise à jour.** Ni `yunohost app upgrade`, ni release, ni
+  vérification de `sha256` : à chaque version, `git pull` puis `docker compose up -d
+  --build`. Les données ne bougent pas, elles sont dans le volume.
+- **L'image est construite depuis les sources, pas depuis une release.** Elle ne porte donc
+  aucun numéro de version, et « À propos » affiche honnêtement « version de développement ».
+  Pour un vrai numéro, passer `-p:Version=X.Y.Z -p:MaBibliDateBuild=…` au `dotnet publish`
+  du `Dockerfile` — voir `CLAUDE.md`, « Y — l'application dit sa version ».
+
+### Vérifié en exécution le 2026-08-21
+
+Image construite et démarrée localement, base neuve dans un volume monté :
+
+| Cas | Résultat |
+|---|---|
+| Migrations au premier démarrage | appliquées, `mabibli.db` créé dans le volume |
+| `GET /` et `_framework/blazor.webassembly.js` | **200**, `<base href="/">` intact |
+| `GET /api/moi` avec `Identite__UtilisateurSimule` | `{"identifiant":"prenom","simule":true}` |
+| `GET /api/moi` sans rien | `{"identifiant":null,"affichage":"inconnu"}` |
+| `GET /api/moi` avec en-tête `YNH_USER: camille` | `{"identifiant":"camille","simule":false}` |
+| `POST /api/souhaits` sans identité | **400**, message lisible |
+
+⚠️ **Ce qui n'a PAS été vérifié** : l'installation sur un Synology réel, le proxy inversé de
+DSM et le certificat. Ce sont des gestes de DSM, pas du code — mais personne ne les a
+éprouvés ici.
+
+---
+
 ## Contraintes permanentes du paquet — ce ne sont pas des tâches
 
 ### Le dépôt du code doit rester public