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>

CLAUDE.md

@@ -2054,6 +2054,62 @@ lui-même** pour les afficher dans son catalogue et son interface d'administrati
 compilation, et rien n'est recompilé sur le serveur. Le manifeste déclare donc
 l'application en `full_domain`.
 
+## Héberger hors YunoHost — voie SECONDAIRE, ajoutée le 2026-08-21
+
+Demande venue d'un tiers voulant installer le projet sur un **Synology**. `Dockerfile`,
+`.dockerignore` et `compose.yaml` sont à la racine du dépôt du code, et la marche à suivre
+est dans `README.md` (« Installer ailleurs que sur YunoHost »).
+
+⚠️ **Le déploiement de référence reste `mabibli_ynh`, et cela ne se discute pas** : c'est le
+seul qui apporte une **authentification**. Cette voie-ci n'en apporte aucune, et il ne faut
+pas la présenter comme une seconde façon d'installer « la même chose ».
+
+### Ce que l'absence de portail coûte exactement
+
+Mesuré, pas supposé : sans `YNH_USER`, `UtilisateurCourant.Anonyme` circule, et les données
+**personnelles** se ferment (`400` avec un message lisible sur les envies, aucun statut de
+lecture), tandis que tout ce qui est **commun** au foyer continue de fonctionner. C'est la
+triple portée du projet — commune / personnelle / trace — qui devient visible à l'usage.
+
+Deux replis, et **aucun des deux n'authentifie** :
+
+| Repli | Quand |
+|---|---|
+| `Identite__UtilisateurSimule` en variable d'environnement | mono-utilisateur ; c'est le mécanisme de développement, qui n'a rien de spécifique à `Development` — c'est de la configuration ordinaire |
+| en-tête `YNH_USER` injecté par le proxy inversé | dès qu'un proxy authentifiant existe (Authelia…), il n'y a plus qu'à recopier son `Remote-User` — **l'application ne change pas** |
+
+⚠️ Le corollaire est le même que sur YunoHost et il est **plus facile à rater** ici : le port
+ne doit être publié que sur `127.0.0.1`. Quiconque atteint le port *est* l'utilisateur
+déclaré. Dans un conteneur, écouter sur `+:8080` est sans danger — c'est la **publication**
+du port qui décide de l'exposition, pas l'écoute.
+
+### Trois décisions d'image
+
+- **Pas de `--self-contained`** dans le conteneur, contrairement au paquet YunoHost. Le
+  self-contained sert à ne rien exiger d'un serveur qu'on ne maîtrise pas ; l'image `aspnet`
+  fournit déjà le runtime, et l'embarquer une seconde fois ne servirait qu'à grossir.
+- **Pas d'`ASPNETCORE_URLS`** : l'image écoute déjà sur 8080, et le poser journalise un
+  avertissement `Overriding HTTP_PORTS` à chaque démarrage — du bruit dans les logs, sur la
+  voie précisément destinée à qui ne connaît pas le projet.
+- **Aucun `dotnet workload install`** n'est nécessaire : vérifié, la machine de
+  développement n'a **aucune** charge de travail installée et le publish Blazor WASM
+  (trimming compris) passe avec le SDK nu.
+
+### Les trois contraintes reconduites telles quelles
+
+x86_64 (le publish visé est `linux-x64`), **HTTPS** sans quoi le scan caméra ne s'ouvre
+jamais, et un **nom d'hôte entier** — `<base href="/">` et les empreintes du service worker
+sont figés à la compilation, exactement ce qui impose `full_domain` à YunoHost.
+
+### Vérifié en exécution le 2026-08-21
+
+Image construite, conteneur démarré sur une base neuve : migrations appliquées dans le
+volume, `/` et `_framework/blazor.webassembly.js` en 200, et les trois états d'identité
+(simulée, absente, en-tête `YNH_USER`) rendus par `GET /api/moi` conformément au tableau
+ci-dessus. ⚠️ **Rien n'a été éprouvé sur un Synology réel** — ni Container Manager, ni le
+proxy inversé de DSM, ni son certificat. Ce sont des gestes de DSM, pas du code, mais le
+README doit continuer de le dire.
+
 ## Historique du projet (pourquoi ces choix)
 
 L'utilisateur a testé deux solutions existantes avant de se lancer dans un projet custom :